기계 번역으로 제공되는 번역입니다. 제공된 번역과 원본 영어의 내용이 상충하는 경우에는 영어 버전이 우선합니다.
# Amazon SQS의 Identity and Access Management
AWS Identity and Access Management (IAM)는 관리자가 AWS 리소스에 대한 액세스를 안전하게 제어하는 데 도움이 AWS 서비스 되는 입니다. IAM 관리자는 어떤 사용자가 Amazon SQS 리소스를 사용할 수 있도록 인증**(로그인)되고 권한이 부여**(권한 있음)될 수 있는지 제어합니다. IAM은 추가 비용 없이 사용할 수 AWS 서비스 있는 입니다.
## 대상
AWS Identity and Access Management (IAM)를 사용하는 방법은 역할에 따라 다릅니다.
+ **서비스 사용자** - 기능에 액세스할 수 없는 경우 관리자에게 권한 요청(참조[Amazon Simple Queue Service ID 및 액세스 문제 해결](security_iam_troubleshoot.md))
+ **서비스 관리자** - 사용자 액세스 결정 및 권한 요청 제출([Amazon Simple Queue Service가 IAM으로 작동하는 방식](security_iam_service-with-iam.md) 참조)
+ **IAM 관리자** - 액세스를 관리하기 위한 정책 작성([정책 모범 사례](sqs-basic-examples-of-iam-policies.md#security_iam_id-based-policy-examples) 참조)
## ID를 통한 인증
인증은 자격 증명 자격 증명을 AWS 사용하여에 로그인하는 방법입니다. AWS 계정 루트 사용자, IAM 사용자 또는 IAM 역할을 수임하여 인증해야 합니다.
AWS IAM Identity Center (IAM Identity Center), Single Sign-On 인증 또는 Google/Facebook 자격 증명과 같은 자격 증명 소스의 자격 증명을 사용하여 페더레이션 자격 증명으로 로그인할 수 있습니다. 로그인하는 방법에 대한 자세한 내용은 *AWS Sign-In 사용 설명서*의 [AWS 계정에 로그인하는 방법](https://docs.aws.amazon.com/signin/latest/userguide/how-to-sign-in.html) 섹션을 참조하세요.
프로그래밍 방식 액세스를 위해는 요청에 암호화 방식으로 서명할 수 있는 SDK 및 CLI를 AWS 제공합니다. 자세한 내용은 *IAM 사용 설명서*의 [API 요청용AWS Signature Version 4](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_sigv.html) 섹션을 참조하세요.
### AWS 계정 루트 사용자
를 생성할 때 모든 AWS 서비스 및 리소스에 대한 완전한 액세스 권한이 있는 AWS 계정 *theroot 사용자*라는 하나의 로그인 자격 증명으로 AWS 계정시작합니다. 일상적인 태스크에 루트 사용자를 사용하지 않을 것을 강력히 권장합니다. 루트 사용자 자격 증명이 필요한 작업은 *IAM 사용 설명서*의 [루트 사용자 자격 증명이 필요한 작업](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_root-user.html#root-user-tasks) 섹션을 참조하세요.
### 페더레이션 ID
가장 좋은 방법은 인간 사용자에게 자격 증명 공급자와의 페더레이션을 사용하여 임시 자격 증명을 AWS 서비스 사용하여에 액세스하도록 요구하는 것입니다.
*페더레이션 자격 증명*은 엔터프라이즈 디렉터리, 웹 자격 증명 공급자 또는 자격 증명 소스의 자격 증명을 AWS 서비스 사용하여 Directory Service 에 액세스하는 사용자입니다. 페더레이션 ID는 임시 자격 증명을 제공하는 역할을 수임합니다.
중앙 집중식 액세스 관리를 위해 AWS IAM Identity Center를 추천합니다. 자세한 정보는 *AWS IAM Identity Center 사용 설명서*의 [What is IAM Identity Center?](https://docs.aws.amazon.com/singlesignon/latest/userguide/what-is.html)를 참조하세요.
### IAM 사용자 및 그룹
*[IAM 사용자](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_users.html)*는 단일 개인 또는 애플리케이션에 대한 특정 권한을 가진 ID입니다. 장기 자격 증명이 있는 IAM 사용자 대신 임시 자격 증명을 사용하는 것이 좋습니다. 자세한 내용은 *IAM 사용 설명서*의 자격 [증명 공급자와의 페더레이션을 사용하여 임시 자격 증명을 AWS 사용하여에 액세스하도록 인간 사용자에게 요구](https://docs.aws.amazon.com/IAM/latest/UserGuide/best-practices.html#bp-users-federation-idp)하기를 참조하세요.
[https://docs.aws.amazon.com/IAM/latest/UserGuide/id_groups.html](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_groups.html)은 IAM 사용자 모음을 지정하고 대규모 사용자 집합에 대한 관리 권한을 더 쉽게 만듭니다. 자세한 내용은 *IAM 사용 설명서*의 [IAM 사용자 사용 사례](https://docs.aws.amazon.com/IAM/latest/UserGuide/gs-identities-iam-users.html) 섹션을 참조하세요.
### IAM 역할
*[IAM 역할](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles.html)*은 임시 자격 증명을 제공하는 특정 권한이 있는 자격 증명입니다. [사용자에서 IAM 역할(콘솔)로 전환하거나 또는 API 작업을 호출하여 역할을](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles_use_switch-role-console.html) 수임할 수 있습니다. AWS CLI AWS 자세한 내용은 *IAM 사용 설명서*의 [역할 수임 방법](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles_manage-assume.html)을 참조하세요.
IAM 역할은 페더레이션 사용자 액세스, 임시 IAM 사용자 권한, 교차 계정 액세스, 교차 서비스 액세스 및 Amazon EC2에서 실행되는 애플리케이션에 유용합니다. 자세한 내용은 *IAM 사용 설명서*의 [교차 계정 리소스 액세스](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies-cross-account-resource-access.html)를 참조하세요.
## 정책을 사용하여 액세스 관리
정책을 AWS 생성하고 자격 증명 또는 리소스에 연결하여 AWS 에서 액세스를 제어합니다. 정책은 자격 증명 또는 리소스와 연결될 때 권한을 정의합니다.는 보안 주체가 요청할 때 이러한 정책을 AWS 평가합니다. 대부분의 정책은에 JSON 문서 AWS 로 저장됩니다. JSON 정책 문서에 대한 자세한 내용은 *IAM 사용 설명서*의 [JSON 정책 개요](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies.html#access_policies-json) 섹션을 참조하세요.
정책을 사용하여 관리자는 어떤 **보안 주체**가 어떤 **리소스**에 대해 어떤 **조건**에서 **작업**을 수행할 수 있는지 정의하여 누가 무엇을 액세스할 수 있는지 지정합니다.
기본적으로 사용자 및 역할에는 어떠한 권한도 없습니다. IAM 관리자는 IAM 정책을 생성하고 사용자가 수임할 수 있는 역할에 추가합니다. IAM 정책은 작업을 수행하기 위해 사용하는 방법과 관계없이 작업에 대한 권한을 정의합니다.
### ID 기반 정책
ID 기반 정책은 ID(사용자, 사용자 그룹 또는 역할)에 연결하는 JSON 권한 정책 문서입니다. 이러한 정책은 자격 증명이 수행할 수 있는 작업, 대상 리소스 및 이에 관한 조건을 제어합니다. ID 기반 정책을 생성하는 방법을 알아보려면 *IAM 사용 설명서*에서 [고객 관리형 정책으로 사용자 지정 IAM 권한 정의](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies_create.html)를 참조하세요.
ID 기반 정책은 *인라인 정책*(단일 ID에 직접 포함) 또는 *관리형 정책*(여러 ID에 연결된 독립 실행형 정책)일 수 있습니다. 관리형 정책 또는 인라인 정책을 선택하는 방법을 알아보려면 *IAM 사용 설명서*의 [관리형 정책 및 인라인 정책 중에서 선택](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies-choosing-managed-or-inline.html) 섹션을 참조하세요.
### 리소스 기반 정책
리소스 기반 정책은 리소스에 연결하는 JSON 정책 설명서입니다. 예를 들어 IAM *역할 신뢰 정책* 및 Amazon S3 *버킷 정책*이 있습니다. 리소스 기반 정책을 지원하는 서비스에서 서비스 관리자는 이러한 정책을 사용하여 특정 리소스에 대한 액세스를 통제할 수 있습니다. 리소스 기반 정책에서 [보안 주체를 지정](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_policies_elements_principal.html)해야 합니다.
리소스 기반 정책은 해당 서비스에 있는 인라인 정책입니다. 리소스 기반 정책에서는 IAM의 AWS 관리형 정책을 사용할 수 없습니다.
### 기타 정책 유형
AWS 는 보다 일반적인 정책 유형에서 부여한 최대 권한을 설정할 수 있는 추가 정책 유형을 지원합니다.
+ **권한 경계** - ID 기반 정책에서 IAM 엔터티에 부여할 수 있는 최대 권한을 설정합니다. 자세한 정보는 *IAM 사용 설명서*의 [IAM 엔터티의 권한 범위](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies_boundaries.html)를 참조하세요.
+ **서비스 제어 정책(SCP)** - AWS Organizations내 조직 또는 조직 단위에 대한 최대 권한을 지정합니다. 자세한 내용은AWS Organizations 사용 설명서의 [서비스 제어 정책](https://docs.aws.amazon.com/organizations/latest/userguide/orgs_manage_policies_scps.html)을 참조하세요.**
+ **리소스 제어 정책(RCP)** – 계정의 리소스에 사용할 수 있는 최대 권한을 설정합니다. 자세한 내용은 *AWS Organizations 사용 설명서*의 [리소스 제어 정책(RCP)](https://docs.aws.amazon.com/organizations/latest/userguide/orgs_manage_policies_rcps.html)을 참조하세요.
+ **세션 정책** – 역할 또는 페더레이션 사용자에 대해 임시 세션을 프로그래밍 방식으로 생성할 때 파라미터로 전달하는 고급 정책입니다. 자세한 내용은 *IAM 사용 설명서*의 [세션 정책](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies.html#policies_session)을 참조하세요.
### 여러 정책 유형
여러 정책 유형이 요청에 적용되는 경우, 결과 권한은 이해하기가 더 복잡합니다. 에서 여러 정책 유형이 관련될 때 요청을 허용할지 여부를 AWS 결정하는 방법을 알아보려면 *IAM 사용 설명서*의 [정책 평가 로직](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_policies_evaluation-logic.html)을 참조하세요.
# Amazon SQS의 액세스 관리 개요
모든 AWS 리소스는에서 소유하며 AWS 계정, 리소스를 생성하거나 액세스할 수 있는 권한은 권한 정책에 의해 관리됩니다. 계정 관리자는 IAM 자격 증명(즉, 사용자, 그룹, 역할)에 권한 정책을 연결할 수 있고, 일부 서비스(예: Amazon SQS)에서는 리소스에 대한 권한 정책 연결도 지원합니다.
**참고**
*계정 관리자* 또는 관리자 사용자는 관리자 권한이 있는 사용자입니다. 자세한 설명은 *IAM 사용자 가이드*의 [IAM 모범 사례](https://docs.aws.amazon.com/IAM/latest/UserGuide/best-practices.html) 섹션을 참조하세요.
권한을 부여하려면 권한을 부여 받을 사용자, 권한 대상이 되는 리소스, 이 리소스에서 허용할 특정 작업을 지정합니다.
## Amazon Simple Queue Service 리소스 및 작업
Amazon SQS에서 유일한 리소스는 대기열**입니다. 정책에서 Amazon 리소스 이름(ARN)을 사용하여 정책이 적용되는 리소스를 식별합니다. 다음 리소스에는 연결된 고유한 ARN이 있습니다.
| 리소스 유형 | ARN 형식 |
| --- | --- |
| 대기열 | arn:aws:sqs:region:account\$1id:queue\$1name |
다음은 대기열 ARN 형식의 몇 가지 예입니다.
+ AWS 계정 123456789012에 속하는 미국 동부(오하이오) 리전`my_queue`에 있는 라는 대기열의 ARN:
```
arn:aws:sqs:us-east-2:123456789012:my_queue
```
+ 다음은 Amazon SQS가 지원하는 여러 리전 각각에서 `my_queue`라고 하는 대기열의 ARN입니다.
```
arn:aws:sqs:*:123456789012:my_queue
```
+ 다음은 `*` 또는 `?`를 대기열 이름에서 와일드카드로 사용하는 ARN입니다. 다음 예제에서 ARN은 `my_prefix_`로 시작하는 모든 대기열과 일치합니다.
```
arn:aws:sqs:*:123456789012:my_prefix_*
```
[https://docs.aws.amazon.com/AWSSimpleQueueService/latest/APIReference/API_GetQueueAttributes.html](https://docs.aws.amazon.com/AWSSimpleQueueService/latest/APIReference/API_GetQueueAttributes.html) 작업을 호출하여 기존 대기열의 ARN 값을 가져올 수 있습니다. `QueueArn` 속성 값은 대기열의 ARN입니다. ARN에 대한 자세한 내용은 **IAM 사용 설명서의 [IAM ARN](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_identifiers.html#identifiers-arns) 단원을 참조하세요.
Amazon SQS는 대기열 리소스를 사용하는 여러 작업을 제공합니다. 자세한 내용은 [Amazon SQS API 권한: 작업 및 리소스 참조](sqs-api-permissions-reference.md) 단원을 참조하십시오.
## 리소스 소유권 이해
는 누가 리소스를 생성했는지에 관계없이 계정에서 생성된 리소스를 AWS 계정 소유합니다. 특히, 리소스 소유자는 리소스 생성 요청을 인증하는 **보안 주체 엔터티(즉, 루트 계정, 사용자 또는 IAM 역할)의 AWS 계정 입니다. 다음 예제에서는 이러한 작동 방법을 설명합니다.
+ 의 루트 계정 자격 증명을 사용하여 Amazon SQS 대기열을 AWS 계정 생성하는 경우 AWS 계정 는 리소스의 소유자입니다(Amazon SQS에서 리소스는 Amazon SQS 대기열).
+ 에서 사용자를 생성하고 사용자에게 대기열을 생성할 수 있는 권한을 AWS 계정 부여하면 사용자가 대기열을 생성할 수 있습니다. 하지만 (사용자가 속한) AWS 계정 은 대기열 리소스를 소유합니다.
+ 에서 Amazon SQS 대기열을 생성할 권한이 AWS 계정 있는 IAM 역할을 생성하는 경우 해당 역할을 수임할 수 있는 사람은 누구나 대기열을 생성할 수 있습니다. AWS 계정 (역할이 속한)가 대기열 리소스를 소유합니다.
## 리소스 액세스 관리
**권한 정책은 계정에 부여된 권한을 설명합니다. 다음 섹션에서는 권한 정책을 생성하는 데 사용할 수 있는 옵션에 대해 설명합니다.
**참고**
이 섹션에서는 Amazon SQS의 맥락에서 IAM을 사용하는 방법에 대해 설명하며, IAM 서비스에 대한 자세한 내용은 다루지 않습니다. IAM 설명서 전체 내용은 *IAM 사용 설명서*의 [IAM이란 무엇입니까?](https://docs.aws.amazon.com/IAM/latest/UserGuide/introduction.html)를 참조하세요. IAM 정책 구문과 설명에 대한 자세한 내용은 *IAM 사용자 안내서*의 [AWS IAM 정책 참조](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_policies.html)를 참조하세요.
IAM 자격 증명에 연결된 정책을 *자격 증명 기반 정책*(IAM 정책)이라 하고, 리소스에 연결된 정책을 *리소스 기반 정책*이라고 합니다.
### ID 기반 정책
사용자에게 Amazon SQS 대기열 권한을 부여하는 방법에는 Amazon SQS 정책 시스템을 사용하는 방법과 IAM 정책 시스템을 사용하는 방법이 있습니다. 두 시스템 중 하나 또는 둘 다를 사용하여 정책을 사용자 또는 역할에 연결할 수 있습니다. 대다수의 경우에 시스템을 사용하여 같은 결과를 얻을 수 있습니다. 예를 들면, 다음을 수행할 수 있습니다.
+ **계정 내 사용자 또는 그룹에 권한 정책 연결** - Amazon SQS 대기열 생성 권한을 사용자에게 부여하려면, 권한 정책을 사용자 또는 사용자가 속한 그룹에 연결합니다.
+ **다른의 사용자에게 권한 정책 연결 AWS 계정** - 다른의 사용자에게 권한 정책을 연결하여 Amazon SQS 대기열과 상호 작용 AWS 계정 할 수 있도록 할 수 있습니다. 그러나 다음 작업에는 교차 계정 권한이 적용되지 않습니다.
다음 작업에는 교차 계정 권한이 적용되지 않습니다.
+ `[AddPermission](https://docs.aws.amazon.com/AWSSimpleQueueService/latest/APIReference/API_AddPermission.html)`
+ `[CancelMessageMoveTask](https://docs.aws.amazon.com/AWSSimpleQueueService/latest/APIReference/API_CancelMessageMoveTask.html)`
+ `[CreateQueue](https://docs.aws.amazon.com/AWSSimpleQueueService/latest/APIReference/API_CreateQueue.html)`
+ `[DeleteQueue](https://docs.aws.amazon.com/AWSSimpleQueueService/latest/APIReference/API_DeleteQueue.html)`
+ `[ListMessageMoveTask](https://docs.aws.amazon.com/AWSSimpleQueueService/latest/APIReference/API_ListMessageMoveTasks.html)`
+ `[ListQueues](https://docs.aws.amazon.com/AWSSimpleQueueService/latest/APIReference/API_ListQueues.html)`
+ `[ListQueueTags](https://docs.aws.amazon.com/AWSSimpleQueueService/latest/APIReference/API_ListQueueTags.html)`
+ `[RemovePermission](https://docs.aws.amazon.com/AWSSimpleQueueService/latest/APIReference/API_RemovePermission.html)`
+ `[SetQueueAttributes](https://docs.aws.amazon.com/AWSSimpleQueueService/latest/APIReference/API_SetQueueAttributes.html)`
+ `[StartMessageMoveTask](https://docs.aws.amazon.com/AWSSimpleQueueService/latest/APIReference/API_StartMessageMoveTask.html)`
+ `[TagQueue](https://docs.aws.amazon.com/AWSSimpleQueueService/latest/APIReference/API_TagQueue.html)`
+ `[UntagQueue](https://docs.aws.amazon.com/AWSSimpleQueueService/latest/APIReference/API_UntagQueue.html)`
이러한 작업에 대한 액세스 권한을 부여하려면 Amazon SQS 대기열을 소유한 동일한 것과 동일한 AWS 계정 에 사용자가 속해 있어야 합니다.
+ **역할에 권한 정책 연결(교차 계정 권한 부여)** - SQS 대기열에 교차 계정 권한을 부여하려면 IAM 정책과 리소스 기반 정책을 둘 다 결합해야 합니다.
1. **계정 A**(대기열 소유)에서:
+ SQS 대기열에 **리소스 기반 정책**을 연결합니다. 이 정책은 **계정 B**의 위탁자(예: IAM 역할)에게 필요한 권한(예: [https://docs.aws.amazon.com/AWSSimpleQueueService/latest/APIReference/API_SendMessage.html](https://docs.aws.amazon.com/AWSSimpleQueueService/latest/APIReference/API_SendMessage.html), [https://docs.aws.amazon.com/AWSSimpleQueueService/latest/APIReference/API_ReceiveMessage.html](https://docs.aws.amazon.com/AWSSimpleQueueService/latest/APIReference/API_ReceiveMessage.html))을 명시적으로 부여해야 합니다.
1. **계정 A**에서 IAM 역할을 생성합니다.
+ **계정 B** 또는 AWS 서비스 가 역할을 수임하도록 허용하는 **신뢰 정책**
**참고**
AWS 서비스 (예: Lambda 또는 EventBridge)가 역할을 수임하도록 하려면 신뢰 정책에 서비스 보안 주체(예: lambda.amazonaws.com)를 지정합니다.
+ 수임된 역할에 대기열과 상호 작용할 수 있는 권한을 부여하는 **ID 기반 정책**
1. **계정 B**에서 **계정 A**의 역할을 수임할 수 있는 권한을 부여합니다.
교차 계정 위탁자를 허용하도록 대기열의 액세스 정책을 구성해야 합니다. IAM ID 기반 정책만으로는 SQS 대기열에 대한 교차 계정 액세스에 충분하지 않습니다.
IAM을 사용하여 권한을 위임하는 방법에 대한 자세한 내용은 *IAM 사용자 안내서*의 [액세스 관리](https://docs.aws.amazon.com/IAM/latest/UserGuide/access.html)를 참조하세요.
Amazon SQS가 IAM 정책을 사용하는 동안에는 자체 정책 인프라를 보유합니다. 대기열과 함께 Amazon SQS 정책을 사용하여 대기열에 액세스할 수 있는 AWS 계정을 지정할 수 있습니다. 액세스 및 조건 유형을 지정할 수 있습니다(예: 2010년 12월 31일 이전에 요청한 경우 `SendMessage`, `ReceiveMessage`를 사용할 권한을 부여하는 조건). 권한을 부여할 수 있는 특정 작업은 전체 Amazon SQS 작업 목록의 하위 집합입니다. Amazon SQS 정책을 작성하고 `*`를 지정하여 "모든 Amazon SQS 작업을 허용"하도록 지정하면 이것은 사용자가 이 하위 집합에서 모든 작업을 수행할 수 있음을 의미합니다.
다음 다이어그램은 작업의 하위 집합과 관련된 이 기본 Amazon SQS 정책 중 하나의 개념을 보여줍니다. 정책은 용이며 `queue_xyz`계정 AWS 1 및 AWS 계정 2에 지정된 대기열에서 허용된 작업을 사용할 수 있는 권한을 부여합니다.
**참고**
정책의 리소스는 로 지정됩니다. `123456789012/queue_xyz`여기서 `123456789012`는 대기열을 소유한 AWS 계정의 계정 ID입니다.
![\[작업의 하위 집합을 다루는 Amazon SQS 정책\]](http://docs.aws.amazon.com/ko_kr/AWSSimpleQueueService/latest/SQSDeveloperGuide/images/SQS_BasicPolicy.png)
IAM 소개 및 **사용자와 **Amazon 리소스 이름(ARN)의 개념에서 SQS 정책에 대한 몇 가지 사항이 바뀌었습니다. 다음 다이어그램과 표에는 이 변경 사항에 대한 설명이 나와 있습니다.
![\[Amazon SQS 정책에 IAM 및 Amazon 리소스 이름이 추가되었습니다.\]](http://docs.aws.amazon.com/ko_kr/AWSSimpleQueueService/latest/SQSDeveloperGuide/images/SQS_PolicyWithNewFeatures.png)
![\[Number one in the diagram.\]](http://docs.aws.amazon.com/ko_kr/AWSSimpleQueueService/latest/SQSDeveloperGuide/images/number-1-red.png) 다른 계정의 사용자에게 권한을 부여하는 방법에 대한 자세한 내용은 *IAM* [사용 설명서의 자습서: IAM 역할을 사용하여 AWS 계정 간 액세스 권한 위임을 참조하세요](https://docs.aws.amazon.com/IAM/latest/UserGuide/tutorial_cross-account-with-roles.html).
![\[Number two in the diagram.\]](http://docs.aws.amazon.com/ko_kr/AWSSimpleQueueService/latest/SQSDeveloperGuide/images/number-2-red.png) `*`에 포함된 작업의 하위 집합이 확장되었습니다. 허용된 작업 목록에 대해서는 [Amazon SQS API 권한: 작업 및 리소스 참조](sqs-api-permissions-reference.md)을 참조하십시오.
![\[Number three in the diagram.\]](http://docs.aws.amazon.com/ko_kr/AWSSimpleQueueService/latest/SQSDeveloperGuide/images/number-3-red.png) IAM 정책에서 리소스를 지정하는 기본 수단인 Amazon 리소스 이름(ARN)을 사용하여 리소스를 지정할 수 있습니다. Amazon SQS 대기열의 ARN 형식에 대한 정보는 [Amazon Simple Queue Service 리소스 및 작업](#sqs-resource-and-operations) 섹션을 참조하세요.
예를 들어 이전 다이어그램의 Amazon SQS 정책에 따라 AWS 계정 1 또는 AWS 계정 2에 대한 보안 자격 증명을 보유한 사람은 누구나에 액세스할 수 있습니다`queue_xyz`. 또한, 자체 AWS 계정(ID `123456789012`)에 있는 사용자 Bob과 Susan은 대기열에 액세스할 수 있습니다.
IAM 소개에 앞서 Amazon SQS는 대기열의 생성자에게 대기열에 대한 전체 제어권을 자동으로 부여합니다(즉, 이 대기열에서 가능한 Amazon SQS 작업 전체에 대한 액세스). 생성자가 AWS 보안 자격 증명을 사용하지 않을 경우 이것은 더 이상 적용되지 않습니다. 대기열 생성 권한을 가진 사용자는 누구나 생성된 대기열에서 어떤 작업이든 할 수 있도록 다른 Amazon SQS 작업을 사용할 권한이 있어야 합니다.
다음은 한 사용자에게 모든 Amazon SQS 작업을 사용하도록 허용하는 정책 예제이지만, 리터럴 문자열 `bob_queue_`로 시작하는 이름을 가진 대기열에만 적용됩니다.
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement": [{
"Effect": "Allow",
"Action": "sqs:*",
"Resource": "arn:aws:sqs:*:123456789012:bob_queue_*"
}]
}
```
------
자세한 내용은 [Amazon SQS에서 정책 사용](sqs-using-identity-based-policies.md) 및 **IAM 사용 설명서의 [자격 증명(사용자, 그룹 및 역할)](https://docs.aws.amazon.com/IAM/latest/UserGuide/id.html) 섹션을 참조하세요.
## 정책 요소 지정: 작업, 효과, 리소스, 보안 주체
각 [Amazon Simple Queue Service 리소스](#sqs-resource-and-operations)마다 서비스는 일련의 [작업](https://docs.aws.amazon.com/AWSSimpleQueueService/latest/APIReference/API_Operations.html)을 정의합니다. 이러한 작업에 대한 권한을 부여하기 위해 Amazon SQS는 정책에서 지정할 수 있는 작업을 정의합니다.
**참고**
작업을 실시하려면 둘 이상의 작업에 대한 권한이 필요할 수 있습니다. 특정 작업에 대한 권한을 부여할 때 해당 작업이 허용되거나 거부되는 리소스도 식별합니다.
다음은 가장 기본적인 정책 요소입니다.
+ **리소스** – 정책에서 Amazon 리소스 이름(ARN)을 사용하여 정책을 적용할 리소스를 식별합니다.
+ **작업** - 작업 키워드를 사용하여 허용 또는 거부할 리소스 작업을 식별합니다. 예를 들어, `sqs:CreateQueue` 권한은 사용자에게 Amazon Simple Queue Service `CreateQueue` 작업 수행을 허용합니다.
+ **결과** – 사용자가 특정 작업을 요청하는 경우의 결과를 지정합니다. 이는 허용 또는 거부 중에 하나가 될 수 있습니다. 리소스에 대한 액세스 권한을 명시적으로 부여하지 않으면 액세스가 암시적으로 거부됩니다. 한 리소스에 대한 액세스를 명시적으로 거부할 수도 있으며, 다른 정책에 따라 액세스 권한이 부여되더라도 사용자가 이 리소스에 액세스하지 못하도록 조치를 취할 수 있습니다.
+ **Principal** – 자격 증명 기반 정책(IAM 정책)에서 정책이 연결되는 사용자는 암시적인 보안 주체입니다. 리소스 기반 정책의 경우, 사용자, 계정, 서비스 또는 권한의 수신자인 기타 개체를 지정합니다(리소스 기반 정책에만 해당).
Amazon SQS 정책 구문과 설명에 대한 자세한 내용은 **IAM 사용 설명서의 [AWS IAM 정책 참조](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_policies.html) 섹션을 참조하세요.
모든 Amazon Simple Queue Service 작업과 해당 작업이 적용되는 리소스를 보여주는 표는 [Amazon SQS API 권한: 작업 및 리소스 참조](sqs-api-permissions-reference.md) 섹션을 참조하세요.
# Amazon Simple Queue Service가 IAM으로 작동하는 방식
IAM을 사용하여 Amazon SQS에 대한 액세스를 관리하기 전에 Amazon SQS에서 사용할 수 있는 IAM 기능에 대해 알아봅니다.
**Amazon SQS와 함께 사용할 수 있는 IAM 기능**
| IAM 특성 | Amazon SQS 지원 |
| --- | --- |
| [자격 증명 기반 정책](#security_iam_service-with-iam-id-based-policies) | 예 |
| [리소스 기반 정책](#security_iam_service-with-iam-resource-based-policies) | 예 |
| [정책 작업](#security_iam_service-with-iam-id-based-policies-actions) | 예 |
| [정책 리소스](#security_iam_service-with-iam-id-based-policies-resources) | 예 |
| [정책 조건 키(서비스별)](#security_iam_service-with-iam-id-based-policies-conditionkeys) | 예 |
| [ACL](#security_iam_service-with-iam-acls) | 아니요 |
| [ABAC(정책 내 태그)](#security_iam_service-with-iam-tags) | 부분적 |
| [임시 자격 증명](#security_iam_service-with-iam-roles-tempcreds) | 예 |
| [전달 액세스 세션(FAS)](#security_iam_service-with-iam-principal-permissions) | 예 |
| [서비스 역할](#security_iam_service-with-iam-roles-service) | 예 |
| [서비스 연결 역할](#security_iam_service-with-iam-roles-service-linked) | 아니요 |
Amazon SQS 및 기타 AWS 서비스가 대부분의 IAM 기능과 작동하는 방식을 개괄적으로 알아보려면 *IAM 사용 설명서*의 [AWS IAM으로 작업하는 서비스를](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_aws-services-that-work-with-iam.html) 참조하세요.
## 액세스 관리
액세스 제어 목록(ACL)은 어떤 보안 주체(계정 멤버, 사용자 또는 역할)가 리소스에 액세스할 수 있는 권한을 가지고 있는지를 제어합니다. ACL은 JSON 정책 문서 형식을 사용하지 않지만 리소스 기반 정책과 유사합니다.
Amazon S3 AWS WAF및 Amazon VPC는 ACLs. ACL에 관한 자세한 내용은 *Amazon Simple Storage Service 개발자 가이드*의 [액세스 제어 목록(ACL) 개요](https://docs.aws.amazon.com/AmazonS3/latest/userguide/acl-overview.html)를 참조하세요.
**참고**
모든 사용자가 자신의 계정에 속한 사용자에게 자신의 권한을 위임할 AWS 계정 수 있다는 점을 이해하는 것이 중요합니다. 교차 계정 액세스를 사용하면 추가 사용자를 관리할 필요 없이 AWS 리소스에 대한 액세스를 공유할 수 있습니다. 교차 계정 액세스 사용에 대한 자세한 정보는 *IAM 사용 설명서*의 [교차 계정 액세스 사용](https://docs.aws.amazon.com/IAM/latest/UserGuide/Delegation.html)을 참조하세요.
Amazon SQS 사용자 지정 정책 내의 콘텐츠 간 권한 및 조건 키에 대한 자세한 내용은 [Amazon SQS 사용자 지정 정책의 제한 사항](sqs-limitations-of-custom-policies.md) 섹션을 참조하세요.
## Amazon SQS의 자격 증명 기반 정책
**ID 기반 정책 지원:** 예
ID 기반 정책은 IAM 사용자, 사용자 그룹 또는 역할과 같은 ID에 연결할 수 있는 JSON 권한 정책 문서입니다. 이러한 정책은 사용자 및 역할이 어떤 리소스와 어떤 조건에서 어떤 작업을 수행할 수 있는지를 제어합니다. 자격 증명 기반 정책을 생성하는 방법을 알아보려면 *IAM 사용 설명서*에서 [고객 관리형 정책으로 사용자 지정 IAM 권한 정의](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies_create.html)를 참조하세요.
IAM ID 기반 정책을 사용하면 허용되거나 거부되는 작업과 리소스뿐 아니라 작업이 허용되거나 거부되는 조건을 지정할 수 있습니다. JSON 정책에서 사용할 수 있는 모든 요소에 대해 알아보려면 *IAM 사용 설명서*의 [IAM JSON 정책 요소 참조](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_policies_elements.html)를 참조하세요.
### Amazon SQS의 자격 증명 기반 정책 예
Amazon SQS 자격 증명 기반 정책 예제를 보려면 [정책 모범 사례](sqs-basic-examples-of-iam-policies.md#security_iam_id-based-policy-examples) 섹션을 참조하세요.
## Amazon SQS 내의 리소스 기반 정책
**리소스 기반 정책 지원:** 예
리소스 기반 정책은 리소스에 연결하는 JSON 정책 설명서입니다. 리소스 기반 정책의 예제는 IAM *역할 신뢰 정책*과 Amazon S3 *버킷 정책*입니다. 리소스 기반 정책을 지원하는 서비스에서 서비스 관리자는 이러한 정책을 사용하여 특정 리소스에 대한 액세스를 통제할 수 있습니다. 정책이 연결된 리소스의 경우 정책은 지정된 보안 주체가 해당 리소스와 어떤 조건에서 어떤 작업을 수행할 수 있는지를 정의합니다. 리소스 기반 정책에서 [보안 주체를 지정](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_policies_elements_principal.html)해야 합니다. 보안 주체에는 계정, 사용자, 역할, 페더레이션 사용자 또는이 포함될 수 있습니다 AWS 서비스.
교차 계정 액세스를 활성화하려는 경우, 전체 계정이나 다른 계정의 IAM 개체를 리소스 기반 정책의 보안 주체로 지정할 수 있습니다. 자세한 내용은 *IAM 사용 설명서*의 [IAM에서 교차 계정 리소스 액세스](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies-cross-account-resource-access.html)를 참조하세요.
## Amazon SQS의 정책 작업
**정책 작업 지원:** 예
관리자는 AWS JSON 정책을 사용하여 누가 무엇에 액세스할 수 있는지 지정할 수 있습니다. 즉, 어떤 **보안 주체**가 어떤 **리소스**와 어떤 **조건**에서 **작업**을 수행할 수 있는지를 지정할 수 있습니다.
JSON 정책의 `Action`요소는 정책에서 액세스를 허용하거나 거부하는 데 사용할 수 있는 작업을 설명합니다. 연결된 작업을 수행할 수 있는 권한을 부여하기 위한 정책에 작업을 포함하세요.
Amazon SQS 작업의 목록을 보려면 **서비스 권한 부여 참조의 [Amazon Simple Queue Service에서 정의한 작업](https://docs.aws.amazon.com/IAM/latest/UserGuide/list_amazonsqs.html#amazonsqs-resources-for-iam-policies)을 참조하세요.
Amazon SQS의 정책 작업은 작업 앞에 다음 접두사를 사용합니다.
```
sqs
```
단일 문에서 여러 작업을 지정하려면 쉼표로 구분합니다.
```
"Action": [
"sqs:action1",
"sqs:action2"
]
```
Amazon SQS 자격 증명 기반 정책 예제를 보려면 [정책 모범 사례](sqs-basic-examples-of-iam-policies.md#security_iam_id-based-policy-examples) 섹션을 참조하세요.
## Amazon SQS의 정책 리소스
**정책 리소스 지원:** 예
관리자는 AWS JSON 정책을 사용하여 누가 무엇에 액세스할 수 있는지 지정할 수 있습니다. 즉, 어떤 **보안 주체**가 어떤 **리소스**와 어떤 **조건**에서 **작업**을 수행할 수 있는지를 지정할 수 있습니다.
`Resource` JSON 정책 요소는 작업이 적용되는 하나 이상의 객체를 지정합니다. 모범 사례에 따라 [Amazon 리소스 이름(ARN)](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference-arns.html)을 사용하여 리소스를 지정합니다. 리소스 수준 권한을 지원하지 않는 작업의 경우, 와일드카드(\$1)를 사용하여 해당 문이 모든 리소스에 적용됨을 나타냅니다.
```
"Resource": "*"
```
Amazon SQS 리소스 유형 및 해당 ARN의 목록을 보려면 **서비스 권한 부여 참조의 [Amazon Simple Queue Service에서 정의한 작업](https://docs.aws.amazon.com/IAM/latest/UserGuide/list_amazonsqs.html#amazonsqs-actions-as-permissions)을 참조하세요. 각 리소스의 ARN을 지정할 수 있는 작업을 알아보려면 [Amazon Simple Queue Service에서 정의한 리소스](https://docs.aws.amazon.com/IAM/latest/UserGuide/list_amazonsqs.html#amazonsqs-resources-for-iam-policies)를 참조하세요.
Amazon SQS 자격 증명 기반 정책 예제를 보려면 [정책 모범 사례](sqs-basic-examples-of-iam-policies.md#security_iam_id-based-policy-examples) 섹션을 참조하세요.
## Amazon SQS의 정책 조건 키
**서비스별 정책 조건 키 지원:** 예
관리자는 AWS JSON 정책을 사용하여 누가 무엇에 액세스할 수 있는지 지정할 수 있습니다. 즉, 어떤 **보안 주체**가 어떤 **리소스**와 어떤 **조건**에서 **작업**을 수행할 수 있는지를 지정할 수 있습니다.
`Condition` 요소는 정의된 기준에 따라 문이 실행되는 시기를 지정합니다. 같음(equals) 또는 미만(less than)과 같은 [조건 연산자](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_policies_elements_condition_operators.html)를 사용하여 정책의 조건을 요청의 값과 일치시키는 조건식을 생성할 수 있습니다. 모든 AWS 전역 조건 키를 보려면 *IAM 사용 설명서*의 [AWS 전역 조건 컨텍스트 키를](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_policies_condition-keys.html) 참조하세요.
Amazon SQS 조건 키 목록을 보려면 **서비스 권한 부여 참조의 [Amazon Simple Queue Service에 사용되는 조건 키](https://docs.aws.amazon.com/IAM/latest/UserGuide/list_amazonsqs.html#amazonsqs-policy-keys)를 참조하세요. 조건 키를 사용할 수 있는 작업과 리소스를 알아보려면 [Amazon Simple Queue Service에서 정의한 리소스](https://docs.aws.amazon.com/IAM/latest/UserGuide/list_amazonsqs.html#amazonsqs-resources-for-iam-policies)를 참조하세요.
Amazon SQS 자격 증명 기반 정책 예제를 보려면 [정책 모범 사례](sqs-basic-examples-of-iam-policies.md#security_iam_id-based-policy-examples) 섹션을 참조하세요.
## Amazon SQS의 ACL
**ACL 지원:** 아니요
액세스 제어 목록(ACL)은 어떤 보안 주체(계정 멤버, 사용자 또는 역할)가 리소스에 액세스할 수 있는 권한을 가지고 있는지를 제어합니다. ACL은 JSON 정책 문서 형식을 사용하지 않지만 리소스 기반 정책과 유사합니다.
## Amazon SQS의 ABAC
**ABAC 지원(정책의 태그):** 부분적
속성 기반 액세스 제어(ABAC)는 태그라고 불리는 속성을 기반으로 권한을 정의하는 권한 부여 전략입니다. IAM 엔터티 및 AWS 리소스에 태그를 연결한 다음 보안 주체의 태그가 리소스의 태그와 일치할 때 작업을 허용하는 ABAC 정책을 설계할 수 있습니다.
태그에 근거하여 액세스를 제어하려면 `aws:ResourceTag/key-name`, `aws:RequestTag/key-name`또는 `aws:TagKeys`조건 키를 사용하여 정책의 [조건 요소](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_policies_elements_condition.html)에 태그 정보를 제공합니다.
서비스가 모든 리소스 유형에 대해 세 가지 조건 키를 모두 지원하는 경우, 값은 서비스에 대해 **예**입니다. 서비스가 일부 리소스 유형에 대해서만 세 가지 조건 키를 모두 지원하는 경우, 값은 **부분적**입니다.
ABAC에 대한 자세한 내용은 *IAM 사용 설명서*의 [ABAC 권한 부여를 통한 권한 정의](https://docs.aws.amazon.com/IAM/latest/UserGuide/introduction_attribute-based-access-control.html)를 참조하세요. ABAC 설정 단계가 포함된 자습서를 보려면 *IAM 사용 설명서*의 [속성 기반 액세스 제어(ABAC) 사용](https://docs.aws.amazon.com/IAM/latest/UserGuide/tutorial_attribute-based-access-control.html)을 참조하세요.
## Amazon SQS에서 임시 자격 증명 사용
**임시 자격 증명 지원:** 예
임시 자격 증명은 AWS 리소스에 대한 단기 액세스를 제공하며 페더레이션 또는 전환 역할을 사용할 때 자동으로 생성됩니다. 장기 액세스 키를 사용하는 대신 임시 자격 증명을 동적으로 생성하는 것이 AWS 좋습니다. 자세한 내용은 *IAM 사용 설명서*의 [IAM의 임시 보안 자격 증명](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_credentials_temp.html) 및 [IAM으로 작업하는AWS 서비스](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_aws-services-that-work-with-iam.html) 섹션을 참조하세요.
## Amazon SQS에 대한 액세스 세션 전달
**전달 액세스 세션(FAS) 지원:** 예
전달 액세스 세션(FAS)은를 호출하는 보안 주체의 권한을 다운스트림 서비스에 AWS 서비스 대한 요청과 AWS 서비스함께 사용합니다. FAS 요청 시 정책 세부 정보는 [전달 액세스 세션](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_forward_access_sessions.html)을 참조하세요.
## Amazon SQS의 서비스 역할
**서비스 역할 지원:** 예
서비스 역할은 서비스가 사용자를 대신하여 작업을 수행하는 것으로 가정하는 [IAM 역할](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles.html)입니다. IAM 관리자는 IAM 내에서 서비스 역할을 생성, 수정 및 삭제할 수 있습니다. 자세한 내용은 *IAM 사용 설명서*의 [AWS 서비스 AWS에 권한을 위임할 역할 생성](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles_create_for-service.html)을 참조하세요.
**주의**
서비스 역할에 대한 권한을 변경하면 Amazon SQS 기능이 중단될 수 있습니다. Amazon SQS에서 관련 지침을 제공하는 경우에만 서비스 역할을 편집합니다.
## Amazon SQS의 서비스 연결 역할
**서비스 연결 역할 지원:** 아니요
서비스 연결 역할은에 연결된 서비스 역할의 한 유형입니다 AWS 서비스. 서비스는 사용자를 대신하여 작업을 수행하기 위해 역할을 수임할 수 있습니다. 서비스 연결 역할은에 표시 AWS 계정 되며 서비스가 소유합니다. IAM 관리자는 서비스 연결 역할의 권한을 볼 수 있지만 편집은 할 수 없습니다.
서비스 연결 역할 생성 또는 관리에 대한 자세한 내용은 [IAM으로 작업하는AWS 서비스](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_aws-services-that-work-with-iam.html)를 참조하세요. **서비스 연결 역할** 열에서 `Yes`가 포함된 서비스를 테이블에서 찾습니다. 해당 서비스에 대한 서비스 연결 역할 설명서를 보려면 **예(Yes)** 링크를 선택합니다.
# AWS 관리형 정책에 대한 Amazon SQS 업데이트
사용자, 그룹 또는 역할에 권한을 추가할 때 정책을 직접 작성하는 것보다 AWS 관리형 정책을 사용하는 것이 더욱 편리합니다. 팀에 필요한 권한만 제공하는 [IAM 고객 관리형 정책을 생성](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies_create-console.html)하려면 시간과 전문 지식이 필요합니다. 빨리 시작하려면 AWS 관리형 정책을 사용할 수 있습니다. 이러한 정책은 일반적인 사용 사례에 적용되며 AWS 계정에서 사용할 수 있습니다. AWS 관리형 정책에 대한 자세한 내용은 *IAM 사용 설명서*의 [AWS 관리형 정책을](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies_managed-vs-inline.html#aws-managed-policies) 참조하세요.
AWS 서비스는 AWS 관리형 정책을 유지 관리하고 업데이트합니다. AWS 관리형 정책에서는 권한을 변경할 수 없습니다. 서비스는 때때로 AWS 관리형 정책에 추가 권한을 추가하여 새 기능을 지원합니다. 이 유형의 업데이트는 정책이 연결된 모든 ID(사용자, 그룹 및 역할)에 적용됩니다. 서비스는 새 기능이 시작되거나 새 작업을 사용할 수 있게 될 때 AWS 관리형 정책을 업데이트할 가능성이 높습니다. 서비스는 AWS 관리형 정책에서 권한을 제거하지 않으므로 정책 업데이트로 인해 기존 권한이 손상되지 않습니다.
또한는 여러 서비스에 걸쳐 있는 직무에 대한 관리형 정책을 AWS 지원합니다. 예를 들어 **ReadOnlyAccess**라는 이름의 AWS 관리형 정책은 모든 AWS 서비스 및 리소스에 대한 읽기 전용 액세스 권한을 제공합니다. 서비스가 새 기능을 시작하면는 새 작업 및 리소스에 대한 읽기 전용 권한을 AWS 추가합니다. 직무 정책의 목록과 설명은 *IAM 사용 설명서*의 [직무에 관한AWS 관리형 정책](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies_job-functions.html)을 참조하세요.
## AWS 관리형 정책: AmazonSQSFullAccess
`AmazonSQSFullAccess` 정책을 Amazon SQS 자격 증명에 연결할 수 있습니다. 이 정책은 Amazon SQS에 대한 전체 액세스를 허용하는 권한을 부여합니다.
이 정책의 권한을 보려면 **AWS 관리형 정책 참조에서 [AmazonSQSFullAccess](https://docs.aws.amazon.com/aws-managed-policy/latest/reference/AmazonSQSFullAccess.html)를 참조하세요.
## AWS 관리형 정책: AmazonSQSReadOnlyAccess
`AmazonSQSReadOnlyAccess` 정책을 Amazon SQS 자격 증명에 연결할 수 있습니다. 이 정책은 Amazon SQS에 대한 읽기 전용 액세스를 허용하는 권한을 부여합니다.
이 정책의 권한을 보려면 **AWS 관리형 정책 참조에서 [AmazonSQSReadOnlyAccess](https://docs.aws.amazon.com/aws-managed-policy/latest/reference/AmazonSQSReadOnlyAccess.html)를 참조하세요.
## AWS 관리형 정책: SQSUnlockQueuePolicy
Amazon SQS 대기열에 대한 모든 사용자의 액세스를 거부하도록 멤버 계정에 대한 대기열 정책을 잘못 구성한 경우 `SQSUnlockQueuePolicy` AWS 관리형 정책을 사용하여 대기열을 잠금 해제할 수 있습니다.
모든 보안 주체가 Amazon SQS 대기열에 액세스하지 못하도록 잘못 구성된 대기열 정책을 제거하는 방법에 대한 자세한 내용은 *IAM 사용 설명서*의 [AWS Organizations 멤버 계정에서 권한 있는 작업 수행을](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_root-user-privileged-task.html) 참조하세요.
## AWS 관리형 정책에 대한 Amazon SQS 업데이트
이 서비스가 이러한 변경 사항을 추적하기 시작한 이후부터 Amazon SQS의 AWS 관리형 정책 업데이트에 대한 세부 정보를 봅니다. 이 페이지의 변경 사항에 대한 자동 알림을 받아보려면 Amazon SQS [문서 기록](sqs-release-notes.md) 페이지에서 RSS 피드를 구독하세요.
| 변경 | 설명 | Date |
| --- | --- | --- |
| [SQSUnlockQueuePolicy](https://docs.aws.amazon.com/IAM/latest/UserGuide/security-iam-awsmanpol.html#security-iam-awsmanpol-SQSUnlockQueuePolicy) | Amazon SQS는 대기열을 잠금 해제하고 모든 보안 주체가 Amazon SQS 대기열에 액세스하는 것을 거부하는 잘못 구성된 대기열 정책을 제거하기 `SQSUnlockQueuePolicy` 위해 라는 새로운 AWS관리형 정책을 추가했습니다. | 2024년 11월 15일 |
| [AmazonSQSReadOnlyAccess](https://console.aws.amazon.com/iam/home#policies/arn:aws:iam::aws:policy/AmazonSQSReadOnlyAccess) | 지정된 Amazon SQS 대기열과 연결된 모든 태그를 검색하는 [https://docs.aws.amazon.com/AWSSimpleQueueService/latest/APIReference/API_ListQueueTags.html](https://docs.aws.amazon.com/AWSSimpleQueueService/latest/APIReference/API_ListQueueTags.html) 작업을 Amazon SQS에 추가했습니다. 이를 통해 조직 또는 메타데이터 목적으로 대기열에 할당된 키 값 페어를 볼 수 있습니다. 이 작업은 `ListQueueTags` API 작업과 연결되어 있습니다. | 2024년 6월 20일 |
| [AmazonSQSReadOnlyAccess](https://console.aws.amazon.com/iam/home#policies/arn:aws:iam::aws:policy/AmazonSQSReadOnlyAccess) | Amazon SQS는 특정 소스 대기열 아래에 가장 최근의 메시지 이동 작업(최대 10개)을 나열할 수 있는 새 작업을 추가했습니다. 이 작업은 [https://docs.aws.amazon.com/AWSSimpleQueueService/latest/APIReference/API_ListMessageMoveTasks.html](https://docs.aws.amazon.com/AWSSimpleQueueService/latest/APIReference/API_ListMessageMoveTasks.html) API 작업과 연결되어 있습니다. | 2023년 6월 9일 |
# Amazon Simple Queue Service ID 및 액세스 문제 해결
다음 정보를 사용하여 Amazon SQS 및 IAM으로 작업할 때 발생할 수 있는 일반적인 문제를 진단하고 수정할 수 있습니다.
## Amazon SQS에서 작업을 수행할 권한이 없음
작업을 수행할 수 있는 권한이 없다는 오류가 수신되면 작업을 수행할 수 있도록 정책을 업데이트해야 합니다.
다음 예제 오류는 `mateojackson` 사용자가 콘솔을 사용하여 가상 `my-example-widget` 리소스에 대한 세부 정보를 보려고 하지만 가상 `sqs:GetWidget` 권한이 없을 때 발생합니다.
```
User: arn:aws:iam::123456789012:user/mateojackson is not authorized to perform: sqs:GetWidget on resource: my-example-widget
```
이 경우 Mateo의 정책은 `sqs:GetWidget` 작업을 사용하여 `my-example-widget` 리소스에 액세스하도록 허용하도록 업데이트해야 합니다.
도움이 필요한 경우 AWS 관리자에게 문의하세요. 관리자는 로그인 자격 증명을 제공한 사람입니다.
## iam:PassRole을 수행하도록 인증되지 않음
`iam:PassRole` 작업을 수행할 수 있는 권한이 없다는 오류가 수신되면 Amazon SQS에 역할을 전달할 수 있도록 정책을 업데이트해야 합니다.
일부 AWS 서비스 에서는 새 서비스 역할 또는 서비스 연결 역할을 생성하는 대신 기존 역할을 해당 서비스에 전달할 수 있습니다. 이렇게 하려면 역할을 서비스에 전달할 권한이 있어야 합니다.
다음 예제 오류는 `marymajor`라는 IAM 사용자가 콘솔을 사용하여 Amazon SQS에서 태스크를 수행하려고 하는 경우에 발생합니다. 하지만 작업을 수행하려면 서비스 역할이 부여한 권한이 서비스에 있어야 합니다. Mary는 서비스에 역할을 전달할 권한이 없습니다.
```
User: arn:aws:iam::123456789012:user/marymajor is not authorized to perform: iam:PassRole
```
이 경우, Mary가 `iam:PassRole`작업을 수행할 수 있도록 Mary의 정책을 업데이트해야 합니다.
도움이 필요한 경우 AWS 관리자에게 문의하세요. 관리자는 로그인 자격 증명을 제공한 사람입니다.
## 내 외부의 사람이 내 Amazon SQS 리소스 AWS 계정 에 액세스하도록 허용하고 싶습니다.
다른 계정의 사용자 또는 조직 외부의 사람이 리소스에 액세스할 때 사용할 수 있는 역할을 생성할 수 있습니다. 역할을 수임할 신뢰할 수 있는 사람을 지정할 수 있습니다. 리소스 기반 정책 또는 액세스 제어 목록(ACL)을 지원하는 서비스의 경우, 이러한 정책을 사용하여 다른 사람에게 리소스에 대한 액세스 권한을 부여할 수 있습니다.
자세한 내용은 다음을 참조하세요.
+ Amazon SQS에서 이러한 기능을 지원하는지 여부를 알아보려면 [Amazon Simple Queue Service가 IAM으로 작동하는 방식](security_iam_service-with-iam.md) 섹션을 참조하세요.
+ 소유 AWS 계정 한의 리소스에 대한 액세스 권한을 제공하는 방법을 알아보려면 [IAM 사용 설명서의 소유한 다른의 IAM 사용자에게 액세스 권한 제공을 참조 AWS 계정 하세요](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles_common-scenarios_aws-accounts.html). **
+ 타사에 리소스에 대한 액세스 권한을 제공하는 방법을 알아보려면 *IAM 사용 설명서*의 [타사가 AWS 계정 소유한에 대한 액세스 권한 제공을](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles_common-scenarios_third-party.html) AWS 계정참조하세요.
+ ID 페더레이션을 통해 액세스 권한을 제공하는 방법을 알아보려면 *IAM 사용 설명서*의 [외부에서 인증된 사용자에게 액세스 권한 제공(ID 페더레이션)](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles_common-scenarios_federated-users.html)을 참조하세요.
+ 크로스 계정 액세스에 대한 역할과 리소스 기반 정책 사용의 차이점을 알아보려면 *IAM 사용 설명서*의 [IAM의 크로스 계정 리소스 액세스](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies-cross-account-resource-access.html)를 참조하세요.
## 대기열을 잠금 해제하고 싶습니다
가 조직에 AWS 계정 속한 경우 AWS Organizations 정책은 Amazon SQS 리소스에 액세스하는 것을 차단할 수 있습니다. 기본적으로 AWS Organizations 정책은 Amazon SQS에 대한 요청을 차단하지 않습니다. 그러나 Amazon SQS 대기열에 대한 액세스를 차단하도록 AWS Organizations 정책이 구성되지 않았는지 확인합니다. AWS Organizations 정책을 확인하는 방법에 대한 지침은 *AWS Organizations 사용 설명서*의 [모든 정책 나열](https://docs.aws.amazon.com/organizations/latest/userguide/orgs_manage_policies_info-operations.html#list-all-pols-in-org.html)을 참조하세요.
또한 Amazon SQS 대기열에 대한 모든 사용자의 액세스를 거부하도록 멤버 계정의 대기열 정책을 잘못 구성할 경우 IAM에서 멤버 계정에 대한 권한 있는 세션을 시작하여 대기열을 잠금 해제할 수 있습니다. 권한 있는 세션을 시작하면 잘못 구성된 대기열 정책을 삭제하여 대기열에 대한 액세스 권한을 다시 얻을 수 있습니다. 자세한 내용은 *IAM 사용 설명서*의 [AWS Organizations 멤버 계정에서 권한 있는 작업 수행을](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_root-user-privileged-task.html) 참조하세요.
# Amazon SQS에서 정책 사용
이 주제에서는 계정 관리자가 IAM 자격 증명(사용자, 그룹, 역할)에 권한 정책을 연결할 수 있는 자격 증명 기반 정책 예제를 제시합니다.
**중요**
Amazon Simple Queue Service 리소스에 대한 액세스 관리를 위해 제공되는 기본 개념과 옵션 설명에 대한 소개 주제 부분을 먼저 읽어 보는 것이 좋습니다. 자세한 내용은 [Amazon SQS의 액세스 관리 개요](sqs-overview-of-managing-access.md) 단원을 참조하십시오.
`ListQueues`를 제외한 모든 Amazon SQS 작업은 리소스 수준 권한을 지원합니다. 자세한 내용은 [Amazon SQS API 권한: 작업 및 리소스 참조](sqs-api-permissions-reference.md) 단원을 참조하십시오.
## Amazon SQS 및 IAM 정책 사용
사용자에게 Amazon SQS 리소스 권한을 부여하는 방법에는 Amazon SQS 정책 시스템(리소스 기반 정책)을 사용하는 방법과 IAM 정책 시스템(자격 증명 기반 정책)을 사용하는 방법이 있습니다. IAM 정책에서만 설정할 수 있는 리전 권한인 `ListQueues` 작업을 제외하고 하나 또는 두 가지 방법을 모두 사용할 수 있습니다.
예를 들어, 다음 다이어그램은 동일한 IAM 정책과 Amazon SQS 정책을 보여줍니다. IAM 정책은 AWS 계정`queue_xyz`에서 라는 대기열에 대한 Amazon SQS `ReceiveMessage` 및 `SendMessage` 작업에 대한 권한을 부여하며, 정책은 Bob과 Susan이라는 사용자에게 연결됩니다(Bob과 Susan은 정책에 명시된 권한을 가짐). 이 Amazon SQS 정책 역시 동일한 대기열에서 `ReceiveMessage` 및 `SendMessage` 작업에 대한 권한을 Bob과 Susan에게 부여합니다.
**참고**
다음 예제는 조건 없는 간단한 정책을 보여줍니다. 두 정책 중 어느 쪽에서도 특정 조건을 지정하고 동일한 결과를 얻을 수 있습니다.
![\[IAM 정책과 이에 상응하는 Amazon SQS 정책을 비교하는 다이어그램입니다. IAM 정책은 AWS 계정queue_xyz에서 라는 대기열에 대한 Amazon SQS ReceiveMessage 및 SendMessage 작업에 대한 권한을 부여하며, 정책은 Bob과 Susan이라는 사용자에게 연결됩니다(Bob과 Susan은 정책에 명시된 권한을 가짐). 이 Amazon SQS 정책 역시 동일한 대기열에서 ReceiveMessage 및 SendMessage 작업에 대한 권한을 Bob과 Susan에게 부여합니다.\]](http://docs.aws.amazon.com/ko_kr/AWSSimpleQueueService/latest/SQSDeveloperGuide/images/sqs-iam-policies-equivalent.png)
IAM과 Amazon SQS 정책에는 한 가지 주요 차이점이 있습니다. Amazon SQS 정책 시스템을 사용하면 다른 AWS 계정에 권한을 부여할 수 있지만 IAM은 부여하지 않습니다.
사용자의 필요에 따라 두 시스템을 함께 사용하여 권한을 관리해야 합니다. 다음 예는 두 정책 시스템이 어떻게 연계하는지 보여줍니다.
+ 첫 번째 예에서 Bob은 IAM 정책과 Amazon SQS 정책 모두를 자신의 계정에 적용했습니다. IAM 정책은 `queue_xyz`에서 `ReceiveMessage` 작업에 대한 계정 권한을 부여하지만, Amazon SQS 정책은 동일한 대기열에서 `SendMessage` 작업에 대한 계정 권한을 부여합니다. 다음 다이어그램에서 관련 개념을 설명합니다.
![\[IAM 정책의 구성 요소를 Amazon SQS 정책과 비교하는 다이어그램입니다. 첫 번째 예에서 Bob은 IAM 정책과 Amazon SQS 정책 모두를 자신의 계정에 적용했습니다. IAM 정책은 queue_xyz에서 ReceiveMessage 작업에 대한 계정 권한을 부여하지만, Amazon SQS 정책은 동일한 대기열에서 SendMessage 작업에 대한 계정 권한을 부여합니다.\]](http://docs.aws.amazon.com/ko_kr/AWSSimpleQueueService/latest/SQSDeveloperGuide/images/sqs-iam-policies-union.png)
Bob이 `ReceiveMessage` 요청을 `queue_xyz`에 전송하면, IAM 정책은 이 작업을 허용합니다. Bob이 `SendMessage` 요청을 `queue_xyz`에 전송하면, Amazon SQS 정책은 이 작업을 허용합니다.
+ 두 번째 예에서 Bob은 `queue_xyz`에 대한 액세스 권한을 침해하므로, 해당 대기열에 대한 전체 액세스 권한을 제거해야 합니다. 가장 쉬운 방법은 모든 대기열 작업에 대한 Bob의 액세스를 거부하는 정책을 추가하는 것입니다. 명시적 `deny`는 항상 `allow`를 무시하기 때문에 이 정책은 다른 2개 정책을 무시합니다. 정책 평가 로직에 대한 자세한 내용은 [Amazon SQS 액세스 정책 언어와 함께 사용자 지정 정책 사용](sqs-creating-custom-policies.md)를 참조하십시오. 다음 다이어그램에서 관련 개념을 설명합니다.
![\[Amazon SQS 정책을 사용한 IAM 정책 재정의를 보여주는 다이어그램입니다. Bob은 queue_xyz에 대한 액세스 권한을 침해하므로, 해당 대기열에 대한 전체 액세스 권한을 제거해야 합니다. 가장 쉬운 방법은 모든 대기열 작업에 대한 Bob의 액세스를 거부하는 정책을 추가하는 것입니다. 명시적 deny는 항상 allow를 무시하기 때문에 이 정책은 다른 2개 정책을 무시합니다.\]](http://docs.aws.amazon.com/ko_kr/AWSSimpleQueueService/latest/SQSDeveloperGuide/images/sqs-iam-policies-deny-override.png)
Bob이 어떤 방식으로 대기열에 액세스하든 간에 거부하는 문을 Amazon SQS 정책에 추가할 수도 있습니다. 이것은 Bob의 대기열 액세스를 거부하는 IAM 정책을 추가하는 것과 동일한 효과가 있습니다. Amazon SQS 작업 및 리소스에 대한 정책의 예는 [Amazon SQS 정책의 기본 예제](sqs-basic-examples-of-sqs-policies.md)에서 확인하세요. Amazon SQS 정책 작성에 대한 자세한 내용은 [Amazon SQS 액세스 정책 언어와 함께 사용자 지정 정책 사용](sqs-creating-custom-policies.md) 섹션을 참조하세요.
## Amazon SQS 콘솔 사용에 필요한 권한
사용자가 Amazon SQS 콘솔로 작업하려면 사용자의 AWS 계정에서 Amazon SQS 대기열로 작업할 수 있는 최소 개수의 권한이 있어야 합니다. 예를 들어, 사용자에게 `ListQueues` 작업을 호출할 권한이 있어 대기열을 나열할 수 있거나 `CreateQueue` 작업을 호출할 권한이 있어 대기열을 생성할 수 있어야 합니다. Amazon SQS 권한 외에도 Amazon SQS 대기열에서 Amazon SNS 주제를 구독하려면 콘솔에 Amazon SNS 작업에 대한 권한도 있어야 합니다.
최소 필수 권한보다 더 제한적인 IAM 정책을 만들면 콘솔은 해당 IAM 정책에 연결된 사용자에 대해 의도대로 작동하지 않을 수 있습니다.
AWS CLI 또는 Amazon SQS 작업만 호출하는 사용자에게는 최소 콘솔 권한을 허용할 필요가 없습니다.
# Amazon SQS의 자격 증명 기반 정책 예
기본적으로 사용자 및 역할은 Amazon SQS 리소스를 생성하거나 수정할 수 있는 권한이 없습니다. 사용자에게 사용자가 필요한 리소스에서 작업을 수행할 권한을 부여하려면 IAM 관리자가 IAM 정책을 생성하면 됩니다.
이러한 예제 JSON 정책 문서를 사용하여 IAM ID 기반 정책을 생성하는 방법을 알아보려면 *IAM 사용 설명서*의 [IAM 정책 생성(콘솔)](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies_create-console.html)을 참조하세요.
각 리소스 유형에 대한 ARN 형식을 포함하여 Amazon SQS에서 정의한 작업 및 리소스 유형에 대한 자세한 내용은 **서비스 권한 부여 참조에서 [Amazon Simple Queue Service에 대한 작업, 리소스 및 조건 키](https://docs.aws.amazon.com/IAM/latest/UserGuide/list_amazonsqs.html)를 참조하세요.
**참고**
Amazon EC2 Auto Scaling의 수명 주기 후크를 구성할 때 Amazon SQS 대기열로 메시지를 전송하는 정책을 작성하지 않아도 됩니다. 자세한 설명은 *Amazon EC2 사용자 가이드*의 [Amazon EC2 Auto Scaling 수명 주기 후크](https://docs.aws.amazon.com/autoscaling/ec2/userguide/lifecycle-hooks.html)를 참조하세요.
## 정책 모범 사례
ID 기반 정책에 따라 계정에서 사용자가 Amazon SQS 리소스를 생성, 액세스 또는 삭제할 수 있는지 여부가 결정됩니다. 이 작업으로 인해 AWS 계정에 비용이 발생할 수 있습니다. ID 기반 정책을 생성하거나 편집할 때는 다음 지침과 권장 사항을 따르세요.
+ ** AWS 관리형 정책을 시작하고 최소 권한으로 전환 -** 사용자 및 워크로드에 권한 부여를 시작하려면 많은 일반적인 사용 사례에 대한 권한을 부여하는 *AWS 관리형 정책을* 사용합니다. 에서 사용할 수 있습니다 AWS 계정. 사용 사례에 맞는 AWS 고객 관리형 정책을 정의하여 권한을 추가로 줄이는 것이 좋습니다. 자세한 내용은 *IAM 사용 설명서*의 [AWS 관리형 정책](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies_managed-vs-inline.html#aws-managed-policies) 또는 [AWS 직무에 대한 관리형 정책](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies_job-functions.html)을 참조하세요.
+ **최소 권한 적용** – IAM 정책을 사용하여 권한을 설정하는 경우, 작업을 수행하는 데 필요한 권한만 부여합니다. 이렇게 하려면 *최소 권한*으로 알려진 특정 조건에서 특정 리소스에 대해 수행할 수 있는 작업을 정의합니다. IAM을 사용하여 권한을 적용하는 방법에 대한 자세한 정보는 *IAM 사용 설명서*에 있는 [IAM의 정책 및 권한](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies.html)을 참조하세요.
+ **IAM 정책의 조건을 사용하여 액세스 추가 제한** – 정책에 조건을 추가하여 작업 및 리소스에 대한 액세스를 제한할 수 있습니다. 예를 들어, SSL을 사용하여 모든 요청을 전송해야 한다고 지정하는 정책 조건을 작성할 수 있습니다. AWS 서비스와 같은 특정를 통해 사용되는 경우 조건을 사용하여 서비스 작업에 대한 액세스 권한을 부여할 수도 있습니다 CloudFormation. 자세한 내용은 *IAM 사용 설명서*의 [IAM JSON 정책 요소: 조건](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_policies_elements_condition.html)을 참조하세요.
+ **IAM Access Analyzer를 통해 IAM 정책을 확인하여 안전하고 기능적인 권한 보장** - IAM Access Analyzer에서는 IAM 정책 언어(JSON)와 모범 사례가 정책에서 준수되도록 새로운 및 기존 정책을 확인합니다. IAM Access Analyzer는 100개 이상의 정책 확인 항목과 실행 가능한 추천을 제공하여 안전하고 기능적인 정책을 작성하도록 돕습니다. 자세한 내용은 *IAM 사용 설명서*의 [IAM Access Analyzer에서 정책 검증](https://docs.aws.amazon.com/IAM/latest/UserGuide/access-analyzer-policy-validation.html)을 참조하세요.
+ **다중 인증(MFA) 필요 -**에서 IAM 사용자 또는 루트 사용자가 필요한 시나리오가 있는 경우 추가 보안을 위해 MFA를 AWS 계정켭니다. API 작업을 직접적으로 호출할 때 MFA가 필요하면 정책에 MFA 조건을 추가합니다. 자세한 내용은 *IAM 사용 설명서*의 [MFA를 통한 보안 API 액세스](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_credentials_mfa_configure-api-require.html)를 참조하세요.
IAM의 모범 사례에 대한 자세한 내용은 *IAM 사용 설명서*의 [IAM의 보안 모범 사례](https://docs.aws.amazon.com/IAM/latest/UserGuide/best-practices.html)를 참조하세요.
## Amazon SQS 콘솔 사용
Amazon Simple Queue Service 콘솔에 액세스하려면 최소한의 권한 집합이 있어야 합니다. 이러한 권한은에서 Amazon SQS 리소스에 대한 세부 정보를 나열하고 볼 수 있도록 허용해야 합니다 AWS 계정. 최소 필수 권한보다 더 제한적인 ID 기반 정책을 생성하는 경우, 콘솔이 해당 정책에 연결된 엔티티(사용자 또는 역할)에 대해 의도대로 작동하지 않습니다.
AWS CLI 또는 AWS API만 호출하는 사용자에게는 최소 콘솔 권한을 허용할 필요가 없습니다. 대신, 수행하려는 API 작업과 일치하는 작업에만 액세스할 수 있도록 합니다.
사용자와 역할이 여전히 Amazon SQS 콘솔을 사용할 수 있도록 하려면 Amazon SQS `AmazonSQSReadOnlyAccess` AWS 관리형 정책도 엔터티에 연결합니다. 자세한 내용은 *IAM 사용 설명서*의 [사용자에게 권한 추가](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_users_change-permissions.html#users_change_permissions-add-console)를 참조하세요.
## 사용자가 자신의 고유한 권한을 볼 수 있도록 허용
이 예제는 IAM 사용자가 자신의 사용자 ID에 연결된 인라인 및 관리형 정책을 볼 수 있도록 허용하는 정책을 생성하는 방법을 보여 줍니다. 이 정책에는 콘솔에서 또는 AWS CLI 또는 AWS API를 사용하여 프로그래밍 방식으로이 작업을 완료할 수 있는 권한이 포함됩니다.
```
{
"Version": "2012-10-17",
"Statement": [
{
"Sid": "ViewOwnUserInfo",
"Effect": "Allow",
"Action": [
"iam:GetUserPolicy",
"iam:ListGroupsForUser",
"iam:ListAttachedUserPolicies",
"iam:ListUserPolicies",
"iam:GetUser"
],
"Resource": ["arn:aws:iam::*:user/${aws:username}"]
},
{
"Sid": "NavigateInConsole",
"Effect": "Allow",
"Action": [
"iam:GetGroupPolicy",
"iam:GetPolicyVersion",
"iam:GetPolicy",
"iam:ListAttachedGroupPolicies",
"iam:ListGroupPolicies",
"iam:ListPolicyVersions",
"iam:ListPolicies",
"iam:ListUsers"
],
"Resource": "*"
}
]
}
```
## 사용자가 대기열을 생성하도록 허용
다음 예제에서는 Bob이 모든 Amazon SQS 작업에 액세스할 수 있도록 정책을 생성하지만, 리터럴 문자열 `alice_queue_`로 시작하는 이름을 가진 대기열에만 해당됩니다.
Amazon SQS는 대기열 생성자에게 대기열 사용 권한을 자동으로 부여하지 않습니다. 따라서 IAM 정책의 `CreateQueue` 작업 외에도 모든 Amazon SQS 작업을 사용할 수 있는 권한을 Bob에게 명시적으로 부여해야 합니다.
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement": [{
"Effect": "Allow",
"Action": "sqs:*",
"Resource": "arn:aws:sqs:*:123456789012:alice_queue_*"
}]
}
```
------
## 개발자가 메시지를 공유 대기열에 작성하도록 허용
다음 예제에서는 개발자를 위한 그룹을 생성하고 그룹이 Amazon SQS `SendMessage` 작업을 사용하도록 허용하는 정책을 연결합니다. 단, 지정된에 속 AWS 계정 하고 이름이 인 대기열에서만 가능합니다`MyCompanyQueue`.
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement": [{
"Effect": "Allow",
"Action": "sqs:SendMessage",
"Resource": "arn:aws:sqs:*:123456789012:MyCompanyQueue"
}]
}
```
------
`SendMessage` 대신에 `*`를 사용하여 공유 대기열에서 보안 주체에게 `ChangeMessageVisibility`, `DeleteMessage`, `GetQueueAttributes`, `GetQueueUrl`, `ReceiveMessage` 및 `SendMessage` 작업을 허용할 수 있습니다.
**참고**
`*`에는 다른 권한 유형에서 제공하는 액세스 권한이 포함되나 Amazon SQS는 권한을 개별적으로 고려합니다. 예를 들어, `*`에 `SendMessage`에서 제공하는 액세스 권한이 포함되어 있더라도 `*` 및 `SendMessage` 권한을 사용자에게 부여할 수 있습니다.
이 개념은 권한을 제거할 때도 적용됩니다. 보안 주체가 `*` 권한만 있는 경우, `SendMessage` 권한을 제거하도록 요청해도 보안 주체에게 everything-but** 권한이 남는 것은 아닙니다**. 그 대신 보안 주체가 명시적 `SendMessage` 권한을 소유하지 않았기 때문에 이 요청은 아무런 영향도 주지 않습니다. `ReceiveMessage` 권한만 보안 주체에게 남기려면 먼저 `ReceiveMessage` 권한을 추가한 후 `*` 권한을 제거합니다.
## 관리자가 일반 크기의 대기열을 가져오도록 허용
다음 예제에서는 관리자를 위한 그룹을 생성하고 그룹이 지정된 AWS 계정에 속한 모든 대기열과 함께 Amazon SQS `GetQueueAttributes` 작업을 사용하도록 허용하는 정책을 연결합니다.
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement": [{
"Effect": "Allow",
"Action": "sqs:GetQueueAttributes",
"Resource": "*"
}]
}
```
------
## 파트너가 메시지를 특정 대기열로 전송하도록 허용
Amazon SQS 정책 또는 IAM 정책을 사용하여 이 작업을 완료할 수 있습니다. 파트너에게이 있는 경우 Amazon SQS 정책을 사용하는 AWS 계정것이 더 쉬울 수 있습니다. 그러나 파트너의 회사에서 AWS 보안 자격 증명을 소유한 모든 사용자는 대기열에 메시지를 보낼 수 있습니다. 액세스를 특정 사용자나 애플리케이션으로 제한하려면, 파트너를 본인 회사의 사용자처럼 다루면서 Amazon SQS 정책이 아닌 IAM 정책을 사용해야 합니다.
이 예제에서는 다음 작업을 수행합니다.
1. 파트너사를 나타내는 WidgetCo라는 그룹을 생성합니다.
1. 파트너사에서 액세스 권한을 필요로 하는 특정 사용자나 애플리케이션을 위해 사용자를 생성합니다.
1. 사용자를 그룹에 추가합니다.
1. `WidgetPartnerQueue`라는 대기열에서만 `SendMessage` 작업에 유일하게 액세스할 수 있는 권한을 이 그룹에 부여하는 정책을 연결합니다.
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement": [{
"Effect": "Allow",
"Action": "sqs:SendMessage",
"Resource": "arn:aws:sqs:*:123456789012:WidgetPartnerQueue"
}]
}
```
------
# Amazon SQS 정책의 기본 예제
이 단원에서는 일반 Amazon SQS 사용 사례에 대한 정책 예제를 보여줍니다.
콘솔을 사용하여 정책을 사용자에게 연결할 때 각 정책의 효과를 확인할 수 있습니다. 처음에 사용자는 권한을 가지고 있지 않으며 콘솔에서 어떠한 작업도 수행할 수 없습니다. 정책을 사용자에게 연결하면 사용자가 콘솔에서 다양한 작업을 수행할 수 있는지 확인할 수 있습니다.
**참고**
두 개의 브라우저 창을 사용하는 것이 좋습니다. 하나는 권한을 부여하고 다른 하나는 권한을 부여할 때 사용자의 자격 증명을 AWS Management Console 사용하여에 로그인하여 권한을 확인하는 것입니다.
## 예제 1: 하나의에 하나의 권한 부여 AWS 계정
다음 예제 정책은 미국 동부(오하`111122223333`이오) 리전`444455556666/queue1`에서 라는 대기열에 대한 `SendMessage` 권한을 AWS 계정 번호에 부여합니다.
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Id": "Queue1_Policy_UUID",
"Statement": [{
"Sid":"Queue1_SendMessage",
"Effect": "Allow",
"Principal": {
"AWS": [
"111122223333"
]
},
"Action": "sqs:SendMessage",
"Resource": "arn:aws:sqs:us-east-2:444455556666:queue1"
}]
}
```
------
## 예제 2: 한에 두 가지 권한 부여 AWS 계정
다음 예제 정책은 이라는 대기열에 대해 `SendMessage` 및 `ReceiveMessage` 권한을 AWS 계정 `111122223333` 모두 부여합니다`444455556666/queue1`.
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Id": "Queue1_Policy_UUID",
"Statement": [{
"Sid":"Queue1_Send_Receive",
"Effect": "Allow",
"Principal": {
"AWS": [
"111122223333"
]
},
"Action": [
"sqs:SendMessage",
"sqs:ReceiveMessage"
],
"Resource": "arn:aws:sqs:*:444455556666:queue1"
}]
}
```
------
## 예제 3: 2에 모든 권한 부여 AWS 계정
다음 예제 정책은 Amazon SQS가 미국 동부(`111122223333`오하이오`444455556666`) 리전`123456789012/queue1`에서 라는 대기열에 대한 공유 액세스를 허용하는 모든 작업을 사용할 수 있는 두 개의 서로 다른 AWS 계정 번호( 및 ) 권한을 부여합니다. Amazon SQS
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Id": "Queue1_Policy_UUID",
"Statement": [{
"Sid":"Queue1_AllActions",
"Effect": "Allow",
"Principal": {
"AWS": [
"111122223333",
"444455556666"
]
},
"Action": "sqs:*",
"Resource": "arn:aws:sqs:us-east-2:123456789012:queue1"
}]
}
```
------
## 예제 4: 역할과 사용자 이름에 교차 계정 권한 부여
다음 예제 정책은 Amazon SQS가 미국 동부(오하이오) 리전`123456789012/queue1`에서 라는 대기열에 대한 공유 액세스를 허용하는 모든 작업을 사용할 수 있는 `111122223333` 교차 계정 권한을 및 AWS 계정 번호 `role1` `username1` 아래에 부여합니다.
다음 작업에는 교차 계정 권한이 적용되지 않습니다.
+ `[AddPermission](https://docs.aws.amazon.com/AWSSimpleQueueService/latest/APIReference/API_AddPermission.html)`
+ `[CancelMessageMoveTask](https://docs.aws.amazon.com/AWSSimpleQueueService/latest/APIReference/API_CancelMessageMoveTask.html)`
+ `[CreateQueue](https://docs.aws.amazon.com/AWSSimpleQueueService/latest/APIReference/API_CreateQueue.html)`
+ `[DeleteQueue](https://docs.aws.amazon.com/AWSSimpleQueueService/latest/APIReference/API_DeleteQueue.html)`
+ `[ListMessageMoveTask](https://docs.aws.amazon.com/AWSSimpleQueueService/latest/APIReference/API_ListMessageMoveTasks.html)`
+ `[ListQueues](https://docs.aws.amazon.com/AWSSimpleQueueService/latest/APIReference/API_ListQueues.html)`
+ `[ListQueueTags](https://docs.aws.amazon.com/AWSSimpleQueueService/latest/APIReference/API_ListQueueTags.html)`
+ `[RemovePermission](https://docs.aws.amazon.com/AWSSimpleQueueService/latest/APIReference/API_RemovePermission.html)`
+ `[SetQueueAttributes](https://docs.aws.amazon.com/AWSSimpleQueueService/latest/APIReference/API_SetQueueAttributes.html)`
+ `[StartMessageMoveTask](https://docs.aws.amazon.com/AWSSimpleQueueService/latest/APIReference/API_StartMessageMoveTask.html)`
+ `[TagQueue](https://docs.aws.amazon.com/AWSSimpleQueueService/latest/APIReference/API_TagQueue.html)`
+ `[UntagQueue](https://docs.aws.amazon.com/AWSSimpleQueueService/latest/APIReference/API_UntagQueue.html)`
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Id": "Queue1_Policy_UUID",
"Statement": [{
"Sid":"Queue1_AllActions",
"Effect": "Allow",
"Principal": {
"AWS": [
"arn:aws:iam::111122223333:role/role1",
"arn:aws:iam::111122223333:user/username1"
]
},
"Action": "sqs:*",
"Resource": "arn:aws:sqs:us-east-2:123456789012:queue1"
}]
}
```
------
## 예제 5: 모든 사용자에게 권한 부여
다음 정책 예제에서는 `111122223333/queue1`이라는 대기열에 대한 `ReceiveMessage` 권한을 모든 사용자(익명 사용자)에게 부여합니다.
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Id": "Queue1_Policy_UUID",
"Statement": [{
"Sid":"Queue1_AnonymousAccess_ReceiveMessage",
"Effect": "Allow",
"Principal": "*",
"Action": "sqs:ReceiveMessage",
"Resource": "arn:aws:sqs:*:111122223333:queue1"
}]
}
```
------
## 예제 6: 모든 사용자에게 시간 제한적인 권한 부여
다음 정책 예제는 모든 사용자(익명 사용자)에게 `111122223333/queue1`라는 이름의 대기열에 대한 `ReceiveMessage` 권한을 부여하지만, 2009년 1월 31일에는 오후 12시(정오)부터 오후 3시까지만 가능합니다.
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Id": "Queue1_Policy_UUID",
"Statement": [{
"Sid":"Queue1_AnonymousAccess_ReceiveMessage_TimeLimit",
"Effect": "Allow",
"Principal": "*",
"Action": "sqs:ReceiveMessage",
"Resource": "arn:aws:sqs:*:111122223333:queue1",
"Condition" : {
"DateGreaterThan" : {
"aws:CurrentTime":"2009-01-31T12:00Z"
},
"DateLessThan" : {
"aws:CurrentTime":"2009-01-31T15:00Z"
}
}
}]
}
```
------
## 예제 7: CIDR 범위의 모든 사용자에게 모든 권한 부여
다음 정책 예제에서는 모든 사용자(익명 사용자)에게 `111122223333/queue1`이라는 대기열에서 공유 가능한 모든 Amazon SQS 작업을 사용할 수 있는 권한을 부여하지만, 이것은 요청이 `192.0.2.0/24` CIDR 범위에서 들어오는 경우에 한합니다.
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Id": "Queue1_Policy_UUID",
"Statement": [{
"Sid":"Queue1_AnonymousAccess_AllActions_AllowlistIP",
"Effect": "Allow",
"Principal": "*",
"Action": "sqs:*",
"Resource": "arn:aws:sqs:*:111122223333:queue1",
"Condition" : {
"IpAddress" : {
"aws:SourceIp":"192.0.2.0/24"
}
}
}]
}
```
------
## 예제 8: 서로 다른 CIDR 범위의 사용자에게 권한 허용(화이트리스트) 및 차단(블랙리스트)
다음의 정책 예제에는 문이 2개입니다.
+ 첫 번째 문은 `192.0.2.0/24` CIDR 범위(`192.0.2.188` 제외)에 있는 모든 사용자(익명 사용자)에게 `111122223333`/queue1이라는 대기열에서 `SendMessage` 작업을 사용할 수 있는 권한을 부여합니다.
+ 두 번째 설명은 `12.148.72.0/23` CIDR 범위의 모든 사용자(익명 사용자)가 대기열을 사용하지 못하도록 차단합니다.
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Id": "Queue1_Policy_UUID",
"Statement": [{
"Sid":"Queue1_AnonymousAccess_SendMessage_IPLimit",
"Effect": "Allow",
"Principal": "*",
"Action": "sqs:SendMessage",
"Resource": "arn:aws:sqs:*:111122223333:queue1",
"Condition" : {
"IpAddress" : {
"aws:SourceIp":"192.0.2.0/24"
},
"NotIpAddress" : {
"aws:SourceIp":"192.0.2.188/32"
}
}
}, {
"Sid":"Queue1_AnonymousAccess_AllActions_IPLimit_Deny",
"Effect": "Deny",
"Principal": "*",
"Action": "sqs:*",
"Resource": "arn:aws:sqs:*:111122223333:queue1",
"Condition" : {
"IpAddress" : {
"aws:SourceIp":"12.148.72.0/23"
}
}
}]
}
```
------
# Amazon SQS 액세스 정책 언어와 함께 사용자 지정 정책 사용
AWS 계정 ID만을 기반으로 기본 권한(예: [https://docs.aws.amazon.com/AWSSimpleQueueService/latest/APIReference/API_SendMessage.html](https://docs.aws.amazon.com/AWSSimpleQueueService/latest/APIReference/API_SendMessage.html) 또는 [https://docs.aws.amazon.com/AWSSimpleQueueService/latest/APIReference/API_ReceiveMessage.html](https://docs.aws.amazon.com/AWSSimpleQueueService/latest/APIReference/API_ReceiveMessage.html))을 부여하려면 사용자 지정 정책을 작성할 필요가 없습니다. 대신 Amazon SQS [https://docs.aws.amazon.com/AWSSimpleQueueService/latest/APIReference/API_AddPermission.html](https://docs.aws.amazon.com/AWSSimpleQueueService/latest/APIReference/API_AddPermission.html) 작업을 사용합니다.
요청 시간 또는 요청자의 IP 주소와 같은 특정 조건에 따라 액세스를 허용하거나 거부하려면 사용자 지정 Amazon SQS 정책을 생성하고 [SetQueueAttributes](https://docs.aws.amazon.com/AWSSimpleQueueService/latest/APIReference/API_SetQueueAttributes.html) 작업을 사용하여 업로드해야 합니다.
**Topics**
+ [액세스 제어 아키텍처](sqs-creating-custom-policies-architecture.md)
+ [액세스 제어 프로세스 워크플로](sqs-creating-custom-policies-process-workflow.md)
+ [Amazon SQS 액세스 정책 언어 주요 개념](sqs-creating-custom-policies-key-concepts.md)
+ [액세스 정책 언어 평가 로직](sqs-creating-custom-policies-evaluation-logic.md)
+ [명시적 거부와 기본 거부의 관계](sqs-creating-custom-policies-relationships-between-explicit-default-denials.md)
+ [사용자 지정 정책 제한](sqs-limitations-of-custom-policies.md)
+ [사용자 지정 액세스 정책 언어 예제](sqs-creating-custom-policies-access-policy-examples.md)
# Amazon SQS 액세스 제어 아키텍처
다음 그림에서는 Amazon SQS 리소스의 액세스 제어에 대해 설명합니다.
![\[Amazon SQS 리소스의 액세스 제어에 대해 설명합니다.\]](http://docs.aws.amazon.com/ko_kr/AWSSimpleQueueService/latest/SQSDeveloperGuide/images/AccessPolicyLanguage_Arch_Overview.png)
![\[In the previous diagram, section number one.\]](http://docs.aws.amazon.com/ko_kr/AWSSimpleQueueService/latest/SQSDeveloperGuide/images/number-1-red.png)리소스 소유자
![\[In the previous diagram, section number two.\]](http://docs.aws.amazon.com/ko_kr/AWSSimpleQueueService/latest/SQSDeveloperGuide/images/number-2-red.png) AWS 서비스 내에 포함된 리소스(예: Amazon SQS 대기열).
![\[In the previous diagram, section number three.\]](http://docs.aws.amazon.com/ko_kr/AWSSimpleQueueService/latest/SQSDeveloperGuide/images/number-3-red.png) 정책. 리소스당 하나의 정책을 가지는 것이 좋습니다. AWS 서비스는 정책을 업로드하고 관리하는 데 사용하는 API를 제공합니다.
![\[In the previous diagram, section number four.\]](http://docs.aws.amazon.com/ko_kr/AWSSimpleQueueService/latest/SQSDeveloperGuide/images/number-4-red.png) 요청자 및 요청자가 AWS 서비스에서 수신하는 요청.
![\[In the previous diagram, section number five.\]](http://docs.aws.amazon.com/ko_kr/AWSSimpleQueueService/latest/SQSDeveloperGuide/images/number-5-red.png) 액세스 정책 언어 평가 코드. 이는 서비스 내에서 해당 정책을 기준으로 수신 요청을 AWS 평가하고 요청자가 리소스에 액세스할 수 있는지 여부를 결정하는 코드 세트입니다.
# Amazon SQS 액세스 제어 프로세스 워크플로
다음 그림에서는 Amazon SQS 액세스 정책 언어를 사용한 일반적인 액세스 제어 워크플로를 설명합니다.
![\[Amazon SQS 액세스 정책 언어를 사용한 일반적인 액세스 제어 워크플로입니다.\]](http://docs.aws.amazon.com/ko_kr/AWSSimpleQueueService/latest/SQSDeveloperGuide/images/AccessPolicyLanguage_Basic_Flow.png)
![\[Figure one in the previous diagram.\]](http://docs.aws.amazon.com/ko_kr/AWSSimpleQueueService/latest/SQSDeveloperGuide/images/number-1-red.png) 대기열에 대한 Amazon SQS 정책을 작성합니다.
![\[Figure two in the previous diagram.\]](http://docs.aws.amazon.com/ko_kr/AWSSimpleQueueService/latest/SQSDeveloperGuide/images/number-2-red.png) 정책을에 업로드합니다 AWS. AWS 서비스는 정책을 업로드하는 데 사용하는 API를 제공합니다. 예를 들어 Amazon SQS `SetQueueAttributes` 작업을 사용하여 특정 Amazon SQS 대기열에 대한 정책을 업로드합니다.
![\[Figure three in the previous diagram.\]](http://docs.aws.amazon.com/ko_kr/AWSSimpleQueueService/latest/SQSDeveloperGuide/images/number-3-red.png) 누군가가 Amazon SQS 대기열을 사용하기 위해 요청을 보냅니다.
![\[Figure four in the previous diagram.\]](http://docs.aws.amazon.com/ko_kr/AWSSimpleQueueService/latest/SQSDeveloperGuide/images/number-4-red.png) Amazon SQS에서는 사용 가능한 모든 Amazon SQS 정책을 검사하고 어느 정책을 적용할 수 있는지 결정합니다.
![\[Figure five in the previous diagram.\]](http://docs.aws.amazon.com/ko_kr/AWSSimpleQueueService/latest/SQSDeveloperGuide/images/number-5-red.png) Amazon SQS에서는 정책을 평가하고 요청자의 대기열 사용을 허용할지 여부를 결정합니다.
![\[Figure six in the previous diagram.\]](http://docs.aws.amazon.com/ko_kr/AWSSimpleQueueService/latest/SQSDeveloperGuide/images/number-6-red.png) 이를테면 정책 평가 결과에 따라 Amazon SQS가 `Access denied` 오류를 요청자에게 반환하거나 계속 요청을 처리합니다.
# Amazon SQS 액세스 정책 언어 주요 개념
고유한 정책을 작성하려면 [JSON](http://json.org/)과 많은 주요 개념에 대해 잘 알고 있어야 합니다.
**허용**
`allow`로 설정된 [효과](#effect)이(가) 있는 [Statement](#statement)의 결과.
**작업**
[보안 주체](#principal)가 일반적으로 AWS에 대한 요청을 수행할 권한이 있는 활동입니다.
**Default-deny**
[허용](#allow) 또는 [Explicit-deny](#explicit-deny) 설정이 없는 [Statement](#statement)의 결과입니다.
**조건**
[권한](#permission)에 대한 제한 또는 세부 정보입니다. 일반적인 조건은 날짜 및 시간과 IP 주소와 관련되어 있습니다.
**효과**
[정책](#policy)의 [Statement](#statement)이(가) 평가 시간에 반환하는 결과. 정책 설명을 작성할 때 `deny` 또는 `allow` 값을 지정합니다. 정책 평가 시간에 [Default-deny](#default-deny), [허용](#allow) 및 [Explicit-deny](#explicit-deny) 결과가 나올 수 있습니다.
**Explicit-deny**
`deny`로 설정된 [효과](#effect)이(가) 있는 [Statement](#statement)의 결과.
**평가**
Amazon SQS에서 수신한 요청을 [정책](#policy)에 따라 거부할지 또는 허용할지 결정하는 데 이용하는 프로세스입니다.
**발행자**
리소스에 권한을 부여하기 위해 [정책](#policy)을 작성하는 사용자입니다. 발급자는 항상 리소스 소유자입니다. AWS 는 Amazon SQS 사용자가 소유하지 않은 리소스에 대한 정책을 생성하도록 허용하지 않습니다.
**Key(키)**
액세스 제한의 기준이 되는 구체적 특성입니다.
**권한**
[조건](#condition) 및 [Key(키)](#key)를 사용하여 리소스에 대한 액세스를 허용하거나 허용하지 않는 개념입니다.
**정책**
하나 이상의 **[설명에 대한 컨테이너 역할을 하는 문서입니다](#statement)**.
![\[문 1과 문 2가 포함된 정책 A는 문 1이 포함된 정책 A와 문 2가 포함된 정책 B와 동일합니다.\]](http://docs.aws.amazon.com/ko_kr/AWSSimpleQueueService/latest/SQSDeveloperGuide/images/AccessPolicyLanguage_Statement_and_Policy.png)
Amazon SQS는 사용자에게 리소스에 대한 액세스 권한을 부과할지 결정하는 정책을 사용합니다.
**보안 주체**
[정책](#policy)에서 [권한](#permission)을 수신하는 사용자입니다.
**리소스**
[보안 주체](#principal) 요청이 액세스하는 객체입니다.
**Statement**
단일 권한에 대한 공식적인 설명이며, 보다 폭넓은 [정책](#policy) 문서의 일환으로서 액세스 정책 언어로 작성됩니다.
**요청자**
[리소스](#resource)에 액세스 요청을 전송하는 사용자입니다.
# Amazon SQS 액세스 정책 언어 평가 로직
평가 시점에 Amazon SQS는 리소스 소유자 이외의 다른 사람의 요청을 허용할지 또는 거부할지 결정합니다. 평가 로직에서는 몇 가지 기본 규칙을 따릅니다.
+ 기본적으로, 본인을 제외한 사람이 리소스를 사용하겠다고 요청하면 모두 거부됩니다.
+ *[허용](sqs-creating-custom-policies-key-concepts.md#allow)*는 모든 *[Default-deny](sqs-creating-custom-policies-key-concepts.md#default-deny)*를 재정의합니다.
+ *[Explicit-deny](sqs-creating-custom-policies-key-concepts.md#explicit-deny)*는 모든 **허용**을 재정의합니다.
+ 정책이 평가되는 순서는 중요하지 않습니다.
다음 그림에서는 Amazon SQS가 액세스 권한에 대한 결정을 평가하는 방식에 대해 자세히 설명합니다.
![\[Amazon SQS가 액세스 권한에 대한 결정을 평가하는 방법을 설명하는 흐름도입니다.\]](http://docs.aws.amazon.com/ko_kr/AWSSimpleQueueService/latest/SQSDeveloperGuide/images/AccessPolicyLanguage_Evaluation_Flow.png)
![\[In the previous diagram, number one.\]](http://docs.aws.amazon.com/ko_kr/AWSSimpleQueueService/latest/SQSDeveloperGuide/images/number-1-red.png) 결정은 **기본 거부**에서 시작합니다.
![\[In the previous diagram, number two.\]](http://docs.aws.amazon.com/ko_kr/AWSSimpleQueueService/latest/SQSDeveloperGuide/images/number-2-red.png)적용 코드에서 (리소스, 보안 주체, 작업, 조건을 고려하여) 해당 요청에 적용 가능한 모든 정책을 평가합니다. 적용 코드에서 정책을 평가하는 순서는 중요하지 않습니다.
![\[In the previous diagram, number three.\]](http://docs.aws.amazon.com/ko_kr/AWSSimpleQueueService/latest/SQSDeveloperGuide/images/number-3-red.png) 적용 코드는 해당 요청에 적용할 수 있는 **명시적 거부** 명령을 찾습니다. 하나라도 찾으면 이 적용 코드는 **거부** 결정을 반환하고 프로세스는 종료됩니다.
![\[In the previous diagram, number four.\]](http://docs.aws.amazon.com/ko_kr/AWSSimpleQueueService/latest/SQSDeveloperGuide/images/number-4-red.png) **명시적 거부** 명령이 없을 경우 적용 코드는 해당 요청에 적용할 수 있는 **허용** 명령을 찾습니다. 하나라도 찾으면 적용 코드는 **허용** 결정을 반환하고 프로세스가 완료됩니다(서비스에서는 계속 요청을 처리함).
![\[In the previous diagram, number five.\]](http://docs.aws.amazon.com/ko_kr/AWSSimpleQueueService/latest/SQSDeveloperGuide/images/number-5-red.png) **허용** 명령이 없을 경우 최종 결정은 **거부**입니다. **명시적 거부** 또는 **허용**이 없으므로 **기본 거부**로 간주됩니다.
# Amazon SQS 액세스 정책 언어의 명시적 거부와 기본 거부 간의 관계
Amazon SQS 정책이 요청에 직접 적용되지 않으면 요청 결과는 *[Default-deny](sqs-creating-custom-policies-key-concepts.md#default-deny)*입니다. 예를 들어, 한 사용자가 Amazon SQS 사용 권한을 요청했지만 해당 사용자에게 적용되는 유일한 정책에서 DynamoDB를 사용할 수 있으면, 요청 결과는 **기본 거부**가 됩니다.
설명의 조건이 충족되지 않을 경우에도 요청 결과는 **기본 거부**가 됩니다. 문의 모든 조건이 충족되면 요청은 정책의 *[효과](sqs-creating-custom-policies-key-concepts.md#effect)* 요소 값에 따라 *[허용](sqs-creating-custom-policies-key-concepts.md#allow)* 또는 *[Explicit-deny](sqs-creating-custom-policies-key-concepts.md#explicit-deny)*로 처리됩니다. 정책에서는 어떤 조건이 충족되지 않을 때 해야 할 일을 지정하지 않으므로, 이러한 경우 기본 결과는 **기본 거부**가 됩니다. 예를 들어 남극 대륙에서 오는 요청을 차단하고 싶다면 남극 대륙에서 오지 않은 요청만 허용하는 정책 A1을 작성하면 됩니다. 다음 다이어그램은 Amazon SQS 정책을 보여줍니다.
![\[정책 A1은 허용과 동일한 효과와 남극 대륙에서 보낸 요청이 아닌 경우와 동일한 조건을 포함합니다.\]](http://docs.aws.amazon.com/ko_kr/AWSSimpleQueueService/latest/SQSDeveloperGuide/images/sqs-security-custom-policy-allow-request-if-not-from-antarctica.png)
사용자가 미국에서 요청을 보낼 경우 (남극 대륙에서 온 요청이 아니므로) 조건을 충족하고, 요청 결과는 **허용**이 됩니다. 그러나 사용자가 남극 대륙에서 요청을 보낸다면 조건이 충족되지 않으므로 요청 결과는 **기본 거부**가 됩니다. 이 결과를 **명시적 거부**로 변경하려면 남극 대륙에서 온 요청을 명시적으로 거부하는 정책 A2를 작성합니다. 다음 다이어그램은 이 정책을 보여줍니다.
![\[정책 A2는 거부와 동일한 효과와 남극 대륙에서 보낸 요청이 있는 경우와 동일한 조건을 포함합니다.\]](http://docs.aws.amazon.com/ko_kr/AWSSimpleQueueService/latest/SQSDeveloperGuide/images/sqs-security-custom-policy-explicitly-deny-request-if-from-antarctica.png)
사용자가 남극 대륙에서 요청을 보낸다면 조건이 충족되므로 요청 결과는 **명시적 거부**가 됩니다.
**허용**은 **기본 거부**를 덮어쓸 수 있지만 **명시적 거부**는 덮어쓸 수 없기 때문에 전자와 후자를 구분하는 것이 중요합니다. 예를 들어, 요청이 2010년 6월 1일에 도착하면 정책 B는 요청을 허용합니다. 다음 다이어그램은 이 정책을 정책 A1과 정책 A2 조합을 비교한 것입니다.
![\[시나리오 1과 시나리오 2를 나란히 비교한 결과입니다.\]](http://docs.aws.amazon.com/ko_kr/AWSSimpleQueueService/latest/SQSDeveloperGuide/images/sqs-security-custom-policy-compare-allow-request-deny-request-policies-override.png)
시나리오 1에서 이 정책은 2010년 6월 1일에 들어오는 요청을 허용하기 때문에 정책 A1의 결과는 **기본 거부**가 되고 정책 B의 결과는 **허용**이 됩니다. 정책 B의 **허용**은 정책 A1의 **기본 거부**보다 우선하므로 이 요청은 허용됩니다.
시나리오 2에서 정책 B2의 결과는 **명시적 거부**이고 정책 B의 결과는 **허용**입니다. 정책 A2의 **명시적 거부**는 정책 B의 **허용**보다 우선하고 이 요청은 거부됩니다.
# Amazon SQS 사용자 지정 정책의 제한 사항
## 크로스 계정 액세스
다음 작업에는 교차 계정 권한이 적용되지 않습니다.
+ `[AddPermission](https://docs.aws.amazon.com/AWSSimpleQueueService/latest/APIReference/API_AddPermission.html)`
+ `[CancelMessageMoveTask](https://docs.aws.amazon.com/AWSSimpleQueueService/latest/APIReference/API_CancelMessageMoveTask.html)`
+ `[CreateQueue](https://docs.aws.amazon.com/AWSSimpleQueueService/latest/APIReference/API_CreateQueue.html)`
+ `[DeleteQueue](https://docs.aws.amazon.com/AWSSimpleQueueService/latest/APIReference/API_DeleteQueue.html)`
+ `[ListMessageMoveTask](https://docs.aws.amazon.com/AWSSimpleQueueService/latest/APIReference/API_ListMessageMoveTasks.html)`
+ `[ListQueues](https://docs.aws.amazon.com/AWSSimpleQueueService/latest/APIReference/API_ListQueues.html)`
+ `[ListQueueTags](https://docs.aws.amazon.com/AWSSimpleQueueService/latest/APIReference/API_ListQueueTags.html)`
+ `[RemovePermission](https://docs.aws.amazon.com/AWSSimpleQueueService/latest/APIReference/API_RemovePermission.html)`
+ `[SetQueueAttributes](https://docs.aws.amazon.com/AWSSimpleQueueService/latest/APIReference/API_SetQueueAttributes.html)`
+ `[StartMessageMoveTask](https://docs.aws.amazon.com/AWSSimpleQueueService/latest/APIReference/API_StartMessageMoveTask.html)`
+ `[TagQueue](https://docs.aws.amazon.com/AWSSimpleQueueService/latest/APIReference/API_TagQueue.html)`
+ `[UntagQueue](https://docs.aws.amazon.com/AWSSimpleQueueService/latest/APIReference/API_UntagQueue.html)`
## 조건 키
현재 Amazon SQS는 다음과 같이 [IAM에서 사용할 수 있는 조건 키](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_policies_elements.html#AvailableKeys)의 제한된 하위 세트만 지원합니다. 자세한 내용은 [Amazon SQS API 권한: 작업 및 리소스 참조](sqs-api-permissions-reference.md) 단원을 참조하십시오.
# 사용자 지정 Amazon SQS 액세스 정책 언어 예제
다음은 일반적인 Amazon SQS 액세스 정책의 예제입니다.
## 예제 1: 1개의 계정에 권한 부여
다음 Amazon SQS 정책 예제는 AWS 계정 444455556666이 소유한 `queue2`에 대해 전송 및 수신할 수 있는 권한을 AWS 계정 111122223333에 부여합니다.
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Id": "UseCase1",
"Statement" : [{
"Sid": "1",
"Effect": "Allow",
"Principal": {
"AWS": [
"111122223333"
]
},
"Action": [
"sqs:SendMessage",
"sqs:ReceiveMessage"
],
"Resource": "arn:aws:sqs:us-east-2:444455556666:queue2"
}]
}
```
------
## 예제 2: 1개 이상의 계정에 권한 부여
다음 예제 Amazon SQS 정책은 특정 기간 동안 계정이 소유한 대기열에 대한 AWS 계정 액세스 권한을 하나 이상 부여합니다. [https://docs.aws.amazon.com/AWSSimpleQueueService/latest/APIReference/API_AddPermission.html](https://docs.aws.amazon.com/AWSSimpleQueueService/latest/APIReference/API_AddPermission.html) 작업은 대기열에 대한 액세스 권한을 부여할 때 시간 제한 지정을 허용하지 않기 때문에 이 정책을 작성하고 [https://docs.aws.amazon.com/AWSSimpleQueueService/latest/APIReference/API_SetQueueAttributes.html](https://docs.aws.amazon.com/AWSSimpleQueueService/latest/APIReference/API_SetQueueAttributes.html) 작업을 사용하여 Amazon SQS에 업로드해야 합니다.
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Id": "UseCase2",
"Statement" : [{
"Sid": "1",
"Effect": "Allow",
"Principal": {
"AWS": [
"111122223333",
"444455556666"
]
},
"Action": [
"sqs:SendMessage",
"sqs:ReceiveMessage"
],
"Resource": "arn:aws:sqs:us-east-2:444455556666:queue2",
"Condition": {
"DateLessThan": {
"AWS:CurrentTime": "2009-06-30T12:00Z"
}
}
}]
}
```
------
## 예제 3: Amazon EC2 인스턴스의 요청에 권한 부여
다음 예제 Amazon SQS 정책에서는 Amazon EC2 인스턴스에서 오는 요청에 대한 액세스를 부여합니다. 이 예제는 "[예제 2: 1개 이상의 계정에 권한 부여](#two-accounts)" 예제를 보강한 것으로, 2009년 6월 30일 12시(정오)(UTC) 이전까지 액세스할 수 있고 액세스 IP 범위를 `203.0.113.0/24`로 제한합니다. [https://docs.aws.amazon.com/AWSSimpleQueueService/latest/APIReference/API_AddPermission.html](https://docs.aws.amazon.com/AWSSimpleQueueService/latest/APIReference/API_AddPermission.html) 작업은 대기열에 대한 액세스 권한을 부여할 때 IP 주소 제한 지정을 허용하지 않기 때문에 이 정책을 작성하고 [https://docs.aws.amazon.com/AWSSimpleQueueService/latest/APIReference/API_SetQueueAttributes.html](https://docs.aws.amazon.com/AWSSimpleQueueService/latest/APIReference/API_SetQueueAttributes.html) 작업을 사용하여 Amazon SQS에 업로드해야 합니다.
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Id": "UseCase3",
"Statement" : [{
"Sid": "1",
"Effect": "Allow",
"Principal": {
"AWS": [
"111122223333"
]
},
"Action": [
"sqs:SendMessage",
"sqs:ReceiveMessage"
],
"Resource": "arn:aws:sqs:us-east-2:444455556666:queue2",
"Condition": {
"DateLessThan": {
"AWS:CurrentTime": "2009-06-30T12:00Z"
},
"IpAddress": {
"AWS:SourceIp": "203.0.113.0/24"
}
}
}]
}
```
------
## 예제 4: 특정 계정에 대한 액세스 거부
다음 예제 Amazon SQS 정책은 대기열에 대한 특정 AWS 계정 액세스를 거부합니다. 이 예제는 "[예제 1: 1개의 계정에 권한 부여](#one-account)" 예제를 기반으로 합니다. 지정된에 대한 액세스를 거부합니다 AWS 계정. [https://docs.aws.amazon.com/AWSSimpleQueueService/latest/APIReference/API_AddPermission.html](https://docs.aws.amazon.com/AWSSimpleQueueService/latest/APIReference/API_AddPermission.html) 작업은 대기열에 대한 액세스 거부를 허용하지 않고 대기열에 대한 액세스 권한 부여만 허용하기 때문에 이 정책을 작성하고 [https://docs.aws.amazon.com/AWSSimpleQueueService/latest/APIReference/API_SetQueueAttributes.html](https://docs.aws.amazon.com/AWSSimpleQueueService/latest/APIReference/API_SetQueueAttributes.html) 작업을 사용하여 Amazon SQS에 업로드해야 합니다.
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Id": "UseCase4",
"Statement" : [{
"Sid": "1",
"Effect": "Deny",
"Principal": {
"AWS": [
"111122223333"
]
},
"Action": [
"sqs:SendMessage",
"sqs:ReceiveMessage"
],
"Resource": "arn:aws:sqs:us-east-2:444455556666:queue2"
}]
}
```
------
## 예제 5: VPC 엔드포인트에서 온 액세스가 아닌 경우 액세스 거부
다음 예시 Amazon SQS 정책은 `queue1`에 대한 액세스를 제한합니다. 111122223333은 VPC 엔드포인트 ID `vpce-1a2b3c4d`(`aws:sourceVpce` 조건을 사용하여 지정됨)에서만 [https://docs.aws.amazon.com/AWSSimpleQueueService/latest/APIReference/API_SendMessage.html](https://docs.aws.amazon.com/AWSSimpleQueueService/latest/APIReference/API_SendMessage.html) 및 [https://docs.aws.amazon.com/AWSSimpleQueueService/latest/APIReference/API_ReceiveMessage.html](https://docs.aws.amazon.com/AWSSimpleQueueService/latest/APIReference/API_ReceiveMessage.html) 작업을 수행할 수 있습니다. 자세한 내용은 [Amazon SQS용 Amazon Virtual Private Cloud 엔드포인트](sqs-internetwork-traffic-privacy.md#sqs-vpc-endpoints) 단원을 참조하십시오.
**참고**
`aws:sourceVpce` 조건은 VPC 엔드포인트 리소스의 ARN을 요구하지 않고 VPC 엔드포인트 ID만 요구합니다.
두 번째 문의 모든 Amazon SQS 작업(`sqs:*`)을 거부하도록 다음 예제를 수정하여 특정 VPC 엔드포인트에 대한 모든 작업을 제한할 수 있습니다. 그러나 그러한 정책 문은 모든 작업(대기열 권한 수정을 위한 관리 작업 포함)을 정책에 정의된 특정 VPC 엔드포인트를 통해서만 해야 하도록 규정하게 될 것이므로 앞으로 사용자가 대기열 권한을 수정하지 못하게 될 가능성이 있습니다.
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Id": "UseCase5",
"Statement": [{
"Sid": "1",
"Effect": "Allow",
"Principal": {
"AWS": [
"111122223333"
]
},
"Action": [
"sqs:SendMessage",
"sqs:ReceiveMessage"
],
"Resource": "arn:aws:sqs:us-east-2:111122223333:queue1"
},
{
"Sid": "2",
"Effect": "Deny",
"Principal": "*",
"Action": [
"sqs:SendMessage",
"sqs:ReceiveMessage"
],
"Resource": "arn:aws:sqs:us-east-2:111122223333:queue1",
"Condition": {
"StringNotEquals": {
"aws:sourceVpce": "vpce-1a2b3c4d"
}
}
}
]
}
```
------
# Amazon SQS에 대한 임시 보안 자격 증명 사용
자체 보안 자격 증명으로 사용자를 생성하는 것 외에도 IAM을 사용하면 모든 사용자에게 임시 보안 자격 증명을 부여하여 사용자가 AWS 서비스 및 리소스에 액세스할 수 있습니다. AWS 계정이 있는 사용자를 관리할 수 있습니다. 가 없는 시스템 사용자 AWS 계정 (연동 사용자)를 관리할 수도 있습니다. 또한 AWS 리소스에 액세스하기 위해 생성한 애플리케이션도 "사용자"로 간주될 수 있습니다.
Amazon SQS에 요청할 때 이 임시 보안 자격 증명을 사용할 수 있습니다. API 라이브러리는 요청 인증 시 이 자격 증명을 사용하여 필요한 서명 값을 계산합니다. 만료된 자격 증명으로 요청을 보내면 Amazon SQS는 요청을 거부합니다.
**참고**
임시 자격 증명을 기반으로 정책을 설정할 수 없습니다.
## 사전 조건
1. IAM을 사용하여 임시 보안 자격 증명 생성:
+ 보안 토큰
+ 액세스 키 ID
+ 비밀 액세스 키
1. 문자열을 준비하여 임시 액세스 키 ID와 보안 토큰으로 서명합니다.
1. 자체 보안 액세스 키가 아닌 임시 보안 액세스 키를 사용하여 쿼리 API 요청에 서명합니다.
**참고**
서명된 쿼리 API 요청을 제출할 때 자체 액세스 키 ID가 아닌 임시 액세스 키 ID를 사용하여 보안 토큰을 포함시킵니다. 임시 보안 자격 증명에 대한 IAM 지원에 대한 자세한 내용은 *IAM 사용 설명서*의 [AWS 리소스에 대한 임시 액세스 권한 부여를 참조하세요](https://docs.aws.amazon.com/IAM/latest/UserGuide/TokenBasedAuth.html).
## 임시 보안 자격 증명을 사용하여 Amazon SQS 쿼리 API 작업을 호출하려면
1. 를 사용하여 임시 보안 토큰을 요청합니다 AWS Identity and Access Management. 자세한 내용은 IAM 사용 설명서**의 [IAM 사용자의 액세스를 활성화하기 위한 임시 보안 자격 증명 생성](https://docs.aws.amazon.com/IAM/latest/UserGuide/CreatingSessionTokens.html)을 참조하세요.
IAM은 보안 토큰, 액세스 키 ID 및 보안 액세스 키를 반환합니다.
1. 자체 액세스 키 ID가 아닌 임시 액세스 키 ID를 사용하여 쿼리를 준비하고 보안 토큰을 포함시킵니다. 자체 보안 액세스 키가 아닌 임시 보안 액세스 키를 사용하여 쿼리 요청에 서명합니다.
1. 임시 액세스 키 ID와 보안 토큰으로 서명된 쿼리 문자열을 제출합니다.
다음 예는 Amazon SQS 요청을 인증하기 위해 임시 보안 자격 증명을 사용하는 방법을 보여줍니다. *`AUTHPARAMS`*의 구조는 API 요청의 서명에 따라 달라집니다. 자세한 내용은 Amazon Web Services 일반 참조의 [AWS API 요청 서명을 참조하세요](https://docs.aws.amazon.com/general/latest/gr/signing_aws_api_requests.html). **
```
https://sqs.us-east-2.amazonaws.com/
?Action=CreateQueue
&DefaultVisibilityTimeout=40
&QueueName=MyQueue
&Attribute.1.Name=VisibilityTimeout
&Attribute.1.Value=40
&Expires=2020-12-18T22%3A52%3A43PST
&SecurityToken=wJalrXUtnFEMI/K7MDENG/bPxRfiCYEXAMPLEKEY
&AWSAccessKeyId=AKIAIOSFODNN7EXAMPLE
&Version=2012-11-05
&AUTHPARAMS
```
다음 예제에서는 임시 보안 자격 증명을 사용하여 `SendMessageBatch` 작업을 통해 두 개의 메시지를 전송합니다.
```
https://sqs.us-east-2.amazonaws.com/
?Action=SendMessageBatch
&SendMessageBatchRequestEntry.1.Id=test_msg_001
&SendMessageBatchRequestEntry.1.MessageBody=test%20message%20body%201
&SendMessageBatchRequestEntry.2.Id=test_msg_002
&SendMessageBatchRequestEntry.2.MessageBody=test%20message%20body%202
&SendMessageBatchRequestEntry.2.DelaySeconds=60
&Expires=2020-12-18T22%3A52%3A43PST
&SecurityToken=je7MtGbClwBF/2Zp9Utk/h3yCo8nvbEXAMPLEKEY
&AWSAccessKeyId=AKIAI44QH8DHBEXAMPLE
&Version=2012-11-05
&AUTHPARAMS
```
# 최소 권한 정책이 있는 암호화된 Amazon SQS 대기열의 액세스 관리
Amazon SQS를 사용하여 [AWS Key Management Service (KMS)](https://docs.aws.amazon.com/kms/latest/developerguide/overview.html)와 통합된 서버 측 암호화(SSE)를 사용하여 애플리케이션 간에 민감한 데이터를 교환할 수 있습니다. Amazon SQS와를 통합 AWS KMS하면 Amazon SQS를 보호하는 키와 다른 AWS 리소스를 보호하는 키를 중앙에서 관리할 수 있습니다.
여러 AWS 서비스가 Amazon SQS로 이벤트를 보내는 이벤트 소스 역할을 할 수 있습니다. 이벤트 소스가 암호화된 Amazon SQS 대기열에 액세스할 수 있도록 하려면 [고객 관리형](https://docs.aws.amazon.com/kms/latest/developerguide/concepts.html#customer-cmk) AWS KMS 키로 대기열을 구성해야 합니다. 그런 다음 키 정책을 사용하여 서비스가 필요한 AWS KMS API 메서드를 사용하도록 허용합니다. 또한 이 서비스에는 대기열이 이벤트를 보낼 수 있도록 액세스를 인증할 수 있는 권한이 필요합니다. Amazon SQS 대기열 및 해당 데이터에 대한 액세스를 제어하는 데 사용할 수 있는 리소스 기반 정책인 Amazon SQS 정책을 사용하여 이를 달성할 수 있습니다.
다음 섹션에서는 Amazon SQS 정책 및 AWS KMS 키 정책을 통해 암호화된 Amazon SQS 대기열에 대한 액세스를 제어하는 방법에 대한 정보를 제공합니다. 이 가이드의 정책은 [최소 권한](https://docs.aws.amazon.com/IAM/latest/UserGuide/best-practices.html#grant-least-privilege)을 획득하는 데 도움이 됩니다.
또한 이 안내서에서는 리소스 기반 정책이 [https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_policies_condition-keys.html#condition-keys-sourcearn](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_policies_condition-keys.html#condition-keys-sourcearn), [https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_policies_condition-keys.html#condition-keys-sourceaccount](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_policies_condition-keys.html#condition-keys-sourceaccount), [https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_policies_condition-keys.html#condition-keys-principalorgid](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_policies_condition-keys.html#condition-keys-principalorgid) 전역 IAM 조건 컨텍스트 키를 사용하여 [혼동된 대리자 문제](https://docs.aws.amazon.com/IAM/latest/UserGuide/confused-deputy.html)를 해결하는 방법도 설명합니다.
**Topics**
+ [
## 개요
](#sqs-least-privilege-overview)
+ [
## Amazon SQS에 대한 최소 권한 키 정책
](#sqs-least-privilege-use-case)
+ [
## DLQ(Dead Letter Queue)에 대한 Amazon SQS 정책 명령문
](#sqs-policy-dlq)
+ [
## 교차 서비스 혼동된 대리자 문제 방지
](#sqs-confused-deputy-prevention)
+ [
## IAM Access Analyzer를 사용하여 크로스 계정 액세스를 검토할 수 있습니다.
](#sqs-cross-account-findings)
## 개요
이 주제에서는 일반적인 사용 사례를 통해 키 정책과 Amazon SQS 대기열 정책을 구축하는 방법을 설명합니다. 이 사용 사례는 다음 이미지에 나와 있습니다.
![\[Amazon SQS에 Amazon SNS 메시지 게시\]](http://docs.aws.amazon.com/ko_kr/AWSSimpleQueueService/latest/SQSDeveloperGuide/images/sqs-least-privilege.png)
이 예제에서 메시지 생산자는 [Amazon Simple Notification Service(SNS)](https://docs.aws.amazon.com/sns/latest/dg/welcome.html) 주제로, 메시지를 암호화된 Amazon SQS 대기열로 팬아웃하도록 구성되어 있습니다. 메시지 소비자는 [AWS Lambda](https://docs.aws.amazon.com/lambda/latest/dg/welcome.html) 함수, [Amazon Elastic Compute Cloud(EC2)](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/concepts.html) 인스턴스 또는 [AWS Fargate](https://docs.aws.amazon.com/AmazonECS/latest/developerguide/AWS_Fargate.html) 컨테이너와 같은 컴퓨팅 서비스입니다. 그런 다음 실패한 메시지를 [DLQ(Dead Letter Queue)](https://docs.aws.amazon.com/AWSSimpleQueueService/latest/SQSDeveloperGuide/sqs-dead-letter-queues.html)로 보내도록 Amazon SQS 대기열을 구성합니다. DLQ는 소비되지 않은 메시지를 구분하여 처리가 실패한 이유를 확인할 수 있으므로 이 방법은 애플리케이션 또는 메시징 시스템을 디버깅하는 데 유용합니다. 이 주제에 정의된 솔루션에서는 Lambda 함수와 같은 컴퓨팅 서비스를 사용하여 Amazon SQS 대기열에 저장된 메시지를 처리합니다. 메시지 소비자가 Virtual Private Cloud(VPC)에 있는 경우 이 안내서에 포함된 [`DenyReceivingIfNotThroughVPCE`](#sqs-restrict-message-to-endpoint) 정책 명령문을 통해 메시지 수신을 특정 VPC로 제한할 수 있습니다.
**참고**
이 안내서에는 정책 명령문 형식의 필수 IAM 권한만 포함되어 있습니다. 정책을 구성하려면 Amazon SQS 정책 또는 AWS KMS 키 정책에 문을 추가해야 합니다. 이 가이드에서는 Amazon SQS 대기열 또는 AWS KMS 키를 생성하는 방법에 대한 지침을 제공하지 않습니다. 이러한 리소스를 생성하는 방법에 대한 지침은 [Amazon SQS 대기열 생성](creating-sqs-standard-queues.md#step-create-standard-queue) 및 [키 생성](https://docs.aws.amazon.com/kms/latest/developerguide/create-keys.html)을 참조하세요.
이 안내서에 정의된 Amazon SQS 정책은 메시지를 동일하거나 다른 Amazon SQS 대기열로 직접 리드라이브하는 것을 지원하지 않습니다.
## Amazon SQS에 대한 최소 권한 키 정책
이 섹션에서는 Amazon SQS 대기열을 암호화하는 데 사용하는 고객 관리형 키에 AWS KMS 대한의 필수 최소 권한 권한을 설명합니다. 이러한 권한을 사용하면 최소 권한을 구현하면서 의도한 엔터티로만 액세스를 제한할 수 있습니다. 키 정책은 다음과 같은 정책 명령문으로 구성되어야 하며, 이에 대해서는 아래에서 자세히 설명합니다.
+ [AWS KMS 키에 대한 관리자 권한 부여](#sqs-use-case-kms-admin-permissions)
+ [키 메타데이터에 대한 읽기 전용 액세스 권한 부여](#sqs-use-case-read-only-permissions)
+ [Amazon SNS에 대기열에 메시지를 게시할 수 있는 Amazon SNS KMS 권한 부여](#sqs-use-case-publish-messages-permissions)
+ [소비자가 대기열에 있는 메시지를 해독할 수 있도록 허용](#sqs-use-case-decrypt-messages-permissions)
### AWS KMS 키에 대한 관리자 권한 부여
AWS KMS 키를 생성하려면 AWS KMS 키를 배포하는 데 사용하는 IAM 역할에 AWS KMS 관리자 권한을 제공해야 합니다. 이러한 관리자 권한은 다음 `AllowKeyAdminPermissions` 정책 명령문에 정의되어 있습니다. 이 문을 AWS KMS 키 정책에 추가할 때는 **을 AWS KMS 키를 배포하거나 AWS KMS 키를 관리하는 데 사용되는 IAM 역할의 Amazon 리소스 이름(ARN)으로 바꿔야 합니다. 이는 배포 파이프라인의 IAM 역할이거나 [AWS 조직](https://aws.amazon.com/organizations/)에서 [조직의 관리자 역할](https://docs.aws.amazon.com/organizations/latest/userguide/orgs_manage_accounts_access.html)일 수 있습니다.
```
{
"Sid": "AllowKeyAdminPermissions",
"Effect": "Allow",
"Principal": {
"AWS": [
""
]
},
"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": "*"
}
```
**참고**
AWS KMS 키 정책에서 `Resource` 요소의 값은 이어야 합니다. 즉`*`, "이 AWS KMS 키"입니다. 별표(`*`)는 AWS KMS 키 정책이 연결된 키를 식별합니다.
### 키 메타데이터에 대한 읽기 전용 액세스 권한 부여
다른 IAM 역할에 키 메타데이터에 대한 읽기 전용 액세스 권한을 부여하려면 키 정책에 `AllowReadAccessToKeyMetaData` 명령문을 추가합니다. 예를 들어 다음 문을 사용하면 감사 목적으로 계정의 모든 AWS KMS 키를 나열할 수 있습니다. 이 문은 AWS 루트 사용자에게 키 메타데이터에 대한 읽기 전용 액세스 권한을 부여합니다. 따라서 계정 내 모든 IAM 보안 주체는 자격 증명 기반 정책이 다음 명령문 `kms:Describe*`, `kms:Get*` 및 `kms:List*`에 나열된 권한을 가질 때 키 메타데이터에 액세스할 수 있습니다. **를 자신의 정보로 바꿉니다.
```
{
"Sid": "AllowReadAcesssToKeyMetaData",
"Effect": "Allow",
"Principal": {
"AWS": [
"arn:aws:iam:::root"
]
},
"Action": [
"kms:Describe*",
"kms:Get*",
"kms:List*"
],
"Resource": "*"
}
```
### Amazon SNS에 대기열에 메시지를 게시할 수 있는 Amazon SNS KMS 권한 부여
Amazon SNS 주제가 암호화된 Amazon SQS 대기열에 메시지를 게시하도록 허용하려면 키 정책에 `AllowSNSToSendToSQS` 정책 명령문을 추가합니다. 이 문은 AWS KMS 키를 사용하여 Amazon SNS Amazon SQS에 부여합니다. **를 자신의 정보로 바꿉니다.
**참고**
문의 `Condition`는 동일한 AWS 계정의 Amazon SNS 서비스에 대한 액세스만 제한합니다.
```
{
"Sid": "AllowSNSToSendToSQS",
"Effect": "Allow",
"Principal": {
"Service": [
"sns.amazonaws.com"
]
},
"Action": [
"kms:Decrypt",
"kms:GenerateDataKey"
],
"Resource": "*",
"Condition": {
"StringEquals": {
"aws:SourceAccount": ""
}
}
}
```
### 소비자가 대기열에 있는 메시지를 해독할 수 있도록 허용
다음 `AllowConsumersToReceiveFromTheQueue` 명령문은 암호화된 Amazon SQS 대기열에서 수신한 메시지를 해독하는 데 필요한 권한을 Amazon SQS 메시지 소비자에게 부여합니다. 정책 명령문을 첨부할 때 **을 메시지 소비자의 IAM 런타임 역할 ARN으로 대체하세요.
```
{
"Sid": "AllowConsumersToReceiveFromTheQueue",
"Effect": "Allow",
"Principal": {
"AWS": [
""
]
},
"Action": [
"kms:Decrypt"
],
"Resource": "*"
}
```
### Amazon SQS 정책에 대한 최소 권한
이 섹션에서는 이 안내서에서 다루는 사용 사례(예: Amazon SNS에서 Amazon SQS로)에 대한 최소 권한 Amazon SQS 대기열 정책을 안내합니다. 정의된 정책은 `Deny` 및 `Allow` 명령문을 모두 사용하여 의도하지 않은 액세스를 방지하도록 설계되었습니다. `Allow` 명령문은 의도한 엔터티 또는 엔터티에 대한 액세스 권한을 부여합니다. 이 `Deny` 명령문은 정책 조건 내에서 의도한 엔터티를 제외하면서 의도하지 않은 다른 엔터티가 Amazon SQS 대기열에 액세스하는 것을 방지합니다.
Amazon SQS 정책에는 다음과 같은 명령문이 포함되어 있으며, 이에 대해서는 아래에서 자세히 설명합니다.
+ [Amazon SQS 관리 권한 제한](#sqs-use-case-restrict-permissions)
+ [지정된 조직의 Amazon SQS 대기열 작업을 제한합니다.](#sqs-use-case-restrict-permissions-from-org)
+ [소비자에게 Amazon SQS 권한 부여](#sqs-use-grant-consumer-permissions)
+ [전송 중 암호화 적용](#sqs-encryption-in-transit)
+ [특정 Amazon SNS 주제로의 메시지 전송 제한](#sqs-restrict-transmission-to-topic)
+ [(선택 사항) 메시지 수신을 특정 VPC 엔드포인트로 제한](#sqs-restrict-message-to-endpoint)
### Amazon SQS 관리 권한 제한
다음 `RestrictAdminQueueActions` 정책 명령문에서는 Amazon SQS 관리 권한을 대기열을 배포하거나 대기열을 관리하는 데 사용하는 IAM 역할 또는 두 가지 모두에 사용하는 역할로만 제한합니다. **을 자체 정보로 바꾸세요. Amazon SQS 대기열을 배포하는 데 사용되는 IAM 역할의 ARN과 Amazon SQS 관리 권한이 있어야 하는 관리자 역할의 ARN을 지정합니다.
```
{
"Sid": "RestrictAdminQueueActions",
"Effect": "Deny",
"Principal": {
"AWS": "*"
},
"Action": [
"sqs:AddPermission",
"sqs:DeleteQueue",
"sqs:RemovePermission",
"sqs:SetQueueAttributes"
],
"Resource": "",
"Condition": {
"StringNotLike": {
"aws:PrincipalARN": [
"arn:aws:iam:::role/",
""
]
}
}
}
```
### 지정된 조직의 Amazon SQS 대기열 작업을 제한합니다.
외부 액세스([AWS 조직](https://docs.aws.amazon.com/organizations/latest/userguide/orgs_introduction.html) 외부 엔터티의 액세스)로부터 Amazon SQS 리소스를 보호하려면 다음 명령문을 사용하세요. 이 명령문은 Amazon SQS 대기열 액세스를 `Condition`에 지정된 조직으로 제한합니다. **을 Amazon SQS 대기열을 배포하는 데 사용된 IAM 역할의 ARN으로 바꾸고, **를 조직 ID로 바꾸어야 합니다.
```
{
"Sid": "DenyQueueActionsOutsideOrg",
"Effect": "Deny",
"Principal": {
"AWS": "*"
},
"Action": [
"sqs:AddPermission",
"sqs:ChangeMessageVisibility",
"sqs:DeleteQueue",
"sqs:RemovePermission",
"sqs:SetQueueAttributes",
"sqs:ReceiveMessage"
],
"Resource": "",
"Condition": {
"StringNotEquals": {
"aws:PrincipalOrgID": [
""
]
}
}
}
```
### 소비자에게 Amazon SQS 권한 부여
Amazon SQS 대기열에서 메시지를 수신하려면 메시지 소비자에게 필요한 권한을 제공해야 합니다. 다음 정책 명령문은 지정한 소비자에게 Amazon SQS 대기열의 메시지를 소비하는 데 필요한 권한을 부여합니다. Amazon SQS 정책에 이 명령문을 추가할 때 **을 소비자가 사용하는 IAM 런타임 역할의 ARN으로 바꾸고, **을 Amazon SQS 대기열을 배포하는 데 사용되는 IAM 역할의 ARN으로 바꾸어야 합니다.
```
{
"Sid": "AllowConsumersToReceiveFromTheQueue",
"Effect": "Allow",
"Principal": {
"AWS": ""
},
"Action": [
"sqs:ChangeMessageVisibility",
"sqs:DeleteMessage",
"sqs:GetQueueAttributes",
"sqs:ReceiveMessage"
],
"Resource": ""
}
```
다른 엔터티가 Amazon SQS 대기열에서 메시지를 수신하지 못하도록 하려면 Amazon SQS 대기열 정책에 `DenyOtherConsumersFromReceiving` 명령문을 추가하세요. 이 명령문은 메시지 소비를 지정한 소비자로 제한하여 다른 소비자는 자격 증명 권한에 따라 액세스 권한이 있는 경우에도 액세스하지 못하도록 합니다. **과 **을 자신의 정보로 바꾸어야 합니다.
```
{
"Sid": "DenyOtherConsumersFromReceiving",
"Effect": "Deny",
"Principal": {
"AWS": "*"
},
"Action": [
"sqs:ChangeMessageVisibility",
"sqs:DeleteMessage",
"sqs:ReceiveMessage"
],
"Resource": "",
"Condition": {
"StringNotLike": {
"aws:PrincipalARN": ""
}
}
}
```
### 전송 중 암호화 적용
다음 `DenyUnsecureTransport` 정책 명령문은 소비자와 생산자가 보안 채널(TLS 연결)을 사용하여 Amazon SQS 대기열에서 메시지를 보내고 받도록 강제합니다. **을 Amazon SQS 대기열을 배포하는 데 사용된 IAM 역할의 ARN으로 바꾸어야 합니다.
```
{
"Sid": "DenyUnsecureTransport",
"Effect": "Deny",
"Principal": {
"AWS": "*"
},
"Action": [
"sqs:ReceiveMessage",
"sqs:SendMessage"
],
"Resource": "",
"Condition": {
"Bool": {
"aws:SecureTransport": "false"
}
}
}
```
### 특정 Amazon SNS 주제로의 메시지 전송 제한
다음 `AllowSNSToSendToTheQueue` 정책 명령문은 특정 Amazon SNS 주제가 Amazon SQS 대기열에 메시지를 전송하도록 허용합니다. **을 Amazon SQS 대기열을 배포하는 데 사용된 IAM 역할의 ARN으로 바꾸고, **을 Amazon SNS 주제 ARN으로 바꾸어야 합니다.
```
{
"Sid": "AllowSNSToSendToTheQueue",
"Effect": "Allow",
"Principal": {
"Service": "sns.amazonaws.com"
},
"Action": "sqs:SendMessage",
"Resource": "",
"Condition": {
"ArnLike": {
"aws:SourceArn": ""
}
}
}
```
다음 `DenyAllProducersExceptSNSFromSending` 정책 명령문은 다른 생산자가 대기열에 메시지를 보내는 것을 방지합니다. ** 및 **을 자신의 정보로 바꿉니다.
```
{
"Sid": "DenyAllProducersExceptSNSFromSending",
"Effect": "Deny",
"Principal": {
"AWS": "*"
},
"Action": "sqs:SendMessage",
"Resource": "",
"Condition": {
"ArnNotLike": {
"aws:SourceArn": ""
}
}
}
```
### (선택 사항) 메시지 수신을 특정 VPC 엔드포인트로 제한
메시지 수신을 특정 [VPC 엔드포인트로](https://aws.amazon.com/about-aws/whats-new/2018/12/amazon-sqs-vpc-endpoints-aws-privatelink/)만 제한하려면 Amazon SQS 대기열 정책에 다음 정책 명령문을 추가하세요. 이 명령문은 메시지가 원하는 VPC 엔드포인트에서 전송되지 않는 한 메시지 소비자가 대기열에서 메시지를 수신하지 못하도록 합니다. **을 Amazon SQS 대기열을 배포하는 데 사용되는 IAM 역할의 ARN으로 바꾸고, **를 VPC 엔드포인트의 ID로 바꿉니다.
```
{
"Sid": "DenyReceivingIfNotThroughVPCE",
"Effect": "Deny",
"Principal": "*",
"Action": [
"sqs:ReceiveMessage"
],
"Resource": "",
"Condition": {
"StringNotEquals": {
"aws:sourceVpce": ""
}
}
}
```
## DLQ(Dead Letter Queue)에 대한 Amazon SQS 정책 명령문
명령문 ID로 식별되는 다음 정책 명령문을 DLQ 액세스 정책에 추가합니다.
+ `RestrictAdminQueueActions`
+ `DenyQueueActionsOutsideOrg`
+ `AllowConsumersToReceiveFromTheQueue`
+ `DenyOtherConsumersFromReceiving`
+ `DenyUnsecureTransport`
DLQ 액세스 정책에 이전 정책 명령문을 추가하는 것 외에도 다음 섹션에 설명된 대로 메시지 전송을 Amazon SQS 대기열로 제한하는 명령문도 추가해야 합니다.
### Amazon SQS 대기열로 메시지 전송 제한
동일한 계정의 Amazon SQS 대기열로만 액세스를 제한하려면 DLQ 대기열 정책에 다음 `DenyAnyProducersExceptSQS` 정책 명령문을 추가합니다. 이 명령문은 기본 대기열을 생성하기 전에 DLQ를 배포해야 하므로 메시지 전송을 특정 대기열로 제한하지 않습니다. 따라서 DLQ를 생성할 때 Amazon SQS ARN을 알 수 없습니다. 하나의 Amazon SQS 대기열로만 액세스를 제한해야 하는 경우, Amazon SQS 소스 대기열의 ARN을 사용하여(아는 경우) `Condition`의 `aws:SourceArn`을 수정합니다.
```
{
"Sid": "DenyAnyProducersExceptSQS",
"Effect": "Deny",
"Principal": {
"AWS": "*"
},
"Action": "sqs:SendMessage",
"Resource": "",
"Condition": {
"ArnNotLike": {
"aws:SourceArn": "arn:aws:sqs:::*"
}
}
}
```
**중요**
이 안내서에 정의된 Amazon SQS 대기열 정책은 `sqs:PurgeQueue` 작업을 특정 IAM 역할로 제한하지 않습니다. `sqs:PurgeQueue` 작업을 사용하면 Amazon SQS 대기열의 모든 메시지를 삭제할 수 있습니다. 또한 이 작업을 사용하여 Amazon SQS 대기열을 교체하지 않고도 메시지 형식을 변경할 수 있습니다. 애플리케이션을 디버깅할 때 Amazon SQS 대기열을 지워 오류가 있을 수 있는 메시지를 제거할 수 있습니다. 애플리케이션을 테스트할 때 Amazon SQS 대기열을 통해 대량의 메시지를 전송한 다음, 대기열을 제거하여 프로덕션에 들어가기 전에 새로 시작할 수 있습니다. 이 작업을 특정 역할로 제한하지 않는 이유는 Amazon SQS 대기열을 배포할 때 이 역할을 알지 못할 수 있기 때문입니다. 대기열을 제거하려면 이 권한을 역할의 ID 기반 정책에 추가해야 합니다.
## 교차 서비스 혼동된 대리자 문제 방지
[혼동된 대리자 문제](https://docs.aws.amazon.com/IAM/latest/UserGuide/confused-deputy.html)는 작업을 수행할 권한이 없는 엔터티가 권한이 더 많은 엔터티에 작업을 수행하도록 강요할 수 있는 보안 문제입니다. 이를 방지하기 위해는 타사(교차 계정이라고 함) 또는 기타 AWS 서비스(교차 서비스라고 함)에 계정의 리소스에 대한 액세스 권한을 제공하는 경우 계정을 보호하는 데 도움이 되는 도구를 AWS 제공합니다. 이 섹션의 정책 명령문은 교차 서비스 혼동된 대리자 문제를 방지하는 데 도움이 될 수 있습니다.
교차 서비스 가장은 한 서비스(직접 호출하는 서비스)가 다른 서비스(직접 호출되는 서비스)를 직접 호출할 때 발생할 수 있습니다. 호출하는 서비스는 다른 고객의 리소스에 대해 액세스 권한이 없는 방식으로 작동하게 권한을 사용하도록 조작될 수 있습니다. 이 문제를 방지하기 위해 이 게시물에 정의된 리소스 기반 정책은 [https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_policies_condition-keys.html#condition-keys-sourcearn](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_policies_condition-keys.html#condition-keys-sourcearn), [https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_policies_condition-keys.html#condition-keys-sourceaccount](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_policies_condition-keys.html#condition-keys-sourceaccount), [https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_policies_condition-keys.html#condition-keys-principalorgid](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_policies_condition-keys.html#condition-keys-principalorgid) 전역 IAM 조건 컨텍스트 키를 사용합니다. 이렇게 하면 서비스가 AWS Organizations의 특정 리소스, 특정 계정 또는 특정 조직에 대해 갖는 권한이 제한됩니다.
## IAM Access Analyzer를 사용하여 크로스 계정 액세스를 검토할 수 있습니다.
[AWS IAM Access Analyzer](https://docs.aws.amazon.com/IAM/latest/UserGuide/what-is-access-analyzer.html)를 사용하여 Amazon SQS 대기열 정책 및 AWS KMS 키 정책을 검토하고 Amazon SQS 대기열 또는 AWS KMS 키가 외부 엔터티에 액세스 권한을 부여할 때 알림을 받을 수 있습니다. IAM Access Analyzer는 신뢰 영역 외부의 엔터티와 공유되는 조직 및 계정의 [리소스](https://docs.aws.amazon.com/IAM/latest/UserGuide/access-analyzer-resources.html)를 식별하는 데 도움이 됩니다. 이 신뢰 영역은 IAM Access Analyzer를 활성화할 때 지정하는 AWS Organizations 내의 AWS 계정 또는 조직일 수 있습니다.
IAM Access Analyzer는 로직 기반 추론을 사용하여 AWS 환경의 리소스 기반 정책을 분석하여 외부 보안 주체와 공유되는 리소스를 식별합니다. 신뢰 영역 외부에서 공유되는 리소스의 각 인스턴스에 대해 Access Analyzer는 결과를 생성합니다. [결과](https://docs.aws.amazon.com/IAM/latest/UserGuide/access-analyzer-findings.html)에는 액세스에 대한 정보와 액세스 권한이 부여되는 외부 보안 주체에 대한 정보가 포함됩니다. 결과를 검토하여 액세스가 의도한 안전한 액세스인지 또는 액세스가 의도하지 않은 보안 위험인지 확인할 수 있습니다. 의도하지 않은 액세스가 발생한 경우 영향을 받는 정책을 검토하고 수정합니다. AWS IAM Access Analyzer가 AWS 리소스에 대한 의도하지 않은 액세스를 식별하는 방법에 대한 자세한 내용은이 [블로그 게시물](https://aws.amazon.com/blogs/aws/identify-unintended-resource-access-with-aws-identity-and-access-management-iam-access-analyzer/)을 참조하세요.
AWS IAM Access Analyzer에 대한 자세한 내용은 [AWS IAM Access Analyzer 설명서를](https://docs.aws.amazon.com/IAM/latest/UserGuide/what-is-access-analyzer.html) 참조하세요.
# Amazon SQS API 권한: 작업 및 리소스 참조
[액세스 관리](security_iam_service-with-iam.md#access-control)를 설정하고 IAM 자격 증명에 연결할 수 있는 권한 정책을 작성할 때 다음 표를 참조로 사용할 수 있습니다. 표 목록 목록에 있습니다. AWS
정책의 `Action` 필드에서 작업을 지정하고, 정책의 `Resource` 필드에서 리소스 값을 지정합니다. 작업을 지정하려면 `sqs:` 접두사 다음에 작업 이름을 사용합니다(예: `sqs:CreateQueue`).
현재 Amazon SQS는 [IAM에서 사용할 수 있는 전역 조건 문맥 키](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_policies_condition-keys.html)를 지원합니다.
스크롤 막대를 사용하여 표의 나머지 부분을 확인합니다.
**Amazon Simple Queue Service API 및 작업에 필요한 권한**
[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ko_kr/AWSSimpleQueueService/latest/SQSDeveloperGuide/sqs-api-permissions-reference.html)