翻訳は機械翻訳により提供されています。提供された翻訳内容と英語版の間で齟齬、不一致または矛盾がある場合、英語版が優先します。
のアクセス許可リファレンス AWS Secrets Manager
アクセス許可のポリシーを構成している要素については、「JSON policy document structure」と「IAM JSON policy elements reference」を参照してください。
独自のアクセス許可ポリシーの作成を開始するには、「のアクセス許可ポリシーの例 AWS Secrets Manager」を参照してください。
[アクション] テーブルの [リソースタイプ] 列は、各アクションがリソースレベルの許可をサポートしているかどうかを示します。この列に値がない場合は、ポリシーステートメントの Resource
要素で、ポリシーが適用されるすべてのリソース (「*」) を指定する必要があります。列にリソースタイプが含まれる場合、そのアクションを含むステートメントでそのタイプの ARN を指定できます。アクションで 1 つ以上のリソースが必須となっている場合、呼び出し元には、それらのリソースを伴うアクションを使用するための許可が付与されている必要があります。必須リソースは、アスタリスク (*) でテーブルに示されています。IAM ポリシーの Resource
要素でリソースアクセスを制限する場合は、必要なリソースタイプごとに ARN またはパターンを含める必要があります。一部のアクションでは、複数のリソースタイプがサポートされています。リソースタイプがオプション (必須として示されていない) の場合、オプションのリソースタイプのいずれかを使用することを選択できます。
[アクション] テーブルの [条件キー] 列には、ポリシーステートメントの Condition
要素で指定できるキーが含まれます。サービスのリソースに関連付けられている条件キーの詳細については、[リソースタイプ] テーブルの [条件キー] 列を参照してください。
Secrets Manager のアクション
Secrets Manager リソース
リソースタイプ | ARN | 条件キー |
---|---|---|
Secret |
arn:${Partition}:secretsmanager:${Region}:${Account}:secret:${SecretId}
|
Secrets Manager は、シークレットの名前の最後にダッシュと 6 つのランダムな英数字を加えることで、シークレット ARN の最後の部分を構成します。シークレットを削除した後に同じ名前の別のシークレットを作成すると、Secrets Manager が 6 つのランダムな文字を生成するため、この形式により、元のシークレットへのアクセス許可を持つユーザーが新しいシークレットに自動でアクセスできないようにすることができます。
シークレットの ARN は、シークレットの詳細ページにある Secrets Manager コンソールで、または DescribeSecret
を呼び出すことで見つけることができます。
条件キー
以下の表の文字列条件をアクセス許可ポリシーに含める場合、Secrets Manager の呼び出し元は、一致するパラメータを渡す必要があります。渡さない場合、アクセスが拒否されます。欠落しているパラメータの呼び出し元を拒否しないようにするには、条件演算子名の末尾に IfExists
を追加します (例: StringLikeIfExists
)。詳細については、「IAM JSON ポリシー要素: 条件演算子」を参照してください。
条件キー | 説明 | [Type] (タイプ) |
---|---|---|
aws:RequestTag/${TagKey} | ユーザーが Secrets Manager サービスに対して行うリクエストに含まれるキーによってアクセスをフィルタリングします。 | 文字列 |
aws:ResourceTag/${TagKey} | リソースに関連付けられたタグでアクセスをフィルタリングします | 文字列 |
aws:TagKeys | ユーザーが Secrets Manager サービスに行うリクエストに存在するすべてのタグキー名のリストに基づいて、アクセスをフィルタリングします。 | ArrayOfString |
secretsmanager:AddReplicaRegions | シークレットをレプリケートするリージョンのリストでアクセスをフィルタリングします。 | ArrayOfString |
secretsmanager:BlockPublicPolicy | リソースポリシーが広範なアクセスをブロックするかどうかで AWS アカウント アクセスをフィルタリングします | Bool |
secretsmanager:Description | リクエスト内の記述テキストによるアクセスをフィルタリングします。 | 文字列 |
secretsmanager:ForceDeleteWithoutRecovery | シークレットがリカバリウィンドウなしですぐに削除されるかどうかによりアクセスをフィルタリングします。 | Bool |
secretsmanager:ForceOverwriteReplicaSecret | 宛先リージョンで同じ名前のシークレットを上書きするかどうかでアクセスをフィルタリングします。 | Bool |
secretsmanager:KmsKeyId | リクエスト内の KMS キーの ARN によるアクセスをフィルタリングします。 | 文字列 |
secretsmanager:ModifyRotationRules | シークレットのローテーションルールを変更するかどうかに基づいて、アクセスをフィルタリングします。 | Bool |
secretsmanager:Name | リクエスト内のシークレットのフレンドリー名によるアクセスをフィルタリングします。 | 文字列 |
secretsmanager:RecoveryWindowInDays | Secrets Manager がシークレットを削除するまで待機する日数でアクセスをフィルタリングします。 | 数値 |
secretsmanager:ResourceTag/tag-key | タグキーおよび値のペアでアクセスをフィルタリングします。 | 文字列 |
secretsmanager:RotateImmediately | シークレットを直ちにローテーションするかどうかに基づいて、アクセスをフィルタリングします。 | Bool |
secretsmanager:RotationLambdaARN | リクエスト内のローテーション Lambda 関数の ARN によるアクセスをフィルタリングします。 | ARN |
secretsmanager:SecretId | リクエスト内の SecretID 値によるアクセスをフィルタリングします。 | ARN |
secretsmanager:SecretPrimaryRegion | シークレットが作成されたプライマリリージョンでアクセスをフィルタリングします | 文字列 |
secretsmanager:VersionId | リクエスト内のシークレットのバージョンの唯一の識別子でアクセスをフィルタリングします。 | 文字列 |
secretsmanager:VersionStage | リクエスト内のバージョンステージのリストでアクセスをフィルタリングします。 | 文字列 |
secretsmanager:resource/AllowRotationLambdaArn | シークレットに関連するローテーション Lambda 関数の ARN によるアクセスをフィルタリングします。 | ARN |
BlockPublicPolicy
条件を利用したシークレットへの広範なアクセスのブロック
アクション PutResourcePolicy
を許可するアイデンティティポリシーでは、BlockPublicPolicy: true
を使用することをお勧めします。この条件は、ポリシーが広範なアクセスを許可していない場合、ユーザーがリソースポリシーのみをシークレットにアタッチできることを意味します。
Secrets Manager は、Zelkova の自動推論を使用して、広範なアクセスのためのリソースポリシーを分析します。Zelkova の詳細については、 AWS セキュリティブログの「 が自動推論 AWS を使用して大規模なセキュリティを実現する方法
次の例は、BlockPublicPolicy
の使用方法を示しています。
{ "Version": "2012-10-17", "Statement": { "Effect": "Allow", "Action": "secretsmanager:PutResourcePolicy", "Resource": "
SecretId
", "Condition": { "Bool": { "secretsmanager:BlockPublicPolicy": "true" } } } }
IP アドレス条件
Secrets Manager へのアクセスを許可または拒否するポリシーステートメントで、IP アドレス条件の演算子または aws:SourceIp
条件キーを指定するときは、注意が必要です。例えば、企業ネットワークの IP アドレス範囲からのリクエストに AWS アクションを制限するポリシーをシークレットにアタッチすると、企業ネットワークからリクエストを呼び出す IAM ユーザーとしてのリクエストは期待どおりに機能します。ただし、Lambda 関数でローテーションを有効にする場合など、他のサービスがユーザーに代わってシークレットにアクセスできるようにすると、その関数は AWS-内部アドレス空間から Secrets Manager オペレーションを呼び出します。IP アドレスのフィルターがあるポリシーによって影響されたリクエストは失敗します。
また、リクエストが Amazon VPC エンドポイントから送信されている場合、aws:sourceIP
条件キーは効果が低下します。特定の VPC エンドポイントに対するリクエストを制限するには、VPC エンドポイントの条件 を使用します。
VPC エンドポイントの条件
特定の VPC または VPC エンドポイントからのリクエストに対するアクセスを許可または拒否するには、aws:SourceVpc
を使用して、指定された VPC からのリクエストに対するアクセスを制限するか、aws:SourceVpce
を使用して、指定された VPC エンドポイントからのリクエストに対するアクセスを制限します。「例: アクセス許可と VPC」を参照してください。
-
aws:SourceVpc
は、指定した VPC からのリクエストにアクセスを制限します。 -
aws:SourceVpce
は、指定した VPC エンドポイントからのリクエストにアクセスを制限します。
これらの条件キーをシークレットポリシーステートメントで使用し、Secrets Manager シークレットへのアクセスを許可または拒否すると、ユーザーに代わってシークレットへのアクセスに Secrets Manager を使用しているサービスへのアクセスを、意図せずに拒否してしまうことがあります。VPC 内のエンドポイントで実行できる AWS のサービスは、一部のみです。シークレットのリクエストを VPC または VPC エンドポイントに制限すると、サービスに設定されていないサービスからの Secrets Manager への呼び出しは失敗します。
「AWS Secrets Manager VPC エンドポイントの使用」を参照してください。