Kỹ sư QLTT Ghi chú ôn thi
← Về danh sách
Bảo mật & Quyền riêng tư
#Sigstore#키리스 서명#소프트웨어 공급망 보안#투명성 로그#코드 서명
Cập nhật lần cuối · 2026-11-04

Ký không khóa (keyless) các artifact phần mềm và nhật ký minh bạch dựa trên Sigstore

1. Tổng quan

Sigstore là một hệ thống ký mã nguồn mở, trong đó nhà phát triển không cần khóa riêng lưu trữ lâu dài mà chứng minh danh tính OpenID Connect (OIDC) để được cấp một chứng chỉ ngắn hạn, ký artifact phần mềm bằng chứng chỉ đó, và ghi sự kiện ký vào một nhật ký minh bạch (transparency log) công khai để bất kỳ ai cũng có thể xác minh và kiểm toán.

Khi các cuộc tấn công chuỗi cung ứng phần mềm gia tăng, việc chứng minh "liệu binary, container image hay package này có thực sự được tạo bởi một chủ thể đáng tin cậy hay không" trở nên quan trọng. Ký mã truyền thống được thực hiện bằng cách nhà phát triển hoặc tổ chức được cấp một khóa riêng, lưu trữ lâu dài, rồi ký các sản phẩm bằng khóa đó. Tuy nhiên, mô hình này có gánh nặng vận hành lớn trong việc lưu trữ, xoay vòng và thu hồi khóa một cách an toàn, và nếu khóa bị rò rỉ thì mọi chữ ký trong quá khứ và tương lai đều bị đe dọa cùng lúc. Hơn nữa, chỉ riêng sự tồn tại của một chữ ký thì bên ngoài khó có thể xác nhận độc lập rằng chữ ký đó được tạo khi nào, với danh tính nào, và không bị giả mạo.

Sigstore tái cấu trúc vấn đề này theo hai trục. Thứ nhất là ký không khóa (keyless), loại bỏ việc lưu trữ khóa lâu dài. Chỉ tại thời điểm ký mới tạo một cặp khóa tạm thời, và khi chứng minh được danh tính OIDC của tổ chức (ví dụ danh tính workflow GitHub Actions, tài khoản Google/GitHub) thì cơ quan chứng thực cấp một chứng chỉ ngắn hạn chỉ có hiệu lực vài phút. Khi ký xong, khóa riêng bị hủy, nên bề mặt tấn công "rò rỉ khóa đã lưu trữ" tự nó biến mất. Thứ hai là tính minh bạch, ghi sự kiện ký vào một nhật ký chỉ thêm (append-only) công khai. Vì chủ thể ký, chứng chỉ và thời điểm được ghi vào nhật ký chống giả mạo, bên xác minh có thể dựa vào nhật ký để xác nhận rằng "danh tính đã hợp lệ tại thời điểm ký" ngay cả khi chứng chỉ đã hết hạn.

Trong bài luận, mô tả Sigstore chỉ như một "công cụ ký miễn phí" là chưa đủ. Thứ nhất, phải phân biệt vai trò của SBOM (danh mục thành phần), SLSA (bằng chứng về quá trình tạo lập) và Sigstore (ký và chứng minh danh tính). Thứ hai, không nên khẳng định "không có khóa nên an toàn hơn" mà phải giải thích rằng niềm tin chỉ chuyển dịch sang nhà cung cấp danh tính OIDC và hệ thống phân phối gốc tin cậy. Thứ ba, cần đề xuất chiến lược triển khai theo giai đoạn cân bằng giữa sự tiện lợi cho nhà phát triển và tính vững chắc của việc xác minh.

A. Bối cảnh ra đời và sự cần thiết

Bối cảnh thứ nhất là giới hạn mang tính cấu trúc của việc quản lý khóa. Để ký các sản phẩm mã nguồn mở bằng GPG hay PKI riêng, mỗi dự án phải tạo và lưu trữ khóa riêng, rồi vận hành việc hết hạn và thu hồi. Trên thực tế, khóa thường bị để dạng văn bản thuần trên laptop hoặc trong cấu hình CI, hoặc bị thất lạc khi người phụ trách rời đi. Sigstore giảm đồng thời gánh nặng vận hành này và rủi ro rò rỉ bằng "một khóa chỉ tồn tại thoáng chốc khi ký rồi bị vứt bỏ".

Bối cảnh thứ hai là khoảng trống ký trong hệ sinh thái phân phối. Trong các hệ sinh thái như npm, PyPI, container registry, nơi hàng triệu mục được phân phối mỗi ngày, gần như không có bằng chứng xác minh được artifact thực sự đến từ nguồn hay bản build nào. Sigstore gắn chữ ký với danh tính của workflow CI, cho phép kiểm tra chính sách kiểu "package này được tạo bởi workflow được bảo vệ của repository này".

Bối cảnh thứ ba là yêu cầu về khả năng kiểm toán độc lập. Mua sắm công, tài chính và các quy định, hướng dẫn an toàn chuỗi cung ứng khác nhau đòi hỏi không chỉ sự tồn tại của chữ ký mà còn phải truy vết được "ai đã ký khi nào" về sau. Nhật ký minh bạch công khai làm cho chủ thể ký khó phủ nhận về sau rằng "tôi chưa từng ký" (chống chối bỏ), và mở ra con đường phát hiện qua giám sát nhật ký nếu có chữ ký độc hại chen vào.

B. Mục tiêu và phạm vi

Mục tiêu của Sigstore không phải ngăn chặn mọi lỗ hổng mà là làm cho việc ký trở nên dễ dàng và xác minh được, để tự động phán định độ tin cậy về nguồn gốc của artifact. Ví dụ, có thể đặt chính sách "image triển khai lên production phải được ký bằng danh tính GitHub Actions của repository được phê duyệt, và chữ ký đó phải tồn tại trong nhật ký công khai", rồi tự động phán định ở bước xác minh. Phạm vi trải dài từ tạo khóa tạm thời, chứng minh danh tính (OIDC), cấp chứng chỉ ngắn hạn, ký, ghi nhật ký, phân phối gốc tin cậy, đến xác minh trước khi triển khai. Ngược lại, lỗ hổng trong chính mã nguồn, mức độ cô lập build, bảo vệ runtime không được Sigstore thay thế một mình, nên phải thiết kế cùng với SLSA, SBOM và bảo mật runtime.

2. Các thành phần cốt lõi và cấu trúc của Sigstore

Chìa khóa để hiểu Sigstore là mối quan hệ giữa Fulcio (CA cấp chứng chỉ ngắn hạn), Rekor (nhật ký minh bạch chữ ký), Cosign (công cụ máy khách), và gốc tin cậy được phân phối bởi TUF (The Update Framework). Người ký dùng Cosign tạo khóa tạm thời, chứng minh danh tính qua OIDC để nhận chứng chỉ ngắn hạn từ Fulcio, rồi ký artifact và đẩy sự kiện lên Rekor. Bên xác minh lấy Fulcio root CA và khóa công khai Rekor nhận qua TUF làm chuẩn tin cậy, và kiểm tra đồng thời chữ ký, chứng chỉ và mục nhật ký.

flowchart LR
    DEV["Nhà phát triển / Workflow CI"] --> COSIGN["Máy khách Cosign\nTạo khóa tạm thời / ký"]
    OIDC["Nhà cung cấp danh tính OIDC\n(GitHub, Google, v.v.)"] --> COSIGN
    COSIGN --> FULCIO["Fulcio\nCA cấp chứng chỉ ngắn hạn"]
    FULCIO --> COSIGN
    COSIGN --> REKOR["Rekor\nNhật ký minh bạch chữ ký"]
    COSIGN --> ART["Artifact đã ký\nImage / Package / Binary"]
    TUF["Phân phối gốc tin cậy TUF\n(Root CA / khóa công khai nhật ký)"] --> VERIFY["Bên xác minh / Policy Engine"]
    ART --> VERIFY
    REKOR --> VERIFY
    VERIFY --> DECIDE["Cho phép hoặc chặn triển khai"]

A. Fulcio — CA cấp chứng chỉ ngắn hạn

Fulcio là cơ quan chứng thực, sau khi xác nhận danh tính OIDC của người ký, cấp một chứng chỉ X.509 ngắn hạn có hiệu lực vài phút ràng buộc danh tính đó với khóa công khai tạm thời. Điểm cốt lõi là tuổi thọ của chứng chỉ rất ngắn nên không tồn tại "bí mật lưu trữ lâu dài". Dù chứng chỉ hết hạn, hiệu lực của chữ ký vẫn được bảo đảm bởi bản ghi "thời điểm ký" lưu trong Rekor. Fulcio đưa giá trị danh tính (ví dụ email, định danh workflow) vào các trường mở rộng của chứng chỉ, để bên xác minh phán định được "ai đã ký" chỉ từ chứng chỉ. Chẳng hạn khi ký trong GitHub Actions, thông tin repository, workflow và trigger được khắc vào làm danh tính, nên có thể đặt chính sách "chỉ cho phép workflow release của repository này làm chủ thể ký".

B. Rekor — nhật ký minh bạch chữ ký

Rekor là nhật ký minh bạch ghi các sự kiện ký (giá trị chữ ký, chứng chỉ, thời điểm, v.v.) vào một nhật ký chỉ thêm, chống giả mạo. Về cấu trúc, nó dựa trên cây Merkle (Merkle tree), nên cung cấp bằng mật mã học một "bằng chứng bao hàm (inclusion proof)" rằng một mục nhất định có trong nhật ký, và một "bằng chứng nhất quán" rằng nhật ký không sửa đổi quá khứ. Nhờ đó bù đắp điểm yếu của chứng chỉ ngắn hạn. Bên xác minh không nhìn vào "chứng chỉ có hết hạn ngay bây giờ không" mà nhìn vào "chứng chỉ có hợp lệ tại thời điểm chữ ký được ghi vào nhật ký không". Nhật ký công khai cũng là cơ sở cho kiểm toán và giám sát. Tổ chức có thể giám sát các chữ ký được đẩy lên dưới danh tính của mình và phát hiện sớm việc lạm dụng danh tính nếu thấy một mục ngoài dự kiến.

C. Cosign — máy khách ký và xác minh

Cosign là công cụ máy khách gắn kết Fulcio, Rekor và các OCI registry để thực hiện việc ký và xác minh thực tế. Nó có thể ký và đính kèm không chỉ container image mà cả tệp thông thường (blob) và các chứng thực (attestation) như SBOM, SLSA provenance, xử lý chữ ký và siêu dữ liệu chuỗi cung ứng trong một hệ thống. Chế độ keyless là luồng mặc định, nhưng tùy tình huống tổ chức nó cũng hỗ trợ dùng khóa KMS hoặc khóa phần cứng, giúp chuyển đổi dần dần. Khi xác minh, nó kiểm tra đồng thời chữ ký, chứng chỉ và mục nhật ký, và cho phép nêu rõ các điều kiện chính sách như danh tính, nhà phát hành được phép, ngăn việc xác minh lỏng lẻo kiểu "cứ có chữ ký là qua".

D. Gốc tin cậy TUF — điểm xuất phát của niềm tin

Để việc xác minh thành lập, chứng chỉ Fulcio root CA và khóa công khai Rekor phải được lấy và cập nhật một cách an toàn, và TUF (The Update Framework) đảm nhận việc này. TUF phân phối tài liệu gốc bằng siêu dữ liệu đã ký và được thiết kế để chống tấn công người-ở-giữa ngay cả khi xoay vòng, thu hồi khóa. Nghĩa là niềm tin của Sigstore đã chuyển dịch từ "khóa lâu dài của nhà phát triển" sang "nhà cung cấp danh tính OIDC + gốc tin cậy phân phối qua TUF", chứ không biến mất. Do đó, dưới góc nhìn Kỹ sư chuyên nghiệp, tính sẵn sàng và toàn vẹn của nhà cung cấp danh tính và hệ thống phân phối gốc tin cậy trở thành điểm kiểm soát cốt lõi mới.

3. Quy trình ký và xác minh không khóa

Ký không khóa diễn ra theo trình tự "tạo khóa tạm thời → chứng minh danh tính → cấp chứng chỉ ngắn hạn → ký → ghi nhật ký", và việc xác minh lần ngược lại trình tự này. Sơ đồ trình tự dưới đây cho thấy tương tác giữa chủ thể ký (nhà phát triển/CI) với Fulcio, Rekor và bên xác minh.

sequenceDiagram
    participant D as "Người ký (CI/Nhà phát triển)"
    participant O as "Nhà cung cấp OIDC"
    participant F as "Fulcio (CA)"
    participant R as "Rekor (Nhật ký)"
    participant V as "Bên xác minh"
    D->>D: "Tạo cặp khóa tạm thời"
    D->>O: "Yêu cầu xác thực danh tính"
    O-->>D: "Cấp token OIDC"
    D->>F: "Nộp token + khóa công khai"
    F-->>D: "Cấp chứng chỉ ngắn hạn (ràng buộc danh tính)"
    D->>D: "Ký artifact"
    D->>R: "Ghi chữ ký, chứng chỉ, thời điểm"
    R-->>D: "Bằng chứng bao hàm (mục nhật ký)"
    V->>R: "Tra cứu mục, kiểm tra bằng chứng bao hàm"
    V->>V: "Xác minh chứng chỉ, danh tính, chính sách; cho phép/chặn"

Điểm thiết kế quan trọng nhất ở giai đoạn ký là hủy khóa tạm thời ngay lập tức. Khi ký xong, khóa riêng bị loại khỏi bộ nhớ, nên về sau không còn đối tượng để chiếm đoạt, và niềm tin hội tụ về "một danh tính đã hợp lệ trong một khoảnh khắc ngắn". Ở giai đoạn ghi nhật ký, thời điểm ký được lưu trong nhật ký, chứng minh "nó đã hợp lệ tại thời điểm đó" dù sau này chứng chỉ hết hạn. Ở giai đoạn xác minh, cần kiểm tra tất cả các điểm sau: (1) chữ ký có khớp với digest của artifact không, (2) chứng chỉ có được cấp dưới gốc tin cậy không, (3) danh tính và nhà phát hành có khớp chính sách không, và (4) sự kiện ký có tồn tại trong Rekor không. Nếu thiếu một trong bốn, trạng thái trở thành "có chữ ký nhưng không thể tin cậy", nên việc thiết kế chính sách xác minh một cách tường minh là cốt lõi.

4. So sánh với ký mã truyền thống và các hệ thống tương tự

Giá trị của Sigstore trở nên rõ ràng khi chỉ ra lý do khác biệt so với ký mã PKI truyền thống. Phương thức truyền thống có thể cho độ tin cậy cao vào khóa lâu dài, nhưng điểm yếu là gánh nặng lưu trữ, thu hồi và thiệt hại rộng khi rò rỉ. Sigstore loại bỏ gánh nặng đó nhưng đổi lại chấp nhận các phụ thuộc bên ngoài là nhà cung cấp danh tính, nhật ký và gốc tin cậy. Ngoài ra, tương tự như certificate transparency (minh bạch chứng chỉ) giám sát việc cấp sai chứng chỉ TLS qua nhật ký, Rekor giám sát "sự kiện ký" qua nhật ký, nên chúng là anh em họ về mặt khái niệm.

Khía cạnh Ký mã PKI truyền thống Sigstore (keyless)
Lưu trữ khóa Cần lưu khóa riêng lâu dài Khóa tạm thời, hủy sau khi ký
Cơ sở tin cậy CA cấp phát + khóa lưu trữ Danh tính OIDC + gốc TUF + nhật ký
Ảnh hưởng khi rò rỉ Đe dọa rộng tới chữ ký quá khứ/tương lai Không có khóa lưu trữ, ảnh hưởng cục bộ
Kiểm toán Cần hệ thống riêng Nhật ký minh bạch công khai tích hợp sẵn
Gánh nặng chính Vận hành, thu hồi khóa Phụ thuộc tính sẵn sàng của nhà cung cấp danh tính / nhật ký

Một ví dụ cụ thể, nếu ký keyless một container image bằng Cosign trong GitHub Actions, danh tính repository và workflow được khắc vào chứng chỉ và chữ ký được ghi vào Rekor. Policy controller của cụm triển khai có thể cưỡng chế chỉ chấp nhận các image thỏa mãn "danh tính workflow của repository được phê duyệt + tồn tại trong nhật ký". Một ví dụ khác, nếu ký SBOM hay SLSA provenance như một attestation và đính vào image, thì việc giả mạo chính siêu dữ liệu chuỗi cung ứng cũng được xác minh cùng lúc. Như vậy, Sigstore không phải là một công cụ đơn lẻ mà định vị như tầng ký và danh tính của ngăn xếp bảo mật chuỗi cung ứng.

5. Chuyên sâu — xu hướng mới nhất và sự áp dụng trong hệ sinh thái

Sigstore tuyên bố phát hành chính thức (GA) tại SigstoreCon vào tháng 10 năm 2022 và kể từ đó vận hành dưới quản trị trung lập của OpenSSF (thuộc Linux Foundation). Tại thời điểm GA, nó cung cấp dịch vụ ký công khai miễn phí dựa trên các bản phát hành v1.0 của Cosign, Fulcio và Rekor, với mục tiêu sẵn sàng khoảng 99,5%. Theo các tài liệu công khai, hàng chục triệu chữ ký đã được ghi vào nhật ký và hàng chục nghìn dự án đã sử dụng quanh thời điểm GA, cho thấy sự áp dụng nhanh chóng; vì con số cụ thể khác nhau theo thời điểm công bố, nên trích dẫn như một xu hướng sẽ an toàn hơn là khẳng định.

Sự áp dụng trong hệ sinh thái cũng mở rộng. npm bắt đầu hỗ trợ ký cùng với GA, Homebrew, PyPI và Maven cũng giới thiệu hoặc theo đuổi tích hợp Sigstore, và các dự án lớn như Kubernetes, Python đã dùng nó để ký bản phát hành. Về phía máy khách, nó tiến hóa từ việc chỉ định URL theo từng cờ sang quản lý cấu hình ký bằng cấu hình, và một định dạng gói (bundle) đóng gói kết quả ký thành một thể được giới thiệu, nên các định dạng và công cụ vẫn tiếp tục phát triển. Dẫu vậy, hành vi chi tiết của bản phát hành và phiên bản thay đổi theo thời điểm, nên khi áp dụng thực tế cần xác nhận theo ghi chú phát hành của phiên bản đó. Khi các công cụ xung quanh như Gitsign để ký git commit và policy-controller để cưỡng chế chính sách lúc triển khai cũng cùng phát triển, Sigstore đang mở rộng vị thế như một trục chuẩn cho việc ký và xác minh trên toàn bộ CI/CD.

6. Các điểm cần cân nhắc và hàm ý

Dưới góc nhìn Kỹ sư chuyên nghiệp, việc áp dụng Sigstore phải cân nhắc cân bằng những điểm sau.

Thứ nhất, kiểm soát đối với sự chuyển dịch niềm tin (trust shift). Đổi lại việc loại bỏ khóa lâu dài, nhà cung cấp danh tính OIDC và gốc tin cậy TUF trở thành điểm kiểm soát cốt lõi mới. Cấu hình sai của nhà cung cấp danh tính hoặc việc đánh cắp token có thể trực tiếp trở thành chiếm đoạt quyền ký, nên phải thiết kế đồng thời việc cấp danh tính, phạm vi quyền và tính ngắn hạn.

Thứ hai, tính tường minh của chính sách xác minh. Cho qua chỉ vì "có một chữ ký" là vô nghĩa. Danh tính, nhà phát hành, repository và workflow được phép, sự hiện diện trong nhật ký, và khớp digest đều phải được quy định chặt thành chính sách, và phải đặt một cổng chặn triển khai khi xác minh thất bại vào trong pipeline.

Thứ ba, sự đánh đổi giữa tính sẵn sàng và chủ quyền. Phụ thuộc vào dịch vụ công khai thì giảm gánh nặng vận hành nhưng phơi mình trước thay đổi về tính sẵn sàng và chính sách bên ngoài. Trong môi trường mạng đóng, bị quản chế, có lựa chọn tự vận hành Fulcio và Rekor, nhưng phải có năng lực vận hành phân phối gốc tin cậy (TUF) và giám sát nhật ký.

Thứ tư, triển khai theo giai đoạn và công nghệ liên kết. Thay vì cưỡng chế keyless toàn diện ngay từ đầu, trước tiên áp dụng ký và xác minh cho các artifact cốt lõi rồi mở rộng dần. Ngoài ra, vì Sigstore chỉ là tầng ký và danh tính, nó phải kết hợp với SBOM (thành phần), SLSA (bằng chứng quá trình tạo lập) và bảo mật runtime thì niềm tin trên toàn bộ chuỗi cung ứng mới hoàn chỉnh.

Thứ năm, quyền riêng tư và tính lâu bền của nhật ký. Vì danh tính ký (như email) được lưu trong nhật ký công khai và trở nên truy vết được, cần một thiết kế danh tính giảm phơi lộ, chẳng hạn dùng tài khoản tổ chức, danh tính workflow.

Tài liệu tham khảo

Tóm tắt một câu: Sigstore ký các artifact bằng chứng chỉ ngắn hạn dựa trên danh tính OIDC (Fulcio) mà không cần khóa riêng lâu dài và ghi sự kiện vào nhật ký minh bạch công khai (Rekor), giảm rủi ro rò rỉ khóa đồng thời cho phép bất kỳ ai xác minh và kiểm toán nguồn gốc cùng thời điểm của một chữ ký — một hệ thống ký chuỗi cung ứng phần mềm.