Cloud Service Mesh 보안 권장사항

이 문서에서는 Google Kubernetes Engine(GKE)에서 실행되는 보안 Cloud Service Mesh 구성을 설정하고 관리하기 위한 권장사항을 설명합니다. 문서의 안내는 Cloud Service Mesh를 구성 및 설치하는 데 사용되는 설정 범위를 넘어, 다른 Google Cloud 제품 및 기능과 함께 Cloud Service Mesh를 사용하여 메시의 애플리케이션에 발생할 수 있는 보안 위협을 방지하는 방법을 설명합니다.

이 문서는 Cloud Service Mesh에서 정책을 관리하는 관리자와 서비스를 실행하는 사용자를 대상으로 합니다. 여기에 설명된 보안 방법은 규정 준수 요구사항을 충족하기 위해 서비스 메시 보안을 강화해야 하는 조직에게도 유용합니다.

이 문서는 다음과 같이 정리되어 있습니다.

소개

Cloud Service Mesh는 통합된 방식으로 서비스를 관찰, 관리, 보호하는 데 도움이 되는 기능과 도구를 제공합니다. 네트워크 IP 중심의 접근 방식보다는 애플리케이션 중심의 접근 방식에 따라 신뢰할 수 있는 애플리케이션 ID가 사용됩니다. 기존 애플리케이션 코드를 수정할 필요 없이 서비스 메시지를 투명하게 배포할 수 있습니다. Cloud Service Mesh는 네트워크 동작에 대해 선언적 제어를 제공하므로, 보안 및 네트워킹을 담당하는 관리자의 책임으로부터 애플리케이션 기능의 제공 및 출시하는 팀의 작업을 분리합니다.

Cloud Service Mesh는 정밀한 구성 및 토폴로지를 가능하게 해주는 오픈소스 Istio 서비스 메시를 기반으로 합니다. 조직의 구조에 따라 하나 이상의 팀 또는 역할이 메시 설치 및 구성을 담당할 수 있습니다. 애플리케이션 보호를 위해 기본 Cloud Service Mesh 설정이 선택되지만 경우에 따라 커스텀 구성을 사용하거나 특정 앱, 포트, IP 주소가 메시에 참여하지 못하도록 제외하는 예외를 부여해야 할 수 있습니다. 메시 구성과 보안 예외를 제어할 수 있도록 하는 것이 중요합니다.

공격 벡터 및 보안 위험

공격 벡터

Cloud Service Mesh 보안은 보안 위협이 조직의 보안 경계 내부 및 외부에서 시작된다고 가정하는 제로 트러스트 보안 모델을 따릅니다. 서비스 메시에서 애플리케이션에 위협이 될 수 있는 보안 공격 유형에 대한 예시는 다음과 같습니다.

  • 데이터 무단 반출 공격. 예를 들어 서비스 간 트래픽에서 민감한 정보 또는 사용자 인증 정보를 도청하는 공격입니다.
  • 중간자 공격. 예를 들어 악의적인 서비스가 서비스 간 통신을 확보하거나 수정하기 위해 적법한 서비스로 가장할 수 있습니다.
  • 권한 에스컬레이션 공격. 예를 들어 승격된 권한에 대한 불법 액세스를 통해 네트워크에서 작업을 수행하려는 공격입니다.
  • 서비스 거부(DoS) 공격.
  • 서비스를 손상시키고 조작하여 다른 서비스에서 공격을 시도하는 봇넷 공격입니다.

공격 대상을 기준으로 공격을 분류할 수도 있습니다.

  • 메시 내부 네트워크 공격. 메시 내부 서비스 간 또는 서비스-제어 영역 간 통신을 손상시키거나, 도청하거나, 스푸핑하려는 공격입니다.
  • 제어 영역 공격. 제어 영역이 오작동하도록 하거나(DoS 공격) 제어 영역에서 민감한 정보를 유출시키려는 공격입니다.
  • 메시 에지 공격. 메시 인그레스 또는 이그레스에서 통신을 손상시키거나, 도청하거나, 스푸핑하려는 공격입니다.
  • 메시 작업 공격. 메시 작업을 대상으로 하는 공격입니다. 공격자는 메시에서 악의적인 작업(예: 보안 정책 및 워크로드 이미지 수정)을 수행하기 위해 승격된 권한을 얻으려고 시도할 수 있습니다.

보안 위험

메시에는 보안 공격 외에도 다른 보안 위험이 있습니다. 다음 목록에서는 몇 가지 발생 가능한 보안 위험에 대해 설명합니다.

  • 불완전한 보안 보호. 서비스 메시에 보안을 위한 인증 및 승인 정책이 구성되지 않았을 수 있습니다. 예를 들어 메시의 서비스에 인증 또는 승인 정책이 정의되어 있지 않습니다.
  • 보안 정책 예외. 특정 사용 사례를 수용하기 위해 사용자는 특정 트래픽(내부 또는 외부)에 대한 보안 정책 예외를 만들어 Cloud Service Mesh 보안 정책에서 제외될 수 있습니다. 이러한 경우를 안전하게 처리하려면 정책에 대한 예외를 안전하게 처리 섹션을 참조하세요.
  • 이미지 업그레이드 태만. 메시에 사용된 이미지에서 취약점이 발견될 수 있습니다. 최신 취약점 수정을 통해 메시 구성요소 및 워크로드 이미지를 최신 상태로 유지해야 합니다.
  • 유지보수 부족(전문 기술 또는 리소스 없음). 최신 보안 보호 메커니즘을 활용하기 위해서는 메시 소프트웨어 및 정책 구성을 정기적으로 유지보수해야 합니다.
  • 가시성 부족. 잘못되거나 안전하지 않은 메시 정책 구성 및 비정상적인 메시 트래픽/작업이 메시 관리자의 눈에 띄지 않을 수 있습니다.
  • 구성 드리프트. 메시의 정책 구성이 정보 소스로부터 벗어날 수 있습니다.

서비스 메시 보호 방법

이 섹션에서는 서비스 메시 보호를 위한 운영 지침을 제공합니다.

보안 아키텍처

서비스 메시의 보안은 메시 시스템 및 애플리케이션의 여러 레이어에 있는 구성요소의 보안에 따라 달라집니다. 제안된 Cloud Service Mesh 보안 상황의 대략적인 의도는 서로 다른 레이어에서 여러 보안 메커니즘을 통합하여 서비스 메시를 보호함으로써 제로 트러스트 보안 모델에 따라 전체 시스템 보안을 공동으로 달성하기 위한 것입니다. 다음 다이어그램은 제안된 Cloud Service Mesh 보안 상황을 보여줍니다.

Cloud Service Mesh 보안 상황

Cloud Service Mesh는 다음과 같은 여러 레이어에서 보안을 제공합니다.

  • 메시 에지 보안
    • Cloud Service Mesh 인그레스 보안은 외부 트래픽에 대한 액세스 제어를 제공하고 메시에서 서비스로 노출되는 API에 대한 외부 액세스를 보호합니다.
    • Cloud Service Mesh 이그레스 보안은 내부 워크로드의 아웃바운드 트래픽을 규제합니다.
    • Cloud Service Mesh 사용자 인증은 Google 인프라와 통합되어 웹 브라우저에서 웹 애플리케이션을 실행하는 서비스에 대한 외부 호출을 인증합니다.
    • Cloud Service Mesh 게이트웨이 인증서 관리는 Certificate Authority Service를 사용하여 Cloud Service Mesh 인그레스 및 이그레스 게이트웨이에서 사용하는 비공개 키와 X.509 인증서를 보호하고 순환합니다.
    • Cloud Armor는 외부 DDoS 및 레이어 7 공격을 방어합니다. 이는 메시를 네트워크 공격으로부터 보호하기 위한 웹 애플리케이션 방화벽(WAF) 역할을 합니다. 예를 들어 삽입 및 원격 코드 실행 공격이 있습니다.
    • VPC 및 VPC 서비스 제어는 비공개 네트워크 액세스 제어를 통해 메시 에지를 보호합니다.
  • 클러스터 보안
    • Cloud Service Mesh 상호 TLS(mTLS)는 워크로드 간 트래픽 암호화 및 인증을 적용합니다.
    • Cloud Service Mesh 인증 기관 및 Certificate Authority Service와 같은 관리형 CA는 워크로드에서 사용하는 인증서를 안전하게 프로비저닝하고 관리합니다.
    • Cloud Service Mesh 승인은 ID 및 기타 속성을 기반으로 메시 서비스에 대해 액세스 제어를 적용합니다.
    • GKE Enterprise 보안 대시보드에서는 워크로드에 대한 보안 정책 및 Kubernetes 네트워크 정책 구성을 모니터링할 수 있습니다.
    • Kubernetes 네트워크 정책은 IP 주소, 포드 라벨, 네임스페이스 등을 기준으로 포드 액세스 제어를 적용합니다.
    • 제어 영역 보안은 제어 영역에 대한 공격을 방어합니다. 이 보호 기능은 공격자가 서비스 및 메시 구성 데이터를 수정, 악용, 유출하지 못하도록 방지합니다.
  • 워크로드 보안
    • 메시에서 실행되는 Cloud Service Mesh 바이너리에 공개적으로 알려진 취약점이 적용되지 않도록 Cloud Service Mesh 보안 출시 버전을 최신 상태로 유지합니다.
    • GKE용 워크로드 아이덴티티 제휴를 사용하면 워크로드가 Google 서비스를 안전하게 호출하기 위한 사용자 인증 정보를 가져올 수 있습니다.
    • Kubernetes CNI(컨테이너 네트워크 인터페이스)는 권한이 있는 Cloud Service Mesh 초기 컨테이너의 필요성을 제거하여 권한 에스컬레이션 공격을 방지합니다.
  • 운영자 보안
    • Kubernetes 역할 기반 액세스 제어(RBAC)는 Kubernetes 리소스에 대한 액세스를 제한하고 악의적인 운영자 또는 운영자 명의 도용으로 인한 공격을 완화하도록 운영자 권한을 제한합니다.
    • GKE Enterprise 정책 컨트롤러는 메시에서 정책 구성을 검증하고 감사하여 잘못된 구성을 방지합니다.
    • Google Cloud Binary Authorization은 메시의 워크로드 이미지가 관리자 승인을 받은 이미지인지 확인합니다.
    • Google Cloud 감사 로깅은 메시 작업을 감사합니다.

아래 다이어그램은 Cloud Service Mesh의 통합 보안 솔루션의 통신 및 구성 흐름을 보여줍니다.

보안 다이어그램 트래픽 흐름

클러스터 보안

엄격한 상호 TLS 사용 설정

중간자(MitM) 공격은 통신을 도청하거나 조작하기 위해 두 통신 당사자 사이에 악의적인 항목을 삽입하려고 시도합니다. Cloud Service Mesh는 모든 통신 당사자에 mTLS 인증 및 암호화를 적용하여 MitM 및 데이터 무단 반출을 방지합니다. 허용 모드에서는 양측에서 지원할 경우 mTLS가 사용되지만 mTLS가 없는 연결이 허용됩니다. 반면에 엄격한 mTLS에서는 mTLS를 통해 트래픽을 암호화 및 인증해야 하고 일반 텍스트 트래픽이 허용되지 않습니다.

Cloud Service Mesh를 사용하면 보안 및 규정 준수 요구사항을 충족하기 위해 워크로드 간의 TLS 연결에 대한 최소 TLS 버전을 구성할 수 있습니다.

자세한 내용은 Cloud Service Mesh 예시: mTLS | 메시 전체 mTLS 적용을 참조하세요.

액세스 제어 사용 설정

인증 및 승인 정책과 같은 Cloud Service Mesh 보안 정책은 Cloud Service Mesh 보안 정책에서 서비스 또는 포드를 제외해야 하는 강력한 근거가 있지 않은 한 메시 내부 및 외부의 모든 트래픽에 적용되어야 합니다. 경우에 따라 일부 포트 및 IP 범위에 대해서는 Cloud Service Mesh 보안 정책을 우회해야 하는 적법한 이유가 있을 수 있습니다. 예를 들어 Cloud Service Mesh에서 관리되지 않는 서비스와 고유 연결을 설정해야 할 수 있습니다. 이러한 사용 사례에서 Cloud Service Mesh를 보호하려면 Cloud Service Mesh 정책 예외를 안전하게 처리를 참조하세요.

서비스 액세스 제어는 서비스에 대한 무단 액세스를 방지하는 데 매우 중요합니다. mTLS 시행은 요청을 암호화하고 인증하지만 서비스에 대한 액세스 제어를 적용하려면 메시에 Cloud Service Mesh 승인 정책이 있어야 합니다. 예를 들어 인증된 클라이언트에서 오는 승인되지 않은 요청을 거부합니다.

Cloud Service Mesh 승인 정책은 승인되지 않은 액세스로부터 서비스를 보호하기 위해 액세스 제어를 구성하는 유연한 방법을 제공합니다. Cloud Service Mesh 승인 정책은 인증된 결과로부터 파생되는 인증된 ID에 따라 적용되어야 합니다. Cloud Service Mesh 승인 정책에 따라 mTLS 또는 JSON 웹 토큰(JWT) 기반 인증을 함께 사용해야 합니다.

Cloud Service Mesh 인증 정책 적용

JSON 웹 토큰(JWT)

mTLS 인증 외에도 메시 관리자는 JWT 기반의 서비스 인증 및 요청 승인을 요구할 수 있습니다. Cloud Service Mesh는 JWT 제공업체로 작동하지 않지만 구성된 JSON 웹 키 집합(JWKS) 엔드포인트를 기준으로 JWT를 인증합니다. JWT 인증은 외부 트래픽의 경우 인그레스 게이트웨이에 적용되고 메시 내 트래픽의 경우 내부 서비스에 적용될 수 있습니다. JWT가 최종 호출자를 나타내기 위한 사용자 인증 정보로 사용되고 최종 호출자 대신 호출된다는 증명이 요청된 서비스에 요구되는 경우 mTLS 인증과 함께 JWT 인증을 조합할 수 있습니다. JWT 인증을 시행하면 유효한 사용자 인증 정보 없이 실제 최종 사용자를 대신하여 서비스에 액세스하는 공격을 방어합니다.

Cloud Service Mesh 사용자 인증

Cloud Service Mesh 사용자 인증은 워크로드에 대한 브라우저 기반 최종 사용자 인증 및 액세스 제어를 위한 통합 솔루션입니다. 서비스 메시를 기존 ID 공급업체(IdP)와 통합하여 표준 웹 기반 OpenID Connect(OIDC) 로그인 및 동의 흐름을 구현하고 Cloud Service Mesh 승인 정책을 사용하여 액세스를 제어합니다.

승인 정책 적용

Cloud Service Mesh 승인 정책은 다음을 제어합니다.

  • 서비스에 액세스할 수 있는 사용자 또는 대상
  • 액세스할 수 있는 리소스
  • 허용된 리소스에서 수행할 수 있는 작업

승인 정책은 서비스가 실행되는 실제 ID, 트래픽의 애플리케이션 레이어(레이어 7) 속성(예: 요청 헤더), IP 범위 및 포트와 같은 네트워크 레이어(레이어 3 및 레이어 4) 속성을 기반으로 액세스 제어를 구성하는 다양한 방법입니다.

Cloud Service Mesh 승인 정책은 서비스 또는 데이터에 대한 무단 액세스를 방지하기 위해 인증 결과에서 파생된 인증된 ID를 기반으로 시행해야 합니다.

서비스에 대한 액세스를 허용하도록 승인 정책이 명시적으로 정의되어 있지 않으면 기본적으로 서비스에 대한 액세스가 거부되어야 합니다. 액세스 요청을 거부하는 승인 정책 예시는 승인 정책 권장사항을 참조하세요.

승인 정책은 가능한 한 신뢰를 제한해야 합니다. 예를 들어 서비스 A만 서비스 B의 /admin 경로에 액세스할 수 있도록 서비스에 의해 노출된 개별 URL 경로를 기준으로 서비스 액세스를 정의할 수 있습니다.

승인 정책은 Kubernetes 네트워크 정책과 함께 사용할 수 있습니다. 이 네트워크 정책은 네트워크 레이어(레이어 3 및 레이어 4)에서만 작동하며 Kubernetes 포드 및 Kubernetes 네임스페이스에서 IP 주소 및 포트의 네트워크 액세스를 제어합니다.

메시 서비스 액세스를 위한 토큰 교환 적용

토큰을 훔치고 훔친 토큰을 다시 사용하여 메시 서비스에 액세스하는 토큰 재생 공격을 방어하려면 메시 외부 요청의 토큰을 메시 에지에서 단기 메시 내부 토큰으로 교환해야 합니다.

메시 서비스에 액세스하기 위한 메시 외부의 요청이 메시 서비스에서 인증되고 승인되려면 JWT 또는 쿠키와 같은 토큰을 포함해야 합니다. 메시 외부의 토큰은 장기 지속될 수 있습니다. 토큰 재생 공격을 방어하려면 메시 외부 토큰을 메시 인그레스에서 제한된 범위의 단기 메시 내부 토큰으로 교환해야 합니다. 메시 서비스는 메시 내부 토큰을 인증하고 메시 내부 토큰을 기준으로 액세스 요청을 승인합니다.

다음 단계