ソフトウェアサプライチェーン攻撃の増加に伴い、アーティファクト(コンテナイメージ、バイナリファイル等)の完全性と信頼性を保証する仕組みが重要になっています。
デジタル署名と検証により、配布されるアーティファクトが改ざんされていないこと、信頼できるソースから提供されていることを確実に検証できます。
はじめに
アーティファクト署名とは、ソフトウェアのバイナリファイルやコンテナイメージなどに対してデジタル署名を付与し、その完全性と出所を証明する技術です。
近年のサプライチェーン攻撃では、正規のソフトウェア配布チャネルを悪用してマルウェアが混入されるケースが増加しており、SolarWinds 事件や Log4j 脆弱性などが記憶に新しいところです。
このような脅威に対抗するため、NIST SSDF(Secure Software Development Framework)や SLSA(Supply-chain Levels for Software Artifacts)などのフレームワークでも、アーティファクトの署名・検証が重要な要素として位置づけられています。
アーティファクト署名の基本概念
デジタル署名の仕組み
デジタル署名は公開鍵暗号技術を利用して、以下の 3 つの要素を保証します:
- 完全性(Integrity): ファイルが改ざんされていないことの証明
- 認証(Authentication): 署名者の身元確認
- 否認防止(Non-repudiation): 署名者が署名したことの証明
署名方式の種類
1. 従来の PKI 方式
- X.509 証明書: CA(Certificate Authority)による証明書チェーン
- PGP/GPG: Web of Trust モデル
- Code Signing: Windows Authenticode、Apple Code Signing
2. 新世代の署名技術
- Sigstore: OpenSSF が推進するオープンソース署名インフラ
- Keyless 署名: 短期間証明書による証明書管理の簡素化
- Transparency Log: 署名の透明性と検証可能性
コンテナベースプラットフォームでの署名・検証
Cosign によるコンテナイメージ署名
Cosign は、CNCF 傘下の Sigstore プロジェクトが提供するコンテナイメージ署名ツールです。
インストールと初期設定
# Cosignのインストール
brew install cosign
# キーペア生成(従来方式)
cosign generate-key-pair
# Keyless署名の設定(推奨)
export COSIGN_EXPERIMENTAL=1
イメージの署名
# 従来のキーペア方式
cosign sign --key cosign.key myregistry/myapp:v1.0.0
# Keyless署名(OIDC認証)
cosign sign myregistry/myapp:v1.0.0
イメージの検証
# 公開鍵による検証
cosign verify --key cosign.pub myregistry/myapp:v1.0.0
# Keyless検証
cosign verify myregistry/myapp:v1.0.0 \
--certificate-identity-regexp=".*@mycompany\.com" \
--certificate-oidc-issuer="https://github.com/login/oauth"
CI/CD パイプラインでの自動署名
GitHub Actions での Cosign 署名例:
name: Build and Sign
on:
push:
tags: ["v*"]
jobs:
build-and-sign:
runs-on: ubuntu-latest
permissions:
contents: read
id-token: write
packages: write
steps:
- uses: actions/checkout@v4
- name: Install Cosign
uses: sigstore/cosign-installer@v3
- name: Build image
run: |
docker build -t ghcr.io/${{ github.repository }}:${{ github.ref_name }} .
- name: Login to registry
run: |
echo "${{ secrets.GITHUB_TOKEN }}" | docker login ghcr.io -u ${{ github.actor }} --password-stdin
- name: Push image
run: |
docker push ghcr.io/${{ github.repository }}:${{ github.ref_name }}
- name: Sign image
env:
COSIGN_EXPERIMENTAL: 1
run: |
cosign sign ghcr.io/${{ github.repository }}:${{ github.ref_name }}
Kubernetes 環境での署名検証
Kyverno による署名検証
Kyverno を使用して、署名されていないコンテナイメージのデプロイを防ぐポリシーを定義する例:
apiVersion: kyverno.io/v1
kind: ClusterPolicy
metadata:
name: verify-image-signatures
spec:
validationFailureAction: enforce
rules:
- name: verify-signature
match:
resources:
kinds:
- Pod
verifyImages:
- image: "ghcr.io/myorg/*"
key: |
-----BEGIN PUBLIC KEY-----
MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQ...
-----END PUBLIC KEY-----
Kyverno は Kubernetes ネイティブなポリシーエンジンで、シンプルな YAML 記述で署名検証を実現できます。
OPA Gatekeeper との比較
特徴 | OPA (Gatekeeper) | Kyverno |
---|---|---|
ポリシー記述言語 | Rego | YAML |
学習コスト | 高め | 低め |
Kubernetes ネイティブ | 部分的 | 完全 |
柔軟性 | 高い(Kubernetes 外のリソースも管理可能) | Kubernetes リソースに特化 |
署名検証のサポート | サポートあり | サポートあり |
アーティファクト署名と追加情報の検証
アーティファクトの署名に加えて、追加情報(メタデータや証明書など)を含め、それを検証する仕組みが注目されています。これにより、単なる完全性の保証だけでなく、アーティファクトの生成プロセスや内容の信頼性を包括的に検証できます。
Attestation(アテステーション)
アテステーションは、アーティファクトに関する追加情報(例: ビルド環境、依存関係、SBOM など)を署名付きで提供する仕組みです。これにより、アーティファクトがどのように生成されたかを検証できます。
Cosign を使用したアテステーションの生成と検証
# SBOM(Software Bill of Materials)を生成
syft packages docker:myapp:latest -o spdx-json > sbom.spdx.json
# SBOM を署名付きでアテステーションとして付与
cosign attest --predicate sbom.spdx.json --type spdx myapp:latest
# アテステーションの検証
cosign verify-attestation myapp:latest \
--type spdx \
--certificate-identity-regexp=".*@mycompany\.com" \
--certificate-oidc-issuer="https://github.com/login/oauth"
Transparency Log(透明性ログ)
透明性ログは、署名やアテステーションが改ざんされていないことを保証するための仕組みです。Sigstore の Rekor などがこれを提供します。
Rekor を使用した署名の記録と検証
# Rekor に署名を記録
cosign sign --key cosign.key --rekor-url https://rekor.sigstore.dev myapp:latest
# Rekor を使用した検証
cosign verify --rekor-url https://rekor.sigstore.dev myapp:latest
透明性ログを利用することで、署名が改ざんされていないことを第三者的に保証できます。
SBOM(Software Bill of Materials)との統合
SBOM は、アーティファクトに含まれるすべての依存関係をリスト化したものです。これを署名付きで提供することで、アーティファクトの内容を詳細に検証できます。
SBOM の生成と署名
# SBOM の生成
syft packages docker:myapp:latest -o spdx-json > sbom.spdx.json
# SBOM の署名
cosign sign-blob --key cosign.key sbom.spdx.json
# SBOM の検証
cosign verify-blob --key cosign.pub --signature sbom.spdx.json.sig sbom.spdx.json
In-Toto フレームワーク
In-Toto は、ソフトウェアサプライチェーン全体を通じて、アーティファクトの生成プロセスを検証するためのフレームワークです。
In-Toto の使用例
# レイアウトの定義
in-toto-run --step-name build --key build.key --products myapp:latest -- docker build -t myapp:latest .
# 検証
in-toto-verify --layout root.layout --layout-key root.pub
In-Toto を使用することで、アーティファクトがどのように生成され、どのステップを経てきたかを詳細に検証できます。
ツールの特徴と比較
以下は、アーティファクト署名と追加情報の検証に使用される主要なツールの特徴を比較した表です。
ツール名 | 主な用途 | 特徴 | メリット | デメリット |
---|---|---|---|---|
Cosign | コンテナイメージの署名と検証 | Sigstore プロジェクトの一部。Keyless 署名をサポート。 | 簡単な操作性。Kubernetes との統合が容易。 | Rekor など他の Sigstore ツールと連携が必要 |
Rekor | 透明性ログの記録と検証 | 署名やアテステーションを透明性ログに記録。 | 改ざん防止の保証。第三者検証が可能。 | Rekor サーバーの運用が必要。 |
Syft | SBOM(ソフトウェア部品表)の生成 | コンテナイメージやファイルシステムから SBOM を生成。 | SBOM 生成が簡単。多くのフォーマットをサポート。 | 検証機能は別ツールが必要。 |
In-Toto | サプライチェーン全体の検証 | 各ステップのメタデータを署名付きで記録し、プロセス全体を検証可能。 | サプライチェーン全体の透明性を確保。 | 導入と運用に手間がかかる。 |
Kyverno | Kubernetes ネイティブなポリシー制御 | YAML でポリシーを記述可能。署名検証や RBAC 強化に利用。 | 学習コストが低い。Kubernetes に特化。 | Kubernetes 以外の環境では利用不可。 |
OPA | ポリシー制御と署名検証 | Rego 言語を使用して柔軟なポリシーを記述可能。 | Kubernetes 以外のリソースも管理可能。 | Rego の学習コストが高い。 |
これらの仕組みを組み合わせることで、アーティファクトの署名に加え、生成プロセスや内容の信頼性を包括的に保証することが可能です。
まとめ
アーティファクトの署名・検証は、現代のサプライチェーンセキュリティにおいて不可欠な技術です。
主要なポイント
- Sigstore/Cosign: コンテナ環境での標準的な署名ソリューション
- Keyless 署名: 運用負荷を軽減する新しいアプローチ
- CI/CD 統合: 自動化されたパイプラインでの署名・検証
- ポリシー制御: Kubernetes 環境での強制的な検証
導入戦略
- 段階的展開: 警告モードから強制モードへの移行
- ツール選択: 環境に適した署名ツールの選定
- 教育・訓練: 開発チームへの署名技術の浸透
アーティファクト署名・検証の適切な実装により、サプライチェーン攻撃のリスクを大幅に軽減し、システム全体の信頼性を向上させることができます。
参考リンク
- Cosign: CNCF 傘下の Sigstore プロジェクトが提供するコンテナイメージ署名ツール。
- Sigstore: オープンソース署名インフラ。
- Rekor: 透明性ログを提供する Sigstore のコンポーネント。
- Syft: SBOM(Software Bill of Materials)生成ツール。
- In-Toto: サプライチェーン全体のプロセス検証を行うフレームワーク。
- Kyverno: Kubernetes ネイティブなポリシーエンジン。
- OPA(Open Policy Agent): Kubernetes やクラウド全体のポリシー管理を行うツール。