翻訳は機械翻訳により提供されています。提供された翻訳内容と英語版の間で齟齬、不一致または矛盾がある場合、英語版が優先します。
# セキュリティ重視のワークロードの API キーを管理する
AWS Secrets Manager は、データベース認証情報、アプリケーション認証情報、OAuth トークン、API キー、およびその他のシークレットをライフサイクル全体で管理、取得、ローテーションするのに役立ちます。このページでは、セキュリティに敏感なワークロードで API キーとサードパーティーの認証情報を管理するための規範的なガイダンスを提供します。自動ローテーションをカスタマーマネージド AWS KMS キーおよび最小特権 IAM ポリシーと組み合わせます。また、侵害された認証情報の露出ウィンドウとブラスト半径を最小限に抑えるように VPC エンドポイントアクセスを設定します。
## に API キーを保存する AWS Secrets Manager
このセクションでは、最適なローテーションと取得のために API キーシークレットを構築する方法について説明します。各 API キーは、構造化された JSON 値を持つ個別のシークレットとして保存します。この構造では、アプリケーションは個々のフィールドを取得し、Secrets Manager は正しい値をローテーション関数に渡すことができます。
次の例は、サードパーティー API キーシークレットの一般的な JSON 構造を示しています。実際のフィールドはプロバイダーの要件によって異なります。保存する必要がある特定の認証情報とメタデータについては、プロバイダーのドキュメントを参照してください。
```
{
"apiKey": "your-api-key-value",
"apiKeyId": "key-identifier",
"endpoint": "https://api.example.com/v1",
"provider": "example-service"
}
```
**API キーのシークレット構造の例**
| フィールド | 値の例 | 目的 |
| --- | --- | --- |
| `apiKey` | `sk_live_abc123...` | アプリケーションがサードパーティー API による認証に使用する認証情報値。 |
| `apiKeyId` | `key_001` | プロバイダー側のキーの識別子。ローテーション中に新しいキーを作成し、古いキーを削除するために使用します。 |
| `endpoint` | `https://api.example.com/v1` | API エンドポイント URL。キーを使用して を保存し、取得によってアプリケーションが接続するために必要なものがすべて返されるようにします。 |
| `provider` | `stripe` | プロバイダー名。複数のプロバイダーを処理する関数ロジックのタグ付け、フィルタリング、ローテーションに役立ちます。 |
IAM ポリシー条件と組織のフィルタリングをサポートするために、各シークレットにメタデータをタグ付けします。たとえば、 AWS CLI または コンソールを使用して、シークレットに所有チーム、環境、コンプライアンススコープをタグ付けできます。
```
aws secretsmanager tag-resource \
--secret-id prod/payments/stripe-api-key \
--tags Key=Team,Value=payments Key=Environment,Value=production \
Key=Provider,Value=stripe Key=Compliance,Value=pci-dss
```
シークレットの作成の詳細については、「」を参照してください[AWS Secrets Manager シークレットを作成する](create_secret.md)。
## 暗号化設定
Secrets Manager は、 AWS KMS キーを使用して保管中のすべてのシークレット値を暗号化します。セキュリティに敏感なワークロードの場合は、コンプライアンスとアクセスコントロールの要件に基づいて暗号化キーを選択します。
**API キーシークレットの KMS キーオプション**
| キーのタイプ | どのようなときに使うか | セキュリティに関する考慮事項 |
| --- | --- | --- |
| AWS マネージドキー (`aws/secretsmanager`) | ほとんどのワークロードのデフォルト。追加コストやキー管理のオーバーヘッドはありません。 | キーポリシーは Secrets Manager オペレーションのみに制限されており、変更することはできません。クロスアカウントアクセスには使用できません。 |
| カスタマーマネージドキー | コンプライアンス要件 (PCI DSS、HIPAA、SOC 2、またはその他の適用可能な標準など）。クロスアカウントシークレット共有。主要な使用状況監査要件。 | キーポリシーはユーザーが制御します。復号できるプリンシパルを制限できます。シークレットとは別に、キーの削除を無効化またはスケジュールできます。を通じて独立した監査証跡を提供します。 |
セキュリティに敏感なワークロードの場合は、次のキーポリシー条件でカスタマーマネージドキーを使用します。
+ `kms:ViaService` – Secrets Manager () から送信されるリクエストにキーの使用を制限します`secretsmanager..amazonaws.com`。
+ `kms:EncryptionContext:SecretARN` – Secrets Manager の暗号化コンテキストを一致させることで、復号を特定のシークレット ARNs に制限します。
+ コンプライアンス境界ごとにキーを分離する – 異なるコンプライアンススコープ (PCI と非 PCI の比較など) のシークレットに異なる AWS KMS キーを使用します。
暗号化と復号プロセスの詳細については、「」を参照してください[でのシークレットの暗号化と復号 AWS Secrets Manager](security-encryption.md)。
## API キーの自動ローテーション
自動ローテーションにより、侵害された認証情報の公開期間が短縮されます。Secrets Manager は、スケジュールに従って Lambda 関数を呼び出します。関数は、プロバイダーに新しい API キーを作成し、シークレット値を更新して、古いキーを削除します。
Secrets Manager は、マネージド外部シークレットを通じて一部のサードパーティープロバイダーにマネージドローテーション機能を提供します。この機能とサポートされているプロバイダーのリストの詳細については、「」を参照してください[マネージド外部シークレットパートナー](mes-partners.md)。マネージドローテーションがサポートされていないプロバイダーの場合、プロバイダーの API を呼び出してキーを作成および削除するカスタム Lambda ローテーション関数を実装します。
### ローテーション関数のライフサイクル
ローテーション Lambda 関数は 4 つのステップを実装します。Secrets Manager は、ステップごとに 関数を 1 回呼び出し、`Step`パラメータを渡します。ステップが失敗すると、Secrets Manager は自動的にローテーション全体を再試行します。
**API キーのローテーションステップ**
| Step | API キーのアクション | 障害処理 |
| --- | --- | --- |
| `createSecret` | プロバイダー API を呼び出して新しいキーを作成します。`AWSPENDING` ステージングラベルを使用して、新しいキー値を Secrets Manager に保存します。 | キーの作成が失敗した場合、ローテーションは次のステップに移行しません。既存のキーは としてアクティブのままです`AWSCURRENT`。 |
| `setSecret` | プロバイダーで作成された API キーの場合、このステップは通常 no-op です。このステップは、ランダムキーが Secrets Manager で生成され、一般的な API キーフローではないプロバイダーで設定する必要がある場合に使用されます。 | このステップが失敗した場合、ローテーションは に進みません`testSecret`。 |
| `testSecret` | Secrets Manager から`AWSPENDING`値を取得し、プロバイダーにテスト API コールを実行して、新しいキーが機能することを確認します。 | テストが失敗した場合は、プロバイダーで保留中のキーを削除し、例外を発生させます。 |
| `finishSecret` | 新しいキー`AWSCURRENT`に移動します。古いキーは に移動します`AWSPREVIOUS`。必要に応じて、プロバイダーで古いキーを削除します。 | ラベルの更新が失敗した場合、ローテーションは完了しません。新しいキーは存在しますが、まだ というラベルが付けられていません`AWSCURRENT`。 |
完全なローテーション関数テンプレートと実装ガイダンスについては、「」を参照してください[Lambda ローテーション関数](rotate-secrets_lambda-functions.md)。
### ローテーションスケジュール設定
コンプライアンス要件と内部セキュリティポリシーに基づいてローテーション間隔を設定します。ワークロードに適用されるコンプライアンス標準を参照して、適切なローテーション頻度を決定します。
ローテーションウィンドウを使用して、ローテーションが発生するタイミングを制御します。これにより、ピークトラフィックまたはメンテナンスウィンドウ中にローテーションが実行されなくなります。
```
aws secretsmanager rotate-secret \
--secret-id prod/payments/stripe-api-key \
--rotation-rules '{
"ScheduleExpression": "cron(0 4 ? * SUN *)",
"Duration": "2h"
}'
```
スケジュール式の構文については、「」を参照してください[ローテーションスケジュール](rotate-secrets_schedule.md)。
## シークレットを効率的に取得する
Secrets Manager は、`GetSecretValue`呼び出しで 1 秒あたり 10,000 件のトランザクションをサポートします。ほとんどのアプリケーションではスロットリングは発生しません。呼び出し量やレイテンシーの影響を受けやすいパスが非常に多いアプリケーションでは、キャッシュソリューションを使用して API 呼び出しを減らし、応答時間を短縮します。
Secrets Manager は、複数の言語のキャッシュクライアントと、実行環境内でシークレットをローカルにキャッシュする Lambda 拡張機能を提供します。キャッシュオプションの詳細については、「」、[Python とクライアント側のキャッシュを使用して、Secrets Manager のシークレット値を取得する](retrieving-secrets_cache-python.md)「」、および[Java とクライアント側のキャッシュを使用して、Secrets Manager のシークレット値を取得する](retrieving-secrets_cache-java.md)「」を参照してください[Go とクライアント側のキャッシュを使用して、Secrets Manager のシークレット値を取得する](retrieving-secrets_cache-go.md)。
すべてのアクセスパターン`secretsmanager:GetSecretValue`について、各アプリケーションが必要とする特定のシークレットに制限する IAM ポリシーを設定します。
```
{
"Version": "2012-10-17",
"Statement": [{
"Effect": "Allow",
"Action": "secretsmanager:GetSecretValue",
"Resource": "arn:aws:secretsmanager:us-east-1:123456789012:secret:prod/payments/*",
"Condition": {
"StringEquals": {
"aws:ResourceTag/Environment": "production"
}
}
}]
}
```
## 機密性の高いワークロードのセキュリティ強化
以下のプラクティスは、厳格なセキュリティ要件 (PCI DSS、SOC 2、HIPAA、またはその他の該当するコンプライアンスフレームワークなど) を持つ環境の API キーを詳細に保護します。
**VPC エンドポイントによるネットワークアクセスの制限**
シークレットの取得がパブリックインターネットを経由しないように、Secrets Manager のインターフェイス VPC エンドポイントを作成します。エンドポイントを介してアクセスできるシークレットを制限するエンドポイントポリシーを適用します。詳細については、「[AWS Secrets Manager VPC エンドポイントの使用](vpc-endpoint-overview.md)」を参照してください。
**リソースポリシーをシークレットに適用する**
アカウント外または特定の VPC エンドポイント外のプリンシパルからのアクセスを明示的に拒否するリソースポリシーを各シークレットにアタッチします。これにより、IAM ID ポリシーとは無関係に 2 番目の認可境界が提供されます。
**でシークレットアクセスをモニタリングする **
は、、`GetSecretValue`、 `PutSecretValue`を含むすべての Secrets Manager API コールを自動的にログに記録します`RotateSecret`。セキュリティに敏感なシークレットの場合は、認識されないソース IP アドレスや IAM プリンシパルからの`GetSecretValue`呼び出しなど、予期しない呼び出しでトリガーする Amazon CloudWatch アラームを作成します。
**正常なローテーション`AWSPREVIOUS`に使用する**
ローテーション中、Secrets Manager は`AWSPREVIOUS`ステージングラベルを使用して以前のキー値を維持します。新しいキーの作成時にプロバイダーが以前のキーを無効にする場合は、 が認証エラー`AWSCURRENT`を返`AWSPREVIOUS`す場合に にフォールバックするようにアプリケーションを設定します。これにより、キーの作成からラベルの更新までの短い時間枠でのダウンタイムを回避できます。
**アタッチする前にリソースポリシーを検証する**
リソースポリシーのないシークレットは、パブリックアクセスを既にブロックしています。シークレットにリソースポリシーをアタッチするときは、 `ValidateResourcePolicy` API を使用して、ポリシーが広範なパブリックアクセスを許可しないようにします。で `BlockPublicPolicy`パラメータを使用して`PutResourcePolicy`、パブリックアクセスを許可するポリシーがアタッチされないようにすることもできます。リソースポリシーで `aws:PrincipalOrgID`条件キーを使用して、組織外のプリンシパルからのアクセスを防止します。
## よくある質問
このセクションでは、 での API キーのローテーションとシークレット管理に関する一般的な質問に回答します AWS Secrets Manager。
### ローテーション中の重複期間を処理するにはどうすればよいですか?
これは、新しいキーの作成時にプロバイダーが既存のキーを無効にする場合にのみ必要です。プロバイダーが複数のアクティブなキーを同時にサポートしている場合、両方のキーはローテーション期間中にアプリケーション側のフォールバックロジックなしで機能します。古いキーを無効にするプロバイダーの場合、現在のキーが 401 または 403 エラーを返`AWSPREVIOUS`した場合に で再試行するようにアプリケーションを設定します。新しいキーが機能していることを確認した後にのみ、`finishSecret`ステップのプロバイダーで古いキーを削除します。
### プロバイダーがプログラムによるキー作成をサポートしていない場合はどうなりますか?
プロバイダーが手動でキーを作成する必要がある場合 (ウェブコンソールなど）、ローテーションを完全に自動化することはできません。代わりに、ローテーションが予定されているときに (Amazon Simple Notification Service を介して) 通知を送信するローテーション関数を使用し、オペレーターにキーを手動で作成してシークレット値を更新するように促します。コンプライアンスローテーションの要件に合わせてローテーションスケジュールを設定し、 で Amazon CloudWatch アラームを使用してローテーション`days_since_last_rotation`の欠落を検出します。
### シークレットを取得するときに API スロットリングを回避するにはどうすればよいですか?
Secrets Manager は、 で 1 秒あたり 10,000 件のトランザクションをサポートしています`GetSecretValue`。ほとんどのアプリケーションではスロットリングは発生しません。アプリケーションで非常に大量の呼び出しを行う場合は、キャッシュクライアントまたは Lambda Parameters and Secrets 拡張機能を使用します。これらはシークレット値をメモリにキャッシュし、定期的に更新して、API コールの数を減らします。アプリケーションがローテーション後に新しいキーを取得するように、キャッシュ TTL をローテーション間隔より短い値に設定します。
### 環境ごとに 1 つのシークレットを使用するか、バージョンで 1 つのシークレットを使用する必要がありますか?
環境ごとに個別のシークレットを使用します (例: `prod/payments/stripe`および `dev/payments/stripe`)。これにより、環境ごとに異なる IAM ポリシー、ローテーションスケジュール、暗号化キーが許可されます。シークレットバージョン (ステージングラベル) はローテーション状態管理用であり、環境分離用ではありません。