상호 TLS 이란 무엇인가요?

mTLS 이는 표준 TLS 프로토콜의 확장 기능으로, 연결에 참여하는 양측이 디지털 인증서를 사용하여 서로를 인증하도록 요구합니다. 표준 인증( TLS )은 서버가 클라이언트에게 인증서를 제시하기만 하면 되는 반면, 상호 인증( mTLS )은 클라이언트와 서버 양쪽 모두 인증서를 제시해야 하므로 양방향 인증 메커니즘을 형성합니다.

mTLS 의 ALB 지원 기능을 통해 다음 두 가지 수준에서 인증서 기반 인증을 구현할 수 있습니다:

프론트엔드 인증

클라이언트가 로드 밸런서 리스너에 연결할 때 유효한 인증서를 제시하도록 요구하여 클라이언트의 신원을 확인합니다.

백엔드 인증

클라이언트 인증서를 제시하여 로드 밸런서를 백엔드 서버에 인증하고, 필요에 따라 백엔드 서버 인증서를 검증합니다.

핵심 기능

ALB mTLS 지원은 다음과 같은 기능을 제공합니다:

리스너에서의 클라이언트 인증서 검증

클라이언트 인증서를 검증하기 위해 인증 기관(CA) 인증서를 구성하여 로드 밸런서 프런트엔드에서 클라이언트 인증을 활성화하십시오. 인증 과정을 통해 신뢰할 수 있는 CA가 서명한 유효한 인증서를 보유한 클라이언트만이 연결을 설정할 수 있도록 보장합니다.

인증서 해지 목록(CRL) 지원

CRL을 업로드하여 클라이언트 인증서가 취소되었는지 확인하고, 보안이 침해되었거나 만료된 인증서를 거부함으로써 보안 수준을 한층 더 강화합니다.

백엔드 서버 인증서 검증

TLS 핸드셰이크 과정에서 백엔드 서버 인증서를 검증하여, 로드 밸런서가 신뢰할 수 있는 백엔드 서버에만 연결되도록 합니다. 검증은 중간자 공격을 방지하는 데 도움이 됩니다.

백엔드 클라이언트 인증

백엔드 인프라에서 인증 기반 인증( mTLS )이 필요한 경우, 로드 밸런서의 클라이언트 인증서를 백엔드 서버에 제시하여 안전한 양방향 인증을 가능하게 합니다.

유스 케이스

mTLS 인증은 보안 강화 및 신원 확인이 필요한 상황에서 유용합니다:

제로 트러스트 보안 아키텍처

모든 연결에 대해 인증서 기반 인증을 의무화하여 제로 트러스트 원칙을 구현함으로써, 통신이 수립되기 전에 모든 클라이언트와 서버가 검증되도록 합니다.

API 보안

클라이언트가 유효한 인증서를 제시하도록 요구함으로써 API 엔드포인트를 보호하고, 민감한 API에 대한 무단 액세스를 방지하며, 인증된 애플리케이션만이 서비스를 이용할 수 있도록 보장합니다.

마이크로서비스 간 통신

프론트엔드와 백엔드 모두에서 mTLS 를 구현하여 마이크로서비스 간의 통신을 안전하게 보호하고, 모든 서비스 간 통신이 인증 및 암호화되도록 보장합니다.

규제 준수 요구사항

금융 서비스, 의료, 정부 부문 등에서와 같이 강력한 인증 메커니즘을 의무화하는 규제 준수 요건을 충족하십시오.

백엔드 서버 검증

인증서를 확인하여 로드 밸런서가 정상적인 백엔드 서버에만 연결되도록 함으로써, 악성 또는 해킹당한 백엔드 인스턴스로부터 시스템을 보호하십시오.

mTLS 가 애플리케이션 로드 밸런서와 연동되는 방식

ALB는 클라이언트-로드 밸런서 간 연결과 로드 밸런서-서버 간 연결 모두에서 mTLS 를 지원합니다. 다음 워크플로는 각 TLS 핸드셰이크 과정에서 인증서 검증이 어떻게 이루어지는지 보여줍니다.

인증서 해지 목록(CRL) 지원

CRL은 만료일 이전에 인증 기관(CA)에 의해 취소된 인증서 목록입니다. 인증서는 다음과 같은 다양한 이유로 취소될 수 있습니다:

• 개인 키가 유출되었습니다
• 해당 증명서가 잘못 발급되었습니다
• 인증서 소유자의 권한이 변경되었습니다
• 이 인증서는 더 이상 필요하지 않습니다

리스너에 대한 CRL을 구성하면, 로드 밸런서는 TLS 핸드셰이크 과정에서 각 클라이언트 인증서를 해지 목록과 대조하여 확인합니다. 인증서가 CRL에 등재되어 있는 경우, 해당 인증서가 그 외의 측면에서는 유효하고 올바르게 서명되어 있더라도 연결이 거부됩니다.

CRL 지원은 만료되지 않은 인증서라도 보안이 침해되었거나 무효화된 인증서가 서비스에 접근하는 데 사용되지 못하도록 보장함으로써 추가적인 보안 계층을 제공합니다.

전제조건

ALB에 대해 ‘ mTLS ’을 구성하기 전에 다음 요구 사항을 충족하는지 확인하십시오:

• mTLS 를 지원하는 프로필이 설정된 ALB가 있습니다. 로드 밸런서 프로필에서 ‘ mtls_supported ’ 속성을 확인하십시오.
• 귀하의 리스너는 HTTPS 프로토콜을 사용합니다. mTLS 은 HTTPS 리스너에서만 사용할 수 있습니다.
• Secrets Manager 에 PEM 형식의 유효한 인증서가 저장되어 있습니다.
• 사용자께서는 Secrets Manager 에서 로드 밸런서를 관리하고 인증서에 액세스할 수 있는 적절한 IAM 권한을 보유하고 있습니다.

중요한 고려사항

구현 시 다음 사항을 유의하십시오. mTLS:

인증서 관리 책임

사용자는 인증서의 발급, 업로드, 갱신 및 취소 등 모든 인증서 관리에 대한 책임이 있습니다. IBM Cloud 에서는 인증서를 자동으로 관리하거나 갱신하지 않습니다.

인증서 검증

인증서가 해당 인증 기관(CA)에 의해 올바르게 서명되었는지, 그리고 신뢰 관계가 올바르게 설정되었는지 반드시 확인해야 합니다. 유효하지 않거나 일치하지 않는 인증서로 인해 TLS 의 핸드셰이크가 실패하고 서비스를 이용할 수 없게 됩니다.

백엔드 서버 검증

이전 버전과의 호환성을 유지하기 위해 백엔드 서버 검증 기능은 기본적으로 비활성화되어 있습니다. 이 기능을 활성화한 경우, 적절한 CA 인증서를 업로드하여 로드 밸런서와 백엔드 서버 간에 유효한 신뢰 관계가 설정되어 있는지 확인해야 합니다.

풀 수준 구성

백엔드 서버 검증과 클라이언트 인증은 모두 풀 수준에서 구성됩니다. 풀 내의 모든 백엔드 서버는 동일한 구성을 사용합니다. 백엔드 서버마다 서로 다른 인증서 정책이 필요한 경우, 별도의 풀을 생성하십시오.

인증서 업데이트

인증서 업데이트 또는 취소의 변경 사항이 적용되려면 부하 분산 서비스를 재시작해야 할 수 있습니다. 서비스 중단을 최소화하기 위해 유지보수 시간대에 인증서 갱신을 계획하십시오.

여러 CA

동일한 풀에 속한 백엔드 서버들이 서로 다른 CA에서 발급한 인증서를 사용하는 경우, 관련 루트 인증서 및 중간 인증서를 모두 포함하는 번들 CA 파일을 제공할 수 있습니다. 모든 백엔드 서버는 해당 서버의 인증서 체인이 번들에 포함된 CA 중 하나와 연결되어 있다면 신뢰할 수 있습니다.

다음 단계

• 리스너 수준에서 클라이언트 인증 구성
• 풀 수준에서 서버 인증 및 클라이언트 인증서 구성