# API Gateway에서 REST API에 대한 액세스 제어 및 관리 API Gateway는 API 액세스 제어 및 관리에 다중 메커니즘을 지원합니다. 다음 메커니즘은 인증 및 권한 부여에 사용할 수 있습니다. + **리소스 정책**으로 리소스 기반 정책을 만들어 특정 소스의 IP 주소 또는 VPC 종단점의 API 및 메서드 액세스 권한을 부여하거나 거부할 수 있습니다. 자세한 내용은 [API Gateway 리소스 정책을 사용하여 REST API에 대한 액세스 제어](apigateway-resource-policies.md) 단원을 참조하세요. + **표준 AWS IAM 역할 및 정책**은 전체 API 또는 개별 메서드에 적용할 수 있는 유연하고 강력한 액세스 제어를 제공합니다. IAM 역할 및 정책을 사용하여 API를 생성하고 관리할 수 있는 사용자와 API를 호출할 수 있는 사용자를 관리할 수 있습니다. 자세한 내용은 [IAM 권한을 사용하여 REST API에 대한 액세스 제어](permissions.md) 단원을 참조하세요. + **IAM 태그**는 액세스 제어를 위해 IAM 정책과 함께 사용할 수 있습니다. 자세한 내용은 [태그를 사용하여 API Gateway REST API 리소스에 대한 액세스 제어](apigateway-tagging-iam-policy.md) 단원을 참조하세요. + **인터페이스 VPC 종단점에 대한 엔드포인트 정책**을 통해 [프라이빗 API](https://docs.aws.amazon.com/apigateway/latest/developerguide/apigateway-private-apis.html)의 보안을 향상시키기 위해 인터페이스 VPC 종단점에 IAM 리소스 정책을 연결할 수 있습니다. 자세한 내용은 [API Gateway의 프라이빗 API에 대한 VPC 종단점 정책 사용](apigateway-vpc-endpoint-policies.md) 단원을 참조하세요. + **Lambda 권한 부여자**는 보유자 토큰 인증과 헤더, 경로, 쿼리 문자열, 단계 변수, 맥락 변수 요청 파라미터에 서술된 정보를 이용하여 REST API 메서드에 대한 액세스를 제어하는 Lambda 함수입니다. Lambda 권한 부여자는 REST API 메서드를 호출할 수 있는 사람을 제어하는 데 사용됩니다. 자세한 내용은 [API Gateway Lambda 권한 부여자 사용](apigateway-use-lambda-authorizer.md) 단원을 참조하세요. + **Amazon Cognito 사용자 풀**로 REST API에 대해 사용자 지정이 가능한 인증 및 권한 부여 솔루션을 만들 수 있습니다. Amazon Cognito 사용자 풀은 REST API 메서드를 호출할 수 있는 사람을 제어하는 데 사용됩니다. 자세한 내용은 [Amazon Cognito 사용자 풀을 권한 부여자로 사용하여 REST API에 대한 액세스 제어](apigateway-integrate-with-cognito.md) 단원을 참조하세요. 다음 메커니즘은 액세스 제어와 관련된 다른 작업을 수행할 때 사용할 수 있습니다. + **CORS(Cross-origin 리소스 공유)**로 REST API가 교차 도메인 리소스 요청에 응답하는 방식을 제어할 수 있습니다. 자세한 내용은 [API Gateway의 REST API CORS](how-to-cors.md) 단원을 참조하세요. + **클라이언트 측 SSL 인증서**를 사용하여 백엔드 시스템에 대한 HTTP 요청이 API Gateway에서 시작된 것인지 확인할 수 있습니다. 자세한 내용은 [API Gateway에서 백엔드 인증을 위한 SSL 인증서 생성 및 구성](getting-started-client-side-ssl-authentication.md) 단원을 참조하세요. + **AWS WAF**는 일반적인 웹 익스플로잇으로부터 API Gateway API를 보호하기 위해 사용할 수 있습니다. 자세한 내용은 [API Gateway에서 AWS WAF를 사용하여 REST API 보호](apigateway-control-access-aws-waf.md) 단원을 참조하세요. 다음 메커니즘은 권한이 있는 클라이언트에게 부여한 액세스 권한을 추적하고 제한하는 데 사용할 수 있습니다. + **사용량 계획**을 통해 고객에게 **API 키**를 제공할 수 있으며 그 후에 각 API 키에 대하여 API 단계와 메서드를 추적하고 사용량을 제한할 수 있습니다. 자세한 내용은 [API Gateway의 REST API 사용량 계획 및 API 키](api-gateway-api-usage-plans.md) 섹션을 참조하세요. # API Gateway 리소스 정책을 사용하여 REST API에 대한 액세스 제어 Amazon API Gateway *리소스 정책*은 지정된 보안 주체(보통 IAM 역할 또는 그룹)가 API를 호출할 수 있는지 여부를 제어하기 위해 API에 연결하는 JSON 정책 문서입니다. API Gateway 리소스 정책을 사용하여 다음과 같은 엔터티의 안전한 API 호출을 허용할 수 있습니다. + 지정된 AWS 계정의 사용자. + 지정된 소스 IP 주소 범위 또는 CIDR 블록. + 지정된 가상 사설 클라우드(VPC) 또는 VPC 종단점(계정 무관). AWS Management Console, AWS CLI 또는 AWS SDK를 사용하여 API Gateway에 모든 API 엔드포인트 유형에 대한 리소스 정책을 연결할 수 있습니다. [프라이빗 API](https://docs.aws.amazon.com/apigateway/latest/developerguide/apigateway-private-apis.html)의 경우 VPC 종단점 정책과 함께 리소스 정책을 사용하여 어떤 주체가 어떤 리소스 및 작업에 대한 액세스를 가질지를 제어할 수 있습니다. 자세한 내용은 [API Gateway의 프라이빗 API에 대한 VPC 종단점 정책 사용](apigateway-vpc-endpoint-policies.md) 섹션을 참조하세요. API Gateway 리소스 정책은 IAM 자격 증명 기반 정책과 다릅니다. IAM 정책은 IAM 엔터티(사용자, 그룹 또는 역할)에 연결되어 이들 엔터티가 어떤 리소스에 대해 어떤 조치를 취할 수 있는지 정의합니다. API Gateway 리소스 정책은 리소스에 연결됩니다. API Gateway 리소스 정책을 IAM 정책과 함께 사용할 수 있습니다. 자세한 내용은 [자격 증명 기반 정책 및 리소스 기반 정책](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies_identity-vs-resource.html)을 참조하세요. **Topics** + [Amazon API Gateway에 대한 액세스 정책 언어 개요](apigateway-control-access-policy-language-overview.md) + [API Gateway 리소스 정책이 권한 부여 워크플로우에 미치는 영향](apigateway-authorization-flow.md) + [API Gateway 리소스 정책 예제](apigateway-resource-policies-examples.md) + [API Gateway 리소스 정책을 생성하여 API에 연결](apigateway-resource-policies-create-attach.md) + [AWSAPI Gateway 리소스 정책에 사용할 수 있는 조건 키](apigateway-resource-policies-aws-condition-keys.md) # Amazon API Gateway에 대한 액세스 정책 언어 개요 이 페이지에서는 Amazon API Gateway 리소스 정책에 사용되는 기본 요소를 설명합니다. IAM 정책과 동일한 구문을 사용하여 리소스 정책이 지정됩니다. 전체 정책 언어에 대한 정보는 **IAM 사용 설명서의 [IAM 정책 개요](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies.html) 및 [AWS Identity and Access Management 정책 참조](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_policies.html)를 참조하세요. AWS 서비스가 어떻게 해당 요청의 허용 또는 거부 여부를 결정하는지에 대한 자세한 내용은 [요청의 허용 또는 거부 결정](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_policies_evaluation-logic.html#policy-eval-denyallow) 단원을 참조하세요. ## 액세스 정책의 공통 요소 가장 기본적인 경우, 리소스 정책에는 다음 요소가 포함되어 있습니다. + **리소스** – API는 권한을 허용 또는 거부할 수 있는 Amazon API Gateway 리소스입니다. 정책에서는 Amazon 리소스 이름(ARN)을 사용하여 리소스를 식별해야 합니다. 리소스 정책을 저장할 때 API Gateway가 전체 ARN으로 자동으로 확장하는 약식 구문을 사용할 수도 있습니다. 자세한 내용은 [API Gateway 리소스 정책 예제](apigateway-resource-policies-examples.md) 단원을 참조하세요. 전체 `Resource` 요소의 형식은 [API Gateway의 API 실행 권한 리소스 형식](api-gateway-control-access-using-iam-policies-to-invoke-api.md#api-gateway-iam-policy-resource-format-for-executing-api) 단원을 참조하세요. + **작업** - 각 리소스에 대해 Amazon API Gateway는 작업의 집합을 지원합니다. 작업 키워드를 사용하여 허용(또는 거부)할 리소스 작업을 식별합니다. 예를 들어 `execute-api:Invoke` 권한은 사용자가 클라이언트 요청 시 API를 호출할 수 있도록 허용합니다. `Action` 요소의 형식은 [API Gateway의 API 실행 권한 작업 형식](api-gateway-control-access-using-iam-policies-to-invoke-api.md#api-gateway-iam-policy-action-format-for-executing-api) 단원을 참조하세요. + **효과** - 사용자가 특정 작업을 요청하는 경우의 효과입니다. 이는 `Allow` 또는 `Deny` 중에 하나가 될 수 있습니다. 다른 정책에서 액세스 권한을 부여하는 경우라도 사용자가 해당 리소스에 액세스할 수 없도록 하기 위해 리소스에 대한 권한을 명시적으로 거부할 수도 있습니다. **참고** "암시적 거부"는 "기본 거부"와 동일합니다. “암시적 거부”는 “명시적 거부”와 다릅니다. 자세한 내용은 [기본 거부와 명시적 거부의 차이](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_policies_evaluation-logic.html#AccessPolicyLanguage_Interplay) 단원을 참조하세요. + **보안 주체** - 문에서의 작업 및 리소스에 액세스할 수 있는 계정 또는 사용자입니다. 리소스 정책에서 보안 주체는 이 권한을 수신하는 사용자나 계정입니다. 다음의 리소스 정책 예시는 이전의 공통 정책 요소를 나타냅니다. 이 정책은 소스 IP 주소가 *123.4.5.6/24* 주소 블록에 속하는 사용자에게 지정된 *region*의 지정된 *account-id*에서 API에 대한 액세스 권한을 부여합니다. 이 정책은 사용자의 소스 IP가 해당 범위 내에 있지 않으면 API에 대한 모든 액세스를 거부합니다. ------ #### [ JSON ] **** ``` { "Version":"2012-10-17", "Statement": [ { "Effect": "Allow", "Principal": "*", "Action": "execute-api:Invoke", "Resource": "arn:aws:execute-api:us-east-1:111111111111:*" }, { "Effect": "Deny", "Principal": "*", "Action": "execute-api:Invoke", "Resource": "arn:aws:execute-api:us-east-1:111111111111:*", "Condition": { "NotIpAddress": { "aws:SourceIp": "123.4.5.6/24" } } } ] } ``` ------ # API Gateway 리소스 정책이 권한 부여 워크플로우에 미치는 영향 API Gateway가 API에 연결된 리소스 정책을 평가할 때 그 결과는, 다음 단원의 흐름 차트에 서명된 것처럼, APi에 대하여 정의한 인증 유형의 영향을 받습니다. **Topics** + [API Gateway 리소스 정책만](#apigateway-authorization-flow-resource-policy-only) + [Lambda 권한 부여자 및 리소스 정책](#apigateway-authorization-flow-lambda) + [IAM 인증 및 리소스 정책](#apigateway-authorization-flow-iam) + [Amazon Cognito 인증 및 리소스 정책](#apigateway-authorization-flow-cognito) + [정책 평가 결과표](#apigateway-resource-policies-iam-policies-interaction) ## API Gateway 리소스 정책만 이 워크플로우에서 API Gateway 리소스 정책은 API에 연결되지만 API에 대하여 정의되는 인증 유형은 없습니다. 정책 평가를 위해서는 호출자의 인바운드 기준에 따른 명시적 허용이 필요합니다. 묵시적 거부 또는 명시적 거부는 호출자에 대한 거부로 이어집니다. ![\[리소스 정책의 권한 부여 흐름만.\]](http://docs.aws.amazon.com/ko_kr/apigateway/latest/developerguide/images/apigateway-auth-resource-policy-only.png) 다음은 이러한 리소스 정책의 예입니다. ------ #### [ JSON ] **** ``` { "Version":"2012-10-17", "Statement": [ { "Effect": "Allow", "Principal": "*", "Action": "execute-api:Invoke", "Resource": "arn:aws:execute-api:us-east-1:111111111111:api-id/", "Condition": { "IpAddress": { "aws:SourceIp": ["192.0.2.0/24", "198.51.100.0/24" ] } } } ] } ``` ------ ## Lambda 권한 부여자 및 리소스 정책 이 워크플로우에서 Lambda 권한 부여자는 리소스 정책과 함께 API에 대하여 구성됩니다. 리소스 정책은 2단계로 평가됩니다. Lambda 권한 부여자를 호출하기 전에 API Gateway는 먼저 정책을 평가하고 명시적 거부를 확인합니다. 명시적 거부가 확인되면 호출자는 즉시 액세스를 거부당합니다. 그렇지 않으면 Lambda 권한 보유자가 호출되어 리소스 정책과 결합하여 평가되는 [정책 문서](api-gateway-lambda-authorizer-output.md)를 반환합니다. 권한 부여자가 캐싱을 사용하는 경우 API Gateway는 캐싱된 정책 문서를 반환할 수 있습니다. 그 결과는 [테이블 A](#apigateway-resource-policies-iam-policies-interaction)에 따라 결정됩니다. 다음의 리소스 정책 예제는 그 VPC 엔드포인트 ID가 `vpce-1a2b3c4d`인 VPC 엔드포인트로부터의 호출만을 허용합니다. “인증 전” 평가 과정 중에는 예제에 나온 VPC 종단점에서의 호출만이 다음 단계로 넘어가 Lambda 권한 부여자를 평가하는 것이 허용됩니다. 나머지 모든 호출은 차단됩니다. 프라이빗 API에 사용자 지정 도메인 이름을 사용하는 경우 이 권한 부여 워크플로는 동일합니다. ![\[리소스 정책과 Lambda 권한 부여자의 권한 부여 흐름.\]](http://docs.aws.amazon.com/ko_kr/apigateway/latest/developerguide/images/apigateway-auth-lambda-resource-policy.png) ------ #### [ JSON ] **** ``` { "Version":"2012-10-17", "Statement": [ { "Effect": "Deny", "Principal": "*", "Action": "execute-api:Invoke", "Resource": [ "arn:aws:execute-api:us-east-1:111111111111:api-id/" ], "Condition" : { "StringNotEquals": { "aws:SourceVpce": "vpce-1a2b3c4d" } } } ] } ``` ------ ## IAM 인증 및 리소스 정책 이 워크플로에서 리소스 정책 외에도 API에 대한 IAM 인증을 구성합니다. IAM 서비스로 사용자를 인증한 후에는 API가 사용자에게 연결된 정책과 리소스 정책을 모두 평가합니다. 그 결과는 호출자가 동일한 AWS 계정에 있는지 또는 API 소유자의 별도 AWS 계정에 있는지에 따라 달라집니다. 호출자와 API 소유자가 각기 다른 계정에 있는 경우, IAM 정책과 리소스 정책 모두 호출자가 진행하도록 명시적으로 허용합니다. 자세한 내용은 [테이블 B](#apigateway-resource-policies-iam-policies-interaction)를 참조하세요. 그러나 호출자와 API 소유자가 동일한 AWS 계정에 있는 경우, IAM 사용자 정책 또는 리소스 정책 중 하나에서 호출자가 진행하도록 명시적으로 허용합니다. 자세한 내용은 [테이블 A](#apigateway-resource-policies-iam-policies-interaction)를 참조하세요. ![\[리소스 정책과 IAM 인증의 권한 부여 흐름.\]](http://docs.aws.amazon.com/ko_kr/apigateway/latest/developerguide/images/apigateway-auth-iam-resource-policy.png) 다음은 교차 계정 리소스 정책의 예입니다. IAM 정책에 허용 효과가 포함되어 있다고 가정할 때, 이 리소스 정책은 VPC ID가 `vpc-2f09a348`인 VPC로부터의 호출만을 허용합니다 자세한 내용은 [테이블 B](#apigateway-resource-policies-iam-policies-interaction)를 참조하세요. ------ #### [ JSON ] **** ``` { "Version":"2012-10-17", "Statement": [ { "Effect": "Allow", "Principal": "*", "Action": "execute-api:Invoke", "Resource": [ "arn:aws:execute-api:us-east-1:111111111111:api-id/" ], "Condition" : { "StringEquals": { "aws:SourceVpc": "vpc-2f09a348" } } } ] } ``` ------ ## Amazon Cognito 인증 및 리소스 정책 이 워크플로에서는 리소스 정책 외에 API에 대해 [Amazon Cognito 사용자 풀](apigateway-integrate-with-cognito.md)이 구성됩니다. API Gateway는 먼저 Amazon Cognito를 통해 호출자에게 권한을 부여하려 합니다. 이는 보통 호출자가 제공하는 [JWT 토큰](https://docs.aws.amazon.com/cognito/latest/developerguide/amazon-cognito-user-pools-using-tokens-with-identity-providers.html)을 통해 수행됩니다. 인증에 성공하면, 리소스 정책이 독립적으로 평가되고 명시적 허용이 필요해집니다. 거부 또는 “허용도 거부도 아님”인 경우에는 거부됩니다. 다음은 Amazon Cognito 사용자 풀과 함께 사용될 수 있는 리소스 정책의 예제입니다. ![\[리소스 정책과 Amazon Cognito 권한 부여자의 권한 부여 흐름.\]](http://docs.aws.amazon.com/ko_kr/apigateway/latest/developerguide/images/apigateway-auth-cognito-resource-policy.png) 다음은 Amazon Cognito 인증 토큰에 허용이 포함되어 있다는 가정하에 지정된 소스 IP로부터의 호출만을 허용하는 리소스 정책의 예제입니다 자세한 내용은 [테이블 B](#apigateway-resource-policies-iam-policies-interaction)를 참조하세요. ------ #### [ JSON ] **** ``` { "Version":"2012-10-17", "Statement": [ { "Effect": "Allow", "Principal": "*", "Action": "execute-api:Invoke", "Resource": "arn:aws:execute-api:us-east-1:111111111111:api-id/", "Condition": { "IpAddress": { "aws:SourceIp": ["192.0.2.0/24", "198.51.100.0/24" ] } } } ] } ``` ------ ## 정책 평가 결과표 테이블 A에는 API Gateway API에 대한 액세스가 IAM 정책 또는 Lambda 권한 부여자 및 API Gateway 리소스 정책에 의해 제어되고, 이러한 두 정책이 모두 동일한 AWS 계정에 있을 때 결과로 수행되는 동작이 나와 있습니다. | **IAM 정책(또는 Lambda 권한 부여자)** | **API Gateway 리소스 정책** | **결과적 동작** | | --- | --- | --- | | 허용 | 허용 | 허용 | | 허용 | 허용도 거부도 아님 | 허용 | | 허용 | 거부 | 명시적 거부 | | 허용도 거부도 아님 | 허용 | 허용 | | 허용도 거부도 아님 | 허용도 거부도 아님 | 암시적 거부 | | 허용도 거부도 아님 | 거부 | 명시적 거부 | | 거부 | 허용 | 명시적 거부 | | 거부 | 허용도 거부도 아님 | 명시적 거부 | | 거부 | 거부 | 명시적 거부 | 테이블 B에는 API Gateway API에 대한 액세스가 IAM 정책 또는 Amazon Cognito 사용자 풀 권한 부여자 및 API Gateway 리소스 정책 에 의해 제어되고, 이러한 정책이 서로 다른 AWS 계정에 있을 때 결과로 수행되는 동작이 나와 있습니다. 허용되지도 거부되지도 않으면, 교차 계정 액세스가 거부됩니다. 왜냐하면 크로스 계정 액세스를 위해서는 리소스 정책과 IAM 정책 또는 Amazon Cognito 사용자 풀 권한 부여자 모두에서 액세스를 명시적으로 허용해야 하기 때문입니다. | **IAM 정책(또는 Amazon Cognito 사용자 풀 권한 부여자)** | **API Gateway 리소스 정책** | **결과적 동작** | | --- | --- | --- | | 허용 | 허용 | 허용 | | 허용 | 허용도 거부도 아님 | 암시적 거부 | | 허용 | 거부 | 명시적 거부 | | 허용도 거부도 아님 | 허용 | 암시적 거부 | | 허용도 거부도 아님 | 허용도 거부도 아님 | 암시적 거부 | | 허용도 거부도 아님 | 거부 | 명시적 거부 | | 거부 | 허용 | 명시적 거부 | | 거부 | 허용도 거부도 아님 | 명시적 거부 | | 거부 | 거부 | 명시적 거부 | # API Gateway 리소스 정책 예제 이 페이지에서는 API Gateway 리소스 정책의 일반적인 사용 사례에 대한 몇 가지 예제를 제시합니다. 다음 예제 정책은 간소화된 구문을 사용하여 API 리소스를 지정합니다. 이 간소화된 구문은 전체 Amazon 리소스 이름(ARN)을 지정하는 대신 API 리소스를 참조할 수 있는 약식 방법입니다. API Gateway는 정책을 저장할 때 약어 구문을 전체 ARN으로 변환합니다. 예를 들어 리소스 정책에서 `execute-api:/stage-name/GET/pets` 리소스를 지정할 수 있습니다. API Gateway는 리소스 정책을 저장할 때 이 리소스를 `arn:aws:execute-api:us-east-2:123456789012:aabbccddee/stage-name/GET/pets`로 변환합니다. API Gateway는 현재 리전, AWS 계정 ID 및 리소스 정책이 연결된 REST API의 ID를 사용하여 전체 ARN을 구축합니다. `execute-api:/*`를 사용하여 현재 API의 모든 단계, 메서드 및 경로를 나타낼 수 있습니다. 액세스 정책 언어에 대한 자세한 내용은 [Amazon API Gateway에 대한 액세스 정책 언어 개요](apigateway-control-access-policy-language-overview.md) 단원을 참조하세요. **Topics** + [예제: 다른 AWS 계정의 역할이 API를 사용하도록 허용](#apigateway-resource-policies-cross-account-example) + [예제: 소스 IP 주소 또는 범위에 따라 API 트래픽 거부](#apigateway-resource-policies-source-ip-address-example) + [예: 프라이빗 API를 사용할 때 소스 IP 주소 또는 범위를 기반으로 API 트래픽 거부](#apigateway-resource-policies-source-ip-address-vpc-example) + [예제: 소스 VPC 또는 VPC 종단점에 따라 프라이빗 API 트래픽 허용](#apigateway-resource-policies-source-vpc-example) ## 예제: 다른 AWS 계정의 역할이 API를 사용하도록 허용 다음의 리소스 정책 예제는 [Signature Version 4](https://docs.aws.amazon.com/IAM/latest/UserGuide/create-signed-request.html)(SigV4) 또는 [Signature Version 4a](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_sigv.html#how-sigv4a-works)(SigV4a) 프로토콜을 통해 한 AWS 계정의 API 액세스 권한을 다른 AWS 계정의 두 역할에 부여합니다. 예를 들면 `account-id-2`로 식별된 AWS 계정의 개발자와 관리자 역할에 AWS 계정의 `pets` 리소스(API)에서 `GET` 작업을 실행할 수 있는 `execute-api:Invoke` 작업에 대한 권한이 부여됩니다. ------ #### [ JSON ] **** ``` { "Version":"2012-10-17", "Statement": [ { "Effect": "Allow", "Principal": { "AWS": [ "arn:aws:iam::111122223333:role/developer", "arn:aws:iam::111122223333:role/Admin" ] }, "Action": "execute-api:Invoke", "Resource": [ "execute-api:/stage/GET/pets" ] } ] } ``` ------ ## 예제: 소스 IP 주소 또는 범위에 따라 API 트래픽 거부 아래의 리소스 정책 예제에서는 2개의 지정된 소스 IP 주소 블록에서 API로 들어오는 트래픽을 거부(차단)합니다. ------ #### [ JSON ] **** ``` { "Version":"2012-10-17", "Statement": [ { "Effect": "Allow", "Principal": "*", "Action": "execute-api:Invoke", "Resource": [ "execute-api:/*" ] }, { "Effect": "Deny", "Principal": "*", "Action": "execute-api:Invoke", "Resource": [ "execute-api:/*" ], "Condition" : { "IpAddress": { "aws:SourceIp": ["192.0.2.0/24", "198.51.100.0/24" ] } } } ] } ``` ------ IAM 사용자 정책 또는 API Gateway 리소스 정책을 사용하여 API Gateway 또는 API Gateway API에 대한 액세스를 제어하는 경우 정책이 IPv6 주소 범위를 포함하도록 업데이트되었는지 확인합니다. IPv6 주소를 처리하도록 업데이트되지 않은 정책은 클라이언트가 듀얼 스택 엔드포인트를 사용하기 시작할 때 API Gateway에 대한 클라이언트의 액세스에 영향을 미칠 수 있습니다. 자세한 내용은 [IAM 정책에서 IPv6 주소 사용](api-ref.md#api-reference-service-endpoints-dualstack-iam) 섹션을 참조하세요. ## 예: 프라이빗 API를 사용할 때 소스 IP 주소 또는 범위를 기반으로 API 트래픽 거부 아래의 리소스 정책 예제에서는 2개의 지정된 소스 IP 주소 블록에서 프라이빗 API로 들어오는 트래픽을 거부(차단)합니다. 프라이빗 API를 사용할 때 `execute-api`의 VPC 종단점은 원래 소스 IP 주소를 다시 기록합니다. `aws:VpcSourceIp` 조건은 원래 요청자 IP 주소를 기준으로 요청을 필터링합니다. ------ #### [ JSON ] **** ``` { "Version":"2012-10-17", "Statement": [ { "Effect": "Allow", "Principal": "*", "Action": "execute-api:Invoke", "Resource": [ "execute-api:/*" ] }, { "Effect": "Deny", "Principal": "*", "Action": "execute-api:Invoke", "Resource": [ "execute-api:/*" ], "Condition" : { "IpAddress": { "aws:VpcSourceIp": ["192.0.2.0/24", "198.51.100.0/24"] } } } ] } ``` ------ ## 예제: 소스 VPC 또는 VPC 종단점에 따라 프라이빗 API 트래픽 허용 다음 예제의 리소스 정책에서는 지정된 Virtual Private Cloud(VPC) 또는 VPC 종단점에서 오는 수신 트래픽만 프라이빗 API에 액세스하도록 허용합니다. 이 리소스 정책 예제는 소스 VPC를 지정합니다. ------ #### [ JSON ] **** ``` { "Version":"2012-10-17", "Statement": [ { "Effect": "Allow", "Principal": "*", "Action": "execute-api:Invoke", "Resource": [ "execute-api:/*" ] }, { "Effect": "Deny", "Principal": "*", "Action": "execute-api:Invoke", "Resource": [ "execute-api:/*" ], "Condition" : { "StringNotEquals": { "aws:SourceVpc": "vpc-1a2b3c4d" } } } ] } ``` ------ 이 리소스 정책 예제는 소스 VPC 종단점을 지정합니다. ------ #### [ JSON ] **** ``` { "Version":"2012-10-17", "Statement": [ { "Effect": "Allow", "Principal": "*", "Action": "execute-api:Invoke", "Resource": [ "execute-api:/*" ] }, { "Effect": "Deny", "Principal": "*", "Action": "execute-api:Invoke", "Resource": [ "execute-api:/*" ], "Condition" : { "StringNotEquals": { "aws:SourceVpce": "vpce-1a2b3c4d" } } } ] } ``` ------ # API Gateway 리소스 정책을 생성하여 API에 연결 사용자가 API 실행 서비스를 호출하여 API에 액세스하도록 허용하려면 API Gateway 리소스 정책을 생성하고 이 정책을 API에 연결해야 합니다. API에 정책을 연결하면 정책의 해당 권한이 API의 메서드에 적용됩니다. 리소스 정책을 업데이트하는 경우 API를 배포해야 합니다. **Topics** + [사전 조건](#apigateway-resource-policies-prerequisites) + [API Gateway API에 리소스 정책 연결](#apigateway-resource-policies-create-attach-procedure) + [리소스 정책 문제 해결](#apigateway-resource-policies-troubleshoot) ## 사전 조건 API Gateway 리소스 정책을 업데이트하려면 `apigateway:UpdateRestApiPolicy` 권한과 `apigateway:PATCH` 권한이 있어야 합니다. 엣지 최적화 또는 리전 API의 경우 API를 생성할 때 또는 배포한 후에 리소스 정책을 API에 연결할 수 있습니다. 프라이빗 API의 경우 리소스 정책 없이는 API를 배포할 수 없습니다. 자세한 내용은 [API Gateway의 프라이빗 REST API](apigateway-private-apis.md) 섹션을 참조하세요. ## API Gateway API에 리소스 정책 연결 다음 절차는 API Gateway API에 리소스 정책을 연결하는 방법을 보여줍니다. ------ #### [ AWS Management Console ] **API Gateway API에 리소스 정책을 연결하려면** 1. [https://console.aws.amazon.com/apigateway](https://console.aws.amazon.com/apigateway)에서 API Gateway 콘솔에 로그인합니다. 1. REST API를 선택합니다. 1. 기본 탐색 창에서 **리소스 정책**을 선택합니다. 1. **정책 생성**을 선택합니다. 1. (선택 사항) 예제 정책을 생성하려면 **템플릿 선택**을 선택합니다. 여기 나온 정책 예제에서는 자리 표시자가 이중 중괄호(`"{{placeholder}}"`)로 묶여 있습니다. 중괄호를 포함한 각각의 자리 표시자를 필요한 정보로 바꿉니다. 1. 템플릿 예제 중 하나를 사용하지 않는 경우에는 리소스 정책을 입력합니다. 1. **변경 사항 저장**을 선택합니다. API Gateway 콘솔에서 이미 배포한 API라면 다시 배포해야 리소스 정책이 적용됩니다. ------ #### [ AWS CLI ] AWS CLI를 사용하여 새 API를 생성하고 여기에 리소스 정책을 연결하려면 다음 [create-rest-api](https://docs.aws.amazon.com/cli/latest/reference/apigateway/create-rest-api.html) 명령을 사용합니다. ``` aws apigateway create-rest-api \ --name "api-name" \ --policy "{\"jsonEscapedPolicyDocument\"}" ``` AWS CLI를 사용하여 기존 API에 리소스 정책을 연결하려면 다음 [update-rest-api](https://docs.aws.amazon.com/cli/latest/reference/apigateway/update-rest-api.html) 명령을 사용합니다. ``` aws apigateway update-rest-api \ --rest-api-id api-id \ --patch-operations op=replace,path=/policy,value='"{\"jsonEscapedPolicyDocument\"}"' ``` 리소스 정책을 별도의 `policy.json` 파일로 첨부하여 [create-rest-api](https://docs.aws.amazon.com/cli/latest/reference/apigateway/create-rest-api.html) 명령에 포함할 수도 있습니다. 다음 [create-rest-api](https://docs.aws.amazon.com/cli/latest/reference/apigateway/create-rest-api.html) 명령은 리소스 정책을 사용하여 새 API를 생성합니다. ``` aws apigateway create-rest-api \ --name "api-name" \ --policy file://policy.json ``` `policy.json`은 API Gateway 리소스 정책(예: [예제: 소스 IP 주소 또는 범위에 따라 API 트래픽 거부](apigateway-resource-policies-examples.md#apigateway-resource-policies-source-ip-address-example))입니다. ------ #### [ AWS CloudFormation ] CloudFormation를 사용하여 리소스 정책을 사용하여 API를 생성할 수 있습니다. 다음 예시에서는 예제 리소스 정책인 [예제: 소스 IP 주소 또는 범위에 따라 API 트래픽 거부](apigateway-resource-policies-examples.md#apigateway-resource-policies-source-ip-address-example)을 사용하여 REST API를 만듭니다. ``` AWSTemplateFormatVersion: 2010-09-09 Resources: Api: Type: 'AWS::ApiGateway::RestApi' Properties: Name: testapi Policy: Statement: - Action: 'execute-api:Invoke' Effect: Allow Principal: '*' Resource: 'execute-api:/*' - Action: 'execute-api:Invoke' Effect: Deny Principal: '*' Resource: 'execute-api:/*' Condition: IpAddress: 'aws:SourceIp': ["192.0.2.0/24", "198.51.100.0/24" ] Version: 2012-10-17 Resource: Type: 'AWS::ApiGateway::Resource' Properties: RestApiId: !Ref Api ParentId: !GetAtt Api.RootResourceId PathPart: 'helloworld' MethodGet: Type: 'AWS::ApiGateway::Method' Properties: RestApiId: !Ref Api ResourceId: !Ref Resource HttpMethod: GET ApiKeyRequired: false AuthorizationType: NONE Integration: Type: MOCK RequestTemplates: application/json: '{"statusCode": 200}' IntegrationResponses: - StatusCode: 200 ResponseTemplates: application/json: '{}' MethodResponses: - StatusCode: 200 ResponseModels: application/json: 'Empty' ApiDeployment: Type: 'AWS::ApiGateway::Deployment' DependsOn: - MethodGet Properties: RestApiId: !Ref Api StageName: test ``` ------ ## 리소스 정책 문제 해결 다음 문제 해결 지침은 리소스 정책 관련 문제를 해결하는 데 도움이 될 수 있습니다. ### 내 API에서 \$1"Message":"User: anonymous is not authorized to perform: execute-api:Invoke on resource: arn:aws:execute-api:us-east-1:\$1\$1\$1\$1\$1\$1\$1\$1/\$1\$1\$1\$1/\$1\$1\$1\$1/"\$1를 반환합니다. 리소스 정책에서 다음과 같이 보안 주체를 AWS 보안 주체로 설정하는 경우 ------ #### [ JSON ] **** ``` { "Version":"2012-10-17", "Statement": [ { "Effect": "Allow", "Principal": { "AWS": [ "arn:aws:iam::111111111111:role/developer", "arn:aws:iam::111111111111:role/Admin" ] }, "Action": "execute-api:Invoke", "Resource": [ "execute-api:/stage/GET/pets" ] } ] } ``` ------ API의 모든 메서드에 `AWS_IAM` 권한 부여를 사용해야 합니다. 그렇지 않으면 API가 이전 오류 메시지를 반환합니다. 메서드에 대한 `AWS_IAM` 권한 부여를 켜는 방법에 대한 자세한 지침은 [API Gateway의 REST API 메서드](how-to-method-settings.md) 섹션을 참조하세요. ### 내 리소스 정책이 업데이트되지 않습니다. API가 생성된 후에 리소스 정책을 업데이트하려면 업데이트된 정책을 연결한 후에 변경 내용이 전파되도록 API를 배포해야 합니다. 정책을 업데이트 또는 저장하는 것만으로는 API의 실행 시간 동작이 변경되지 않습니다. API 배포에 대한 자세한 내용은 [API Gateway에서 REST API 배포](how-to-deploy-api.md) 단원을 참조하세요. ### 리소스 정책에서 ‘정책 문서가 잘못됨’이라는 오류가 반환됩니다. 정책 구문을 확인하고 보안 주체가 유효한지 확인하세요. 이 오류를 해결하려면 먼저 정책 구문을 확인하는 것이 좋습니다. 자세한 내용은 [Amazon API Gateway에 대한 액세스 정책 언어 개요](apigateway-control-access-policy-language-overview.md) 섹션을 참조하세요. 또한 지정된 모든 보안 주체가 유효하고 삭제되지 않았는지 확인하는 것이 좋습니다. 또한 API가 [옵트인 리전](https://docs.aws.amazon.com/glossary/latest/reference/glos-chap.html?icmpid=docs_homepage_addtlrcs#optinregion)에 있는 경우 리소스 정책의 모든 계정에 리전이 활성화되어 있는지 확인하세요. # AWSAPI Gateway 리소스 정책에 사용할 수 있는 조건 키 다음 표에는 각각의 권한 부여 유형에 대해 API Gateway에서 API를 위한 리소스 정책에서 사용할 수 있는 AWS 조건 키가 포함되어 있습니다. AWS 조건 키에 대한 자세한 내용은 [AWS 전역 조건 컨텍스트 키](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_policies_condition-keys.html) 단원을 참조하세요. | **조건 키**: | **기준** | **이 필요합니까?`AuthN`** | **권한 부여 유형** | | --- | --- | --- | --- | | aws:CurrentTime | 없음 | 아니요 | 모두 | | aws:EpochTime | 없음 | 아니요 | 모두 | | aws:TokenIssueTime | 임시 보안 자격 증명을 사용해 서명된 요청에만 키가 존재합니다. | 예 | IAM | | aws:MultiFactorAuthPresent | 임시 보안 자격 증명을 사용해 서명된 요청에만 키가 존재합니다. | 예 | IAM | | aws:MultiFactorAuthAge | MFA가 요청에 존재하는 경우에만 키가 존재합니다. | 예 | IAM | | aws:PrincipalAccount | 없음 | 예 | IAM | | aws:PrincipalArn | 없음 | 예 | IAM | | aws:PrincipalOrgID | 이 키는 보안 주체가 조직의 멤버인 경우에만 요청 컨텍스트에 포함됩니다. | 예 | IAM | | aws:PrincipalOrgPaths | 이 키는 보안 주체가 조직의 멤버인 경우에만 요청 컨텍스트에 포함됩니다. | 예 | IAM | | aws:PrincipalTag | 이 키는 보안 주체가 태그가 연결된 IAM 사용자를 사용하는 경우 요청 컨텍스트에 포함됩니다. 연결된 태그 또는 세션 태그가 있는 IAM 역할을 사용하는 보안 주체에 포함됩니다. | 예 | IAM | | aws:PrincipalType | 없음 | 예 | IAM | | aws:Referer | HTTP 헤더에서 호출자가 값을 제공하는 경우에만 키가 존재합니다. | 아니요 | 모두 | | aws:SecureTransport | 없음 | 아니요 | 모두 | | aws:SourceArn | 없음 | 아니요 | 모두 | | aws:SourceIp | 없음 | 아니요 | 모두 | | aws:SourceVpc | 이 키는 프라이빗 API에만 사용할 수 있습니다. | 아니요 | 모두 | | aws:SourceVpce | 이 키는 프라이빗 API에만 사용할 수 있습니다. | 아니요 | 모두 | | aws:VpcSourceIp | 이 키는 프라이빗 API에만 사용할 수 있습니다. | 아니요 | 모두 | | aws:UserAgent | HTTP 헤더에서 호출자가 값을 제공하는 경우에만 키가 존재합니다. | 아니요 | 모두 | | aws:userid | 없음 | 예 | IAM | | aws:username | 없음 | 예 | IAM | # IAM 권한을 사용하여 REST API에 대한 액세스 제어 다음 두 API Gateway 구성 요소 프로세스에 대한 액세스를 제어하여 [IAM 권한](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_controlling.html)을 통해 Amazon API Gateway API에 대한 액세스를 제어합니다. + API Gateway에서 API를 생성, 배포, 관리하려면 API 개발자에게 API Gateway의 API 관리 구성 요소에서 지원되는 필수 작업을 수행할 수 있는 권한을 부여해야 합니다. + 배포된 API를 호출하거나 API 캐시를 새로 고치려면 API Gateway의 API 실행 구성 요소에서 지원되는 필요한 IAM 작업을 수행할 권한을 API 호출자에게 부여해야 합니다. 두 프로세스에 대한 액세스 제어에는 다음에 설명하는 서로 다른 권한 모델이 포함됩니다. ## API 생성 및 관리를 위한 API Gateway 권한 모델 API 개발자가 API Gateway에서 API를 생성하고 관리할 수 있도록 허용하려면 지정된 API 개발자가 필수 [API 엔터티](https://docs.aws.amazon.com/apigateway/latest/api/API_Resource.html)를 생성, 업데이트, 배포, 보기 또는 삭제할 수 있도록 허용하는 [IAM 권한 정책을 생성](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies_create.html)해야 합니다. 사용자, 역할 또는 그룹에 권한 정책을 연결합니다. 액세스 권한을 제공하려면 사용자, 그룹 또는 역할에 권한을 추가하세요. + AWS IAM Identity Center의 사용자 및 그룹: 권한 세트를 생성합니다. *AWS IAM Identity Center 사용자 안내서*에서 [권한 세트 생성](https://docs.aws.amazon.com//singlesignon/latest/userguide/howtocreatepermissionset.html)의 지침을 따릅니다. + ID 제공업체를 통해 IAM에서 관리되는 사용자: ID 페더레이션을 위한 역할을 생성합니다. *IAM 사용자 설명서*의 [Create a role for a third-party identity provider (federation)](https://docs.aws.amazon.com//IAM/latest/UserGuide/id_roles_create_for-idp.html)의 지침을 따릅니다. + IAM 사용자: + 사용자가 맡을 수 있는 역할을 생성합니다. *IAM 사용자 설명서*에서 [Create a role for an IAM user](https://docs.aws.amazon.com//IAM/latest/UserGuide/id_roles_create_for-user.html)의 지침을 따릅니다. + (권장되지 않음) 정책을 사용자에게 직접 연결하거나 사용자를 사용자 그룹에 추가합니다. *IAM 사용 설명서*에서 [사용자(콘솔)에 권한 추가](https://docs.aws.amazon.com//IAM/latest/UserGuide/id_users_change-permissions.html#users_change_permissions-add-console)의 지침을 따릅니다. 이 권한 모델을 사용하는 방법에 대한 자세한 내용은 [API Gateway 자격 증명 기반 정책](security_iam_service-with-iam.md#security_iam_service-with-iam-id-based-policies) 단원을 참조하세요. ## API 호출을 위한 API Gateway 권한 모델 API 호출자가 API를 호출하거나 캐싱을 새로 고치도록 허용하려면 지정된 API 호출자에게 사용자 인증이 사용되는 API 메서드를 호출하도록 허용하는 IAM 정책을 생성해야 합니다. API 개발자는 메서드의 `authorizationType` 속성을 `AWS_IAM`으로 설정하여 인증받을 사용자의 보안 인증 정보를 제출하도록 호출자에게 요구합니다. API Gateway는 사용자의 자격 증명을 인증하기 위해 Signature Version 4a(SigV4a) 및 Signature Version 4(SigV4)를 지원합니다. 자세한 내용은 [AWS Signature Version 4](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_sigv.html)를 참조하세요. 그런 다음 정책을 사용자, 역할 또는 그룹에 연결할 수 있습니다. 이 IAM 권한 정책 설명에서, IAM `Resource` 요소는 지정된 HTTP 동사와 API Gateway [리소스 경로](https://docs.aws.amazon.com/apigateway/latest/api/API_Resource.html)로 식별할 수 있는 배포된 API 메서드 목록을 포함합니다. IAM `Action` 요소는 필요한 API Gateway API 실행 작업을 포함합니다. 이러한 작업은 `execute-api:Invoke` 또는 `execute-api:InvalidateCache`를 포함합니다. 여기서 `execute-api`는 API Gateway의 기본 API 실행 구성 요소를 지정합니다. 이 권한 모델을 사용하는 방법에 대한 자세한 내용은 [API 호출을 위한 액세스 제어](api-gateway-control-access-using-iam-policies-to-invoke-api.md) 단원을 참조하세요. API가 백엔드에서 AWS 서비스(예: AWS Lambda)와 통합될 경우 API Gateway에도 API 호출자를 대신하여 통합된 AWS 리소스(예: Lambda 함수 호출)에 액세스할 권한이 있어야 합니다. 이러한 권한을 부여하려면 **API Gateway용 AWS 서비스** 유형의 IAM 역할을 생성합니다. IAM 관리 콘솔에서 이 역할을 생성하면 이 결과 역할에는 API Gateway를 역할을 수임하도록 허용되는 신뢰할 수 있는 개체로 선언하는 다음 IAM 신뢰 정책이 포함됩니다. ------ #### [ JSON ] **** ``` { "Version":"2012-10-17", "Statement": [ { "Sid": "", "Effect": "Allow", "Principal": { "Service": "apigateway.amazonaws.com" }, "Action": "sts:AssumeRole" } ] } ``` ------ CLI [create-role](https://docs.aws.amazon.com/cli/latest/reference/iam/create-role.html) 명령 또는 동등한 SDK 메서드를 호출하여 IAM 역할을 생성할 경우 `assume-role-policy-document`의 입력 파라미터로 상기 신뢰 정책을 제공해야 합니다. IAM 관리 콘솔에서 직접, 또는 AWS CLI [create-policy](https://docs.aws.amazon.com/cli/latest/reference/iam/create-policy.html) 명령 또는 동등한 SDK 메서드를 호출하여 그러한 정책을 생성하려 하지 마세요. API Gateway가 통합된 AWS 서비스를 호출하려면, 이 역할에 통합된 AWS 서비스를 호출하는 데 적절한 IAM 권한 정책도 연결해야 합니다. 예를 들어 Lambda 함수를 호출하려면 IAM 역할에 다음 IAM 권한 정책을 포함해야 합니다. ------ #### [ JSON ] **** ``` { "Version":"2012-10-17", "Statement": [ { "Effect": "Allow", "Action": "lambda:InvokeFunction", "Resource": "*" } ] } ``` ------ Lambda는 신뢰 정책과 권한 정책을 결합한 리소스 기반 액세스 정책을 지원합니다. API Gateway 콘솔을 사용하여 API를 Lambda 함수와 통합할 경우 콘솔에서 사용자의 동의를 받아 Lambda 함수에 대한 리소스 기반 권한을 자동으로 설정하므로 이 IAM 역할을 명시적으로 설정하라는 메시지가 표시되지 않습니다. **참고** AWS 서비스에 대한 액세스 제어를 적용하려면 권한 정책이 호출자의 사용자 또는 그룹에 직접 연결되는 호출자 기반 권한 모델을 사용하거나 권한 정책이 API Gateway에서 가정할 수 있는 IAM 역할에 연결되는 역할 기반 권한 모델을 사용할 수 있습니다. 두 모델의 권한 정책은 다를 수 있습니다. 예를 들어 호출자 기반 정책에서는 액세스를 차단하고 역할 기반 정책에서는 액세스를 허용할 수 있습니다. 이를 활용하여 사용자에게 API Gateway API를 통해서만 AWS 서비스에 액세스하도록 요구할 수 있습니다. # API 호출을 위한 액세스 제어 이 섹션에서는 IAM 권한을 사용하여 API에 대한 액세스를 제어하는 권한 모델에 대해 알아봅니다. IAM 권한 부여가 활성화된 경우 클라이언트는 Signature Version 4a(SigV4a) 및 Signature Version 4(SigV4)를 사용하여 AWS 자격 증명으로 요청에 서명해야 합니다. 자세한 내용은 [AWS Signature Version 4](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_sigv.html)를 참조하세요. 이 섹션에서는 템플릿 IAM 정책 설명과 정책 설명 참조를 보여줍니다. 정책 설명 참조에는 API 실행 서비스와 관련된 `Action` 및 `Resource` 필드의 형식도 포함되어 있습니다. 이러한 참조를 사용하여 IAM 정책 설명을 생성합니다. IAM 정책 설명을 생성할 때 API Gateway 리소스 정책이 권한 부여 워크플로에 미치는 영향을 고려해야 할 수 있습니다. 자세한 내용은 [API Gateway 리소스 정책이 권한 부여 워크플로우에 미치는 영향](apigateway-authorization-flow.md) 섹션을 참조하세요. 프라이빗 API의 경우 API Gateway 리소스 정책과 VPC 종단점 정책을 조합하여 사용해야 합니다. 자세한 정보는 다음 주제를 참조하세요. + [API Gateway 리소스 정책을 사용하여 REST API에 대한 액세스 제어](apigateway-resource-policies.md) + [API Gateway의 프라이빗 API에 대한 VPC 종단점 정책 사용](apigateway-vpc-endpoint-policies.md) ## IAM 정책을 사용하여 API Gateway API 메서드를 호출할 수 있는 사용자 제어 IAM 권한을 사용하여 배포된 API를 호출할 수 있는 사용자와 호출할 수 없는 사용자를 제어하려면 필요한 권한을 사용하여 IAM 정책 문서를 생성합니다. 그런 정책 문서에 대한 템플릿은 다음과 같습니다. ------ #### [ JSON ] **** ``` { "Version":"2012-10-17", "Statement": [ { "Effect": "Permission", "Action": [ "execute-api:Execution-operation" ], "Resource": [ "arn:aws:execute-api:region:123456789012:api-id/stage/METHOD_HTTP_VERB/Resource-path" ] } ] } ``` ------ 여기서 포함된 권한을 부여할지 취소할지 여부에 따라 `Permission`은 `Allow` 또는 `Deny`로 대체됩니다. `Execution-operation`은 API 실행 서비스에서 지원되는 작업으로 대체됩니다. `METHOD_HTTP_VERB`는 지정된 리소스에서 지원되는 HTTP 동사를 나타냅니다. `Resource-path`는 해당 `[Resource](https://docs.aws.amazon.com/apigateway/latest/api/API_Resource.html)`를 지원하는 배포된 API `METHOD_HTTP_VERB` 인스턴스의 URL 경로에 대한 자리 표시자입니다. 자세한 내용은 [API Gateway에서 API 실행을 위한 IAM 정책의 설명 참조](#api-gateway-calling-api-permissions) 단원을 참조하세요. **참고** IAM 정책을 적용하려면 메서드의 `AWS_IAM` 속성에 대한 `[authorizationType](https://docs.aws.amazon.com/apigateway/latest/api/API_Method.html#authorizationType)`을 설정하여 API 메서드에서 IAM 인증을 활성화해야 합니다. 그렇지 않은 경우 API 메서드에 공개적으로 액세스할 수 있습니다. 예를 들어 사용자에게 지정된 API 노출 반려 동물 목록을 볼 수 있는 권한을 부여하고, 목록에 반려 동물을 추가할 수 있는 권한을 거부하려면 IAM 정책에 다음 명령문을 포함하세요. ------ #### [ JSON ] **** ``` { "Version":"2012-10-17", "Statement": [ { "Effect": "Allow", "Action": [ "execute-api:Invoke" ], "Resource": [ "arn:aws:execute-api:us-east-1:111111111111:api-id/*/GET/pets" ] }, { "Effect": "Deny", "Action": [ "execute-api:Invoke" ], "Resource": [ "arn:aws:execute-api:us-east-1:111111111111:api-id/*/POST/pets" ] } ] } ``` ------ 사용자에게 `GET /pets/{petId}`로 구성된 API를 통해 공개된 특정 반려 동물을 볼 수 있는 권한을 부여하려면, IAM 정책에 다음 명령문을 포함합니다. ------ #### [ JSON ] **** ``` { "Version":"2012-10-17", "Statement": [ { "Effect": "Allow", "Action": [ "execute-api:Invoke" ], "Resource": [ "arn:aws:execute-api:us-east-1:111122223333:api-id/*/GET/pets/a1b2" ] } ] } ``` ------ ## API Gateway에서 API 실행을 위한 IAM 정책의 설명 참조 다음은 API 실행을 위한 액세스 권한에 대한 IAM 정책 설명의 작업 및 리소스 형식입니다. ### API Gateway의 API 실행 권한 작업 형식 API 실행 `Action` 표현식의 일반적인 형식은 다음과 같습니다. ``` execute-api:action ``` 여기서 *작업*은 사용 가능한 API 실행 작업입니다. + **\$1**는 다음의 모든 작업을 나타냅니다. + **호출**은 클라이언트 요청에 따라 API를 호출하는 데 사용됩니다. + **InvalidateCache**는 클라이언트 요청에 따라 API 캐시를 무효화하는 데 사용됩니다. ### API Gateway의 API 실행 권한 리소스 형식 API 실행 `Resource` 표현식의 일반적인 형식은 다음과 같습니다. ``` arn:aws:execute-api:region:account-id:api-id/stage-name/HTTP-VERB/resource-path-specifier ``` 여기서 각 항목은 다음과 같습니다. + *region*은 메서드에 대해 배포된 API에 해당하는 AWS 리전(예: **us-east-1** 또는 **\$1**(모든 AWS 리전))입니다. + *account-id*는 REST API 소유자의 12자리 AWS 계정 ID입니다. + *api-id*는 API Gateway에서 메서드에 대한 API에 할당한 식별자입니다. + *stage-name*은 메서드와 연결된 스테이지의 이름입니다. + *HTTP-VERB*는 메서드에 대한 HTTP 동사입니다. GET, POST, PUT, DELETE, PATCH 중 하나일 수 있습니다. + *resource-path-specifier*는 원하는 메서드의 경로입니다. **참고** 와일드카드(`*`)를 지정하는 경우 `Resource` 표현식에서 표현식의 나머지에 와일드카드가 적용됩니다. 다음은 리소스 표현식의 몇 가지 예입니다. + **arn:aws:execute-api:\$1:\$1:\$1**는 모든 단계의 모든 리소스 경로와 모든 AWS 리전의 모든 API를 나타내며, + **arn:aws:execute-api:us-east-1:\$1:\$1**는 모든 단계의 모든 리소스 경로와 AWS의 `us-east-1` 리전의 모든 API를 나타내며, + **arn:aws:execute-api:us-east-1:\$1:*api-id*/\$1**는 모든 단계의 모든 리소스 경로와 AWS 리전(us-east-1)에서 식별자가 *api-id*인 API를 나타냅니다. + **arn:aws:execute-api:us-east-1:\$1:*api-id*/`test`/\$1**는 `test` 단계의 리소스 경로와 AWS 리전(us-east-1)에서 식별자가 *api-id*인 API를 나타냅니다. 자세한 내용은 [API Gateway Amazon 리소스 이름(ARN) 참조](arn-format-reference.md)를 참조하세요. # API 실행 권한에 대한 IAM 정책 예 권한 모델 및 기타 배경 정보는 [API 호출을 위한 액세스 제어](api-gateway-control-access-using-iam-policies-to-invoke-api.md) 단원을 참조하세요. 다음 정책 설명은 사용자에게 `mydemoresource` 경로를 따라 `test` 단계에서 식별자가 `a123456789`인 API에 대해 POST 메서드를 호출할 수 있는 권한을 부여합니다. 여기서는 해당 API가 AWS 리전(us-east-1)에 배포된 것으로 가정합니다. ------ #### [ JSON ] **** ``` { "Version":"2012-10-17", "Statement": [ { "Effect": "Allow", "Action": [ "execute-api:Invoke" ], "Resource": [ "arn:aws:execute-api:us-east-1:*:a123456789/test/POST/my-demo-resource-path/*" ] } ] } ``` ------ 다음 예제 정책 설명은 사용자에게 모든 단계의 `petstorewalkthrough/pets` 리소스 경로에서 해당 API가 배포된 `a123456789` 리전에서 식별자가 AWS인 API에 대해 모든 메서드를 호출할 수 있는 권한을 부여합니다. ------ #### [ JSON ] **** ``` { "Version":"2012-10-17", "Statement": [ { "Effect": "Allow", "Action": [ "execute-api:Invoke" ], "Resource": [ "arn:aws:execute-api:*:*:a123456789/*/*/petstorewalkthrough/pets" ] } ] } ``` ------ # API Gateway의 프라이빗 API에 대한 VPC 종단점 정책 사용 프라이빗 API의 보안을 강화하기 위해 VPC 엔드포인트 정책을 생성할 수 있습니다. VPC 엔드포인트 정책은 VPC 엔드포인트에 연결할 수 있는 IAM 리소스 정책입니다. 자세한 정보는 [VPC 종단점을 통해 서비스에 대한 액세스 제어](https://docs.aws.amazon.com/vpc/latest/privatelink/vpc-endpoints-access.html)를 참조하세요. VPC 엔드포인트 정책을 생성하여 다음을 생성하는 것이 좋습니다. + 특정 조직 또는 리소스만 VPC 엔드포인트에 액세스하고 API를 간접적으로 호출하도록 허용합니다. + 단일 정책을 사용하고 세션 기반 또는 역할 기반 정책을 피하여 API로 향하는 트래픽을 제어합니다. + 온프레미스에서 AWS로 마이그레이션하는 동안 애플리케이션의 보안 경계를 강화합니다. ## VPC 엔드포인트 정책 고려 사항 다음은 VPC 엔드포인트 정책에 대한 고려 사항입니다. + 호출자의 ID는 `Authorization` 헤더 값을 기반으로 평가됩니다. VPC 엔드포인트 정책이 먼저 평가된 후 API Gateway가 메서드 요청에 구성된 권한 부여 유형에 따라 요청을 평가합니다. 다음 표는 `Authorization` 헤더 값의 내용을 기반으로 VPC 엔드포인트 정책이 평가되는 방법을 보여줍니다. [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ko_kr/apigateway/latest/developerguide/apigateway-vpc-endpoint-policies.html) + 액세스 제어가 Lambda 또는 Amazon Cognito 권한 부여자와 같은 보유자 토큰 사용에 의존하는 경우 [리소스의 속성](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_policies_condition-keys.html#condition-keys-resource-properties)을 사용하여 보안 경계를 제어할 수 있습니다. + 권한 부여 제어에서 IAM 권한 부여를 사용하는 경우 [리소스의 속성](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_policies_condition-keys.html#condition-keys-resource-properties)과 [보안 주체의 속성](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_policies_condition-keys.html#condition-keys-resource-principal)을 사용하여 보안 경계를 제어할 수 있습니다. + VPC 종단점 정책은 API Gateway 리소스 정책과 함께 사용할 수 있습니다. API Gateway 리소스 정책은 API에 액세스할 수 있는 보안 주체를 지정합니다. 엔드포인트 정책은 VPC에 액세스할 수 있는 사용자와 VPC 엔드포인트에서 직접적으로 호출할 수 있는 API를 지정합니다. 프라이빗 API에는 리소스 정책이 필요하지만 사용자 지정 VPC 엔드포인트 정책을 생성할 필요는 없습니다. ## VPC 엔드포인트 정책 예제 Amazon API Gateway에 대한 Amazon Virtual Private Cloud 엔드포인트 정책을 생성하여 다음을 지정할 수 있습니다. + 작업을 수행할 수 있는 보안 주체. + 수행할 수 있는 작업. + 작업을 수행할 수 있는 리소스. 이는 권한 부여 헤더의 내용에 따라 달라질 수 있습니다. 자세한 내용은 [VPC 엔드포인트 정책 고려 사항](#apigateway-vpc-endpoint-policies-considerations) 섹션을 참조하세요. 추가 정책 예제는 GitHub 웹사이트의 [Data perimeter policy examples](https://github.com/aws-samples/data-perimeter-policy-examples)를 참조하세요. VPC 종단점에 정책을 첨부하려면 VPC 콘솔을 사용해야 합니다. 자세한 정보는 [VPC 종단점을 통해 서비스에 대한 액세스 제어](https://docs.aws.amazon.com/vpc/latest/privatelink/vpc-endpoints-access.html)를 참조하세요. ## 예제 1: 두 API에 대한 액세스 권한을 부여하는 VPC 종단점 정책 다음 예제 정책은 정책이 첨부된 VPC 종단점을 통해 두 개의 특정 API로만 액세스 권한을 부여합니다. ------ #### [ JSON ] **** ``` { "Version":"2012-10-17", "Statement": [ { "Principal": "*", "Action": [ "execute-api:Invoke" ], "Effect": "Allow", "Resource": [ "arn:aws:execute-api:us-east-1:123412341234:a1b2c3d4e5/*", "arn:aws:execute-api:us-east-1:123412341234:aaaaa11111/*" ] } ] } ``` ------ ## 예제 2: GET 메서드에 대한 액세스 권한을 부여하는 VPC 종단점 정책 다음 예제 정책은 해당 정책이 연결된 VPC 종단점을 통해 특정 API에 대한 `GET` 메서드에 대한 액세스 권한을 사용자에게 부여합니다. ------ #### [ JSON ] **** ``` { "Version":"2012-10-17", "Statement": [ { "Principal": "*", "Action": [ "execute-api:Invoke" ], "Effect": "Allow", "Resource": [ "arn:aws:execute-api:us-east-1:123412341234:a1b2c3d4e5/stageName/GET/*" ] } ] } ``` ------ ## 예제 3: 특정 API에 특정 사용자 액세스 권한을 부여하는 VPC 종단점 정책 다음 예제 정책은 정책이 연결된 VPC 종단점을 통한 특정 API에 대한 특정 사용자 액세스 권한을 부여합니다. 이 경우 정책에서 특정 IAM 보안 주체에 대한 액세스를 제한하기 때문에 메서드의 `authorizationType`을 `AWS_IAM` 또는 `NONE`으로 설정해야 합니다. ------ #### [ JSON ] **** ``` { "Version":"2012-10-17", "Statement": [ { "Principal": { "AWS": [ "arn:aws:iam::123412341234:user/MyUser" ] }, "Action": [ "execute-api:Invoke" ], "Effect": "Allow", "Resource": [ "arn:aws:execute-api:us-east-1:123412341234:a1b2c3d4e5/*" ] } ] } ``` ------ ## 예제 4: 사용자에게 특정 사용자 지정 도메인 이름과 도메인에 매핑된 모든 API에 대한 액세스 권한을 부여하는 VPC 엔드포인트 정책 다음 예제 정책은 해당 정책이 연결된 VPC 엔드포인트를 통해 특정 사용자 지정 도메인 이름에 대한 액세스 권한을 사용자에게 부여합니다. 이 정책을 사용하면 사용자가 VPC 엔드포인트와 사용자 지정 도메인 이름 간에 도메인 이름 액세스 연결을 생성하고 사용자 지정 도메인 이름과 사용자 지정 도메인 이름에 매핑된 프라이빗 API를 간접적으로 호출할 수 있는 액세스 권한이 부여되는 한, 사용자는 이 사용자 지정 도메인 이름에 매핑된 모든 API를 간접적으로 호출할 수 있습니다. 자세한 내용은 [API Gateway의 프라이빗 API에 대한 사용자 지정 도메인 이름](apigateway-private-custom-domains.md) 섹션을 참조하세요. ------ #### [ JSON ] **** ``` { "Version":"2012-10-17", "Statement": [ { "Effect": "Allow", "Principal": { "AWS": "*" }, "Action": "execute-api:Invoke", "Resource": [ "*" ], "Condition": { "ArnEquals": { "execute-api:viaDomainArn": "arn:aws:execute-api:us-west-2:111122223333:/domainnames/private.test.com+f4g5h6", } } } ] } ``` ------ ## 예제 5: 특정 API 및 도메인 리소스에 대한 액세스 권한을 부여하거나 거부하는 VPC 엔드포인트 정책 다음 예제 정책은 사용자에게 특정 API 및 도메인 리소스에 대한 액세스 권한을 부여합니다. 이 정책을 사용하면 사용자가 VPC 엔드포인트와 사용자 지정 도메인 이름 간에 도메인 이름 액세스 연결을 생성하고 사용자 지정 도메인 이름 및 사용자 지정 도메인 이름에 매핑된 프라이빗 API를 간접적으로 호출할 수 있는 액세스 권한이 부여되는 한 사용자는 허용된 프라이빗 API 및 도메인 리소스를 간접적으로 호출할 수 있습니다. 자세한 내용은 [API Gateway의 프라이빗 API에 대한 사용자 지정 도메인 이름](apigateway-private-custom-domains.md) 섹션을 참조하세요. ------ #### [ JSON ] **** ``` { "Version":"2012-10-17", "Statement": [ { "Effect": "Allow", "Principal": { "AWS": "*" }, "Action": "execute-api:Invoke", "Resource": [ "arn:aws:execute-api:us-west-2:111122223333:/domainnames/private.test.com+f4g5h6", "arn:aws:execute-api:us-west-2:111122223333:a1b2c3d4e5/*" ] }, { "Effect": "Deny", "Principal": { "AWS": "*" }, "Action": "execute-api:Invoke", "Resource": [ "arn:aws:execute-api:us-west-2:111122223333:a1b2c3d4e5/admin/*", "arn:aws:execute-api:us-west-2:111122223333:bcd123455/*" ] } ] } ``` ------ ## 예제 6: 조직에 속한 위탁자 및 리소스별로 액세스 권한을 부여하거나 거부하는 VPC 엔드포인트 정책 다음 예제 정책은 조직에 속한 위탁자 및 리소스에 대한 액세스 권한을 부여합니다. ------ #### [ JSON ] **** ``` { "Version":"2012-10-17", "Statement": [ { "Condition": { "StringEquals": { "aws:ResourceOrgID": "o-abcd1234", "aws:PrincipalOrgID": "o-abcd1234" } }, "Action": "*", "Resource": "*", "Effect": "Allow", "Principal": { "AWS": "*" }, "Sid": "AllowRequestsByOrgsIdentitiesToOrgsResources" } ] } ``` ------ # API Gateway에서 태그를 사용하여 REST API에 대한 액세스 제어 IAM 정책에서 속성 기반 액세스 제어를 사용하여 REST API 액세스 권한을 미세 조정할 수 있습니다. 자세한 내용은 [태그를 사용하여 API Gateway REST API 리소스에 대한 액세스 제어](apigateway-tagging-iam-policy.md) 단원을 참조하십시오. # API Gateway Lambda 권한 부여자 사용 *Lambda 권한 부여자*(이전 *사용자 지정 권한 부여자*)를 사용하여 API에 대한 액세스를 제어할 수 있습니다. 클라이언트가 API의 메서드를 요청하면 API Gateway는 Lambda 권한 부여자를 직접적으로 호출합니다. Lambda 권한 부여자는 호출자의 자격 증명을 입력으로 사용하고 IAM 정책을 출력으로 반환합니다. Lambda 권한 부여자를 사용하여 사용자 지정 권한 부여 체계를 구현할 수 있습니다. 이 체계는 요청 파라미터를 사용하여 호출자의 자격 증명을 확인하거나 OAuth 또는 SAML과 같은 보유자 토큰 인증 전략을 사용할 수 있습니다. AWS CLI 또는 AWS SDK를 사용하여 API Gateway REST API 콘솔에서 Lambda 권한 부여자를 생성합니다. ## Lambda 권한 부여자 인증 워크플로 다음 다이어그램은 Lambda 권한 부여자에 대한 인증 워크플로를 보여줍니다. ![\[API Gateway Lambda 권한 부여 워크플로\]](http://docs.aws.amazon.com/ko_kr/apigateway/latest/developerguide/images/custom-auth-workflow.png) **API Gateway Lambda 권한 부여 워크플로** 1. 클라이언트가 API Gateway API의 메서드를 직접적으로 호출하고 보유자 토큰 또는 요청 파라미터를 전달합니다. 1. API Gateway는 메서드 요청에 Lambda 권한 부여자가 구성되어 있는지 확인합니다. 구성되어 있으면 API Gateway가 Lambda 함수를 호출합니다. 1. Lambda 함수가 호출자를 인증합니다. 이 함수는 다음과 같은 방식으로 인증될 수 있습니다. + OAuth 공급자를 직접적으로 호출하여 OAuth 액세스 토큰을 받습니다. + SAML 공급자를 직접적으로 호출하여 SAML 어설션을 받습니다. + 요청 파라미터 값을 기반으로 IAM 정책을 생성합니다. + 데이터베이스에서 자격 증명을 가져옵니다. 1. Lambda 함수가 IAM 정책과 보안 주체 식별자를 반환합니다. Lambda 함수가 해당 정보를 반환하지 않으면 직접 호출이 실패합니다. 1. API Gateway가 IAM 정책을 평가합니다. + 액세스가 거부되면 API Gateway는 적절한 HTTP 상태 코드(예: `403 ACCESS_DENIED`)를 반환합니다. + 액세스가 허용되면 API Gateway가 메서드를 간접 호출합니다. 권한 부여 캐싱이 활성화된 경우, API Gateway는 Lambda 권한 부여자 함수가 다시 간접적으로 호출되지 않도록 정책을 캐싱합니다. 정책이 API의 모든 리소스 및 메서드에 적용 가능한지 확인합니다. `403 ACCESS_DENIED` 또는 `401 UNAUTHORIZED` 게이트웨이 응답을 사용자 지정할 수 있습니다. 자세한 내용은 [API Gateway의 REST API에 대한 게이트웨이 응답](api-gateway-gatewayResponse-definition.md)를 참조하세요. ## Lambda 권한 부여자 유형 선택 Lambda 권한 부여자는 두 가지 유형이 있습니다. **요청 파라미터 기반 Lambda 권한 부여자(`REQUEST` 권한 부여자)** `REQUEST` 권한 부여자는 헤더, 쿼리 문자열 파라미터, [`stageVariables`](api-gateway-mapping-template-reference.md#stagevariables-template-reference), [`$context`](api-gateway-mapping-template-reference.md#context-variable-reference) 변수 조합에 있는 직접 호출자 자격 증명을 받습니다. `REQUEST` 권한 부여자를 사용하여 `$context.path` 및 `$context.httpMethod` 컨텍스트 변수와 같은 여러 자격 증명 소스의 정보를 기반으로 세분화된 정책을 생성할 수 있습니다. `REQUEST` 권한 부여자에 대한 권한 부여 캐싱을 켜면 API Gateway는 요청에 지정된 모든 자격 증명 소스가 있는지 확인합니다. 지정된 자격 증명 소스가 없거나, null이거나, 비어 있을 경우 API Gateway가 Lambda 권한 부여자 함수를 호출하지 않고 `401 Unauthorized` HTTP 응답을 반환합니다. 여러 개의 자격 증명 소스가 정의된 경우, 이들은 순서가 유지된 상태로 모두 권한 부여자의 캐시 키를 도출하는 데 사용됩니다. 여러 자격 증명 소스를 사용하여 세분화된 캐시 키를 정의할 수 있습니다. 캐시 키 부분을 변경하고 API를 재배포하면 권한 부여자가 캐시된 정책 문서를 폐기하고 새로 생성합니다. `REQUEST` 권한 부여자에 대한 권한 부여 캐싱을 끄면 API Gateway가 요청을 Lambda 함수에 직접 전달합니다. **토큰 기반 Lambda 권한 부여자(`TOKEN` 권한 부여자)** `TOKEN` 권한 부여자는 보유자 토큰(JSON Web Token(JWT) 또는 OAuth 토큰)에 있는 호출자의 자격 증명을 받습니다. `TOKEN` 권한 부여자에 대한 인증 캐싱을 켜는 경우 토큰 소스에 지정된 헤더 이름이 캐시 키가 됩니다. 또한 토큰 검증을 사용하여 정규 표현식 문을 입력할 수 있습니다. API Gateway는 이 표현식에 대해 입력 토큰의 초기 검증을 수행하고 검증에 성공할 경우 Lambda 권한 부여자 함수를 간접적으로 호출합니다. 이렇게 하면 API 호출을 줄일 수 있습니다. `IdentityValidationExpression` 속성은 `TOKEN` 권한 부여자에만 지원됩니다. 자세한 내용은 [x-amazon-apigateway-authorizer 객체](api-gateway-swagger-extensions-authorizer.md) 섹션을 참조하세요. **참고** `REQUEST` 권한 부여자를 사용하여 API에 대한 액세스를 제어하는 것이 좋습니다. `TOKEN` 권한 부여자를 사용할 때는 단일 자격 증명 소스를 기반으로 하지만 `REQUEST` 권한 부여자를 사용할 때는 여러 자격 증명 소스를 기반으로 하여 API에 대한 액세스를 제어할 수 있습니다. 또한 `REQUEST` 권한 부여자의 경우 여러 자격 증명 소스를 사용하여 캐시 키를 분리할 수 있습니다. ## `REQUEST` 권한 부여자 Lambda 함수 예제 다음 예제 코드는 클라이언트가 제공한 `HeaderAuth1` 헤더, `QueryString1` 쿼리 파라미터 및 스테이지 변수 `StageVar1`이 모두 `headerValue1`, `queryValue1`, `stageValue1`의 지정된 값과 각각 일치하는 경우 요청을 허용하는 Lambda 권한 부여 함수를 생성합니다. ------ #### [ Node.js ] ``` // A simple request-based authorizer example to demonstrate how to use request // parameters to allow or deny a request. In this example, a request is // authorized if the client-supplied HeaderAuth1 header, QueryString1 // query parameter, and stage variable of StageVar1 all match // specified values of 'headerValue1', 'queryValue1', and 'stageValue1', // respectively. export const handler = function(event, context, callback) { console.log('Received event:', JSON.stringify(event, null, 2)); // Retrieve request parameters from the Lambda function input: var headers = event.headers; var queryStringParameters = event.queryStringParameters; var pathParameters = event.pathParameters; var stageVariables = event.stageVariables; // Parse the input for the parameter values var tmp = event.methodArn.split(':'); var apiGatewayArnTmp = tmp[5].split('/'); var awsAccountId = tmp[4]; var region = tmp[3]; var restApiId = apiGatewayArnTmp[0]; var stage = apiGatewayArnTmp[1]; var method = apiGatewayArnTmp[2]; var resource = '/'; // root resource if (apiGatewayArnTmp[3]) { resource += apiGatewayArnTmp[3]; } // Perform authorization to return the Allow policy for correct parameters and // the 'Unauthorized' error, otherwise. if (headers.HeaderAuth1 === "headerValue1" && queryStringParameters.QueryString1 === "queryValue1" && stageVariables.StageVar1 === "stageValue1") { callback(null, generateAllow('me', event.methodArn)); } else { callback(null, generateDeny('me', event.methodArn)); } } // Help function to generate an IAM policy var generatePolicy = function(principalId, effect, resource) { // Required output: var authResponse = {}; authResponse.principalId = principalId; if (effect && resource) { var policyDocument = {}; policyDocument.Version = '2012-10-17'; // default version policyDocument.Statement = []; var statementOne = {}; statementOne.Action = 'execute-api:Invoke'; // default action statementOne.Effect = effect; statementOne.Resource = resource; policyDocument.Statement[0] = statementOne; authResponse.policyDocument = policyDocument; } // Optional output with custom properties of the String, Number or Boolean type. authResponse.context = { "stringKey": "stringval", "numberKey": 123, "booleanKey": true }; return authResponse; } var generateAllow = function(principalId, resource) { return generatePolicy(principalId, 'Allow', resource); } var generateDeny = function(principalId, resource) { return generatePolicy(principalId, 'Deny', resource); } ``` ------ #### [ Python ] ``` # A simple request-based authorizer example to demonstrate how to use request # parameters to allow or deny a request. In this example, a request is # authorized if the client-supplied headerauth1 header, QueryString1 # query parameter, and stage variable of StageVar1 all match # specified values of 'headerValue1', 'queryValue1', and 'stageValue1', # respectively. def lambda_handler(event, context): print(event) # Retrieve request parameters from the Lambda function input: headers = event['headers'] queryStringParameters = event['queryStringParameters'] pathParameters = event['pathParameters'] stageVariables = event['stageVariables'] # Parse the input for the parameter values tmp = event['methodArn'].split(':') apiGatewayArnTmp = tmp[5].split('/') awsAccountId = tmp[4] region = tmp[3] restApiId = apiGatewayArnTmp[0] stage = apiGatewayArnTmp[1] method = apiGatewayArnTmp[2] resource = '/' if (apiGatewayArnTmp[3]): resource += apiGatewayArnTmp[3] # Perform authorization to return the Allow policy for correct parameters # and the 'Unauthorized' error, otherwise. if (headers['HeaderAuth1'] == "headerValue1" and queryStringParameters['QueryString1'] == "queryValue1" and stageVariables['StageVar1'] == "stageValue1"): response = generateAllow('me', event['methodArn']) print('authorized') return response else: print('unauthorized') response = generateDeny('me', event['methodArn']) return response # Help function to generate IAM policy def generatePolicy(principalId, effect, resource): authResponse = {} authResponse['principalId'] = principalId if (effect and resource): policyDocument = {} policyDocument['Version'] = '2012-10-17' policyDocument['Statement'] = [] statementOne = {} statementOne['Action'] = 'execute-api:Invoke' statementOne['Effect'] = effect statementOne['Resource'] = resource policyDocument['Statement'] = [statementOne] authResponse['policyDocument'] = policyDocument authResponse['context'] = { "stringKey": "stringval", "numberKey": 123, "booleanKey": True } return authResponse def generateAllow(principalId, resource): return generatePolicy(principalId, 'Allow', resource) def generateDeny(principalId, resource): return generatePolicy(principalId, 'Deny', resource) ``` ------ 이 예제에서 Lambda 권한 부여자 함수는 입력 파라미터를 확인하고 다음과 같이 동작합니다. + 필요한 모든 파라미터 값이 예상 값과 일치하면 권한 부여자 함수가 `200 OK` HTTP 응답 및 다음과 같은 IAM 정책을 반환하고 메서드 요청이 성공합니다. ------ #### [ JSON ] **** ``` { "Version":"2012-10-17", "Statement": [ { "Action": "execute-api:Invoke", "Effect": "Allow", "Resource": "arn:aws:execute-api:us-east-1:123456789012:ivdtdhp7b5/ESTestInvoke-stage/GET/" } ] } ``` ------ + 일치하지 않으면 권한 부여자 함수가 `401 Unauthorized` HTTP 응답을 반환하고 메서드 요청이 실패합니다. Lambda 권한 부여자 함수는 IAM 정책을 반환하는 것 외에 호출자의 보안 주체 ID도 반환해야 합니다. 선택적으로 통합 백엔드로 전달될 수 있는 추가 정보를 포함하는 `context` 객체를 반환할 수 있습니다. 자세한 내용은 [API Gateway Lambda 권한 부여자의 출력](api-gateway-lambda-authorizer-output.md) 섹션을 참조하세요. 프로덕션 코드에서는 권한 부여를 허용하기 전에 사용자를 인증해야 할 수 있습니다. 해당 공급자의 설명서에 나온 대로 인증 공급자를 직접적으로 호출하여 Lambda 함수에 인증 로직을 추가할 수 있습니다. ## `TOKEN` 권한 부여자 Lambda 함수 예제 다음 예제 코드는 클라이언트 제공 토큰 값이 `allow`이면 호출자가 메서드를 간접적으로 호출하도록 허용하는 `TOKEN` Lambda 권한 부여자 함수를 생성합니다. 토큰 값이 `deny`이면 호출자가 요청을 간접적으로 호출할 수 없습니다. 토큰 값이 `unauthorized` 또는 빈 문자열인 경우 권한 부여자 함수는 `401 UNAUTHORIZED` 응답을 반환합니다. ------ #### [ Node.js ] ``` // A simple token-based authorizer example to demonstrate how to use an authorization token // to allow or deny a request. In this example, the caller named 'user' is allowed to invoke // a request if the client-supplied token value is 'allow'. The caller is not allowed to invoke // the request if the token value is 'deny'. If the token value is 'unauthorized' or an empty // string, the authorizer function returns an HTTP 401 status code. For any other token value, // the authorizer returns an HTTP 500 status code. // Note that token values are case-sensitive. export const handler = function(event, context, callback) { var token = event.authorizationToken; switch (token) { case 'allow': callback(null, generatePolicy('user', 'Allow', event.methodArn)); break; case 'deny': callback(null, generatePolicy('user', 'Deny', event.methodArn)); break; case 'unauthorized': callback("Unauthorized"); // Return a 401 Unauthorized response break; default: callback("Error: Invalid token"); // Return a 500 Invalid token response } }; // Help function to generate an IAM policy var generatePolicy = function(principalId, effect, resource) { var authResponse = {}; authResponse.principalId = principalId; if (effect && resource) { var policyDocument = {}; policyDocument.Version = '2012-10-17'; policyDocument.Statement = []; var statementOne = {}; statementOne.Action = 'execute-api:Invoke'; statementOne.Effect = effect; statementOne.Resource = resource; policyDocument.Statement[0] = statementOne; authResponse.policyDocument = policyDocument; } // Optional output with custom properties of the String, Number or Boolean type. authResponse.context = { "stringKey": "stringval", "numberKey": 123, "booleanKey": true }; return authResponse; } ``` ------ #### [ Python ] ``` # A simple token-based authorizer example to demonstrate how to use an authorization token # to allow or deny a request. In this example, the caller named 'user' is allowed to invoke # a request if the client-supplied token value is 'allow'. The caller is not allowed to invoke # the request if the token value is 'deny'. If the token value is 'unauthorized' or an empty # string, the authorizer function returns an HTTP 401 status code. For any other token value, # the authorizer returns an HTTP 500 status code. # Note that token values are case-sensitive. import json def lambda_handler(event, context): token = event['authorizationToken'] if token == 'allow': print('authorized') response = generatePolicy('user', 'Allow', event['methodArn']) elif token == 'deny': print('unauthorized') response = generatePolicy('user', 'Deny', event['methodArn']) elif token == 'unauthorized': print('unauthorized') raise Exception('Unauthorized') # Return a 401 Unauthorized response return 'unauthorized' try: return json.loads(response) except BaseException: print('unauthorized') return 'unauthorized' # Return a 500 error def generatePolicy(principalId, effect, resource): authResponse = {} authResponse['principalId'] = principalId if (effect and resource): policyDocument = {} policyDocument['Version'] = '2012-10-17' policyDocument['Statement'] = [] statementOne = {} statementOne['Action'] = 'execute-api:Invoke' statementOne['Effect'] = effect statementOne['Resource'] = resource policyDocument['Statement'] = [statementOne] authResponse['policyDocument'] = policyDocument authResponse['context'] = { "stringKey": "stringval", "numberKey": 123, "booleanKey": True } authResponse_JSON = json.dumps(authResponse) return authResponse_JSON ``` ------ 이 예제에서는 API가 메서드 요청을 받을 때 API Gateway가 소스 토큰을 이 Lambda 권한 부여자 함수의 `event.authorizationToken` 속성에 전달합니다. Lambda 권한 부여자 함수는 토큰을 읽고 다음과 같이 동작합니다. + 토큰 값이 `allow`인 경우 권한 부여자 함수는 `200 OK` HTTP 응답 및 다음과 같은 IAM 정책을 반환하고 메서드 요청이 성공합니다. ------ #### [ JSON ] **** ``` { "Version":"2012-10-17", "Statement": [ { "Action": "execute-api:Invoke", "Effect": "Allow", "Resource": "arn:aws:execute-api:us-east-1:123456789012:ivdtdhp7b5/ESTestInvoke-stage/GET/" } ] } ``` ------ + 토큰 값이 `deny`인 경우 권한 부여자 함수는 `200 OK` HTTP 응답 및 다음과 같은 `Deny` IAM 정책을 반환하고 메서드 요청이 실패합니다. ------ #### [ JSON ] **** ``` { "Version":"2012-10-17", "Statement": [ { "Action": "execute-api:Invoke", "Effect": "Deny", "Resource": "arn:aws:execute-api:us-east-1:123456789012:ivdtdhp7b5/ESTestInvoke-stage/GET/" } ] } ``` ------ **참고** 테스트 환경 밖에서는 API Gateway가 `403 Forbidden` HTTP 응답을 반환하고 메서드 요청이 실패합니다. + 토큰 값이 `unauthorized`이나 빈 문자열인 경우 권한 부여자 함수는 `401 Unauthorized` HTTP 응답을 반환하고 메서드 호출이 실패합니다. + 그 외 토큰의 경우 클라이언트는 `500 Invalid token` 응답을 수신하고, 메서드 호출은 실패합니다. Lambda 권한 부여자 함수는 IAM 정책을 반환하는 것 외에 호출자의 보안 주체 ID도 반환해야 합니다. 선택적으로 통합 백엔드로 전달될 수 있는 추가 정보를 포함하는 `context` 객체를 반환할 수 있습니다. 자세한 내용은 [API Gateway Lambda 권한 부여자의 출력](api-gateway-lambda-authorizer-output.md) 섹션을 참조하세요. 프로덕션 코드에서는 권한 부여를 허용하기 전에 사용자를 인증해야 할 수 있습니다. 해당 공급자의 설명서에 나온 대로 인증 공급자를 직접적으로 호출하여 Lambda 함수에 인증 로직을 추가할 수 있습니다. ## Lambda 권한 부여자 함수의 추가 예제 다음 목록은 Lambda 권한 부여자 함수의 추가 예제를 보여줍니다. API를 생성한 계정과 동일한 계정이나 다른 계정에서 Lambda 함수를 생성할 수 있습니다. 이전 Lambda 함수 예제는 다른 AWS 서비스를 직접적으로 호출하지 않으므로 기본으로 제공되는 [AWSLambdaBasicExecutionRole](https://docs.aws.amazon.com/lambda/latest/dg/lambda-intro-execution-role.html)을 사용할 수 있습니다. Lambda 함수가 다른 AWS 서비스를 호출한다면 Lambda 함수에 IAM 실행 역할을 할당해야 합니다. 역할을 생성하려면 [AWS Lambda 실행 역할](https://docs.aws.amazon.com/lambda/latest/dg/lambda-intro-execution-role.html)의 지침을 따르세요. **Lambda 권한 부여자 함수의 추가 예제** + 예제 애플리케이션은 GitHub의 [Open Banking Brazil - Authorization Samples](https://github.com/aws-samples/openbanking-brazilian-auth-samples)를 참조하세요. + 더 많은 Lambda 함수 예제는 GitHub에 있는 [ aws-apigateway-lambda-authorizer-blueprints](https://github.com/awslabs/aws-apigateway-lambda-authorizer-blueprints)를 참조하세요. + Amazon Cognito 사용자 풀을 사용하여 사용자를 인증하고 Verified Permissions를 사용하여 정책 스토어를 기반으로 호출자에게 권한을 부여하는 Lambda 권한 부여자를 생성할 수 있습니다. 자세한 내용은 [Verified Permissions를 사용하여 자격 증명의 속성을 기반으로 액세스 제어](apigateway-lambda-authorizer-verified-permissions.md) 섹션을 참조하세요. + Lambda 콘솔은 Python 블루프린트를 제공합니다. **블루프린트 사용**을 선택하고 **api-gateway-authorizer-python** 블루프린트를 선택하여 이 블루프린트를 사용할 수 있습니다. # API Gateway Lambda 권한 부여자 구성 Lambda 함수를 생성한 후 Lambda 함수를 API의 권한 부여자로 구성합니다. 그런 다음 Lambda 권한 부여자를 간접적으로 호출하도록 메서드를 구성하여 호출자가 메서드를 간접적으로 호출할 수 있는지 확인합니다. API를 생성한 계정과 동일한 계정이나 다른 계정에서 Lambda 함수를 생성할 수 있습니다. API Gateway 콘솔에 기본으로 제공되는 도구를 사용하거나 [Postman](https://www.postman.com/)을 사용하여 Lambda 권한 부여자를 테스트할 수 있습니다. Postman을 사용하여 Lambda 권한 부여 함수를 테스트하는 방법에 대한 지침은 [API Gateway Lambda 권한 부여자를 사용한 API 직접 호출](call-api-with-api-gateway-lambda-authorization.md) 섹션을 참조하세요. ## Lambda 권한 부여자 구성(콘솔) 다음 절차는 API Gateway REST API 콘솔에서 Lambda 권한 부여자를 생성하는 방법을 보여줍니다. 다른 Lambda 권한 부여자 유형에 대해 자세히 알아보려면 [Lambda 권한 부여자 유형 선택](apigateway-use-lambda-authorizer.md#api-gateway-lambda-authorizer-choose) 섹션을 참조하세요. ------ #### [ REQUEST authorizer ] **`REQUEST` Lambda 권한 부여자를 구성하려면** 1. [https://console.aws.amazon.com/apigateway](https://console.aws.amazon.com/apigateway)에서 API Gateway 콘솔에 로그인합니다. 1. API를 선택한 다음 **권한 부여자**를 선택합니다. 1. **권한 부여자 생성**을 선택합니다. 1. **권한 부여자 이름**에 권한 부여자의 이름을 입력합니다. 1. **권한 부여자 유형**으로 **Lambda**를 선택합니다. 1. **Lambda 함수** 함수에서 Lambda 권한 부여자 함수를 생성한 AWS 리전을 선택하고 함수 이름을 입력합니다. 1. API Gateway REST API 콘솔이 리소스 기반 정책을 설정하도록 **Lambda 호출 역할**을 비워 둡니다. 이 정책은 API Gateway에 Lambda 권한 부여자 함수를 간접적으로 호출할 권한을 부여합니다. API Gateway가 Lambda 권한 부여자 함수를 간접적으로 호출하도록 허용하는 IAM 역할의 이름을 입력할 수도 있습니다. 예시 역할은 [맡을 수 있는 IAM 역할 생성](integrating-api-with-aws-services-lambda.md#api-as-lambda-proxy-setup-iam-role-policies) 섹션을 참조하세요. 1. **Lambda 이벤트 페이로드**로 **요청**을 선택합니다. 1. **자격 증명 소스 유형**에서 파리미터 유형을 선택합니다. 지원되는 파라미터 유형은 `Header`, `Query string`, `Stage variable` 및 `Context`입니다. 자격 증명 소스를 더 추가하려면 **파라미터 추가**를 선택합니다. 1. 권한 부여자에 의해 생성된 권한 부여 정책을 캐싱하려면 **권한 부여 캐싱**을 설정해 둡니다. 정책 캐싱을 활성화한 경우 **TTL** 값을 수정할 수 있습니다. **TTL**을 0으로 설정하면 정책 캐싱이 비활성화됩니다. 캐싱을 활성화하는 경우 권한 부여자가 API 전체의 모든 메서드에 적용 가능한 정책을 반환해야 합니다. 메서드별 정책을 적용하려면 컨텍스트 변수 `$context.path` 및 `$context.httpMethod`를 사용하세요. 1. **권한 부여자 생성**을 선택합니다. ------ #### [ TOKEN authorizer ] **`TOKEN` Lambda 권한 부여자를 구성하려면** 1. [https://console.aws.amazon.com/apigateway](https://console.aws.amazon.com/apigateway)에서 API Gateway 콘솔에 로그인합니다. 1. API를 선택한 다음 **권한 부여자**를 선택합니다. 1. **권한 부여자 생성**을 선택합니다. 1. **권한 부여자 이름**에 권한 부여자의 이름을 입력합니다. 1. **권한 부여자 유형**으로 **Lambda**를 선택합니다. 1. **Lambda 함수** 함수에서 Lambda 권한 부여자 함수를 생성한 AWS 리전을 선택하고 함수 이름을 입력합니다. 1. API Gateway REST API 콘솔이 리소스 기반 정책을 설정하도록 **Lambda 호출 역할**을 비워 둡니다. 이 정책은 API Gateway에 Lambda 권한 부여자 함수를 간접적으로 호출할 권한을 부여합니다. API Gateway가 Lambda 권한 부여자 함수를 간접적으로 호출하도록 허용하는 IAM 역할의 이름을 입력할 수도 있습니다. 예시 역할은 [맡을 수 있는 IAM 역할 생성](integrating-api-with-aws-services-lambda.md#api-as-lambda-proxy-setup-iam-role-policies) 섹션을 참조하세요. 1. **Lambda 이벤트 페이로드**로 **토큰**을 선택합니다. 1. **토큰 소스**에 인증 토큰이 포함된 헤더 이름을 입력합니다. 호출자는 권한 부여 토큰을 Lambda 권한 부여자에게 전송하기 위해 이 이름의 헤더를 포함해야 합니다. 1. (선택 사항) **토큰 검증**에 정규 표현식 문을 입력합니다. API Gateway는 이 표현식에 대해 입력 토큰의 초기 확인을 수행하고 확인이 성공할 경우 권한 부여자를 호출합니다. 1. 권한 부여자에 의해 생성된 권한 부여 정책을 캐싱하려면 **권한 부여 캐싱**을 설정해 둡니다. 정책 캐싱을 비활성화한 경우 **토큰 소스**에 지정된 헤더 이름이 캐시 키가 됩니다. 정책 캐싱을 활성화한 경우 **TTL** 값을 수정할 수 있습니다. **TTL**을 0으로 설정하면 정책 캐싱이 비활성화됩니다. 캐싱을 활성화하는 경우 권한 부여자가 API 전체의 모든 메서드에 적용 가능한 정책을 반환해야 합니다. 메서드별 정책을 적용하려는 경우 **권한 부여자 캐싱**을 끌 수 있습니다. 1. **권한 부여자 생성**을 선택합니다. ------ Lambda 권한 부여자를 생성한 후 테스트할 수 있습니다. 다음 절차는 Lambda 권한 부여자를 테스트하는 방법을 보여줍니다. ------ #### [ REQUEST authorizer ] **`REQUEST` Lambda 권한 부여자를 테스트하려면** 1. [https://console.aws.amazon.com/apigateway](https://console.aws.amazon.com/apigateway)에서 API Gateway 콘솔에 로그인합니다. 1. 권한 부여자의 이름을 선택합니다. 1. **테스트 권한 부여자**에 자격 증명 소스의 값을 입력합니다. [`REQUEST` 권한 부여자 Lambda 함수 예제](apigateway-use-lambda-authorizer.md#api-gateway-lambda-authorizer-request-lambda-function-create)를 사용하는 경우 다음과 같이 합니다. 1. **헤더**를 선택하고 **headerValue1**을 입력한 다음 **파라미터 추가**를 선택합니다. 1. **자격 증명 소스 유형**에서 **쿼리 문자열**을 선택한 다음 **queryValue1**을 입력하고 **파라미터 추가**를 선택합니다. 1. **자격 증명 소스 유형**에서 **스테이지 변수**를 선택하고 **stageValue1**을 입력합니다. 테스트 간접 호출을 위한 컨텍스트 변수는 수정할 수 없지만 Lambda 함수의 **API Gateway 권한 부여자** 테스트 이벤트 템플릿은 수정할 수 있습니다. 그런 다음 수정된 컨텍스트 변수를 사용하여 Lambda 권한 부여자 함수를 테스트할 수 있습니다. 자세한 내용은 AWS Lambda 개발자 안내서의 [콘솔에서 Lambda 함수 테스팅](https://docs.aws.amazon.com/lambda/latest/dg/testing-functions.html)을 참조하세요.** 1. **테스트 권한 부여자**를 선택합니다. ------ #### [ TOKEN authorizer ] **`TOKEN` Lambda 권한 부여자를 테스트하려면** 1. [https://console.aws.amazon.com/apigateway](https://console.aws.amazon.com/apigateway)에서 API Gateway 콘솔에 로그인합니다. 1. 권한 부여자의 이름을 선택합니다. 1. **테스트 권한 부여자**에 토큰 값을 입력합니다. [`TOKEN` 권한 부여자 Lambda 함수 예제](apigateway-use-lambda-authorizer.md#api-gateway-lambda-authorizer-token-lambda-function-create)를 사용하는 경우 다음과 같이 합니다. 1. **authorizationToken**에 **allow**를 입력합니다. 1. **테스트 권한 부여자**를 선택합니다. Lambda 권한 부여자가 테스트 환경에서 요청을 성공적으로 거부하면 테스트는 `200 OK` HTTP 응답으로 응답합니다. 그러나 테스트 환경 밖에서는 API Gateway가 `403 Forbidden` HTTP 응답을 반환하고 메서드 요청이 실패합니다. ------ ## Lambda 권한 부여자 구성(AWS CLI) 다음 [create-authorizer](https://docs.aws.amazon.com/cli/latest/reference/apigateway/create-authorizer.html) 명령은 AWS CLI를 사용하여 Lambda 권한 부여자를 생성하는 방법을 보여줍니다. ------ #### [ REQUEST authorizer ] 다음 [create-authorizer](https://docs.aws.amazon.com/cli/latest/reference/apigateway/create-authorizer.html) 명령은 `REQUEST` 권한 부여자를 생성하고 `Authorizer` 헤더와 `accountId` 컨텍스트 변수를 자격 증명 소스로 사용합니다. ``` aws apigateway create-authorizer \ --rest-api-id 1234123412 \ --name 'First_Request_Custom_Authorizer' \ --type REQUEST \ --authorizer-uri 'arn:aws:apigateway:us-west-2:lambda:path/2015-03-31/functions/arn:aws:lambda:us-west-2:123412341234:function:customAuthFunction/invocations' \ --identity-source 'method.request.header.Authorization,context.accountId' \ --authorizer-result-ttl-in-seconds 300 ``` ------ #### [ TOKEN authorizer ] 다음 [create-authorizer](https://docs.aws.amazon.com/cli/latest/reference/apigateway/create-authorizer.html) 명령은 `TOKEN` 권한 부여자를 생성하고 `Authorization` 헤더를 자격 증명 소스로 사용합니다. ``` aws apigateway create-authorizer \ --rest-api-id 1234123412 \ --name 'First_Token_Custom_Authorizer' \ --type TOKEN \ --authorizer-uri 'arn:aws:apigateway:us-west-2:lambda:path/2015-03-31/functions/arn:aws:lambda:us-west-2:123412341234:function:customAuthFunction/invocations' \ --identity-source 'method.request.header.Authorization' \ --authorizer-result-ttl-in-seconds 300 ``` ------ Lambda 권한 부여자를 생성한 후 테스트할 수 있습니다. 다음 [test-invoke-authorizer](https://docs.aws.amazon.com/cli/latest/reference/apigateway/test-invoke-authorizer.html) 명령은 Lambda 권한 부여자를 테스트합니다. ``` aws apigateway test-invoke-authorizer --rest-api-id 1234123412 \ --authorizer-id efg1234 \ --headers Authorization='Value' ``` ## Lambda 권한 부여자를 사용하도록 메서드 구성(콘솔) Lambda 권한 부여자를 구성한 후 API에 대한 메서드에 연결해야 합니다. 권한 부여자가 권한 부여 캐싱을 사용하는 경우 정책을 업데이트하여 추가 메서드에 대한 액세스를 제어해야 합니다. **Lambda 권한 부여자를 사용하도록 API 메서드를 구성하려면** 1. [https://console.aws.amazon.com/apigateway](https://console.aws.amazon.com/apigateway)에서 API Gateway 콘솔에 로그인합니다. 1. API를 선택합니다. 1. **리소스**를 선택한 다음 새 메서드를 선택하거나 기존 메서드를 선택합니다. 1. **메서드 요청** 탭의 **메서드 요청 설정**에서 **편집**을 선택합니다. 1. **권한 부여자**의 경우 드롭다운 메뉴에서 방금 생성한 Lambda 권한 부여자를 선택합니다. 1. (선택 사항) 권한 부여 토큰을 백엔드로 전달하려면 **HTTP 요청 헤더**를 선택합니다. **헤더 추가**를 선택한 다음 인증 헤더의 이름을 추가합니다. **이름**에서, API에 대한 Lambda 권한 부여자를 생성할 때 지정한 **토큰 소스** 이름과 일치하는 헤더 이름을 입력합니다. `REQUEST` 권한 부여자에는 이 단계가 적용되지 않습니다. 1. **저장**을 선택합니다. 1. **Deploy API(API 배포)**를 선택하여 단계에 API를 배포합니다. 스테이지 변수를 사용하는 `REQUEST` 권한 부여자의 경우 **스테이지** 페이지가 열려 있는 동안 필요한 스테이지 변수를 지정하고 값을 지정해야 합니다. ## Lambda 권한 부여자를 사용하도록 메서드 구성(AWS CLI) Lambda 권한 부여자를 구성한 후 API에 대한 메서드에 연결해야 합니다. 새 메서드를 생성하거나 패치 작업을 사용하여 권한 부여자를 기존 메서드에 연결할 수 있습니다. 권한 부여자가 권한 부여 캐싱을 사용하는 경우 정책을 업데이트하여 추가 메서드에 대한 액세스를 제어해야 합니다. 다음 [put-method](https://docs.aws.amazon.com/cli/latest/reference/apigateway/put-method.html) 명령은 Lambda 권한 부여자를 사용하는 새 메서드를 생성합니다. ``` aws apigateway put-method --rest-api-id 1234123412 \ --resource-id a1b2c3 \ --http-method PUT \ --authorization-type CUSTOM \ --authorizer-id efg1234 ``` 다음 [update-method](https://docs.aws.amazon.com/cli/latest/reference/apigateway/update-method.html) 명령은 Lambda 권한 부여자를 사용하도록 기존 메서드를 업데이트합니다. ``` aws apigateway update-method \ --rest-api-id 1234123412 \ --resource-id a1b2c3 \ --http-method PUT \ --patch-operations op="replace",path="/authorizationType",value="CUSTOM" op="replace",path="/authorizerId",value="efg1234" ``` # API Gateway Lambda 권한 부여자에 대한 입력 다음 섹션에서는 API Gateway에서 Lambda 권한 부여자로 보내는 입력 형식을 설명합니다. ## `TOKEN` 입력 형식 `TOKEN` 유형 Lambda 권한 부여자(이전에는 사용자 지정 권한 부여자라고 함)의 경우 API에 대해 권한 부여자를 구성할 때 사용자 지정 헤더를 **토큰 원본**으로 지정해야 합니다. API 클라이언트는 수신되는 요청에 있는 해당 헤더의 권한 부여 토큰을 전달해야 합니다. 메서드 요청을 수신하면 API Gateway는 사용자 지정 헤더로부터 토큰을 추출합니다. 그런 다음 토큰을 Lambda 함수 내 `authorizationToken` 객체의 `event` 속성으로 전달하고 메서드 ARN을 `methodArn` 속성으로 전달합니다. ``` { "type":"TOKEN", "authorizationToken":"{caller-supplied-token}",     "methodArn":"arn:aws:execute-api:{regionId}:{accountId}:{apiId}/{stage}/{httpVerb}/[{resource}/[{child-resources}]]" } ``` 이 예제에서 `type` 속성은 권한 부여자 유형(`TOKEN` 권한 부여자)을 지정합니다. `{caller-supplied-token}`의 출처는 클라이언트 요청의 권한 부여 헤더이며 모든 문자열 값이 될 수 있습니다. `methodArn`은 수신 메서드 요청의 ARN이며 API Gateway에서 Lambda 권한 부여자 구성에 따라 채워집니다. ## `REQUEST` 입력 형식 `REQUEST` 유형의 Lambda 권한 부여자의 경우, API Gateway가 요청 파라미터를 `event` 객체의 일부로 Lambda 함수에 전달합니다. 이러한 요청 파라미터에는 헤더, 경로 파라미터, 쿼리 문자열 파라미터, 단계 변수 및 일부 요청 컨텍스트 변수가 포함됩니다. API 호출자는 경로 파라미터, 헤더 및 쿼리 문자열 파라미터를 설정할 수 있습니다. API 개발자는 API를 배포할 때 단계 변수를 설정해야 하며, API Gateway는 런타임 시 요청 컨텍스트를 제공합니다. **참고** 경로 파라미터는 Lambda 권한 부여자 함수에 요청 파라미터로 전달될 수 있지만, 자격 증명 원본으로 사용될 수는 없습니다. 다음 예제는 프록시 통합을 포함하는 API 메서드(`REQUEST`)에 대한 `GET /request` 권한 부여자에 대한 입력입니다. ``` { "type": "REQUEST", "methodArn": "arn:aws:execute-api:us-east-1:123456789012:abcdef123/test/GET/request", "resource": "/request", "path": "/request", "httpMethod": "GET", "headers": { "X-AMZ-Date": "20170718T062915Z", "Accept": "*/*", "HeaderAuth1": "headerValue1", "CloudFront-Viewer-Country": "US", "CloudFront-Forwarded-Proto": "https", "CloudFront-Is-Tablet-Viewer": "false", "CloudFront-Is-Mobile-Viewer": "false", "User-Agent": "..." }, "queryStringParameters": { "QueryString1": "queryValue1" }, "pathParameters": {}, "stageVariables": { "StageVar1": "stageValue1" }, "requestContext": { "path": "/request", "accountId": "123456789012", "resourceId": "05c7jb", "stage": "test", "requestId": "...", "identity": { "apiKey": "...", "sourceIp": "...", "clientCert": { "clientCertPem": "CERT_CONTENT", "subjectDN": "www.example.com", "issuerDN": "Example issuer", "serialNumber": "a1:a1:a1:a1:a1:a1:a1:a1:a1:a1:a1:a1:a1:a1:a1:a1", "validity": { "notBefore": "May 28 12:30:02 2019 GMT", "notAfter": "Aug 5 09:36:04 2021 GMT" } } }, "resourcePath": "/request", "httpMethod": "GET", "apiId": "abcdef123" } } ``` `requestContext`는 키-값 페어의 맵이며 [\$1context](api-gateway-mapping-template-reference.md#context-variable-reference) 변수에 해당합니다. 결과는 API 종속적입니다. API Gateway는 새 키를 맵에 추가할 수 있습니다. Lambda 프록시 통합에서의 Lambda 함수에 대한 자세한 내용은 [프록시 통합에 대한 Lambda 함수의 입력 형식](set-up-lambda-proxy-integrations.md#api-gateway-simple-proxy-for-lambda-input-format) 단원을 참조하세요. # API Gateway Lambda 권한 부여자의 출력 Lambda 권한 부여자 함수의 출력은 사전과 같은 객체이며, 이 객체에는 보안 주체 ID(`principalId`)와 정책 설명 목록이 들어 있는 정책 문서(`policyDocument`)가 포함되어 있어야 합니다. 또한 키-값 페어를 포함하는 `context` 맵을 포함할 수 있습니다. API가 사용량 계획을 사용하는 경우([https://docs.aws.amazon.com/apigateway/latest/api/API_RestApi.html#apiKeySource](https://docs.aws.amazon.com/apigateway/latest/api/API_RestApi.html#apiKeySource)가 `AUTHORIZER`로 설정됨), Lambda 권한 부여자 함수는 `usageIdentifierKey` 속성 값으로 사용량 계획의 API 키 중 하나를 반환해야 합니다. 다음은 이 출력의 예입니다. ------ #### [ JSON ] **** ``` {   "principalId": "yyyyyyyy", "policyDocument": { "Version":"2012-10-17", "Statement": [ { "Action": "execute-api:Invoke", "Effect": "Allow|Deny", "Resource": "arn:aws:execute-api:{regionId}:{accountId}:{apiId}/{stage}/{httpVerb}/[{resource}/[{child-resources}]]" } ] }, "context": { "stringKey": "value", "numberKey": "1", "booleanKey": "true" }, "usageIdentifierKey": "{api-key}" } ``` ------ 여기서 정책 설명은 API Gateway 실행 서비스에서 지정된 API 메서드(`Effect`)를 호출(`Action`)하도록 허용할지 거부할지(`Resource`) 여부를 지정합니다. 권한 부여자에 따라 여러 리소스에 대한 액세스를 제어해야 할 수 있습니다. 와일드카드(`*`)를 사용하여 리소스 유형(메서드)를 지정할 수 있습니다. API 호출에 대한 유효한 정책을 설정하는 방법은 [API Gateway에서 API 실행을 위한 IAM 정책의 설명 참조](api-gateway-control-access-using-iam-policies-to-invoke-api.md#api-gateway-calling-api-permissions) 단원을 참조하세요. 권한 부여가 활성화된 메서드 ARN의 경우(예: `arn:aws:execute-api:{regionId}:{accountId}:{apiId}/{stage}/{httpVerb}/[{resource}/[{child-resources}]]`) 최대 길이는 1,600바이트입니다. 경로 파라미터 값은 실행 시간에 값 크기가 결정되기 때문에 ARN 길이가 한도를 초과하게 될 가능성이 있습니다. 이런 일이 발생하면 API 클라이언트는 `414 Request URI too long` 응답을 받습니다. 뿐만 아니라 권한 부여자의 정책 설명 출력 내용과 마찬가지로 리소스 ARN은 현재 512자로 제한되어 있습니다. 이런 이유 때문에 요청 URI에서는 길이가 상당히 긴 JWT 토큰이 있는 URI를 사용해서는 안 됩니다. 그 대신에 요청 헤더에서 JWT 토큰을 안전하게 전달할 수도 있습니다. `principalId` 변수를 사용하여 매핑 템플릿에서 `$context.authorizer.principalId` 값에 액세스할 수 있습니다. 이 기능은 값을 백엔드에 전달하려는 경우에 유용합니다. 자세한 내용은 [데이터 변환용 컨텍스트 변수](api-gateway-mapping-template-reference.md#context-variable-reference) 단원을 참조하세요. 각각 `stringKey`, `numberKey` 또는 `booleanKey`를 호출하여 매핑 템플릿에서 `"value"` 맵의 `"1"`, `"true"` 또는 `context` 값(예: `$context.authorizer.stringKey`, `$context.authorizer.numberKey` 또는 `$context.authorizer.booleanKey`)에 액세스할 수 있습니다. 반환되는 값은 모두 문자열화됩니다. JSON 객체 또는 어레이를 `context` 맵의 유효한 키 값으로 설정할 수 없습니다. `context` 맵을 사용하면 통합 요청 매핑 템플릿을 사용해 캐시된 자격 증명을 권한 부여자에서 백엔드로 반환할 수 있습니다. 그러면 캐시된 자격 증명을 사용해 모든 요청에 대해 보안 키에 액세스하고 권한 부여 토큰을 열 필요를 줄일 수 있으므로 백엔드가 개선된 사용자 경험을 제공할 수 있습니다. Lambda 프록시 통합의 경우 API Gateway가 `context` 객체를 입력 `event`의 일부로 Lambda 권한 부여자에서 백엔드 Lambda 함수로 직접 전달합니다. `context`를 호출하여 Lambda 함수에서 `$event.requestContext.authorizer.key` 키-값 페어를 검색할 수 있습니다. `{api-key}`는 API 단계의 사용량 계획에서 API 키를 뜻합니다. 자세한 내용은 [API Gateway의 REST API 사용량 계획 및 API 키](api-gateway-api-usage-plans.md) 단원을 참조하세요. 다음 예제는 Lambda 권한 부여자의 출력을 보여줍니다. 예제 출력에는 AWS 계정(`123456789012`)의 API(`ymy8tbxw7b`) `dev` 스테이지에 대해 `GET` 메서드에 대한 호출을 차단(`Deny`)하는 정책 설명이 포함되어 있습니다. ------ #### [ JSON ] **** ``` { "principalId": "user", "policyDocument": { "Version":"2012-10-17", "Statement": [ { "Action": "execute-api:Invoke", "Effect": "Deny", "Resource": "arn:aws:execute-api:us-west-2:123456789012:ymy8tbxw7b/dev/GET/" } ] } } ``` ------ # API Gateway Lambda 권한 부여자를 사용한 API 직접 호출 Lambda 권한 부여자(이전에는 사용자 지정 권한 부여자라고 함)를 구성하고 API를 배포했으면 Lambda 권한 부여자가 활성화된 상태에서 API를 테스트해야 합니다. 이를 위해서는 REST 클라이언트(예: cURL 또는 [Postman](https://www.postman.com/))가 필요합니다. 다음 예제에서는 Postman을 사용합니다. **참고** 권한 부여자 사용 메서드를 호출할 때 지정된 **토큰 확인 표현식**에 필요한 `TOKEN` 권한 부여자가 설정되어 있지 않거나 null이거나 무효화된 경우 API Gateway에서는 CloudWatch에 대한 호출을 기록하지 않습니다. 마찬가지로 API Gateway는 `REQUEST` 권한 부여자에 필요한 자격 증명 원본이 하나라도 설정되지 않았거나, null이거나, 비어 있을 경우 CloudWatch에 대한 호출을 기록하지 않습니다. 다음에서는 Postman을 사용하여 Lambda `TOKEN` 권한 부여자로 API를 호출하거나 테스트하는 방법을 보여줍니다. 이 방법은 필요한 경로, 헤더 또는 쿼리 문자열 파라미터를 명시적으로 지정할 경우 Lambda `REQUEST` 권한 부여자를 사용해 API를 호출하는 데 적용할 수 있습니다. **사용자 지정 `TOKEN` 권한 부여자를 사용해 API를 호출하려면** 1. **Postman**을 열고 **GET** 메서드를 선택한 후 API의 **Invoke URL(URL 호출)**을 인접한 URL 필드에 붙여 넣습니다. Lambda 권한 부여 토큰 헤더를 추가하고 값을 `allow`로 설정합니다. **Send(전송)**를 선택합니다. ![\[Lambda 권한 부여 허용 토큰을 사용하여 API 호출\]](http://docs.aws.amazon.com/ko_kr/apigateway/latest/developerguide/images/custom-auth-call-api-with-allow-token.png) 응답을 보면, API Gateway Lambda 권한 부여자가 **200 OK** 응답을 반환하고, 메서드와 통합된 HTTP 엔드포인트(http://httpbin.org/get)에 액세스할 수 있는 호출 권한을 부여함을 알 수 있습니다. 1. Postman에 머물면서 Lambda 권한 부여 토큰 헤더 값을 `deny`로 변경합니다. **Send(전송)**를 선택합니다. ![\[Lambda 권한 부여 거부 토큰을 사용하여 API 호출\]](http://docs.aws.amazon.com/ko_kr/apigateway/latest/developerguide/images/custom-auth-call-api-with-deny-token.png) 응답을 보면, API Gateway Lambda 권한 부여자가 **403 Forbidden** 응답을 반환하고, HTTP 엔드포인트에 액세스할 수 있는 호출 권한을 부여하지 않음을 알 수 있습니다. 1. Postman에서 Lambda 권한 부여 토큰 헤더 값을 `unauthorized`로 변경하고 **전송**을 선택합니다. ![\[Lambda 권한 부여 권한 없음 토큰을 사용하여 API 호출\]](http://docs.aws.amazon.com/ko_kr/apigateway/latest/developerguide/images/custom-auth-call-api-with-unauthorized-token.png) 응답을 보면, API Gateway가 **401 Unauthorized** 응답을 반환하고, HTTP 엔드포인트에 액세스할 수 있는 호출 권한을 부여하지 않음을 알 수 있습니다. 1. 이제 Lambda 권한 부여 토큰 헤더 값을 `fail`로 변경합니다. **Send(전송)**를 선택합니다. ![\[Lambda 권한 부여 실패 토큰을 사용하여 API 호출\]](http://docs.aws.amazon.com/ko_kr/apigateway/latest/developerguide/images/custom-auth-call-api-with-fail-token.png) 응답을 보면, API Gateway가 **500 Internal Server Error** 응답을 반환하고, HTTP 엔드포인트에 액세스할 수 있는 호출 권한을 부여하지 않음을 알 수 있습니다. # 교차 계정 API Gateway Lambda 권한 부여자 구성 이제는 다른 AWS Lambda 계정의 AWS 함수도 API 권한 부여자 함수로 사용할 수 있습니다. 각 계정은 Amazon API Gateway를 사용할 수 있는 모든 리전에 존재할 수 있습니다. Lambda 권한 부여자 함수는 OAuth 또는 SAML 같은 보유자 토큰 인증 전략을 사용할 수 있습니다. 따라서 여러 API Gateway API에 대해 Lambda 권한 부여자 함수를 중앙에서 손쉽게 관리 및 공유할 수 있습니다. 이 단원에서는 Amazon API Gateway 콘솔을 사용하여 교차 계정 Lambda 권한 부여자 함수를 구성하는 방법을 보여줍니다. 이 지침에서는 한 AWS 계정에서 API Gateway API를, 다른 계정에서는 Lambda 권한 부여자 함수를 이미 생성했다고 가정합니다. ## API Gateway 콘솔을 사용하여 교차 계정 Lambda 권한 부여자 구성 API를 포함하고 있는 계정에서 Amazon API Gateway 콘솔에 로그인하고 다음을 수행합니다. 1. API를 선택하고 기본 탐색 창에서 **권한 부여자**를 선택합니다. 1. **권한 부여자 생성**을 선택합니다. 1. **권한 부여자 이름**에 권한 부여자의 이름을 입력합니다. 1. **권한 부여자 유형**으로 **Lambda**를 선택합니다. 1. **Lambda 함수**에서 두 번째 계정에서 생성한 Lambda 권한 부여자 함수의 정식 ARN을 입력합니다. **참고** Lambda 콘솔 창의 오른쪽 위 모서리에서 함수의 ARN을 찾을 수 있습니다. 1. `aws lambda add-permission` 명령 문자열과 함께 경고가 표시됩니다. 이 정책은 권한 부여자 Lambda 함수를 호출할 API Gateway 권한을 부여합니다. 나중에 사용하기 위해 명령을 복사하여 저장합니다. 권한 부여자를 생성한 후 명령을 실행합니다. 1. **Lambda 이벤트 페이로드**에서 `TOKEN` 권한 부여자는 **토큰**을, `REQUEST` 권한 부여자는 **요청**을 선택합니다. 1. 이전 단계에서의 선택에 따라 다음 중 하나를 수행합니다. 1. **토큰** 옵션의 경우 다음을 수행합니다. + **토큰 소스**에 인증 토큰이 포함된 헤더 이름을 입력합니다. API 클라이언트는 권한 부여 토큰을 Lambda 권한 부여자에게 전송하려면 이 이름의 헤더를 포함해야 합니다. + 선택적으로 **토큰 검증**에 정규 표현식 문을 입력합니다. API Gateway는 이 표현식에 대해 입력 토큰의 초기 확인을 수행하고 확인이 성공할 경우 권한 부여자를 호출합니다. 이렇게 하면 API 호출을 줄일 수 있습니다. + 권한 부여자에 의해 생성된 권한 부여 정책을 캐싱하려면 **권한 부여 캐싱**을 설정해 둡니다. 정책 캐싱을 활성화한 경우 **TTL** 값을 수정할 수 있습니다. **TTL**을 0으로 설정하면 정책 캐싱이 비활성화됩니다. 정책 캐싱을 비활성화한 경우 **토큰 소스**에 지정된 헤더 이름이 캐시 키가 됩니다. 요청에서 이 헤더에 여러 값이 전달되면 모든 값이 순서가 유지된 상태로 캐시 키가 됩니다. **참고** 기본 **TTL** 값은 300초입니다. 최대 TTL 값은 3600초이며, 이 제한은 늘릴 수 없습니다. 1. **요청** 옵션의 경우 다음을 수행합니다. + **자격 증명 소스 유형**에서 파리미터 유형을 선택합니다. 지원되는 파라미터 유형은 `Header`, `Query string`, `Stage variable` 및 `Context`입니다. 자격 증명 소스를 더 추가하려면 **파라미터 추가**를 선택합니다. + 권한 부여자에 의해 생성된 권한 부여 정책을 캐싱하려면 **권한 부여 캐싱**을 설정해 둡니다. 정책 캐싱을 활성화한 경우 **TTL** 값을 수정할 수 있습니다. **TTL**을 0으로 설정하면 정책 캐싱이 비활성화됩니다. API Gateway는 지정된 자격 증명 원본을 요청 권한 부여자 캐싱 키로 사용합니다. 캐싱을 활성화한 경우 API Gateway가 런타임 시 모든 지정된 자격 증명 원본이 존재하는 것을 성공적으로 확인한 경우에만 권한 부여자의 Lambda 함수를 호출합니다. 지정된 자격 증명 원본이 없거나, Null이거나, 비어 있을 경우 API Gateway가 권한 부여자 Lambda 함수를 직접적으로 호출하지 않고 `401 Unauthorized` 응답을 반환합니다. 여러 개의 자격 증명 소스가 정의된 경우, 이들은 모두 권한 부여자의 캐시 키를 도출하는 데 사용됩니다. 캐시 키 부분을 변경하면 권한 부여자가 캐시된 정책 문서를 폐기하고 새로 생성합니다. 요청에서 여러 값이 있는 헤더가 전달되면 모든 값이 순서가 유지된 상태로 캐시 키의 일부가 됩니다. + 캐싱을 비활성화한 경우 자격 증명 소스를 지정할 필요가 없습니다. **참고** 캐싱을 활성화하려면 권한 부여자가 API 전체의 모든 메서드에 적용 가능한 정책을 반환해야 합니다. 메서드별 정책을 적용하려는 경우 **권한 부여자 캐싱**을 해제할 수 있습니다. 1. **권한 부여자 생성**을 선택합니다. 1. 이전 단계에서 복사한 `aws lambda add-permission` 명령 문자열을 두 번째 계정에 대해 구성된 AWS CLI 창에 붙여 넣습니다. `AUTHORIZER_ID`를 권한 부여자의 ID로 바꿉니다. 이렇게 하면 첫 번째 계정이 두 번째 계정의 Lambda 권한 부여자 함수에 액세스할 수 있는 권한이 부여됩니다. # Verified Permissions를 사용하여 자격 증명의 속성을 기반으로 액세스 제어 Amazon Verified Permissions를 사용하여 API Gateway API에 대한 액세스를 제어합니다. Verified Permissions와 함께 API Gateway를 사용하는 경우 Verified Permissions가 세분화된 권한 부여 결정을 사용하여 API에 대한 액세스를 제어하는 Lambda 권한 부여자를 생성합니다. Verified Permissions는 Cedar 정책 언어를 사용해 애플리케이션 사용자에 대한 세분화된 권한을 정의하여 정책 스토어 스키마 및 정책을 기반으로 호출자에게 권한을 부여합니다. 자세한 내용은 *Amazon Verified Permissions 사용 설명서*의 [연결된 API 및 ID 공급자를 사용하여 정책 저장소 생성](https://docs.aws.amazon.com/verifiedpermissions/latest/userguide/getting-started-api-policy-store.html)을 참조합니다. Verified Permissions는 자격 증명 소스로서 Amazon Cognto 사용자 풀 또는 OpenID Connect(OIDC) ID 제공업체를 지원합니다. Verified Permissions는 보안 주체가 이전에 식별되고 인증된 것으로 가정합니다. Verified Permissions는 리전 및 엣지 최적화 REST API에만 지원됩니다. ## Verified Permissions를 사용하여 Lambda 권한 부여자 생성 Verified Permissions는 Lambda 권한 부여자를 생성하여 보안 주체가 API에서 작업을 수행할 수 있는지 여부를 결정합니다. Verified Permissions가 권한 부여 작업을 수행하는 데 사용할 Cedar 정책을 생성합니다. 다음은 API의 `GET /users` 리소스에 있는 `developer` 그룹에 대해 Amazon Cognito 사용자 풀 `us-east-1_ABC1234`를 기반으로 API를 간접적으로 호출할 수 있도록 액세스를 허용하는 Cedar 정책의 예시입니다. Verified Permissions는 발신자 ID에 대한 보유자 토큰을 구문 분석하여 그룹 멤버십을 결정합니다. ``` permit( principal in MyAPI::UserGroup::"us-east-1_ABC1234|developer", action in [ MyAPI::Action::"get /users" ], resource ); ``` 선택적으로 Verified Permissions에서 API의 메서드에 권한 부여자를 연결할 수 있습니다. API의 프로덕션 스테이지에서는 Verified Permissions의 권한 부여자 연결을 허용하지 않는 것이 좋습니다. 다음 목록은 Lambda 권한 부여자를 API 메서드의 메서드 요청에 연결하거나 연결하지 않도록 Verified Permissions를 구성하는 방법을 보여줍니다. **권한 부여자 연결(AWS Management Console)** Verified Permissions 콘솔에서 **정책 스토어 생성**을 선택할 때 **앱 통합 배포** 페이지에서 **지금**을 선택합니다. **권한 부여자 연결 안 함(AWS Management Console)** Verified Permissions 콘솔에서 **정책 스토어 생성**을 선택할 때 **앱 통합 배포** 페이지에서 **나중에**를 선택합니다. Verified Permissions는 여전히 Lambda 권한 부여자를 생성합니다. Lambda 권한 부여자는 `AVPAuthorizerLambda-`로 시작합니다. 메서드에 권한 부여자를 연결하는 방법에 대한 자세한 지침은 [Lambda 권한 부여자를 사용하도록 메서드 구성(콘솔)](configure-api-gateway-lambda-authorization.md#configure-api-gateway-lambda-authorization-method-console) 섹션을 참조하세요. **권한 부여자 연결(CloudFormation)** Verified Permissions에서 생성된 CloudFormation 템플릿의 `Conditions` 섹션에서 `"Ref": "shouldAttachAuthorizer"`를 `true`로 설정합니다. **권한 부여자 연결 안 함(CloudFormation)** Verified Permissions에서 생성된 CloudFormation 템플릿의 `Conditions` 섹션에서 `"Ref": "shouldAttachAuthorizer"`를 `false`로 설정합니다. Verified Permissions는 여전히 Lambda 권한 부여자를 생성합니다. Lambda 권한 부여자는 `AVPAuthorizerLambda-`로 시작합니다. 메서드에 권한 부여자를 연결하는 방법에 대한 자세한 지침은 [Lambda 권한 부여자를 사용하도록 메서드 구성(AWS CLI)](configure-api-gateway-lambda-authorization.md#configure-api-gateway-lambda-authorization-method-cli) 섹션을 참조하세요. ## Verified Permissions를 사용하여 Lambda 권한 부여자 직접 호출 `Authorization` 헤더에 자격 증명 또는 액세스 토큰을 제공하여 Lambda 권한 부여자를 직접적으로 호출할 수 있습니다. 자세한 내용은 [API Gateway Lambda 권한 부여자를 사용한 API 직접 호출](call-api-with-api-gateway-lambda-authorization.md) 섹션을 참조하세요. API Gateway는 Lambda 권한 부여자가 반환하는 정책을 120초 동안 캐싱합니다. API Gateway 콘솔에서 또는 AWS CLI를 사용하여 TTL을 수정할 수 있습니다. # Amazon Cognito 사용자 풀을 권한 부여자로 사용하여 REST API에 대한 액세스 제어 [IAM 역할 및 정책](permissions.md) 또는 [Lambda 권한 부여자](apigateway-use-lambda-authorizer.md)(이전에는 사용자 지정 권한 부여자라고 함)를 사용하는 것 말고도 [Amazon Cognito 사용자 풀](https://docs.aws.amazon.com/cognito/latest/developerguide/cognito-user-identity-pools.html)을 사용하여 Amazon API Gateway에서 API에 액세스할 수 있는 사람을 제어할 수도 있습니다. API에 Amazon Cognito 사용자 풀을 사용하려면 먼저 `COGNITO_USER_POOLS` 유형의 권한 부여자를 생성한 다음 해당 권한 부여자를 사용하도록 API 메서드를 구성해야 합니다. API가 배포된 후 클라이언트는 먼저 사용자 풀에 사용자를 로그인하고, 해당 사용자의 [자격 증명 또는 액세스 토큰](https://docs.aws.amazon.com/cognito/latest/developerguide/amazon-cognito-user-pools-using-tokens-with-identity-providers.html)을 획득한 다음 일반적으로 요청의 `Authorization` 헤더로 설정되는 토큰 1개를 사용하여 API 메서드를 호출해야 합니다. API 호출은 필요한 토큰이 제공되고 제공된 토큰이 유효한 경우에만 성공하며, 그렇지 않으면 권한이 부여될 수 있는 자격 증명이 클라이언트에게 없기 때문에 호출할 권한이 클라이언트에게 부여되지 않습니다. 자격 증명 토큰은 로그인한 사용자의 자격 증명 클레임을 기반으로 API 호출 권한을 부여하는 데 사용됩니다. 액세스 토큰은 지정된 액세스 보호 리소스의 사용자 지정 범위를 기반으로 API 호출 권한을 부여하는 데 사용됩니다. 자세한 내용은 [사용자 풀에 토큰 사용](https://docs.aws.amazon.com/cognito/latest/developerguide/amazon-cognito-user-pools-using-tokens-with-identity-providers.html)과 [리소스 서버 및 사용자 지정 범위](https://docs.aws.amazon.com/cognito/latest/developerguide/cognito-user-pools-define-resource-servers.html)를 참조하세요. API를 위한 Amazon Cognito 사용자 풀을 생성하고 구성하려면 다음 작업을 수행하세요. + Amazon Cognito 콘솔, CLI/SDK 또는 API를 사용하여 사용자 풀을 생성하거나 다른 AWS 계정이 소유한 사용자 풀을 사용합니다. + API Gateway 콘솔, CLI/SDK 또는 API를 사용하여 선택한 사용자 풀이 포함된 API Gateway 권한 부여자를 생성합니다. + 선택한 API 메서드에서 API Gateway 콘솔, CLI/SDK 또는 API를 사용하여 권한 부여자를 활성화합니다. 사용자 풀이 활성화된 상태에서 API 메서드를 호출하기 위해 API 클라이언트는 다음 작업을 수행합니다. + Amazon Cognito CLI/SDK 또는 API를 사용하여 선택한 사용자 풀에 사용자를 로그인하고 자격 증명 토큰 또는 액세스 토큰을 획득합니다. SDK 사용에 대한 자세히 내용은 [AWS SDK를 사용한 Amazon Cognito 코드 예시](https://docs.aws.amazon.com/cognito/latest/developerguide/service_code_examples.html)를 참조하세요. + 클라이언트별 프레임워크를 사용하여 배포된 API Gateway API를 호출하고 `Authorization` 헤더에서 적절한 토큰을 제공합니다. API 개발자는 클라이언트 개발자에게 사용자 풀 ID와 클라이언트 ID 및 가능한 경우, 사용자 풀의 일부로 정의되는 연결된 클라이언트 비밀번호를 제공해야 합니다. **참고** 사용자가 Amazon Cognito 자격 증명을 사용하여 로그인하고 IAM 역할 권한과 함께 사용할 임시 자격 증명도 획득하게 하려면 [Amazon Cognito 연동 ID](https://docs.aws.amazon.com/cognito/latest/developerguide/cognito-identity.html)를 사용합니다. 각 API 리소스 엔드포인트 HTTP 메서드에 대해 권한 부여 유형을 설정하고 `Method Execution` 범주를 `AWS_IAM`으로 설정합니다. 이 단원에서는 사용자 풀을 생성하고, API Gateway API를 사용자 풀과 통합하고, 사용자 풀에 통합된 API를 호출하는 방법을 설명합니다. **Topics** + [REST API에 대한 Amazon Cognito 사용자 풀 생성](apigateway-create-cognito-user-pool.md) + [REST API와 Amazon Cognito 사용자 풀 통합](apigateway-enable-cognito-user-pool.md) + [Amazon Cognito 사용자 풀과 통합된 REST API 호출](apigateway-invoke-api-integrated-with-cognito-user-pool.md) + [API Gateway 콘솔을 사용하여 REST API를 위한 교차 계정 Amazon Cognito 권한 부여자 구성](apigateway-cross-account-cognito-authorizer.md) + [CloudFormation을 사용하여 REST API를 위한 Amazon Cognito 권한 부여자 생성](apigateway-cognito-authorizer-cfn.md) # REST API에 대한 Amazon Cognito 사용자 풀 생성 API를 사용자 풀과 통합하기 전에 Amazon Cognito에서 사용자 풀을 생성해야 합니다. 사용자 풀 구성은 [Amazon Cognito의 모든 리소스 할당량](https://docs.aws.amazon.com/cognito/latest/developerguide/limits.html)을 준수해야 합니다. 그룹, 사용자 및 역할과 같은 모든 사용자 정의 Amazon Cognito 변수가 영숫자 문자만 사용해야 합니다. 사용자 풀을 생성하는 방법에 대한 지침은 *Amazon Cognito 개발자 가이드*에서 [자습서: 사용자 풀 생성](https://docs.aws.amazon.com/cognito/latest/developerguide/tutorial-create-user-pool.html)을 참조하세요. 사용자 풀 ID, 클라이언트 ID 및 모든 클라이언트 비밀번호를 적어 둡니다. 사용자가 사용자 풀에 등록하고, 사용자 풀에 로그인하고, 사용자 풀에 구성된 API 메서드를 호출하기 위해 요청에 포함할 자격 증명 또는 액세스 토큰을 획득하려면 클라이언트가 Amazon Cognito에 이러한 ID 및 클라이언트 비밀번호를 제공해야 합니다. 또한 다음에 설명한 대로 사용자 풀을 API Gateway에서 권한 부여자로 구성할 경우 사용자 풀 이름을 지정해야 합니다. 액세스 토큰을 사용하여 API 메서드 호출 권한을 부여하는 경우, 사용자 풀과의 앱 통합을 구성하여 지정된 리소스 서버에서 원하는 사용자 지정 범위를 설정해야 합니다. Amazon Cognito 사용자 풀을 통해 토큰 사용에 대한 자세한 내용은 [사용자 풀을 통해 토큰 사용](https://docs.aws.amazon.com/cognito/latest/developerguide/amazon-cognito-user-pools-using-tokens-with-identity-providers.html)을 참조하세요. 리소스 서버에 대한 자세한 내용은 [사용자 풀의 리소스 서버 정의](https://docs.aws.amazon.com/cognito/latest/developerguide/cognito-user-pools-define-resource-servers.html)를 참조하세요. 구성된 리소스 서버 식별자와 사용자 지정 범위 이름을 적어 둡니다. 이 정보는 `COGNITO_USER_POOLS` 권한 부여자가 사용하는 **OAuth Scopes(OAuth 범위)**의 액세스 범위 전체 이름을 생성하는 데 필요합니다. ![\[Amazon Cognito 사용자 풀 리소스 서버 및 범위\]](http://docs.aws.amazon.com/ko_kr/apigateway/latest/developerguide/images/cognito-user-pool-custom-scopes-new-console.png) # REST API와 Amazon Cognito 사용자 풀 통합 API Gateway에서 Amazon Cognito 사용자 풀을 생성한 다음 이 사용자 풀을 사용하는 `COGNITO_USER_POOLS` 권한 부여자를 생성해야 합니다. 다음 절차에서는 API Gateway 콘솔에서 이 작업을 수행하는 방법을 보여줍니다. **참고** [https://docs.aws.amazon.com/apigateway/latest/api/API_CreateAuthorizer.html](https://docs.aws.amazon.com/apigateway/latest/api/API_CreateAuthorizer.html) 작업을 통해 여러 사용자 풀을 사용하는 `COGNITO_USER_POOLS` 권한 부여자를 생성할 수 있습니다. `COGNITO_USER_POOLS` 권한 부여자 한 명에 최대 1,000개의 사용자 풀을 사용할 수 있습니다. 이 한도는 늘릴 수 없습니다. **중요** 아래 절차를 수행한 후 변경 사항을 전파하기 위해 API를 배포 또는 재배포할 필요가 있습니다. API 배포에 대한 자세한 내용은 [API Gateway에서 REST API 배포](how-to-deploy-api.md) 단원을 참조하세요. **API Gateway 콘솔을 사용하여 `COGNITO_USER_POOLS` 권한 부여자를 생성하려면** 1. API Gateway에서 새 API를 생성하거나 기존 API를 선택합니다. 1. 기본 탐색 창에서 **권한 부여자**를 선택합니다. 1. **권한 부여자 생성**을 선택합니다. 1. 사용자 풀을 사용하도록 새 권한 부여자를 구성하려면 다음을 수행합니다. 1. **권한 부여자 이름**에 이름을 입력합니다. 1. **권한 부여자 유형**으로 **Cognito**를 선택합니다. 1. **Cognito 사용자 풀**의 경우 Amazon Cognito를 생성한 AWS 리전을 선택하고 사용 가능한 사용자 풀을 선택합니다. 스테이지 변수를 사용하여 사용자 풀을 정의할 수 있습니다. 사용자 풀에는 다음 형식을 사용합니다. `arn:aws:cognito-idp:us-east-2:111122223333:userpool/${stageVariables.MyUserPool}` 1. **토큰 소스**에 헤더 이름으로 **Authorization**을 입력하여 사용자가 성공적으로 로그인할 때 Amazon Cognito에서 반환하는 자격 증명 또는 액세스 토큰을 전달합니다. 1. (선택 사항) **토큰 검증** 필드에 정규식을 입력하여 Amazon Cognito를 통해 요청에 대한 권한이 부여되기 전에 자격 증명 토큰의 `aud`(대상) 필드를 검증합니다. 액세스 토큰을 사용할 경우, 액세스 토큰에 `aud` 필드가 포함되지 않으므로 이 유효성 검사는 요청을 거부합니다. 1. **권한 부여자 생성**을 선택합니다. 1. `COGNITO_USER_POOLS` 권한 부여자를 만든 후 사용자 풀에서 프로비저닝한 ID 토큰을 제공하여 간접 호출을 테스트할 수 있습니다. 액세스 토큰을 사용하여 권한 부여자 간접 호출을 테스트할 수 없습니다. [Amazon Cognito 자격 증명 SDK](https://docs.aws.amazon.com/cognito/latest/developerguide/cognito-integrate-apps.html)를 호출하여 사용자 로그인을 수행함으로써 이 자격 증명 토큰을 얻을 수 있습니다. [https://docs.aws.amazon.com/cognito-user-identity-pools/latest/APIReference/API_InitiateAuth.html](https://docs.aws.amazon.com/cognito-user-identity-pools/latest/APIReference/API_InitiateAuth.html) 작업을 사용해도 됩니다. **권한 부여 범위**를 구성하지 않으면 API Gateway는 제공된 토큰을 자격 증명 토큰으로 취급합니다. 이전 절차에서는 새로 생성된 Amazon Cognito 사용자 풀을 사용하는 `COGNITO_USER_POOLS` 권한 부여자를 생성합니다. API 메서드에서 권한 부여자를 활성화하는 방법에 따라 통합된 사용자 풀에서 프로비저닝되는 자격 증명 토큰 또는 액세스 토큰을 사용할 수 있습니다. **메서드에서 `COGNITO_USER_POOLS` 권한 부여자를 구성하려면** 1. **리소스**를 선택합니다. 새 메서드를 선택하거나 기존 메서드를 선택합니다. 필요하다면 리소스를 생성합니다. 1. **메서드 요청** 탭의 **메서드 요청 설정**에서 **편집**을 선택합니다. 1. **권한 부여자**의 경우 드롭다운 메뉴에서 방금 생성한 **Amazon Cognito 사용자 풀 권한 부여자**를 선택합니다. 1. 자격 증명 토큰을 사용하려면 다음 작업을 수행하세요. 1. **권한 부여 범위**를 비워둡니다. 1. 필요에 따라 **통합 요청**에서 본문 매핑 템플릿에 `$context.authorizer.claims['property-name']` 또는 `$context.authorizer.claims.property-name` 표현식을 추가하여, 사용자 풀에서 백엔드로 지정된 자격 증명 클레임 속성을 전달합니다. `sub` 또는 `custom-sub`처럼 단순한 속성 이름의 경우, 두 표기법이 동일합니다. `custom:role`처럼 복잡한 속성 이름의 경우, 점 표기법을 사용할 수 없습니다. 예를 들어 다음 매핑 표현식은 클레임의 [표준 필드](https://openid.net/specs/openid-connect-core-1_0.html#StandardClaims)인 `sub` 및 `email`를 백엔드로 전달합니다. ``` { "context" : { "sub" : "$context.authorizer.claims.sub", "email" : "$context.authorizer.claims.email" } } ``` 사용자 풀을 구성할 때 사용자 지정 클레임 필드를 선언했다면 동일한 패턴에 따라 사용자 지정 필드에 액세스할 수 있습니다. 다음 예에서는 클레임의 사용자 지정 `role` 필드를 가져옵니다. ``` { "context" : { "role" : "$context.authorizer.claims.role" } } ``` 사용자 지정 클레임 필드가 `custom:role`로 선언되면 다음 예를 사용하여 클레임의 속성을 가져옵니다. ``` { "context" : { "role" : "$context.authorizer.claims['custom:role']" } } ``` 1. 액세스 토큰을 사용하려면 다음 작업을 수행하세요. 1. **권한 부여 범위**에 Amazon Cognito 사용자 풀이 생성되었을 때 구성된 범위의 전체 이름을 하나 이상 입력합니다. 예를 들어 [REST API에 대한 Amazon Cognito 사용자 풀 생성](apigateway-create-cognito-user-pool.md)에서 제시된 예를 따르면, 스코프 중 하나는 `https://my-petstore-api.example.com/cats.read`입니다. 런타임 시 이 단계의 메서드에서 지정되는 범위가 수신되는 토큰에서 클레임되는 범위와 일치하면 메서드 호출이 성공합니다. 그렇지 않으면 호출은 `401 Unauthorized` 응답과 함께 실패합니다. 1. **저장**을 선택합니다. 1. 선택한 다른 메서드에 대해 이러한 단계를 반복합니다. `COGNITO_USER_POOLS` 권한 부여자의 경우, **OAuth Scopes** 옵션이 지정되지 않으면 API Gateway는 제공된 토큰을 자격 증명 토큰으로 취급하고 클레임된 자격 증명을 사용자 풀의 자격 증명과 대조하여 확인합니다. 그렇지 않으면 API Gateway는 제공된 토큰을 액세스 토큰으로 취급하고 토큰에서 클레임된 액세스 범위를 메서드에서 선언된 권한 부여 범위와 대조하여 확인합니다. API Gateway 콘솔을 사용하는 대신 OpenAPI 정의 파일을 지정하고 API 정의를 API Gateway로 가져와 메서드에서 Amazon Cognito 사용자 풀을 활성화할 수도 있습니다. **OpenAPI 정의 파일을 사용하여 COGNITO\$1USER\$1POOLS 권한 부여자를 가져오려면** 1. API에 OpenAPI 정의 파일을 생성(또는 내보내기)합니다. 1. `COGNITO_USER_POOLS` 권한 부여자(`MyUserPool`) JSON 정의를 다음과 같이 OpenAPI 3.0의 `securitySchemes` 섹션 또는 Open API 2.0의 `securityDefinitions` 섹션의 일부로 지정합니다. ------ #### [ OpenAPI 3.0 ] ``` "securitySchemes": { "MyUserPool": { "type": "apiKey", "name": "Authorization", "in": "header", "x-amazon-apigateway-authtype": "cognito_user_pools", "x-amazon-apigateway-authorizer": { "type": "cognito_user_pools", "providerARNs": [ "arn:aws:cognito-idp:{region}:{account_id}:userpool/{user_pool_id}" ] } } ``` ------ #### [ OpenAPI 2.0 ] ``` "securityDefinitions": { "MyUserPool": { "type": "apiKey", "name": "Authorization", "in": "header", "x-amazon-apigateway-authtype": "cognito_user_pools", "x-amazon-apigateway-authorizer": { "type": "cognito_user_pools", "providerARNs": [ "arn:aws:cognito-idp:{region}:{account_id}:userpool/{user_pool_id}" ] } } ``` ------ 1. 메서드 권한 부여에 자격 증명 토큰을 사용하려면 루트 리소스에서 다음 GET 메서드에 나온 것처럼 `{ "MyUserPool": [] }`을 메서드의 `security` 정의에 추가합니다. ``` "paths": { "/": { "get": { "consumes": [ "application/json" ], "produces": [ "text/html" ], "responses": { "200": { "description": "200 response", "headers": { "Content-Type": { "type": "string" } } } }, "security": [ { "MyUserPool": [] } ], "x-amazon-apigateway-integration": { "type": "mock", "responses": { "default": { "statusCode": "200", "responseParameters": { "method.response.header.Content-Type": "'text/html'" }, } }, "requestTemplates": { "application/json": "{\"statusCode\": 200}" }, "passthroughBehavior": "when_no_match" } }, ... } ``` 1. 메서드 권한 부여에 액세스 토큰을 사용하려면 위의 보안 정의를 `{ "MyUserPool": [resource-server/scope, ...] }`로 변경합니다. ``` "paths": { "/": { "get": { "consumes": [ "application/json" ], "produces": [ "text/html" ], "responses": { "200": { "description": "200 response", "headers": { "Content-Type": { "type": "string" } } } }, "security": [ { "MyUserPool": ["https://my-petstore-api.example.com/cats.read", "http://my.resource.com/file.read"] } ], "x-amazon-apigateway-integration": { "type": "mock", "responses": { "default": { "statusCode": "200", "responseParameters": { "method.response.header.Content-Type": "'text/html'" }, } }, "requestTemplates": { "application/json": "{\"statusCode\": 200}" }, "passthroughBehavior": "when_no_match" } }, ... } ``` 1. 필요에 따라 적절한 OpenAPI 정의 또는 확장자를 사용해 다른 API 구성을 설정할 수 있습니다. 자세한 내용은 [API Gateway용 OpenAPI 확장 프로그램](api-gateway-swagger-extensions.md) 단원을 참조하세요. # Amazon Cognito 사용자 풀과 통합된 REST API 호출 사용자 풀 권한 부여자를 구성한 상태로 메서드를 호출하려면 클라이언트에서 다음을 수행해야 합니다. + 사용자가 사용자 풀을 사용하여 로그인하도록 설정합니다. + 사용자가 사용자 풀에 로그인하도록 설정합니다. + 사용자 풀에서 로그인한 사용자의 [자격 증명 또는 액세스 토큰](https://docs.aws.amazon.com/cognito/latest/developerguide/amazon-cognito-user-pools-using-tokens-with-identity-providers.html)을 가져옵니다. + `Authorization` 헤더(또는 권한 부여자를 생성할 때 지정한 다른 헤더)에 토큰을 포함합니다. [AWS Amplify]()를 사용하여 이러한 작업을 수행할 수 있습니다. 자세한 내용은 [Amazon Cognito와 웹 및 모바일 앱 통합](https://docs.aws.amazon.com/cognito/latest/developerguide/cognito-integrate-apps.html)을 참조하세요. + Android의 경우 [Android용 Amplify 시작하기](https://docs.amplify.aws/android/build-a-backend/auth/)를 참조하세요. + iOS를 사용하려면 [iOS용 Amplify 시작하기](https://docs.amplify.aws/swift/build-a-backend/auth/)를 참조하세요. + JavaScript를 사용하려면 [Javascript용 Amplify 시작하기](https://docs.amplify.aws/javascript/build-a-backend/auth/)를 참조하세요. # API Gateway 콘솔을 사용하여 REST API를 위한 교차 계정 Amazon Cognito 권한 부여자 구성 이제 다른 AWS 계정의 Amazon Cognito 사용자 풀도 API 권한 부여자로 사용할 수 있습니다. Amazon Cognito 사용자 풀은 OAuth 또는 SAML 같은 보유자 토큰 인증 전략을 사용할 수 있습니다. 따라서 여러 API Gateway API에 대해 Amazon Cognito 사용자 풀 권한 부여자를 중앙에서 손쉽게 관리 및 공유할 수 있습니다. 이 단원에서는 Amazon API Gateway 콘솔을 사용하여 교차 계정 Amazon Cognito 사용자 풀을 구성하는 방법을 보여줍니다. 이 지침에서는 한 AWS 계정에서 API Gateway API를, 다른 계정에서는 Amazon Cognito 사용자 풀을 이미 생성했다고 가정합니다. ## REST API를 위한 교차 계정 Amazon Cognito 권한 부여자 생성 API를 포함하고 있는 계정에서 Amazon API Gateway 콘솔에 로그인하고 다음을 수행합니다. 1. API Gateway에서 새 API를 생성하거나 기존 API를 선택합니다. 1. 기본 탐색 창에서 **권한 부여자**를 선택합니다. 1. **권한 부여자 생성**을 선택합니다. 1. 사용자 풀을 사용하도록 새 권한 부여자를 구성하려면 다음을 수행합니다. 1. **권한 부여자 이름**에 이름을 입력합니다. 1. **권한 부여자 유형**으로 **Cognito**를 선택합니다. 1. **Cognito 사용자 풀**에서는 두 번째 계정에 있는 사용자 풀의 전체 ARN을 입력합니다. **참고** Amazon Cognito 콘솔에서 **일반 설정** 창의 **풀 ARN** 필드에서 사용자 풀의 ARN을 찾을 수 있습니다. 1. **토큰 소스**에 헤더 이름으로 **Authorization**을 입력하여 사용자가 성공적으로 로그인할 때 Amazon Cognito에서 반환하는 자격 증명 또는 액세스 토큰을 전달합니다. 1. (선택 사항) **토큰 검증** 필드에 정규식을 입력하여 Amazon Cognito를 통해 요청에 대한 권한이 부여되기 전에 자격 증명 토큰의 `aud`(대상) 필드를 검증합니다. 액세스 토큰을 사용할 경우, 액세스 토큰에 `aud` 필드가 포함되지 않으므로 이 유효성 검사는 요청을 거부합니다. 1. **권한 부여자 생성**을 선택합니다. # CloudFormation을 사용하여 REST API를 위한 Amazon Cognito 권한 부여자 생성 CloudFormation을 사용하여 Amazon Cognito 사용자 풀 및 Amazon Cognito 권한 부여자를 생성합니다. 예제 CloudFormation 템플릿은 다음을 수행합니다. + Amazon Cognito 사용자 풀을 생성합니다. 클라이언트는 먼저 사용자를 사용자 풀에 로그인시키고 [자격 증명 또는 액세스 토큰](https://docs.aws.amazon.com/cognito/latest/developerguide/amazon-cognito-user-pools-using-tokens-with-identity-providers.html)을 얻어야 합니다. 액세스 토큰을 사용하여 API 메서드 호출 권한을 부여하는 경우, 사용자 풀과의 앱 통합을 구성하여 지정된 리소스 서버에서 원하는 사용자 지정 범위를 설정해야 합니다. + `GET` 메서드를 사용하여 API Gateway API를 생성합니다. + `Authorization` 헤더를 토큰 소스로 사용하는 Amazon Cognito 권한 부여자를 생성합니다. ``` AWSTemplateFormatVersion: 2010-09-09 Resources: UserPool: Type: AWS::Cognito::UserPool Properties: AccountRecoverySetting: RecoveryMechanisms: - Name: verified_phone_number Priority: 1 - Name: verified_email Priority: 2 AdminCreateUserConfig: AllowAdminCreateUserOnly: true EmailVerificationMessage: The verification code to your new account is {####} EmailVerificationSubject: Verify your new account SmsVerificationMessage: The verification code to your new account is {####} VerificationMessageTemplate: DefaultEmailOption: CONFIRM_WITH_CODE EmailMessage: The verification code to your new account is {####} EmailSubject: Verify your new account SmsMessage: The verification code to your new account is {####} UpdateReplacePolicy: Retain DeletionPolicy: Retain CogAuthorizer: Type: AWS::ApiGateway::Authorizer Properties: Name: CognitoAuthorizer RestApiId: Ref: Api Type: COGNITO_USER_POOLS IdentitySource: method.request.header.Authorization ProviderARNs: - Fn::GetAtt: - UserPool - Arn Api: Type: AWS::ApiGateway::RestApi Properties: Name: MyCogAuthApi ApiDeployment: Type: AWS::ApiGateway::Deployment Properties: RestApiId: Ref: Api DependsOn: - CogAuthorizer - ApiGET ApiDeploymentStageprod: Type: AWS::ApiGateway::Stage Properties: RestApiId: Ref: Api DeploymentId: Ref: ApiDeployment StageName: prod ApiGET: Type: AWS::ApiGateway::Method Properties: HttpMethod: GET ResourceId: Fn::GetAtt: - Api - RootResourceId RestApiId: Ref: Api AuthorizationType: COGNITO_USER_POOLS AuthorizerId: Ref: CogAuthorizer Integration: IntegrationHttpMethod: GET Type: HTTP_PROXY Uri: http://petstore-demo-endpoint.execute-api.com/petstore/pets Outputs: ApiEndpoint: Value: Fn::Join: - "" - - https:// - Ref: Api - .execute-api. - Ref: AWS::Region - "." - Ref: AWS::URLSuffix - / - Ref: ApiDeploymentStageprod - / ```