상호 TLS 인증

상호 TLS(전송 계층 보안) 인증은 양방향 피어 인증을 제공하는 TLS의 선택적 구성 요소입니다. 상호 TLS 인증은 TLS 위에 보안 계층을 추가하고 서비스가 연결을 설정하는 클라이언트를 확인할 수 있도록 합니다.

클라이언트-서버 관계에 있는 클라이언트도 세션 협상 프로세스 중에 X.509 인증서를 제공합니다. 서버는 이 인증서를 사용하여 클라이언트를 식별하고 인증합니다. 이 프로세스를 통해 신뢰할 수 있는 인증 기관(CA)에서 발급한 인증서인지와 유효한 인증서인지 확인할 수 있습니다. 또한 인증서의 주체 대체 이름(SAN)을 사용하여 클라이언트를 식별합니다.

에서 지원하는 AWS App Mesh모든 프로토콜에 대해 상호 TLS 인증을 활성화할 수 있습니다. 이러한 프로토콜은 TCP, HTTP/1.1, HTTP/2, gRPC입니다.

참고

App Mesh를 사용하면 서비스의 Envoy 프록시 간 통신을 위해 상호 TLS 인증을 구성할 수 있습니다. 하지만 애플리케이션과 Envoy 프록시 간의 통신은 암호화되지 않습니다.

상호 TLS 인증 인증서

AWS App Mesh 상호 TLS 인증을 위한 두 가지 가능한 인증서 소스를 지원합니다. TLS 클라이언트 정책의 클라이언트 인증서와 리스너 TLS 구성의 서버 검증은 다음에서 가져올 수 있습니다.

• 파일 시스템 - 실행 중인 Envoy 프록시의 로컬 파일 시스템에서 가져온 인증서. Envoy에 인증서를 배포하려면 인증서 체인의 파일 경로와 App Mesh API에 대한 프라이빗 키를 제공해야 합니다.

• Envoy의 비밀 검색 서비스 (SDS) — SDS를 구현하고 Envoy에 인증서를 보낼 수 있도록 하는 B ring-your-own 사이드카입니다. 여기에는 SPIFFE Runtime Environment(SPIRE)가 포함됩니다.

중요

App Mesh는 상호 TLS 인증에 사용되는 인증서나 프라이빗 키를 저장하지 않습니다. 대신 Envoy는 이러한 항목을 메모리에 저장합니다.

메시 엔드포인트 구성

가상 노드 또는 게이트웨이와 같은 메시 엔드포인트에 대한 상호 TLS 인증을 구성합니다. 이러한 엔드포인트는 인증서를 제공하고 신뢰할 수 있는 기관을 지정합니다.

이렇게 하려면 클라이언트와 서버 모두에 대해 X.509 인증서를 프로비저닝하고 TLS 종료 및 TLS 시작 모두의 검증 컨텍스트에서 신뢰할 수 있는 기관 인증서를 명시적으로 정의해야 합니다.

메시 내부의 신뢰

서버 측 인증서는 가상 노드 리스너(TLS 종료)에서 구성되고, 클라이언트 측 인증서는 가상 노드 서비스 백엔드(TLS 시작)에서 구성됩니다. 이 구성 대신, 가상 노드의 모든 서비스 백엔드에 대한 기본 클라이언트 정책을 정의한 다음, 필요에 따라 특정 백엔드에 대해 이 정책을 재정의할 수 있습니다. 가상 게이트웨이는 모든 백엔드에 적용되는 기본 클라이언트 정책으로만 구성할 수 있습니다.

두 메시의 가상 게이트웨이에서 인바운드 트래픽에 대해 상호 TLS 인증을 활성화하여 서로 다른 메시 간에 신뢰를 구성할 수 있습니다.

메시 외부의 신뢰

가상 게이트웨이 리스너에서 TLS 종료를 위한 서버 측 인증서를 지정합니다. 가상 게이트웨이와 통신하여 클라이언트 측 인증서를 제공하는 외부 서비스를 구성합니다. 인증서는 서버 측 인증서가 TLS 시작을 위해 가상 게이트웨이 리스너에서 사용하는 것과 동일한 인증 기관(CA) 중 하나에서 파생되어야 합니다.

상호 TLS 인증으로 서비스 마이그레이션

App Mesh 내의 기존 서비스를 상호 TLS 인증으로 마이그레이션할 때 연결을 유지하려면 다음 지침을 따르세요.

일반 텍스트를 통해 통신하는 서비스 마이그레이션

1. 서버 엔드포인트의 TLS 구성에 대해 PERMISSIVE 모드를 활성화합니다. 이 모드에서는 일반 텍스트 트래픽이 엔드포인트에 연결하도록 허용합니다.

2. 서버 인증서, 신뢰 체인 및 선택적으로 신뢰할 수 있는 SAN을 지정하여 서버에서 상호 TLS 인증을 구성합니다.

3. TLS 연결을 통해 통신이 이루어지고 있는지 확인합니다.

4. 클라이언트 인증서, 신뢰 체인 및 선택적으로 신뢰할 수 있는 SAN을 지정하여 클라이언트에서 상호 TLS 인증을 구성합니다.

5. 서버의 TLS 구성에 대해 STRICT 모드를 활성화합니다.

TLS를 통해 통신하는 서비스 마이그레이션

1. 클라이언트 인증서 및 선택적으로 신뢰할 수 있는 SAN을 지정하여 클라이언트에서 상호 TLS 설정을 구성합니다. 클라이언트 인증서는 백엔드 서버에서 요청하기 전까지는 백엔드로 전송되지 않습니다.

2. 신뢰 체인과 선택적으로 신뢰할 수 있는 SAN을 지정하여 서버의 상호 TLS 설정을 구성합니다. 이를 위해 서버는 클라이언트 인증서를 요청합니다.

상호 TLS 인증 확인

전송 계층 보안: 암호화 확인 설명서를 참조하여 Envoy가 TLS 관련 통계를 정확히 어떻게 내보내는지 확인할 수 있습니다. 상호 TLS 인증의 경우 다음 통계를 검사해야 합니다.

• ssl.handshake

• ssl.no_certificate

• ssl.fail_verify_no_cert

• ssl.fail_verify_san

다음 두 가지 통계 예제는 가상 노드로 종료되는 성공적인 TLS 연결이 모두 인증서를 제공한 클라이언트에서 시작되었음을 보여 줍니다.

listener.0.0.0.0_15000.ssl.handshake: 3

listener.0.0.0.0_15000.ssl.no_certificate: 0

다음 통계 예제는 가상 클라이언트 노드(또는 게이트웨이)에서 백엔드 가상 노드로의 연결이 실패했음을 보여 줍니다. 서버 인증서에 표시된 주체 대체 이름(SAN)이 클라이언트가 신뢰하는 SAN과 일치하지 않습니다.

cluster.cds_egress_my-mesh_my-backend-node_http_9080.ssl.fail_verify_san: 5

App Mesh 상호 TLS 인증 살펴보기

• 상호 TLS 인증 살펴보기: 이 살펴보기에서는 App Mesh CLI를 사용하여 상호 TLS 인증으로 컬러 앱을 구축하는 방법을 설명합니다.

• Amazon EKS 상호 TLS SDS 기반 살펴보기: 이 살펴보기에서는 Amazon EKS 및 SPIFFE Runtime Environment(SPIRE)에서 상호 TLS SDS 기반 인증을 사용하는 방법을 보여 줍니다.

• Amazon EKS 상호 TLS 파일 기반 살펴보기: 이 살펴보기에서는 Amazon EKS 및 SPIFFE Runtime Environment(SPIRE)에서 상호 TLS 파일 기반 인증을 사용하는 방법을 보여 줍니다.