안녕하세요 클래스메소드의 수재입니다.
어플리케이션에 대한 권한을 관리하는 방법을 찾던 도중 AWS Verified Access 라는 서비스를 알게 되었습니다.
공부 겸 제가 알아본 내용을 공유하고자 합니다.
어떤 서비스인가?
VPN 없이 기업 애플리케이션에 대한 보안 액세스 제공
제로 트러스트 가이드 원칙을 기반으로 구축된 AWS Verified Access는 액세스를 허용하기 전에 모든 애플리케이션을 빠짐 없이 검증합니다.
VPN을 사용하지 않고도 애플리케이션에 대한 보안 액세스를 제공할 수 있기 때문에 관리 복잡성을 줄여줍니다.
제로 트러스트란?
데이터에 대한 액세스가 네트워크 위치만을 기반으로 이루어져서는 안 된다는 생각에 초점을 맞춘 보안 모델입니다. 이를 위해서는 사용자와 시스템이 자신의 자격 증명과 신뢰성을 강력하게 입증해야 하며, 애플리케이션, 데이터 및 기타 시스템에 액세스하기 전에 세분화된 자격 증명 기반 권한 부여 규칙을 적용해야 합니다. - AWS 공식 문서
사용자나 기기 및 소프트웨어도 기본적으로 신뢰할 수 없다고 가정하는 것으로 이미 한정된 네트워크 안에 있더라도 자격 증명을 필요로 하는 보안 모델입니다.
장점
공식 문서에 소개된 Verified Access 의 장점은 다음과 같습니다.
- 보안 상태 개선
- 각 애플리케이션 액세스 요청을 실시간으로 평가합니다. 이로 인해 악의적인 공격자가 한 애플리케이션에서 다른 애플리케이션으로 이동하기가 어렵습니다.
- 보안 서비스와의 통합
- AWS 및 타사 서비스 모두를 포함한 ID 및 디바이스 관리 서비스와 통합됩니다.
- 사용자 환경 개선
- 사용자가 VPN을 사용하여 애플리케이션에 액세스할 필요가 없습니다.
- 간소화된 문제 해결 및 감사
- 모든 액세스 시도를 기록하여 애플리케이션 액세스에 대한 중앙 집중식 환경을 제공하여 보안 사고 및 감사 요청에 신속하게 대응할 수 있도록 지원합니다.
많은 서비스에서 처음 액세스 할 때 보안 평가를 진행한 후 활동을 종료할 때 까지 다시 보안 평가를 진행하지 않습니다.
Verified Access는 모든 액세스 요청에 대해 평가하기 때문에 악의를 가진 사용자가 액세스에 성공하더라도 다른 애플리케이션까지 조작하기 위해서는 다시 보안 평가를 진행해야합니다.
따라서 보안 사고에 대해 영향을 줄일 수 있습니다.
또한 AWS 이외의 서비스와도 통합할 수 있으며 중앙 집중식으로 관리할 수 있기 때문에 효율적으로 운용할 수 있습니다.
주요 요소
공식 문서에 따르면 Verified Access 의 주요 구성 요소는 다음과 같습니다.
- Verified Access 인스턴스
- 인스턴스는 애플리케이션 요청을 평가하여 보안 요구 사항이 충족되는 경우에만 액세스를 부여합니다.
- Verified Access 엔드포인트
- 각 엔드포인트는 애플리케이션을 나타냅니다. 로드 밸런서 엔드포인트 또는 네트워크 인터페이스 엔드포인트를 생성할 수 있습니다.
- 엔드포인트 도메인 자체가 Verified Access 인스턴스에서 제공되고 있습니다.
- Verified Access 그룹 – 엔드포인트의 모음입니다.
- 신뢰 공급자
- 사용자 ID 또는 디바이스 보안 상태를 관리하는 서비스입니다.
- 액세스 정책
- 애플리케이션에 대한 액세스를 허용할지 거부할지를 결정하는 사용자 정의 규칙 집합입니다. 사용자 ID 및 디바이스 보안 상태를 비롯한 여러 요소를 조합하여 지정할 수 있습니다.
- 신뢰 데이터
- 신뢰 공급자가 확인된 액세스에 보내는 사용자 또는 디바이스의 보안 관련 데이터입니다.
엔드포인트에서 실제 비공개 애플리케이션에 대한 경로 및 구성을 설정하며 신뢰 공급자는 신뢰할 수 있는 IdP 및 장치와 같은 구성을 설정합니다.
고려 사항
신뢰 공급자
신뢰 공급자에는 TrustProviderType이라는 속성이 있으며 사용자 자격 증명 신뢰 공급자와 디바이스 기반 신뢰 공급자의 두 가지 유형이 있습니다.
또한 Verified Access 인스턴스에는 여러 신뢰 공급자를 연결할 수 있습니다.
단, 속성이 같은 신뢰 공급자를 하나의 인스턴스에 연결 할 수는 없습니다. 예로 들면 IAM Identity Center 와 Azure AD 같이 사용자 + 사용자 신뢰 공급자는 동일 인스턴스에 연결할 수 없습니다.
AWS IAM Identity Center 또는 OpenID Connect와 호환되는 사용자 자격 증명 신뢰 공급자 중 하나를 사용하도록 선택할 수 있습니다. - 공식 문서(Verified Access - 사용자 자격 증명 신뢰 공급자)
따라서 IAM Identity Center(사용자 자격 증명 신뢰 공급자)와 Jamf(디바이스 기반 신뢰 공급자)의 조합이면 동일한 인스턴스에 연결할 수 있습니다.
정책 관리
정책 관리를 단순화하려면 보안 요구 사항이 비슷한 애플리케이션의 엔드포인트를 그룹화하는 것이 좋습니다.
예를 들어, 모든 판매 애플리케이션의 엔드포인트를 함께 그룹화할 수 있습니다.
크로스 리전
현재 cross region간의 endpoint구성은 지원하지 않습니다.
적용하려고 하는 어플리케이션의 엔드포인트 (ALB, NLB, ENI)가 위치한 동일 리전에 Verified Access 를 구성할 수 있습니다.
- 출처 : verified access 사용관련(AWS re:post)
- 블로그 작성 시점인 24년 1월 30일 기준으로 서울 리전도 GA입니다.
저희 회사의 @いわさ(이와사)가 쓴 글도 참고가 되어 링크를 남깁니다.
- AWS Verified Access の主要な 4 つのコンポーネント構造を整理してみた
- 일본어 글이긴 하지만 번역으로 보아도 이해가 되었습니다.
비용
Verified Access 는 연결된 애플리케이션의 시간당 비용과 처리된 데이터에 대한 GB당 비용의 두 가지 구성 요소를 바탕으로 요금이 결정됩니다.
또한 Verified Access를 사용하여 전송된 모든 데이터에 대한 표준 AWS 데이터 전송 요금도 발생합니다.
서울 리전 기준으로 1~14만 8,800 시간 까지는 시간당 0.35 USD 가 애플리케이션 비용이 발생하며 처리된 데이터는 GB당 0.02 USD가 발생합니다.
예로 들면 서울 리전에서 1개의 어플리케이션을 한달(720시간)동안 연결하였고 10 GB의 데이터가 발생하였다면 252.2 USD가 청구됩니다.
- (720 X 0.35) + (10 X 0.02) = 252.2
마무리
모든 액세스 권한을 중앙 집중식으로 관리할 수 있는 AWS Verified Access에 대해 개념을 정리해보았습니다.
이와 비슷한 여러 서비스가 공개되어 있으므로 요건에 맞춰 필요한 서비스를 사용하는 것이 좋다고 생각됩니다.
개념적으로 거의 비슷한 Google Zanzibar에 대해서는 유튜브의 애플코딩님의 영상이 쉽게 이해가 되므로 소개합니다.
긴 글 읽어주셔서 감사합니다.
내용 피드백 및 오탈자는 must01940 지메일로 보내주시면 감사합니다.
0
