AWS Signer

目次

Security, Identity & Compliance・コード署名とサプライチェーン整合性

AWS Signer は、Lambda 関数・コンテナイメージ・IoT ファームウェアのコード署名をマネージドで行うサービスです。デプロイするコードの整合性を 暗号学的に保証し、改ざんされていないことを検証可能にします。署名鍵は KMS で管理され、署名済みコードのみ実行を許可するポリシーをアカウント全体に強制でき、ソフトウェアサプライチェーン攻撃を防止します。このページでは、Signer の本質・署名プロファイル・ユースケース・統合方法を体系的に整理します。


このページの目的

このページでは以下を対象としています。

  • セキュリティアーキテクト: コード整合性・署名ポリシーの設計
  • CI/CD エンジニア: GitLab CI / GitHub Actions / CodePipeline への署名統合
  • 開発者向け: Lambda・コンテナイメージの署名実装
  • 意思決定者向け: Signer vs Sigstore vs GPG / Microsoft SignTool の選択判断

2025-2026 年の Signer エコシステム

  • Sigstore 統合深化: CNCF Sigstore(Cosign)との相互運用性向上
  • SBOM(Software Bill of Materials)署名:CycloneDX / SPDX フォーマット対応
  • Notation コンテナ署名: CNCF Notation(OCI Artifact Signing)完全対応
  • ポリシーエンジン拡張:カスタム署名検証ルール、複数署名者の並行署名
  • Post-Quantum Cryptography 準備:量子耐性アルゴリズムへの段階的対応
  • GitHub Actions / GitLab CI 統合:ワークフロー内署名の自動化

定義

AWS 公式による定義:

“AWS Signer is a fully managed code signing service that helps you sign software artifacts to ensure their integrity and authorship.”

開発者が長期間秘密鍵を管理せずに、暗号的に安全な署名をコード署名に統合。


本質・定義 {#本質定義}

初心者向け説明

Signer は「コードを署名する公証人」です。デプロイするコード(Lambda・コンテナ・ファームウェア)に対して、秘密鍵で署名を付与。実行時、AWS が署名を検証し、「このコードは改ざんされていない、信頼できる開発者から来ている」ことを保証します。

Service の役割

Signer は以下の署名機能を提供:

機能 説明
Signing Profile 署名プロファイル(署名者の身元・証明書)
Signing Job 実際のコード署名実行
Code Integrity Verification デプロイ時の署名検証
Policy Enforcement 署名済みコードのみデプロイを許可
Audit Trail CloudTrail との統合、署名操作ログ

Signer が解決する課題 {#課題}

1. サプライチェーン攻撃への対策

課題:CI/CD パイプラインへの不正介入でコードが改ざんされても、組織は改ざんに気付かない

Signer の解決:署名済みコードの検証を強制、改ざんされたコードの実行をブロック

2. 秘密鍵管理の複雑性

課題:自前の OpenSSL / GPG では秘密鍵の安全な保管・ローテーション・監査が困難

Signer の解決:KMS で鍵を管理、鍵の回転・アクセス監査を自動化

3. Lambda の改ざん検出

課題:誤ったコードがデプロイされても検出が遅い、本番で実行される

Signer の解決:「署名済み ZIP のみデプロイ可能」ポリシーを Lambda に設定、未署名コードをブロック

4. コンテナイメージの整合性検証

課題:ECR に push されたイメージが信頼できるソースかどうか不明

Signer の解決:Notation / Cosign 統合で、署名済みイメージのみ EKS にデプロイ可能


主な特徴 {#特徴}

1. 複数署名対象のサポート

Lambda 関数
  └─ ZIP パッケージに署名
      ├─ CodePipeline / CodeBuild で自動署名
      └─ Lambda Code Signing Config で署名検証

コンテナイメージ
  └─ OCI イメージ(ECR)に署名
      ├─ Notation(CNCF 標準)
      ├─ Cosign(Sigstore)
      └─ EKS Admission Controller で検証

IoT デバイス
  └─ OTA ファームウェアパッケージに署名
      ├─ IoT Jobs で署名検証
      └─ デバイスが署名を確認後、インストール

2. 署名プロファイルの柔軟な管理

署名プロファイル
  ├─ 署名者の身元(Developer / CI/CD Bot)
  ├─ 有効期限(1年~無期限)
  ├─ 署名タイプ(SHA256withRSA など)
  ├─ Alias(参照用)
  └─ KMS キーへの参照

3. KMS による署名鍵保護

  • 秘密鍵が KMS 内に保管、外部に出ない
  • CloudTrail で署名操作を監査
  • 鍵のローテーション・無効化を自動化

4. ポリシーエンジンによる強制実行制御

# Lambda Code Signing Config
code_signing_config = {
    'AllowedPublishers': {
        'SigningProfileVersionArns': [
            'arn:aws:signer:region:account:signing-profile/prod-profile:version/1'
        ]
    },
    'CodeSigningPolicies': {
        'UntrustedArtifactOnDeployment': 'Enforce'  # 署名なきデプロイをブロック
    }
}

アーキテクチャ {#アーキテクチャ}

【図1】コード署名フロー

開発環境
  ├─ コードコミット(Git)
  ├─ CodeBuild でビルド
  └─ ZIP パッケージ生成

CodePipeline
  ├─ Signer に署名リクエスト
  │   ├─ KMS でコード ハッシュを署名
  │   └─ 署名済みメタデータ返却
  │
  └─ 署名済み ZIP + メタデータ

Lambda / ECR
  ├─ Code Signing Config で署名検証
  │   ├─ Signer から公開鍵を取得
  │   └─ 署名が正当か確認
  │
  └─ 署名済みコードのみデプロイ

実行時
  └─ 正当なコードが実行開始

【図2】署名検証パイプライン

graph TB
    Code["Code/Image"]
    Hash["Hash (SHA-256)"]
    Sign["Sign (KMS RSA)"]
    Sig["Signature"]
    Deploy["Deploy to Lambda/EKS"]
    Verify["Verify (Public Key)"]
    Allow["Allow / Block"]

    Code -->|Compute| Hash
    Hash -->|Send to Signer| Sign
    Sign -->|Generate| Sig
    Sig -->|Attach| Deploy
    Deploy -->|Check| Verify
    Verify -->|Valid?| Allow

署名プロファイル・署名ジョブ {#署名プロファイル}

署名プロファイルの作成

import boto3

signer = boto3.client('signer', region_name='us-east-1')

# 署名プロファイル作成
response = signer.put_signing_profile(
    ProfileName='prod-signing-profile',
    ProfileVersion='v1',
    SigningMaterial={
        'CertificateArn': 'arn:aws:acm:region:account:certificate/xxxxx'
    },
    SignatureAlgorithmFamily='RSA_SHA256',  # RSA_SHA256 / ECDSA_SHA256
    Tags={
        'Environment': 'production',
        'Team': 'security'
    }
)

profile_arn = response['Arn']
print(f"Signing Profile created: {profile_arn}")

署名プロファイルの種類

Signer マネージドプロファイル
  ├─ プラットフォーム署名
  │   ├─ Lambda
  │   ├─ IoT
  │   └─ Generic Binary
  │
  └─ 有効期限ベース
      ├─ 1 年(推奨)
      ├─ 3 年
      └─ 無期限(レガシー)

署名ジョブの実行

# 署名ジョブ投入
response = signer.start_signing_job(
    source={
        's3': {
            'bucket': 'my-build-artifacts',
            'key': 'lambda-function.zip',
            'version': 'v123'
        }
    },
    destination={
        's3': {
            'bucket': 'my-signed-artifacts',
            'prefix': 'lambda-signed/'
        }
    },
    profileName='prod-signing-profile',
    profileOwner='123456789012',  # AWS Account ID
    clientRequestToken='unique-token-12345'
)

job_id = response['jobId']
print(f"Signing Job: {job_id}")

# ジョブ進行状況を確認
job_status = signer.describe_signing_job(jobId=job_id)
print(f"Status: {job_status['signingJob']['status']}")

Lambda コード署名 {#lambda署名}

Lambda Code Signing Config の設定

import boto3

lambda_client = boto3.client('lambda', region_name='us-east-1')
signer = boto3.client('signer', region_name='us-east-1')

# 1. Code Signing Config 作成
csc_response = lambda_client.create_code_signing_config(
    Description='Production Lambda signing policy',
    AllowedPublishers={
        'SigningProfileVersionArns': [
            'arn:aws:signer:us-east-1:123456789012:signing-profile/prod-profile:version/v1'
        ]
    },
    CodeSigningPolicies={
        'UntrustedArtifactOnDeployment': 'Enforce'  # 署名なずデプロイをブロック
    }
)

config_arn = csc_response['CodeSigningConfig']['CodeSigningConfigArn']
print(f"Code Signing Config: {config_arn}")

# 2. Lambda 関数に Code Signing Config をアタッチ
lambda_client.update_function_code_signing_config(
    CodeSigningConfigArn=config_arn,
    FunctionName='my-production-function'
)

# 3. デプロイ時に署名済み ZIP を指定
lambda_client.update_function_code(
    FunctionName='my-production-function',
    S3Bucket='my-signed-artifacts',
    S3Key='lambda-signed/lambda-function.zip'
    # AWS は自動的に署名を検証
)

Lambda 署名デプロイフロー

# 【ステップ 1】コードビルド
cd my-lambda-project
npm install && npm run build
zip -r lambda-function.zip dist/

# 【ステップ 2】Signer に署名リクエスト
aws signer start-signing-job \
  --source s3://my-build-artifacts/lambda-function.zip \
  --destination s3://my-signed-artifacts/ \
  --profile-name prod-signing-profile

# 【ステップ 3】署名済みコードを取得(~30 秒)
aws s3 cp s3://my-signed-artifacts/lambda-function.zip ./lambda-signed.zip

# 【ステップ 4】Lambda にデプロイ
aws lambda update-function-code \
  --function-name my-production-function \
  --zip-file fileb://lambda-signed.zip

# 署名が検証され、デプロイが成功(署名なければ失敗)

コンテナイメージ署名 {#コンテナ署名}

Notation によるコンテナ署名

# 【ステップ 1】コンテナイメージをビルド
docker build -t my-app:latest .
aws ecr get-login-password | docker login --username AWS --password-stdin 123456789012.dkr.ecr.us-east-1.amazonaws.com
docker tag my-app:latest 123456789012.dkr.ecr.us-east-1.amazonaws.com/my-app:latest
docker push 123456789012.dkr.ecr.us-east-1.amazonaws.com/my-app:latest

# 【ステップ 2】Signer でイメージに署名(Notation)
notation key generate --default "my-signing-key"

# AWS Signer と統合
aws signer put-signing-profile \
  --profile-name container-signing \
  --signing-material certificateArn=arn:aws:acm:...

# 【ステップ 3】コンテナイメージに署名
notation sign \
  --key "aws:signer:region:account:signing-profile/container-signing" \
  123456789012.dkr.ecr.us-east-1.amazonaws.com/my-app:latest

# 【ステップ 4】EKS Admission Controller で署名検証
# → 署名済みイメージのみをクラスタにデプロイ許可

kubectl apply -f deployment.yaml
# Signer 経由で署名確認済みなら Pod は起動

Cosign(Sigstore)との統合

# Cosign をインストール
curl https://github.com/sigstore/cosign/releases/download/v2.0.0/cosign-linux-amd64
chmod +x cosign-linux-amd64

# AWS KMS キーを使用して署名
export COSIGN_EXPERIMENTAL=1
export AWS_SIGNER_PROFILE_ARN="arn:aws:signer:us-east-1:123456789012:signing-profile/my-profile"

# イメージに署名
cosign sign --key awskms://arn:aws:kms:us-east-1:123456789012:key/xxxxx \
  123456789012.dkr.ecr.us-east-1.amazonaws.com/my-app:latest

# 署名を検証
cosign verify --key awskms://arn:aws:kms:us-east-1:123456789012:key/xxxxx \
  123456789012.dkr.ecr.us-east-1.amazonaws.com/my-app:latest

IoT ファームウェア署名 {#iot署名}

IoT Device Defender 統合

import boto3
import json

signer = boto3.client('signer', region_name='us-east-1')
iot = boto3.client('iot', region_name='us-east-1')

# 【ステップ 1】ファームウェアイメージを署名
response = signer.start_signing_job(
    source={
        's3': {
            'bucket': 'firmware-builds',
            'key': 'device-firmware-v2.0.bin'
        }
    },
    destination={
        's3': {
            'bucket': 'signed-firmware',
            'prefix': 'releases/'
        }
    },
    profileName='firmware-signing-profile'
)

signed_firmware_s3 = response['jobId']  # 署名完了後 S3 に保存

# 【ステップ 2】IoT OTA Job を作成(署名済みファームウェア)
ota_response = iot.create_ota_update(
    otaUpdateId='firmware-update-v2-0',
    description='Firmware update for device fleet',
    targets=['arn:aws:iot:us-east-1:123456789012:thing/my-device'],
    files=[
        {
            'fileName': 'device-firmware-v2.0.bin',
            'fileVersion': '2.0',
            'fileLocation': {
                's3Location': {
                    'bucket': 'signed-firmware',
                    'key': f'releases/device-firmware-v2.0.bin'  # 署名済みファイル
                }
            },
            'codeSigning': {
                'awsSignerJobId': signed_firmware_s3
            }
        }
    ],
    roleArn='arn:aws:iam::123456789012:role/IoT-OTA-Role'
)

# 【ステップ 3】デバイスは署名を検証してからインストール
# デバイスファームウェア:
# 1. S3 からファイルをダウンロード
# 2. IoT OTA Job から署名情報を取得
# 3. Signer の公開鍵で署名検証
# 4. 署名有効 → インストール、署名無効 → ロールバック

SBOM・Notation 統合 {#sbom}

SBOM(Software Bill of Materials)署名

{
  "bomFormat": "CycloneDX",
  "version": "1",
  "components": [
    {
      "type": "library",
      "name": "aws-sdk",
      "version": "2.1.0"
    },
    {
      "type": "library",
      "name": "express",
      "version": "4.18.0"
    }
  ]
}

SBOM に署名・検証

# SBOM を JSON で出力
cyclonedx-npm > sbom.json

# AWS Signer でコード本体に署名(通常のコード署名)
# + SBOM をアーティファクト として ECR に保存

# Notation で SBOM に署名
notation sign \
  --key "aws:signer:region:account:signing-profile/sbom-signing" \
  --artifact-reference sbom.json \
  myregistry/myapp:latest

# 署名を検証(サプライチェーン整合性を確認)
notation verify \
  --key "aws:signer:region:account:signing-profile/sbom-signing" \
  myregistry/myapp:latest

主要ユースケース {#ユースケース}

ユースケース 1: 金融機関の Lambda 署名ポリシー

シナリオ:銀行が決済処理 Lambda に「署名済みコードのみ」を強制

流れ:
  1. 開発者が決済コードをコミット
  2. CodeBuild でテスト・ビルド
  3. Signer が自動的に署名
  4. Lambda Code Signing Config で署名検証
  5. 署名有効 → デプロイ成功、署名無効 → デプロイ失敗

セキュリティ効果: 不正なコード変更を本番デプロイ前に検出

ユースケース 2: Kubernetes クラスタでの署名済みイメージのみ実行

シナリオ:EKS クラスタが「署名済みコンテナのみ」を実行許可

流れ:
  1. CI/CD パイプラインでコンテナビルド
  2. Signer / Notation でイメージに署名
  3. ECR に push
  4. EKS Admission Controller で署名検証
  5. 署名済み → Pod 起動、署名なし → Pod 拒否

セキュリティ効果: コンテナレジストリへの不正アクセスでも不正イメージ実行不可

ユースケース 3: IoT フリート OTA 更新

シナリオ:IoT デバイス 10,000 台に新ファームウェアを安全に配布

流れ:
  1. ファームウェア開発・テスト
  2. Signer がバイナリに署名
  3. S3 にアップロード
  4. IoT OTA Job で段階的ロールアウト(10% → 50% → 100%)
  5. 各デバイスが署名検証後にインストール

セキュリティ効果: 改ざんされたファームウェアがデバイスに install される可能性 ゼロ

ユースケース 4: エンタープライズ多チーム署名管理

シナリオ:異なる署名プロファイルで複数チームが独立運用

チーム構成:
  ├─ Platform Team
  │   └─ Signing Profile: platform-signing-prod
  │       └─ 署名権限: Infrastructure Lambda のみ
  │
  ├─ Service A Team
  │   └─ Signing Profile: service-a-signing-prod
  │       └─ 署名権限: Service A Lambda のみ
  │
  └─ Service B Team
      └─ Signing Profile: service-b-signing-prod
          └─ 署名権限: Service B Lambda のみ

効果: 誰が何を署名したかを完全に監査可能

設定・操作の具体例 {#設定操作}

1. 署名プロファイル作成(CLI)

# 署名プロファイル作成
aws signer put-signing-profile \
  --profile-name prod-lambda-signing \
  --platform AWSLambda-SHA256-RSA \
  --signing-material certificateArn=arn:aws:acm:us-east-1:123456789012:certificate/xxxxx \
  --region us-east-1

# 署名プロファイル一覧
aws signer list-signing-profiles

# 署名プロファイル詳細
aws signer get-signing-profile \
  --profile-name prod-lambda-signing

2. Lambda 署名デプロイ(Terraform)

# 署名プロファイル定義
resource "aws_signer_signing_profile" "lambda" {
  name          = "prod-lambda-signing"
  platform_id   = "AWSLambda-SHA256-RSA"
  signature_algorithm = "SHA256RSA"
}

# Code Signing Config
resource "aws_lambda_code_signing_config" "prod" {
  allowed_publishers {
    signing_profile_version_arns = [
      "${aws_signer_signing_profile.lambda.arn}:version/1"
    ]
  }

  policies {
    untrusted_artifact_on_deployment = "Enforce"
  }
}

# Lambda 関数に Code Signing Config をアタッチ
resource "aws_lambda_function" "example" {
  filename            = "lambda-function.zip"
  function_name       = "my-prod-function"
  code_signing_config_arn = aws_lambda_code_signing_config.prod.arn
  # ...
}

3. 自動署名パイプライン(CodePipeline)

{
  "pipeline": {
    "name": "signed-lambda-pipeline",
    "stages": [
      {
        "name": "Source",
        "actions": [
          {
            "name": "CodeCommit",
            "actionTypeId": {
              "category": "Source",
              "owner": "AWS",
              "provider": "CodeCommit"
            }
          }
        ]
      },
      {
        "name": "Build",
        "actions": [
          {
            "name": "BuildLambda",
            "actionTypeId": {
              "category": "Build",
              "owner": "AWS",
              "provider": "CodeBuild"
            }
          }
        ]
      },
      {
        "name": "Sign",
        "actions": [
          {
            "name": "SignCode",
            "actionTypeId": {
              "category": "CodeSigning",
              "owner": "AWS",
              "provider": "CodeSigner"
            },
            "configuration": {
              "ProfileName": "prod-lambda-signing",
              "ProfileVersion": "v1",
              "SigningMaterial": "s3://build-artifacts/lambda-function.zip"
            }
          }
        ]
      },
      {
        "name": "Deploy",
        "actions": [
          {
            "name": "DeployToLambda",
            "actionTypeId": {
              "category": "Deploy",
              "owner": "AWS",
              "provider": "CloudFormation"
            }
          }
        ]
      }
    ]
  }
}

類似サービス比較 {#比較}

特性 AWS Signer Sigstore / Cosign GPG Microsoft SignTool
形態 AWS マネージド オープンソース + パブリック サービス ローカル / KMS 連携 Windows 専用
鍵管理 ◎ KMS 統合 △ OIDC + 短期証明書 △ 手動 / KMS △ コード署名証明書
Lambda 統合 ◎ Code Signing Config △ 別途検証スクリプト ✗ 非対応 ✗ 非対応
コンテナ署名 ◎ Notation / Cosign ◎ 完全対応 △ 限定的 △ 限定的
IoT 署名 ◎ OTA Jobs 統合 △ 可能だが手動 △ 限定的 ✗ 非対応
CloudTrail 監査 ◎ ネイティブ △ 別途ログ管理 △ CloudTrail に非対応 △ Windows Event Log
初期セットアップ 低(AWS マネージド) 中(Sigstore インスタンス管理) 低(GPG インストール) 低(証明書取得)
運用負荷
AWS 親和性 ◎ 最高 △ 互換性向上中 △ 標準的 ✗ 非互換
グローバル対応 ◎ マルチリージョン ◎ パブリック ◎ グローバル △ 地域制限あり

ベストプラクティス {#ベストプラクティス}

✅ 推奨される構成

✓ Lambda には必ず Code Signing Config を設定
✓ 署名プロファイルに短い有効期限(1年)
✓ CI/CD パイプラインで自動署名
✓ CloudTrail で署名操作の監査ログを永続保存
✓ IAM ロールで署名権限を最小化
✓ コンテナイメージは Notation で署名
✓ SBOM にも署名して、サプライチェーン全体を保護
✓ IoT デバイスは OTA Jobs で署名済みファームウェアのみ

❌ アンチパターン

× Code Signing Config なしで Lambda をデプロイ(改ざんリスク)
× 署名プロファイルの有効期限を無期限化(鍵漏洩リスク)
× 全員に Signer 署名権限を付与(権限昇格リスク)
× CloudTrail ログを削除(コンプライアンス違反)
× コンテナイメージを署名なしで本番デプロイ
× 異なるチームで同一署名プロファイルを共有(監査追跡困難)

トラブルシューティング {#トラブルシューティング}

症状 原因 解決策
Lambda Code Signing Config 失敗 Code Signing Config ARN の誤り Lambda コンソールで Code Signing Config を確認
署名済み ZIP のデプロイが拒否される 署名者が Code Signing Config に含まれていない allow_publishers の署名プロファイル ARN 確認
Notation でコンテナ署名失敗 Signer プロファイルの証明書ダウンロード失敗 notation cert list で証明書確認
署名ジョブが Pending のまま S3 ソースファイル存在しない 指定 S3 バケット・キーを確認
CloudTrail に署名操作ログがない CloudTrail が無効 CloudTrail を有効化・ S3 トレイル設定確認

近年の動向 {#近年の動向}

  1. SBOM 署名の標準化:CycloneDX / SPDX ネイティブサポート
  2. Notation v2 完全対応:OCI Artifact Signing の完全サポート
  3. ポリシーエンジン拡張:複数署名者による並行署名・複合認証
  4. Post-Quantum Cryptography 準備:量子耐性署名アルゴリズムへの段階的対応
  5. GitHub Actions / GitLab CI 深度統合:ワークフロー内署名の完全自動化

学習リソース {#資料}

公式ドキュメント

  1. AWS Signer Developer Guide
  2. AWS Signer API Reference
  3. Sigstore Documentation
  4. CNCF Notation
  5. Cosign Documentation

参考資料

  • AWS Lambda Code Signing
  • EKS Policy Controller ドキュメント
  • IoT OTA Jobs ドキュメント

実装例・チェックリスト {#実装チェック}

実装フェーズ

【Week 1】設計・計画
  Day 1-3: セキュリティ要件整理
  Day 4-7: 署名フロー設計(CI/CD 統合方式)

【Week 2-3】セットアップ・テスト
  Day 8-10: 署名プロファイル作成
  Day 11-14: Code Signing Config テスト
  Day 15-21: CI/CD パイプライン統合テスト

【Week 4】本番化
  Day 22-28: セキュリティ監査・ポリシー適用

実装チェックリスト

【設計フェーズ】
☐ サプライチェーン攻撃シナリオ分析
☐ 署名対象リソース(Lambda / Container / IoT)確定
☐ 署名ポリシー設計(Enforce / Warn)
☐ 多チーム署名管理戦略

【セットアップ】
☐ Signer 署名プロファイル作成
☐ Lambda Code Signing Config 設定
☐ IAM ロール・ポリシー設定
☐ CloudTrail ロギング有効化

【実装】
☐ CI/CD パイプラインへの Signer 統合
☐ CodeBuild / CodePipeline での自動署名
☐ コンテナイメージ署名(Notation / Cosign)
☐ IoT OTA Jobs での署名検証

【テスト】
☐ Lambda 署名デプロイテスト
☐ 署名なしデプロイの拒否確認
☐ コンテナ署名・EKS デプロイテスト
☐ IoT デバイス OTA 更新テスト

【本番運用】
☐ 署名プロファイル ローテーション スケジュール
☐ CloudTrail 監査ログ分析・アラート設定
☐ インシデント対応計画
☐ スタッフトレーニング

コスト・プライシング {#コスト}

月額概算

【スターアップ】(月間 10,000 署名)
  署名操作 10,000 × $0.0001     = $1
  署名プロファイル 1 × $25      = $25
  月額合計: 約 $26/月

【成長期エンタープライズ】(月間 1,000,000 署名)
  署名操作 100 万 × $0.0001     = $100
  署名プロファイル 5 × $25      = $125
  月額合計: 約 $225/月

【大規模組織】(月間 10,000,000 署名)
  署名操作 1,000 万 × $0.00008  = $800
  署名プロファイル 10 × $25     = $250
  月額合計: 約 $1,050/月

年額(参考): 数千~数万円(スケールアウトしても低コスト)

まとめ {#まとめ}

AWS Signer は、コード署名によるサプライチェーン整合性保証をマネージドで提供するサービスです。Lambda・コンテナ・IoT ファームウェアに暗号的署名を付与し、デプロイ時に改ざんを検出。KMS で署名鍵を管理し、CloudTrail で監査可能 に。セキュリティが重要な金融・医療・製造業で、開発スピードを損なわずにセキュリティを強化 するために欠かせません。

核心ポイント

  1. サプライチェーン攻撃への対抗:CI/CD パイプラインへの不正介入を暗号的に検出
  2. Lambda Code Signing Config:署名済みコードのみデプロイ可能に強制
  3. コンテナイメージ署名:Notation / Cosign で OCI 標準署名をサポート
  4. KMS 鍵管理:秘密鍵を AWS で安全に保管、CloudTrail で監査
  5. 自動署名 CI/CD 統合:CodePipeline で署名を自動化、開発スピード維持