블로그

분산 앱 클러스터의 보안을 위한 Service Mesh의 한계 극복

Ankur Singla 썸네일
안쿠르 싱글라
2020년 4월 13일 게시

이는 SaaS 서비스를 구축하고 운영하는 데 필요한 다양한 측면을 다루는 일련의 블로그 중 네 번째 블로그입니다.

  1. 분산 Kubernetes PaaS를 위한 제어 평면
  2. 분산 애플리케이션을 위한 글로벌 서비스 메시
  3. 분산 인프라, 앱 및 데이터를 위한 플랫폼 보안
  4. 분산 클러스터의 응용 프로그램 및 네트워크 보안
  5. 전 세계적으로 분산된 플랫폼에서의 관찰 가능성
  6. 전 세계적으로 분산된 플랫폼의 운영 및 SRE
  7. 분산 마이크로서비스를 위한 Golang 서비스 프레임워크

이전 블로그 에서는 암호화 기술을 사용하여 플랫폼(인프라, 앱, 데이터)을 보호하는 데 따르는 과제에 대한 통찰력을 제공했습니다. 이 블로그에서는 네트워크(인터넷과 내부)에서 발생하는 표적형 공격으로부터 플랫폼을 보호하는 데 사용하는 기술을 다룹니다. 앱이 더 이상 물리적 위치에 제약을 받지 않기 때문에 기존의 경계 기반 방화벽과 서명 기반 보안 솔루션은 더 이상 효과적이지 않습니다. 우리는 최초의 제로 트러스트 보안 구현의 단점을 간략히 설명하고, 이를 머신 러닝과 알고리즘 기술로 보강하여 분산 인프라와 앱 클러스터의 보안을 적절히 유지한 방법을 설명하겠습니다.

TL;DR (요약)

  1. 당사의 앱 간 및 사용자 간 보안 요구 사항은 당사 플랫폼이 여러 클라우드 공급업체(AWS 및 Azure), 글로벌 네트워크 및 엣지 위치에서 몇 개의 모놀리식 앱과 함께 수백 개의 마이크로서비스(여러 Kubernetes 클러스터에 걸쳐)를 실행한다는 사실로 인해 복잡해졌습니다.
     
  2. 또한 우리는 개발자, 운영팀, 고객 개발자, 운영팀 및 최종 사용자에게 공유 인프라에 대한 선택적 액세스를 제공하는 프로세스를 구축하고 강력한 네트워크 + 앱 보안 솔루션을 제공하라는 요청을 받았습니다. PCI-DSS, SOC 등의 규정 준수 요구 사항을 충족해야 한다는 사실로 인해 상황은 더욱 복잡해졌습니다.
     
  3. 우리는 이미 글로벌 서비스 메시와 API 게이트웨이를 기반으로 제로 트러스트 솔루션을 구축했지만 시스템 취약성, 리소스 고갈, 봇/맬웨어의 인터넷 공격, 인증되지 않은 액세스를 제공하는 일부 서비스의 요구 사항 등 많은 보안 문제는 해결하지 못했습니다. 또한, 때로는 보안 작전팀이 개발자로부터 API 정보를 얻는 데 어려움을 겪었습니다. 이는 액세스 허용 목록에 의존하는 우수한 제로 트러스트 배포에 필수적인 사항입니다.
     
  4. 이러한 요구 사항을 충족하려면 플랫폼 팀이 공급업체/클라우드 공급업체로부터 서비스를 조달하거나 L3-L7+ 데이터 경로(자세한 내용은 여기 참조)에 네트워크 방화벽, 앱 방화벽, DDoS 보호, 권한 있는 액세스 관리 등의 추가 보안 기능을 추가해야 했습니다. 기존 공급업체/클라우드 공급업체가 통합 정책, 관찰성 및 자동화된 API 검색 기능을 제공하는 툴로 이러한 문제를 해결할 수 없다는 사실을 고려하여 우리는 데이터 경로와 제어 평면을 보강하기 위한 내부 프로젝트에 착수한다는 어려운 결정을 내려야 했습니다.
     
  5. 네트워크 + 앱 보안 기능을 데이터 경로에 구축하는 작업의 일환으로 우리는 많은 새로운 기능을 추가하게 되었는데, 이는 지금까지 어떤 네트워크 데이터 경로에서도 달성된 적이 없는 기능입니다. 우리는 네트워크 + 앱 트래픽에 대한 알고리즘 보안 기능과 머신 러닝을 결합했으며, 네트워크, HTTP, API 등 스택 전반에서 작동하는 프로그래밍 가능한 정책 엔진도 함께 사용했습니다. 그 결과, 이제 배포 환경, 트래픽 모델 및 지연 시간 요구 사항에 따라 다양한 보안 기능을 제공할 수 있게 되었습니다. 이를 통해 글로벌 서비스 메시의 보안이 강화되었고, SOC 팀의 오탐지 수가 줄어들었으며, 지연 시간과 컴퓨팅 리소스가 크게 감소했습니다.

서비스 메시 및 제로 트러스트 아키텍처의 한계

당사 플랫폼은 엣지, 글로벌 네트워크, AWS 및 Azure 퍼블릭 클라우드에서 자체 클러스터를 운영하는 여러 팀에서 많은 수의 앱을 실행합니다. 대부분의 워크로드는 Kubernetes를 사용하여 마이크로서비스로 오케스트레이션되지만, Terraform을 사용하여 관리하는 소수의 대규모 모놀리스(예: Elasticsearch)도 있습니다. 그림 1은 우리 플랫폼의 분산적 특성을 보여줍니다. 예를 들어, 18개 이상의 글로벌 네트워크 PoP(물리적 서버 수십 개에서 100개가 조금 넘는 수) 각각에서 수천 개의 앱 포드를 실행합니다. 하지만 오늘날에는 3,000개 이상의 활성 위치(각 위치마다 1~7개의 컴퓨팅 장치 있음)에서 수십 개의 앱 포드를 실행하는 개별 고객 배포가 있습니다.

메시 제한 1
그림 1 : Volterra 플랫폼 전반의 분산 앱 및 데이터

이 플랫폼은 완전한 멀티 테넌트 방식으로, 각 노드는 다양한 고객(및 당사 자체)의 워크로드를 실행합니다. 이러한 앱 중 일부는 공개 인터넷에 노출되어 있으므로 앱과의 모든 통신이 보안되도록 해야 합니다. 이전 두 블로그에서 설명한 대로, 우리는 서비스 메시 와 API 게이트웨이를 구동하는 자체 L3-L7+ 네트워크 데이터 경로(VoltMesh)와 함께 강력한 ID, 인증 및 권한 부여 시스템을 구축했습니다. 그림 2에서 볼 수 있듯이 이를 통해 앱 클러스터(mTLS), 사용자(TLS/mTLS), 직원(mTLS) 전반에 걸쳐 전송 수준 보안을 제공하고, 인증+권한 부여에 따른 액세스 제어도 제공할 수 있었습니다.

메시 제한 2
그림 2: 서비스 메시 및 API 게이트웨이를 사용한 전송 보안

이러한 제로 트러스트 구현은 많은 이점을 제공하지만, 여러 보안 문제는 자동으로 해결하지 못했습니다.

  1. 시스템 취약성 - 시스템 취약성이나 권한이 있지만 악의적인 직원으로 인해 앱이 손상될 수 있습니다. 이러한 상황을 감지하고 자동으로 시정 조치를 취하고 SRE 팀에 경고하는 메커니즘이 필요합니다.
     
  2. 리소스 고갈 — 합법적이고 승인된 클라이언트 액세스조차도 설계가 좋지 않아 앱 리소스를 천천히 고갈시키는 상황이 많이 있습니다. 이러한 상황은 다른 사용자의 성능을 크게 저하시킬 수 있습니다.
     
  3. 인터넷 공격 - 우리(및 고객)의 인프라와 앱 중 상당수가 공개 인터넷에 직접 노출되어 있기 때문에 이러한 리소스는 악의적인 사용자, 봇, 맬웨어로부터 지속적으로 공격을 받습니다. 다른 사용자에게 빠른 대응 시간을 제공하기 위해서는 이러한 리소스를 서비스 거부, 볼륨형 및 침입 공격으로부터 탐지하고 보호해야 합니다.
     
  4. 인증되지 않은 서비스 - 대부분의 앱에는 인증이 필요하지만(제로 트러스트에도 필요함) 앱을 제한할 수 없는 경우도 있습니다. 결과적으로 이러한 앱에는 네트워크 기반 솔루션을 사용한 추가 보호가 필요합니다.

이 플랫폼을 개발해 온 지난 2.5년 동안 우리는 개발자들이 오픈소스 앱을 통합하고 컨테이너화한 다음 DevOps 팀에 플랫폼에 배포해 달라고 요청하는 경우가 많다는 사실을 깨달았습니다. 하지만 보안 팀에서 통신을 허용 목록에 추가하기 위한 정책을 만드는 데 필요한 이러한 앱 내의 API 수준 상호작용에 대한 세부 정보가 부족한 경우가 많습니다. 이는 앱에서 사용하는 API만 허용하고 다른 모든 트래픽을 차단하는 허용 목록 정책을 요구하기 때문에 제로 트러스트 보안 구현에 큰 걸림돌입니다. 이 요구 사항에 예외를 만들 때마다 일부 앱은 매우 기본적인 네트워크 수준 세분화되어 공격 표면이 늘어났습니다.

Zero-trust 서비스 메시 증강

결과적으로, 위에 나열된 문제를 처리하기 위해 기존의 제로 트러스트 보안 솔루션을 추가적인 보안 기능으로 보강해야 했습니다. 우리는 플랫폼에 구축해야 할 추가 보안 기능 목록을 확인했습니다.

  1. API 발견 및 제어 - 개발자에 의존하지 않고 실행 중인 앱에서 API를 학습하고 앱/API 허용 목록 정책 생성을 자동화하는 기능을 구축합니다.
  2. 이상 감지 - 모든 소스 유형(신뢰할 수 있는 사용자/앱 또는 신뢰할 수 없는 사용자/앱)의 트래픽에 대한 이상 동작을 감지하고 보호하는 기능
  3. 동작 프로파일링 - 리소스 고갈, 앱/API 공격(인터넷 또는 내부 네트워크)으로부터 앱을 보호하고 인터넷에서 인프라 및/또는 앱으로의 볼륨형 공격으로부터 보호합니다.
  4. 로깅 및 시각화 - 향후 포렌식 및/또는 규정 준수 요구 사항을 위해 모든 액세스를 로깅하고 추적하는 기능

우리는 이러한 문제를 해결하기 위해 기존의 서명 기반 기술, 통계적 알고리즘, 그리고 보다 동적인 머신 러닝 접근 방식을 결합하기로 결정했습니다. 이를 위해 SaaS 백엔드를 변경하고 네트워크 데이터 경로에 새로운 기능을 추가해야 했습니다.

API 발견 및 제어를 위한 딥 러닝

플랫폼을 잠그기 위해 모든 앱에 대한 API 화이트리스트에 따라 네트워크 연결만 허용합니다. 이를 위해 보안팀은 개발자와 협력하고 프로그래밍 가능한 정책 엔진에 올바른 API 정보가 제공되도록 해야 합니다. 우리는 우리 서비스 프레임워크를 사용하여 구축되지 않은 앱에 대해 개발자가 이러한 정보를 제공하는 것이 불가능하다는 사실을 금방 깨달았습니다.

서비스 메시 프록시가 앱에 대한 모든 액세스의 네트워크 경로에 있으므로 프록시를 통과하는 모든 액세스에 대한 런타임 분석을 수행하여 앱에서 노출되는 API와 정적 리소스를 알아보기로 했습니다. 이 접근 방식의 과제는 URL을 검사하고 동적으로 생성된 구성 요소를 분리하여 API 엔드포인트를 식별하는 것입니다. 예를 들어, API "api/user/<user_id>/vehicle/"의 경우 프록시는 다음과 같은 액세스를 볼 수 있습니다.

이런 요청은 수백만 건에 달할 수 있으므로 해독하기가 매우 어렵습니다. 결과적으로, 이러한 관련 요청에서 동적 구성 요소를 식별하는 작업은 딥 러닝과 그래프 분석을 통해 수행됩니다. 우리는 전체 URL 구성 요소 세트를 그래프로 표현한 다음, 동적으로 생성된 구성 요소의 특정 속성을 포착하는 기능 세트를 사용하여 유사한 속성을 가진 하위 그래프를 찾기 위해 그래프 클러스터링을 수행합니다. 이러한 속성은 다음과 같습니다.

  • 구조적 특성
  • 노드의 엔트로피
  • 그래프의 다양한 부분 사이의 자카드 유사성
  • 잘 알려진 딥러닝 방법을 사용한 간단한 문자열 분류

결과적으로 동적 구성 요소가 분류되고 시스템 출력은 다음과 같습니다.

API의 머신 러닝을 사용하면 서비스 메시 프록시에서 시행할 수 있는 정책을 쉽고 자동으로 생성할 수 있습니다. 발견된 API 엔드포인트를 기반으로 어떤 앱이 다른 앱과 통신하기 위해 어떤 API를 사용하는지, 이러한 API의 일반적인 동작 등과 같은 기타 속성도 알아낼 수 있습니다. 이를 통해 보안 팀이 포렌식, 검색 및 API 수준의 마이크로 세분화를 위해 서비스 간 상호 작용을 시각화하는 데 도움이 되는 서비스 그래프를 구축할 수 있습니다.

방화벽의 단점 식별

나머지 두 가지 기능(이상 탐지 및 동작 프로파일링)을 추가하기 전에, 우리는 기존 솔루션이 도움이 될 수 있는지 알아보기로 했습니다. 시중에는 다양한 경계 방화벽과 웹 앱 방화벽 제품이 있지만, 이러한 솔루션의 대부분은 인터넷에 연결된 앱을 보호하는 데 중점을 두고 있습니다. 그들은 서비스되는 트래픽이 웹 트래픽이라는 가정을 하고 HTML, 자바스크립트, SQL, CMS 등에 대한 타깃형 보호 기능을 제공합니다. 이를 통해 취약점과 알려진 익스플로잇을 포착하기 위한 서명과 규칙을 작성하는 것이 비교적 쉬워집니다.

이 기능이 웹 트래픽에 중요한 것은 사실이지만, 우리 환경에서는 점점 더 많은 양의 API와 머신 간 트래픽도 처리해야 합니다. 이를 해결하려면 보안팀에서 OWASP CRS와 같은 알려진 일반적인 웹 규칙에 해당하지 않는 앱별 규칙을 작성해야 합니다. 일반적으로 보안 관리자는 앱에 대해 거의 알지 못하며, 환경의 동적 특성으로 인해 앱 유형과 구조를 추적하여 앱별 규칙을 작성하는 것이 더욱 어려워집니다. 따라서 당사 플랫폼 팀은 네트워크 데이터 경로에서 이 기능을 제공하지만, 보안 팀에서는 자주 사용하지 않습니다.

우리 네트워크에서 상당한 양의 데이터를 확보한 또 다른 문제는 앱 공격이 시간이 지남에 따라 훨씬 더 정교해지고 있다는 것입니다. 공격자는 HTTP/TCP 서명 등을 살펴서 API, 앱, 기반 인프라, OS 유형의 세부 사항을 파악하기 위해 며칠 동안 정찰을 수행합니다. 이러한 상황에서 기존의 서명 및 규칙 기반 접근 방식은 매우 제한적으로 사용되며, 우리는 사용자 행동을 자동으로 학습하고 좋은 행동과 나쁜 행동을 강제하는 AI 기반 접근 방식을 계속 사용하기로 결정했습니다.

행동 프로파일링을 위한 머신 러닝

대부분의 앱은 특정 워크플로(API 시퀀스)와 컨텍스트(API 내 데이터)를 갖고 있으며, 이를 기반으로 다양한 사용 사례/배포가 설계되고 일반적으로 앱 사용자가 이를 따릅니다. 우리는 이러한 속성을 활용하여 기계 학습 알고리즘을 훈련하여 앱과 일반적인 사용자 상호작용에서 "유효한" 행동 패턴을 모델링합니다.

그림 3에서 볼 수 있듯이, 데이터 경로는 관련 데이터와 함께 각 API에 대한 요청/응답을 샘플링하여 중앙 학습 엔진으로 전송합니다. 이 엔진은 유효한 행동 패턴 모델을 지속적으로 생성하고 업데이트하며, 이후 데이터 경로에서 실행되는 추론 엔진이 이를 사용하여 의심스러운 행동에 대한 경고/차단을 실행합니다.

메시 제한 3
그림 3: Learning Core와 분산 추론 엔진 간의 상호 작용

학습 엔진은 API 순서, 요청 간 간격, 동일한 API에 대한 반복 요청, 인증 실패 등 여러 가지 측정 항목을 살펴봅니다. 이러한 측정항목은 각 사용자별로 분석되고 집계되어 좋은 행동과 나쁜 행동을 분류합니다. 또한 우리는 "좋은 행동"의 여러 다른 시퀀스를 식별하기 위해 행동 클러스터링을 수행합니다. 이를 설명하기 위해 예를 들어 보겠습니다.

  • 이 모델은 여러 사용자를 대상으로 분석을 수행하여 좋은 행동의 순서를 정의합니다. 각 색상은 개별적인 다른 API 호출을 나타냅니다.
메시-한계-4
그림 4: API의 일반적인 순서

    다음 API 시퀀스는 시스템에서 의심스럽거나 잘못된 동작으로 표시되며 시스템에서 자동으로 완화하거나 관리자가 개입할 수 있는 경고를 생성합니다.

메시 제한 5
그림 5: 의심스러운 API 시퀀스

1년 전 이 시스템을 생산에 투입한 이후, 우리는 사용량과 고객 피드백을 토대로 모델을 지속적으로 개선해 왔습니다. 우리는 다음과 같은 유형의 공격을 성공적으로 식별할 수 있었습니다. 

  • 앱의 취약점을 찾고 앱에서 노출된 모든 API의 맵을 생성하기 위해 앱의 정찰을 수행하는 크롤러/스캐너
     
  • 취약한 API에 여러 공격 벡터를 실행하여 지속적인 악의적 활동
     
  • 리소스 고갈로 이어지는 HTTP 수준 서비스 거부 공격(예: API에 대한 여러 번의 로그인 시도)
     
  • 정보를 수집하도록 설계된 봇에 의한 데이터 누출(예: 경쟁자가 전자상거래 사이트에서 제공하는 가격 정보)
     
  • 무차별 대입 공격 - 로그인/비밀번호에 대한 사전 공격
     
  • 좋은 봇 식별(예: Google, Bing 크롤러)

그럼에도 불구하고 우리는 이 접근 방식에는 몇 가지 문제가 있다는 것을 깨달았습니다. 즉, 비정상 탐지 기술을 적용해야 하는 저속 공격(무차별 대입 공격, 앱 서비스 거부 공격, 스캐너)을 찾아낼 수 없습니다.

알고리즘 + AI 기반 이상 감지

때로는 우리의 행동 분석 기술의 레이더에 잡히지 않는 대규모 분산 봇넷을 이용한 매우 정교한 공격을 볼 수도 있습니다. 이러한 공격의 예는 다음과 같습니다. 

  • 분산된 무차별 대입 공격
  • 분산 사전 기반 계정 인수 공격
  • 여러 클라이언트에서 취약점을 찾아 악용하기 위한 분산 스캐너
  • 고도로 분산된 봇넷의 HTTP DoS 공격
  • 컴퓨팅 집약적 API의 소수 하위 집합을 타겟으로 하는 봇넷
  • 데이터가 많은 API를 타겟으로 하는 봇넷으로 리소스를 고갈시키려는 시도

네트워크 데이터 경로가 글로벌 네트워크 전반의 각 노드에서 정보를 수집하기 때문에 요청 비율, 오류 비율, 응답 처리량 등과 같은 특정 앱의 집계 지표에 대한 분석을 수행하는 것이 비교적 쉬워집니다. 이러한 분석을 통해 분산형 공격을 감지하고 해당 봇넷에 포함될 수 있는 사용자를 식별하여 (모든 노드에서) 공격을 완화할 수 있습니다. 다양한 시간 창(마지막 5분, 30분, 4시간, 24시간)에서 요청 속도를 살펴보고, 주어진 시간 창 내에서 요청 속도가 높으면 시스템에서 액세스 로그에 대한 다음과 같은 심층 분석을 수행하는 예를 들어보겠습니다. 

  • 소스 IP 주소 확산이 일반적인 것보다 더 높거나 낮은지 분석합니다. 다수의 고유한 소스 IP에서 요청이 발생한 경우, 각 소스 IP에 대해 보다 공격적인 버전의 사용자 행동 분석을 실시하는 매우 분산된 공격이 있음을 나타냅니다.
  • 각 소스 IP 주소에 대해 보다 공격적인 사용자 동작 분석을 실행하여 의심 점수를 할당하고 구성된 완화 조치를 취합니다.
  • 대부분의 요청이 평소보다 적은 수의 API 엔드포인트로 전송된 경우, 무차별 대입 공격이나 DoS 공격을 나타냅니다. APIEP 확산이 평소보다 큰 경우 분산 크롤러, 스캐너 또는 DoS 공격을 나타냅니다.

이상 탐지는 방화벽 어플라이언스의 침입 탐지 및 방지(IDS/IPS)를 위한 중요한 기술이었지만, 이러한 어플라이언스는 글로벌 앱 계층 공격을 완화할 수 없습니다. 글로벌 플랫폼 전반에서 API 마크업과 학습을 수행할 수 있는 역량을 바탕으로, 이제 분산 네트워크 전반에서 소스에 대한 공격을 억제할 수 있습니다.

앱 + 네트워크 보안을 위한 머신 러닝의 이점

우리는 서비스 메시와 API 게이트웨이를 기반으로 한 제로 트러스트 구현에 매우 만족했지만, 그것이 분산된 앱 클러스터를 취약점과 악의적인 공격으로부터 보호하기에 포괄적이지 않다는 것을 깨달았습니다. 더 나은 보안 솔루션을 제공하기 위해 기존의 시그니처+규칙 기반 기술과 더불어 동작 분석+이상 탐지를 위한 머신 러닝으로 보완해야 했습니다.

우리는 중앙 집중형 SaaS에서 실행되는 학습 코어와 함께 L3-L7+ 네트워크 데이터 경로에 분산 추론을 추가하여 세 가지 중요한 이점을 얻었습니다. 

  1. 엔드투엔드 제로 트러스트 네트워크 - 이제 전체 플랫폼에서 API 수준의 마이크로 세그먼테이션을 적용할 수 있는 기능이 있습니다(100% 빈틈 없이). 전체 네트워크는 API 수준 액세스와 네트워크 수준 액세스가 없는 글로벌 분산 프록시입니다.
     
  2. 지속적으로 모델을 조정하여 거짓 양성 판정을 82% 이상 줄였고 , NOC와 SOC 팀이 처리해야 하는 거짓 양성 판정의 수를 크게 줄였습니다. 기존 도구는 수많은 경보를 발생시켜 전혀 쓸모가 없었기 때문에 이는 큰 문제였습니다.
     
  3. 기존 규칙과 서명 기반 알고리즘으로 수행되던 작업을 더 많이 새로운 머신 러닝 코어로 천천히 마이그레이션하여 지연 시간과 컴퓨팅 활용도를 크게 줄였습니다 .

네트워크 및 앱 보안은 끝없는 활주로와 같으며, 아직도 추가해야 할 새로운 기능이 잔뜩 쌓여 있는 듯합니다. 가까운 시일 내에 다시 방문하여 우리가 구현한 증분적 알고리즘과 기술에 대한 추가적인 통찰력을 공유하겠습니다.

계속됩니다…

이 블로그 시리즈에서는 퍼블릭 클라우드의 많은 앱 클러스터, 프라이빗 네트워크 PoP, 엣지 사이트를 활용하여 전 세계적으로 분산된 SaaS 서비스를 구축하고 운영하는 데 필요한 다양한 측면을 다룰 것입니다. 다음은 "글로벌 분산 플랫폼 전반의 관찰 가능성"(곧 출시)입니다.