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