☁️ Serverless Secrets 베일 벗기기: 심층 탐구

Source: Dev.to

초록

서버리스 컴퓨팅, 특히 AWS Lambda의 급속한 도입은 애플리케이션 개발에 혁신을 가져와 뛰어난 확장성과 비용 효율성을 제공하고 있습니다. 그러나 이러한 아키텍처 전환은 보안 책임에 대한 공통된 오해 때문에 종종 간과되는 새로운 공격 표면을 만들기도 합니다. 이 글에서는 서버리스 함수에서 발생할 수 있는 주요 잘못된 구성들을 살펴보고, 사소해 보이는 실수가 데이터 유출, 권한 상승, 공급망 침해와 같은 심각한 보안 취약점으로 이어질 수 있는 방식을 상세히 설명합니다.

본 연구는 보안 전문가들이 이러한 위험을 보다 깊이 이해하고, 강력한 방어를 위한 실용적인 전략을 마련하도록 돕는 것을 목표로 하며, 클라우드 보안이라는 변화하는 환경에 귀중한 통찰을 제공하고자 합니다. 🛡️

Research Context

Serverless 아키텍처는 더 이상 틈새 기술이 아니며, 현대 클라우드‑네이티브 애플리케이션의 핵심 요소가 되었습니다. 개발자들은 인프라 관리 추상화 덕분에 비즈니스 로직에만 집중할 수 있게 되어 이를 선호합니다. 이러한 패러다임 전환은 민첩성에 도움이 되지만, 전통적인 보안 경계를 재정의합니다.

공유 책임 모델은 클라우드에서 다음을 의미합니다:

Serverless 환경에서는 고객의 책임이 개별 함수의 복잡한 권한 및 환경 설정까지 확장되는 경우가 많으며, 이러한 영역은 자주 오해되거나 잘못 적용되어 보안 침해의 발판이 됩니다. 🌐

문제 설명

많은 서버리스 배포에서 핵심 보안 격차는 클라우드 플랫폼 자체의 고유한 보안에 있는 것이 아니라, 서버리스 함수와 연관된 리소스의 잘못된 구성에 있습니다. 일반적인 함정은 다음과 같습니다:

• Lambda 함수에 과도하게 허용적인 IAM 역할을 부여하는 경우.
• 환경 변수에 민감한 데이터를 노출하는 경우.
• 타사 종속성을 충분히 관리하지 못하는 경우.

이러한 잘못된 구성은 은밀한 공격 벡터를 만들며, 공격자는 서버리스 아키텍처 고유의 취약점을 악용할 수 있습니다—종종 단일 애플리케이션을 위해 설계된 전통적인 경계 방어를 우회합니다. 서버리스의 일시적인 특성과 분산된 구성 요소는 이러한 문제를 탐지하고 해결하기 어렵게 만들어, 지속적인 보안 사각지를 초래합니다. 👻

방법론 / 조사 과정

서버리스 잘못된 구성에 대한 조사는 시뮬레이션된 AWS 환경을 구축하고 여러 Lambda 함수와 통합 서비스들을 의도적으로 잘못 구성함으로써 진행되었습니다. 이 과정은 다음과 같은 주요 단계로 이루어졌습니다:

1. 환경 설정

   • 서로 다른 런타임(Python, Node.js)을 사용하는 여러 AWS Lambda 함수를 배포했습니다.
   • S3, DynamoDB, API Gateway와 통합했습니다.

2. 구성 분석

   • 오픈소스 도구 Prowler와 ScoutSuite를 실행하여 보안 상태를 기준선으로 잡았습니다.
   • IAM 역할, 네트워크 설정, 데이터 처리와 관련된 일반적인 잘못된 구성 패턴을 식별했습니다.

3. 취약점 시뮬레이션 – 특정 잘못된 구성을 목표로 수동으로 만든 개념 증명(POC) 공격을 실행했습니다. 포함된 내용:

   • 과도하게 허용된 IAM 역할을 통한 역할 가정 및 권한 상승.
   • 손상된 Lambda 권한을 이용한 S3 버킷에서의 데이터 유출.
   • 민감한 환경 변수 추출.
   • Lambda 패키지 내 취약한 서드파티 종속성을 통한 악성 코드 삽입.

4. 런타임 관찰

   • 함수 호출 로그, CloudTrail 이벤트, VPC 흐름 로그를 모니터링하여 성공 및 실패한 공격의 흔적을 파악했습니다.

5. 데이터 수집

   • 구체적인 잘못된 구성 시나리오, 활성화된 공격 경로, 그리고 그에 따른 영향을 문서화했습니다. 📝

Findings and Technical Analysis

조사 결과 여러 번 반복되는 중요한 잘못된 구성 패턴이 발견되었습니다:

1. 과도하게 허용된 IAM 역할

• 함수에 s3:*, dynamodb:*, 혹은 ec2:*와 같은 광범위한 권한이 부여되는 경우가 많았으며, 실제로는 s3:GetObject와 같은 특정 작업만 필요했습니다.
• Impact: 공격자가 해당 함수 내에서 코드 실행 권한을 얻으면, 과도한 권한을 이용해 관련 없는 리소스에 접근하거나 수정할 수 있어 권한 상승이 발생합니다.

Example: 단일 버킷에 s3:PutObject 권한만 필요했던 썸네일‑제너레이터 Lambda에 실수로 모든 버킷에 대해 s3:* 권한이 부여되었습니다. 코드 인젝션이 발생하면 전혀 다른 버킷의 중요한 데이터를 삭제할 수 있습니다. 📉

2. 안전하지 않은 환경 변수

• 민감한 데이터(API 키, 데이터베이스 자격 증명, 개인 토큰)가 Lambda 환경 변수에 직접 저장되었습니다.
• AWS가 이를 휴지 상태에서 암호화하지만, 런타임 시 쉽게 접근할 수 있습니다.

Impact: 원격 코드 실행(RCE) 취약점—심지어 사소한 명령어 인젝션—이 발생하면 공격자가 이러한 변수를 추출해 하위 서비스나 내부 시스템을 손상시킬 수 있습니다. 🔑

3. 취약한 서드‑파티 의존성

• 많은 함수가 알려진 CVE를 가진 오래되었거나 패치되지 않은 라이브러리(npm 패키지, Python PyPI 모듈)를 사용하고 있었습니다.
• 이러한 공급망 취약점을 이용하면 Lambda 컨텍스트 내에서 RCE를 달성할 수 있어 추가 공격의 발판이 됩니다. ⛓️

4. 네트워크 분리 및 VPC 구성 부족

• 민감한 데이터를 처리하는 함수가 종종 적절한 VPC 설정 없이 배포되어, 직접 퍼블릭 인터넷에 노출되거나 무제한 아웃바운드 트래픽을 허용했습니다.

Impact: 함수가 네트워크 제어 없이 내부 리소스에 연결할 경우, 데이터 유출 및 횡방향 이동을 촉진합니다. 📡

위험 및 영향 평가

Bottom‑Line Recommendations

1. Principle of Least Privilege – IAM 정책을 정확히 필요한 작업 및 리소스로 제한합니다.
2. Secrets Management – 자격 증명을 평문 환경 변수에 저장하지 말고 AWS Secrets Manager 또는 Parameter Store에 저장합니다.
3. Dependency Hygiene – 자동화 도구(예: Dependabot, Snyk)를 사용해 서드파티 라이브러리를 최신 상태로 유지하고 CVE를 스캔합니다.
4. Network Controls – Lambda 함수를 보안 그룹과 아웃바운드 규칙이 엄격히 제어되는 VPC 내부에 배포합니다.
5. Continuous Posture Scanning – Prowler/ScoutSuite(또는 AWS Config 기본 규칙)를 CI/CD 파이프라인에 통합해 지속적인 규정 준수를 유지합니다.

이러한 잘못된 구성을 해결함으로써 조직은 서버리스 워크로드의 공격 표면을 크게 줄이고, 공유 책임 모델의 보안 기대치에 부합할 수 있습니다.

위험

• 데이터 노출: 민감한 고객 데이터, 지적 재산권, 또는 규제 비준수가 유출되는 경우.
• 권한 상승: 공격자가 초기 침해된 기능의 범위를 넘어 관리 권한이나 핵심 클라우드 리소스에 대한 제어를 획득하는 경우.
• 공급망 공격: 개발 파이프라인이 손상되어 악성 코드가 서버리스 함수에 주입되고, 이는 하위 사용자나 서비스에 영향을 미치는 경우.
• 자원 고갈 및 서비스 거부: 잘못 구성된 함수를 악용해 과도한 자원 사용을 유발, 막대한 클라우드 비용이 발생하거나 정상 서비스가 중단되는 경우.
• 평판 손상: 보안 사고로 인한 고객 신뢰 상실 및 브랜드 이미지 훼손. 💸

완화 및 방어 전략

이러한 위험을 해결하려면 다계층 접근 방식이 필요하며, 서버리스 개발 및 운영에서 “보안‑우선” 마인드셋을 강조합니다:

• 최소 권한 원칙 – Lambda 함수에 할당된 IAM 역할에 대해 최소 권한 원칙을 엄격히 적용합니다. 함수가 작동하는 데 필요한 절대 최소 권한만 부여합니다. 리소스와 작업에 대한 세밀한 제어를 위해 IAM 조건 키를 사용합니다. 🤏

• 보안 비밀 관리 – 민감한 자격 증명을 환경 변수에 직접 저장하지 마세요. AWS Secrets Manager 또는 AWS Systems Manager Parameter Store 를 활용해 비밀을 안전하게 저장·조회하고, 런타임에 안전하게 주입되도록 합니다.

• 종속성 스캔 및 패치 관리 – 자동화 도구(예: Snyk, Dependabot, AWS Inspector)를 사용해 서드파티 라이브러리를 지속적으로 스캔하고 알려진 취약점을 탐지합니다. 종속성을 신속히 업데이트할 수 있도록 엄격한 패치‑관리 프로세스를 구축합니다.

• VPC 구성 및 네트워크 분리 – 민감한 Lambda 함수를 VPC 내부에 배치해 네트워크 접근을 제한합니다. 보안 그룹 및 네트워크 ACL을 사용해 인바운드·아웃바운드 트래픽을 제어하고, 함수가 허가된 엔드포인트와만 통신하도록 보장합니다.

• 런타임 보안 및 모니터링 – 서버리스 환경에 맞춘 런타임 애플리케이션 자체 보호(RASP) 또는 유사 솔루션을 배포합니다. CloudWatch 로그, CloudTrail 이벤트, VPC Flow Logs 를 모니터링해 이상 행동 및 잠재적 악용 시도를 탐지합니다.

• 정적·동적 애플리케이션 보안 테스트(SAST/DAST) – CI/CD 파이프라인에 SAST 도구를 통합해 코드 수준 취약점을 식별하고, DAST 도구로 배포된 함수의 런타임 취약점을 테스트합니다.

• 개발자 보안 교육 – 개발자에게 보안 코딩 관행, 클라우드 보안 모범 사례, 공유 책임 모델을 교육합니다. 설계 단계부터 보안이 통합되는 문화를 조성합니다. 🧑‍💻

Researcher Reflection

이 서버리스 보안 연구를 진행하면서 많은 통찰을 얻었습니다. Harsh로서, 서버리스에서 개발자 속도의 매력이 종종 기본적인 보안 고려사항을 가릴 수 있다는 것을 배웠습니다. 함수 배포가 쉬워지면 “설정하고 잊어버리기” 사고방식이 생겨, 초기 보안 구성이 애플리케이션이 진화함에 따라 유지되지 않을 수 있습니다.

가장 중요한 교훈은 보안을 왼쪽으로 이동하는 것의 중요성으로, 개발 수명 주기 전반에 걸쳐 견고한 검증과 균형을 통합하는 것이 사후에 추가하는 것보다 훨씬 효과적이라는 점입니다. 혁신과 보안을 균형 잡는 것은 끊임없는 싸움이며, 우리 보안 자세에 대한 솔직한 자기 평가가 가장 중요합니다. 제 경험을 통해 이를 확신합니다. 💡

경력 및 연구 영향

이 연구 결과는 클라우드 및 서버리스 보안에 대한 깊은 전문성을 갖춘 사이버 보안 전문가에 대한 중요한 그리고 증가하는 수요를 강조합니다. 클라우드 보안 엔지니어, 서버리스 보안 아키텍트, 그리고 특화된 위협 헌터와 같은 역할이 점점 더 필수적으로 되고 있습니다.

보안 연구자를 지망하는 이들에게 이 분야는 일시적이고 이벤트‑드리븐 아키텍처에 맞춘 새로운 탐지 기법, 자동화된 복구 도구, 그리고 정교한 위협 모델을 제공할 수 있는 막대한 기회를 제공합니다. 윤리적 연구와 책임 있는 공개는 우리 모두의 보안 지식을 발전시키고 디지털 환경을 보호하기 위한 기본 원칙으로 남아 있습니다. 🎓

행동 촉구

👉 Cyber Sphere 커뮤니티에 참여하세요:

---

결론

서버리스 컴퓨팅은 변혁적이지만 전통적인 아키텍처보다 본질적으로 더 안전한 것은 아니다. 서버리스 애플리케이션의 보안 태세는 철저한 구성, 지속적인 모니터링, 그리고 공유‑책임 모델에 대한 깊은 이해에 크게 좌우된다. IAM 역할, 환경 변수, 종속성 및 네트워크 설정의 잘못된 구성을 사전에 해결함으로써 조직은 공격 표면을 크게 줄이고 보다 회복력 있는 서버리스 애플리케이션을 구축할 수 있다.

내 연구는 클라우드 보안이 지속적인 경계와 적응을 요구하는 끊임없는 여정임을 강조한다. 🔒

Discussion Question

서버리스 환경에서 제로데이 잘못된 구성에 가장 효과적인 새로운 탐지 또는 방지 전략은 무엇이라고 생각하십니까? 특히 함수가 점점 더 일시적이고 상호 연결될수록? 🕵️‍♀️

---

Written by Harsh Kanojia