서버리스 보안이란 무엇인가요?

서버리스는 개발자가 인프라 또는 서버 측 IT를 관리할 필요 없이 애플리케이션과 서비스를 빌드하고 실행할 수 있는 클라우드 컴퓨팅의 클라우드 네이티브 개발 모델을 말합니다. 서버리스 모델의 애플리케이션은 인프라 및 가상 머신을 관리, 패치, 보호할 필요성을 없애주는 관리형 클라우드 서비스와 서비스형 기능(FaaS)의 조합에 의존합니다.

서버리스 아키텍처의 이점

오라일리에 따르면 2020년까지 40%의 조직이 서버리스 아키텍처를 완전히 도입했다고 답했습니다. 이후 몇 년 동안 서버리스는 주요 애플리케이션 실행 환경으로 자리 잡았습니다. 클라우드 네이티브 보안 현황 보고서 2024에 따르면 설문 응답자의 70%가 향후 24개월 내에 사용량을 늘릴 계획이라고 답해 앞으로 더 큰 성장이 예상됩니다.

서버리스 모델을 채택하면 여러 가지 방식으로 애플리케이션 개발에 도움이 됩니다:

  • 운영 오버헤드 감소: 관리할 서버가 없으므로 개발자와 DevOps는 인프라 확장, 에이전트 설치 및 유지 관리 또는 기타 인프라 관련 작업에 대해 걱정할 필요가 없습니다.
  • 민첩성 향상: 서버리스 애플리케이션은 데이터베이스 및 인증과 같은 관리형 서비스에 크게 의존하기 때문에 개발자는 애플리케이션의 실제 비즈니스 로직에 집중할 수 있으며, 이는 일반적으로 AWS® Lambda 또는 Google Cloud Functions와 같은 FaaS에서 실행됩니다.
  • 비용 절감: 서버리스 애플리케이션에서 사용되는 대부분의 서비스에서 고객은 사용량에 대해서만 비용을 지불합니다. 예를 들어, AWS Lambda를 사용하는 고객은 함수 실행에 대한 비용을 지불합니다. 가상 머신처럼 사용하지 않는 용량에 대해 비용을 지불할 필요가 없기 때문에 일반적으로 비용에 큰 영향을 미칩니다.
서버리스 모델의 구성 요소
그림 1: 서버리스 모델의 구성 요소

 

서버리스 애플리케이션에는 서버리스 보안이 필요합니다.

소프트웨어 개발과 IT 운영이 크게 발전할 때마다 공격 벡터와 보안 위험도 함께 변화합니다. 컨테이너가상화 초기에 보안 전문가들은 인프라를 강화하고 방어하며 관리하기 위한 새로운 방법을 찾아 적응해야 했습니다. 서버리스 애플리케이션의 개념은 애플리케이션 보안에 있어 가장 큰 패러다임의 전환을 의미합니다.

기존에는 조직에서 인프라 및 네트워크 기반 도구에 의존하여 애플리케이션을 보호했습니다. 방화벽으로 트래픽을 검사하고, 침입 탐지 시스템으로 악의적인 활동을 탐지하거나, 런타임 애플리케이션 자체 보호(RASP) 기술로 애플리케이션을 보호할 수 있습니다. 컨테이너를 사용하더라도 조직은 기본 인프라의 보안에 어느 정도 의존할 수 있습니다.

서버리스 애플리케이션은 람다 함수를 트리거하는 S3 버킷과 같이 분산된 클라우드 서비스가 함께 작동하여 DynamoDB®를 트리거하는 것으로 구성됩니다. 이 아키텍처에서는 방화벽, IDS/IPS 도구, 모든 종류의 계측 에이전트 또는 서버 기반 보호 방법을 사용할 수 있는 공간이 없습니다. 서버리스 모델은 네트워크 검사 및 액세스 제어 목록에 집중하는 대신 보안의 초점을 IAM 권한, 행동 보호 및 강력한 코드로전환합니다.

서버리스 모델에 적용
그림 2: 서버리스 모델에 적용

 

서버리스 공격 벡터

서버리스 보안을 도입하면 조직은 더 이상 인프라, 네트워크 또는 호스트 보안에 대해 걱정할 필요가 없으므로 보안 관점에서 애플리케이션이 유리한 고지를 선점할 수 있습니다. 그러나 새로운 공격 벡터가 등장하고 익숙한 공격이 서버리스 환경에 맞게 재해석되었습니다. 한 가지 예를 살펴보겠습니다(전체 목록은 클라우드 보안 연합의 서버리스 애플리케이션의 상위 12가지 위험을참조하세요):

이벤트 데이터 주입

현재까지 가장 일반적인 위험 중 하나인 애플리케이션의 인젝션 결함은 많은 보안 코딩 모범 사례 가이드에서 자세히 다루고 있습니다. 높은 수준에서 인젝션 결함은 신뢰할 수 없는 입력이 실행되거나 평가되기 전에 인터프리터에 직접 전달될 때 발생합니다. 하지만 서버리스 아키텍처의 맥락에서 함수 이벤트 데이터 주입은 웹 API 호출을통한 입력과 같은 직접적인 사용자 입력으로 엄격하게 제한되지 않습니다. 대부분의 서버리스 아키텍처는 서버리스 함수의 실행을 트리거할 수 있는 다양한 이벤트 소스를 제공합니다.

이벤트 데이터 주입 소스 예시는 다음과 같습니다:

  • 클라우드 스토리지 이벤트(예: AWS S3®, Azure Blob Storage, Google Cloud Storage)
  • NoSQL 데이터베이스 이벤트(예: AWS DynamoDB, Azure Cosmos DB®)
  • SQL 데이터베이스 이벤트
  • 스트림 처리 이벤트(예: Amazon Kinesis®)
  • 코드 변경 및 새 리포지토리 코드 커밋
  • HTTP API 호출

각 이벤트 입력에는 서로 다른 메시지 형식이 포함될 수 있으며, 이러한 이벤트 메시지의 여러 부분에는 공격자가 제어하거나 위험한 입력이 포함될 수 있습니다. 풍부한 이벤트 소스 세트는 잠재적인 공격 표면을 증가시키고 이벤트 데이터 인젝션으로부터 서버리스 기능을 보호하려고 할 때 복잡성을 야기합니다. 특히 서버리스 아키텍처는 개발자가 어떤 메시지 부분을 신뢰해서는 안 되는지(예: GET/POST 매개변수, HTTP 헤더 등) 잘 알고 있는 웹 환경만큼 잘 이해하지 못하기 때문에 더욱 그러합니다.

이벤트 데이터 인젝션 공격 표면
그림 3: 이벤트 데이터 인젝션 공격 표면

 

서버리스 애플리케이션 보호

효과적인 서버리스 보안은 코드 무결성, 엄격한 권한 및 행동 분석을 보장하는 데 중점을 둡니다.

  • 액세스 및 권한: 서버리스 기능 및 기타 서비스에 대한 최소 권한 액세스를 유지하세요. 예를 들어, AWS Lambda 함수가 DynamoDB 테이블에 액세스해야 하는 경우, 비즈니스 로직에서 요구하는 특정 작업만 수행할 수 있는지 확인합니다.
  • 취약점 스캔: 취약한 타사 종속성, 구성 오류, 과도한 권한이 있는 역할을 정기적으로 검사하여 코드 및 IoC 템플릿의 무결성을 보장하세요.
  • 런타임 보호: 런타임 보호를 사용하여 악성 이벤트 입력과 비정상적인 함수 동작을 탐지하고 필요에 따라 각 함수의 파일, 호스트, 인터넷 액세스 및 하위 프로세스 생성 기능을 제한하세요.

 

서버리스 FAQ

서버리스 아키텍처라고도 하는 서버리스 컴퓨팅은 엔지니어가 기본 인프라를 관리할 필요 없이 애플리케이션을 빌드하고 실행할 수 있는 소프트웨어 설계 접근 방식입니다. 대신 클라우드 제공업체는 디지털 또는 클라우드 네이티브 조직을 위해 애플리케이션, 데이터베이스, 스토리지 시스템을 실행할 서버를 프로비저닝합니다.
서비스형 기능은 고객이 복잡한 관리 없이 이벤트에 대응하여 코드를 실행할 수 있는 클라우드 컴퓨팅 서비스입니다.
서버리스 아키텍처는 개발자가 HTTP 요청 또는 유사한 이벤트에 대한 응답으로 특정 작업을 수행하도록 설계된 고유한 함수 집합으로 애플리케이션 코드를 작성하는 FaaS입니다. 클라우드 공급자 계정에 기능이 구축되면 클라우드 공급자는 클라우드 공급자가 제공한 서버에서 기능을 실행합니다.
클라우드 제공업체가 제공하는 서버리스 서비스의 예로는 Google Cloud Functions, AWS Lambda, Microsoft Azure Functions 등이 있습니다.
이전 네트워크 보안은 공동의 책임
다음 코드로서의 정책이란 무엇인가요?