AWS Secrets Manager

初心者から実務者向けの包括的解説

AWS Secrets Manager は、API キー・データベース認証情報・OAuth トークン・SSH キー・カスタムシークレットを安全に保存・取得・自動ローテーションする マネージドサービスです。2016 年にリリース後、暗号化・IAM 連携・自動ローテーション機能を通じて、シークレット管理のベストプラクティスを実現する業界標準ツールになりました。このページでは、Secrets Manager の概念・使い方・エコシステム・近年の動向を体系的に整理します。

このページの目的

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

• 初心者向け： Secrets Manager とは何か、なぜ必要かを学びたい方
• 開発者向け： GetSecretValue API を使ってシークレットを取得したい方
• DevOps / SRE 向け： Lambda ローテーション、KMS 統合、VPC エンドポイント設定したい方
• セキュリティ向け： IAM Policy・ResourcePolicy・監査ログを活用したい方
• 意思決定者向け： Parameter Store との使い分け・投資判断

2025-2026 年の Secrets Manager エコシステム

• AI Secret Scanning： CodeBuild / GitHub Actions での漏洩シークレット自動検出
• Cross-Region Replication： DR 対応でのシークレット自動複製
• Cost Optimization Batch API： 複数シークレット一括取得で API 料金削減
• OpenID Connect（OIDC）Integration： GitHub Actions / GitLab CI / Terraform Cloud での認証
• Hybrid Environment Support： オンプレミス Vault、HashiCorp との統合
• RDS / Redshift 自動ローテーション拡張： DocumentDB、ElastiCache サポート追加

定義

AWS 公式による定義：

“Secrets Manager enables you to manage, retrieve, and rotate database credentials, API keys, and other secrets throughout their lifecycle.”

暗号化・IAM ベースアクセス制御・自動ローテーション・CloudTrail 監査ログをあらゆるアプリケーション・インフラに提供します。

概要

初心者向けメモ： Secrets Manager は「シークレットの銀行」のようなものです。パスワード・API キー・秘密鍵などを暗号化して安全に保管し、必要なアプリケーションだけに IAM ポリシーで認可後に GetSecretValue API で配布します。単なるストレージではなく、Lambda ローテーション関数で定期的にシークレットを自動更新し、CloudTrail で全アクセスを監査します。

Secrets Manager は、複雑なマルチクラウド・ハイブリッド環境において以下を実現します。

• シークレットの一元管理：パスワード、API キー、証明書、OAuth トークンを統一されたインターフェースで保管・配布
• 自動ローテーション：Lambda 関数で定期的にシークレット更新、アプリ再起動なしで新認証情報に切り替わる
• クロスアカウント・クロスリージョン共有：IAM Policy・Resource Policy・レプリケーションで複数環境をサポート
• KMS 統合暗号化：カスタマーマネージドキー or AWS マネージドキーで保存時の暗号化
• 監査・コンプライアンス：全シークレットアクセスを CloudTrail でログ、PCI DSS・HIPAA 対応
• VPC PrivateLink：インターネット経由なしの安全なアクセス

Secrets Manager の位置づけ

【図1】AWS セキュリティスタックにおける Secrets Manager の位置：

graph TD
    Apps[アプリケーション群<br/>EC2/Lambda/ECS/EKS]

    Apps -->|GetSecretValue| SM[AWS Secrets Manager]

    SM -->|KMS暗号化<br/>復号化| KMS[AWS KMS<br/>Customer Managed Key]
    SM -->|バージョニング| Ver[Version History<br/>AWSCURRENT/AWSPENDING]
    SM -->|自動ローテーション| Lambda[Lambda<br/>Rotation Function]
    SM -->|アクセス監査| CT[CloudTrail]
    SM -->|IAM権限管理| IAM[IAM Policy<br/>Resource Policy]
    SM -->|DR対応| Replica[Cross-Region<br/>Replication]

    Lambda -->|自動更新| DB[RDS/Redshift<br/>DocumentDB<br/>Aurora]
    Lambda -->|外部API| API[Third Party API<br/>Stripe/Twilio等]

    Apps -->|VPC Endpoint| VPCEndpoint[VPC PrivateLink<br/>no Internet]
    VPCEndpoint -->|Private| SM

Secrets Manager が解決する課題

主な特徴

アーキテクチャ

初心者向けメモ： Secrets Manager は 4 層構造です。アプリケーションが IAM 権限を持つ場合、GetSecretValue API でシークレットを取得→KMS が復号化→アプリへ返却。ローテーション時は Lambda が DB パスワードを更新→Secrets Manager に新値を保存。「Secrets Manager が管理するのはシークレット本体とアクセス権、実際の使用方法はアプリ次第」というのが重要です。

【図2】Secrets Manager の多層アーキテクチャ：

graph TD
    subgraph Apps["アプリケーション層"]
        EC2["EC2/On-Prem"]
        Lambda["Lambda"]
        ECS["ECS/Fargate"]
        EKS["Kubernetes/EKS"]
    end

    subgraph Access["アクセス制御層"]
        IAMPolicy["IAM Policy<br/>GetSecretValue"]
        ResourcePolicy["Resource Policy<br/>Cross-Account"]
        VPCEndpoint["VPC Endpoint<br/>PrivateLink"]
    end

    subgraph Core["Secrets Manager コア"]
        Storage["Secret Storage<br/>暗号化保存"]
        Versioning["Version Manager<br/>AWSCURRENT/PENDING"]
        Rotation["Rotation Engine<br/>Lambda Trigger"]
    end

    subgraph Encryption["暗号化・監査層"]
        KMS["AWS KMS<br/>Customer Managed Key"]
        CloudTrail["CloudTrail<br/>Access Audit"]
    end

    subgraph Replica["DR・レプリケーション"]
        Primary["Primary Region"]
        Secondary["Secondary Region<br/>Read-Only Replica"]
    end

    Apps -->|GetSecretValue| Access
    Access -->|認可確認| Core
    Core -->|暗号化/復号化| KMS
    Core -->|ログ記録| CloudTrail
    Core -->|自動ローテーション| Rotation
    Rotation -->|RDS更新| DB[(RDS/Redshift<br/>Database)]
    Primary -->|自動複製| Secondary

アーキテクチャの主要コンポーネント

1. Secret Storage（シークレット保管）

Secrets Manager はマネージドサービスで、AWS インフラ上で暗号化して保管。ユーザーは直接ストレージ にアクセスしない。

保存形式：

• JSON キーバリュー： RDS 認証情報、API キー等を JSON で保存
• 文字列： カスタムシークレット、SSH キー、トークン等

サイズ制限：

• 最大 65,536 バイト / シークレット
• 十分に大きく、証明書チェーン・プライベートキー等を保存可能

2. Encryption（暗号化）

AWS KMS 統合：

Secrets Manager が KMS にデータを送信
  ↓
KMS が Data Key を生成・管理
  ↓
シークレットを暗号化して保存
  ↓
GetSecretValue API → KMS で復号化 → アプリへ返却

キーの選択：

• AWS Managed Key： alias/aws/secretsmanager（デフォルト、無料）
• Customer Managed Key： 独自ポリシーで制御（推奨・本番環境）

3. Versioning（バージョニング）

新しいシークレット作成
  ↓
AWSPENDING（待機状態）
  ↓
テスト・検証
  ↓
AWSCURRENT に昇格（現在の値）
  ↓
AWSPREVIOUS（前のバージョン・ロールバック用）

用途：

• ローテーション時の段階的切り替え
• 問題発生時のロールバック
• バージョン履歴の追跡

4. Rotation（自動ローテーション）

1. createSecret：新しいシークレット生成（AWSPENDING）
  ↓
2. setSecret：DB/外部サービスに新シークレット適用
  ↓
3. testSecret：新シークレットで接続テスト
  ↓
4. finishSecret：AWSPENDING → AWSCURRENT 昇格

ローテータ Lambda が実行

• AWS 提供ローテーター：RDS、Redshift、DocumentDB、MongoDB Atlas
• カスタムローテーター：API キー、外部 DB（PostgreSQL on EC2 等）

Secret タイプ

1. RDS Database Credentials（RDS 認証情報）

対応 DB エンジン：

• MySQL
• PostgreSQL
• MariaDB
• Oracle
• SQL Server
• Aurora（MySQL / PostgreSQL）

保存フォーマット：

{
  "username": "admin",
  "password": "GeneratedPassword123!",
  "engine": "mysql",
  "host": "mydb.cluster-xxxx.ap-northeast-1.rds.amazonaws.com",
  "port": 3306,
  "dbname": "mydb",
  "dbClusterIdentifier": "mydb-cluster"
}

自動ローテーション： ✅ AWS が提供する Lambda ローテーター使用

用途： EC2 アプリ、Lambda、ECS から RDS へのアクセス

2. Redshift Credentials（Redshift 認証情報）

保存フォーマット：

{
  "username": "admin",
  "password": "GeneratedPassword123!",
  "engine": "redshift",
  "host": "mycluster.xxxx.redshift.amazonaws.com",
  "port": 5439,
  "dbname": "dev"
}

自動ローテーション： ✅ AWS 提供ローテーター使用

3. DocumentDB Credentials（DocumentDB 認証情報）

保存フォーマット：

{
  "username": "admin",
  "password": "GeneratedPassword123!",
  "engine": "docdb",
  "host": "mydb-cluster.xxxx.docdb.amazonaws.com",
  "port": 27017,
  "dbname": "mydb"
}

自動ローテーション： ✅ AWS 提供ローテーター使用

4. API Key / OAuth Token（API キー・OAuth トークン）

一般的なサービス：

• Stripe API Key
• Twilio Token
• Slack Bot Token
• GitHub Personal Access Token
• 汎用 HTTP API キー

保存フォーマット（JSON）：

{
  "api_key": "sk-abc123defghi...",
  "api_endpoint": "https://api.stripe.com",
  "api_version": "2024-04-01",
  "expiry_date": "2026-12-31"
}

保存フォーマット（文字列）：

• sk-abc123defghi…

自動ローテーション： ❌ カスタム Lambda ローテーター必須（API が rotate/revoke メソッドをサポートしている場合）

5. SSH Key（SSH 秘密鍵）

用途：

• EC2 インスタンスへの SSH キー
• GitHub Deploy Key
• 外部サーバーへのアクセスキー

保存フォーマット：

• -----BEGIN RSA PRIVATE KEY-----
• MIIEpAIBAAKCAQEA2a2rwplBCc…
• …
• -----END RSA PRIVATE KEY-----

自動ローテーション： ❌ キーローテーション時には新キーペア生成が必要

6. Custom Secrets（カスタムシークレット）

自由形式のシークレット。任意の JSON または文字列を保存可能。

例：

{
  "db_password": "xxx",
  "api_token": "yyy",
  "encryption_key": "zzz",
  "certificate": "-----BEGIN CERTIFICATE-----..."
}

自動ローテーション： ❌ カスタム Lambda ローテーター実装

主要ユースケース

初心者向けメモ： Secrets Manager は「データベース認証情報管理」のイメージが強いですが、API キー・OAuth トークン・SSH キー・カスタムシークレットなど幅広い用途があります。ここでは実務でよくある 10+ のユースケースを整理します。

1. RDS Database Credentials（最も典型）

EC2 / Lambda / ECS アプリケーションが RDS に接続する際のパスワード管理。

パターン：

App 起動
  ↓
Secrets Manager から DB パスワード取得（IAM ロール認可）
  ↓
RDS に接続
  ↓
30 日ごとに自動ローテーション（アプリ再起動不要）

利点：

• ✅ ハードコード廃止
• ✅ 定期的な自動ローテーション
• ✅ パスワード漏洩時の迅速な対応
• ✅ CloudTrail でアクセス監査

2. API Key Management（API キー管理）

Third-party API（Stripe、Twilio、SendGrid など）のキー一元管理。

パターン：

複数の API キー
  ↓
Secrets Manager で一元保管
  ↓
IAM ロールでサービスごとのアクセス権制御
  ↓
ローテーション時にキー無効化・再生成

利点：

• ✅ キー漏洩リスク低減
• ✅ チームによるキー管理の一元化
• ✅ キー有効期限の管理

3. OAuth / JWT Token Management

GitHub、GitLab、OIDC、Okta などのシングルサインオン・フェデレーション認証の token 管理。

用途：

• GitHub Actions での認証
• Terraform Cloud との連携
• Kubernetes クラスタの OIDC provider トークン
• マイクロサービス間の Service-to-Service 認証

4. SSH Key Management

EC2 キーペア、GitHub Deploy Key、外部サーバーへのアクセスキー。

パターン：

EC2 インスタンスへの SSH キー
  ↓
Secrets Manager で一元保管
  ↓
Infrastructure as Code（Terraform 等）で自動配布
  ↓
キーローテーション時に新キー生成

利点：

• ✅ キーを環境変数・設定ファイルに保存しない
• ✅ 複数サーバーでの統一管理

5. CI/CD Secret Management（CodeBuild、GitHub Actions）

ビルド・デプロイパイプラインで必要なシークレット管理。

パターン：

GitHub Actions
  ↓
OIDC で AWS に認証
  ↓
IAM ロール経由で Secrets Manager にアクセス
  ↓
API キー・DB パスワード取得
  ↓
デプロイ実行

利点：

• ✅ GitHub Secrets に hardcode しない
• ✅ 複数リポジトリで統一管理
• ✅ OIDC で credential なし認証

6. Kubernetes（EKS）External Secrets Operator（ESO）

EKS ポッドから Secrets Manager のシークレットを自動マウント。

パターン：

K8s Pod
  ↓
External Secrets Operator
  ↓
Secrets Manager から取得
  ↓
K8s Secret として自動同期

利点：

• ✅ K8s Secret に hardcode しない
• ✅ 自動ローテーション対応
• ✅ 複数ポッドでの統一管理

7. IoT Certificate Management

IoT デバイスの X.509 証明書・秘密鍵保管。

用途：

• AWS IoT Core デバイス認証
• mTLS 通信のクライアント証明書

8. Lambda Environment Variable 代替

Lambda 環境変数に秘密情報を保存しない方法。

パターン：

Lambda 関数
  ↓
GetSecretValue で Secrets Manager からデータ取得
  ↓
環境変数を使わないゼロシークレット設計

利点：

• ✅ Lambda コンソール UI に秘密が表示されない
• ✅ コンテナイメージにシークレット埋め込まない

9. RDS Proxy Authentication

Amazon RDS Proxy（コネクションプーリング）のデータベース認証。

パターン：

アプリ
  ↓
RDS Proxy（IAM DB Auth またはパスワード）
  ↓
RDS Proxy が Secrets Manager からパスワード取得
  ↓
バックエンド RDS に接続

利点：

• ✅ アプリ側でパスワード管理不要
• ✅ RDS Proxy が自動ローテーション対応

10. ElastiCache、MemoryDB Credentials

Redis、Memcached のアクセス認証情報。

用途：

• ElastiCache for Redis（AUTH パスワード）
• MemoryDB for Redis（ユーザー認証）

11. Container Registry Authentication

Amazon ECR、Docker Hub、GitHub Container Registry のログイン認証。

用途：

• ECS / Fargate でのイメージプル認証
• CI/CD パイプラインでのイメージプッシュ

12. Third-Party SaaS Credentials

Datadog、New Relic、Sumo Logic、PagerDuty などのアカウント認証。

用途：

• API キーの安全な保管
• スクリプト・ラムダ関数からのプログラマティックアクセス

シークレットローテーション

ローテーションの目的

初心者向けメモ： シークレットローテーションは「定期的にパスワードやキーを更新し、漏洩リスクを低減する」セキュリティプラクティスです。Secrets Manager の自動ローテーション機能により、アプリケーション再起動なしに 新しい認証情報に切り替わります。

ローテーション実行の流れ：

ローテーションスケジュール（例：30 日）
  ↓
CloudWatch Events（EventBridge）が Secrets Manager トリガー
  ↓
Secrets Manager が Lambda ローテーター関数を呼び出し
  ↓
Lambda 処理：
    1. createSecret：新しいシークレット生成（AWSPENDING 状態）
    2. setSecret：DB/外部サービスに新シークレット適用
    3. testSecret：新シークレットで接続テスト
    4. finishSecret：AWSPENDING → AWSCURRENT 昇格
  ↓
アプリケーションは次回 GetSecretValue 呼び出し時に新値取得

AWS 提供ローテーター（RDS・Redshift・DocumentDB）

対応サービス：

• ✅ RDS（MySQL、PostgreSQL、Oracle、SQL Server、MariaDB、Aurora）
• ✅ Redshift
• ✅ DocumentDB（MongoDB 互換）

ローテーター Lambda 自動提供： AWS が提供する Lambda レイヤーにローテーション関数が含まれており、ユーザーは DB 接続設定とローテーション Lambda を Secrets Manager に登録するだけで動作。

設定例：

シークレット → Rotation タブ → Enable rotation
  ↓
Lambda function: SecretsManagerRDSMysqlRotation
  ↓
Rotation interval: 30 days
  ↓
VPC（DB にアクセス可能なセキュリティグループ）

カスタムローテーター（API キー・外部 DB）

API キーやサードパーティシステムのローテーション時には、カスタム Lambda 関数を実装。

実装例（Stripe API キーローテーション）：

import boto3
import json
import requests

def lambda_handler(event, context):
    secrets_manager = boto3.client('secretsmanager')
    secret_id = event['ClientRequestToken']

    metadata = secrets_manager.describe_secret(SecretId=secret_id)

    if not metadata['RotationEnabled']:
        raise ValueError("Secret rotation is not enabled")

    # 1. createSecret：新キー生成
    if event['Step'] == 'createSecret':
        # Stripe API で新キー生成（仮想例）
        new_key = generate_new_stripe_key
        secrets_manager.put_secret_value(
            SecretId=secret_id,
            ClientRequestToken=event['ClientRequestToken'],
            SecretString=json.dumps({'api_key': new_key}),
            VersionStages=['AWSPENDING']
        )

    # 2. setSecret：新キーを本番環境に適用
    elif event['Step'] == 'setSecret':
        pending_secret = secrets_manager.get_secret_value(
            SecretId=secret_id,
            VersionId=event['ClientRequestToken'],
            VersionStage='AWSPENDING'
        )
        new_key = json.loads(pending_secret['SecretString'])['api_key']
        update_environment_variable('STRIPE_API_KEY', new_key)

    # 3. testSecret：新キーで接続テスト
    elif event['Step'] == 'testSecret':
        pending_secret = secrets_manager.get_secret_value(
            SecretId=secret_id,
            VersionId=event['ClientRequestToken'],
            VersionStage='AWSPENDING'
        )
        new_key = json.loads(pending_secret['SecretString'])['api_key']
        response = requests.post(
            'https://api.stripe.com/v1/account',
            auth=('', new_key)
        )
        if response.status_code != 200:
            raise Exception("New API key test failed")

    # 4. finishSecret：AWSPENDING → AWSCURRENT
    elif event['Step'] == 'finishSecret':
        secrets_manager.update_secret_version_stage(
            SecretId=secret_id,
            VersionStage='AWSCURRENT',
            MoveToVersionId=event['ClientRequestToken'],
            RemoveFromVersionId=metadata['VersionIdsToStages'].keys[0]
        )

RDS・Redshift・DocumentDB 自動ローテーション

RDS 自動ローテーション（最も一般的）

対応 DB エンジン：

MySQL 5.7, 8.0+
PostgreSQL 9.6+
MariaDB 10.1+
Oracle 12c+
SQL Server 2016+
Aurora（MySQL/PostgreSQL 互換）

ローテーション動作：

1. DB 管理者ユーザーで新パスワード生成
2. RDS API で DB ユーザーパスワード更新（ALTER USER...）
3. 新パスワードを AWSPENDING として保存
4. 接続テスト実行
5. AWSCURRENT に昇格

アプリケーションへの影響：

• ❌ アプリ再起動不要
• ✅ アクティブな DB 接続：ローテーション後に自動切断
• ✅ コネクションプール：次の接続時に新パスワードで再接続

Redshift 自動ローテーション

1. Redshift クラスタ管理者ユーザーで新パスワード生成
2. ALTER USER で Redshift ユーザーパスワード更新
3. テスト接続確認
4. AWSCURRENT に昇格

注意点：

• ✅ Redshift Serverless 対応
• ❌ Redshift 復旧時はマスターユーザーのみローテーション対応

DocumentDB 自動ローテーション

1. DocumentDB クラスタマスターユーザーで新パスワード生成
2. db.updateUser で DocumentDB ユーザーパスワード更新
3. MongoDB 互換接続テスト
4. AWSCURRENT に昇格

バージョニング

初心者向けメモ： Secrets Manager のバージョニングは「シークレットの履歴管理と段階的ローテーション」を実現します。AWSCURRENT（現在使用）、AWSPENDING（待機中）、AWSPREVIOUS（前版）の 3 つの状態があります。

バージョンステージ

ローテーション時のバージョン遷移

初期状態：
  v1 → AWSCURRENT（アプリ使用中）
  v2 → AWSPREVIOUS（前版）

ローテーション開始：
  v1 → AWSCURRENT（アプリ使用中）
  v2 → AWSPREVIOUS
  v3 → AWSPENDING（新バージョン、ローテーション中）

テスト実行中：
  v3 を新しい設定で検証
  DB パスワード確認、接続テスト実行

ローテーション完了：
  v1 → AWSPREVIOUS（ロールバック用）
  v3 → AWSCURRENT（新規使用）
  v2 → （削除されます）

ロールバック

問題が発生した場合、前のバージョンに戻す：

# AWS CLI で手動ロールバック
aws secretsmanager update-secret-version-stage \
  --secret-id MyDatabaseSecret \
  --version-stage AWSCURRENT \
  --move-to-version-id <PREVIOUS_VERSION_ID> \
  --remove-from-version-id <CURRENT_VERSION_ID>

レプリケーション（クロスリージョン）

目的

Secrets Manager のシークレットを複数リージョンに自動複製。災害復旧（DR）、高可用性、グローバル展開に対応。

パターン：

Primary Region（us-east-1）
  └─ シークレット作成・管理
      ↓ 自動複製

Replica Region 1（eu-west-1）
  └─ Read-only replica

Replica Region 2（ap-northeast-1）
  └─ Read-only replica

レプリケーション設定

# プライマリでレプリケーション有効化
aws secretsmanager replicate-secret-to-regions \
  --secret-id MySecret \
  --add-replica-regions RegionCode=eu-west-1 RegionCode=ap-northeast-1

フェイルオーバー

Primary リージョンが障害時、Replica リージョンを昇格：

# Replica を新プライマリに昇格
aws secretsmanager update-secret \
  --secret-id MySecret \
  --replica-region-primary RegionCode=eu-west-1

利点

• ✅ DR：別リージョンでシークレット即座利用可能
• ✅ レイテンシ削減：ローカルリージョンから GetSecretValue
• ✅ 自動同期：新ローテーション時に全リージョンへ自動複製
• ✅ コスト最適化：Replica は読み取り専用で低コスト

VPC Endpoint（PrivateLink）

目的

プライベートサブネットの EC2 / Lambda / ECS から、インターネット経由なしで Secrets Manager にアクセス。

従来（インターネット経由）：

• Private Subnet EC2
• ↓ Internet Gateway（VPN/NAT）
• Secrets Manager（API Gateway）

VPC Endpoint（推奨）：

• Private Subnet EC2
• ↓ VPC Endpoint（PrivateLink）
• Secrets Manager（AWS ネットワーク内）

VPC Endpoint 設定

# Interface Endpoint 作成
aws ec2 create-vpc-endpoint \
  --vpc-id vpc-xxxxx \
  --vpc-endpoint-type Interface \
  --service-name com.amazonaws.ap-northeast-1.secretsmanager \
  --subnet-ids subnet-xxxxx subnet-yyyyy \
  --security-group-ids sg-xxxxx

セキュリティグループ設定

• Inbound Rule:
• Protocol: TCP
• Port: 443
• Source: Private Subnet CIDR（10.0.0.0/16）

利点

• ✅ インターネット経由なし（より安全）
• ✅ AWS ネットワーク内で低レイテンシ
• ✅ NAT Gateway コスト削減
• ✅ FIPS 140-2 環境対応

セキュリティ（KMS・IAM・ResourcePolicy）

1. KMS 暗号化

デフォルト設定：

• AWS Managed Key（alias/aws/secretsmanager）
• 無料・AWS が鍵ローテーション管理

本番推奨：

• Customer Managed Key（ユーザー作成）
• カスタム Policy で暗号化キーへのアクセス制御
• 監査ログ細粒度管理

設定例：

# Customer Managed Key 作成
aws kms create-key \
  --description "Secrets Manager encryption key" \
  --key-policy <POLICY_JSON>

# シークレット作成時に CMK 指定
aws secretsmanager create-secret \
  --name MySecret \
  --secret-string '{"password":"secret"}' \
  --kms-key-id arn:aws:kms:ap-northeast-1:123456789012:key/xxxxx

2. IAM Policy（アクセス制御）

ポリシー例：

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Allow",
      "Action": [
        "secretsmanager:GetSecretValue"
      ],
      "Resource": "arn:aws:secretsmanager:ap-northeast-1:123456789012:secret:MyDatabaseSecret-*"
    },
    {
      "Effect": "Allow",
      "Action": [
        "kms:Decrypt"
      ],
      "Resource": "arn:aws:kms:ap-northeast-1:123456789012:key/xxxxx"
    }
  ]
}

ベストプラクティス：

• ✅ Resource ARN にワイルドカード（secret:MyDbSecret-*）で複数バージョン対応
• ✅ KMS Decrypt アクション をセットで許可
• ✅ 最小権限：必要なシークレットのみアクセス許可

3. Resource Policy（クロスアカウント）

複数の AWS アカウント間でシークレット共有。

ポリシー例：

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Sid": "AllowCrossAccountAccess",
      "Effect": "Allow",
      "Principal": {
        "AWS": "arn:aws:iam::999999999999:role/AppRole"
      },
      "Action": "secretsmanager:GetSecretValue",
      "Resource": "*"
    }
  ]
}

用途：

• マイクロサービスアーキテクチャ（別 AWS アカウント）での統一 DB 認証情報共有
• マルチアカウント環境での API キー一元管理

4. CloudTrail 監査ログ

ログに記録されるイベント：

CreateSecret
DeleteSecret
UpdateSecret
GetSecretValue ← 重要：誰がいつシークレットを取得したか
RotateSecret
ReplicateSecretToRegions

CloudTrail 設定確認：

# CloudTrail でシークレット API ログ確認
aws cloudtrail lookup-events \
  --lookup-attributes AttributeKey=ResourceType,AttributeValue=AWS::SecretsManager::Secret \
  --max-results 50

コンプライアンス対応：

• ✅ PCI DSS：全シークレットアクセスをログに記録
• ✅ HIPAA：Protected Health Information（PHI）アクセス監査
• ✅ SOC 2：アクセス制御・監査ログ要件満たし

ECS・EKS・Lambda 連携

1. ECS Task（Fargate）でのシークレット利用

パターン：

ECS Task Definition
  ↓
Environment Variables：Secrets Manager の ARN 指定
  ↓
ECS Agent が GetSecretValue でシークレット取得
  ↓
コンテナに環境変数として注入

Task Definition 設定例：

{
  "family": "my-app",
  "containerDefinitions": [
    {
      "name": "app-container",
      "image": "myapp:latest",
      "secrets": [
        {
          "name": "DB_PASSWORD",
          "valueFrom": "arn:aws:secretsmanager:ap-northeast-1:123456789012:secret:MyDatabaseSecret-xxxxx:password::"
        }
      ],
      "environment": [
        {
          "name": "DB_HOST",
          "value": "mydb.cluster-xxxx.ap-northeast-1.rds.amazonaws.com"
        }
      ]
    }
  ],
  "executionRoleArn": "arn:aws:iam::123456789012:role/ecsTaskExecutionRole"
}

IAM ロール権限：

{
  "Effect": "Allow",
  "Action": [
    "secretsmanager:GetSecretValue"
  ],
  "Resource": "arn:aws:secretsmanager:ap-northeast-1:123456789012:secret:MyDatabaseSecret-*"
}

2. Kubernetes（EKS）External Secrets Operator

EKS ポッドから Secrets Manager のシークレットを自動同期。

インストール：

helm repo add external-secrets https://charts.external-secrets.io
helm install external-secrets external-secrets/external-secrets -n external-secrets-system --create-namespace

SecretStore 定義：

apiVersion: external-secrets.io/v1beta1
kind: SecretStore
metadata:
  name: aws-secrets-manager
spec:
  provider:
    aws:
      service: SecretsManager
      region: ap-northeast-1
      auth:
        jwt:
          serviceAccountRef:
            name: external-secrets-sa

ExternalSecret 定義：

apiVersion: external-secrets.io/v1beta1
kind: ExternalSecret
metadata:
  name: db-secret
spec:
  refreshInterval: 1h
  secretStoreRef:
    name: aws-secrets-manager
    kind: SecretStore
  target:
    name: db-secret-k8s
    creationPolicy: Owner
  data:
  - secretKey: password
    remoteRef:
      key: MyDatabaseSecret
      property: password

Pod での利用：

apiVersion: v1
kind: Pod
metadata:
  name: app-pod
spec:
  serviceAccountName: app-sa
  containers:
  - name: app
    image: myapp:latest
    env:
    - name: DB_PASSWORD
      valueFrom:
        secretKeyRef:
          name: db-secret-k8s
          key: password

3. Lambda 関数での GetSecretValue

Python 例：

import boto3
import json

secrets_client = boto3.client('secretsmanager', region_name='ap-northeast-1')

def lambda_handler(event, context):
    try:
        # Secrets Manager からシークレット取得
        response = secrets_client.get_secret_value(
            SecretId='MyDatabaseSecret'
        )

        # JSON パース（RDS 認証情報の場合）
        if 'SecretString' in response:
            secret = json.loads(response['SecretString'])
            username = secret['username']
            password = secret['password']
            host = secret['host']

        # DB 接続
        import pymysql
        conn = pymysql.connect(
            host=host,
            user=username,
            password=password,
            database='mydb'
        )

        return {'statusCode': 200, 'body': 'Connected'}

    except Exception as e:
        return {'statusCode': 500, 'body': str(e)}

Lambda IAM ロール権限：

{
  "Effect": "Allow",
  "Action": [
    "secretsmanager:GetSecretValue"
  ],
  "Resource": "arn:aws:secretsmanager:ap-northeast-1:123456789012:secret:MyDatabaseSecret-*"
}

4. Lambda キャッシングライブラリ

GetSecretValue API は遅延・コスト発生。キャッシング推奨。

AWS Secrets Manager キャッシュライブラリ（公式）：

from aws_secretsmanager_caching import SecretCache

cache = SecretCache

def lambda_handler(event, context):
    # キャッシュから取得（初回は API、以降はメモリ）
    secret = cache.get_secret_string('MyDatabaseSecret')

    # パスワード利用
    import json
    creds = json.loads(secret)
    return {'password': creds['password']}

メリット：

• ✅ API 呼び出し削減（コスト削減）
• ✅ レイテンシ低減
• ✅ TTL キャッシュで自動ローテーション対応

Cost Optimization

1. 価格体系

例：

シークレット 10 個 × $0.40 = $4.00 / 月
API 呼び出し 100 万回 × $0.05 / 10,000 = $5.00 / 月
Total: 月 $9.00

2. コスト削減戦略

A. Batch GetSecretValue API（2024 年新機能）

複数シークレットを1つの API 呼び出しで取得。

import boto3

client = boto3.client('secretsmanager')

# 複数シークレット一括取得
response = client.batch_get_secret_value(
    SecretIds=['Secret1', 'Secret2', 'Secret3']
)

for secret in response['Secrets']:
    print(secret['Name'], secret['SecretString'])

コスト削減効果：

従来：3 つのシークレット取得 → 3 × $0.05 / 10,000 = $0.00015 / 回
Batch：1 回で 3 つ取得 → 1 × $0.05 / 10,000 = $0.000050 / 回
削減：66% コスト削減

B. Lambda キャッシング

GetSecretValue の キャッシュで API 削減。

100 万回呼び出し
  ↓
キャッシュ 95%
  ↓
実際の API：50,000 回
  ↓
コスト：$0.25 / 月（従来 $5.00）

C. Parameter Store との使い分け

• DB 認証情報・API キー → Secrets Manager
• （自動ローテーション、KMS 標準）
• 設定値・ARN・環境値 → Parameter Store
• （低コスト、小さいデータ）

3. 一般的なコスト

スタートアップ（シークレット 5～10 個、API 100k/月）
  → 月 $2～3

中規模組織（シークレット 50 個、API 1M/月、レプリケーション 2 リージョン）
  → 月 $30～40

エンタープライズ（シークレット 500 個、API 10M/月、レプリケーション 5 リージョン）
  → 月 $300～500

Parameter Store vs Secrets Manager 使い分け

初心者向けメモ： AWS には 2 つのシークレット管理サービスがあります。DB パスワード・API キーは Secrets Manager、設定値・ARN は Parameter Store が最適です。

決定フロー：

シークレット？
  ├─ Yes（DB password、API key、OAuth token）
  │   └─ Secrets Manager
  │       （自動ローテーション機能あり）
  │
  └─ No（設定値、ARN、リージョン情報）
      └─ Parameter Store
          （コスト最適、小さいデータ）

他の類似ツールとの比較

Secrets Manager vs HashiCorp Vault

Secrets Manager vs Azure Key Vault

Secrets Manager vs GCP Secret Manager

Secrets Manager vs 1Password / Doppler

クライアント・エコシステム

1. AWS CLI

# シークレット取得
aws secretsmanager get-secret-value \
  --secret-id MyDatabaseSecret \
  --region ap-northeast-1

# シークレット作成
aws secretsmanager create-secret \
  --name MyAPIKey \
  --secret-string '{"api_key":"sk-abc123..."}' \
  --kms-key-id arn:aws:kms:ap-northeast-1:123456789012:key/xxxxx

# ローテーション有効化
aws secretsmanager rotate-secret \
  --secret-id MyDatabaseSecret \
  --rotation-lambda-arn arn:aws:lambda:ap-northeast-1:123456789012:function:SecretsManagerRDSMysqlRotation \
  --rotation-rules DurationSeconds=2592000

2. AWS SDK（複数言語）

Python（boto3）：

import boto3

client = boto3.client('secretsmanager', region_name='ap-northeast-1')
response = client.get_secret_value(SecretId='MyDatabaseSecret')
print(response['SecretString'])

Node.js：

const AWS = require('aws-sdk');
const client = new AWS.SecretsManager({ region: 'ap-northeast-1' });

client.getSecretValue({ SecretId: 'MyDatabaseSecret' }, (err, data) => {
  if (err) console.log(err);
  else console.log(data.SecretString);
});

Java：

import software.amazon.awssdk.services.secretsmanager.SecretsManagerClient;
import software.amazon.awssdk.services.secretsmanager.model.GetSecretValueRequest;
import software.amazon.awssdk.services.secretsmanager.model.GetSecretValueResponse;

SecretsManagerClient client = SecretsManagerClient.builder.region(Region.AP_NORTHEAST_1).build;
GetSecretValueResponse response = client.getSecretValue(
    GetSecretValueRequest.builder.secretId("MyDatabaseSecret").build
);
System.out.println(response.secretString);

3. Terraform

# Secrets Manager シークレット作成
resource "aws_secretsmanager_secret" "db_secret" {
  name       = "mydb-secret"
  kms_key_id = aws_kms_key.secrets_key.id
}

# シークレット値設定
resource "aws_secretsmanager_secret_version" "db_secret_version" {
  secret_id = aws_secretsmanager_secret.db_secret.id
  secret_string = jsonencode({
    username = "admin"
    password = random_password.db_password.result
    engine   = "mysql"
    host     = aws_db_instance.mydb.endpoint
    port     = 3306
  })
}

# ローテーション設定
resource "aws_secretsmanager_secret_rotation" "db_rotation" {
  secret_id           = aws_secretsmanager_secret.db_secret.id
  rotation_enabled    = true
  rotation_lambda_arn = aws_lambda_function.rotation.arn
  rotation_rules {
    automatically_after_days = 30
  }
}

4. AWS CloudFormation

AWSTemplateFormatVersion: '2010-09-09'

Resources:
  MyDatabaseSecret:
    Type: AWS::SecretsManager::Secret
    Properties:
      Name: mydb-secret
      KmsKeyId: !GetAtt SecretsKey.Arn
      SecretString: |
        {
          "username": "admin",
          "password": "InitialPassword123!",
          "engine": "mysql",
          "host": "mydb.cluster-xxxx.ap-northeast-1.rds.amazonaws.com"
        }

  SecretRotation:
    Type: AWS::SecretsManager::RotationSchedule
    Properties:
      SecretId: !Ref MyDatabaseSecret
      RotationLambdaARN: arn:aws:lambda:ap-northeast-1:123456789012:function:SecretsManagerRDSMysqlRotation
      RotationRules:
        DurationSeconds: 7200
        Frequency:
          Duration: 30
          Unit: DAYS

5. External Secrets Operator（Kubernetes）

前述の「EKS 連携」セクション参照。

6. コンテナイメージ拡張

ECS / Fargate でのシークレット注入は、ECS Agent が自動実行。追加ライブラリ不要。

ベストプラクティス

1. 最小権限の原則

{
  "Effect": "Allow",
  "Action": [
    "secretsmanager:GetSecretValue"
  ],
  "Resource": "arn:aws:secretsmanager:ap-northeast-1:123456789012:secret:MyDatabaseSecret-*",
  "Condition": {
    "IpAddress": {
      "aws:SourceIp": "10.0.0.0/8"
    }
  }
}

✅ DO：

• 必要なシークレットのみアクセス許可
• IP 制限・VPC エンドポイント経由に限定
• IAM ロール は時間制限付き

❌ DON’T：

• Root ユーザーに GetSecretValue 許可
• 全 ARN（*）に権限付与
• Policy ポリシーで細粒度制御なし

2. 自動ローテーション戦略

高頻度（API キー）：7～30 日
  ↓
中頻度（DB パスワード）：30～90 日
  ↓
低頻度（SSH キー）：90～365 日

テスト環境：

• ローテーション無効にして開発効率向上
• 本番移行時のみ有効化

3. ローテーション Lambda の VPC 設定

• Lambda が以下にアクセス可能か確認：
• ✅ RDS / Redshift（DB セキュリティグループ）
• ✅ Secrets Manager（VPC Endpoint または NAT Gateway）

セキュリティグループ設定：

• ローテーション Lambda SG：
• Outbound → RDS SG Port 3306（MySQL）
• Outbound → NAT Gateway または VPC Endpoint

4. クロスアカウント設定

マイクロサービスがシークレット共有時：

Account A（Secrets Manager 管理）
  └─ Resource Policy で Account B のロール許可

Account B（アプリケーション実行）
  └─ IAM Policy で Account A のシークレット GetSecretValue

5. KMS キー ポリシー

{
  "Sid": "AllowSecretsManagerToUse",
  "Effect": "Allow",
  "Principal": {
    "Service": "secretsmanager.amazonaws.com"
  },
  "Action": [
    "kms:Decrypt",
    "kms:GenerateDataKey"
  ],
  "Resource": "*"
}

6. バージョン管理・GitOps

Terraform + Git でシークレット管理：

# git では encrypted 値のみコミット
resource "aws_secretsmanager_secret" "example" {
  name = "myapp-secret"
}

# 実際の値は terraform.tfvars（.gitignore）または Vault で管理
resource "aws_secretsmanager_secret_version" "example" {
  secret_id     = aws_secretsmanager_secret.example.id
  secret_string = var.secret_value  # 環境変数から注入
}

7. 監査・コンプライアンス

# CloudTrail で GetSecretValue ログ確認
aws cloudtrail lookup-events \
  --lookup-attributes AttributeKey=EventName,AttributeValue=GetSecretValue \
  --max-results 100 \
  --output json | jq '.Events[] | {EventTime, Username, EventName, Resources}'

CloudWatch ログ集約：

• CloudTrail → CloudWatch Logs → Athena で SQL クエリ

トラブルシューティング

よくある問題と解決策

1. AccessDeniedException: User is not authorized

原因： IAM Policy に GetSecretValue 権限がない

解決：

{
  "Effect": "Allow",
  "Action": "secretsmanager:GetSecretValue",
  "Resource": "arn:aws:secretsmanager:ap-northeast-1:123456789012:secret:MySecret-*"
}

2. InvalidParameterException: Resource policy is not valid JSON

原因： Resource Policy の JSON 構文エラー

解決：

# JSON バリデーション
aws secretsmanager get-resource-policy --secret-id MySecret | jq .

3. ローテーション失敗：Lambda が DB にアクセスできない

原因： Lambda セキュリティグループが RDS へのアウトバウンドトラフィックをブロック

解決：

• Lambda SG：
• Outbound rule → RDS SG Port 3306

4. テスト接続失敗：新パスワードが古い設定で利用中

原因： ローテーション中にアプリがまだ古いパスワードを使用

解決：

• Lambda キャッシュ TTL を短縮
• GetSecretValue を定期呼び出し
• コネクションプール を再起動

5. クロスリージョンレプリケーション遅延

原因： Primary リージョンでの更新がレプリカリージョンに 数秒遅延

解決：

• 強力な整合性が必要な場合は Primary リージョンのみアクセス
• 読み取り専用レプリカは参照用のみ

近年の動向

1. AI Secret Scanning（自動検出）

CodeBuild / GitHub Actions でコードの漏洩シークレット自動検出・隔離。

実装例（GitHub Actions）：

- name: AWS Secret Detection
  uses: aws-actions/configure-aws-credentials@v2
  with:
    aws-region: ap-northeast-1

- name: Scan for secrets
  run: |
    aws codeartifact list-repositories --domain myco

2. OpenID Connect（OIDC）Integration

GitHub Actions、GitLab CI、Terraform Cloud での認証。

name: Deploy
on: push

permissions:
  id-token: write
  contents: read

jobs:
  deploy:
    runs-on: ubuntu-latest
    steps:
    - uses: aws-actions/configure-aws-credentials@v2
      with:
        role-to-assume: arn:aws:iam::123456789012:role/GitHubActionsRole
        aws-region: ap-northeast-1

    - name: Get secret
      run: aws secretsmanager get-secret-value --secret-id MySecret

3. Hybrid Environment Support

オンプレミス Vault、HashiCorp との統合。

• Hybrid Secret Sync：
• AWS Secrets Manager ← → HashiCorp Vault
• （クロスプラットフォーム ローテーション）

4. Cost Optimization Features

• Batch GetSecretValue：複数シークレット一括取得で 66% API コスト削減
• キャッシング強化：Lambda レイヤーでのディープキャッシング

5. RDS Auto Minor Version Upgrade 連携

RDS 自動パッチ時のローテーション自動調整。

6. DynamoDB・DocumentDB・ElastiCache 拡張

DocumentDB、ElastiCache（Redis・Memcached）のネイティブローテーション対応予定。

学習リソース

公式ドキュメント・リファレンス

• AWS Secrets Manager ユーザーガイド
• AWS Secrets Manager API リファレンス
• AWS Lambda ローテーション関数
• RDS データベース認証

実装サンプル

• AWS Blog：Secrets Manager の例
• AWS GitHub リポジトリ
• Terraform AWS Provider

オンライン学習

• AWS Skills Builder：Secrets Manager コース
• Pluralsight / Udemy：AWS セキュリティ認定向け講座

コミュニティ

• AWS Secrets Manager フォーラム
• Stack Overflow（aws-secrets-manager タグ）

実装例・活用シーン

シーン 1：RDS + Lambda + Secrets Manager

import boto3
import json
import pymysql

def lambda_handler(event, context):
    secrets_client = boto3.client('secretsmanager')

    # Secrets Manager からシークレット取得
    response = secrets_client.get_secret_value(SecretId='mydb-secret')
    secret = json.loads(response['SecretString'])

    # RDS に接続・クエリ実行
    conn = pymysql.connect(
        host=secret['host'],
        user=secret['username'],
        password=secret['password'],
        database=secret['dbname']
    )

    cursor = conn.cursor
    cursor.execute('SELECT * FROM users LIMIT 10')
    result = cursor.fetchall

    conn.close

    return {'statusCode': 200, 'data': result}

シーン 2：ECS Fargate + Secrets Manager

{
  "family": "myapp-task",
  "containerDefinitions": [
    {
      "name": "myapp",
      "image": "myapp:latest",
      "secrets": [
        {
          "name": "DB_PASSWORD",
          "valueFrom": "arn:aws:secretsmanager:ap-northeast-1:123456789012:secret:mydb-secret-xxxxx:password::"
        },
        {
          "name": "API_KEY",
          "valueFrom": "arn:aws:secretsmanager:ap-northeast-1:123456789012:secret:stripe-api-key-xxxxx:api_key::"
        }
      ]
    }
  ],
  "executionRoleArn": "arn:aws:iam::123456789012:role/ecsTaskExecutionRole"
}

シーン 3：GitHub Actions + OIDC + Secrets Manager

name: Deploy to AWS

on: push

permissions:
  id-token: write
  contents: read

jobs:
  deploy:
    runs-on: ubuntu-latest
    steps:
    - uses: actions/checkout@v3

    - uses: aws-actions/configure-aws-credentials@v2
      with:
        role-to-assume: arn:aws:iam::123456789012:role/GitHubActionsRole
        aws-region: ap-northeast-1

    - name: Get deployment secret
      run: |
        SECRET=$(aws secretsmanager get-secret-value --secret-id deploy-key --query SecretString --output text)
        echo "::add-mask::$SECRET"
        echo "DEPLOY_KEY=$SECRET" >> $GITHUB_ENV

    - name: Deploy
      run: ./deploy.sh
      env:
        DEPLOY_KEY: ${{ env.DEPLOY_KEY }}

シーン 4：Kubernetes（EKS）+ External Secrets Operator

前述「EKS 連携」セクション参照。

導入ロードマップ

Phase 1：計画・評価（1～2 月）

• [ ] セキュリティ要件・コンプライアンス要件確認
• [ ] 既存シークレット管理方式の棚卸し
• [ ] Secrets Manager vs Parameter Store の用途分類
• [ ] PoC 環境構築
• [ ] KMS キーポリシー設計
• [ ] コスト試算

Phase 2：開発環境構築（2～4 月）

• [ ] AWS Secrets Manager 権限設計（IAM ロール）
• [ ] 開発用 KMS キー作成
• [ ] シークレット作成テンプレート整備
• [ ] Lambda ローテーター関数開発（RDS / 外部 DB）
• [ ] Local テスト環境でのシークレット取得テスト
• [ ] CloudTrail ログ設定

Phase 3：Staging 環境（4～6 月）

• [ ] Customer Managed KMS キー作成・Policy 設定
• [ ] RDS / Redshift ローテーション設定
• [ ] ECS / Lambda での GetSecretValue 実装
• [ ] VPC Endpoint 設定
• [ ] ローテーション動作確認
• [ ] Resource Policy（クロスアカウント）設定・テスト

Phase 4：本番デプロイ（6～8 月）

• [ ] 本番 Secrets Manager インスタンス起動
• [ ] 既存シークレット段階的マイグレーション
• [ ] 運用 Runbook 作成
• [ ] 監視・アラート設定（CloudWatch / EventBridge）
• [ ] 本番トラブルシューティング演習

Phase 5：最適化・継続運用（8 月以降）

• [ ] CloudTrail ログ分析・アクセス監査
• [ ] ローテーション失敗の自動復旧
• [ ] コスト分析・Batch API 導入検討
• [ ] レプリケーション戦略見直し
• [ ] チーム教育・ドキュメント更新
• [ ] セキュリティレビュー

実装チェックリスト

セットアップ・アクセス制御

• [ ] Secrets Manager シークレット作成
• [ ] AWS KMS Customer Managed Key 作成・設定
• [ ] IAM Policy で GetSecretValue 権限付与
• [ ] VPC Endpoint（PrivateLink）設定
• [ ] Resource Policy でクロスアカウント権限設定

自動ローテーション

• [ ] Lambda ローテーター関数デプロイ
• [ ] ローテーションスケジュール設定（RDS: 30 日等）
• [ ] ローテーション失敗時の Lambda Dead Letter Queue 設定
• [ ] ローテーション Lambda の VPC セキュリティグループ設定

アプリケーション統合

• [ ] Lambda / ECS での GetSecretValue 実装
• [ ] EKS（External Secrets Operator）設定
• [ ] Secrets Manager キャッシュライブラリ導入
• [ ] Batch API 活用検討

監視・監査

• [ ] CloudTrail で Secrets Manager ログ有効化
• [ ] CloudWatch Logs グループ作成・集約
• [ ] GetSecretValue 監視アラート設定
• [ ] 定期的なアクセスログレビュー

セキュリティ・コンプライアンス

• [ ] 最小権限 Policy 設計・監査
• [ ] キーローテーション Policy 設定
• [ ] PCI DSS / HIPAA コンプライアンス対応確認
• [ ] 定期セキュリティレビュー

まとめ

AWS Secrets Manager は 「シークレットの保存・取得・自動ローテーションを統合管理する、AWS ネイティブなマネージドサービス」 です。

何ができるか

✅ RDS・Redshift・DocumentDB の自動ローテーション ✅ API キー・OAuth トークン・SSH キーの一元管理 ✅ IAM + KMS による細粒度アクセス制御 ✅ CloudTrail による監査ログ・コンプライアンス対応 ✅ クロスリージョンレプリケーション（DR 対応） ✅ VPC PrivateLink でのセキュアアクセス ✅ ECS・EKS・Lambda と統合

導入のポイント

1. シークレット分類：DB パスワード（Secrets Manager） vs 設定値（Parameter Store）
2. 自動ローテーション：30～90 日ごとに自動更新、ドリフト防止
3. KMS 統合：Customer Managed Key で暗号化・監査
4. IAM Policy：最小権限、Resource Policy でクロスアカウント対応
5. キャッシング：Lambda キャッシュで API コスト・レイテンシ最適化

2025-2026 の展望

• OpenID Connect（OIDC）統合で GitHub Actions・Terraform Cloud 認証強化
• AI Secret Scanning で漏洩シークレット自動検出
• Batch GetSecretValue で API コスト 66% 削減
• Hybrid Environment Support でオンプレミス Vault 連携

参考文献

公式ドキュメント

• AWS Secrets Manager User Guide
• AWS Secrets Manager API Reference
• Rotating secrets
• Replicate secrets

関連 AWS サービス

• AWS KMS（Key Management Service）
• AWS CloudTrail
• AWS Systems Manager Parameter Store
• Amazon RDS
• AWS Lambda

ツール・ライブラリ

• AWS SDK for Python（boto3）
• AWS SDK for Node.js
• Terraform AWS Provider
• External Secrets Operator

ベストプラクティス・ブログ

• AWS Security Blog
• AWS Well-Architected Framework - Security Pillar

2025-2026 最新参考文献

11. Cross-Region Replication in Secrets Manager - マルチリージョン対応
12. Automate Secrets Replication Across AWS Regions - DR対応
13. OpenID Connect Integration with Secrets Manager - GitHub Actions/Terraform Cloud認証
14. AI Secret Scanning for Developers - 漏洩検知（2026新機能）
15. Batch GetSecretValue API - コスト最適化
16. HashiCorp Vault Integration - ハイブリッド環境対応
17. External Secrets Operator (ESO) - Kubernetes連携
18. CSI Secrets Store Driver - Kubernetes Pod マウント