서비스 보안

이 문서에서는 Cloud Service Mesh의 서비스 보안에 대해 간략하게 설명합니다. 이 문서는 인증, 암호화, 승인을 배포에 추가하려는 Cloud Service Mesh 사용자를 대상으로 합니다. 이 문서에서는 사용자가 Cloud Service Mesh 개요 및 프록시리스 gRPC 애플리케이션에 익숙하다고 가정합니다.

Cloud Service Mesh를 사용하면 메시에서 서비스 간 통신을 보호할 수 있습니다. 메시의 각 서비스에는 ID가 있습니다. 다음 기능은 보안 통신을 지원하는 데 도움이 됩니다.

  • Envoy를 사용하는 Cloud Service Mesh와 프록시리스 gRPC 애플리케이션을 사용하는 Cloud Service Mesh 모두에 전송 계층 보안(TLS) 및 상호 TLS(mTLS)를 사용하는 인증 및 암호화. 클라이언트 TLS 정책과 서버 TLS 정책은 서비스가 서로에게 ID를 증명하고 암호화된 통신 채널을 사용해야 하는지 여부를 제어합니다.
  • 클라이언트 및 요청의 특성에 따른 승인. 승인 정책은 서비스가 다른 서비스에 액세스하도록 허용할지 여부와 허용되는 작업을 제어합니다.

비공개 인증 기관(CA) 서비스인 Google의 Certificate Authority Service가 제공하는 인증서와 키를 사용하면 서비스 보안을 보다 쉽게 유지할 수 있습니다. CA 서비스는 GKE 메시 인증서를 제공합니다. GKE 메시 인증서 기능과 Cloud Service Mesh를 사용하면 이러한 인증서를 자동으로 배포하고 워크로드에서 사용할 수 있습니다. 포드를 수정하면 워크로드가 mTLS 사용자 인증 정보를 수신하고 사용할 수 있게 할 수 있습니다. 현재 GKE 기반 워크로드에서만 Cloud Service Mesh 서비스 보안을 사용할 수 있습니다.

최신 마이크로서비스 기반 아키텍처에서는 더 작고 집중적인 서비스가 대규모 모놀리식 애플리케이션을 대체합니다. 서비스 호출은 네트워크를 통해 서로 통신합니다. 이러한 호출(모놀리식 애플리케이션에서 처리 중인 호출)은 보안 문제가 있으므로 인증, 암호화, 승인하는 것이 가장 좋습니다. 이러한 단계는 트래픽이 네트워크 내부에서 발생하는지 외부에서 발생하는지 여부에 상관없이 모든 네트워크 트래픽이 위험한 것으로 간주되는 제로 트러스트 원칙을 지원합니다.

서비스 메시 설계 패턴은 서비스 간 통신과 관련된 복잡성을 비즈니스 로직과 분리합니다. 대신 데이터 영역에서 이러한 복잡성을 처리합니다. 서비스 메시 설계 패턴은 애플리케이션 복잡성을 줄이는 것 외에도 구현 및 관리가 어려울 수 있는 보안 패턴을 사용 설정합니다.

이 모델에서는 프록시리스 gRPC 또는 Envoy 사이드카가 Cloud Service Mesh에서 구성 정보를 가져오고 CA 서비스 풀에서 인증서를 가져와 통신을 안전하게 인증하고 암호화합니다.

이러한 보안 기능은 다음과 같은 이점을 제공하므로 Cloud Service Mesh 배포 프로세스가 더 쉬워집니다.

  • 메시의 모든 서비스에 키 및 인증서 자동 프로비저닝
  • 키 및 인증서를 자동 순환하여 보안을 강화
  • Google Kubernetes Engine(GKE)과 통합되어 배포 설명자, 라벨과 같은 모든 기능을 사용할 수 있습니다.
  • Cloud Service Mesh 및 CA 서비스 관리형 비공개 인증 기관 풀을 포함한 Google 관리 서비스의 고가용성
  • Google Identity and Access Management(IAM)에 연결된 보안: 승인된 Google 서비스 계정을 기반으로 서비스 승인
  • Envoy 기반 및 프록시리스 워크로드와 원활한 상호 운용성. 예를 들어 서비스가 Envoy 프록시 뒤에 있을 수 있지만 클라이언트는 gRPC 프록시리스 서비스 메시 보안을 사용합니다. 반대로 서비스는 gRPC 프록시리스 서비스 메시 보안 뒤에 있을 수 있지만 클라이언트는 Envoy 프록시를 사용합니다.

서비스 간 통신 보호

Cloud Service Mesh는 TLS를 사용하는 암호화와 인증을 통해 승인과 서비스 간 보안을 제공합니다. 클라이언트 TLS 정책과 서버 TLS 정책을 통해 서비스에서 다음을 수행할 수 있습니다.

  • ID 어설션 및 검증
  • TLS 또는 mTLS를 사용하여 통신 세션 암호화

서비스 메시에서는 데이터 영역이 이러한 유형의 보안을 처리하므로 애플리케이션이 보안을 위해 특별한 프로비저닝을 만들 필요가 없습니다.

승인 정책은 정의한 규칙에 따라 액세스를 거부 또는 허용할 수 있게 해줍니다.

암호화에 TLS 사용

한 서비스가 HTTP, HTTP/2, 또는 gRPC 프로토콜을 사용하여 다른 서비스를 호출하면 해당 네트워크를 전송하는 트래픽이 일반 텍스트로 표시됩니다. 이 트래픽은 공격자가 트래픽을 가로채서 콘텐츠를 검사하거나 조작할 수 있는 중간자 공격의 대상이 될 수 있습니다.

이 잠재적인 문제를 완화하려면 Cloud Service Mesh와 함께 TLS를 통해 HTTP, HTTP/2 또는 gRPC를 사용하면 됩니다. TLS를 통해 이러한 프로토콜을 사용하면 클라이언트와 서버 간의 트래픽은 서버 인증서를 기반으로 하는 TLS를 사용하여 암호화됩니다. 트래픽이 더 이상 일반 텍스트로 표시되지 않으므로 공격자가 콘텐츠를 가로채서 검사하거나 조작할 가능성이 줄어듭니다.

인증에 TLS 사용

한 서비스가 다른 서비스를 호출할 때 다음 질문을 고려해보세요.

  • 클라이언트가 가짜 서버가 아닌 올바른 서버로부터 응답을 받고 있는지 어떻게 알 수 있나요? 예를 들어 HTTP 기반의 일반적인 요청-응답 상호작용에서 클라이언트는 서버의 ID를 확인하지 않습니다.

  • 공격자가 해당 트래픽을 가로채면 어떻게 되나요? 예를 들어 HTTP 트래픽은 암호화되지 않으므로 트래픽을 수신하는 모든 사용자가 콘텐츠를 검사할 수 있습니다. 이를 중간자 공격이라고 합니다.

이러한 문제를 완화하기 위해 TLS를 통해 HTTP, HTTP/2, gRPC를 사용할 수 있습니다. 클라이언트와 서버 간의 이러한 교환에서 서버는 서버 인증서를 사용하여 클라이언트에 ID를 증명해야 합니다. 그러면 요청과 응답이 TLS를 사용하여 암호화됩니다.

상호 TLS 인증

Cloud Service Mesh에서 클라이언트와 서버의 애플리케이션 네트워킹을 구성할 때(예: 클라이언트 측에서 Envoy 프록시를 구성하고 서버 측에 다른 Envoy 프록시를 구성) 상호 인증과 같은 고급 인증 패턴을 활용할 수 있습니다.

상호 인증을 기반으로 하지 않는 일반적인 HTTP over TLS 교환에서 서버에는 클라이언트와 서버 간의 통신을 암호화하는 데 사용하는 인증서가 있습니다. 클라이언트는 TLS 핸드셰이크 중에 서버가 반환하는 서명을 확인하여 서버의 ID를 검증할 수 있습니다. 그러나 서버는 클라이언트의 ID를 검증하지 않습니다.

상호 인증이 사용 설정되면 클라이언트도 인증서를 가집니다. 클라이언트는 이전 단락에서 설명한 대로 서버의 ID를 확인하며 서버도 클라이언트의 ID를 확인할 수 있습니다. 클라이언트 인증서와 서버 인증서 둘 다 통신 채널을 암호화하는 데 사용됩니다. 이렇게 하면 서버에서 확인된 클라이언트 ID를 기반으로 클라이언트를 승인할 수도 있습니다.

서비스 메시의 상호 TLS(mTLS) 인증
서비스 메시의 상호 TLS(mTLS) 인증(확대하려면 클릭)

서비스 호출 승인

승인 정책을 사용하여 서비스 액세스를 허용하거나 거부하도록 선택할 수 있습니다. Cloud Service Mesh를 사용하면 요청 매개변수를 기반으로 액세스를 승인하도록 허용 규칙과 거부 규칙을 정의할 수 있습니다. mTLS 연결의 client-cert에서 파생되는 클라이언트 ID, 소스 IP 주소, 호스트 일치, 메서드 일치, 헤더 일치를 포함하여 레이어 3 및 레이어 7 매개변수를 기반으로 이러한 규칙을 만들 수 있습니다. 다음 다이어그램은 Envoy 프록시를 사용한 승인을 보여줍니다. 이 프로세스는 gRPC 클라이언트와 비슷합니다.

서비스 메시에서 승인
Envoy를 사용하는 서비스 메시 승인(확대하려면 클릭)

승인을 사용하여 액세스 제한

서비스 메시 내의 권장사항은 최소 권한의 원칙을 준수하는 것입니다. 서비스에 종속되는 호출자로만 서비스 액세스를 제한하여 이 원칙을 준수할 수 있습니다. 호출자가 승인되지 않은 서비스에 액세스하려고 시도하면 이러한 시도가 거부됩니다.

Cloud Service Mesh를 사용하면 정의한 규칙에 따라 데이터 영역에서 서비스 액세스를 허용 또는 거부할 수 있도록 승인 정책을 구성할 수 있습니다. 이러한 정책은 다음 두 가지 구성요소로 이루어집니다.

  • 작업: 허용 또는 거부
  • 규칙 목록

요청 또는 RPC가 전송되면 호출된 서비스에 대한 Cloud Service Mesh 클라이언트에서 규칙 일치가 있는지 여부를 확인합니다. 일치가 있으면 요청 또는 RPC가 허용되거나 거부됩니다. 다음과 같이 속성과 일치시킬 규칙을 정의할 수 있습니다.

  • mTLS가 사용된 경우 호출 서비스의 Kubernetes 서비스 계정
  • 호출 서비스의 IP 주소(또는 주소 범위)
  • 대상 서비스의 포트
  • 호스트 이름, 메서드, 사용자 정의 HTTP 헤더를 포함한 요청의 HTTP 속성

보안 이름 지정

추가 보안 메커니즘으로 Cloud Service Mesh를 사용하여 보안 이름 지정을 구성할 수 있습니다. 이렇게 하면 클라이언트가 연결하려고 시도하는 특정 서비스에 대해 허용된 이름 목록 또는 SPIFFE(Secure Production Identity Framework for Everyone) ID를 정의할 수 있습니다. TLS 교환 중에 서비스의 백엔드는 X.509 인증서를 클라이언트에 반환합니다. 그러면 클라이언트가 인증서를 검사하여 X.509 인증서가 이름 또는 SPIFFE ID 중 하나와 일치하는지 확인합니다. SPIFFE ID에 대한 자세한 내용은 Secure Production Identity Framework for Everyone을 참조하세요.

게이트웨이의 트래픽 보안

게이트웨이를 구성하려면 Cloud Service Mesh를 사용하면 됩니다. 게이트웨이는 일반적으로 다음 중 하나의 역할을 하는 독립형 Envoy 프록시입니다.

  • 메시 또는 다른 도메인에 들어오는 트래픽을 처리하는 인그레스 게이트웨이
  • 메시 또는 다른 도메인에서 나가는 트래픽을 처리하는 이그레스 게이트웨이
  • 인바운드 트래픽을 하나 이상의 서비스에 분산하는 역방향 프록시 또는 중간 프록시

메시로 또는 메시에서 트래픽을 전송하려는 클라이언트는 게이트웨이로 트래픽을 전송합니다. 그러면 게이트웨이가 Cloud Service Mesh에 설정한 규칙에 따라 요청을 처리합니다. 예를 들어 인그레스 게이트웨이를 통해 메시로 들어오는 트래픽이 TLS를 사용하여 암호화되도록 할 수 있습니다.

보안 구성요소

Cloud Service Mesh 서비스 보안은 클라이언트 TLS 정책, 서버 TLS 정책, 승인 정책을 지원합니다. Cloud Service Mesh가 데이터 영역을 구성하고 보안 기능을 사용 설정할 수 있도록 이러한 정책을 만듭니다. 이러한 정책을 만들거나 업데이트하기 위해 애플리케이션을 변경할 필요가 없습니다.

암호화 및 지원되는 인증 모드

한 서비스가 다른 서비스를 호출할 때 보안 통신을 설정하는 첫 번째 단계는 각 서비스가 다른 서비스에 ID를 증명하도록 하는 것입니다. 서비스가 ID를 증명해야 하는 정도는 구성한 TLS 모드에 따라 결정됩니다.

다음 보안 수준을 구성할 수 있습니다.

  • 암호화되지 않음/인증되지 않음
  • TLS
  • 상호 TLS(mTLS)
  • 허용: 클라이언트가 연결을 시작하는 방법에 따라 mTLS 또는 암호화되지 않음/인증되지 않음

인증서 및 인증 기관

인증서 및 신뢰할 수 있는 인증 기관(CA)은 서비스 메시와 같은 분산 시스템에서 신뢰를 위한 기반을 제공합니다. 서비스는 인증서를 사용하여 ID를 증명하고 다음과 같은 방법으로 ID의 유효성을 확인할 수 있습니다.

  • 다른 서비스에 ID를 증명하려는 서비스는 다른 서비스에 인증서를 제공합니다. 두 서비스 모두 신뢰하는 CA에서 이 인증서를 암호화 서명하고 발급합니다.
  • 이 인증서를 수신하는 서비스는 신뢰할 수 있는 CA에서 발급한 인증서의 유효성을 확인할 수 있습니다.

Cloud Service Mesh는 인증 기관이 아닙니다. 보안 통신을 사용 설정하려면 다음을 수행하는 메커니즘을 설정해야 합니다.

  • ID 및 인증서 프로비저닝
  • Cloud Service Mesh에서 구성하는 Envoy 프록시와 같은 Cloud Service Mesh 클라이언트에서 인증서를 사용할 수 있게 합니다.

Cloud Service Mesh는 Google의 CA 서비스를 지원합니다. Envoy 및 프록시리스 gRPC의 설정 가이드에는 이를 설정하는 안내가 포함되어 있습니다. 자세한 내용은 다음 단계를 참조하세요.

아키텍처 및 리소스

Cloud Service Mesh에는 Google Cloud API 리소스 3개로 구성된 Network Security API 네임스페이스가 포함되어 있으며 이 리소스를 사용하여 데이터 영역에 적용해야 하는 보안 정책을 지정할 수 있습니다.

메시에서는 2개의 Google Cloud API 리소스(클라이언트 TLS 정책 및 서버 TLS 정책)가 인증을 지원합니다. 세 번째 리소스인 승인 정책은 승인을 지원합니다.

Network Services API 네임스페이스에는 Cloud Service Mesh에서 구성(서버 TLS, 클라이언트 TLS, 승인 정책)을 엔드포인트에 제공할 수 있는 엔드포인트 정책 리소스가 포함되어 있습니다. 엔드포인트는 다른 Cloud Service Mesh 클라이언트에서 인바운드 통신을 종료하는 Cloud Service Mech 클라이언트입니다.

클라이언트 TLS 정책

클라이언트 TLS 정책을 사용하면 클라이언트 측 TLS 모드와 데이터 영역에 적용할 인증서 제공업체 정보를 지정할 수 있습니다. 클라이언트 TLS 정책은 TLS 및 mTLS 인증을 지원합니다. 클라이언트 TLS 정책은 전역 백엔드 서비스 리소스에 연결되어야 합니다.

TLS를 구성할 때는 클라이언트가 serverValidationCa API 필드를 통해 TLS 교환 중에 서버에서 수신하는 인증서를 검증하는 메커니즘을 제공해야 합니다. 클라이언트는 이 정보를 사용하여 서버 인증서를 검증하는 데 사용할 수 있는 유효성 검사 인증서를 가져옵니다.

mTLS를 구성할 때는 클라이언트가 clientCertificate API 필드를 통해 인증서와 비공개 키를 가져오는 메커니즘을 추가로 제공해야 합니다. 클라이언트는 TLS 핸드셰이크 중에 이 정보를 사용하여 서버에 인증서를 제공합니다.

이 출시 버전에서 Cloud Service Mesh는 관리형 인증 기관인 CA 서비스를 지원합니다. 구성은 간단합니다. 인증서 제공업체를 구성할 때 google_cloud_private_spiffe 플러그인 이름을 지정합니다. 그러면 xDS 클라이언트가 정적 위치에서 인증서와 키를 로드합니다. 기본 요건으로 CA 서비스 풀을 구성하고 GKE 클러스터에서 메시 인증서를 사용 설정해야 합니다.

서버 TLS 정책

서버 TLS 정책(ServerTlsPolicy 리소스)을 사용하면 서버 측 TLS 모드와 데이터 영역에 적용할 인증서 제공업체 정보를 지정할 수 있습니다. 서버 TLS 정책은 TLS, mTLS를 지원하며 Envoy에서만 Open_or_mTLS 인증을 지원합니다. 서버 TLS 정책을 엔드포인트 정책 리소스에 연결합니다.

주체 대체 이름

전역 백엔드 서비스의 securitySettings 필드를 구성할 때 subjectAltNames 필드에 주체 대체 이름 목록을 제공할 수 있습니다. 클라이언트가 서비스 백엔드 중 하나와 TLS 핸드셰이크를 시작하면 서버는 X.509 인증서를 제공합니다. 클라이언트가 인증서의 subjectAltName 필드를 검사합니다. 필드에 지정된 값 중 하나가 포함된 경우 통신이 계속됩니다. 이 메커니즘은 앞서 보안 이름 지정에서 설명합니다.

승인 정책

승인 정책(AuthorizationPolicy 리소스)은 서버가 들어오는 요청 또는 RPC를 승인하는 방법을 지정합니다. 요청을 보낸 클라이언트 ID, 호스트, 헤더, 기타 HTTP 속성과 같은 다양한 매개변수를 기반으로 하여 들어오는 요청 또는 RPC를 허용하거나 거부하도록 구성할 수 있습니다. 승인 정책을 엔드포인트 정책 리소스에 연결합니다.

승인 정책 규칙에는 다음 구성요소가 포함됩니다.

  • from: 규칙에서 허용하는 클라이언트의 ID를 지정합니다. ID는 상호 TLS 연결의 클라이언트 인증서에서 파생될 수도 있고, 서비스 계정이나 보안 태그와 같이 클라이언트 VM과 연결된 주변 ID일 수도 있습니다.
  • to: 액세스할 수 있는 URL 또는 허용되는 HTTP 메서드와 같이 규칙에서 허용하는 작업을 지정합니다.
  • when: 충족해야 하는 추가 제약조건을 정의할 수 있습니다. Common Expression Language(CEL) 표현식을 사용하여 제약조건을 정의할 수 있습니다.
  • action: 규칙의 작업을 지정합니다. ALLOW, DENY, CUSTOM 중 하나일 수 있습니다.

제한사항

Cloud Service Mesh 서비스 보안은 GKE에서만 지원됩니다. Compute Engine으로는 서비스 보안을 배포할 수 없습니다.

요청을 평가할 때 승인 정책은 다음 작업 중 하나를 실행합니다.

  • ALLOW: 요청이 승인 정책 내에서 정의된 규칙과 일치하는 경우 요청된 리소스에 대한 액세스 권한을 부여합니다. 요청이 승인 정책 내에서 정의된 규칙과 일치하지 않으면 승인 정책은 요청된 리소스에 대한 액세스를 차단합니다. 다른 정책에서 허용하더라도 ALLOW 정책과 일치하지 않으면 요청이 거부됩니다.

  • DENY: 요청이 DENY 정책 내에 지정된 규칙과 일치하는 경우 리소스에 대한 액세스를 차단합니다. 요청이 승인 정책 내에서 정의된 규칙과 일치하지 않으면 승인 정책은 요청된 리소스에 대한 액세스 권한을 부여합니다. 요청이 DENY 정책과 일치하면 다른 정책에서 허용하더라도 요청이 거부됩니다.

  • CUSTOM(Cloud Service Mesh에서는 지원되지 않음): 복잡한 승인 결정을 위해 외부 승인 시스템과의 통합을 지원합니다. CUSTOM 작업은 승인 결정에 서비스 확장 프로그램을 사용하는 정책에 사용됩니다.

승인 정책 평가 순서

단일 리소스에 여러 승인 정책이 연결된 경우 다음 순서대로 평가하여 요청이 허용 또는 거부되는지 여부를 결정합니다.

  1. CUSTOM 작업이 있는 정책: CUSTOM 정책에서 요청을 거부하면 요청이 즉시 거부됩니다. DENY 또는 ALLOW 정책이 구성되어 있더라도 평가되지 않습니다.

  2. DENY 작업이 있는 정책: DENY 정책이 요청과 일치하면 요청이 거부됩니다. 구성된 ALLOW 정책이 있더라도 평가되지 않습니다.

  3. ALLOW 작업이 있는 정책: ALLOW 정책이 없거나 ALLOW 정책이 요청과 일치하면 요청이 허용됩니다. 그러나 요청과 일치하는 ALLOW 정책이 없으면 요청이 거부됩니다.

프록시리스 gRPC 애플리케이션의 제한사항

프록시리스 gRPC 서비스에 대한 서비스 보안에는 다음과 같은 제한사항이 있습니다.

  • 이 출시 버전은 자바, Python, C++, Go로 제한됩니다.

AuthzPolicy 할당량

  • 게이트웨이당 승인 정책은 총 5개로 제한됩니다.
  • 프로젝트당 AuthzPolicy 리소스는 20개로 제한됩니다.
  • 단일 AuthzPolicy는 최대 100개의 게이트웨이를 가리킬 수 있습니다.

다음 단계