# AWS Lambda의 보안
AWS에서 클라우드 보안을 가장 중요하게 생각합니다. AWS 고객으로서 여러분은 가장 높은 보안 요구 사항을 충족하기 위해 설계된 데이터 센터 및 네트워크 아키텍처의 혜택을 받게 됩니다.
보안은 AWS과 사용자의 공동 책임입니다. [공동 책임 모델](https://aws.amazon.com/compliance/shared-responsibility-model/)은 이 사항을 클라우드 내** 보안 및 클라우드**의 보안으로 설명합니다.
+ **클라우드의 보안** - AWS는 AWS 서비스 클라우드에서 AWS를 실행하는 인프라를 보호합니다. AWS는 또한 안전하게 사용할 수 있는 서비스를 제공합니다. 서드 파티 감사원은 정기적으로 [AWS 규정 준수 프로그램](https://aws.amazon.com/compliance/programs/)의 일환으로 보안 효과를 테스트하고 검증합니다. AWS Lambda에 적용되는 규정 준수 프로그램에 대한 자세한 내용은 [규정 준수 프로그램 제공 범위 내의 AWS 서비스](https://aws.amazon.com/compliance/services-in-scope/) 내용을 참조하세요.
+ **Security in the cloud(클라우드 내 보안)** – 귀하의 책임은 귀하가 사용하는 AWS 서비스에 의해 결정됩니다. 또한 귀하는 데이터의 민감도, 회사 요구 사항, 관련 법률 및 규정을 비롯한 기타 요소에 대해서도 책임이 있습니다.
이 설명서는 Lambda 사용 시 책임 분담 모델을 적용하는 방법을 이해하는 데 도움이 됩니다. 다음 항목에서는 보안 및 규정 준수 목표를 충족하도록 Lambda를 구성하는 방법을 보여줍니다. 또한 Lambda 리소스를 모니터링하고 보호하는 데 도움이 되는 다른 AWS 서비스를 사용하는 방법도 학습합니다.
Lambda 애플리케이션에 보안 원칙을 적용하는 방법에 대한 자세한 내용은 Serverless Land의 [Security](https://serverlessland.com/content/service/lambda/guides/aws-lambda-operator-guide/security-ops)를 참조하세요.
**Topics**
+ [
# AWS Lambda의 데이터 보호
](security-dataprotection.md)
+ [
# Lambda의 서비스 연결 역할 사용
](using-service-linked-roles.md)
+ [
# AWS Lambda의 ID 및 액세스 관리
](security-iam.md)
+ [
# Lambda 함수 및 계층에 대한 거버넌스 전략 생성
](governance-concepts.md)
+ [
# AWS Lambda의 규정 준수 확인
](security-compliance.md)
+ [
# AWS Lambda의 복원성
](security-resilience.md)
+ [
# AWS Lambda의 인프라 보안
](security-infrastructure.md)
+ [
# 퍼블릭 엔드포인트를 사용하여 워크로드 보호
](security-public-endpoints.md)
+ [
# 코드 서명을 사용하여 Lambda로 코드 무결성 확인
](configuration-codesigning.md)
# AWS Lambda의 데이터 보호
AWS [공동 책임 모델](https://aws.amazon.com/compliance/shared-responsibility-model/)은 AWS Lambda의 데이터 보호에 적용됩니다. 이 모델에서 설명하는 것처럼 AWS는 모든 AWS 클라우드를 실행하는 글로벌 인프라를 보호할 책임이 있습니다. 사용자는 인프라에서 호스팅되는 콘텐츠를 관리해야 합니다. 사용하는 AWS 서비스의 보안 구성과 관리 작업에 대한 책임도 사용자에게 있습니다. 데이터 프라이버시에 대한 자세한 내용은 [데이터 프라이버시 FAQ](https://aws.amazon.com/compliance/data-privacy-faq/)를 참조하세요. 유럽의 데이터 보호에 대한 자세한 내용은 *AWS 보안 블로그*의 [AWS 공동 책임 모델 및 GDPR](https://aws.amazon.com/blogs/security/the-aws-shared-responsibility-model-and-gdpr/) 블로그 게시물을 참조하세요.
데이터를 보호하려면 AWS 계정보안 인증 정보를 보호하고 AWS IAM Identity Center또는 AWS Identity and Access Management(IAM)를 통해 개별 사용자 계정을 설정하는 것이 좋습니다. 이렇게 하면 개별 사용자에게 자신의 직무를 충실히 이행하는 데 필요한 권한만 부여됩니다. 또한 다음과 같은 방법으로 데이터를 보호하는 것이 좋습니다.
+ 각 계정에 멀티 팩터 인증 설정(MFA)을 사용하세요.
+ SSL/TLS를 사용하여 AWS 리소스와 통신하세요. TLS 1.2는 필수이며 TLS 1.3을 권장합니다.
+ AWS CloudTrail로 API 및 사용자 활동 로깅을 설정하세요. AWS 활동 캡처에 CloudTrail 추적을 사용하는 방법에 대한 자세한 내용은 *AWS CloudTrail 사용 설명서*의 [CloudTrail 추적 작업](https://docs.aws.amazon.com/awscloudtrail/latest/userguide/cloudtrail-trails.html)을 참조하세요.
+ AWS 암호화 솔루션을 AWS 서비스 내의 모든 기본 보안 컨트롤과 함께 사용하세요.
+ Amazon S3에 저장된 민감한 데이터를 검색하고 보호하는 데 도움이 되는 Amazon Macie와 같은 고급 관리형 보안 서비스를 사용하세요.
+ 명령행 인터페이스 또는 API를 통해 AWS에 액세스할 때 FIPS 140-3 검증된 암호화 모듈이 필요한 경우, FIPS 엔드포인트를 사용합니다. 사용 가능한 FIPS 엔드포인트에 대한 자세한 내용은 [Federal Information Processing Standard(FIPS) 140-3](https://aws.amazon.com/compliance/fips/)을 참조하세요.
고객의 이메일 주소와 같은 기밀 정보나 중요한 정보는 태그나 **이름** 필드와 같은 자유 양식 필드에 입력하지 않는 것이 좋습니다. 여기에는 Lambda 또는 기타 AWS 서비스에서 콘솔, API, AWS CLI 또는 AWS SDK를 사용하여 작업하는 경우가 포함됩니다. 이름에 사용되는 태그 또는 자유 형식 텍스트 필드에 입력하는 모든 데이터는 청구 또는 진단 로그에 사용될 수 있습니다. 외부 서버에 URL을 제공할 때 해당 서버에 대한 요청을 검증하기 위해 보안 인증 정보를 URL에 포함시켜서는 안 됩니다.
**Topics**
+ [
## 전송 중 데이터 암호화
](#security-privacy-intransit)
+ [
# AWS Lambda의 저장된 데이터 암호화
](security-encryption-at-rest.md)
## 전송 중 데이터 암호화
Lambda API 엔드포인트는 HTTPS를 통한 보안 연결만을 지원합니다. AWS Management Console, AWS SDK 또는 Lambda API를 사용하여 Lambda 리소스를 관리하면 모든 통신이 TLS(전송 계층 보안)로 암호화됩니다. API 엔드포인트의 전체 목록은 AWS 일반 참조의 [AWS 리전 및 엔드포인트](https://docs.aws.amazon.com/general/latest/gr/rande.html)를 참조하세요.
[함수를 파일 시스템에 연결하면](configuration-filesystem.md) Lambda에서는 모든 연결에 대해 전송 중 암호화를 사용합니다. 자세한 내용은 *Amazon Elastic File System 사용 설명서*에서 [Amazon EFS의 데이터 암호화](https://docs.aws.amazon.com/efs/latest/ug/encryption.html)를 참조하세요.
[환경 변수](configuration-envvars.md)를 사용하면, 콘솔 암호화 도우미가 클라이언트 측 암호화를 사용하여 전송 중인 환경 변수를 보호하도록 할 수 있습니다. 자세한 내용은 [Lambda 환경 변수 보안](configuration-envvars-encryption.md) 단원을 참조하십시오.
# AWS Lambda의 저장된 데이터 암호화
Lambda는 항상 [AWS 소유 키](https://docs.aws.amazon.com/kms/latest/developerguide/concepts.html#aws-owned-cmk) 또는 [AWS 관리형 키](https://docs.aws.amazon.com/kms/latest/developerguide/concepts.html#aws-managed-cmk)를 사용하여 다음 리소스에 대한 저장 데이터 암호화를 제공합니다.
+ 환경 변수
+ 배포 패키지와 계층 아카이브를 포함하여 Lambda에 업로드하는 파일
+ 이벤트 소스 매핑 필터 기준 객체
선택적으로 고객 관리형 키를 사용하여 [환경 변수](configuration-envvars-encryption.md), [.zip 배포 패키지](encrypt-zip-package.md) 및 [필터 기준 객체](invocation-eventfiltering.md#filter-criteria-encryption)를 암호화하도록 Lambda를 구성할 수 있습니다.
Amazon CloudWatch Logs 및 AWS X-Ray의 경우에도 데이터를 기본적으로 암호화하며, 고객 관리형 키를 사용하도록 구성할 수도 있습니다. 자세한 내용은 [CloudWatch Logs의 로그 데이터 암호화](https://docs.aws.amazon.com/AmazonCloudWatch/latest/logs/encrypt-log-data-kms.html)와 [AWS X-Ray의 데이터 보호](https://docs.aws.amazon.com/xray/latest/devguide/xray-console-encryption.html)를 참조하세요.
## Lambda에 대한 암호화 키 모니터링
Lambda에서 AWS KMS 고객 관리형 키를 사용할 때 [AWS CloudTrail](https://docs.aws.amazon.com/awscloudtrail/latest/userguide/cloudtrail-user-guide.html)을 사용할 수 있습니다. 다음 예제는 Lambda가 고객 관리형 키로 암호화된 데이터에 액세스하기 위해 수행하는 `Decrypt`, `DescribeKey` 및 `GenerateDataKey` 호출에 대한 CloudTrail 이벤트입니다.
------
#### [ Decrypt ]
AWS KMS 고객 관리형 키를 사용하여 [필터 기준](invocation-eventfiltering.md#filter-criteria-encryption) 객체를 암호화한 경우 일반 텍스트로 해당 객체에 액세스하려고 할 때(예: `ListEventSourceMappings` 직접 호출) Lambda가 사용자를 대신하여 `Decrypt` 요청을 전송합니다. 다음 예제 이벤트는 `Decrypt` 작업을 기록합니다.
```
{
"eventVersion": "1.09",
"userIdentity": {
"type": "AssumedRole",
"principalId": "AROA123456789EXAMPLE:example",
"arn": "arn:aws:sts::123456789012:assumed-role/role-name/example",
"accountId": "123456789012",
"accessKeyId": "ASIAIOSFODNN7EXAMPLE",
"sessionContext": {
"sessionIssuer": {
"type": "Role",
"principalId": "AROA123456789EXAMPLE",
"arn": "arn:aws:iam::123456789012:role/role-name",
"accountId": "123456789012",
"userName": "role-name"
},
"attributes": {
"creationDate": "2024-05-30T00:45:23Z",
"mfaAuthenticated": "false"
}
},
"invokedBy": "lambda.amazonaws.com"
},
"eventTime": "2024-05-30T01:05:46Z",
"eventSource": "kms.amazonaws.com",
"eventName": "Decrypt",
"awsRegion": "eu-west-1",
"sourceIPAddress": "lambda.amazonaws.com",
"userAgent": "lambda.amazonaws.com",
"requestParameters": {
"keyId": "arn:aws:kms:eu-west-1:123456789012:key/a1b2c3d4-5678-90ab-cdef-EXAMPLE11111",
"encryptionContext": {
"aws-crypto-public-key": "ABCD+7876787678+CDEFGHIJKL/888666888999888555444111555222888333111==",
"aws:lambda:EventSourceArn": "arn:aws:sqs:eu-west-1:123456789012:sample-source",
"aws:lambda:FunctionArn": "arn:aws:lambda:eu-west-1:123456789012:function:sample-function"
},
"encryptionAlgorithm": "SYMMETRIC_DEFAULT"
},
"responseElements": null,
"requestID": "a1b2c3d4-5678-90ab-cdef-EXAMPLEaaaaa",
"eventID": "a1b2c3d4-5678-90ab-cdef-EXAMPLEbbbbb",
"readOnly": true,
"resources": [
{
"accountId": "AWS Internal",
"type": "AWS::KMS::Key",
"ARN": "arn:aws:kms:eu-west-1:123456789012:key/a1b2c3d4-5678-90ab-cdef-EXAMPLE11111"
}
],
"eventType": "AwsApiCall",
"managementEvent": true,
"recipientAccountId": "123456789012",
"eventCategory": "Management",
"sessionCredentialFromConsole": "true"
}
```
------
#### [ DescribeKey ]
AWS KMS 고객 관리형 키를 사용하여 [필터 기준](invocation-eventfiltering.md#filter-criteria-encryption) 객체를 암호화한 경우 해당 객체에 액세스하려고 할 때(예: `DescribeKey` 직접 호출) Lambda가 사용자를 대신하여 `GetEventSourceMapping` 요청을 전송합니다. 다음 예제 이벤트는 `DescribeKey` 작업을 기록합니다.
```
{
"eventVersion": "1.09",
"userIdentity": {
"type": "AssumedRole",
"principalId": "AROA123456789EXAMPLE:example",
"arn": "arn:aws:sts::123456789012:assumed-role/role-name/example",
"accountId": "123456789012",
"accessKeyId": "ASIAIOSFODNN7EXAMPLE",
"sessionContext": {
"sessionIssuer": {
"type": "Role",
"principalId": "AROA123456789EXAMPLE",
"arn": "arn:aws:iam::123456789012:role/role-name",
"accountId": "123456789012",
"userName": "role-name"
},
"attributes": {
"creationDate": "2024-05-30T00:45:23Z",
"mfaAuthenticated": "false"
}
}
},
"eventTime": "2024-05-30T01:09:40Z",
"eventSource": "kms.amazonaws.com",
"eventName": "DescribeKey",
"awsRegion": "eu-west-1",
"sourceIPAddress": "54.240.197.238",
"userAgent": "Mozilla/5.0 (Macintosh; Intel Mac OS X 10_15_7) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/125.0.0.0 Safari/537.36",
"requestParameters": {
"keyId": "a1b2c3d4-5678-90ab-cdef-EXAMPLE11111"
},
"responseElements": null,
"requestID": "a1b2c3d4-5678-90ab-cdef-EXAMPLEaaaaa",
"eventID": "a1b2c3d4-5678-90ab-cdef-EXAMPLEbbbbb",
"readOnly": true,
"resources": [
{
"accountId": "AWS Internal",
"type": "AWS::KMS::Key",
"ARN": "arn:aws:kms:eu-west-1:123456789012:key/a1b2c3d4-5678-90ab-cdef-EXAMPLE11111"
}
],
"eventType": "AwsApiCall",
"managementEvent": true,
"recipientAccountId": "123456789012",
"eventCategory": "Management",
"tlsDetails": {
"tlsVersion": "TLSv1.3",
"cipherSuite": "TLS_AES_256_GCM_SHA384",
"clientProvidedHostHeader": "kms.eu-west-1.amazonaws.com"
},
"sessionCredentialFromConsole": "true"
}
```
------
#### [ GenerateDataKey ]
`CreateEventSourceMapping` 또는 `UpdateEventSourceMapping` 호출에서 AWS KMS 고객 관리 키를 사용하여 [필터 기준](invocation-eventfiltering.md#filter-criteria-encryption) 객체를 암호화하는 경우 Lambda는 사용자를 대신하여 `GenerateDataKey` 요청을 전송하여 필터 기준을 암호화하는 데이터 키를 생성합니다([봉투 암호화](https://docs.aws.amazon.com/kms/latest/developerguide/concepts.html#enveloping)). 다음 예제 이벤트는 `GenerateDataKey` 작업을 기록합니다.
```
{
"eventVersion": "1.09",
"userIdentity": {
"type": "AssumedRole",
"principalId": "AROA123456789EXAMPLE:example",
"arn": "arn:aws:sts::123456789012:assumed-role/role-name/example",
"accountId": "123456789012",
"accessKeyId": "ASIAIOSFODNN7EXAMPLE",
"sessionContext": {
"sessionIssuer": {
"type": "Role",
"principalId": "AROA123456789EXAMPLE",
"arn": "arn:aws:iam::123456789012:role/role-name",
"accountId": "123456789012",
"userName": "role-name"
},
"attributes": {
"creationDate": "2024-05-30T00:06:07Z",
"mfaAuthenticated": "false"
}
},
"invokedBy": "lambda.amazonaws.com"
},
"eventTime": "2024-05-30T01:04:18Z",
"eventSource": "kms.amazonaws.com",
"eventName": "GenerateDataKey",
"awsRegion": "eu-west-1",
"sourceIPAddress": "lambda.amazonaws.com",
"userAgent": "lambda.amazonaws.com",
"requestParameters": {
"numberOfBytes": 32,
"keyId": "arn:aws:kms:eu-west-1:123456789012:key/a1b2c3d4-5678-90ab-cdef-EXAMPLE11111",
"encryptionContext": {
"aws-crypto-public-key": "ABCD+7876787678+CDEFGHIJKL/888666888999888555444111555222888333111==",
"aws:lambda:EventSourceArn": "arn:aws:sqs:eu-west-1:123456789012:sample-source",
"aws:lambda:FunctionArn": "arn:aws:lambda:eu-west-1:123456789012:function:sample-function"
},
},
"responseElements": null,
"requestID": "a1b2c3d4-5678-90ab-cdef-EXAMPLEaaaaa",
"eventID": "a1b2c3d4-5678-90ab-cdef-EXAMPLEbbbbb",
"readOnly": true,
"resources": [
{
"accountId": "AWS Internal",
"type": "AWS::KMS::Key",
"ARN": "arn:aws:kms:eu-west-1:123456789012:key/a1b2c3d4-5678-90ab-cdef-EXAMPLE11111"
}
],
"eventType": "AwsApiCall",
"managementEvent": true,
"recipientAccountId": "123456789012",
"eventCategory": "Management"
}
```
------
# Lambda의 서비스 연결 역할 사용
Lambda는 AWS Identity and Access Management(IAM) [서비스 연결 역할](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles_terms-and-concepts.html#iam-term-service-linked-role)을 사용합니다. 서비스 링크 역할은 Lambda에 직접 연결된 고유한 유형의 IAM 역할입니다. 서비스 연결 역할은 Lambda에서 사전 정의하며 서비스에서 다른 AWS 서비스를 자동으로 직접 호출하기 위해 필요한 권한을 포함합니다.
Lambda에서 서비스 연결 역할의 권한을 정의하므로 Lambda만 해당 역할을 수임할 수 있습니다. 정의된 권한에는 신뢰 정책과 권한 정책이 포함되며 이 권한 정책은 다른 IAM 엔터티에 연결할 수 없습니다.
먼저 관련 리소스를 삭제한 후에만 서비스 연결 역할을 삭제할 수 있습니다. 이렇게 하면 리소스에 대한 액세스 권한을 부주의로 삭제할 수 없기 때문에 Lambda 리소스가 보호됩니다.
서비스 연결 역할을 지원하는 기타 서비스에 대한 자세한 내용은 [AWS IAM으로 작업하는 서비스](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_aws-services-that-work-with-iam.html)를 참조하고 **서비스 연결 역할** 열에 **예**가 있는 서비스를 찾으세요. 해당 서비스에 대한 서비스 연결 역할 설명서를 보려면 **예** 링크를 선택합니다.
## Lambda의 서비스 연결 역할 권한
Lambda는 **AWSServiceRoleForLambda**라는 서비스 연결 역할을 사용합니다. 서비스 연결 역할은 역할을 수임하기 위해 다음 서비스를 신뢰합니다.
+ `lambda.amazonaws.com`
AWSServiceRoleForLambda라는 역할 권한 정책은 Lambda가 지정된 리소스에 대해 다음 작업을 수행하도록 허용합니다.
+ 작업: `ec2:ManagedResourceOperator`와 `scaler.lambda.amazonaws.com`이 동일한 조건으로 `arn:aws:ec2:*:*:instance/*`에서 `ec2:TerminateInstances`
+ 작업: `*`의 `ec2:DescribeInstanceStatus` 및 `ec2:DescribeInstances`
사용자, 그룹 또는 역할이 서비스 연결 역할을 생성, 편집 또는 삭제할 수 있도록 사용 권한을 구성해야 합니다. 자세한 내용은 *IAM 사용 설명서*의 [서비스 연결 역할 권한](https://docs.aws.amazon.com/IAM/latest/UserGuide/using-service-linked-roles.html#service-linked-role-permissions)을 참조하세요.
관리형 정책 업데이트는 [Lambda 관리형 정책](security-iam-awsmanpol.md#lambda-security-iam-awsmanpol-updates)을 참조하세요.
## Lambda 서비스 연결 역할 생성
서비스 연결 역할은 수동으로 생성할 필요가 없습니다. AWS Management Console, AWS CLI 또는 AWS API에서 Lambda 용량 공급자를 생성하면 Lambda에서 서비스 연결 역할이 생성됩니다.
이 서비스 연결 역할을 삭제했다가 다시 생성해야 하는 경우 동일한 프로세스를 사용하여 계정에서 역할을 다시 생성할 수 있습니다. Lambda 용량 공급자를 생성하면 Lambda에서 서비스 연결 역할이 다시 생성됩니다.
IAM 콘솔에서 **AWSServiceRoleForLambda** 사용 사례를 사용하여 서비스 연결 역할을 생성할 수 있습니다. AWS CLI 또는 AWS API에서 `lambda.amazonaws.com` 서비스 이름의 서비스 연결 역할을 생성합니다. 자세한 내용은 *IAM 사용자 설명서*의 [서비스 연결 역할 생성](https://docs.aws.amazon.com/IAM/latest/UserGuide/using-service-linked-roles.html#create-service-linked-role)을 참조하세요. 이 서비스 연결 역할을 삭제하면 동일한 프로세스를 사용하여 역할을 다시 생성할 수 있습니다.
## Lambda 서비스 연결 역할 편집
Lambda는 AWSServiceRoleForLambda 서비스 연결 역할의 편집을 허용하지 않습니다. 서비스 연결 역할을 생성한 후에는 다양한 개체가 역할을 참조할 수 있기 때문에 역할 이름을 변경할 수 없습니다. 하지만 IAM을 사용하여 역할의 설명을 편집할 수 있습니다. 자세한 내용은 *IAM 사용 설명서*의 [서비스 연결 역할 편집](https://docs.aws.amazon.com/IAM/latest/UserGuide/using-service-linked-roles.html#edit-service-linked-role)을 참조하세요.
## Lambda 서비스 연결 역할 삭제
서비스 연결 역할이 필요한 기능 또는 서비스가 더 이상 필요 없는 경우에는 해당 역할을 삭제하는 것이 좋습니다. 따라서 적극적으로 모니터링하거나 유지하지 않는 미사용 엔터티가 없도록 합니다. 단, 서비스 연결 역할에 대한 리소스를 먼저 정리해야 수동으로 삭제할 수 있습니다.
**참고**
리소스를 삭제하려 할 때 Lambda 서비스가 역할을 사용 중이면 삭제에 실패할 수 있습니다. 이 문제가 발생하면 몇 분 기다렸다가 작업을 다시 시도하세요.
**AWSServiceRoleForLambda에서 사용하는 Lambda 리소스 삭제**
1. 계정에서 모든 Lambda 용량 공급자를 제거합니다. 이 작업은 Lambda 콘솔, CLI 또는 API를 사용하여 수행할 수 있습니다.
1. 서비스 연결 역할을 삭제하기 전에 계정에 Lambda 용량 공급자가 남아 있지 않은지 확인합니다.
**IAM을 사용하여 수동으로 서비스 연결 역할을 삭제하려면 다음을 수행하세요.**
IAM 콘솔, AWS CLI 또는 AWS API를 사용하여 AWSServiceRoleForLambda 서비스 연결 역할을 삭제합니다. 자세한 내용은 IAM 사용 설명서의 [서비스 연결 역할 삭제](https://docs.aws.amazon.com/IAM/latest/UserGuide/using-service-linked-roles.html#delete-service-linked-role)**를 참조하십시오.
## Lambda 서비스 링크 역할이 지원되는 리전
Lambda에서는 서비스가 제공되는 모든 리전에서 서비스 연결 역할 사용을 지원하지 않습니다. AWSServiceRoleForLambda는 다음 AWS 리전에서 지원됩니다.
| 리전 이름 | 리전 자격 증명 | Lambda에서의 지원 |
| --- | --- | --- |
| 미국 동부(버지니아 북부) | us-east-1 | 예 |
| 미국 동부(오하이오) | us-east-2 | 예 |
| 미국 서부(캘리포니아 북부) | us-west-1 | 예 |
| 미국 서부(오리건) | us-west-2 | 예 |
| 아프리카(케이프타운) | af-south-1 | 아니요 |
| 아시아 태평양(홍콩) | ap-east-1 | 예 |
| 아시아 태평양(자카르타) | ap-southeast-3 | 예 |
| 아시아 태평양(방콕) | ap-southeast-7 | 예 |
| 아시아 태평양(뭄바이) | ap-south-1 | 예 |
| 아시아 태평양(오사카) | ap-northeast-3 | 아니요 |
| 아시아 태평양(서울) | ap-northeast-2 | 아니요 |
| 아시아 태평양(싱가포르) | ap-southeast-1 | 예 |
| 아시아 태평양(시드니) | ap-southeast-2 | 예 |
| 아시아 태평양(도쿄) | ap-northeast-1 | 예 |
| 캐나다(중부) | ca-central-1 | 아니요 |
| 유럽(프랑크푸르트) | eu-central-1 | 예 |
| 유럽(아일랜드) | eu-west-1 | 예 |
| 유럽(런던) | eu-west-2 | 예 |
| 유럽(밀라노) | eu-south-1 | 아니요 |
| 유럽(파리) | eu-west-3 | 아니요 |
| 유럽(스톡홀름) | eu-north-1 | 아니요 |
| 중동(바레인) | me-south-1 | 아니요 |
| 중동(UAE) | me-central-1 | 아니요 |
| 남아메리카(상파울루) | sa-east-1 | 아니요 |
| AWS GovCloud(미국 동부) | us-gov-east-1 | 아니요 |
| AWS GovCloud(미국 서부) | us-gov-west-1 | 아니요 |
# AWS Lambda의 ID 및 액세스 관리
AWS Identity and Access Management(IAM)는 관리자가 AWS 리소스에 대한 액세스를 안전하게 제어할 수 있도록 지원하는 AWS 서비스입니다. IAM 관리자는 어떤 사용자가 Lambda 리소스를 사용할 수 있는 *인증*(로그인) 및 *권한*(권한 있음)을 받을 수 있는지 제어합니다. IAM은 추가 비용 없이 사용할 수 있는 AWS 서비스입니다.
**Topics**
+ [
## 고객
](#security_iam_audience)
+ [
## ID를 통한 인증
](#security_iam_authentication)
+ [
## 정책을 사용하여 액세스 관리
](#security_iam_access-manage)
+ [
# AWS Lambda에서 IAM을 사용하는 방식
](security_iam_service-with-iam.md)
+ [
# AWS Lambda에 대한 자격 증명 기반 정책 예시
](security_iam_id-based-policy-examples.md)
+ [
# AWS Lambda의 AWS 관리형 정책
](security-iam-awsmanpol.md)
+ [
# AWS Lambda 보안 인증 및 액세스 문제 해결
](security_iam_troubleshoot.md)
## 고객
AWS Identity and Access Management(IAM)를 사용하는 방법은 역할에 따라 다릅니다.
+ **서비스 사용자** - 기능에 액세스할 수 없는 경우 관리자에게 권한 요청(참조[AWS Lambda 보안 인증 및 액세스 문제 해결](security_iam_troubleshoot.md))
+ **서비스 관리자** - 사용자 액세스 결정 및 권한 요청 제출([AWS Lambda에서 IAM을 사용하는 방식](security_iam_service-with-iam.md) 참조)
+ **IAM 관리자** - 액세스를 관리하기 위한 정책 작성([AWS Lambda에 대한 자격 증명 기반 정책 예시](security_iam_id-based-policy-examples.md) 참조)
## ID를 통한 인증
인증은 ID 자격 증명을 사용하여 AWS에 로그인하는 방식입니다. AWS 계정 루트 사용자이나 IAM 사용자로, 또는 IAM 역할을 수임하여 인증(에 로그인)받아야 합니다.
AWS IAM Identity Center(IAM Identity Center), Single Sign-On 인증 또는 Google/Facebook 자격 증명과 같은 자격 증명 소스의 자격 증명을 사용하여 페더레이션 ID로 로그인할 수 있습니다. 로그인하는 방법에 대한 자세한 내용은 *AWS Sign-In사용 설명서*의 [AWS 계정에 로그인하는 방법](https://docs.aws.amazon.com/signin/latest/userguide/how-to-sign-in.html) 섹션을 참조하세요.
프로그래밍 방식 액세스를 위해 AWS는 요청에 암호화 방식으로 서명할 수 있는 SDK 및 CLI를 제공합니다. 자세한 내용은 *IAM 사용 설명서*의 [API 요청용 AWS Signature Version 4](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_sigv.html) 섹션을 참조하세요.
### AWS 계정 루트 사용자
AWS 계정을 생성하는 경우에는 모든 AWS 서비스 서비스와 리소스에 대한 완전한 액세스 권한이 있는 AWS 계정 *루트 사용자*라는 단일 로그인 ID로 시작합니다. 일상적인 태스크에 루트 사용자를 사용하지 않을 것을 강력히 권장합니다. 루트 사용자 자격 증명이 필요한 작업은 *IAM 사용 설명서*의 [루트 사용자 자격 증명이 필요한 작업](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_root-user.html#root-user-tasks) 섹션을 참조하세요.
### 페더레이션 ID
가장 좋은 방법은 인간 사용자가 ID 공급자와의 페더레이션을 사용하여 임시 자격 증명으로 AWS 서비스에 액세스하도록 하는 것입니다.
*페더레이션 ID*는 엔터프라이즈 사용자 디렉터리, 웹 ID 제공업체 또는 Directory Service의 사용자로, ID의 자격 증명을 사용하여 AWS 서비스에 액세스합니다. 페더레이션 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에 액세스하려면 인간 사용자가 ID 제공업체와의 페더레이션을 사용하도록 요구](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 역할(콘솔)로 전환](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles_use_switch-role-console.html)하거나 AWS CLI 또는 AWS API 작업을 직접적으로 호출하여 역할을 수임할 수 있습니다. 자세한 내용은 *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 ID 또는 리소스에 연결하여 AWS에서 내 액세스를 제어합니다. 정책은 자격 증명이나 리소스와 연결될 때 해당 권한을 정의합니다. AWS는 보안 주체가 요청을 보낼 때 이러한 정책을 평가합니다. 대부분의 정책은 AWS에 JSON 문서로 저장됩니다. 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)을 참조하세요.
# AWS Lambda에서 IAM을 사용하는 방식
IAM을 사용하여 Lambda에 대한 액세스를 관리하기 전에 Lambda와 함께 사용할 수 있는 IAM 기능을 알아보세요.
| IAM 특성 | Lambda 지원 |
| --- | --- |
| [자격 증명 기반 정책](#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) | 부분적 |
Lambda 및 기타 AWS 서비스가 대부분의 IAM 기능과 작동하는 방법을 개괄적으로 알아보려면 *IAM 사용 설명서*의 [AWSIAM이 호환되는 서비스](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_aws-services-that-work-with-iam.html)를 참조하세요.
## Lambda에 대한 자격 증명 기반 정책
**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)를 참조하세요.
### Lambda의 자격 증명 기반 정책 예시
Lambda 자격 증명 기반 정책 예제를 보려면 [AWS Lambda에 대한 자격 증명 기반 정책 예시](security_iam_id-based-policy-examples.md) 섹션을 참조하십시오.
## Lambda 내 리소스 기반 정책
**리소스 기반 정책 지원:** 예
리소스 기반 정책은 리소스에 연결하는 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)를 참조하세요.
리소스 기반 정책을 Lambda 함수 또는 계층에 연결할 수 있습니다. 이 정책은 함수 또는 레이어에서 작업을 수행할 수 있는 보안 주체를 정의합니다.
함수 또는 레이어에 리소스 기반 정책을 연결하는 방법은 [Lambda에서 리소스 기반 IAM 정책 보기](access-control-resource-based.md) 섹션을 참조하십시오.
## Lambda 정책 작업
**정책 작업 지원:** 예
관리자는 AWS JSON 정책을 사용하여 누가 무엇에 액세스할 수 있는지를 지정할 수 있습니다. 즉, 어떤 **보안 주체**가 어떤 **리소스**와 어떤 **조건**에서 **작업**을 수행할 수 있는지를 지정할 수 있습니다.
JSON 정책의 `Action`요소는 정책에서 액세스를 허용하거나 거부하는 데 사용할 수 있는 작업을 설명합니다. 연결된 작업을 수행할 수 있는 권한을 부여하기 위한 정책에 작업을 포함하세요.
Lambda 작업 목록을 보려면 *서비스 인증 참조*의 [AWS Lambda에서 정의한 작업](https://docs.aws.amazon.com/IAM/latest/UserGuide/list_awslambda.html#awslambda-actions-as-permissions)을 참조하세요.
Lambda의 정책 작업은 작업 앞에 다음 접두사를 사용합니다.
```
lambda
```
단일 문에서 여러 작업을 지정하려면 쉼표로 구분합니다.
```
"Action": [
"lambda:action1",
"lambda:action2"
]
```
Lambda 자격 증명 기반 정책 예제를 보려면 [AWS Lambda에 대한 자격 증명 기반 정책 예시](security_iam_id-based-policy-examples.md) 섹션을 참조하십시오.
## Lambda 정책 리소스
**정책 리소스 지원:** 예
관리자는 AWS JSON 정책을 사용하여 누가 무엇에 액세스할 수 있는지를 지정할 수 있습니다. 즉, 어떤 **보안 주체**가 어떤 **리소스**와 어떤 **조건**에서 **작업**을 수행할 수 있는지를 지정할 수 있습니다.
`Resource` JSON 정책 요소는 작업이 적용되는 하나 이상의 객체를 지정합니다. 모범 사례에 따라 [Amazon 리소스 이름(ARN)](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference-arns.html)을 사용하여 리소스를 지정합니다. 리소스 수준 권한을 지원하지 않는 작업의 경우, 와일드카드(\$1)를 사용하여 해당 문이 모든 리소스에 적용됨을 나타냅니다.
```
"Resource": "*"
```
Lambda 리소스 유형 및 해당 ARN의 목록을 보려면 *서비스 권한 부여 참조*의 [AWS Lambda에서 정의한 리소스 유형](https://docs.aws.amazon.com/IAM/latest/UserGuide/list_awslambda.html#awslambda-resources-for-iam-policies)을 참조하십시오. 각 리소스의 ARN을 지정할 수 있는 작업을 알아보려면 [AWS Lambda에서 정의한 작업](https://docs.aws.amazon.com/IAM/latest/UserGuide/list_awslambda.html#awslambda-actions-as-permissions)을 참조하세요.
Lambda 자격 증명 기반 정책 예제를 보려면 [AWS Lambda에 대한 자격 증명 기반 정책 예시](security_iam_id-based-policy-examples.md) 섹션을 참조하십시오.
## Lambda 정책 조건 키
**서비스별 정책 조건 키 지원:** 예
관리자는 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)를 참조하세요.
Lambda 조건 키 목록을 보려면 *서비스 인증 참조*의 [AWS Lambda을(를) 위한 조건 키](https://docs.aws.amazon.com/IAM/latest/UserGuide/list_awslambda.html#awslambda-policy-keys)를 참조하세요. 조건 키를 사용할 수 있는 작업과 리소스를 알아보려면 [AWS Lambda에서 정의한 작업](https://docs.aws.amazon.com/IAM/latest/UserGuide/list_awslambda.html#awslambda-actions-as-permissions)을 참조하세요.
Lambda 자격 증명 기반 정책 예제를 보려면 [AWS Lambda에 대한 자격 증명 기반 정책 예시](security_iam_id-based-policy-examples.md) 섹션을 참조하십시오.
## Lambda의 ACL
**ACL 지원:** 아니요
액세스 제어 목록(ACL)은 어떤 보안 주체(계정 멤버, 사용자 또는 역할)가 리소스에 액세스할 수 있는 권한을 가지고 있는지를 제어합니다. ACL은 JSON 정책 문서 형식을 사용하지 않지만 리소스 기반 정책과 유사합니다.
## ABAC와 Lambda 사용
**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)을 참조하세요.
Lambda 리소스 태그 지정에 대한 자세한 내용은 [Lambda에서 속성 기반 액세스 제어 사용](attribute-based-access-control.md) 섹션을 참조하세요.
## Lambda에서 임시 보안 인증 정보 사용
**임시 자격 증명 지원:** 예
임시 자격 증명은 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) 섹션을 참조하세요.
## Lambda에 대한 전달 액세스 세션
**전달 액세스 세션(FAS) 지원:** 아니요
전달 액세스 세션(FAS)은 AWS 서비스를 직접 호출하는 위탁자의 권한과 요청하는 AWS 서비스를 함께 사용하여 다운스트림 서비스에 대한 요청을 수행합니다. FAS 요청 시 정책 세부 정보는 [전달 액세스 세션](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_forward_access_sessions.html)을 참조하세요.
## Lambda에 대한 서비스 역할
**서비스 역할 지원:** 예
서비스 역할은 서비스가 사용자를 대신하여 작업을 수행하는 것으로 가정하는 [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)을 참조하세요.
Lambda에서는 서비스 역할을 [실행 역할](lambda-intro-execution-role.md)이라고 합니다.
**주의**
서비스 역할에 대한 권한을 변경하면 Lambda 기능이 중단될 수 있습니다.
## Lambda의 서비스 연결 역할
**서비스 링크 역할 지원:** 부분적
서비스 연결 역할은 AWS 서비스에 연결된 서비스 역할의 한 유형입니다. 서비스는 사용자를 대신하여 작업을 수행하기 위해 역할을 수임할 수 있습니다. 서비스 연결 역할은 AWS 계정에 나타나고, 서비스가 소유합니다. IAM 관리자는 서비스 연결 역할의 권한을 볼 수 있지만 편집은 할 수 없습니다.
Lambda에는 서비스 연결 역할이 없지만 Lambda@Edge에는 있습니다. 자세한 내용은 *Amazon CloudFront 개발자 안내서*의 [Lambda@Edge의 서비스 연결 역할](https://docs.aws.amazon.com/AmazonCloudFront/latest/DeveloperGuide/lambda-edge-permissions.html#using-service-linked-roles)을 참조하세요.
서비스 연결 역할 생성 또는 관리에 대한 자세한 내용은 [IAM으로 작업하는 AWS서비스](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_aws-services-that-work-with-iam.html)를 참조하세요. **서비스 연결 역할** 열에서 `Yes`가 포함된 서비스를 테이블에서 찾습니다. 해당 서비스에 대한 서비스 연결 역할 설명서를 보려면 **예(Yes)** 링크를 선택합니다.
# AWS Lambda에 대한 자격 증명 기반 정책 예시
기본적으로 사용자 및 역할은 Lambda 리소스를 생성하거나 수정할 수 있는 권한이 없습니다. 사용자에게 사용자가 필요한 리소스에서 작업을 수행할 권한을 부여하려면 IAM 관리자가 IAM 정책을 생성하면 됩니다.
이러한 예제 JSON 정책 문서를 사용하여 IAM ID 기반 정책을 생성하는 방법을 알아보려면 *IAM 사용 설명서*의 [IAM 정책 생성(콘솔)](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies_create-console.html)을 참조하세요.
각 리소스 유형에 대한 ARN 형식을 포함하여 Lambda에서 정의한 작업 및 리소스 유형에 대한 자세한 내용은 *서비스 권한 부여 참조*에서 [AWS Lambda에 대한 작업, 리소스 및 조건 키](https://docs.aws.amazon.com/IAM/latest/UserGuide/list_awslambda.html)를 참조하십시오.
**Topics**
+ [
## 정책 모범 사례
](#security_iam_service-with-iam-policy-best-practices)
+ [
## Lambda 콘솔 사용
](#security_iam_id-based-policy-examples-console)
+ [
## 사용자가 자신이 권한을 볼 수 있도록 허용
](#security_iam_id-based-policy-examples-view-own-permissions)
## 정책 모범 사례
ID 기반 정책에 따라 계정에서 사용자가 Lambda 리소스를 생성, 액세스 또는 삭제할 수 있는지 여부가 결정됩니다. 이 작업으로 인해 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을 사용하여 모든 요청을 전송해야 한다고 지정하는 정책 조건을 작성할 수 있습니다. CloudFormation와 같이, 특정 AWS 서비스를 통해 사용되는 경우에만 서비스 작업에 대한 액세스 권한을 부여할 수도 있습니다. 자세한 내용은 *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) 필요** – AWS 계정에 IAM 사용자 또는 루트 사용자가 필요한 시나리오가 있는 경우, 추가 보안을 위해 MFA를 설정합니다. 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)를 참조하세요.
## Lambda 콘솔 사용
AWS Lambda 콘솔에 액세스하려면 최소 권한 세트가 있어야 합니다. 이러한 권한은 AWS 계정에서 Lambda 리소스에 대한 세부 정보를 나열하고 볼 수 있도록 허용해야 합니다. 최소 필수 권한보다 더 제한적인 ID 기반 정책을 생성하는 경우, 콘솔이 해당 정책에 연결된 엔티티(사용자 또는 역할)에 대해 의도대로 작동하지 않습니다.
AWS CLI 또는 AWS API만 직접적으로 호출하는 사용자에게 최소 콘솔 권한을 허용할 필요가 없습니다. 대신, 수행하려는 API 작업과 일치하는 작업에만 액세스할 수 있도록 합니다.
함수 개발을 위해 최소한의 액세스를 부여하는 정책 예제는 단원을 참조하세요[사용자에게 Lambda 함수에 대한 액세스 권한 부여](permissions-user-function.md) Lambda API에 더해 Lambda 콘솔은 다른 서비스를 사용하여 트리거 구성을 표시하고 사용자의 신규 트리거 추가를 돕습니다. 사용자가 다른 서비스와 함께 Lambda를 사용하는 경우 해당 서비스에도 액세스해야 합니다. Lambda로 다른 서비스를 구성하는 방법에 대한 자세한 내용은 [다른 AWS 서비스의 이벤트로 Lambda 간접 호출](lambda-services.md) 단원을 참조하세요.
## 사용자가 자신이 권한을 볼 수 있도록 허용
이 예제는 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": "*"
}
]
}
```
# AWS Lambda의 AWS 관리형 정책
AWS 관리형 정책은 AWS에 의해 생성되고 관리되는 독립 실행형 정책입니다. AWS 관리형 정책은 사용자, 그룹 및 역할에 권한 할당을 시작할 수 있도록 많은 일반 사용 사례에 대한 권한을 제공하도록 설계되었습니다.
AWS 관리형 정책은 모든 AWS 고객이 사용할 수 있기 때문에 특정 사용 사례에 대해 최소 권한을 부여하지 않을 수 있습니다. 사용 사례에 고유한 [고객 관리형 정책](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies_managed-vs-inline.html#customer-managed-policies)을 정의하여 권한을 줄이는 것이 좋습니다.
AWS 관리형 정책에서 정의한 권한은 변경할 수 없습니다. 만약 AWS가 AWS 관리형 정책에 정의된 권한을 업데이트할 경우 정책이 연결되어 있는 모든 보안 주체 ID(사용자, 그룹 및 역할)에도 업데이트가 적용됩니다. 새 AWS 서비스을(를) 시작하거나 새 API 작업을 기존 서비스에 이용하는 경우, AWS가 AWS 관리형 정책을 업데이트할 가능성이 높습니다.
자세한 내용은 *IAM 사용자 가이드*의 [AWS 관리형 정책](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies_managed-vs-inline.html#aws-managed-policies)을 참조하세요.
**Topics**
+ [
## AWS 관리형 정책: AWSLambda\$1FullAccess
](#lambda-security-iam-awsmanpol-AWSLambda_FullAccess)
+ [
## AWS 관리형 정책: AWSLambda\$1ReadOnlyAccess
](#lambda-security-iam-awsmanpol-AWSLambda_ReadOnlyAccess)
+ [
## AWS 관리형 정책: AWSLambdaBasicExecutionRole
](#lambda-security-iam-awsmanpol-AWSLambdaBasicExecutionRole)
+ [
## AWS 관리형 정책: AWSLambdaBasicDurableExecutionRolePolicy
](#lambda-security-iam-awsmanpol-AWSLambdaBasicDurableExecutionRolePolicy)
+ [
## AWS 관리형 정책: AWSLambdaDynamoDBExecutionRole
](#lambda-security-iam-awsmanpol-AWSLambdaDynamoDBExecutionRole)
+ [
## AWS 관리형 정책: AWSLambdaENIManagementAccess
](#lambda-security-iam-awsmanpol-AWSLambdaENIManagementAccess)
+ [
## AWS 관리형 정책: AWSLambdaInvocation-DynamoDB
](#lambda-security-iam-awsmanpol-AWSLambdaInvocation-DynamoDB)
+ [
## AWS 관리형 정책: AWSLambdaKinesisExecutionRole
](#lambda-security-iam-awsmanpol-AWSLambdaKinesisExecutionRole)
+ [
## AWS 관리형 정책: AWSLambdaMSKExecutionRole
](#lambda-security-iam-awsmanpol-AWSLambdaMSKExecutionRole)
+ [
## AWS 관리형 정책: AWSLambdaRole
](#lambda-security-iam-awsmanpol-AWSLambdaRole)
+ [
## AWS 관리형 정책: AWSLambdaSQSQueueExecutionRole
](#lambda-security-iam-awsmanpol-AWSLambdaSQSQueueExecutionRole)
+ [
## AWS 관리형 정책: AWSLambdaVPCAccessExecutionRole
](#lambda-security-iam-awsmanpol-AWSLambdaVPCAccessExecutionRole)
+ [
## AWS 관리형 정책: AWSLambdaManagedEC2ResourceOperator
](#lambda-security-iam-awsmanpol-AWSLambdaManagedEC2ResourceOperator)
+ [
## AWS 관리형 정책: AWSLambdaServiceRolePolicy
](#lambda-security-iam-awsmanpol-AWSLambdaServiceRolePolicy)
+ [
## AWS 관리형 정책에 대한 Lambda 업데이트
](#lambda-security-iam-awsmanpol-updates)
## AWS 관리형 정책: AWSLambda\$1FullAccess
이 정책은 Lambda 작업에 대한 전체 액세스 권한을 부여합니다. 또한 Lambda 리소스를 개발하고 유지 관리하는 데 사용되는 다른 AWS 서비스에 대한 권한도 부여합니다.
사용자, 그룹 및 역할에 `AWSLambda_FullAccess` 정책을 연결할 수 있습니다.
** 권한 세부 정보**
이 정책에는 다음 권한이 포함되어 있습니다.
+ `lambda` – 보안 주체에게 Lambda에 대한 전체 액세스 권한을 허용합니다.
+ `cloudformation` – 보안 주체가 AWS CloudFormation 스택을 설명하고 해당 스택의 리소스를 나열하도록 허용합니다.
+ `cloudwatch` - 보안 주체가 Amazon CloudWatch 지표를 나열하고 지표 데이터를 가져오도록 허용합니다.
+ `ec2` - 보안 주체가 보안 그룹, 서브넷 및 VPC를 설명하도록 허용합니다.
+ `iam` - 보안 주체가 정책, 정책 버전, 역할, 역할 정책, 연결된 역할 정책 및 역할 목록을 가져오도록 허용합니다. 이 정책은 또한 보안 주체가 Lambda에 역할을 전달할 수 있도록 허용합니다. `PassRole` 권한은 함수에 실행 역할을 할당할 때 사용됩니다. `CreateServiceLinkedRole` 권한은 서비스 연결 역할을 생성할 때 사용됩니다.
+ `kms` – 보안 주체가 볼륨 암호화 별칭을 나열하고 키를 설명할 수 있도록 허용합니다.
+ `logs` - 위탁자가 로그 스트림을 설명하고, 로그 이벤트를 가져오고, 로그 이벤트를 필터링하고, Live Tail 세션을 시작하고 중지할 수 있도록 허용합니다.
+ `states` – 보안 주체가 AWS Step Functions 상태 시스템을 설명하고 나열하도록 허용합니다.
+ `tag` - 보안 주체가 태그를 기반으로 리소스를 가져오도록 허용합니다.
+ `xray` - 보안 주체가 AWS X-Ray 트레이스 요약을 가져오고 ID로 지정된 트레이스 목록을 검색하도록 허용합니다.
JSON 정책 문서와 정책 버전을 비롯한 이 정책에 대한 자세한 내용은 **AWS관리형 정책 참조 가이드의 [AWSLambda\$1FullAccess](https://docs.aws.amazon.com/aws-managed-policy/latest/reference/AWSLambda_FullAccess.html)를 참조하세요.
## AWS 관리형 정책: AWSLambda\$1ReadOnlyAccess
이 정책은 Lambda 리소스 및 Lambda 리소스를 개발하고 유지 관리하는 데 사용되는 다른 AWS 서비스에 대한 읽기 전용 액세스 권한을 부여합니다.
사용자, 그룹 및 역할에 `AWSLambda_ReadOnlyAccess` 정책을 연결할 수 있습니다.
** 권한 세부 정보**
이 정책에는 다음 권한이 포함되어 있습니다.
+ `lambda` - 보안 주체가 모든 리소스를 가져오고 나열하도록 허용합니다.
+ `cloudformation` – 보안 주체가 AWS CloudFormation 스택을 설명 및 나열하고 해당 스택의 리소스를 나열하도록 허용합니다.
+ `cloudwatch` - 보안 주체가 Amazon CloudWatch 지표를 나열하고 지표 데이터를 가져오도록 허용합니다.
+ `ec2` - 보안 주체가 보안 그룹, 서브넷 및 VPC를 설명하도록 허용합니다.
+ `iam` - 보안 주체가 정책, 정책 버전, 역할, 역할 정책, 연결된 역할 정책 및 역할 목록을 가져오도록 허용합니다.
+ `kms` - 보안 주체가 별칭을 나열하도록 허용합니다.
+ `logs` - 위탁자가 로그 스트림을 설명하고, 로그 이벤트를 가져오고, 로그 이벤트를 필터링하고, Live Tail 세션을 시작하고 중지할 수 있도록 허용합니다.
+ `states` – 보안 주체가 AWS Step Functions 상태 시스템을 설명하고 나열하도록 허용합니다.
+ `tag` - 보안 주체가 태그를 기반으로 리소스를 가져오도록 허용합니다.
+ `xray` - 보안 주체가 AWS X-Ray 트레이스 요약을 가져오고 ID로 지정된 트레이스 목록을 검색하도록 허용합니다.
JSON 정책 문서와 정책 버전을 비롯한 이 정책에 대한 자세한 내용은 **AWS관리형 정책 참조 가이드의 [AWSLambda\$1ReadOnlyAccess](https://docs.aws.amazon.com/aws-managed-policy/latest/reference/AWSLambda_ReadOnlyAccess.html)를 참조하세요.
## AWS 관리형 정책: AWSLambdaBasicExecutionRole
이 정책은 CloudWatch Logs에 로그를 업로드할 수 있는 권한을 부여합니다.
사용자, 그룹 및 역할에 `AWSLambdaBasicExecutionRole` 정책을 연결할 수 있습니다.
JSON 정책 문서와 정책 버전을 비롯한 이 정책에 대한 자세한 내용은 **AWS관리형 정책 참조 가이드의 [AWSLambdaBasicExecutionRole](https://docs.aws.amazon.com/aws-managed-policy/latest/reference/AWSLambdaBasicExecutionRole.html)을 참조하세요.
## AWS 관리형 정책: AWSLambdaBasicDurableExecutionRolePolicy
이 정책은 CloudWatch Logs에 대한 쓰기 권한과 Lambda 지속성 함수에서 사용하는 지속 실행 API에 대한 읽기/쓰기 권한을 제공합니다. 이 정책은 Lambda 지속성 함수에 필요한 필수 권한을 제공하며, 지속 실행 API를 사용하여 함수 간접 호출 전반에서 진행 상황과 상태를 유지합니다.
사용자, 그룹 및 역할에 `AWSLambdaBasicDurableExecutionRolePolicy` 정책을 연결할 수 있습니다.
** 권한 세부 정보**
이 정책에는 다음 권한이 포함되어 있습니다.
+ `logs` - 보안 주체가 로그 그룹 및 로그 스트림을 생성하고, 로그 이벤트를 CloudWatch Logs에 쓸 수 있습니다.
+ `lambda` - 보안 주체가 지속 실행 상태에 체크포인트를 지정하고 Lambda 지속성 함수의 지속 실행 상태를 검색할 수 있습니다.
최신 버전의 JSON 정책 문서를 포함하여 정책에 대한 추가 세부 정보를 보려면 *AWS 관리형 정책 참조 안내서*의 [AWSLambdaBasicDurableExecutionRolePolicy](https://docs.aws.amazon.com/aws-managed-policy/latest/reference/AWSLambdaBasicDurableExecutionRolePolicy.html)를 참조하세요.
## AWS 관리형 정책: AWSLambdaDynamoDBExecutionRole
이 정책은 Amazon DynamoDB Stream에서 레코드를 읽고 CloudWatch Logs에 쓸 수 있는 권한을 부여합니다.
사용자, 그룹 및 역할에 `AWSLambdaDynamoDBExecutionRole` 정책을 연결할 수 있습니다.
JSON 정책 문서와 정책 버전을 비롯한 이 정책에 대한 자세한 내용은 **AWS관리형 정책 참조 가이드의 [AWSLambdaDynamoDBExecutionRole](https://docs.aws.amazon.com/aws-managed-policy/latest/reference/AWSLambdaDynamoDBExecutionRole.html)을 참조하세요.
## AWS 관리형 정책: AWSLambdaENIManagementAccess
이 정책은 VPC 지원 Lambda 함수에서 사용하는 탄력적 네트워크 인터페이스를 생성, 설명 및 삭제할 권한을 부여합니다.
사용자, 그룹 및 역할에 `AWSLambdaENIManagementAccess` 정책을 연결할 수 있습니다.
JSON 정책 문서와 정책 버전을 비롯한 이 정책에 대한 자세한 내용은 **AWS관리형 정책 참조 가이드의 [AWSLambdaENIManagementAccess](https://docs.aws.amazon.com/aws-managed-policy/latest/reference/AWSLambdaENIManagementAccess.html)를 참조하세요.
## AWS 관리형 정책: AWSLambdaInvocation-DynamoDB
이 정책은 Amazon DynamoDB Streams에 대한 읽기 액세스 권한을 부여합니다.
사용자, 그룹 및 역할에 `AWSLambdaInvocation-DynamoDB` 정책을 연결할 수 있습니다.
JSON 정책 문서와 정책 버전을 비롯한 이 정책에 대한 자세한 내용은 **AWS관리형 정책 참조 가이드의 [AWSLambdaInvocation-DynamoDB](https://docs.aws.amazon.com/aws-managed-policy/latest/reference/AWSLambdaInvocation-DynamoDB.html)를 참조하세요.
## AWS 관리형 정책: AWSLambdaKinesisExecutionRole
이 정책은 Amazon Kinesis 데이터 스트림에서 이벤트를 읽고 CloudWatch Logs에 쓸 수 있는 권한을 부여합니다.
사용자, 그룹 및 역할에 `AWSLambdaKinesisExecutionRole` 정책을 연결할 수 있습니다.
JSON 정책 문서와 정책 버전을 비롯한 이 정책에 대한 자세한 내용은 **AWS관리형 정책 참조 가이드의 [AWSLambdaKinesisExecutionRole](https://docs.aws.amazon.com/aws-managed-policy/latest/reference/AWSLambdaKinesisExecutionRole.html)을 참조하세요.
## AWS 관리형 정책: AWSLambdaMSKExecutionRole
이 정책은 Amazon Managed Streaming for Apache Kafka 클러스터에서 레코드를 읽고 액세스하고, 탄력적 네트워크 인터페이스를 관리하고, CloudWatch Logs에 쓸 수 있는 권한을 부여합니다.
사용자, 그룹 및 역할에 `AWSLambdaMSKExecutionRole` 정책을 연결할 수 있습니다.
JSON 정책 문서와 정책 버전을 비롯한 이 정책에 대한 자세한 내용은 **AWS관리형 정책 참조 가이드의 [AWSLambdaMSKExecutionRole](https://docs.aws.amazon.com/aws-managed-policy/latest/reference/AWSLambdaMSKExecutionRole.html)을 참조하세요.
## AWS 관리형 정책: AWSLambdaRole
이 정책은 Lambda 함수를 간접적으로 간접 호출할 수 있는 권한을 부여합니다.
사용자, 그룹 및 역할에 `AWSLambdaRole` 정책을 연결할 수 있습니다.
JSON 정책 문서와 정책 버전을 비롯한 이 정책에 대한 자세한 내용은 **AWS관리형 정책 참조 가이드의 [AWSLambdaRole](https://docs.aws.amazon.com/aws-managed-policy/latest/reference/AWSLambdaRole.html)을 참조하세요.
## AWS 관리형 정책: AWSLambdaSQSQueueExecutionRole
이 정책은 Amazon Simple Queue Service(Amazon SQS) 대기열에서 메시지를 읽고 삭제하고 CloudWatch Logs에 쓸 수 있는 권한을 부여합니다.
사용자, 그룹 및 역할에 `AWSLambdaSQSQueueExecutionRole` 정책을 연결할 수 있습니다.
JSON 정책 문서와 정책 버전을 비롯한 이 정책에 대한 자세한 내용은 **AWS관리형 정책 참조 가이드의 [AWSLambdaSQSQueueExecutionRole](https://docs.aws.amazon.com/aws-managed-policy/latest/reference/AWSLambdaSQSQueueExecutionRole.html)을 참조하세요.
## AWS 관리형 정책: AWSLambdaVPCAccessExecutionRole
이 정책은 Amazon Virtual Private Cloud 내에서 탄력적 네트워크 인터페이스를 관리하고 CloudWatch Logs에 쓸 수 있는 권한을 부여합니다.
사용자, 그룹 및 역할에 `AWSLambdaVPCAccessExecutionRole` 정책을 연결할 수 있습니다.
JSON 정책 문서와 정책 버전을 비롯한 이 정책에 대한 자세한 내용은 **AWS관리형 정책 참조 가이드의 [AWSLambdaVPCAccessExecutionRole](https://docs.aws.amazon.com/aws-managed-policy/latest/reference/AWSLambdaVPCAccessExecutionRole.html)을 참조하세요.
## AWS 관리형 정책: AWSLambdaManagedEC2ResourceOperator
이 정책은 Lambda 용량 공급자에 대해 자동화된 Amazon Elastic Compute Cloud 인스턴스 관리를 활성화합니다. Lambda 스케일러 서비스에 사용자를 대신하여 인스턴스 수명 주기 작업을 수행할 권한을 부여합니다.
사용자, 그룹 및 역할에 `AWSLambdaManagedEC2ResourceOperator` 정책을 연결할 수 있습니다.
** 권한 세부 정보**
이 정책에는 다음 권한이 포함되어 있습니다.
+ `ec2:RunInstances` - ec2:ManagedResourceOperator가 scaler.lambda.amazonaws.com과 같고 AMI 사용을 Amazon 소유 이미지로만 제한하는 조건으로 Lambda의 새 Amazon EC2 인스턴스 시작을 허용합니다.
+ `ec2:DescribeInstances` 및 `ec2:DescribeInstanceStatus` - Lambda의 인스턴스 상태 모니터링 및 인스턴스 정보 검색을 허용합니다.
+ `ec2:CreateTags` -관리 및 식별 목적으로 Lambda가 Amazon EC2 리소스에 태그를 지정할 수 있도록 허용합니다.
+ `ec2:DescribeAvailabilityZones` - 인스턴스 배치 결정을 위해 Lambda가 사용 가능한 영역을 볼 수 있도록 허용합니다.
+ `ec2:DescribeCapacityReservations` - 최적의 인스턴스 배치를 위해 Lambda가 용량 예약을 확인할 수 있도록 허용합니다.
+ `ec2:DescribeInstanceTypes` 및 `ec2:DescribeInstanceTypeOfferings` - Lambda의 사용 가능한 인스턴스 유형 및 해당 제품 검토를 허용합니다.
+ `ec2:DescribeSubnets` - 네트워크 계획을 위해 Lambda가 서브넷 구성을 검사할 수 있도록 허용합니다.
+ `ec2:DescribeSecurityGroups` - Lambda가 네트워크 인터페이스 구성에 대한 보안 그룹 정보를 검색할 수 있도록 허용합니다.
+ `ec2:CreateNetworkInterface` - Lambda의 네트워크 인터페이스 생성 및 서브넷과 보안 그룹 연결 관리를 허용합니다.
+ `ec2:AttachNetworkInterface` - `ec2:ManagedResourceOperator`가 [scaler.lambda.amazonaws.com](http://scaler.lambda.amazonaws.com/)과 같은 조건에서 Lambda가 Amazon EC2 인스턴스에 네트워크 인터페이스를 연결할 수 있도록 허용합니다.
JSON 정책 문서와 정책 버전을 비롯한 이 정책에 대한 자세한 내용은 *AWS 관리형 정책 참조 가이드*의 [AWSLambdaManagedEC2ResourceOperator](https://docs.aws.amazon.com/aws-managed-policy/latest/reference/AWSLambdaManagedEC2ResourceOperator.html)를 참조하세요.
## AWS 관리형 정책: AWSLambdaServiceRolePolicy
이 정책은 Lambda가 Lambda 용량 공급자의 일부로 관리되는 인스턴스를 종료할 수 있도록 AWSServiceRoleForLambda라는 서비스 연결 역할에 연결됩니다.
** 권한 세부 정보**
이 정책에는 다음 권한이 포함되어 있습니다.
+ `ec2:TerminateInstances` - ec2:ManagedResourceOperator가 scaler.lambda.amazonaws.com과 같은 조건으로 Lambda의 EC2 인스턴스 종료를 허용합니다.
+ `ec2:DescribeInstanceStatus` 및 `ec2:DescribeInstances` - Lambda가 EC2 인스턴스를 설명할 수 있도록 허용합니다.
이 정책에 대한 자세한 내용은 [Lambda의 서비스 연결 역할 사용](using-service-linked-roles.md)을 참조하세요.
## AWS 관리형 정책에 대한 Lambda 업데이트
| 변경 | 설명 | 날짜 |
| --- | --- | --- |
| [AWSLambdaManagedEC2ResourceOperator](https://docs.aws.amazon.com/aws-managed-policy/latest/reference/AWSLambdaManagedEC2ResourceOperator.html) – 새 정책 | Lambda에서 스케일러 서비스가 인스턴스 수명 주기 작업을 수행할 수 있도록 Lambda 용량 공급자에 대한 자동화된 Amazon EC2 인스턴스 관리를 활성화하는 새 관리형 정책이 추가되었습니다. | 2025년 11월 30일 |
| [AWSLambdaServiceRolePolicy](https://docs.aws.amazon.com/aws-managed-policy/latest/reference/AWSLambdaServiceRolePolicy.html) – 새 정책 | Lambda가 Lambda 용량 공급자의 일부로 관리되는 인스턴스를 종료할 수 있도록 서비스 연결 역할에 새 관리형 정책이 추가되었습니다. | 2025년 11월 30일 |
| [AWSLambda\$1FullAccess](https://docs.aws.amazon.com/aws-managed-policy/latest/reference/AWSLambda_FullAccess.html) – 변경 | `kms:DescribeKey` 및 `iam:CreateServiceLinkedRole` 작업을 허용하도록 `AWSLambda_FullAccess` 정책이 업데이트되었습니다. | 2025년 11월 30일 |
| [AWSLambdaBasicDurableExecutionRolePolicy](https://docs.aws.amazon.com/aws-managed-policy/latest/reference/AWSLambdaBasicDurableExecutionRolePolicy.html) – 새 관리형 정책 | CloudWatch Logs에 대한 쓰기 권한과 Lambda 지속성 함수에서 사용하는 지속 실행 API에 대한 읽기/쓰기 권한을 제공하는 새 관리형 정책인 `AWSLambdaBasicDurableExecutionRolePolicy`가 릴리스되었습니다. | 2025년 12월 1일 |
| [AWSLambda\$1ReadOnlyAccess](https://docs.aws.amazon.com/aws-managed-policy/latest/reference/AWSLambda_ReadOnlyAccess.html) 및 [AWSLambda\$1FullAccess](https://docs.aws.amazon.com/aws-managed-policy/latest/reference/AWSLambda_FullAccess.html) – 변경 | Lambda는 `logs:StartLiveTail` 및 `logs:StopLiveTail` 작업을 허용하도록 `AWSLambda_ReadOnlyAccess` 및 `AWSLambda_FullAccess` 정책을 업데이트했습니다. | 2025년 3월 17일 |
| [AWSLambdaVPCAccessExecutionRole](https://docs.aws.amazon.com/aws-managed-policy/latest/reference/AWSLambdaVPCAccessExecutionRole.html) - 변경 | Lambda는 `ec2:DescribeSubnets` 작업을 허용하도록 `AWSLambdaVPCAccessExecutionRole` 정책을 업데이트했습니다. | 2024년 1월 5일 |
| [AWSLambda\$1ReadOnlyAccess](https://docs.aws.amazon.com/aws-managed-policy/latest/reference/AWSLambda_ReadOnlyAccess.html) – 변경 | Lambda는 보안 주체가 CloudFormation 스택을 나열할 수 있도록 `AWSLambda_ReadOnlyAccess` 정책을 업데이트했습니다. | 2023년 7월 27일 |
| AWS Lambda에서 변경 사항 추적 시작 | AWS Lambda에서 AWS 관리형 정책에 대한 변경 내용 추적을 시작했습니다. | 2023년 7월 27일 |
# AWS Lambda 보안 인증 및 액세스 문제 해결
다음 정보를 사용하여 Lambda 및 IAM으로 작업할 때 발생할 수 있는 일반적인 문제를 진단하고 수정할 수 있습니다.
**Topics**
+ [
## Lambda에서 작업을 수행할 권한이 없음
](#security_iam_troubleshoot-no-permissions)
+ [
## iam:PassRole을 수행하도록 인증되지 않음
](#security_iam_troubleshoot-passrole)
+ [
## 내 AWS 계정 외부의 사람이 내 Lambda 리소스에 액세스할 수 있게 허용하기를 원합니다.
](#security_iam_troubleshoot-cross-account-access)
## Lambda에서 작업을 수행할 권한이 없음
작업을 수행할 권한이 없다는 오류가 표시되면 작업을 수행할 수 있도록 정책을 업데이트해야 합니다.
다음의 예제 오류는 `mateojackson` IAM 사용자가 콘솔을 사용하여 가상 `my-example-widget` 리소스에 대한 세부 정보를 보려고 하지만 가상 `lambda:GetWidget` 권한이 없을 때 발생합니다.
```
User: arn:aws:iam::123456789012:user/mateojackson is not authorized to perform: lambda:GetWidget on resource: my-example-widget
```
이 경우, `lambda:GetWidget` 작업을 사용하여 `my-example-widget` 리소스에 액세스할 수 있도록 `mateojackson` 사용자 정책을 업데이트해야 합니다.
도움이 필요한 경우 AWS 관리자에게 문의하세요. 관리자는 로그인 자격 증명을 제공한 사람입니다.
## iam:PassRole을 수행하도록 인증되지 않음
`iam:PassRole` 작업을 수행할 수 있는 권한이 없다는 오류가 수신되면 Lambda에 역할을 전달할 수 있도록 정책을 업데이트해야 합니다.
일부 AWS 서비스에서는 새로운 서비스 역할 또는 서비스 연결 역할을 생성하는 대신 해당 서비스에 기존 역할을 전달할 수 있습니다. 이렇게 하려면 사용자가 서비스에 역할을 전달할 수 있는 권한을 가지고 있어야 합니다.
다음 예제 오류는 `marymajor`라는 IAM 사용자가 콘솔을 사용하여 Lambda에서 작업을 수행하려고 하는 경우에 발생합니다. 하지만 작업을 수행하려면 서비스 역할이 부여한 권한이 서비스에 있어야 합니다. Mary는 서비스에 역할을 전달할 수 있는 권한을 가지고 있지 않습니다.
```
User: arn:aws:iam::123456789012:user/marymajor is not authorized to perform: iam:PassRole
```
이 경우, Mary가 `iam:PassRole`작업을 수행할 수 있도록 Mary의 정책을 업데이트해야 합니다.
도움이 필요한 경우 AWS 관리자에게 문의하세요. 관리자는 로그인 자격 증명을 제공한 사람입니다.
## 내 AWS 계정 외부의 사람이 내 Lambda 리소스에 액세스할 수 있게 허용하기를 원합니다.
다른 계정의 사용자 또는 조직 외부의 사람이 리소스에 액세스할 때 사용할 수 있는 역할을 생성할 수 있습니다. 역할을 수임할 신뢰할 수 있는 사람을 지정할 수 있습니다. 리소스 기반 정책 또는 액세스 제어 목록(ACL)을 지원하는 서비스의 경우, 이러한 정책을 사용하여 다른 사람에게 리소스에 대한 액세스 권한을 부여할 수 있습니다.
자세히 알아보려면 다음을 참조하세요.
+ Lambda에서 이러한 기능을 지원하는지 여부를 알아보려면 [AWS Lambda에서 IAM을 사용하는 방식](security_iam_service-with-iam.md) 단원을 참조하세요.
+ 소유하고 있는 AWS 계정의 리소스에 대한 액세스 권한을 제공하는 방법을 알아보려면 *IAM 사용 설명서*의 [자신이 소유한 다른 AWS 계정의 IAM 사용자에 대한 액세스 권한 제공](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles_common-scenarios_aws-accounts.html)을 참조하세요.
+ 리소스에 대한 액세스 권한을 서드 파티 AWS 계정에게 제공하는 방법을 알아보려면 *IAM 사용 설명서*의 [서드 파티가 소유한 AWS 계정에 대한 액세스 제공](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles_common-scenarios_third-party.html)을 참조하세요.
+ 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)를 참조하세요.
# Lambda 함수 및 계층에 대한 거버넌스 전략 생성
서버리스 클라우드 네이티브 애플리케이션을 빌드하고 배포하려면 적절한 거버넌스 및 가드레일을 통해 민첩성과 시장 출시 속도를 높여야 합니다. 비즈니스 수준의 우선순위를 설정합니다. 민첩성을 최우선으로 강조하거나 거버넌스, 가드레일 및 제어를 통한 위험 회피를 강조할 수 있습니다. 소프트웨어 개발 라이프사이클에서 민첩성과 가드레일의 균형을 맞출 때 현실적으로 '둘 중 하나'의 전략이 아니라 '둘 모두'를 고려해야 합니다. 이러한 요구 사항이 회사 라이프사이클의 어느 단계에 속하든, 프로세스와 도구 체인의 구현 요구 사항으로 거버넌스 기능이 포함될 가능성이 큽니다.
다음은 조직에서 Lambda에 대해 구현할 수 있는 거버넌스 제어의 몇 가지 예제입니다.
+ Lambda 함수는 공개적으로 액세스할 수 없어야 합니다.
+ Lambda 함수는 VPC에 연결되어야 합니다.
+ Lambda 함수는 더 이상 사용되지 않는 런타임을 사용해서는 안 됩니다.
+ Lambda 함수는 필수 태그 세트로 태그를 지정해야 합니다.
+ Lambda 계층은 조직 외부에서 액세스할 수 없어야 합니다.
+ 보안 그룹이 연결된 Lambda 함수에는 함수와 보안 그룹 간에 일치하는 태그가 있어야 합니다.
+ 연결된 계층이 있는 Lambda 함수는 승인된 버전을 사용해야 합니다.
+ Lambda 환경 변수는 고객 관리형 키로 저장 시 암호화되어야 합니다.
다음 다이어그램은 소프트웨어 개발 및 배포 프로세스 전반에 걸쳐 제어 및 정책을 구현하는 심층 거버넌스 전략의 예제입니다.
![\[Governance strategy that uses AWS CloudFormation Guard, AWS Config, and Amazon Inspector.\]](http://docs.aws.amazon.com/ko_kr/lambda/latest/dg/images/governance-concepts.png)
다음 주제에서는 스타트업과 엔터프라이즈 모두를 위해 조직에서 Lambda 함수를 개발하고 배포하기 위한 제어를 구현하는 방법을 설명합니다. 조직에 관련 도구가 이미 있을 수도 있습니다. 다음 주제에서는 이러한 제어에 대한 모듈식 접근 방식을 사용하므로 실제로 필요한 구성 요소를 선택할 수 있습니다.
**Topics**
+ [
# AWS CloudFormation Guard를 사용하는 Lambda의 사전 예방적 제어
](governance-cloudformation-guard.md)
+ [
# AWS Config를 사용하여 Lambda에 대한 예방적 제어 구현
](governance-config.md)
+ [
# AWS Config를 사용하여 규정 미준수 Lambda 배포 및 구성 감지
](governance-config-detection.md)
+ [
# AWS Signer를 사용하여 Lambda 코드 서명
](governance-code-signing.md)
+ [
# Amazon Inspector를 사용하여 Lambda에 대한 보안 평가 자동화
](governance-code-scanning.md)
+ [
# Lambda 보안 및 규정 준수를 위한 관찰성 구현
](governance-observability.md)
# AWS CloudFormation Guard를 사용하는 Lambda의 사전 예방적 제어
[AWS CloudFormation Guard](https://docs.aws.amazon.com/cfn-guard/latest/ug/what-is-guard.html)는 오픈 소스, 범용, 코드형 정책 평가 도구입니다. 정책 규칙을 기준으로 코드형 인프라(IaC) 템플릿 및 서비스 구성을 검증함으로써 예방적 거버넌스 및 규정 준수를 위해 사용할 수 있습니다. 이러한 규칙은 팀 또는 조직의 요구 사항에 따라 사용자 지정할 수 있습니다. Lambda 함수의 경우 Guard 규칙을 사용하여 Lambda 함수를 생성 또는 업데이트하는 동안 필요한 필수 속성 설정을 정의함으로써 리소스 생성 및 구성 업데이트를 제어할 수 있습니다.
규정 준수 관리자는 Lambda 함수를 배포하고 업데이트하는 데 필요한 제어 및 거버넌스 정책 목록을 정의합니다. 플랫폼 관리자는 코드 리포지토리가 포함된 사전 커밋 검증 웹후크로 CI/CD 파이프라인에서 제어를 구현하고, 개발자에게 로컬 워크스테이션에서 템플릿 및 코드를 검증하기 위한 명령줄 도구를 제공합니다. 개발자는 코드를 작성하고 명령줄 도구를 사용해 템플릿을 검증한 후 리포지토리에 코드를 커밋합니다. 그러면 리포지토리를 AWS 환경에 배포하기 전에 CI/CD 파이프라인을 통해 코드가 자동으로 검증됩니다.
Guard를 사용하면 다음과 같이 도메인별 언어로 [규칙을 작성](https://docs.aws.amazon.com/cfn-guard/latest/ug/writing-rules.html)하고 제어를 구현할 수 있습니다.
![\[Guard rules include resource type, property name, operator, expression value, and optional comment\]](http://docs.aws.amazon.com/ko_kr/lambda/latest/dg/images/governance-cloudformation-guard.png)
예를 들어 개발자가 최신 런타임만 선택하려고 한다고 가정합니다. 두 가지 정책을 지정할 수 있습니다. 하나는 이미 지원이 중단된 [런타임](lambda-runtimes.md)을 식별하는 정책이고 다른 하나는 곧 지원 중단 예정인 런타임을 식별하는 정책입니다. 이를 위해 다음 `etc/rules.guard` 파일을 작성할 수 있습니다.
```
let lambda_functions = Resources.*[
Type == "AWS::Lambda::Function"
]
rule lambda_already_deprecated_runtime when %lambda_functions !empty {
%lambda_functions {
Properties {
when Runtime exists {
Runtime !in ["dotnetcore3.1", "nodejs12.x", "python3.6", "python2.7", "dotnet5.0", "dotnetcore2.1", "ruby2.5", "nodejs10.x", "nodejs8.10", "nodejs4.3", "nodejs6.10", "dotnetcore1.0", "dotnetcore2.0", "nodejs4.3-edge", "nodejs"] <>
}
}
}
}
rule lambda_soon_to_be_deprecated_runtime when %lambda_functions !empty {
%lambda_functions {
Properties {
when Runtime exists {
Runtime !in ["nodejs16.x", "nodejs14.x", "python3.7", "java8", "dotnet7", "go1.x", "ruby2.7", "provided"] <>
}
}
}
}
```
이제 Lambda 함수를 정의하는 다음과 같은 `iac/lambda.yaml` CloudFormation 템플릿을 작성한다고 가정합니다.
```
Fn:
Type: AWS::Lambda::Function
Properties:
Runtime: python3.7
CodeUri: src
Handler: fn.handler
Role: !GetAtt FnRole.Arn
Layers:
- arn:aws:lambda:us-east-1:111122223333:layer:LambdaInsightsExtension:35
```
Guard 유틸리티를 [설치](https://docs.aws.amazon.com/cfn-guard/latest/ug/setting-up.html)한 후 템플릿을 검증합니다.
```
cfn-guard validate --rules etc/rules.guard --data iac/lambda.yaml
```
출력은 다음과 같습니다.
```
lambda.yaml Status = FAIL
FAILED rules
rules.guard/lambda_soon_to_be_deprecated_runtime
---
Evaluating data lambda.yaml against rules rules.guard
Number of non-compliant resources 1
Resource = Fn {
Type = AWS::Lambda::Function
Rule = lambda_soon_to_be_deprecated_runtime {
ALL {
Check = Runtime not IN ["nodejs16.x","nodejs14.x","python3.7","java8","dotnet7","go1.x","ruby2.7","provided"] {
ComparisonError {
Message = Lambda function is using a runtime that is targeted for deprecation.
Error = Check was not compliant as property [/Resources/Fn/Properties/Runtime[L:88,C:15]] was not present in [(resolved, Path=[L:0,C:0] Value=["nodejs16.x","nodejs14.x","python3.7","java8","dotnet7","go1.x","ruby2.7","provided"])]
}
PropertyPath = /Resources/Fn/Properties/Runtime[L:88,C:15]
Operator = NOT IN
Value = "python3.7"
ComparedWith = [["nodejs16.x","nodejs14.x","python3.7","java8","dotnet7","go1.x","ruby2.7","provided"]]
Code:
86. Fn:
87. Type: AWS::Lambda::Function
88. Properties:
89. Runtime: python3.7
90. CodeUri: src
91. Handler: fn.handler
}
}
}
}
```
Guard를 사용하면 개발자가 로컬 개발자 워크스테이션에서 조직이 허용하는 런타임을 사용하도록 템플릿을 업데이트해야 한다는 사실을 확인할 수 있습니다. 코드 리포지토리를 커밋하고 이후 CI/CD 파이프라인 내에서 검사에 실패하기 전에 확인할 수 있습니다. 따라서 개발자는 규정을 준수하는 템플릿을 개발하고 비즈니스 가치를 전달하는 코드를 작성하는 데 시간을 더 할애하는 방법에 대한 피드백을 받을 수 있습니다. 이 제어는 배포 전에 로컬 개발자 워크스테이션, 사전 커밋 검증 웹후크 및/또는 CI/CD 파이프라인에 적용할 수 있습니다.
## 경고
AWS Serverless Application Model(AWS SAM) 템플릿을 사용하여 Lambda 함수를 정의하는 경우 다음과 같이 `AWS::Serverless::Function` 리소스 유형을 검색하도록 Guard 규칙을 업데이트해야 합니다.
```
let lambda_functions = Resources.*[
Type == "AWS::Serverless::Function"
]
```
또한 Guard에서는 리소스 정의에 속성을 포함한다고 예상합니다. 한편, AWS SAM 템플릿을 사용하면 별도의 [글로벌](https://docs.aws.amazon.com/serverless-application-model/latest/developerguide/sam-specification-template-anatomy-globals.html) 섹션에서 속성을 지정할 수 있습니다. 글로벌 섹션에 정의된 속성은 Guard 규칙으로 검증되지 않습니다.
Guard 문제 해결 [설명서에](https://docs.aws.amazon.com/cfn-guard/latest/ug/troubleshooting.html) 설명된 대로, Guard에서는 짧은 양식의 내장 함수(예: `!GetAtt` 또는 `!Sub`)를 지원하지 않으며, 대신 확장된 양식(`Fn::GetAtt` 및 `Fn::Sub`)을 사용해야 합니다. ([이전 예제](#guard-iac-yaml)에서는 역할 속성을 평가하지 않으므로 단순한 설명을 위해 짧은 양식의 내장 함수를 사용했습니다.)
# AWS Config를 사용하여 Lambda에 대한 예방적 제어 구현
가능하면 개발 프로세스 초기에 서버리스 애플리케이션의 규정 준수를 보장하는 것이 중요합니다. 이 주제에서는 [AWS Config](https://docs.aws.amazon.com/config/latest/developerguide/WhatIsConfig.html)를 사용하여 사전 예방적 제어를 구현하는 방법을 다룹니다. 이를 통해 개발 프로세스 초기에 규정 준수 검사를 구현하고 CI/CD 파이프라인에서 동일한 제어를 구현할 수 있습니다. 또한 AWS 계정 전체에서 제어를 일관되게 적용할 수 있도록 중앙에서 관리되는 규칙 리포지토리에서 제어를 표준화합니다.
예를 들어 규정 준수 관리자가 모든 Lambda 함수에 AWS X-Ray 추적 기능을 포함하는 요구 사항을 정의한다고 가정합니다. AWS Config의 사전 예방 모드를 사용하면 배포 전에 Lambda 함수 리소스에서 규정 준수 검사를 실행하여 잘못 구성된 Lambda 함수를 배포할 위험을 줄이고 코드형 인프라 템플릿에서 피드백을 더 빠르게 제공하여 개발자의 시간을 절약할 수 있습니다. 다음은 AWS Config를 사용하는 사전 예방적 제어의 흐름을 시각화한 것입니다.
![\[CloudFormation requests must pass AWS Config rules before provisioning.\]](http://docs.aws.amazon.com/ko_kr/lambda/latest/dg/images/governance-config-1.png)
모든 Lambda 함수에 추적 기능이 활성화되어 있어야 하는 요구 사항을 고려합니다. 이에 대한 응답으로 플랫폼 팀은 모든 계정에서 사전 예방적으로 특정 AWS Config 규칙을 실행해야 할 필요성을 식별합니다. 이 규칙은 구성된 X-Ray 트레이싱 구성이 없는 모든 Lambda 함수에 규정 미준수 리소스로 플래그를 지정합니다. 팀은 규칙을 개발하고, 이를 [적합성 팩](https://docs.aws.amazon.com/config/latest/developerguide/conformance-packs.html)으로 패키징한 후, 조직의 모든 계정이 이러한 제어를 균일하게 적용하도록 모든 AWS 계정에 적합성 팩을 배포합니다. 다음 형식을 사용하는 AWS CloudFormation Guard 2.x.x 구문으로 규칙을 작성할 수 있습니다.
```
rule name when condition { assertion }
```
다음은 Lambda 함수에 트레이싱 기능이 활성화되어 있는지 확인하는 샘플 Guard 규칙입니다.
```
rule lambda_tracing_check {
when configuration.tracingConfig exists {
configuration.tracingConfig.mode == "Active"
}
}
```
플랫폼 팀은 모든 AWS CloudFormation 배포에서 사전 생성 또는 업데이트 [후크](https://docs.aws.amazon.com/cloudformation-cli/latest/userguide/hooks-structure.html)를 간접 호출하도록 요구하여 추가 조치를 수행합니다. 이 후크를 개발하고 파이프라인을 구성하며 규정 준수 규칙의 중앙 집중식 제어를 강화하고 모든 배포에서 일관된 적용을 유지하는 일은 플랫폼 팀의 책임입니다. 후크를 개발, 패키징 및 등록하려면 CloudFormation 명령줄(CFN-CLI) 설명서의 [AWS CloudFormation 후크 개발](https://docs.aws.amazon.com/cloudformation-cli/latest/hooks-userguide/hooks-develop.html)을 참조하세요. [CloudFormation CLI](https://docs.aws.amazon.com/cloudformation-cli/latest/userguide/initiating-hooks-project-python.html)를 사용하여 후크 프로젝트를 생성할 수 있습니다.
```
cfn init
```
이 명령은 후크 프로젝트에 대한 몇 가지 기본 정보를 요청하고 다음 파일이 포함된 프로젝트를 생성합니다.
```
README.md
.json
rpdk.log
src/handler.py
template.yml
hook-role.yaml
```
후크 개발자인 경우 `.json` 구성 파일에 원하는 대상 리소스 유형을 추가해야 합니다. 아래 구성에서는 CloudFormation을 사용하여 Lambda 함수를 생성하기 전에 후크가 실행되도록 구성되어 있습니다. `preUpdate` 및 `preDelete` 작업에도 유사한 핸들러를 추가할 수 있습니다.
```
"handlers": {
"preCreate": {
"targetNames": [
"AWS::Lambda::Function"
],
"permissions": []
}
}
```
또한 CloudFormation 후크가 AWS Config API를 직접 호출할 수 있는 적절한 권한을 보유하는지도 확인해야 합니다. `hook-role.yaml`이라는 역할 정의 파일을 업데이트하여 이 작업을 수행할 수 있습니다. 역할 정의 파일에는 기본적으로 다음과 같은 신뢰 정책이 있으며, 이를 통해 CloudFormation이 역할을 수임할 수 있습니다.
```
AssumeRolePolicyDocument:
Version: '2012-10-17'
Statement:
- Effect: Allow
Principal:
Service:
- hooks.cloudformation.amazonaws.com
- resources.cloudformation.amazonaws.com
```
이 후크가 구성 API를 직접 호출하도록 허용하려면 정책 명령에 다음 권한을 추가해야 합니다. 그런 다음, `cfn submit` 명령을 사용하여 후크 프로젝트를 제출합니다. 그러면 CloudFormation에서 필요한 권한을 가진 역할을 자동으로 생성합니다.
```
Policies:
- PolicyName: HookTypePolicy
PolicyDocument:
Version: '2012-10-17'
Statement:
- Effect: Allow
Action:
- "config:Describe*"
- "config:Get*"
- "config:List*"
- "config:SelectResourceConfig"
Resource: "*
```
다음으로 `src/handler.py` 파일에 Lambda 함수를 작성해야 합니다. 이 파일에는 프로젝트 시작 시 이름이 `preCreate`, `preUpdate`, `preDelete`인 메서드가 이미 생성되어 있습니다. AWS SDK for Python (Boto3)을 사용하여 사전 예방적 모드에서 AWS Config `StartResourceEvaluation` API를 직접 호출하는 재사용 가능한 공통 함수를 작성하는 것을 목표로 합니다. 이 API 직접 호출은 리소스 속성을 입력으로 사용하고 규칙 정의를 기준으로 리소스를 평가합니다.
```
def validate_lambda_tracing_config(resource_type, function_properties: MutableMapping[str, Any]) -> ProgressEvent:
LOG.info("Fetching proactive data")
config_client = boto3.client('config')
resource_specs = {
'ResourceId': 'MyFunction',
'ResourceType': resource_type,
'ResourceConfiguration': json.dumps(function_properties),
'ResourceConfigurationSchemaType': 'CFN_RESOURCE_SCHEMA'
}
LOG.info("Resource Specifications:", resource_specs)
eval_response = config_client.start_resource_evaluation(EvaluationMode='PROACTIVE', ResourceDetails=resource_specs, EvaluationTimeout=60)
ResourceEvaluationId = eval_response.ResourceEvaluationId
compliance_response = config_client.get_compliance_details_by_resource(ResourceEvaluationId=ResourceEvaluationId)
LOG.info("Compliance Verification:", compliance_response.EvaluationResults[0].ComplianceType)
if "NON_COMPLIANT" == compliance_response.EvaluationResults[0].ComplianceType:
return ProgressEvent(status=OperationStatus.FAILED, message="Lambda function found with no tracing enabled : FAILED", errorCode=HandlerErrorCode.NonCompliant)
else:
return ProgressEvent(status=OperationStatus.SUCCESS, message="Lambda function found with tracing enabled : PASS.")
```
이제 사전 생성 후크의 핸들러에서 공통 함수를 직접 호출할 수 있습니다. 다음은 핸들러 예제입니다.
```
@hook.handler(HookInvocationPoint.CREATE_PRE_PROVISION)
def pre_create_handler(
session: Optional[SessionProxy],
request: HookHandlerRequest,
callback_context: MutableMapping[str, Any],
type_configuration: TypeConfigurationModel
) -> ProgressEvent:
LOG.info("Starting execution of the hook")
target_name = request.hookContext.targetName
LOG.info("Target Name:", target_name)
if "AWS::Lambda::Function" == target_name:
return validate_lambda_tracing_config(target_name,
request.hookContext.targetModel.get("resourceProperties")
)
else:
raise exceptions.InvalidRequest(f"Unknown target type: {target_name}")
```
이 단계 이후에 후크를 등록하고 모든 AWS Lambda 함수 생성 이벤트를 수신하도록 구성할 수 있습니다.
개발자가 Lambda를 사용하여 서버리스 마이크로서비스를 위한 코드형 인프라(IaC) 템플릿을 준비합니다. 이 준비 작업에는 내부 표준을 준수한 후 템플릿을 로컬에서 테스트하고 리포지토리에 커밋하는 작업이 포함됩니다. 다음은 예제 IaC 템플릿입니다.
```
MyLambdaFunction:
Type: 'AWS::Lambda::Function'
Properties:
Handler: index.handler
Role: !GetAtt LambdaExecutionRole.Arn
FunctionName: MyLambdaFunction
Code:
ZipFile: |
import json
def handler(event, context):
return {
'statusCode': 200,
'body': json.dumps('Hello World!')
}
Runtime: python3.14
TracingConfig:
Mode: PassThrough
MemorySize: 256
Timeout: 10
```
CI/CD 프로세스의 일부로 CloudFormation 템플릿이 배포되면 CloudFormation 서비스는 `AWS::Lambda::Function` 리소스 유형을 프로비저닝하기 바로 전에 사전 생성 또는 업데이트 후크를 간접 호출합니다. 후크는 사전 예방적 모드에서 실행되는 AWS Config 규칙을 활용하여 Lambda 함수 구성에 필수 트레이싱 구성이 포함되어 있는지 확인합니다. 후크의 응답에 따라 다음 단계가 결정됩니다. 규정을 준수하는 경우 후크는 성공 신호를 보내고 CloudFormation은 리소스 프로비저닝을 진행합니다. 그렇지 않으면 CloudFormation 스택 배포가 실패하고 파이프라인이 즉시 중단되며 시스템은 후속 검토를 위해 세부 정보를 기록합니다. 규정 준수 알림이 관련 이해관계자에게 전송됩니다.
CloudFormation 콘솔에서 후크 성공 또는 실패 정보를 찾을 수 있습니다.
![\[Hook success/fail information in the CloudFormation console\]](http://docs.aws.amazon.com/ko_kr/lambda/latest/dg/images/governance-config-2.png)
CloudFormation 후크에 대해 로그가 활성화된 경우 후크 평가 결과를 캡처할 수 있습니다. 다음은 실패 상태의 후크에 대한 샘플 로그로, Lambda 함수에서 X-Ray가 활성화되지 않았음을 나타냅니다.
![\[Sample log for a hook with a failed status\]](http://docs.aws.amazon.com/ko_kr/lambda/latest/dg/images/governance-config-3.png)
개발자가 IaC를 변경하여 `TracingConfig Mode` 값을 `Active`로 업데이트하고 다시 배포하도록 선택하면 후크가 성공적으로 실행되고 스택에서 Lambda 리소스 생성을 진행합니다.
![\[CloudFormation console shows successful resource deployment\]](http://docs.aws.amazon.com/ko_kr/lambda/latest/dg/images/governance-config-4.png)
이렇게 하면 AWS 계정에서 서버리스 리소스를 개발하고 배포할 때 AWS Config에서 사전 예방적 모드로 예방 제어를 구현할 수 있습니다. AWS Config 규칙을 CI/CD 파이프라인에 통합하면 활성 트레이싱 구성이 없는 Lambda 함수와 같이 규정 미준수 리소스 배포를 식별하고 선택적으로 차단할 수 있습니다. 이렇게 하면 최신 거버넌스 정책을 준수하는 리소스만 AWS 환경에 배포할 수 있습니다.
# AWS Config를 사용하여 규정 미준수 Lambda 배포 및 구성 감지
[선제적 평가](governance-config.md) 외에도 AWS Config에서는 거버넌스 정책을 준수하지 않는 리소스 배포 및 구성을 사후 대응적으로 감지할 수 있습니다. 이 기능은 조직이 새로운 모범 사례를 학습하고 구현함에 따라 거버넌스 정책도 발전하기 때문에 중요합니다.
Lambda 함수를 배포하거나 업데이트할 때 완전히 새로운 정책을 설정하는 시나리오를 고려합니다. 모든 Lambda 함수는 항상 승인된 특정 Lambda 계층 버전을 사용해야 합니다. 계층 구성을 위해 새 함수 또는 업데이트된 함수를 모니터링하도록 AWS Config를 구성할 수 있습니다. AWS Config에서 승인된 계층 버전을 사용하지 않는 함수를 탐지하면 해당 함수에 비준수 리소스로 플래그를 지정합니다. 선택적으로 AWS Systems Manager 자동화 문서를 사용하여 수정 조치를 지정함으로써 리소스를 자동으로 수정하도록 AWS Config를 구성할 수 있습니다. 예를 들어, AWS SDK for Python (Boto3)을 사용하여 Python에서 승인된 계층 버전을 가리키도록 규정 미준수 함수를 업데이트하는 자동화 문서를 작성할 수 있습니다. 이를 통해 AWS Config에서는 감지 및 수정 제어 기능을 모두 지원하며 규정 준수 관리를 자동화합니다.
이 프로세스를 세 가지 중요한 구현 단계로 나누어 보겠습니다.
![\[The three implementation phases are identify, notify, and deploy remediation.\]](http://docs.aws.amazon.com/ko_kr/lambda/latest/dg/images/governance-config-detective-1.png)
## 1단계: 액세스 리소스 식별
먼저 여러 계정을 AWS Config를 활성화하고 AWS Lambda 함수를 기록하도록 구성합니다. 그러면 AWS Config에서 Lambda 함수가 생성되거나 업데이트되는 시점을 관찰할 수 있습니다. 그런 다음, 특정 정책 위반을 검사하도록 [사용자 지정 정책 규칙](https://docs.aws.amazon.com/config/latest/developerguide/evaluate-config_develop-rules_cfn-guard.html)을 구성합니다. 이때 AWS CloudFormation Guard 구문을 사용합니다. Guard 규칙은 다음과 같은 일반적인 양식을 사용합니다.
```
rule name when condition { assertion }
```
다음은 계층이 이전 계층 버전으로 설정되지 않았는지 확인하는 샘플 규칙입니다.
```
rule desiredlayer when configuration.layers !empty {
some configuration.layers[*].arn != CONFIG_RULE_PARAMETERS.OldLayerArn
}
```
규칙 구문과 구조를 살펴봅니다.
+ **규칙 이름:** 제공된 예제의 규칙 이름은 `desiredlayer`입니다.
+ **조건:** 이 절은 규칙을 확인해야 하는 조건을 지정합니다. 제공된 예제에서 조건은 `configuration.layers !empty`입니다. 즉, 구성의 `layers` 속성이 비어 있지 않은 경우에만 리소스를 평가해야 합니다.
+ **어설션:** `when` 절 뒤의 어설션은 규칙이 검사하는 대상을 결정합니다. `some configuration.layers[*].arn != CONFIG_RULE_PARAMETERS.OldLayerArn` 어설션은 Lambda 계층 ARN이 `OldLayerArn` 값과 일치하지 않는지 확인합니다. 일치하지 않으면 어설션은 true이고 규칙은 통과됩니다. 그렇지 않으면 실패합니다.
`CONFIG_RULE_PARAMETERS`는 AWS Config 규칙으로 구성된 특별한 파라미터 세트입니다. 이 경우 `OldLayerArn`은 `CONFIG_RULE_PARAMETERS` 내부의 파라미터입니다. 이를 통해 사용자는 오래되었거나 더 이상 사용되지 않는 것으로 간주되는 특정 ARN 값을 제공할 수 있으며, 이후 이 규칙은 Lambda 함수가 이 오래된 ARN을 사용하고 있는지 확인합니다.
## 2단계: 시각화 및 설계
AWS Config에서는 구성 데이터를 수집하고 Amazon Simple Storage Service(Amazon S3) 버킷에 저장합니다. [Amazon Athena](https://aws.amazon.com/athena/)를 사용하여 S3 버킷에서 직접 이 데이터를 쿼리할 수 있습니다. Athena를 사용하면 조직 수준에서 이 데이터를 집계하여 모든 계정의 리소스 구성을 전체적으로 파악할 수 있습니다. 리소스 구성 데이터의 집계를 설정하려면 AWS 클라우드 운영 및 관리 블로그에서 [Visualizing AWS Config data using Athena and Amazon Quick](https://aws.amazon.com/blogs/mt/visualizing-aws-config-data-using-amazon-athena-and-amazon-quicksight/)을 참조하세요.
다음은 특정 계층 ARN을 사용하여 모든 Lambda 함수를 식별하기 위한 샘플 Athena 쿼리입니다.
```
WITH unnested AS (
SELECT
item.awsaccountid AS account_id,
item.awsregion AS region,
item.configuration AS lambda_configuration,
item.resourceid AS resourceid,
item.resourcename AS resourcename,
item.configuration AS configuration,
json_parse(item.configuration) AS lambda_json
FROM
default.aws_config_configuration_snapshot,
UNNEST(configurationitems) as t(item)
WHERE
"dt" = 'latest'
AND item.resourcetype = 'AWS::Lambda::Function'
)
SELECT DISTINCT
region as Region,
resourcename as FunctionName,
json_extract_scalar(lambda_json, '$.memorySize') AS memory_size,
json_extract_scalar(lambda_json, '$.timeout') AS timeout,
json_extract_scalar(lambda_json, '$.version') AS version
FROM
unnested
WHERE
lambda_configuration LIKE '%arn:aws:lambda:us-east-1:111122223333:layer:AnyGovernanceLayer:24%'
```
쿼리 결과는 다음과 같습니다.
![\[Query results in Athena console.\]](http://docs.aws.amazon.com/ko_kr/lambda/latest/dg/images/governance-config-detective-2.png)
조직 전체에서 집계된 AWS Config 데이터를 사용하여 [Amazon Quick](https://aws.amazon.com/quicksight/)을 통해 대시보드를 생성할 수 있습니다. Athena 결과를 Quick으로 가져오면 Lambda 함수가 계층 버전 규칙을 얼마나 잘 준수하는지 시각화할 수 있습니다. 이 대시보드는 규정 준수 및 규정 미준수 리소스를 강조 표시하므로, [다음 섹션](#governance-config-detective-implement)에 설명된 대로 적용 정책을 결정하는 데 도움이 됩니다. 다음 이미지는 조직 내 기능에 적용된 계층 버전의 분포를 보고하는 대시보드 예제입니다.
![\[Example Quick dashboard shows distribution of layer versions in Lambda functions.\]](http://docs.aws.amazon.com/ko_kr/lambda/latest/dg/images/governance-config-detective-3.png)
## 3단계: 구현 및 적용
이제 선택적으로 AWS SDK for Python (Boto3)에서 쓴 Python 스크립트로 작성한 Systems Manager 자동화 문서를 통해 [1단계](#governance-config-detective-identify)에서 생성한 계층 버전 규칙을 수정 조치와 페어링할 수 있습니다. 스크립트는 각 Lambda 함수에 대해 [UpdateFunctionConfiguration](https://docs.aws.amazon.com/lambda/latest/api/API_UpdateFunctionConfiguration.html) API 작업을 직접 호출하여 새 계층 ARN으로 함수 구성을 업데이트합니다. 또는 스크립트가 코드 리포지토리에 풀 요청을 제출하여 계층 ARN을 업데이트하도록 할 수도 있습니다. 그러면 향후 코드 배포 시에도 올바른 계층 ARN으로 업데이트됩니다.
# AWS Signer를 사용하여 Lambda 코드 서명
[AWS Signer](https://docs.aws.amazon.com/signer/latest/developerguide/Welcome.html)는 완전 관리형 코드 서명 서비스로, 디지털 서명을 대상으로 코드를 검증하여 코드가 변경되지 않고 신뢰할 수 있는 게시자가 제공한 코드인지 확인할 수 있습니다. AWS Signer는 AWS Lambda와 함께 사용하여 AWS 환경에 배포하기 전에 함수와 계층이 변경되지 않았는지 확인할 수 있습니다. 이를 통해 새 함수를 생성하거나 기존 함수를 업데이트하기 위해 보안 인증 정보를 획득했을 수 있는 악의적인 행위자로부터 조직을 보호할 수 있습니다.
Lambda 함수에 대한 코드 서명을 설정하려면 먼저 버전 관리가 활성화된 S3 버킷을 생성합니다. 그런 다음, AWS Signer에서 서명 프로파일을 생성하고 Lambda를 플랫폼으로 지정한 후 서명 프로파일의 유효 기간(일)을 지정합니다. 예시
```
Signer:
Type: AWS::Signer::SigningProfile
Properties:
PlatformId: AWSLambda-SHA384-ECDSA
SignatureValidityPeriod:
Type: DAYS
Value: !Ref pValidDays
```
그런 다음, 서명 프로파일을 사용하고 Lambda로 서명 구성을 생성합니다. 서명 구성에서 예상한 디지털 서명과 일치하지 않는 아티팩트를 찾은 경우 수행할 작업(경고(배포 허용) 또는 적용(배포 차단))을 지정해야 합니다. 아래 예제는 배포를 적용하고 차단하도록 구성되어 있습니다.
```
SigningConfig:
Type: AWS::Lambda::CodeSigningConfig
Properties:
AllowedPublishers:
SigningProfileVersionArns:
- !GetAtt Signer.ProfileVersionArn
CodeSigningPolicies:
UntrustedArtifactOnDeployment: Enforce
```
이제 신뢰할 수 없는 배포를 차단하도록 Lambda에서 AWS Signer를 구성했습니다. 기능 요청 코딩을 마쳤고 이제 함수를 배포할 준비가 되었다고 가정합니다. 첫 번째 단계는 적절한 종속 항목으로 코드를 압축한 다음, 생성한 서명 프로파일을 사용하여 아티팩트에 서명하는 것입니다. zip 아티팩트를 S3 버킷에 업로드한 다음, 서명 작업을 시작하면 이 작업을 수행할 수 있습니다.
```
aws signer start-signing-job \
--source 's3={bucketName=your-versioned-bucket,key=your-prefix/your-zip-artifact.zip,version=QyaJ3c4qa50LXV.9VaZgXHlsGbvCXxpT}' \
--destination 's3={bucketName=your-versioned-bucket,prefix=your-prefix/}' \
--profile-name your-signer-id
```
결과는 다음과 같습니다. 여기서 `jobId`는 대상 버킷에서 생성된 객체 및 접두사이며 `jobOwner`는 작업이 실행된 12자리 AWS 계정 ID입니다.
```
{
"jobId": "87a3522b-5c0b-4d7d-b4e0-4255a8e05388",
"jobOwner": "111122223333"
}
```
이제 서명된 S3 객체 및 생성한 코드 서명 구성을 사용하여 함수를 배포할 수 있습니다.
```
Fn:
Type: AWS::Serverless::Function
Properties:
CodeUri: s3://your-versioned-bucket/your-prefix/87a3522b-5c0b-4d7d-b4e0-4255a8e05388.zip
Handler: fn.handler
Role: !GetAtt FnRole.Arn
CodeSigningConfigArn: !Ref pSigningConfigArn
```
서명되지 않은 원래 소스 zip 아티팩트를 사용하여 함수 배포를 테스트할 수도 있습니다. 배포에 실패하고 다음 메시지가 표시됩니다.
```
Lambda cannot deploy the function. The function or layer might be signed using a signature that the client is not configured to accept. Check the provided signature for unsigned.
```
AWS Serverless Application Model(AWS SAM)을 사용하여 함수를 빌드하고 배포하는 경우 패키지 명령은 S3로의 zip 아티팩트 업로드를 처리하고 서명 작업을 시작한 후 서명된 아티팩트를 가져옵니다. 이를 위해 다음 명령과 파라미터를 사용합니다.
```
sam package -t your-template.yaml \
--output-template-file your-output.yaml \
--s3-bucket your-versioned-bucket \
--s3-prefix your-prefix \
--signing-profiles your-signer-id
```
AWS Signer는 계정에 배포된 zip 아티팩트가 배포 시 신뢰할 수 있는지 확인하는 데 도움이 됩니다. 위의 프로세스를 CI/CD 파이프라인에 포함하고 이전 주제에서 설명한 방법을 사용하여 모든 함수에 코드 서명 구성을 연결하도록 요구할 수 있습니다. Lambda 함수 배포에서 코드 서명을 사용하면 함수를 생성하거나 업데이트하기 위해 보안 인증 정보를 획득했을 수 있는 악의적인 행위자가 함수에 악성 코드를 삽입하는 것을 방지할 수 있습니다.
# Amazon Inspector를 사용하여 Lambda에 대한 보안 평가 자동화
[Amazon Inspector](https://aws.amazon.com/inspector/)는 알려진 소프트웨어 취약성 및 의도하지 않은 네트워크 노출이 있는 워크로드를 지속적으로 스캔하는 취약성 관리 서비스입니다. Amazon Inspector는 취약성을 설명하고, 영향을 받는 리소스를 식별하며, 취약성의 심각도를 평가하고, 해결 지침을 제공하는 조사 결과를 생성합니다.
Amazon Inspector 지원은 Lambda 함수 및 계층에 대한 지속적이고 자동화된 보안 취약성 평가를 제공합니다. Amazon Inspector는 Lambda에 대해 두 가지 유형의 스캔을 제공합니다.
+ **Lambda 표준 스캔(기본값):** Lambda 함수 및 해당 계층 내의 애플리케이션 종속 항목을 스캔하여 [패키지 취약성](https://docs.aws.amazon.com/inspector/latest/user/findings-types.html#findings-types-package)을 찾습니다.
+ **Lambda 코드 스캔**: 함수 및 계층에서 사용자 지정 애플리케이션 코드를 스캔하여 [코드 취약성](https://docs.aws.amazon.com/inspector/latest/user/findings-types.html#findings-types-code)을 찾습니다. Lambda 표준 스캔을 활성화하거나, Lambda 코드 스캔과 함께 Lambda 표준 스캔을 활성화할 수 있습니다.
Amazon Inspector를 활성화하려면 [Amazon Inspector 콘솔](https://console.aws.amazon.com/inspector/)로 이동하고 **설정** 섹션을 확장한 다음, **계정 관리**를 선택합니다. **계정** 탭에서 **활성화**를 선택한 다음, 스캔 옵션 중 하나를 선택합니다.
Amazon Inspector를 설정하는 동안 여러 계정에 대해 Amazon Inspector를 활성화하고 조직의 Amazon Inspector를 관리할 권한을 특정 계정에 위임할 수 있습니다. 활성화하는 동안 역할(`AWSServiceRoleForAmazonInspector2`)을 생성하여 Amazon Inspector에 권한을 부여해야 합니다. Amazon Inspector 콘솔에서는 원클릭 옵션을 사용하여 이 역할을 생성할 수 있습니다.
Lambda 표준 스캔의 경우 Amazon Inspector는 다음과 같은 경우에 Lambda 함수의 취약성 스캔을 시작합니다.
+ Amazon Inspector에서 기존 Lambda 함수를 발견하는 즉시
+ 새 Lambda 함수를 배포하는 경우
+ 기존 Lambda 함수 또는 해당 계층의 애플리케이션 코드 또는 종속성에 대한 업데이트를 배포하는 경우
+ Amazon Inspector가 새로운 일반적인 취약성 및 노출(CVE) 항목을 데이터베이스에 추가하고, 해당 CVE가 함수와 관련이 있는 경우
Lambda 코드 스캔의 경우 Amazon Inspector는 애플리케이션 코드의 전반적인 보안 규정 준수를 분석하는 자동 추론 및 기계 학습을 사용하여 Lambda 함수 애플리케이션 코드를 평가합니다. Amazon Inspector에서 Lambda 함수 애플리케이션 코드의 취약성을 탐지한 경우 Amazon Inspector는 상세한 **코드 취약성** 결과를 생성합니다. 가능한 탐지 목록은 [Amazon CodeGuru Detector Library](https://docs.aws.amazon.com/codeguru/detector-library/)를 참조하세요.
결과를 보려면 [Amazon Inspector 콘솔](https://console.aws.amazon.com/inspector/)로 이동합니다. **결과** 메뉴에서 **Lambda 함수 기준**을 선택하여 Lambda 함수에서 수행한 보안 스캔 결과를 표시합니다.
Lambda 함수를 표준 스캔에서 제외하려면 다음 키 값 페어를 사용하여 함수에 태그를 지정합니다.
+ `Key:InspectorExclusion`
+ `Value:LambdaStandardScanning`
Lambda 함수를 코드 스캔에서 제외하려면 다음 키 값 페어를 사용하여 함수에 태그를 지정합니다.
+ `Key:InspectorCodeExclusion`
+ `Value:``LambdaCodeScanning`
예를 들어, 다음 이미지에 표시된 대로, Amazon Inspector는 자동으로 취약성을 감지하고 결과를 **코드 취약성** 유형으로 분류합니다. 코드 종속 라이브러리가 아니라 함수의 코드에 취약성이 있음을 나타냅니다. 특정 함수 또는 여러 함수에 대한 이러한 세부 정보를 한 번에 확인할 수 있습니다.
![\[Amazon Inspector finds vulnerabilities in Lambda code.\]](http://docs.aws.amazon.com/ko_kr/lambda/latest/dg/images/governance-code-scanning-1.png)
이러한 각 결과를 자세히 살펴보고 문제를 해결하는 방법을 알아볼 수 있습니다.
![\[Amazon Inspector console displays code vulnerability details.\]](http://docs.aws.amazon.com/ko_kr/lambda/latest/dg/images/governance-code-scanning-2.png)
Lambda 함수를 작업할 때는 Lambda 함수의 이름 지정 규칙을 준수해야 합니다. 자세한 내용은 [Lambda 환경 변수 작업](configuration-envvars.md) 단원을 참조하십시오.
제안된 해결 방법을 수락할 경우 이에 따른 책임은 귀하에게 있습니다. 그러므로 제안된 해결 방법을 수락하기 전에 항상 검토하세요. 코드가 의도한 대로 작동하도록 제안된 해결 방법을 수정해야 할 수도 있습니다.
# Lambda 보안 및 규정 준수를 위한 관찰성 구현
AWS Config는 규정 미준수 AWS 서버리스 리소스를 찾아 수정하는 데 유용한 도구입니다. 서버리스 리소스에서 변경한 내용은 모두 AWS Config에 기록됩니다. 또한 AWS Config에서는 구성 스냅샷 데이터를 S3에 저장할 수 있습니다. Amazon Athena 및 Amazon Quick을 사용하여 대시보드를 생성하고 AWS Config 데이터를 볼 수 있습니다. [AWS Config를 사용하여 규정 미준수 Lambda 배포 및 구성 감지](governance-config-detection.md)에서는 Lambda 계층과 같은 특정 구성을 시각화하는 방법을 설명했습니다. 이 주제에서는 이러한 개념을 확장합니다.
## Lambda 구성에 대한 가시성
쿼리를 사용하여 AWS 계정 ID, 리전, AWS X-Ray 트레이싱 구성, VPC 구성, 메모리 크기, 런타임, 태그와 같은 중요한 구성을 가져올 수 있습니다. 다음은 Athena에서 이 정보를 가져오는 데 사용할 수 있는 샘플 쿼리입니다.
```
WITH unnested AS (
SELECT
item.awsaccountid AS account_id,
item.awsregion AS region,
item.configuration AS lambda_configuration,
item.resourceid AS resourceid,
item.resourcename AS resourcename,
item.configuration AS configuration,
json_parse(item.configuration) AS lambda_json
FROM
default.aws_config_configuration_snapshot,
UNNEST(configurationitems) as t(item)
WHERE
"dt" = 'latest'
AND item.resourcetype = 'AWS::Lambda::Function'
)
SELECT DISTINCT
account_id,
tags,
region as Region,
resourcename as FunctionName,
json_extract_scalar(lambda_json, '$.memorySize') AS memory_size,
json_extract_scalar(lambda_json, '$.timeout') AS timeout,
json_extract_scalar(lambda_json, '$.runtime') AS version
json_extract_scalar(lambda_json, '$.vpcConfig.SubnetIds') AS vpcConfig
json_extract_scalar(lambda_json, '$.tracingConfig.mode') AS tracingConfig
FROM
unnested
```
쿼리를 사용하여 Quick 대시보드를 빌드하고 데이터를 시각화할 수 있습니다. AWS 리소스 구성 데이터를 집계하고 Athena에서 테이블을 생성하며 Athena의 데이터를 기반으로 Quick 대시보드를 빌드하려면 AWS 클라우드 운영 및 관리 블로그에서 [Visualizing AWS Config data using Athena and Amazon Quick](https://aws.amazon.com/blogs/mt/visualizing-aws-config-data-using-amazon-athena-and-amazon-quicksight/)을 참조하세요. 특히 이 쿼리는 함수에 대한 태그 정보도 검색합니다. 이를 통해 특히 사용자 지정 태그를 사용하는 경우 워크로드와 환경에 대한 심층적인 인사이트를 얻을 수 있습니다.
![\[Query results in Quick dashboard\]](http://docs.aws.amazon.com/ko_kr/lambda/latest/dg/images/governance-observability-1.png)
수행할 수 있는 작업에 대한 자세한 내용은 이 주제의 후반부에 나오는 [관찰성 결과 처리](#governance-observability-addressing) 섹션을 참조하세요.
## Lambda 규정 준수에 대한 가시성
AWS Config에서 생성한 데이터를 사용하여 조직 수준의 대시보드를 만들어 규정 준수를 모니터링할 수 있습니다. 이를 통해 다음을 일관되게 추적하고 모니터링할 수 있습니다.
+ 규정 준수 점수별 규정 준수 팩
+ 규정 미준수 리소스별 규칙
+ 규정 준수 상태
![\[AWS Config console dashboard\]](http://docs.aws.amazon.com/ko_kr/lambda/latest/dg/images/governance-observability-2.png)
각 규칙을 확인하여 해당 규칙에 대한 규정 미준수 리소스를 식별합니다. 예를 들어, 조직에서 모든 Lambda 함수를 VPC와 연결하도록 규정하고 규정 준수를 식별하는 AWS Config 규칙을 배포한 경우 위 목록에서 `lambda-inside-vpc` 규칙을 선택할 수 있습니다.
![\[View non-compliant resources in AWS Config console\]](http://docs.aws.amazon.com/ko_kr/lambda/latest/dg/images/governance-observability-3.png)
수행할 수 있는 작업에 대한 자세한 내용은 아래 [관찰성 결과 처리](#governance-observability-addressing) 섹션을 참조하세요.
## Security Hub CSPM을 사용하여 Lambda 함수 경계에 대한 가시성 확보
![\[Diagram of example AWS Security Hub CSPM inputs for Lambda, such as resource policy, runtime, and code\]](http://docs.aws.amazon.com/ko_kr/lambda/latest/dg/images/governance-observability-4.png)
Lambda를 비롯한 AWS 서비스를 안전하게 사용할 수 있도록 AWS에서는 Foundational Security Best Practices v1.0.0을 도입했습니다. 이 모범 사례 세트는 강력한 보안 태세 유지의 중요성을 강조하면서 AWS 환경의 리소스 및 데이터 보안을 위한 명확한 지침을 제공합니다. AWS Security Hub CSPM는 통합 보안 및 규정 준수 센터를 제공하여 이를 보완합니다. 그리고 Amazon Inspector, AWS Identity and Access Management Access Analyzer 및 Amazon GuardDuty와 같은 여러 AWS 서비스의 보안 결과를 집계하고 구성하며 우선순위를 지정합니다.
AWS 조직 내에서 Security Hub CSPM, Amazon Inspector, IAM Access Analyzer 및 GuardDuty를 활성화한 경우 Security Hub CSPM은 이러한 서비스의 결과를 자동으로 집계합니다. 예를 들어 Amazon Inspector를 고려합니다. Security Hub CSPM을 사용하면 Lambda 함수의 코드 및 패키지 취약성을 효율적으로 식별할 수 있습니다. Security Hub CSPM 콘솔에서 하단의 **AWS 통합의 최근 분석 결과** 섹션으로 이동합니다. 여기에서 통합된 다양한 AWS 서비스에서 가져온 결과를 보고 분석할 수 있습니다.
![\[Security Hub CSPM console "Latest findings from AWS integrations" section\]](http://docs.aws.amazon.com/ko_kr/lambda/latest/dg/images/governance-observability-5.png)
세부 정보를 보려면 두 번째 열의 **결과 보기** 링크를 선택합니다. 여기에는 Amazon Inspector와 같이 제품별로 필터링된 결과 목록이 표시됩니다. 검색을 Lambda 함수로 제한하려면 `ResourceType`을 `AwsLambdaFunction`으로 설정합니다. 여기에는 Lambda 함수와 관련된 Amazon Inspector의 결과가 표시됩니다.
![\[Filter for Amazon Inspector results related to Lambda functions\]](http://docs.aws.amazon.com/ko_kr/lambda/latest/dg/images/governance-observability-6.png)
GuardDuty의 경우 의심스러운 네트워크 트래픽 패턴을 식별할 수 있습니다. 이러한 이상 현상은 Lambda 함수 내에 잠재적인 악성 코드가 존재함을 암시할 수 있습니다.
IAM Access Analyzer를 사용하면 정책, 특히 외부 엔터티에 대한 함수 액세스 권한을 부여하는 조건문이 있는 정책을 확인할 수 있습니다. 또한 IAM Access Analyzer는 Lambda API에서 [AddPermission](https://docs.aws.amazon.com/lambda/latest/api/API_AddPermission.html) 작업을 `EventSourceToken`과 함께 사용할 때 설정된 권한을 평가합니다.
## 관찰성 결과 처리
Lambda 함수에 사용할 수 있는 광범위한 구성과 고유한 요구 사항을 고려할 때 문제 해결을 위한 표준화된 자동화 솔루션이 모든 상황에 적합하지 않을 수도 있습니다. 또한 변경 사항은 다양한 환경에서 다르게 구현됩니다. 호환되지 않는 구성이 있으면 다음 지침을 고려합니다.
1. **태그 지정 전략**
포괄적인 태그 지정 전략을 구현하는 것이 좋습니다. 각 Lambda 함수에는 다음과 같은 주요 정보로 태그를 지정해야 합니다.
+ **소유자:** 함수를 담당하는 사람 또는 팀.
+ **환경:** 프로덕션, 스테이징, 개발 또는 샌드박스.
+ **애플리케이션:** 해당하는 경우 이 함수가 속한 더 넓은 컨텍스트.
1. **소유자 아웃리치**
주요 변경 사항(예: VPC 구성 조정)을 자동화하는 대신, 규정 미준수 함수의 소유자(소유자 태그로 식별됨)에게 사전에 연락하여 다음 중 하나를 수행할 수 있는 충분한 시간을 확보합니다.
+ Lambda 함수에서 규정 미준수 구성을 조정합니다.
+ 설명을 제공하고 예외를 요청하거나 규정 준수 표준을 세분화합니다.
1. **구성 관리 데이터베이스(CMDB) 유지 관리**
태그는 즉각적인 컨텍스트를 제공하는 반면, 중앙 집중식 CMDB를 유지 관리하면 더 심층적인 인사이트를 제공할 수 있습니다. 각 Lambda 함수, 해당 종속 항목 및 기타 중요한 메타데이터에 대한 보다 세분화된 정보를 보관할 수 있습니다. CMDB는 감사, 규정 준수 검사 및 함수 소유자 식별을 위한 매우 중요한 리소스입니다.
서버리스 인프라 환경이 지속적으로 발전함에 따라 모니터링에 대한 사전 예방적 접근 태세를 취해야 합니다. AWS Config, Security Hub CSPM 및 Amazon Inspector와 같은 도구를 사용하면 잠재적 이상 또는 규정 미준수 구성을 신속하게 식별할 수 있습니다. 하지만 도구만으로는 완전한 규정 준수나 최적의 구성을 보장할 수 없습니다. 이러한 도구를 잘 문서화된 프로세스 및 모범 사례와 함께 사용하는 것이 중요합니다.
+ **피드백 루프:** 문제 해결 단계를 수행한 후 피드백 루프가 있는지 확인합니다. 즉, 규정 미준수 리소스를 주기적으로 다시 확인하여 해당 리소스가 업데이트되었는지 또는 동일한 문제가 계속 발생하는지 확인해야 합니다.
+ **문서화:** 항상 관찰 내용, 수행한 작업, 허용된 예외 사항을 문서화합니다. 적절한 문서화는 감사 중에 도움이 될 뿐만 아니라 향후 규정 준수 및 보안 강화를 위한 프로세스를 개선하는 데도 도움이 됩니다.
+ **교육 및 인식:** 모든 이해관계자, 특히 Lambda 함수 소유자가 모범 사례, 조직 정책 및 규정 준수 규정을 주기적으로 교육받고 인지해야 합니다. 정기 워크숍, 웨비나 또는 교육 세션은 보안 및 규정 준수와 관련하여 모든 사람이 동일한 이해 기반을 갖추는 데 큰 도움이 될 수 있습니다.
결론적으로, 도구와 기술은 잠재적 문제를 감지하고 플래그를 지정하는 강력한 기능을 제공하지만, 이해, 소통, 교육 및 문서화와 같은 인적 요소도 여전히 중요합니다. 이 둘을 함께 활용하면 Lambda 기능 및 광범위한 인프라가 규정을 준수하고 안전하며 비즈니스 요구 사항에 맞게 최적화되도록 보장하는 강력한 이점을 제공합니다.
# AWS Lambda의 규정 준수 확인
타사 감사자는 여러 AWS Lambda 규정 준수 프로그램의 일환으로 AWS의 보안 및 규정 준수를 평가합니다. 여기에는 SOC, PCI, FedRAMP, HIPAA 등이 포함됩니다.
특정 규정 준수 프로그램 범위에 속하는 AWS 서비스의 목록은 [규정 준수 프로그램 제공 AWS 범위 내 서비스](https://aws.amazon.com/compliance/services-in-scope/)를 참조하세요. 일반 정보는 [AWS 규정 준수 프로그램](https://aws.amazon.com/compliance/programs/)을 참조하세요.
AWS Artifact를 사용하여 타사 감사 보고서를 다운로드할 수 있습니다. 자세한 내용은 [AWS 아티팩트의 보고서 다운로드](https://docs.aws.amazon.com/artifact/latest/ug/downloading-documents.html)를 참조하세요.
Lambda 사용 시 규정 준수 책임은 데이터의 민감도, 회사의 규정 준수 목표 및 관련 법률 및 규정에 따라 결정됩니다. 회사의 Lambda 함수가 규정 준수 요구 사항을 충족하도록 거버넌스 제어를 구현할 수 있습니다. 자세한 내용은 [Lambda 함수 및 계층에 대한 거버넌스 전략 생성](governance-concepts.md) 단원을 참조하십시오.
# AWS Lambda의 복원성
AWS 글로벌 인프라는 AWS 지역 및 가용 영역을 중심으로 구축됩니다. AWS 리전은 물리적으로 분리되고 격리된 다수의 가용 리전을 제공하며 이러한 가용 리전은 짧은 지연 시간, 높은 처리량 및 높은 중복성을 갖춘 네트워크에 연결되어 있습니다. 가용 영역을 사용하면 중단 없이 가용 영역 간에 자동으로 장애 조치가 이루어지는 애플리케이션 및 데이터베이스를 설계하고 운영할 수 있습니다. 가용 영역은 기존의 단일 또는 다중 데이터 센터 인프라보다 가용성, 내결함성, 확장성이 뛰어납니다.
AWS 리전 및 가용 영역에 대한 자세한 내용은 [AWS 글로벌 인프라](https://aws.amazon.com/about-aws/global-infrastructure/)를 참조하세요.
AWS 글로벌 인프라뿐만 아니라 Lambda도 데이터 복원력과 백업 요구 사항을 지원하는 다양한 기능을 제공합니다.
+ **버전 관리** – Lambda에서 버전 관리를 사용하여 함수 개발 시 그 코드와 구성을 저장할 수 있습니다. 별칭과 함께 버전 관리를 사용하여 블루/그린 및 롤링 배포를 수행할 수 있습니다. 자세한 내용은 [Lambda 함수 버전 관리](configuration-versions.md) 단원을 참조하세요.
+ **확장** – 함수가 이전 요청을 처리하는 동안 요청을 받으면 Lambda는 함수의 다른 인스턴스를 실행하여 늘어난 로드를 처리합니다. Lambda는 리전당 1,000개의 동시 실행을 처리할 수 있도록 자동으로 확장되며, 필요한 경우 [할당량](gettingstarted-limits.md)을 증가시킬 수 있습니다. 세부 정보는 [Lambda 함수 규모 조정 이행](lambda-concurrency.md)을 참조하세요.
+ **고가용성** – Lambda는 함수를 여러 가용 영역에서 실행하여 단일 영역 내 서비스 중단 발생 시 이벤트를 처리할 수 있도록 합니다. 계정의 VPC(Virtual Private Cloud)로 연결되도록 함수를 구성하는 경우에는 여러 가용 영역의 서브넷을 지정해 고가용성을 보장합니다. 자세한 내용은 [Lambda 함수에 Amazon VPC의 리소스에 대한 액세스 권한 부여](configuration-vpc.md) 단원을 참조하세요.
+ **예약 동시성** – 함수가 추가 요청을 처리할 수 있도록 항상 확장할 수 있게 해당 함수에 대한 동시성을 예약할 수 있습니다. 함수에 대해 예약 동시성을 설정하면 특정 수의 동시 호출까지 확장할 수 있습니다(이를 초과하지는 않음). 그러면 다른 함수가 가용 동시성을 모두 사용하여 요청을 놓치는 경우를 피할 수 있습니다. 자세한 내용은 [함수에 대해 예약된 동시성 구성](configuration-concurrency.md) 단원을 참조하세요.
+ **재시도** – 다른 서비스에 의해 트리거되는 호출의 서브셋과 비동기식 호출의 경우, Lambda는 재시도 간의 지연 시간을 두고 오류 시 재시도를 자동으로 수행합니다. 함수를 동기식으로 간접 호출하는 다른 클라이언트와 AWS 서비스에서 재시도를 수행합니다. 세부 정보는 [Lambda의 재시도 동작 이해](invocation-retries.md)을 참조하세요.
+ **배달 못한 편지 대기열** – 비동기식 호출의 경우 재시도가 모두 실패 시 배달 못한 편지 대기열로 요청을 전송하도록 Lambda를 구성할 수 있습니다. 배달 못한 편지 대기열은 문제 해결이나 재처리에 대한 이벤트를 수신하는 Amazon SNS 주제 또는 Amazon SQS 대기열입니다. 세부 정보는 [Dead Letter Queue(DLQ) 추가](invocation-async-retain-records.md#invocation-dlq)을 참조하세요.
# AWS Lambda의 인프라 보안
관리형 서비스인 AWS Lambda은 AWS 글로벌 네트워크 보안으로 보호됩니다. AWS 보안 서비스와 AWS의 인프라 보호 방법에 대한 자세한 내용은 [AWS 클라우드 보안](https://aws.amazon.com/security/)을 참조하세요. 인프라 보안에 대한 모범 사례를 사용하여 AWS 환경을 설계하려면 *보안 원칙 AWS Well‐Architected Framework*의 [인프라 보호](https://docs.aws.amazon.com/wellarchitected/latest/security-pillar/infrastructure-protection.html)를 참조하십시오.
AWS에서 게시한 API 호출을 사용하여 네트워크를 통해 Lambda에 액세스합니다. 고객은 다음을 지원해야 합니다.
+ Transport Layer Security(TLS) TLS 1.2는 필수이며 TLS 1.3을 권장합니다.
+ DHE(Ephemeral Diffie-Hellman) 또는 ECDHE(Elliptic Curve Ephemeral Diffie-Hellman)와 같은 완전 전송 보안(PFS)이 포함된 암호 제품군 Java 7 이상의 최신 시스템은 대부분 이러한 모드를 지원합니다.
# 퍼블릭 엔드포인트를 사용하여 워크로드 보호
퍼블릭 액세스가 가능한 워크로드에 대해 AWS에서는 특정 위험을 완화하는 데 도움이 될 수 있는 많은 기능과 서비스를 제공합니다. 이 섹션에서는 애플리케이션 사용자의 인증 및 권한 부여와 API 엔드포인트 보호를 다룹니다.
## 인증 및 권한 부여
인증은 자격 증명과 관련이 있으며, 권한 부여는 작업을 의미합니다. 인증을 사용하여 Lambda 함수를 간접 호출할 수 있는 사용자를 제어하고 이후 권한 부여를 사용하여 수행할 수 있는 작업을 제어합니다. 많은 애플리케이션에서 두 제어 메커니즘을 모두 관리하는 데 IAM으로도 충분합니다.
웹 또는 모바일 애플리케이션과 같은 외부 사용자를 포함하는 애플리케이션의 경우 [JSON 웹 토큰](https://jwt.io/introduction/)(JWT)을 사용하여 인증 및 권한 부여를 관리하는 것이 일반적입니다. 기존의 서버 기반 암호 관리와 달리 모든 요청에서 클라이언트로부터 JWT가 전달됩니다. 클라이언트에서 전달된 데이터를 사용하여 자격 증명 및 클레임을 확인하는 암호화를 사용한 보안 방법입니다. Lambda 기반 애플리케이션의 경우 이 방식을 사용하여 인증을 위해 중앙 서버에 의존하지 않고 각 API 엔드포인트에 대한 모든 직접 호출을 보안할 수 있습니다.
등록, 인증, 계정 복구 및 기타 일반적인 계정 관리 작업을 처리할 수 있는 사용자 디렉터리 서비스인 [Amazon Cognito를 사용하여 JWT를 구현](https://docs.aws.amazon.com/cognito/latest/developerguide/amazon-cognito-user-pools-using-tokens-with-identity-providers.html)할 수 있습니다. [Amplify Framework](https://docs.amplify.aws/start/getting-started/auth/q/integration/react)에서는 이 서비스를 프론트엔드 애플리케이션에 간편하게 통합할 수 있는 라이브러리를 제공합니다. [Auth0](https://auth0.com/)과 같은 서드파티 파트너 서비스를 고려할 수도 있습니다.
ID 제공업체 서비스의 중요한 보안 역할을 고려할 때 전문 도구를 사용하여 애플리케이션을 보호하는 것이 중요합니다. 인증 또는 권한 부여를 처리하기 위해 자체 서비스를 작성하는 방법은 권장되지 않습니다. 사용자 지정 라이브러리의 취약성은 워크로드 및 해당 데이터의 보안에 상당한 영향을 미칠 수도 있습니다.
## API 엔드포인트 보호
서버리스 애플리케이션의 경우 백엔드 애플리케이션을 공개적으로 지원하는 데 선호되는 방법은 Amazon API Gateway를 사용하는 것입니다. 이 경우 악의적인 사용자 또는 트래픽 급증으로부터 API를 보호할 수 있습니다.
API Gateway는 서버리스 개발자를 위한 두 가지 엔드포인트 유형, [REST API](https://docs.aws.amazon.com/apigateway/latest/developerguide/apigateway-rest-api.html) 및 [HTTP API](https://docs.aws.amazon.com/apigateway/latest/developerguide/http-api.html)를 제공합니다. 둘 다 Amazon Cognito, IAM 또는 [AWS Lambda 항목을 사용하는 권한 부여](https://docs.aws.amazon.com/apigateway/latest/developerguide/apigateway-use-lambda-authorizer.html)를 지원합니다. IAM 또는 Amazon Cognito를 사용하는 경우 수신 요청이 평가되고 필수 토큰이 누락되거나 잘못된 인증이 포함된 경우 요청이 거부됩니다. 이러한 요청에 대해서는 요금이 부과되지 않으며 스로틀링 할당량에 포함되지 않습니다.
인증되지 않은 API 경로는 퍼블릭 인터넷의 누구나 액세스할 수 있으므로 인증되지 않은 API의 사용을 제한하는 것이 좋습니다. 인증되지 않은 API를 사용해야 하는 경우 [서비스 거부](https://en.wikipedia.org/wiki/Denial-of-service_attack)(DoS) 공격과 같은 일반적인 위험으로부터 이러한 API를 보호해야 합니다. [ 이러한 API에 AWS WAF 항목을 적용](https://docs.aws.amazon.com/apigateway/latest/developerguide/apigateway-control-access-aws-waf.html)하면 SQL 명령어 삽입 및 크로스 사이트 스크립팅(XSS) 공격으로부터 애플리케이션을 보호할 수 있습니다. 또한 API Gateway는 API 키를 사용하는 경우 AWS 계정 수준 및 클라이언트별 수준에서 [ 스로틀링](https://docs.aws.amazon.com/apigateway/latest/developerguide/api-gateway-request-throttling.html)을 구현합니다.
많은 경우에 인증되지 않은 API에서 제공하는 기능은 대체 접근 방식으로 수행할 수 있습니다. 예를 들어 웹 애플리케이션에서 DynamoDB 테이블의 고객 리테일 매장 목록을 로그인하지 않은 사용자에게 제공할 수 있습니다. 이 요청은 프론트엔드 웹 애플리케이션 또는 URL 엔드포인트를 직접 호출하는 다른 소스에서 시작될 수 있습니다. 이 다이어그램에서는 세 가지 솔루션을 비교합니다.
![\[보안 운영 그림 5\]](http://docs.aws.amazon.com/ko_kr/lambda/latest/dg/images/security-ops-figure-5.png)
1. 인증되지 않은 이 API는 인터넷에 있는 모든 사용자가 직접 호출할 수 있습니다. 서비스 거부 공격으로 기본 테이블에서 API 스로틀링, Lambda 동시성 또는 DynamoDB 프로비저닝된 읽기 용량을 소진할 수 있습니다.
1. 적절한 [ Time-to-Live](https://docs.aws.amazon.com/AmazonCloudFront/latest/DeveloperGuide/Expiration.html)(TTL) 구성을 갖춘 API 엔드포인트 전면에 배치된 CloudFront 배포는 데이터를 가져오기 위한 기본 솔루션을 변경하지 않고도 DoS 공격에서 대부분의 트래픽을 흡수합니다.
1. 또는 거의 변경되지 않는 정적 데이터의 경우 CloudFront 배포에서 Amazon S3 버킷의 데이터를 지원할 수 있습니다.
# 코드 서명을 사용하여 Lambda로 코드 무결성 확인
코드 서명은 신뢰할 수 있는 코드만 Lambda 함수에 배포되도록 하는 데 도움이 됩니다. AWS Signer를 사용하여 함수에 대한 디지털 방식으로 서명된 코드 패키지를 생성할 수 있습니다. [함수에 코드 서명 구성을 추가](configuration-codesigning-create.md)하면 Lambda는 신뢰할 수 있는 소스가 모든 새 코드 배포를 서명했는지 확인합니다. 코드 서명 유효성 검사는 배포 시 실행되므로 함수 실행에는 영향을 주지 않습니다.
**중요**
코드 서명 구성은 서명되지 않은 코드의 새로운 배포만 방지합니다. 서명되지 않은 코드가 있는 기존 함수에 코드 서명 구성을 추가하는 경우 새 코드 패키지를 배포할 때까지 해당 코드가 계속 실행됩니다.
함수에 대한 코드 서명을 활성화하면 함수에 추가하는 모든 [계층](chapter-layers.md)도 허용된 서명 프로필로 서명되어야 합니다.
AWS Signer 사용 또는 AWS Lambda에 대한 코드 서명에 따른 추가 요금은 없습니다.
## 서명 검증
Lambda는 서명된 코드 패키지를 함수에 배포할 때 다음과 같은 검증을 수행합니다.
1. **무결성**: 코드 패키지가 서명된 이후 수정되지 않았는지 검증합니다. Lambda는 패키지의 해시를 서명의 해시와 비교합니다.
1. **만료**: 코드 패키지의 서명이 만료되지 않았는지 검증합니다.
1. **불일치**: 코드 패키지가 허용된 서명 프로필로 서명되었는지 검증합니다.
1. **해지**: 코드 패키지의 서명이 해지되지 않았는지 검증합니다.
코드 서명 구성을 생성할 때 [UntrustedArtifactOnDeployment](https://docs.aws.amazon.com/lambda/latest/api/API_CodeSigningPolicies.html#lambda-Type-CodeSigningPolicies-UntrustedArtifactOnDeployment) 파라미터를 사용하여 만료, 불일치 또는 해지 확인에 실패할 경우 Lambda가 어떻게 응답해야 하는지 지정할 수 있습니다. 다음 작업 중 하나를 선택할 수 있습니다.
+ `Warn`: 이것이 기본 설정입니다. Lambda는 코드 패키지의 배포를 허용하지만 경고를 발생시킵니다. Lambda는 새로운 Amazon CloudWatch 지표(`SignatureValidationErrors`)를 발생시키고 경고를 CloudTrail 로그에 저장합니다.
+ `Enforce` Lambda는 경고를 발생시키고(`Warn` 작업과 동일) 코드 패키지의 배포를 차단합니다.
**Topics**
+ [
## 서명 검증
](#config-codesigning-valid)
+ [
# Lambda에 대한 코드 서명 구성 생성
](configuration-codesigning-create.md)
+ [
# Lambda 코드 서명 구성에 대한 IAM 정책 구성
](config-codesigning-policies.md)
+ [
# 코드 서명 구성에 태그 사용
](tags-csc.md)
# Lambda에 대한 코드 서명 구성 생성
함수에 대한 코드 서명을 활성화하려면 *코드 서명 구성*을 생성하고 함수에 연결합니다. 코드 서명 구성은 허용된 서명 프로필의 목록과 유효성 검사가 실패한 경우 수행할 정책 작업을 정의합니다.
**참고**
컨테이너 이미지로 정의된 함수는 코드 서명을 지원하지 않습니다.
**Topics**
+ [
## 구성 사전 조건
](#config-codesigning-prereqs)
+ [
## 코드 서명 구성 생성
](#config-codesigning-config-console)
+ [
## 함수에 대한 코드 서명 활성화
](#config-codesigning-function-console)
## 구성 사전 조건
Lambda 함수에 대한 코드 서명을 구성하려면 먼저 AWS Signer를 사용하여 다음을 수행해야 합니다.
+ [서명 프로필](https://docs.aws.amazon.com/signer/latest/developerguide/signing-profiles.html)을 하나 이상 생성합니다.
+ 서명 프로필을 사용하여 [함수에 대한 서명된 코드 패키지를 생성](https://docs.aws.amazon.com/signer/latest/developerguide/lambda-workflow.html)합니다.
## 코드 서명 구성 생성
코드 서명 구성은 허용된 서명 프로필의 목록과 서명 검증 정책을 정의합니다.
**코드 서명 구성을 생성하려면(콘솔)**
1. Lambda 콘솔의 [코드 서명 구성 페이지](https://console.aws.amazon.com/lambda/home#/code-signing-configurations)를 엽니다.
1. **구성 생성**을 선택합니다.
1. **설명(Description)**에 구성을 설명하는 이름을 입력합니다.
1. **서명 프로필(Signing profiles)**에서 구성에 최대 20개의 서명 프로필을 추가합니다.
1. **서명 프로필 버전 ARN(Signing profile version ARN)**에서 프로필 버전의 Amazon 리소스 이름(ARN)을 선택하거나 ARN을 입력합니다.
1. 다른 서명 프로필을 추가하려면 **서명 프로필 추가(Add signing profiles)**를 선택합니다.
1. **서명 검증 정책(Signature validation policy)**에서 **경고(Warn)** 또는 **적용(Enforce)**을 선택합니다.
1. **구성 생성**을 선택합니다.
## 함수에 대한 코드 서명 활성화
함수에 대한 코드 서명을 활성화하려면 함수에 코드 서명 구성을 추가합니다.
**중요**
코드 서명 구성은 서명되지 않은 코드의 새로운 배포만 방지합니다. 서명되지 않은 코드가 있는 기존 함수에 코드 서명 구성을 추가하는 경우 새 코드 패키지를 배포할 때까지 해당 코드가 계속 실행됩니다.
**코드 서명 구성을 함수와 연결하려면(콘솔)**
1. Lambda 콘솔의 [함수 페이지](https://console.aws.amazon.com/lambda/home#/functions)를 엽니다.
1. 코드 서명을 활성화하려는 함수를 선택합니다.
1. **구성** 탭을 엽니다.
1. 아래로 스크롤하여 **코드 서명**을 선택합니다.
1. **편집**을 선택합니다.
1. **코드 서명 편집(Edit code signing)**에서 이 함수에 대한 코드 서명 구성을 선택합니다.
1. **저장**을 선택합니다.
# Lambda 코드 서명 구성에 대한 IAM 정책 구성
사용자에게 Lambda 코드 서명 API 작업에 액세스할 수 있는 권한을 부여하려면 하나 이상의 정책 설명을 사용자 정책에 연결합니다. 사용자 정책에 대한 자세한 내용은 단원을 참조하세요[Lambda에 대한 자격 증명 기반 IAM 정책](access-control-identity-based.md)
다음 예제 정책 설명은 코드 서명 구성을 생성, 업데이트 및 검색할 수 있는 권한을 부여합니다.
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Action": [
"lambda:CreateCodeSigningConfig",
"lambda:UpdateCodeSigningConfig",
"lambda:GetCodeSigningConfig"
],
"Resource": "*"
}
]
}
```
------
관리자는 `CodeSigningConfigArn` 조건 키를 사용하여 개발자가 함수를 생성하거나 업데이트하는 데 사용해야 하는 코드 서명 구성을 지정할 수 있습니다.
다음 예제 정책 설명에서는 함수를 생성할 수 있는 권한을 부여합니다. 정책 설명에는 허용되는 코드 서명 구성을 지정할 수 있는 `lambda:CodeSigningConfigArn` 조건이 포함되어 있습니다. [CodeSigningConfigArn](https://docs.aws.amazon.com/lambda/latest/api/API_CreateFunction.html#lambda-CreateFunction-request-CodeSigningConfigArn) 파라미터가 누락되었거나 조건의 값과 일치하지 않으면 Lambda는 `CreateFunction` API 요청을 차단합니다.
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement": [
{
"Sid": "AllowReferencingCodeSigningConfig",
"Effect": "Allow",
"Action": [
"lambda:CreateFunction"
],
"Resource": "*",
"Condition": {
"StringEquals": {
"lambda:CodeSigningConfigArn": "arn:aws:lambda:us-east-1:111122223333:code-signing-config:csc-0d4518bd353a0a7c6"
}
}
}
]
}
```
------
# 코드 서명 구성에 태그 사용
코드 서명 구성에 태그를 지정하여 리소스를 구성하고 관리할 수 있습니다. 태그는 AWS 서비스 전반에서 지원되는 리소스와 연결된 자유 형식의 키-값 페어입니다. 태그 사용 사례에 대한 자세한 내용은 *AWS 리소스에 태그 지정 및 Tag Editor 사용 설명서*의 [일반적인 태그 지정 전략](https://docs.aws.amazon.com//tag-editor/latest/userguide/best-practices-and-strats.html#tag-strategies)을 참조하세요.
AWS Lambda API를 사용하여 태그를 보고 업데이트할 수 있습니다. Lambda 콘솔에서 특정 코드 서명 구성을 관리하면서 태그를 보고 업데이트할 수도 있습니다.
**Topics**
+ [
## 태그 작업에 필요한 권한
](#csc-tags-required-permissions)
+ [
## Lambda 콘솔에서 태그 사용
](#tags-csc-console)
+ [
## AWS CLI에서 태그 사용
](#tags-csc-cli)
## 태그 작업에 필요한 권한
AWS Identity and Access Management(IAM) ID(사용자, 그룹 또는 역할)가 리소스의 태그를 읽거나 설정할 수 있도록 허용하려면 해당 권한을 부여합니다.
+ **lambda:ListTags** - 리소스에 태그가 있는 경우 리소스에서 `ListTags`를 직접적으로 호출해야 하는 모든 사람에게 이 권한을 부여합니다. 태그가 지정된 함수의 경우 `GetFunction`에도 이 권한이 필요합니다.
+ **lambda:TagResource** - `TagResource`를 직접적으로 호출하거나 생성 시 태그를 수행해야 하는 모든 사람에게 이 권한을 부여합니다.
선택적으로 리소스에 대한 `UntagResource` 직접 호출을 허용하도록 **lambda:UntagResource** 권한 부여를 고려하세요.
자세한 내용은 [Lambda에 대한 자격 증명 기반 IAM 정책](access-control-identity-based.md) 섹션을 참조하세요.
## Lambda 콘솔에서 태그 사용
Lambda 콘솔을 사용하여 태그가 있는 코드 서명 구성을 생성하고 , 기존 코드 서명 구성에 태그를 추가하고, 태그로 코드 서명 구성을 필터링할 수 있습니다.
**코드 서명 구성을 생성할 때 태그를 추가하려면 다음을 수행하세요.**
1. Lambda 콘솔에서 [코드 서명 구성](https://console.aws.amazon.com/lambda/home#/code-signing-configurations)을 엽니다.
1. 콘텐츠 창의 헤더에서 **구성 생성**을 선택합니다.
1. 콘텐츠 창 상단의 섹션에서 코드 서명 구성을 설정합니다. 코드 서명 구성에 대한 자세한 내용은 [코드 서명을 사용하여 Lambda로 코드 무결성 확인](configuration-codesigning.md) 섹션을 참조하세요.
1. **태그** 항목에서 **새로운 태그 추가**를 선택합니다.
1. **키** 필드에 태그 키를 입력합니다. 태그 지정 제한에 대한 자세한 내용은 *AWS 리소스에 태그 지정 및 Tag Editor 사용 설명서*의 [태그 이름 지정 제한 및 요구 사항](https://docs.aws.amazon.com//tag-editor/latest/userguide/best-practices-and-strats.html#id_tags_naming_best_practices)을 참조하세요.
1. **구성 생성**을 선택합니다.
**기존 코드 서명 구성에 태그를 추가하려면 다음을 수행하세요.**
1. Lambda 콘솔에서 [코드 서명 구성](https://console.aws.amazon.com/lambda/home#/code-signing-configurations)을 엽니다.
1. 코드 서명 구성의 이름을 선택합니다.
1. **세부 정보** 창 아래의 탭에서 **태그**를 선택합니다.
1. **태그 관리**를 선택합니다.
1. **새로운 태그 추가**를 선택합니다.
1. **키** 필드에 태그 키를 입력합니다. 태그 지정 제한에 대한 자세한 내용은 *AWS 리소스에 태그 지정 및 Tag Editor 사용 설명서*의 [태그 이름 지정 제한 및 요구 사항](https://docs.aws.amazon.com//tag-editor/latest/userguide/best-practices-and-strats.html#id_tags_naming_best_practices)을 참조하세요.
1. **저장**을 선택합니다.
**태그로 코드 서명 구성을 필터링하려면 다음을 수행하세요.**
1. Lambda 콘솔에서 [코드 서명 구성](https://console.aws.amazon.com/lambda/home#/code-signing-configurations)을 엽니다.
1. 검색 창을 선택합니다.
1. 드롭다운 목록에서 **태그** 부제목 아래에서 태그를 선택합니다.
1. **용도: “tag-name”**을 선택하여 이 키로 태그가 지정된 모든 코드 서명 구성을 보거나 **연산자**를 선택하여 값으로 추가 필터링할 수 있습니다.
1. 태그 키와 값의 조합으로 필터링하려면 태그 값을 선택합니다.
검색 상자는 태그 키 검색도 지원합니다. 목록에서 찾을 키의 이름을 입력합니다.
## AWS CLI에서 태그 사용
코드 서명 구성을 포함하여 기존 Lambda 리소스에 Lambda API로 태그를 추가하고 제거할 수 있습니다. 또한 코드 서명 구성을 생성할 때 태그를 추가하여 리소스의 전체 수명 주기 동안 태그를 유지할 수 있습니다.
### Lambda 태그 API를 사용하여 태그 업데이트
[TagResource](https://docs.aws.amazon.com/lambda/latest/api/API_TagResource.html) 및 [UntagResource](https://docs.aws.amazon.com/lambda/latest/api/API_UntagResource.html) API 작업을 통해 지원되는 Lambda 리소스에 대한 태그를 추가하고 제거할 수 있습니다.
AWS CLI를 사용하여 이러한 작업을 직접적으로 호출할 수 있습니다. 기존 리소스에 태그를 추가하려면 `tag-resource` 명령을 사용합니다. 이 예에서는 두 개의 태그를 추가합니다. 하나는 *Department*라는 키를 갖는 태그이고 다른 하나는 *CostCenter*라는 키를 갖는 태그입니다.
```
aws lambda tag-resource \
--resource arn:aws:lambda:us-east-2:123456789012:resource-type:my-resource \
--tags Department=Marketing,CostCenter=1234ABCD
```
태그를 제거하려면 `untag-resource` 명령을 사용합니다. 이 예에서는 *Department*라는 키가 있는 태그를 제거합니다.
```
aws lambda untag-resource --resource arn:aws:lambda:us-east-1:123456789012:resource-type:resource-identifier \
--tag-keys Department
```
### 코드 서명 구성 생성 시 태그 추가
태그를 사용하여 새 Lambda 코드 서명 구성을 생성하려면 [CreateCodeSigningConfig](https://docs.aws.amazon.com//lambda/latest/api/API_CreateCodeSigningConfig.html) API 작업을 사용합니다. `Tags` 파라미터를 지정합니다. `create-code-signing-config` AWS CLI 명령과 `--tags` 옵션을 사용하여 이 작업을 직접적으로 호출할 수 있습니다. CLI 명령에 대한 자세한 내용은 *AWS CLI Command Reference*의 [create-code-signing-config](https://awscli.amazonaws.com/v2/documentation/api/latest/reference/lambda/create-code-signing-config.html)를 참조하세요.
`CreateCodeSigningConfig`와 함께 `Tags` 파라미터를 사용하기 전에 역할에 이 작업에 필요한 일반적인 권한과 함께 리소스에 태그를 지정할 수 있는 권한이 있는지 확인하세요. 태그 지정 권한에 대한 자세한 내용은 [태그 작업에 필요한 권한](#csc-tags-required-permissions) 섹션을 참조하세요.
### Lambda 태그 API를 사용하여 태그 보기
특정 Lambda 리소스에 적용된 태그를 보려면 `ListTags` API 작업을 사용합니다. 자세한 내용은 [ListTags](https://docs.aws.amazon.com/lambda/latest/api/API_ListTags.html)를 참조하세요.
Amazon 리소스 이름(ARN)을 제공하여 `list-tags` AWS CLI 명령으로 이 작업을 직접적으로 호출할 수 있습니다.
```
aws lambda list-tags --resource arn:aws:lambda:us-east-1:123456789012:resource-type:resource-identifier
```
### 태그로 리소스 필터링
AWS Resource Groups Tagging API [GetResources](https://docs.aws.amazon.com/resourcegroupstagging/latest/APIReference/API_GetResources.html) API 작업을 사용하여 태그를 기준으로 리소스를 필터링할 수 있습니다. `GetResources` 작업은 최대 10개의 필터를 수신하며 각 필터는 태그 키와 최대 10개의 태그 값을 포함합니다. `GetResources`에 `ResourceType`을 지정하면 특정 리소스 유형별로 필터링할 수 있습니다.
`get-resources` AWS CLI 명령을 사용하여 이 작업을 직접적으로 호출할 수 있습니다. `get-resources` 사용 예는 *AWS CLI Command Reference*의 [get-resources](https://awscli.amazonaws.com/v2/documentation/api/latest/reference/resourcegroupstaggingapi/get-resources.html#examples)를 참조하세요.