Security (sec) luôn là một trong những lĩnh vực cá nhân tôi khá là ngại khi động vào. Thú thực là bản thân tôi cũng khá là lười khi nghiên cứu về security, một phần do chưa có quá nhiều động lực, một phần khác là lý thuyết về security cũng vô cùng phức tạp, phải dành nhiều thời gian, đặc biệt là những thuật toán liên quan đến mã hoá (tổng quát hoá là mật mã học – cryptography). Tuy nhiên trong thời gian cloud computing ngày càng phát triển, các workload này càng được phân tán kéo theo các lý thuyết về security được hoàn thiện theo nhiều hướng tiếp cận mới, điều này thôi thúc cá nhân tôi dành thời gian nhiều hơn cho mảng security. Thêm vào đó là sự kiện SolarWinds bị supply-chain attack năm 2021 gây ra hậu quả vô cùng nghiêm trọng đã dấy lên một mối lo ngại thực sự về cyberattack, đặc biệt trong thời gian tới khi mà cloud computing sẽ bùng nổ vô cùng mạnh mẽ, là một thế hệ hạ tầng mới cho các workload trong tương lai.
Trong phạm vi bài viết này, tôi sẽ mạo muội chia sẻ những gì tôi biết dựa trên kinh nghiệm làm việc cũng như hiểu được sau khi dành thời gian đọc, tìm hiểu và thực hành. Vì sec là một phạm trù quá rộng, tôi sẽ chỉ tập trung đi vào các giải pháp mã nguồn mở cho supply-chain security vì nó vô cùng quan trọng cho xu hướng phát triển các ứng dụng trên cloud sau này. Tại sao tôi lại đề cập đến mã nguồn mở vì một phần tôi là big fan của mã nguồn mở, phần khác là vì khi sử dụng các sản phẩm của hãng, người dùng có thể quy kết trách nhiệm cho hãng khi có vấn đề xảy ra mà đôi lúc không cần quan tâm đến điều gì thực sự xảy ra bên trong. Cá nhân tôi luôn đề cao việc tìm đến tận gốc mọi vấn đề, và mã nguồn mở là cách tiếp cận giúp tôi làm được việc đó. Bên cạnh đó, tôi sẽ giới hạn supply-chain sec trong phạm vi phát triển phần mềm vì tôi cho rằng đã đến lúc chúng ta quan tâm nhiều hơn đến DevSecOps.
Điều đầu tiên tôi muốn đề cập nhanh đến zero-trust architecture theo cách dễ hiểu nhất.
Theo cách truyền thống, bảo mật về network hay bảo mật cho các workload chạy trong các hệ thống được xác định dựa theo một phạm vi nhất định hay còn gọi là perimeter security. Khái niệm và ví dụ về perimeter security có rất nhiều trên Internet, tuy nhiên nói một cách đơn giản thì nó chính là việc sử dụng các firewalls, các hệ thống IDS, IPS, etc. để “cô lập” hệ thống khỏi các nguy cơ tấn công từ bên ngoài. Toàn bộ các thành phần “nằm bên trong” của lớp “perimeter” đó được mặc định là an toàn. Điều này chỉ đạt hiệu quả tốt khi toàn bộ workload nằm tại một vị trí nhất định và cố định. Trong thời đại cloud hiện nay, điều này không còn đúng khi workload hiện tại “phân tán”, bao gồm ở trên cloud và cả on-prem. Do đó, để tăng tính bảo mật, đặc biệt trong những use case khi workload được phân tán ở nhiều nơi thì zero-trust architecture là một hướng đi vô cùng hữu hiệu.
Zero-trust được hiểu một cách thông dụng chính là “không tin tưởng” bất cứ ai/đơn vị/thành phần nào trong tiến trình thực thi bảo mật của một hệ thống. Quay lại ví dụ về perimeter security thì đằng sau “perimeter” (nói cách khác là đằng sau các hệ thống như firewalls, etc.), mọi thứ được an toàn, điều đó có nghĩa là các workload sau perimeter đó “tin tưởng” lẫn nhau. Zero-trust đi ngược với niềm tin đó. Trong kiến trúc zero-trust thì không có thành phần nào tin cậy cả, tất cả đều phải được xác thực trước khi một tương tác diễn ra. Zero trust tập trung vào việc bảo vệ “asset” thay cho việc bảo vệ một “perimeter”. Ví dụ như áp dụng việc định danh cho phần cứng thì ta có thể dùng TPM. Phần cứng ở đây chính là một asset, TPM là một cách thức để định danh phần cứng đó, tăng cường sec theo tư duy zero-trust. Hay một ví dụ điển hình về định danh người dùng của một service khi áp dụng zero-trust chính là bảo mật nhiều lớp, e.g. gửi code xác thực đến điện thoại người dùng.
Zero-Trust Supply Chain Security
Supply Chain Sec là một phạm trù vô cùng rộng, định nghĩa về nó có rất nhiều cách nhìn vì bản thân nó tổng hợp nhiều bên liên quan trong Sec. Tuy nhiên, một yếu tố mà tôi cho rằng khác biệt nhất đó là khi áp dụng supply chain sec trong phát triển phần mềm thì nó tập trung vào việc bảo mật artifact cấu thành nên một phần mềm hơn là các giải pháp bảo mật liên quan đến authorization, authentication. Điều này càng đúng hơn trong thế giới mã nguồn mở. Hãy lấy 1 ví dụ như thế này: Khi ta ứng dụng mã nguồn mở cho các giải pháp phần mềm thì rõ ràng ta nắm bắt được trong phần mềm đó có các thành phần nào, chúng hoạt động ra sao. Thêm vào đó, các giải pháp này trong thời đại cloud sẽ được triển khai theo hình thức phân tán ngày càng nhiều, từ đó tạo nên một sự phức tạp nhất định trong cách quản lý chúng. Các nhà phát triển, vận hành phần mềm cần nắm chắc được thành phần nào đang chạy ở đâu (on-prem, cloud, etc.) và chúng được tạo ra bởi ai. Các thành phần cấu thành nên một ứng dụng được tạo ra bởi rất nhiều artifact (programming language, library, build system, repository, base image, etc.) từ rất nhiều team khác nhau. Do đó, khi ứng dụng tư duy về zero-trust, toàn bộ các artifacts kể trên bắt buộc phải được chứng thực rằng ai là người tạo ra chúng, chúng được lưu ở đâu, chúng đến từ đâu, etc. Điều này dẫn đến việc sinh ra một công việc mới là Code Signing – là trọng tâm của series này – cái mà tôi sẽ nhắc nhiều trong các phần sau. Công việc chứng thực và xác minh các artifact đề cập phía trên đều cần phải dựa trên lý thuyết về mã hoá. Có rất nhiều giải pháp dựa trên mật mã học và không thể không nhắc đến PKI.
PKI?
Public Key Infrastructure hay PKI được xây dựng dựa trên mã hoá khoá công khai hay còn gọi là mã hoá bất đối xứng. Lý thuyết về nó có rất nhiều, tôi sẽ không nhắc lại ở đây nữa, chỉ có một từ tôi nghĩ cần phải làm rõ, đó chính là infrastructure. Từ này gây rất nhiều sự nhiễu loạn, tại sao lại là hạ tầng? Nó không phải chỉ đơn giản chỉ là mật mã học, cụ thể hơn là keys? Nhìn một cách rộng hơn, “hạ tầng” ở đây ám chỉ toàn bộ thành phần cấu thành nên một giải pháp toàn diện giúp khởi tạo, phân bố, lưu trữ, sử dụng, thu hồi, etc. các keys và các chứng chỉ (certificate). Nói nôm na thì ta cần một giải pháp phần mềm/cứng để tạo các keys và chứng chỉ, sau đó lưu trữ và thu hồi chúng dựa trên thời hạn được định sẵn. Các phần tiếp theo của series, tôi sẽ đề cập đến một giải pháp mã nguồn mở đáp ứng được các tác vụ trên. Một trong những ví dụ đơn giản nhất về một PKI đó là SSH. Tuy nhiên SSH không sử dụng certificates mà chỉ sử dụng các keys. Trong thực tế, có rất nhiều giải pháp để xây dựng một PKI cho riêng mình, nhưng tất cả đều phải dựa trên public keys.
Vậy thì certificates là gì? Trước tiên, tôi nghĩ ta cần làm rõ sự khác biệt giữa Encryption và Signing, tức là mã hoá vs ký. Vì cá nhân tôi cho rằng, nếu không hiểu rõ ý niệm này, những người tìm hiểu về PKI và không phải chuyên gia sec như tôi sẽ gặp tình trạng bị “loạn” thông tin.
Encryption: Khi bạn mã hoá dữ liệu, điều đó có nghĩa là bạn muốn dữ liệu đó chỉ được đọc bởi những người bạn tin cậy và bạn cho phép. Điều đó đồng nghĩa với việc bạn sẽ dùng public key của bạn để mã hoá dữ liệu và bạn sẽ đưa cho người mà bạn muốn họ sẽ đọc đoạn mã hoá đó private key của bạn để họ giải mã.
Signing: Trong thực tế, khi chúng ta ký một điều gì đó (văn bản, thư từ, etc.) đồng nghĩa với việc ta xác nhận rằng chính chúng ta (mà không phải ai khác) đồng ý điều gì đó. Ý niệm này cũng được thể hiện trong PKI. Người ký sẽ dùng private key để ký (xác nhận chính xác là tôi, vì chỉ có tôi mới có private key), người nhận sẽ dùng public key của người ký để verify đúng là người ký đã ký mà không phải ai khác.
OK, vậy certificate liên quan gì ở đây? Certificate liên quan đến SIGNING. Certificate trong thực tế nó giống như một cái bằng lái xe chẳng hạn, trên đó lưu thông tin về cá nhân của bạn. Khi gặp cảnh sát giao thông (CSGT), mặc dù không hề quen biết bạn, nhưng CSGT họ tin vào đơn vị cấp bằng lái xe của bạn (vì bằng được cấp bởi sở giao thông vận tải) chứng thực đó là bạn, họ kiểm tra hình ảnh và dấu hiệu nhận biết trên khuôn mặt. Nói theo ngôn ngữ máy tính thì bằng lái xe chính là một dạng dữ liệu mà trên đó lưu thông tin cá nhân chủ sở hữu, bằng lái xe được cấp và kí bởi 1 bên thứ 3 tin cậy (sở giao thông vận tải). Certificate trong PKI cũng vậy. Certificate cũng chính là một dạng dữ liệu lưu thông tin về public key và tên của đơn vị sở hữu public key đó và certificate được ký bởi một bên thứ 3 tin cậy để xác thực rằng thông tin trên certificate đó là đúng. Nó rất đơn giản phải không :D. Khi các bạn vào các trang web sử dụng HTTPS thì sẽ thấy các certificate được xác thực và các web browser xác nhận rằng: web mà bạn đang truy cập là web đúng, không phải giả mạo. Hãy lấy ví dụ về website của báo: chungta.vn.
Đây chính là một cert thực tế của báo chungta.vn của FPT, phần sau tôi sẽ trình bày chi tiết hơn về nội dung trong cert này. Bên cạnh đó tôi cũng sẽ trao đổi một chút về một số thông tin thú vị liên quan đến tiêu chuẩn X509, về giải pháp mã nguồn mở PKI mà tôi muốn đề cập đến.
Vietstack/Tuti
