AWS Signer

解決する課題

• 配布するコードやコンテナイメージが改ざんされていないことを、実行前に検証したい
• 署名に使う秘密鍵を自前で安全に保管・管理する運用負荷から解放されたい
• どのアーティファクトが信頼できる出所から来たかを、機械的に判定したい
• 署名の有効期間・失効・監査を組織のポリシーとして統制したい

AWS Signer は、コードやアーティファクトへデジタル署名を付与し、その署名を検証するためのマネージドサービスです。署名に使う秘密鍵はサービス内で AWS Private CA によって保護され、利用者は鍵を直接扱わずに「誰が署名したか」「署名後に改ざんされていないか」を保証できます。

主要概念と用語

• デジタル署名: アーティファクトのハッシュを秘密鍵で暗号化した値。検証側は公開鍵で復号し、改ざんがないこと（完全性）と発行者（真正性）を確認する
• 署名プロファイル: 署名の設定をまとめたテンプレート。署名対象のプラットフォーム種別や署名の有効期間、使用する証明書などを定義し、これを使って署名ジョブを実行する
• 署名ジョブ: 署名プロファイルに基づいて特定のアーティファクトに署名する1回の処理。結果として署名済みオブジェクトが生成される
• プラットフォーム: 署名対象の種類を表す識別子。AWS Lambda、コンテナイメージ（OCI/Notation）、AWS IoT 向けなどがあり、署名形式が異なる
• 署名材料（signing material）: 署名に用いる証明書と秘密鍵。AWS Private CA で発行・管理され、利用者には公開されない
• 検証（verify）: 配布先や実行基盤が公開鍵を使って署名の正当性を確認する処理。Lambda はデプロイ時に、コンテナは実行時などに検証する
• 失効（revocation）: 漏えいや不正が判明した署名プロファイルや署名ジョブを無効化し、以後その署名を信頼させない操作
• コード署名設定（Code Signing Configuration）: Lambda 側の設定で、信頼する署名プロファイルと、未署名・無効署名コードを「拒否」するか「警告」するかのポリシーを定める

仕様・制限・クォータ

• 対応プラットフォームが定義済み: 署名できる対象は Signer がサポートするプラットフォーム（Lambda、コンテナイメージ、IoT など）に限られる。任意のバイナリ形式を自由に署名する汎用ツールではない
• 鍵はサービス管理: 署名に使う秘密鍵はエクスポートできず、AWS Private CA 配下でマネージドに保護される
• リージョンスコープ: 署名プロファイルやジョブはリージョン単位で管理する。複数リージョンで使うなら各リージョンで構成する
• 署名の有効期間: 署名プロファイルには有効期間を設定でき、期間を過ぎた署名は検証時に無効と扱える
• Lambda 連携の制約: Lambda のコード署名は ZIP デプロイパッケージが対象で、署名済みアーティファクトは Amazon S3 を経由して扱う
• 署名プロファイル数や同時署名ジョブ数などにはアカウント・リージョンごとのクォータがあり、件数の上限は引き上げ申請で緩和できる場合がある

内部の仕組み

AWS Signer の中核は「署名プロファイル」と、その背後にある AWS Private CA による鍵保護です。署名プロファイルを作成すると、Signer は署名に使う証明書と秘密鍵を内部で用意します。秘密鍵は利用者に公開されず、署名操作のときだけサービス内部で使われます。

署名ジョブでは、対象アーティファクトのハッシュを計算し、そのハッシュを秘密鍵で署名します。生成された署名は、プラットフォームごとの形式（Lambda なら署名済み ZIP、コンテナなら Notation/OCI の署名アーティファクト）で出力されます。元データを丸ごと暗号化するのではなく、ハッシュへの署名を付与する点がポイントです。

検証側は、署名プロファイルに対応する公開鍵（証明書チェーン）を使って署名を確認します。Lambda の場合、関数に「コード署名設定」を関連付けておくと、デプロイ時に署名が信頼する署名プロファイルのものか、改ざんがないか、有効期間内かを自動でチェックします。検証に失敗したコードは、設定したポリシーに応じて拒否されます。

設計パターン / ベストプラクティス

• Lambda はコード署名設定を「拒否」で運用: 信頼する署名プロファイルを登録し、未署名・無効署名のデプロイをブロックするポリシーにして、検証されたコードだけを本番に流す
• CI/CD パイプラインに署名を組み込む: ビルド成果物を署名ジョブに通し、署名済みアーティファクトだけをデプロイ段階へ渡す。手動署名に頼らず自動化する
• 署名プロファイルを用途で分ける: 本番・検証環境やチームごとにプロファイルを分離し、信頼範囲と失効の影響範囲を限定する
• 有効期間を設定する: 署名に有効期間を持たせ、古い成果物が無期限に信頼され続けないようにする
• コンテナは Notation で検証: OCI イメージは Notation 形式の署名を付け、Amazon EKS などのアドミッションコントロールで実行時に検証する
• 失効手順を用意しておく: 鍵漏えいや不正ビルドが判明したときに、署名プロファイルや署名ジョブを失効させる運用フローを事前に整える

運用・監視

• CloudTrail で署名操作を追跡: 署名プロファイルの作成・署名ジョブの実行・失効などの API 操作は CloudTrail に記録され、誰がいつ署名したかを監査できる
• 署名ジョブの成否を監視: 署名ジョブが失敗した場合に CI/CD を止められるよう、ジョブ結果をパイプラインで判定する
• 有効期間切れの検知: 署名の有効期間が切れると検証で弾かれるため、再署名の必要性を運用で把握する
• 失効の伝播を確認: 失効した署名プロファイルが、検証を行う各基盤（Lambda のコード署名設定など）で確実に信頼対象から外れているかを確認する

コスト

• 署名ジョブ単位の課金: 実行した署名処理の量に応じた料金が中心になる
• AWS Private CA の費用: Signer の鍵保護に AWS Private CA を伴う構成では、CA の月額や証明書発行に関する料金が別途かかる場合がある
• 保管・転送の費用: 署名済みアーティファクトを置く S3 や ECR のストレージ・データ転送料が周辺コストとして発生する
• 変動しやすい単価は公式の料金ページで最新の値を確認すること。署名そのものより、付随するストレージや CI/CD 実行のコストが全体に占める割合が大きいことが多い

セキュリティ

• 秘密鍵を露出させない: 署名鍵は AWS Private CA 配下でマネージドに保護され、利用者がファイルとして扱うことはない。鍵漏えいの主因である「鍵の手元保管」を排除できる
• IAM で署名権限を最小化: 署名プロファイルの作成・署名・失効の各操作を IAM ポリシーで分離し、署名できる主体を限定する
• 検証を強制する: Lambda のコード署名設定を「拒否」ポリシーにし、検証を任意ではなく必須にすることでサプライチェーン上の改ざんを止める
• CloudTrail で証跡を残す: すべての署名操作を記録し、不正な署名や想定外の実行者を追跡できるようにする

関連サービス・比較

AWS Signer はコードへの署名を担い、署名鍵の保護に AWS Private CA を利用します。汎用的な暗号鍵管理を担う AWS KMS と役割が異なるため、両者を整理します。

ハンズオン / CLI例

# 署名プロファイルを作成（Lambda 向けプラットフォームの例）
aws signer put-signing-profile \
  --profile-name MyLambdaProfile \
  --platform-id AWSLambda-SHA384-ECDSA \
  --region ap-northeast-1

# 署名プロファイルの一覧を確認
aws signer list-signing-profiles --region ap-northeast-1

# S3 上の Lambda パッケージに署名ジョブを実行
#  source は署名対象、destination は署名済み成果物の出力先
aws signer start-signing-job \
  --source 's3={bucketName=my-src-bucket,key=function.zip,version=VERSION_ID}' \
  --destination 's3={bucketName=my-signed-bucket,prefix=signed/}' \
  --profile-name MyLambdaProfile \
  --region ap-northeast-1

# 署名ジョブの状態を確認
aws signer describe-signing-job \
  --job-id <署名ジョブのID> \
  --region ap-northeast-1