Cloud Service Mesh 보안 개요
Cloud Service Mesh 보안을 사용하면 워크로드 간의 모든 통신이 암호화, 상호 인증, 승인되어 내부 위협을 완화하고 정보 유출 위험을 줄일 수 있습니다.
일반적으로 IP 기반 규칙을 사용하는 마이크로 세분화는 내부 위험을 완화하는 데 사용되어 왔습니다. 그러나 여러 클라우드에 분산된 컨테이너, 공유 서비스, 분산 프로덕션 환경을 채택하면 이 방식을 구성하기 어렵고 유지관리는 더욱 어려워집니다.
Cloud Service Mesh를 사용하면 기본 네트워크의 보안과 별개인 서비스 컨텍스트 인식 및 요청 컨텍스트 인식 네트워크 보안 레이어를 구성할 수 있습니다. 따라서 Cloud Service Mesh를 사용하면 제로 트러스트 보안 원칙과 일치하는 심층 방어 태세를 채택할 수 있습니다. 이렇게 하면 선언적 정책을 통해 애플리케이션 코드를 수정하지 않고도 이러한 태세를 갖출 수 있습니다.
상호 TLS
Cloud Service Mesh는 피어 인증에 상호 TLS(mTLS)를 사용합니다. 인증에서는 ID를 참조하여 이 서비스는 무엇이고 최종 사용자는 누구이며 사용자가 밝힌 신원을 신뢰할 수 있는지 파악합니다.
mTLS를 사용하면 워크로드가 서로의 ID를 확인하고, 인증할 수 있습니다. 브라우저가 웹 서버를 신뢰하고 교환되는 데이터를 암호화할 수 있도록 HTTPS에서 간단한 TLS를 사용하는 것은 잘 알고 계실 것입니다. 단순한 TLS를 사용하면 클라이언트는 인증서를 확인하여 서버의 신뢰성을 확인합니다. mTLS는 클라이언트와 서버가 서로 인증서를 교환하여 ID를 확인하는 TLS 구현입니다.
mTLS는 Cloud Service Mesh가 서비스 간에 인증 및 암호화를 모두 구현하는 방법입니다.
Cloud Service Mesh 1.6 이상에서는 기본적으로 자동 mTLS가 사용 설정됩니다. 자동 mTLS를 사용하면 클라이언트 사이드카 프록시가 서버에 사이드카가 있는지 자동으로 감지합니다. 클라이언트 사이드카는 사이드카가 있는 워크로드에는 mTLS를 전송하고, 사이드카 없는 워크로드에는 일반 텍스트를 전송합니다. 하지만 서비스는 일반 텍스트와 mTLS 트래픽을 모두 수락합니다. 서비스 메시를 보호하려면 mTLS 트래픽만 허용하도록 서비스를 마이그레이션하는 것이 좋습니다.
mTLS만 적용하는 방법에 대한 자세한 내용은 예시별 Cloud Service Mesh: mTLS를 참조하세요.
암호화 스위트 구성
다음 목록에는 Cloud Service Mesh의 기본 FIPS 규정 준수 암호화 스위트가 포함되어 있습니다.
ECDHE-ECDSA-AES128-GCM-SHA256
ECDHE-RSA-AES128-GCM-SHA256
ECDHE-ECDSA-AES256-GCM-SHA384
ECDHE-RSA-AES256-GCM-SHA384
보안을 강화하기 위해 Cloud Service Mesh 워크로드에서 지원하는 서버 측 최소 TLS 버전은 암호화 스위트 맞춤설정을 지원하는 1.2입니다. Cloud Service Mesh는 암호화 스위트를 하드 코딩하고 변경을 지원하지 않는 TLS v1.3도 지원합니다.
암호화 스위트에 대한 자세한 내용은 Envoy의 공통 TLS 구성 및 Istio의 상호 TLS 인증을 참조하세요.
보안 이점
Cloud Service Mesh는 다음과 같은 보안 이점을 제공합니다.
도용된 사용자 인증 정보를 사용하는 재생 또는 명의 도용 공격의 위험을 완화합니다. Cloud Service Mesh는 JSON 웹 토큰(JWT)과 같은 Bearer 토큰이 아닌 mTLS 인증서를 사용하여 피어를 인증합니다. mTLS 인증서는 TLS 채널에 결합되므로 프로덕션 환경에 있는 항목이 비공개 키에 액세스하지 않고 인증 토큰을 다시 재생하는 방식으로 다른 사용자의 명의를 도용하는 것은 불가능합니다.
전송 중인 데이터 암호화를 보장합니다. 인증에 대한 mTLS를 사용하면 전송 시 모든 TCP 통신이 암호화됩니다.
승인된 클라이언트만 민감한 정보를 포함한 서비스에 액세스할 수 있도록 합니다. 승인된 클라이언트만 클라이언트의 네트워크 위치와 애플리케이션 수준 사용자 인증 정보와 관계없이 민감한 정보를 포함한 서비스에 액세스할 수 있습니다. 승인된 서비스 ID가 있거나 또는 승인된 Kubernetes 네임스페이스에 있는 클라이언트만 서비스에 액세스하도록 지정할 수 있습니다. 또한 IP 기반 액세스 정책을 사용하여 GKE Enterprise 환경 외부에 배포된 클라이언트에 액세스 권한을 부여할 수 있습니다.
프로덕션 네트워크 내에서 사용자 정보 유출 위험을 완화합니다. 내부 사용자가 승인된 클라이언트를 통해서만 민감한 정보에 액세스하도록 할 수 있습니다. 또한 클라이언트가 유효한 단기 사용자 토큰을 제시할 수 있는 경우에만 특정 클라이언트가 사용자 데이터에 액세스하도록 할 수 있습니다. 이렇게 하면 단일 클라이언트 사용자 인증 정보의 손상으로 공격자가 모든 사용자 데이터에 액세스할 수 있는 위험이 줄어듭니다.
민감한 정보를 포함한 서비스에 액세스한 클라이언트를 식별합니다. Cloud Service Mesh 액세스 로깅은 IP 주소와 함께 클라이언트의 mTLS ID를 캡처합니다. 따라서 동적으로 배포된 임시 워크로드가 다른 클러스터 또는 Virtual Private Cloud(VPC) 네트워크에 있는 경우에도 서비스에 액세스한 워크로드를 쉽게 파악할 수 있습니다.
기능
이 섹션에서는 Cloud Service Mesh의 보안 이점을 구현하기 위해 제공하는 기능을 설명합니다.
자동 인증서 및 키 순환
서비스 ID에 기반한 mTLS를 사용하면 모든 TCP 통신을 암호화할 수 있고 액세스 제어를 위해 보다 안전하고 재생 불가능한 사용자 인증 정보가 제공됩니다. mTLS를 대규모로 사용할 때의 문제 중 하나는 모든 대상 워크로드의 키와 인증서를 관리하는 것입니다. Cloud Service Mesh는 통신을 중단하지 않고 GKE Enterprise 워크로드의 mTLS 키 및 인증서 순환을 처리합니다. 위험을 줄이기 위해 더 작은 인증서 새로고침 간격을 구성할 수 있습니다.
Cloud Service Mesh 인증 기관
Cloud Service Mesh에는 mTLS용 인증서를 발급하기 위한 관리형 멀티 리전 비공개 인증 기관인 Cloud Service Mesh 인증 기관이 포함되어 있습니다. Cloud Service Mesh 인증 기관은 클라우드 플랫폼에서 동적으로 확장되는 워크로드에 최적화된 안정성과 확장성이 뛰어난 서비스입니다. Google은 Cloud Service Mesh 인증 기관을 통해 CA 백엔드의 보안 및 가용성을 관리합니다. Cloud Service Mesh 인증 기관을 사용하면 GKE Enterprise 클러스터 전반에서 신뢰할 수 있는 단일 루트를 사용할 수 있습니다. Cloud Service Mesh 인증 기관을 사용하는 경우 워크로드 아이덴티티 풀을 사용하여 대략적인 격리를 제공할 수 있습니다. 기본적으로 클라이언트와 서버가 동일한 워크로드 아이덴티티 풀에 없으면 인증이 실패합니다.
Cloud Service Mesh 인증 기관의 인증서에는 애플리케이션 서비스에 대한 다음 데이터가 포함됩니다.
- Google Cloud 프로젝트 ID
- GKE 네임스페이스
- GKE 서비스 계정 이름
Certificate Authority Service
Cloud Service Mesh 인증 기관 대신 Cloud Service Mesh에서 다음 사용 사례에 적합한 Certificate Authority Service를 사용하도록 구성할 수 있습니다.
- 여러 클러스터에서 워크로드 인증서에 서명하는 데 다른 인증 기관이 필요한 경우
- Istiod 커스텀 CA 플러그인 인증서를 사용하려는 경우
- 관리형 HSM에서 서명 키를 백업해야 하는 경우
- 규제가 심한 업종에 속해 있고 규정 준수해야 하는 경우
- Cloud Service Mesh CA를 커스텀 엔터프라이즈 루트 인증서에 연결하여 워크로드 인증서에 서명하려는 경우
Cloud Service Mesh 인증 기관 비용은 Cloud Service Mesh 가격에 포함되어 있습니다. CA 서비스는 기본 Cloud Service Mesh 가격에 포함되지 않으며 요금이 별도로 청구됩니다. 또한 CA Service에는 명시적 SLA가 제공되지만 Cloud Service Mesh 인증 기관의 경우에는 그렇지 않습니다.
이러한 통합을 위해 Cloud Service Mesh의 모든 워크로드에는 다음과 같은 두 가지 IAM 역할이 부여됩니다.
ID 인식 액세스 제어(방화벽) 정책
Cloud Service Mesh를 사용하면 mTLS ID 대비 피어의 IP 주소를 기반으로 한 네트워크 보안 정책을 구성할 수 있습니다. 이렇게 하면 워크로드의 네트워크 위치와 관계없이 정책을 만들 수 있습니다. 현재 동일한 Google Cloud 프로젝트의 클러스터 간 통신만 지원됩니다.
요청 클레임 인식 액세스 제어(방화벽) 정책
mTLS ID 외에도 HTTP 또는 gRPC 요청의 JWT 헤더에 있는 요청 클레임을 기반으로 액세스 권한을 부여할 수 있습니다. Cloud Service Mesh를 사용하면 JWT가 신뢰할 수 있는 기관에 의해 서명되었음을 어설션할 수 있습니다. 즉, 요청 클레임이 있거나 지정된 값과 일치하는 경우에만 특정 클라이언트의 액세스를 허용하는 정책을 구성할 수 있습니다.
IAP(Identity-Aware Proxy)로 사용자 인증
IAP(Identity-Aware Proxy)를 사용하여 Cloud Service Mesh 인그레스 게이트웨이에 노출된 모든 서비스에 액세스하는 사용자를 인증합니다. IAP는 브라우저에서 로그인하는 사용자를 인증하고, 커스텀 ID 공급업체와 통합하고, 사이드카를 사용하여 인그레스 게이트웨이 또는 다운스트림 서비스에서 액세스 권한을 부여하는 데 사용할 수 있는 단기 JWT 토큰 또는 RCToken을 발급합니다. 자세한 내용은 Cloud Service Mesh와 IAP 통합을 참조하세요.
기존 ID 공급업체를 통한 사용자 인증
기존 ID 공급업체를 Cloud Service Mesh와 통합하여 브라우저 기반 최종 사용자 인증 및 액세스 제어를 배포된 워크로드에 제공할 수 있습니다. 자세한 내용은 Cloud Service Mesh 사용자 인증 구성을 참조하세요.
액세스 로깅 및 모니터링
Cloud Service Mesh를 사용하면 액세스 로그와 측정항목을 Google Cloud Observability에서 사용할 수 있으며 이 데이터를 기반으로 서비스나 워크로드의 액세스 패턴을 파악할 수 있도록 통합 대시보드가 제공됩니다. 비공개 대상을 구성할 수도 있습니다. Cloud Service Mesh는 구성 가능한 기간에 성공한 액세스를 한 번만 로깅하여 액세스 로그의 노이즈를 줄여줍니다. 보안 정책에서 거부되거나 오류가 발생하는 요청은 항상 로깅됩니다. 이렇게 하면 주요 보안 신호의 손실 없이 로그 수집, 저장, 처리와 관련된 비용을 크게 절감할 수 있습니다.
FIPS 규정 준수
모든 클러스터 내 컨트롤 플레인 구성요소 및 x86 아키텍처의 프록시는 FIPS 140-2 검증 암호화 모듈을 사용합니다.
제한사항
현재 Cloud Service Mesh 보안에는 다음과 같은 제한사항이 있습니다.
- IAP를 사용하는 사용자 인증을 위해서는 서비스를 인터넷에 게시해야 합니다. IAP 및 Cloud Service Mesh를 사용하면 허용된 IP 범위에서 승인된 사용자와 클라이언트에 대한 액세스 권한을 제한할 수 있는 정책을 구성할 수 있습니다. 동일한 네트워크의 클라이언트에만 서비스를 노출하려면 사용자 인증 및 토큰 발급을 위한 커스텀 정책 엔진을 구성해야 합니다.