翻訳は機械翻訳により提供されています。提供された翻訳内容と英語版の間で齟齬、不一致または矛盾がある場合、英語版が優先します。

最小特権ポリシーを持つ暗号化された Amazon SQSキューのアクセス管理

Amazon を使用するとSQS、 (SSE) と統合されたサーバー側の暗号化 () を使用して、アプリケーション間で機密データを交換できますAWS Key Management Service KMS。Amazon SQSと の統合により AWS KMS、Amazon を保護するキーとSQS、他の AWS リソースを保護するキーを一元管理できます。

複数の AWS サービスは、Amazon にイベントを送信するイベントソースとして機能しますSQS。イベントソースが暗号化された Amazon SQSキューにアクセスできるようにするには、カスタマーマネージド AWS KMS キーを使用してキューを設定する必要があります。次に、キーポリシーを使用して、サービスに必要なメソッドの使用 AWS KMS APIを許可します。サービスには、キューがイベントを送信できるようにするためのアクセス認証のアクセス権限も必要です。これを実現するには、Amazon SQSポリシーを使用します。これは、Amazon SQSキューとそのデータへのアクセスを制御するために使用できるリソースベースのポリシーです。

以下のセクションでは、Amazon SQSポリシーと AWS KMS キーポリシーを使用して暗号化された Amazon SQSキューへのアクセスを制御する方法について説明します。このガイドのポリシーは、最小特権を達成するのに役立ちます。

このガイドでは、aws:SourceArn、、および aws:PrincipalOrgID グローバルIAM条件コンテキストキーを使用してaws:SourceAccount、リソースベースのポリシーが混乱した代理問題にどのように対処するかについても説明します。

概要

このトピックでは、キーポリシーと Amazon SQSキューポリシーを構築する方法を説明する一般的なユースケースについて説明します。このユースケースは次の画像に示されています。

この例では、メッセージプロデューサーは Amazon Simple Notification Service (SNS） トピックであり、暗号化された Amazon SQSキューにメッセージをファンアウトするように設定されています。メッセージコンシューマーは、AWS Lambda関数、Amazon Elastic Compute Cloud (EC2) インスタンス、AWS Fargateコンテナなどのコンピューティングサービスです。その後、Amazon SQSキューは、失敗したメッセージをデッドレターキュー (DLQ) に送信するように設定されます。これは、消費されていないメッセージを分離して処理が成功しなかった理由を特定DLQsできるため、アプリケーションまたはメッセージングシステムのデバッグに役立ちます。このトピックで定義されているソリューションでは、Lambda 関数などのコンピューティングサービスを使用して、Amazon SQSキューに保存されているメッセージを処理します。メッセージコンシューマーが仮想プライベートクラウド (VPC) にある場合、このガイドに含まれているDenyReceivingIfNotThroughVPCEポリシーステートメントにより、メッセージの受信をその特定の に制限できますVPC。

Amazon の最小特権キーポリシー SQS

このセクションでは、Amazon SQSキューの暗号化に使用するカスタマーマネージドキー AWS KMS の に必要な最小権限のアクセス許可について説明します。これらのアクセス許可により、最小特権を実装しながら、アクセスを目的のエンティティのみに制限できます。キーポリシーは、以下のポリシーステートメントで構成されている必要があります。詳細については以下で説明します。

AWS KMS キーへの管理者アクセス許可の付与

AWS KMS キーを作成するには、 AWS KMS キーのデプロイに使用するIAMロールに AWS KMS 管理者権限を付与する必要があります。これらの管理者権限は、以下の AllowKeyAdminPermissions ポリシーステートメントで定義されています。このステートメントを AWS KMS キーポリシーに追加するときは、必ず <admin-role ARN> キーのデプロイ、 AWS KMS キーの管理、 AWS KMS またはその両方に使用されるIAMロールの Amazon リソースネーム (ARN) を使用します。これは、デプロイパイプラインのIAMロールでも、組織内の組織の管理者ロールでもかまいませんAWS 。

{
  "Sid": "AllowKeyAdminPermissions",
  "Effect": "Allow",
  "Principal": {
    "AWS": [
      "<admin-role ARN>"
    ]
  },
  "Action": [
    "kms:Create*",
    "kms:Describe*",
    "kms:Enable*",
    "kms:List*",
    "kms:Put*",
    "kms:Update*",
    "kms:Revoke*",
    "kms:Disable*",
    "kms:Get*",
    "kms:Delete*",
    "kms:TagResource",
    "kms:UntagResource",
    "kms:ScheduleKeyDeletion",
    "kms:CancelKeyDeletion"
  ],
  "Resource": "*"
}

キーメタデータへの読み取り専用アクセスを付与する

他のIAMロールにキーメタデータへの読み取り専用アクセスを許可するには、キーポリシーに AllowReadAccessToKeyMetaDataステートメントを追加します。例えば、次のステートメントでは、監査目的でアカウント内のすべての AWS KMS キーを一覧表示できます。このステートメントは、 AWS ルートユーザーにキーメタデータへの読み取り専用アクセスを許可します。したがって、アイデンティティベースのポリシーに、 kms:Describe*、、および ステートメントに記載されているアクセス許可がある場合kms:Get*、アカウントのプリンIAMシパルはキーメタデータにアクセスできますkms:List*。必ず を置き換えてください <account-ID> 独自の情報。

{
  "Sid": "AllowReadAcesssToKeyMetaData",
  "Effect": "Allow",
  "Principal": {
    "AWS": [
      "arn:aws:iam::<accountID>:root"
    ]
  },
  "Action": [
    "kms:Describe*",
    "kms:Get*",
    "kms:List*"
  ],
  "Resource": "*"
}

キューにメッセージを公開SNSするアクセスSNSKMS許可を Amazon に付与する

Amazon SNSトピックが暗号化された Amazon SQSキューにメッセージを公開できるようにするには、 AllowSNSToSendToSQS ポリシーステートメントをキーポリシーに追加します。このステートメントは、 AWS KMS キーを使用して Amazon SQSキューに発行するアクセスSNS許可を Amazon に付与します。必ず を置き換えてください <account-ID> 独自の情報。

{
  "Sid": "AllowSNSToSendToSQS",
  "Effect": "Allow",
  "Principal": {
    "Service": [
      "sns.amazonaws.com"
    ]
  },
  "Action": [
    "kms:Decrypt",
    "kms:GenerateDataKey"
  ],
  "Resource": "*",
  "Condition": {
    "StringEquals": {
      "aws:SourceAccount": "<account-id>"
    }
  }
}

コンシューマーがキューからのメッセージを復号化することを許可する

次のAllowConsumersToReceiveFromTheQueueステートメントは、暗号化された Amazon SQSキューから受信したメッセージを復号するために必要なアクセス許可を Amazon SQS メッセージコンシューマーに付与します。ポリシーステートメントをアタッチするときは、<consumer's runtime role ARN> メッセージコンシューマーARNのIAMランタイムロール。

{
  "Sid": "AllowConsumersToReceiveFromTheQueue",
  "Effect": "Allow",
  "Principal": {
    "AWS": [
      "<consumer's execution role ARN>"
    ]
  },
  "Action": [
    "kms:Decrypt"
  ],
  "Resource": "*"
}

最小特権 Amazon SQSポリシー

このセクションでは、このガイドの対象となるユースケース (Amazon SNSから Amazon など) の最小特権の Amazon SQSキューポリシーについて説明しますSQS。定義されたポリシーは、Deny および Allow ステートメントの両方を組み合わせて使用することで、意図しないアクセスを防ぐように設計されています。Allow ステートメントは、目的の 1 つ以上のエンティティへのアクセスを許可します。Deny ステートメントは、ポリシー条件内の目的のエンティティを除外しながら、他の意図しないエンティティが Amazon SQSキューにアクセスできないようにします。

Amazon SQSポリシーには、以下に詳しく説明する以下のステートメントが含まれています。

Amazon SQS管理アクセス許可を制限する

次のRestrictAdminQueueActionsポリシーステートメントは、Amazon SQS管理アクセス許可を、キューのデプロイIAM、キューの管理、またはその両方に使用するロールのみに制限します。必ず <placeholder values> 独自の情報。Amazon SQSキューのデプロイに使用されるIAMロールARNの と、Amazon SQS管理アクセス許可を持つ必要がある管理者ロールARNsの を指定します。

{
  "Sid": "RestrictAdminQueueActions",
  "Effect": "Deny",
  "Principal": {
    "AWS": "*"
  },
  "Action": [
    "sqs:AddPermission",
    "sqs:DeleteQueue",
    "sqs:RemovePermission",
    "sqs:SetQueueAttributes"
  ],
  "Resource": "<SQS Queue ARN>",
  "Condition": {
    "StringNotLike": {
      "aws:PrincipalARN": [
        "arn:aws:iam::<account-id>:role/<deployment-role-name>",
        "<admin-role ARN>"
      ]
    }
  }
}

指定された組織からの Amazon SQSキューアクションを制限する

Amazon SQSリソースを外部アクセス (AWS 組織外のエンティティによるアクセス) から保護するには、次のステートメントを使用します。このステートメントは、 で指定した組織への Amazon SQSキューアクセスを制限しますCondition。必ず を置き換えてください <SQS queue ARN> Amazon SQSキューのデプロイに使用されるIAMロールARNの と、<org-id>、組織 ID を含む。

{
  "Sid": "DenyQueueActionsOutsideOrg",
  "Effect": "Deny",
  "Principal": {
    "AWS": "*"
  },
  "Action": [
    "sqs:AddPermission",
    "sqs:ChangeMessageVisibility",
    "sqs:DeleteQueue",
    "sqs:RemovePermission",
    "sqs:SetQueueAttributes",
    "sqs:ReceiveMessage"
  ],
  "Resource": "<SQS queue ARN>",
  "Condition": {
    "StringNotEquals": {
      "aws:PrincipalOrgID": [
        "<org-id>"
      ]
    }
  }
}

コンシューマーに Amazon アクセスSQS許可を付与する

Amazon SQSキューからメッセージを受信するには、メッセージコンシューマーに必要なアクセス許可を提供する必要があります。次のポリシーステートメントは、指定したコンシューマーに、Amazon SQSキューからのメッセージを消費するために必要なアクセス許可を付与します。Amazon SQSポリシーに ステートメントを追加するときは、必ず を置き換えてください。<consumer's IAM runtime role ARN> コンシューマーが使用するIAMランタイムロールARNの を使用する。<SQS queue ARN>、Amazon SQSキューのデプロイに使用されるIAMロールARNの 。

{
  "Sid": "AllowConsumersToReceiveFromTheQueue",
  "Effect": "Allow",
  "Principal": {
    "AWS": "<consumer's IAM execution role ARN>"
  },
  "Action": [
    "sqs:ChangeMessageVisibility",
    "sqs:DeleteMessage",
    "sqs:GetQueueAttributes",
    "sqs:ReceiveMessage"
  ],
  "Resource": "<SQS queue ARN>"
}
				
			

他のエンティティが Amazon SQSキューからメッセージを受信しないようにするには、Amazon SQSキューポリシーに DenyOtherConsumersFromReceivingステートメントを追加します。このステートメントは、メッセージの消費を指定したコンシューマーに制限します。つまり、そのコンシューマーの ID アクセス許可によってアクセスが許可される場合でも、他のコンシューマーにはアクセスできなくなります。必ず を置き換えてください <SQS queue ARN> また、<consumer’s runtime role ARN> 独自の情報。

{
  "Sid": "DenyOtherConsumersFromReceiving",
  "Effect": "Deny",
  "Principal": {
    "AWS": "*"
  },
  "Action": [
    "sqs:ChangeMessageVisibility",
    "sqs:DeleteMessage",
    "sqs:ReceiveMessage"
  ],
  "Resource": "<SQS queue ARN>",
  "Condition": {
    "StringNotLike": {
      "aws:PrincipalARN": "<consumer's execution role ARN>"
    }
  }
}		
			

転送時の暗号化を強制する

次のDenyUnsecureTransportポリシーステートメントでは、コンシューマーとプロデューサーが安全なチャネル (TLS 接続) を使用して Amazon SQSキューからメッセージを送受信することを強制しています。必ず を置き換えてください <SQS queue ARN> Amazon SQSキューのデプロイに使用されるIAMロールARNの 。

{
  "Sid": "DenyUnsecureTransport",
  "Effect": "Deny",
  "Principal": {
    "AWS": "*"
  },
  "Action": [
    "sqs:ReceiveMessage",
    "sqs:SendMessage"
  ],
  "Resource": "<SQS queue ARN>",
  "Condition": {
    "Bool": {
      "aws:SecureTransport": "false"
    }
  }
}
				
			

メッセージの送信を特定の Amazon SNSトピックに制限する

次のAllowSNSToSendToTheQueueポリシーステートメントは、指定された Amazon SNSトピックが Amazon SQSキューにメッセージを送信することを許可します。必ず を置き換えてください <SQS queue ARN> Amazon SQSキューのデプロイに使用されるIAMロールARNの を使用する。<SNS topic ARN>、Amazon SNSトピック ARN。

{
  "Sid": "AllowSNSToSendToTheQueue",
  "Effect": "Allow",
  "Principal": {
    "Service": "sns.amazonaws.com"
  },
  "Action": "sqs:SendMessage",
  "Resource": "<SQS queue ARN>",
  "Condition": {
    "ArnLike": {
      "aws:SourceArn": "<SNS topic ARN>"
    }
  }
}				
			

次の DenyAllProducersExceptSNSFromSending ポリシーステートメントは、他のプロデューサーがキューにメッセージを送信できないようにします。置換 <SQS queue ARN> また、<SNS topic ARN> 独自の情報。

{
  "Sid": "DenyAllProducersExceptSNSFromSending",
  "Effect": "Deny",
  "Principal": {
    "AWS": "*"
  },
  "Action": "sqs:SendMessage",
  "Resource": "<SQS queue ARN>",
  "Condition": {
    "ArnNotLike": {
      "aws:SourceArn": "<SNS topic ARN>"
    }
  }
}
				
			

（オプション) メッセージ受信を特定のVPCエンドポイントに制限する

メッセージの受信を特定のVPCエンドポイント のみに制限するには、Amazon SQSキューポリシーに次のポリシーステートメントを追加します。このステートメントは、メッセージが目的のVPCエンドポイントからのものでない限り、メッセージコンシューマーがキューからメッセージを受信することを防ぎます。置換 <SQS queue ARN> Amazon SQSキューのデプロイに使用されるIAMロールARNの を使用する。<vpce_id> VPC エンドポイントの ID。

{
  "Sid": "DenyReceivingIfNotThroughVPCE",
  "Effect": "Deny",
  "Principal": "*",
  "Action": [
    "sqs:ReceiveMessage"
  ],
  "Resource": "<SQS queue ARN>",
  "Condition": {
    "StringNotEquals": {
      "aws:sourceVpce": "<vpce id>"
    }
  }
}

デッドレターキューの Amazon SQSポリシーステートメント

アクセスポリシーに、ステートメント ID で識別される次のDLQポリシーステートメントを追加します。

DLQ アクセスポリシーに前述のポリシーステートメントを追加するだけでなく、次のセクションで説明するように、Amazon SQSキューへのメッセージ送信を制限するステートメントも追加する必要があります。

Amazon SQSキューへのメッセージ送信を制限する

同じアカウントからの Amazon SQSキューのみへのアクセスを制限するには、次のDenyAnyProducersExceptSQSポリシーステートメントをDLQキューポリシーに追加します。このステートメントは、メインキューを作成するDLQ前に をデプロイする必要があるため、特定のキューへのメッセージ送信を制限しないため、 を作成するSQSARNときに Amazon がわかりませんDLQ。アクセスを 1 つの Amazon SQSキューのみに制限する必要がある場合は、Amazon SQSソースキューARNの Conditionを使用して aws:SourceArn 内の を、それがわかっている場合に変更します。

{
  "Sid": "DenyAnyProducersExceptSQS",
  "Effect": "Deny",
  "Principal": {
    "AWS": "*"
  },
  "Action": "sqs:SendMessage",
  "Resource": "<SQS DLQ ARN>",
  "Condition": {
    "ArnNotLike": {
      "aws:SourceArn": "arn:aws:sqs:<region>:<account-id>:*"
    }
  }
}

サービス間での混乱した使節問題を防止する

「混乱した代理」問題は、アクションを実行するためのアクセス許可を持たないエンティティが、より特権のあるエンティティにアクションの実行を強制できてしまう場合に生じる、セキュリティ上の問題です。これを防ぐために、 は、アカウント内のリソースへのアクセスをサードパーティー (クロスアカウント) またはその他の AWS サービス (クロスサービス) に提供する場合に、アカウントを保護するのに役立つツール AWS を提供します。このセクションのポリシーステートメントは、サービス間の混乱した使節の問題を防止するのに役立ちます。

サービス間でのなりすましは、あるサービス (呼び出し元サービス) が、別のサービス (呼び出し対象サービス) を呼び出すときに発生する可能性があります。呼び出し元サービスが操作され、それ自体のアクセス許可を通じて、別の顧客のリソースに対して本来アクセス許可が付与されるべきではない形で働きかけが行われることがあります。この問題から保護するために、この記事で定義されているリソースベースのポリシーではaws:SourceArn、、aws:SourceAccount、および aws:PrincipalOrgID グローバルIAM条件コンテキストキーを使用します。これにより、サービスが持つアクセス許可が、 AWS Organizations 内の特定のリソース、特定のアカウント、または特定の組織に制限されます。

IAM Access Analyzer を使用してクロスアカウントアクセスを確認する

AWS IAM Access Analyzer を使用して、Amazon SQSキューポリシーと AWS KMS キーポリシーを確認し、Amazon SQSキューまたは AWS KMS キーが外部エンティティへのアクセスを許可すると警告できます。IAM Access Analyzer は、組織内のリソースと、信頼ゾーン外のエンティティと共有されているアカウントを識別するのに役立ちます。この信頼ゾーンは、IAMAccess Analyzer を有効にするときに指定する AWS Organizations 内の AWS アカウントまたは組織です。

IAM Access Analyzer は、論理ベースの推論を使用して AWS 環境内のリソースベースのポリシーを分析することで、外部プリンシパルと共有されているリソースを識別します。信頼ゾーン外で共有されているリソースのインスタンスごとに、Access Analyzer は結果を生成します。結果には、アクセスと付与される外部プリンシパルに関する情報が含まれます。結果を確認して、アクセスが意図的で安全なものであるか、またはアクセスが意図しないものであるか、セキュリティ上のリスクであるかを判断します。意図しないアクセスについては、影響を受けるポリシーを確認して修正します。Access Analyzer が AWS リソースへの意図しないアクセスを識別する方法 AWS IAMの詳細については、このブログ記事を参照してください。

Access Analyzer の詳細については AWS IAM、AWS IAM「Access Analyzer ドキュメント」を参照してください。