AWS Signer

解決する課題

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

AWS Signer は、コードやアーティファクトへデジタル署名を付与し、その署名を検証するためのマネージドサービスです。署名鍵とコード署名証明書はサービス側で管理され、利用者は鍵を直接扱わずに「誰が署名したか」「署名後に改ざんされていないか」を検証できます。

主要概念と用語

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

仕様・制限・クォータ

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

内部の仕組み

横にスクロール

AWS Signer の中核は「署名プロファイル」とサービス管理の署名材料です。署名プロファイルを作成すると、対応プラットフォームに応じてSignerが証明書と秘密鍵を管理します。秘密鍵は利用者に公開されず、署名操作のときだけサービス内部で使われます。IoT向けなど一部の流れではACMへ取り込んだ証明書を指定します。

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

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

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

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

運用・監視

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

コスト

• Lambda、ECR、EKS、IoTなど対応する統合ワークフローでAWS Signerを使う場合、Signer自体の追加料金はない
• 署名元・出力先のS3、ECR、CI/CD実行、データ転送など関連サービスには通常の料金がかかる
• Signerの鍵保護のために利用者がAWS Private CA料金を支払う、という一般的な前提はない。別用途でPrivate CAを使う場合だけ個別に試算する

セキュリティ

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

関連サービス・比較

AWS Signer はコード署名のワークフローと署名材料を管理します。汎用的な暗号鍵管理を担う 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