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

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

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

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

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

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

概要

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

この例では、メッセージプロデューサーは Amazon Simple Notification Service (SNS) トピックで、暗号化された Amazon SQS キューにメッセージをファンアウトするように設定されています。メッセージコンシューマーは、AWS Lambda 関数、Amazon Elastic Compute Cloud (EC2) インスタンス、AWS Fargate コンテナなどのコンピューティングサービスです。Amazon SQS キューは、失敗したメッセージをデッドレターキュー (DLQ) に送信するように設定されます。DLQ は、未使用のメッセージを分離して、処理が成功しない理由を調べることができるため、アプリケーションやメッセージングシステムのデバッグに役立ちます。このトピックで定義されているソリューションでは、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 Organizations 内の組織の管理者ロールでもかまいません。

{
  "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 ルートユーザーにキーメタデータへの読み取り専用アクセスを許可します。したがって、アカウント内の IAM プリンシパルは、その ID ベースのポリシーに次のステートメント (kms:Describe*、kms:Get*、kms:List*) に記載されているアクセス権限が付与されていれば、キーメタデータにアクセスできます。<account-ID> をユーザー自身の情報に必ず置き換えます。

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

キューにメッセージを発行するために、Amazon SNS KMS のアクセス許可を Amazon SNS に付与する

Amazon SNS トピックが、暗号化された Amazon SQS キューにメッセージを発行できるようにするには、AllowSNSToSendToSQS ポリシーステートメントをキーポリシーに追加します。このステートメントは、 AWS KMS キーを使用して Amazon SNSAmazon SQSに付与します。<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> をメッセージコンシューマーの IAM ランタイムロール ARN に置き換えます。

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

Amazon SQS の最小特権ポリシー

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

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

Amazon SQS の管理権限を制限する

次の RestrictAdminQueueActions ポリシーステートメントは、Amazon SQS の管理権限を、キューのデプロイ、キューの管理、またはその両方に使用する 1 つまたは複数の IAM ロールのみに制限します。<placeholder values> をユーザー自身の情報に必ず置き換えます。Amazon SQS キューのデプロイに使用する IAM ロールの ARN と、Amazon SQS 管理権限が必要なすべての管理者ロールの ARN を指定します。

{
  "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 キューのみへのアクセスを制限するには、DLQ キューポリシーに次の DenyAnyProducersExceptSQS ポリシーステートメントを追加します。DLQ はメインキューを作成する前にデプロイする必要があるため、このステートメントでは特定のキューへのメッセージ送信を制限しません。DLQ の作成時に Amazon SQS ARN を知ることができないためです。1 つの Amazon SQS キューのみにアクセスを制限する必要がある場合、Condition 内の aws:SourceArn を Amazon SQS ソースキューの ARN で変更します。

{
  "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 を提供します。このセクションのポリシーステートメントは、サービス間の混乱した使節の問題を防止するのに役立ちます。

サービス間でのなりすましは、1 つのサービス (呼び出し元サービス) が、別のサービス (呼び出し対象サービス) を呼び出すときに発生する可能性があります。呼び出し元サービスが操作され、それ自体のアクセス許可を通じて、別の顧客のリソースに対して本来アクセス許可が付与されるべきではない形で働きかけが行われることがあります。この問題を防ぐため、この記事で定義されているリソースベースのポリシーでは、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 の機能は、信頼ゾーン外のエンティティと共有されている組織とアカウントのリソースを識別するのに役立ちます。この信頼ゾーンは、IAM Access Analyzer を有効にするときに指定する AWS アカウントまたは AWS Organizations 内の組織とすることができます。

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

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