본 문서는 총 2부로 구성되어 있으며 이 글은 2부입니다.
1부 링크 : AWS Lambda의 보안 개요 1/2
기능 간 및 MicroVM 간 격리
각 실행 환경에는 다음 항목의 전용 복사본이 포함되어 있습니다.
· 함수 코드
· 함수에 대해 선택된 모든 Lambda 레이어
· 내장 함수 (Java 8, NodeJS 8, Python 3.7 등) 또는 사용자 정의 런타임 중 하나 인 함수 런타임
· Amazon Linux 기반의 최소 Linux 사용자 영역
실행 환경은 리눅스 커널에 내장된 여러 컨테이너 기술을 사용하여 서로 격리됩니다. 이러한 기술에는 다음이 포함됩니다.
· cgroup — 실행 환경 당 CPU, 메모리, 디스크 처리량 및 네트워크 처리량을 제한하도록 리소스 액세스를 제한합니다.
· 네임 스페이스 — 그룹 프로세스 ID, 사용자 ID, 네트워크 인터페이스 및 Linux 커널에서 관리하는 기타 리소스. 각 실행 환경은 전용 네임 스페이스에서 실행됩니다.
· seccomp-bpf — 실행 환경 내에서 사용할 수 있는 syscall을 제한합니다.
· iptables 및 라우팅 테이블 — 실행 환경을 서로 분리합니다.
· chroot — 기본 파일 시스템에 대한 범위 액세스를 제공합니다.
이러한 메커니즘은 AWS 전용 분리 기술과 함께 실행 환경 간에 강력한 분리를 제공합니다. 이러한 분리를 통해 환경은 다른 환경에 속하는 데이터에 액세스하거나 수정할 수 없습니다.
단일 AWS 계정의 여러 실행 환경이 단일 마이크로 VM에서 실행될 수 있지만, 마이크로 VM은 AWS 계정 간에 공유되거나 재사용되지 않습니다. 이때 AWS Lambda는 두 가지 메커니즘, 즉 EC2 인스턴스와 Firecracker를 분리하는 방법을 사용합니다. EC2 인스턴스는 2015년부터 Lambda 게스트 분리에 사용되었습니다. Firecracker는 AWS에서 특히 서버리스 워크로드를 위해 개발한 새로운 오픈 소스 하이퍼바이저로, 2018년에 도입되었습니다. microVM을 실행하는 기본 물리적 하드웨어는 여러 계정의 워크로드에서 공유됩니다. 자세한 내용은 부록 — 람다 EC2 & 파이어크래커 모델을 참조합니다.
보관 및 상태
Lambda 실행 환경이 여러 기능에서 재사용되지는 않지만 동일한 기능을 호출하기 위해 단일 실행 환경을 재사용 할 수 있습니다. 함수는 로컬 캐시를 유지하고 호출간 오래 지속되는 연결을 재사용하고 공통 계산 결과를 사전 계산하여 효율성을 향상시키기 위해 이 동작을 활용할 수 있습니다. 실행 환경 내에서 이러한 다중 호출은 단일 프로세스에 의해 처리되므로 재사용 된 실행 환경에서 호출이 발생할 경우 향후 호출에서 프로세스 전체 상태 (예 : Java의 정적 상태)를 재사용 할 수 있습니다.
각 Lambda 실행 환경에는 쓰기 가능한 파일 시스템도 포함되어 있습니다.
/ tmp. 이 스토리지는 다른 실행 환경에서 액세스 할 수 없습니다. 프로세스 상태와 마찬가지로 / tmp에 기록 된 파일은 실행 환경의 수명 동안 유지됩니다. 이를 통해 ML (Downloader Learning) 모델과 같은 값 비싼 전송 작업을 여러 번 호출 할 때 상각 할 수 있습니다. 호출간 데이터를 유지하지 않으려는 함수는 / tmp에 쓰거나 각 호출 후에 / tmp에서 파일을 삭제하지 않아야 합니다. / tmp 스토리지는 Amazon EBS (Amazon Elastic Block Store) 또는 Lambda 작업자 인스턴스의 로컬 스토리지로 구현됩니다.
또한 함수의 첫 번째 호출 전에 Lambda는 메모리를 실행 환경에 할당하기 전에 메모리를 제거하여 동일한 계정과 다른 고객 계정에 속하는 기능 간의 메모리 공유를 효과적으로 방지합니다. 실행 환경 재사용을 용이하게하기 위해 Lambda는 동일한 기능에 대해 동일한 실행 환경에서 후속 호출간 메모리를 제거하지 않습니다. 기능 종료 전에 자체 메모리 암호화 및 삭제 프로세스를 구현할 수 있습니다.
데이터 경로 호출
Invoke API는 이벤트 모드와 요청-응답 모드의 두 가지 모드로 호출 할 수 있습니다. 이벤트 모드는 나중에 실행하기 위해 호출을 대기시킵니다. 요청-응답 모드는 제공된 페이로드로 함수를 즉시 호출하고 응답을 반환합니다. 두 경우 모두 실제 함수 실행은 Lambda 실행 환경에서 수행되지만 페이로드는 다른 경로를 사용합니다. 자세한 내용은 Lambda 런타임 환경 섹션을 참조하십시오.
요청-응답 호출의 경우 페이로드는 API 호출자 (예 : AWS API Gateway 또는 AWS SDK)에서로드 밸런서로 전달 된 다음 Lambda 호출 서비스로 전달됩니다. 이 서비스는 함수의 실행 환경을 식별하고 페이로드를 해당 실행 환경으로 전달하여 호출을 완료합니다. 로드 밸런서로의 트래픽은 인터넷을 통과하고 TLS로 보호됩니다. Lambda 서비스 내의 트래픽 (로드 밸런서에서 다운으로)은 단일 AWS 리전 내의 Lambda 내부 VPC를 통과합니다.
이벤트 호출은 즉시 실행되거나 처리를 위해 대기 할 수 있습니다. 경우에 따라 대기열은 Amazon Simple Queue Service (Amazon SQS)로 구현되고 내부 폴러 프로세스에 의해 Lambda 호출 서비스로 다시 전달됩니다. 이 경로의 트래픽은 TLS로 보호되지만 Amazon SQS에 저장된 데이터에 대한 추가 암호화는 제공되지 않습니다. Lambda에서 사용하는 Amazon SQS 대기열은 Lambda 서비스에서 관리하며 고객에게는 표시되지 않습니다. 이벤트 호출의 경우 응답이 리턴되지 않으며 작업자가 응답 데이터를 삭제합니다. Amazon S3, Amazon SNS, CloudWatch 이벤트 및 기타 이벤트 소스에서의 호출은 Lambda 서비스의 이벤트 호출 경로를 따릅니다. Amazon Kinesis 및 DynamoDB 스트림, SQS 대기열, Application Load Balancer 및 API Gateway에서의 호출은 요청-응답 경로를 따릅니다.
Lambda의 런타임 유지 관리
AWS Lambda는 Java 8, Python 3.7, Go, NodeJS 8, .NET core 2 등 런타임을 사용하여 여러 프로그래밍 언어를 지원합니다. 전체 목록은 AWS Lambda 런타임을 참조하십시오. Lambda는 업데이트, 보안 패치 및 기타 유지 관리를 포함하여 이러한 런타임을 지원합니다. 일반적으로 Lambda 런타임 용 최신 패치를 선택하기위한 조치가 필요하지 않지만, 패치를 배포하기 전에 테스트하기 위해 조치가 필요할 수 있습니다. 조치가 필요한 경우 AWS는 (예 : 개인 건강 대시 보드를 통해) 연락을 드릴 것입니다.
사용자 정의 런타임을 구현하여 Lambda에서 다른 언어를 사용할 수 있습니다. 사용자 정의 런타임의 경우 제공하는 런타임에 최신 보안 패치가 포함되어 있는지 확인하는 등 유지 관리가 사용자의 책임입니다. 자세한 내용은 AWS Lambda 개발자 안내서의 사용자 지정 AWS Lambda 런타임을 참조하십시오.
때때로 Lambda는 업스트림 관리자가 수명 종료 (EOL)로 표시 한 경우와 같이 런타임 버전을 더 이상 사용하지 않습니다. 더 이상 사용되지 않는 것으로 표시된 버전은 더 이상 사용되지 않는 런타임에서 작성된 기존 기능에 대한 새 기능 및 업데이트 작성을 지원하지 않습니다. AWS Lambda는 더 이상 사용되지 않는 런타임에 대한 보안 업데이트, 기술 지원 또는 핫픽스를 제공하지 않으며, 더 이상 사용되지 않는 런타임에서 실행되도록 구성된 함수 호출을 비활성화 할 수 있는 권한을 보유합니다. 런타임이 더 이상 사용되지 않는 시기에 대한 자세한 내용은 AWS Lambda 런타임 지원 정책을 참조하십시오.
Lambda 함수 모니터링 및 감사
다음 서비스를 포함하여 여러 AWS 방법 및 서비스로 Lambda 기능을 모니터링하고 감사 할 수 있습니다.
Amazon CloudWatch
AWS Lambda는 사용자를 대신하여 Lambda 기능을 자동으로 모니터링합니다. Amazon CloudWatch를 통해 요청 수, 요청 당 실행 시간 및 오류를 일으킨 요청 수와 같은 지표를보고합니다. 이러한 지표는 기능 수준에서 노출되며이를 사용하여 CloudWatch 경보를 설정할 수 있습니다. Lambda에 의해 노출되는 지표 목록은 AWS Lambda 지표를 참조하십시오.
Amazon CloudTrail
Amazon CloudTrail을 사용하면 Lambda를 포함한 전체 AWS 계정의 거버넌스, 규정 준수, 운영 감사 및 위험 감사를 구현할 수 있습니다. CloudTrail을 사용하면 AWS 인프라 전체의 작업과 관련된 계정 활동을 기록, 지속적으로 모니터링 및 유지하여 AWS 관리 콘솔, AWS SDK, 명령 줄 도구 및 기타 AWS 서비스를 통해 수행 된 작업의 전체 이벤트 기록을 제공 할 수 있습니다. CloudTrail을 사용하면 Amazon Key Management Service (KMS)를 사용하여 로그 파일을 선택적으로 암호화하고 긍정적 인 주장을 위해 CloudTrail 로그 파일 무결성 검증을 활용할 수도 있습니다.
AWS X-Ray
AWS X-Ray를 사용하면 프로덕션 및 분산 Lambda 기반 애플리케이션을 분석 및 디버깅 할 수 있으며,이를 통해 애플리케이션 및 기본 서비스의 성능을 파악할 수 있으므로 성능 문제 및 오류의 근본 원인을 파악하고 해결할 수 있습니다. X-Ray의 요청이 애플리케이션을 통과 할 때의 전체적인 관점은 애플리케이션의 기본 구성 요소 맵을 보여 주므로 개발 및 생산 과정에서 애플리케이션을 분석 할 수 있습니다.
AWS Config
AWS Config를 사용하면 Lambda IAM 실행 역할, 서브넷 및 보안 그룹 연결. 이를 통해 Lambda 함수의 수명 주기를 전체적으로 확인할 수 있으며 잠재적인 감사 및 준수 요구 사항에 대해 해당 데이터를 표시 할 수 있습니다.
Lambda 함수 설계 및 운영
Lambda 서비스의 기본 사항을 살펴 보았으므로 이제 아키텍처 및 운영으로 넘어갑니다. 서버리스 애플리케이션의 표준 모범 사례에 대한 자세한 내용은 서버리스 컨텍스트에서 AWS Well Architected Framework의 기반을 정의하고 살펴 보는 서버리스 애플리케이션 렌즈 백서를 참조하십시오.
· 운영 우수성 기반 — 비즈니스 가치를 제공하고 지원 프로세스 및 절차를 지속적으로 개선하기 위해 시스템을 실행 및 모니터링하는 기능.
· 보안 기반 — 위험 평가 및 완화 전략을 통해 비즈니스 가치를 제공하면서 정보, 시스템 및 자산을 보호하는 기능.
· 안정성 기반 — 시스템이 인프라 또는 서비스 중단을 복구하고, 컴퓨팅 리소스를 동적으로 획득하여 요구를 충족 시키며, 잘못 구성되거나 일시적인 네트워크 문제와 같은 중단을 완화하는 기능.
· 성능 효율성 기반 — 수요 변화와 기술이 발전함에 따라 컴퓨팅 리소스를 효율적으로 사용하여 요구 사항과 효율성을 유지 관리합니다.
Serverless Application Lens 백서에는 메트릭 로깅 및 경보, 제한 및 제한, Lambda 기능에 권한 할당 및 Lambda 기능에 민감한 데이터를 제공하는 등의 주제가 포함되어 있습니다.
Lambda 및 규정 준수
공유 책임 모델 섹션에서 언급 한 바와 같이, 데이터에 적용 할 규정 준수 체제를 결정해야 합니다. 규정 준수 요구 사항을 확인한 후 다양한 Lambda 기능을 사용하여 해당 컨트롤을 일치시킬 수 있습니다. AWS 전문가 (예 : 솔루션 아키텍트, 도메인 전문가, 기술 계정 관리자 및 기타 인적 자원)에게 문의하여 도움을 받을 수 있습니다.
그러나 AWS는 고객에게 특정 유스 케이스에 적용 가능한 준수 체계가 무엇인지 조언 할 수 없습니다.
Lambda는 2019 년 3 월 현재 SOC 1, SOC 2, SOC 3, PCI DSS, 미국 건강 보험 이동성 및 책임법 (HIPAA) 등을 준수합니다. 규정 준수 정보 목록은 규정 준수 프로그램 별 범위 내 AWS 서비스 페이지를 참조하십시오.
일부 준수 보고서의 민감한 특성으로 인해 공개적으로 공유 할 수 없습니다. 이러한 보고서에 액세스하려면 AWS 콘솔에 로그인하고 AWS 셀프 서비스 포털 없이 무료로 AWS Artifact를 사용하여 AWS 규정 준수 보고서에 대한 온 디맨드 액세스를 수행 할 수 있습니다.
결론
AWS Lambda는 안전하고 확장 가능한 애플리케이션을 구축 할 수 있는 강력한 툴킷을 제공합니다. AWS Lambda의 보안 및 규정 준수에 대한 많은 모범 사례는 모든 AWS 서비스와 동일하지만 일부는 Lambda에만 해당됩니다. 이 백서에서는 Lambda의 이점, 응용 프로그램에 대한 적합성 및 Lambda 관리 런타임 환경에 대해 설명합니다. 모니터링 및 감사, 보안 및 규정 준수 모범 사례에 대한 정보도 포함되어 있습니다. 다음 구현에 대해 생각할 때 AWS Lambda에 대해 배운 내용과 다음 워크로드 솔루션을 개선 할 수 있는 방법을 고려하십시오.
부록 — Lambda EC2 및 Firecracker 모델
다음은 AWS Lambda에 대한 EC2 및 Firecracker 모델을 비교 한 것입니다.
빌드업웍스에서 AWS 무료 컨설팅을 진행합니다.
AWS에 대하여 궁금하신 내용이 있으시거나, 도입을 검토 중이시라면 편하게 신청해주세요.
[ 고지 사항 (Disclaimer) ]
본 컨텐츠는 고객의 편의를 위하여 AWS 서비스 설명을 위해 제작, 제공된 것입니다. 만약 AWS 사이트와 컨텐츠 상에서 차이나 불일치가 있을 경우 AWS 사이트 (AWS.amazon.com)가 우선합니다. 또한 AWS 사이트 상에서 한글 번역문과 영어 원문에 차이나 불일치가 있을 경우(번역의 지체로 인한 경우 등 포함), 영어 원문이 우선합니다.
본 문서는 Security Overview of AWS Lambda (2019년, 영문) 내용에 기반하여 작성 되었습니다.
이 문서는 정보 제공의 목적으로만 제공됩니다. 본 문서의 발행일 당시 AWS의 현재 제품 오퍼링 및 실행방법 등을 설명하며, 예고 없이 변경될 수 있습니다. 고객은 본 문서에 포함된 정보나 AWS 제품 또는 서비스의 사용을 독립적으로 평가할 책임이 있으며, 각 정보 및 제품은 명시적이든 묵시적이든 어떠한 종류의 보증 없이 “있는 그대로” 제공됩니다. 본 문서는 AWS, 그 자회사, 공급업체 또는 라이선스 제공자로부터 어떠한 보증, 표현, 계약 약속, 조건 또는 보장을 구성하지 않습니다. 고객에 대한 AWS의 책임 및 의무는 AWS 계약에 의해 관리되며 본 문서는 AWS와 고객 사이의 어떠한 계약에도 속하지 않으며 계약을 변경하지도 않습니다.
© 2020, Amazon Web Services, Inc. or its affiliates. All rights reserved.
