서버리스 컴퓨팅이란?
서버리스 컴퓨팅은 클라우드 공급자가 서버를 실행하고 머신 리소스의 할당을 동적으로 관리하는 클라우드 컴퓨팅 모델을 말합니다. AWS Lambda Functions, Google 클라우드 Functions 및 Azure Functions 는 애플리케이션을 구축하는 데 널리 사용되는 서버리스 프레임워크입니다.
서버리스 아키텍처는 거의 무한에 가까운 자동화된 확장의 이점을 제공합니다. 개발자와 배포된 코드 사이에 차이가 거의 없어 출시 시간이 단축되고 개별 기능을 더 쉽게 유지 관리하고 테스트할 수 있습니다. 마지막으로, 소비되는 애플리케이션 리소스의 실제 양은 가격에 영향을 미치며, 이는 사용한 만큼만 비용을 지불하므로 비용이 절감됩니다.
서버리스는 고객에서 클라우드 공급자로의 추가적인 책임 이동을 나타냅니다. 인프라가 필요하지 않으면 운영 오버헤드가 크게 줄어듭니다.
인프라 관리를 클라우드 공급자로 전환하면 조직과 고객에게 서비스를 제공하는 솔루션을 개발하는 데 집중할 수 있습니다. 고유한 경쟁 우위에 계속 집중할 수 있도록 지원하며, 컴퓨팅뿐만 아니라 인력을 개발로 전환하여 비용을 절감하는 경우가 많습니다.
서버리스는 보안을 어떻게 개선합니까?
다음은 몇 가지 핵심 사항입니다.
- 클라우드 공급자는 운영 체제, 런타임 보안 및 패치를 처리합니다. 서버리스 애플리케이션을 배포할 때 대부분의 스택에 대한 제어권을 클라우드 공급자에게 양도하고 클라우드 공급자는 키 관리와 같은 서비스를 제공합니다. 더 이상 운영체제 강화, 관리자 권한, SSH 및 세그멘테이션을 소유하지 않습니다. AWS, Microsoft 및 Google 은 스택의 일부를 패치하고 보호하는 데 신뢰할 수 있으므로 스택의 더 많은 부분을 제공하면 확실히 개선됩니다.
- 무국적/임시. 또한 서버리스 컴퓨팅의 일시적인 상태 비저장 특성은 공격자의 삶을 더 어렵게 만듭니다. AWS Lambda와 같은 서버리스 함수는 몇 초 동안 실행된 후 종료됩니다. 컨테이너는 재활용됩니다. 메모리가 없는 서버리스 기능이 왔다 갔다 한다는 사실은 장기적인 공격의 위험을 줄여줍니다.
- 서버리스 애플리케이션에 대한 가시성 – 이점. 서버리스 애플리케이션이 클라우드에서 많은 수의 작은 기능으로 구성되어 있다는 사실은 보안을 위한 환상적인 기회를 제공합니다. 애플리케이션 보안 도구는 종종 애플리케이션의 내부 흐름을 관찰하거나 필터링할 수 있도록 패키지된 애플리케이션을 분석하고 계측하는 데 엄청난 노력을 기울입니다.
- 더 작은 마이크로서비스 = 각 기능에 적합한 최소한의 역할을 구성할 수 있는 능력입니다. 더 작은 마이크로서비스로 전환하면 더 세분화된 IAM을 수행할 수 있습니다. 이러한 작은 것들 각각에 보안 정책을 적용할 수 있으며, 이를 통해 공격 표면을 크게 줄일 수 있습니다.
컨테이너 내의 함수가 S3에서 읽기 위해 액세스 권한이 필요한 한, 해당 컨테이너 내의 모든 함수도 해당 권한을 갖게 됩니다. AWS Lambda를 사용하면 개별 함수에 권한을 적용하고 이러한 권한이 필요한 가장 작은 범위로만 제한되도록 할 수 있습니다. 함수 중 하나에 취약성이 있는 경우 공격자는 컨테이너에 부여할 수 있는 대규모 권한 집합이 아닌 해당 함수의 제한된 기능에만 액세스할 수 있습니다.
Serverless Security 챌린지란 무엇입니까?
서버리스 애플리케이션의 구조가 변화함에 따라 몇 가지 새로운 과제가 발생합니다.
- 보안 가시성이 점점 더 어려워집니다. 총 정보의 양과 리소스 수는 서버리스와 함께 증가합니다. 이렇게 하면 모든 데이터를 이해하는 데 방해가 됩니다. 매일 로그에 10억 개의 이벤트가 기록되기 때문에 진정한 관찰 가능성을 위해 방대한 데이터에서 인텔리전스를 얻는 것은 어려운 일입니다.
- 프로토콜, 벡터, 공격 지점은 모든 기능에 배가되었으며 프로토콜 = 잠재적 공격 지점입니다. 이를 위해서는 Google Functions, Azure Functions 및 AWS Lambda 보안에 대한 고유한 접근 방식이 필요합니다.
- 더 많은 리소스 = 관리할 더 많은 권한. 리소스가 많을수록 관리할 권한이 많아지므로 이러한 모든 상호 작용에 대한 권한을 결정하는 데 어려움이 있습니다. 자동화된 기술은 구성 위험을 감지하고 최소 권한 기능 권한을 자동으로 생성할 수 있습니다.
- 서버리스 앱에 대한 관찰 가능성 – 과제. 서버리스 앱은 여러 버전 및 지역에 걸쳐 다양한 클라우드 공급자의 다양한 서비스를 사용합니다. 공격 표면과 잠재적 위험을 이해하려면 전체 서버리스 에코시스템에 대한 포괄적인 관점이 필요합니다. 앱이 전파됨에 따라 이러한 보안 중심 보기는 빌드하고 유지 관리하기가 점점 더 어려워질 수 있습니다.
Serverless Security어디에 배포합니까?
서버리스 애플리케이션에는 WAF, 방화벽 및 IDS와 같은 고전적인 보안을 배치할 곳이 없습니다. 공격자와 리소스 사이에 벽을 쌓는 것은 여러 가지 이유로 간단하지 않습니다.
- 더 빠르고 더 빈번한 배포는 매우 긍정적일 수 있지만 서버리스의 속도는 보안 구성에 새로운 문제를 제기할 수 있습니다.
- 보안 도구는 처리 시간을 추가할 수 있으며, 모든 요청을 곱해야 합니다. 다행히 대부분의 Serverless Security 모범 사례에는 추가 처리 시간이 필요하지 않습니다.
- 경계의 침식. 기존 애플리케이션에는 명확한 경계가 있었습니다. 외부와 내부가 뚜렷하게 구분되어 경계에서 보안을 유지할 수 있었습니다. 보안이 경계에만 유지되는 것이 이상적이지는 않지만 벽을 세우는 것은 여전히 가능했습니다.
서버리스 애플리케이션은 더 다공성이고 세분화되어 있습니다. 수십 또는 수백 개의 기능으로 구성된 서버리스 애플리케이션은 자체 정책, 역할, API, 감사 추적 등을 갖춘 작은 마이크로서비스입니다. 이렇게 하면 공격 표면이 변경되어 각 진입점 뒤에 많은 기능이 숨겨져 있는 소수의 진입점 대신 이제 더 많은 진입점이 있으며 각 진입점은 앱의 작은 부분이 뒤에 있습니다. 이제 애플리케이션을 방어하려면 각 진입점에 대해 생각해야 합니다.
다양한 이벤트가 다음과 같은 기능을 트리거할 수 있습니다.
- 클라우드 스토리지 이벤트(예: AWS S3, Azure Blob storage, Google 클라우드 Storage)
- 스트림 데이터 처리(예: AWS 키네시스)
- 데이터베이스 변경(예: AWS DynamoDB, Azure CosmosDB)를 참조하십시오.
- 코드 수정(예: AWS CodeCommit)을 참조하십시오.
- 알림(예: SMS, 이메일, IoT)
Serverless Security 위협이란 무엇입니까?
공격자의 동기는 동일하지만 서버리스 애플리케이션에 사용할 전술은 변경되어야 합니다. 다음은 이 새로운 응용 프로그램 아키텍처에 고유한 Serverless Security 위협 중 일부입니다.
1. 과도한 특권 기능의 위협
서버리스 애플리케이션을 사용하면 개별 기능에 권한을 적용하고 이러한 권한이 필요한 가장 작은 범위로만 제한되도록 할 수 있습니다. 이를 통해 공격 표면을 크게 최소화하고 공격의 영향을 완화할 수 있습니다.
불행히도 체크 포인트의 최근 연구에 따르면 대다수의 개발자가이 기회를 활용하지 못하고 있습니다. 조사에 따르면 서버리스 애플리케이션의 기능 중 98%가 위험에 처해 있으며 16%는 "심각"한 것으로 간주됩니다. 또한 이러한 함수의 대부분은 필요한 것보다 더 많은 권한으로 프로비전되며, 이는 기능 및 애플리케이션의 보안을 향상시키기 위해 제거할 수 있습니다.
기능을 분석할 때 체크 포인트는 각 기능에 위험 점수를 할당합니다. 이는 발견된 자세 약점을 기반으로 하며, 약점의 특성뿐만 아니라 약점이 발생하는 맥락도 고려합니다. 라이브 애플리케이션에서 수만 개의 기능을 스캔한 후 대부분의 서버리스 애플리케이션이 위험을 최소화하는 데 필요한 만큼 안전하게 배포되지 않고 있음을 발견했습니다. 체크 포인트에서 발견한 가장 큰 보안 태세 문제는 불필요한 권한이고 나머지는 취약한 코드 및 구성입니다.
2. 그라운드호그 데이 공격
서버리스 기능은 일시적이고 수명이 짧기 때문에 공격자가 애플리케이션을 장기적으로 유지하기가 더 어려워집니다. 또한 이것은 서버리스의 많은 보안 이점 중 하나입니다. 그러나 이것이 단순히 공격자의 삶을 더 어렵게 만든다고 해서 공격을 중단할 것이라는 의미는 아닙니다. 그들은 단지 전략을 바꿀 것입니다.
서버리스 기능의 지속 시간이 짧다는 것은 Serverless Security 위협의 형태가 바뀔 수 있음을 의미합니다. 공격자는 예를 들어 몇 개의 신용 카드 번호만 훔치는 훨씬 더 짧은 공격을 구성할 수 있습니다. 이 단일 공격은 우리가 "그라운드호그 데이" 공격이라고 부르는 공격에서 계속 반복됩니다.
3. 우물에 독을 풀다
클라우드 네이티브 리소스의 짧은 수명에도 불구하고 공격자는 여전히 앱에서 장기적인 지속성을 얻을 수 있는 방법을 찾을 수 있습니다. 공격자가 서버리스 애플리케이션의 일시적인 특성을 우회할 수 있는 한 가지 방법은 업스트림 공격 또는 "우물 중독"입니다.
클라우드 네이티브 애플리케이션은 다양한 타사 소스의 코드가 포함된 많은 모듈과 라이브러리로 구성되는 경향이 있습니다. 공격자는 일반적인 프로젝트에 악성 코드를 포함시키기 위해 노력합니다. 그런 다음 우물에 중독을 일으킨 후 클라우드 앱의 악성 코드가 홈으로 전화를 걸어 지침을 얻고 혼란을 일으킬 수 있습니다.
4. Serverless Security 구성 시간 증가
이것이 정확히 보안 "위협"은 아니지만 서버리스 아키텍처를 보호하려는 노력에 더 큰 도전이자 방해가 될 수 있습니다.
서버리스는 애플리케이션 개발 속도 향상의 이점을 제공합니다. 안타깝게도 개발자가 코드를 작성하고 워크로드를 패키징한 다음 보안 운영에서 해당 워크로드에 대한 보안 제어를 적용하는 기존의 보안 접근 방식은 서버리스에서는 작동하지 않습니다.
개발자가 포트, IAM 역할 또는 보안 그룹을 열기 위해 보안을 기다려야 하는 경우 속도 증가의 이점이 빠르게 사라집니다. 해결책은 방정식에서 SecOps를 제거하는 것인데, 이는 실제로 위험할 수 있습니다.
반면에 무수한 서버리스 리소스와 이들 간의 상호 작용에 대한 권한을 구성하는 것은 시간이 많이 걸리는 작업입니다. 또한 개발자가 보안 구성에 시간을 '소비'하면 비용이 많이 들 뿐만 아니라 시간을 이상적으로 사용할 수 없게 될 수 있습니다. CloudGuard 플랫폼과 같은 자동화를 활용하면 과도한 개발자 시간을 할애하지 않고도 Serverless Security 높일 수 있습니다.
5. 보안 처리 시간 증가
서버리스의 또 다른 이점은 실제로 사용한 만큼만 비용을 지불하므로 비용을 절감할 수 있다는 것입니다. 그럼에도 불구하고 사용한 만큼만 비용을 지불하면 처리 시간이 증가하면 비용이 증가합니다.
앱에 과도한 앱 초 구성을 배치하면 잠재적으로 함수에 추가 작업이 추가되어 비용이 증가할 수 있습니다. 보안을 위해 처리 시간을 추가하는 것은 현명한 투자이지만 과도하고 불필요한 비용 증가를 방지하기 위해 적절한 구현이 필요합니다.
위의 Serverless Security 구성 시간 증가와 유사하게, 이는 정확히 위협이 아니라 서버리스 아키텍처를 보호하는 동안 해결해야 하는 과제에 가깝습니다.
피드백