AWS Client VPN 인증: IAM 권한은 로그인 방법이 아닙니다

사용자에게 AWS Client VPN 엔드포인트를 생성하거나 설명할 권한을 부여해도 그 사용자가 엔드포인트에 연결할 수 있는 것은 아닙니다. 이는 서로 다른 두 종류의 ID입니다. IAM은 AWS API 호출을 관리하고, 엔드포인트는 그 위에 구성된 클라이언트 인증 방식만 받아들입니다. 따라서 사용자가 콘솔에서 넓은 권한을 가져도 VPN 클라이언트가 제시할 수 있는 것이 하나도 없을 수 있습니다. 엔드포인트가 어떤 방식을 신뢰하는지 정하고, 그다음 부여하려는 접근에 전체 터널이 맞는 형태인지 정하세요.

API ID는 터널 ID가 아닙니다

«IAM 역할이 연결되어 있는데 왜 VPN이 계속 실패하나요»라고 누군가 묻는다면, 답은 보통 연결 흐름의 어느 단계도 그 역할을 읽지 않는다는 것입니다. 클라이언트는 인증서, AD 사용자 이름과 비밀번호, 또는 SAML 어설션을 제시합니다. 엔드포인트는 그중 하나를 검증한 뒤 주소를 할당합니다.

IAM은 여전히 중요하지만 더 나중에, 다른 곳에서 중요합니다. 엔드포인트 생성, 서브넷 연결, 경로 게시, 권한 부여 규칙 작성은 API 작업입니다. 이런 권한은 그것이 필요한 운영자에게만 한정하고, 모든 사용자에게 엔드포인트의 접근 규칙을 다시 쓸 수 있는 능력을 주지 마세요.

엔드포인트가 지원하는 방식 중에서 고르세요

AWS Client VPN은 인증서 기반 상호 인증, Active Directory 인증, SAML 기반 연합 인증을 받아들입니다. 어떤 클라이언트 방식을 선택하든 서버 인증서가 필요하며, 방식을 결합한 구성은 둘 다 성공해야 하고 하나만으로는 안 됩니다.

인증서는 도입 비용이 가장 낮고 규모가 커지면 가장 틀리기 쉬운 방식입니다. 모든 사용자에게 자격 증명이 필요하고 퇴사할 때마다 폐기가 필요하기 때문입니다. 디렉터리 인증은 그 수명 주기를 기존 시스템으로 옮깁니다. 연합은 그것을 ID 공급자로 옮기고 클라이언트에 브라우저 단계를 추가합니다.

클라이언트를 디버그하기 전에 엔드포인트 자체의 구성을 읽으세요. 사용자 기반 방식과 함께 상호 인증이 활성화되어 있으면, 유효한 인증서가 있어도 디렉터리 계정이 없는 클라이언트는 여전히 실패하며, 오류는 보통 일반적인 핸드셰이크 문제처럼 보입니다.

연합은 액세스 키를 전달하는 것이 아닙니다

SAML 구성은 IAM 액세스 키나 수임된 역할 토큰을 터널에 넣지 않습니다. ID 공급자가 사람을 인증하고 어설션을 반환하면, 엔드포인트가 구성한 신뢰 아래에서 그것을 받아들입니다. 그 결과 생기는 세션은 VPN 세션이며 AWS API 세션이 아닙니다.

이 차이가 누가 무엇을 진단할 수 있는지를 정합니다. IdP 문제는 터널이 존재하기 전에 브라우저나 클라이언트 오류로 나타나고, 터널 문제는 어설션이 성공한 뒤에 나타납니다. 어느 콘솔을 열기 전에 두 가지 중 무엇을 보고 있는지 물어보세요.

로그인 후에도 경로와 권한 부여가 결정합니다

인증은 세션에 주소를 줄 뿐, 세션에 목적지를 주지는 않습니다. 엔드포인트 경로는 어느 서브넷으로 보낼지 클라이언트에 알려 주고, 권한 부여 규칙은 어떤 사용자가 그 서브넷 중 어디에 도달할 수 있는지 정하며, 보안 그룹과 대상 자체의 권한이 나머지를 정합니다.

그래서 성공적으로 인증된 사용자도 데이터베이스에 도달하지 못할 수 있습니다. 서브넷의 경로 테이블 연결, 사용자 그룹의 권한 부여 규칙, 대상의 보안 그룹을 이 순서로 확인하세요. 각각이 다른 종류의 시간 초과를 만들기 때문입니다.

프라이빗 데이터베이스 하나라면 포트 포워딩과 비교하세요

실제 작업이 프라이빗 데이터베이스 하나에 대한 승인된 연결 하나라면, 전체 네트워크 터널은 요구 사항이 아니라 선택입니다. AWS Systems Manager Session Manager는 IAM을 통해 관리형 노드로 포트 포워딩 세션을 열 수 있고, 그 노드가 프라이빗 네트워크의 데이터베이스에 도달합니다. 사용자는 VPC 주소를 받지 않습니다. 관리형 노드가 데이터베이스 포트에 도달할 수 있는 유일한 호스트가 되며, 보통 보안 검토가 요구한 것이 바로 이것입니다. 그러면 사용자에게는 VPN 프로필 대신 로컬 클라이언트와 세션 명령이 필요합니다.

트레이드오프는 범위 대 전제 조건입니다. 포트 포워딩에는 관리형 노드의 SSM 에이전트, 그 노드에서 데이터베이스까지의 네트워크 도달성, 사용자 머신의 Session Manager 플러그인, 그리고 그 특정 세션을 시작할 권한이 필요합니다. 모든 서브넷으로 들어가는 경로가 아니며, 터널처럼 임의의 프로토콜을 실어 나르지도 않습니다.

어떤 경우든 데이터베이스 자체의 ID는 그대로 두세요. 경로가 IAM으로 승인되었다고 해서 TLS 검증과 데이터베이스 인증이 사라지지 않으며, 승인된 세션은 사용자가 어떤 테이블을 읽을 수 있는지에 대해 아무것도 말하지 않습니다.

범위와 수명 주기로 선택하세요. 많은 사용자가 많은 목적지를 필요로 하고 인증서나 디렉터리 수명 주기를 운영할 수 있다면 터널, 소수의 사람이 하나의 서비스를 필요로 하고 네트워크 주소를 배포하고 싶지 않다면 포워딩 세션입니다. 어떤 경우든 인증 방식, 권한 부여 규칙, 데이터베이스 로그인을 세 가지 별개의 사실로 기록하세요. 각각 따로 실패하기 때문입니다.