[레포트]Architecting secure serverless applications #SVS302-R #reinvent

re:invent 2022의 Architecting secure serverless applications 세션에 대해 작성한 글 입니다
2022.12.17

この記事は公開されてから1年以上経過しています。情報が古い可能性がありますので、ご注意ください。

안녕하세요, 클래스메소드의 서은우입니다.

2022 re:Invent에서 오프라인으로 참석했던 Architecting secure serverless applications 세션에 대한 정리를 하려고합니다.

세션 개요

This session explores how to think about security from the front to the back of a typical serverless application. How do you configure AWS serverless services to provide least-privileged access while helping to ensure functionality? How should you think about managing IAM policies for your AWS Lambda functions? This session covers all of this and more, leaving you with concrete examples applicable to almost any workload.

발표자

  • Josh Kahn, Tech Leader, Serverless, AWS

세션 영상2022

서버리스 서비스를 사용함에 있어

서버리스 서비스들은 보통, VPC에 붙일 수 없어 NACL 등을 이용할 수 없거나, 너무 퍼져 있어서 하나의 큰 방화벽을 사용할 수 없는 등 보안 대책에 대한 어려움이 있습니다.

하지만 AWS 서비스들은 공통적으로 IAM 사용할 수 있습니다. 그렇기 때문에 IAM 을 이용해서 권한의 제한을 두는 것으로 서버리스 서비스에 관한 보안을 구현할 수 있습니다.

이것 외에도 항상 주의해야할 사항들이 있습니다.

  • 자신의 데이터를 보호할 것
  • 코드를 잘 작성하는 것
  • 최소한의 권한만을 줄 것
  • 모니터링할 것

서버리스에 관한 책임 공유 모델

람다나 Step Functions같은 서버리스 서비스에는 다음과 같은 책임 공유 모델을 적용시킬 수 있습니다.

고객측의 책임에 대해

  • 만약 람다를 s3에 연결하는 것을 예로 들면, SCP, IAM 정책, 버킷 정책, vpc 엔드포인트 등의 보안 대책이 가능한데 이런 것은 공유 책임 모델에서 고객측의 보안 책임에 해당합니다.
  • 그리고 특히 IAM은 모든 액세스의 문이 되며, 액세스 컨트롤의 기반이 되기 때문에 정말 중요하다고 할 수 있습니다.

AWS의 책임에 대해

Log4Shell과 Lambda

AWS의 책임에 대해 설명하기 위해 Log4Shell 취약성에 대응한 Lambda의 이야기를 할 수 있습니다.

Lambda는 Log4j를 사용하지 않는 서비스이며, Lambda에서 제공하는 관리형 JAVA 런타임에도 포함되어 있지 않습니다. 하지만 Log4j는 로깅을 위해 쉽게 사용할 수 있는 유명한 라이브러리였기 때문에 AWS에서도 많은 유저들이 Log4j를 사용하고 있다는 사실을 알고 있었으며 빠르게 대응해야 했습니다.

Lambda function의 구조는 다음과 같습니다.

  • 람다 함수는 분리된 샌드박스 안에서 실행된다
    • 이 환경은 Firecracker라고 하는 마이크로 가상 머신 위에 구현 된다.
      • Firecracker를 사용함으로 인해 격리된 환경, 낮은 메모리 오버헤드, 빠른 시작이 가능하다.
    • 샌드박스에 속해 있는 것
      • 최소한의 유저스페이스 기반의 아마존 리눅스2
      • 최소한의 파일 시스템
      • 복수의 레이어에 걸친 고객의 코드(KMS로 암호화됨)

서버리스 서비스의 보안

최소한의 권한을 주는 것

IAM을 이용할 때 중요한 것 중 하나는 바로 필수적인 최소한의 권한만 주어야한다는 것입니다. 작업을 실행하기 위해 필요한 최소한의 권한만 부여를 하고 리소스 마다 고유의 역할과 세분화된 엑세스 제어를 사용하는 것이 좋습니다. 또한 제한된 리소스 집합과 허용하는 액션을 구체적으로 설정하는 것이 좋습니다.

데이터를 보호하기 위한 여러 옵션들도 추가되었습니다. SQS의 경우, SSE-SQS 암호화를 기본값으로 사용할 수 있고, ABAC(Attribute Based Access Controls)가 지원 되며, SNS의 경우 대부분의 민감한 데이터를 SNS Data Protection으로 보호할 수 있게 되었습니다.

신뢰할 수 없는 이벤트 페이로드를 검증하는 것

프로세싱이나 파싱 하기 전에 들어오는 이벤트 페이로드에 대하여 검증하고 정적 타이핑을 사용하며 모든 이벤트 소스, 특히 APIs에 적용시키는 것을 고려해야합니다.

개발

프레임워크를 사용하여 쉽게 구현할 수 있습니다. 또한 IAM을 통해 엑세스를 제어할 때, ABAC(속성 기반 엑세스 제어) 방법으로 태그를 통해 엑세스 제어를 구현할 수 있습니다. 뿐만 아니라 개발자들이 안전하게 정책을 만들 수 있도록 적절한 권한을 부여할 수 있습니다,

마지막으로

평소 서버리스 서비스는 어떻게 보안을 높일 수 있을지 고민이 되는 부분이 많았는데요, 이번 세션을 통해 서버리스 서비스를 이용할 때 보안 대책을 어떻게 세울 수 있는지 또 모범사례 등을 배울 수 있어서 좋은 기회가 된 것 같습니다. 블로그의 레포트 이외에도 유튜브에서 해당 세션의 영상을 확인 할 수 있으니 보다 구체적인 내용을 확인하고 싶으신 분들은 유튜브를 참고해주세요!