Ở phần trước, tôi đã trình bày qua với các bạn những khái niệm cơ bản của PKI và Web PKI. Tôi cũng có nhắc đến Internal PKI và trong phần này ta cùng nhau điểm qua Internal PKI trước khi đến Code Signing. Đây là phần dài nhất trong cả series và nó cũng chứa nhiều thông tin nhất, mong các bạn vừa đọc vừa phản biện nhé.
Internal PKI:
Trong khi Web PKI là PKI sử dụng cho web thì về mặt ngữ nghĩa, internal PKI là những giải pháp PKI dành cho các dịch vụ internal – những dịch vụ riêng biệt, mang tính chất nội bộ nằm trong các tổ chức, công ty, etc. Ví dụ như thế này, trong công ty của bạn, khi một văn bản được gửi từ nhiều phòng ban khác nhau thì bạn cần chứng thực rằng: văn bản tôi gửi qua phòng marketing => tài chính => IT không bị fake. Internal PKI sẽ giúp chúng ta tạo ra các chữ ký điện tử cho từng phòng ban đó. Vậy tại sao Web PKI không làm được việc này? Ta có rất nhiều CA nổi tiếng trên thế giới (DigiCert là 1 ví dụ trong báo chungta.vn)? Nói nôm na, Web PKI là dành cho Web và có rất nhiều sự khác biệt giữa Web và các dịch vụ nội bộ. Có một số vấn đề như sau:
– Trong nội bộ mà ta muốn nhiều ứng dụng và chúng chạy liên tục trong một thời gian dài thì các cert cũng phải có giá trị trong khoảng thời gian dài đó. Tuy nhiên các CA hiện nay đều có các điều lệ liên quan đến Rate Limit (trong đó có quy định về số lượng certs cho một domain) và tính Availability của cert (tức là cert đều có thời gian hết hạn) và điều quan trọng là người dùng hầu như không có quyền quản trị các yếu tố trên (các CA sẽ làm điều đó). Giả sử rằng, trong một tiến trình DevSecOps nội bộ, có rất nhiều step, mỗi step cần 1 cert, tuy nhiên các CA chỉ cho phép số lượng nhiều nhất có thể bằng 1/2 số lượng step?
– Vấn đề thứ 2 mà tôi nghĩ quan trọng nhất chính là các Web PKI CA không được phép cấp các cert cho các địa chỉ IP nội bộ, e.g. 172.16.1.1 hoặc các domain name không fully-qualified, không resolvable trong public, e.g. các domain trong k8s kiểu “foo.bar.internal.local.cluster”. Mà một cert cần phải có thông tin về domain mà cert đó được cấp cho, vậy trong trường hợp này thì sao?
Đến đây, chúng ta ngầm hiểu rằng, với những tiến trình nội bộ phức tạp chứa nhiều dịch vụ cần chứng thực mà domain của các dịch vụ đó không fully-qualified, resolvable trong public thì ta cần một giải pháp Internal PKI. Nếu các bạn có thời gian, có thể xem qua một tổ chức đang nghiên cứu các chuẩn hoá cho Internal PKI (https://spiffe.io/).
OK, tôi nghĩ chúng ta cũng đã đi qua các khái niệm cơ bản và sau đây là lý do tại sao tôi lại dẫn dắt câu chuyện nó dài dòng như vậy. Chủ đề chính của series này chính là Zero Trust Supply Chain trong việc phát triển phần mềm, tuy nhiên, căn cơ của việc ứng dụng zero trust trong câu chuyện này chính là áp dụng các tư duy cũng như giải pháp liên quan đến signing, verifying các cert cần thiết trong mỗi bước của cả 1 tiến trình phát triển phần mềm. Do đó, tôi nghĩ nếu như ta không nắm được ít nhất những điều căn bản thì sẽ rất dễ bị nhầm lẫn. Và trong phạm vi series này, giải pháp phần mềm mã nguồn mở mà tôi muốn nhắc đến để giải quyết vấn đề Zero Trust Supply Chain chính là SIGSTORE (https://www.sigstore.dev/). Nhưng, trước khi đến với SIGSTORE, chúng ta hãy cùng tìm hiểu một bài toán thực tế. Cá nhân tôi hơi lười vẽ nên tôi sẽ dùng file ảnh của CDFoundation để minh hoạ:
(Source: https://cd.foundation/blog/2021/10/04/zero-trust-supply-chain-security/)
Tôi xin phép được tóm tắt nhanh như sau:
- Trong bối cảnh cloud hiện nay, một giải pháp phát triển phần mềm từ A-Z có thể được triển khai phân tán, trong thực tế thì một số bước vì lý do nào đó, e.g. độ nhạy cảm về dữ liệu hoặc chính sách bảo mật, được triển khai on-prem, còn lại được triển khai trên cloud.
- Các bước từ lúc code được lưu trong repo cho đến khi được deploy trong môi trường production sẽ trải qua nhiều công đoạn mà ở đó không có sự đảm bảo về tính tin cậy. Tôi lấy ví dụ, với các Container Image chẳng hạn, chúng ta có thể dễ dàng download chúng từ các repo public hoặc các repo nội bộ, tuy nhiên việc định danh hay kiểm tra tính xác thực, tin cậy của owner (đặc biệt là đối với public repo) mỗi lần container image thay đổi là khá khó khăn. Ta không thể chắc chắn là các thay đổi của image có đúng là do owner thực hiện hay không, nó có thể dễ dàng bị fake.
- Chính vì vậy mà ở mỗi bước trong cả quy trình phát triển phần mềm, việc đưa các giải pháp chứng thực là vô cùng quan trong. Mặc dù điều này không thể hoàn toàn giải quyết được bài toán Supply Chain Attack (vì có thể đơn vị cấp chứng chỉ bị hack, vấn đề này tôi sẽ nói qua ở sau về Certificate Transparency), nhưng nó giúp giảm thiểu rất nhiều nguy cơ bị tấn công. Và mỗi một artifact (container image, code, etc.) ở mỗi bước được chứng thực thì ta gọi nó là CODE SIGNING.
Câu chuyện đến đây tôi hi vọng đã tường minh hơn. Bài toán chúng ta cần giải chính là ta cần một giải pháp internal PKI để cung cấp, lưu trữ, thu hồi, etc. các chứng chỉ nhằm mục đích chứng thực các bước trong một tiến trình phát triển phần mềm (hay còn gọi là DevSecOps) của một công ty, tổ chức nhất định. Và SIGSTORE giải quyết được nhu cầu này. Tất cả các thông tin về dự án SIGSTORE các bạn có thể đọc và tham khảo trên https://sigstore.dev hoặc có thể search trên Internet, có rất nhiều bài viết về SIGSTORE, dưới đây tôi sẽ tóm tắt một vài điểm chính của dự án này mà tôi nghĩ nó sẽ là cần thiết nhất. Phải nói là Google có một đội ngũ kỹ sư phần mềm tuyệt vời, nhưng lại hơi kém về mặt trình bày (viết tài liệu kỹ thuật :D) cho nên công cuộc tìm hiểu sâu về dự án SIGSTORE của tôi hơi mất nhiều thời gian một chút mặc dù tôi cũng biết đến nó hồi còn làm ở Red Hat:
(Source: https://speakerdeck.com/redhatlivestreaming/secure-your-open-source-supply-chain-with-sigstore?slide=10)
REKOR: Là dự án cung cấp một “immutable, tamper-resistant ledger of metadata” – nôm na là sổ cái mà dữ liệu được lưu trong đó là IMMUTABLE và TAMPER-RESISTANT (dữ liệu ở đây là METADATA được sinh ra trong một supply chain (https://docs.sigstore.dev/rekor/overview/). Tuy nhiên, các bạn để ý chữ “cung cấp” nhé. Thực chất Rekor nó không phải là một sổ cái mà là một lớp tiếp nhận và xử lý metadata còn metadata được mã hoá và lưu ở đâu thì lại nhờ Trillian và Mysql. Nói đúng ra thì Trillian và backend là Mysql mới chính là thành phần đem lại tính chất “sổ cái”. Các bạn nghe thấy cụm từ “immutable, tamper-resistant ledger” khá giống những miêu tả liên quan đến blockchain đúng không :D.
Trillian: Trillian là một dự án mã nguồn mở được phát triển bởi Google. Trillian chính là một append-only ledger mà tính chất append-only (nôm na là chỉ thêm mà ko thể chỉnh sửa hoặc xoá) có được là nhờ Merkle tree. Trillian implement ý niệm của Merkel Tree trong code của mình và backend để lưu Merkle tree chính là Mysql. Bản thân Trillian không phải là 1 dự án của Sigstore mà là một cấu phần trong Rekor.
FULCIO: Trong các thành phần của Sigstore, tôi thấy thú vị nhất ngoài việc sử dụng Trillian như ở trên thì chính là Fulcio. Fulcio đơn giản chính là một CA, là nơi cung cấp cert dựa trên OIDC. 2 yếu tố khác biệt nhất của Fulcio cũng được liệt kê trên GitHub (https://github.com/sigstore/fulcio):
- fulcio is a free Root-CA for code signing certs – issuing certificates based on an OIDC email address.
- fulcio only signs short-lived certificates that are valid for under 20 minutes.
Về cơ chế cấp cert thì các bạn có thể tham khảo các bước cụ thể ở đây nhé: https://github.com/sigstore/fulcio/blob/main/docs/how-certificate-issuing-works.md
Các bạn sẽ thấy sự xuất hiện của một thành phần mới: Certificate Transparency (CT) – “sự minh bạch của cert”. CT không phải là một điều gì đó mới lạ, các bạn có thể search thông tin của nó trên Internet rất nhiều, trong phạm vi bài viết này tôi sẽ cố gắng giải thích nó một cách vô cùng ngắn gọn. Đơn giản thì CA là nơi tạo ra các cert, vậy giả sử nếu CA bị hack thì các hacker họ dễ dàng tạo ra các cert giả và dùng nó để thực hiện nhiều cuộc tấn công (đặc biệt trong môi trường public web). CT giúp người dùng bằng cách cung cấp một hệ thống log (ngoài ra còn monitor và audit), hay còn gọi là bản ghi của các cert được cấp bởi các CA tin cậy. Người dùng có thể check một cert có được cấp bởi một CA tin cậy hay không hay là cert này đã được giả mạo thì có thể check log được cung cấp bởi CT. Các bạn có thể tìm hiểu thêm mô hình hoạt động của CT theo link này: https://certificate.transparency.dev/howctworks/ Ok, vậy trong bài toán của sigstore thì ta sẽ dùng 1 CT làm log để lưu các cert của Fulcio. Các cert sẽ được lưu theo cơ chế của Merkel Tree với backend là Mysql. Toàn bộ việc implementation của thuật toán Merkel Tree được thể hiện thông qua Trillian server. (Tôi sẽ không đi sâu vào Merkel Tree tránh dài dòng, các bạn có thể tự tìm hiểu khái niệm này trên Internet.). Các bạn có thể tìm hiểu thêm flow của việc cấp 1 certificate trong sigstore theo link dưới đây:
- https://github.com/sigstore/fulcio/blob/main/docs/how-certificate-issuing-works.md
- https://github.com/sigstore/fulcio/blob/main/docs/ctlog.md.
Quy trình này cũng là một quy trình chuẩn, ta có thể gặp rất nhiều trong Web PKI chẳng hạn. Trong lúc tìm hiểu các bạn có thể thấy 2 từ đó là PRE-CERTIFICATE và FINAL CERTIFICATE. Precertificate chính là cert mà CA ký tuy nhiên chưa gửi lại cho client mà cert này được lưu vào trong CT. Sau đó CT sẽ lấy thông tin của pre-cert và tạo ra một SCT (Signed Certificate Timestamp) – là một cryptographic object được tạo ra bằng việc dùng private key của CT để ký – để chứng minh rằng: vào thời điểm cụ thể …. (Ngày, giờ, etc.), một CA đã kí một pre-cert và lưu vào trong CT. Sau đó, cả pre-cert và SCT sẽ được CT gửi lại tới CA, CA sẽ tạo ra một FINAL CERT dựa trên PRECERT và SCT và gửi FINAL CERT tới client. Cuối cùng client sẽ chứng thực rằng SCT này là đúng (bằng việc sử dụng public key của CT). Việc chứng thực SCT là đúng đồng nghĩa với việc khẳng định rằng chính CA là đơn vị đã tạo ra cái precert mà ko phải CA mạo danh nào khác. Đây chính là ý nghĩa sâu xa của việc dùng CT.
Vậy tại sao lại phải dùng SCT? Tất cả đều có lý do của nó. SCT chính là một model trong việc thực hiện security. Các bạn có thể tham khảo tại đây nhé: https://github.com/sigstore/fulcio/blob/main/docs/security-model.md
Tôi nghĩ đến đây là quá nhiều thông tin về Sigstore mà tôi cho rằng sẽ tốt hơn nếu để các bạn tự trải nghiệm nó. Phần demo tôi cũng đã chuẩn bị, hi vọng sẽ có dịp demo với các bạn trong một buổi technical meetup nào đó của FPT.
Br,
Vietstack/Tuti
