이 문서에서는 Access Context Manager 서비스와 그 기능에 대한 일반적인 개요를 제공합니다. Google Cloud 조직 관리자는 Access Context Manager를 사용하여 Google Cloud의 프로젝트 및 리소스에 대해 세분화된 속성 기반 액세스 제어를 정의할 수 있습니다. 관리자는 먼저 액세스 수준과 서비스 경계의 조직 전반에 걸친 컨테이너인 액세스 정책을 정의합니다.
액세스 수준에서는 요청 처리에 대한 요구사항을 설명합니다. 예를 들면 다음과 같습니다.
- 기기 유형 및 운영체제
- IP 주소
- 사용자 ID
서비스 경계는 경계 내에서 자유롭게 데이터를 교환할 수 있지만 경계 외부로 데이터를 내보낼 수 없는 리소스 샌드박스를 정의합니다. Access Context Manager는 정책 적용까지는 담당하지 않으며, Access Context Manager는 특정 규칙이나 컨텍스트를 정의하도록 설계되었습니다. 정책은 VPC 서비스 제어와 같은 다양한 지점에서 구성되고 적용됩니다. 이러한 서비스에 대한 자세한 내용은 해당 사용자 가이드를 참고하세요.
다음 Chrome Enterprise Premium 솔루션 구성요소에서 Access Context Manager 정책을 구성하고 적용할 수 있습니다.
이점
많은 회사들이 내부 리소스 보안을 위해 방화벽과 같은 경계 보안 모델을 사용하고 있습니다. 경계 보안 모델은 하나의 출입구에 경비가 집중되어 있습니다. 벽 밖에 있는 것은 무엇이든지 위험한 것으로 간주됩니다. 안에 있는 것은 무엇이든지 신뢰할 수 있습니다.
방화벽과 경계 보안 모델은 특정 사용자와 서비스 주위에 정확한 경계가 있는 경우에 효과적입니다. 그러나 직원이 이동을 많이 하는 환경에서는 사용자가 자신의 기기(BYOD)를 가져오고 클라우드 기반 서비스를 활용하므로 기기의 다양성이 증가하게 됩니다. 이 시나리오에서는 경계 모델에서 고려되지 않는 추가 공격 벡터가 발생합니다. 따라서 경계는 더 이상 기업의 물리적 위치가 아니며 내부에 있는 것이 안전하다고 가정할 수 없습니다.
Access Context Manager를 사용하여 권한이 부여된 네트워크의 크기를 줄이고 엔드포인트가 네트워크에 따라 주변 권한을 갖지 않는 모델로 전환할 수 있습니다. 대신 필요한 경우 회사 네트워크 액세스를 확인하면서 기기 유형 및 사용자 ID 등과 같은 요청의 컨텍스트에 따라 액세스 권한을 부여할 수 있습니다.
Access Context Manager는 Google에서 펼치고 있는 BeyondCorp 이니셔티브의 일부입니다. 자세한 내용은 BeyondCorp를 참고하세요.액세스 정책
액세스 정책은 액세스 수준 및 서비스 경계와 같은 모든 Access Context Manager 리소스의 컨테이너입니다.
조직 컨텍스트에서 액세스 정책을 만들고 조직 어디에서나 조직 수준 액세스 정책을 사용할 수 있습니다. 액세스 정책 관리를 위임하려면 범위가 지정된 액세스 정책을 만들고 폴더나 프로젝트 수준에서 정책 범위를 설정하면 됩니다. 범위가 지정된 정책이 할당된 위임된 관리자는 범위가 지정된 액세스 정책만 관리할 수 있으며 조직 수준 액세스 정책을 관리할 수 없습니다.
액세스 정책은 etag를 통해 버전 관리됩니다.
etag를 사용하여 액세스 수준 수정과 같은 액세스 정책의 변경사항을 특정 버전의 정책에 타겟팅할 수 있습니다. 여러 소스에서 액세스 정책을 변경하는 경우 gcloud 명령줄 도구와 API 호출에 etag 필드를 사용하면 의도하지 않은 덮어쓰기와 충돌을 방지할 수 있습니다.
액세스 정책을 만드는 방법은 액세스 정책 만들기를 참조하세요.
액세스 수준
액세스 수준은 요청에 대한 컨텍스트 정보를 기반으로 리소스에 대한 액세스를 허용하는 데 사용됩니다. 액세스 수준을 사용하면 트러스트 계층을 구성할 수 있습니다. 예를 들어 권한이 높은 소규모 개인 그룹의 요청을 허용하는 High_Level 액세스 수준을 만들 수 있습니다. 또한 요청을 허용할 IP 범위와 같이 신뢰할 수 있는 보다 일반적인 그룹을 식별할 수도 있습니다. 이 경우 Medium_Level라는 액세스 수준을 만들어 이러한 요청을 허용할 수 있습니다.
액세스 수준을 정의한 후에는 적용 서비스에서 이러한 액세스 수준에 따라 요청을 처리할지 여부를 결정할 수 있습니다. 예를 들어 대부분의 리소스에 Medium_Trust를 요구하되, 더욱 민감한 특정 리소스에는 High_Trust 수준을 요구하도록 지정할 수 있습니다. 이러한 확인 작업은 표준 IAM 정책에 추가되어 적용됩니다.
액세스 수준은 맞춤설정할 수 있습니다. High_Trust 및 Medium_Trust 액세스 수준이 그 예입니다. 액세스 정책의 일부로 액세스 수준을 여러 개 지정할 수 있습니다.
기본 액세스 수준은 요청을 테스트하는 데 사용되는 조건의 모음으로 구성됩니다. 조건은 기기 유형, IP 주소, 사용자 ID 등 테스트하려는 속성 그룹으로 정의할 수 있습니다. 속성은 AND 연산 (모두 true여야 함) 또는 NOR 연산 (아무것도 true여서는 안 됨)으로 결합되어 조건 충족 여부를 결정합니다.
커스텀 액세스 수준은 Common Expression Language의 하위 집합을 사용하여 만들어집니다. 기본 액세스 수준에 사용되는 요청 컨텍스트 외에도 커스텀 액세스 수준을 사용하여 제3자 서비스의 데이터를 기반으로 요청을 허용할 수도 있습니다. 자세한 내용은 맞춤 액세스 수준을 참고하세요.
AND (&&) 및 OR(||)의 피연산자 중 하나가 결과를 고유하게 결정하는 경우 다른 피연산자가 평가될 수도 있고 평가되지 않을 수도 있습니다. 또한 평가 결과 런타임 오류가 발생하면 무시됩니다. 예를 들어 다음 표현식에서 origin.region_code 평가는 실패하지만 levels.ip_check 평가는 성공합니다.
하나 이상의 검사가 성공했으므로 OR로 결합된 전체 조건이 참이 되고 액세스가 GRANTED가 됩니다.
!(origin.region_code in ['RU', 'BY', 'UA']) -> FAILED // levels.regions_check
inIpRange(origin.ip, ['205.220.128.0/23']) -> GRANTED // levels.ip_check
!(origin.region_code in ['RU', 'BY', 'UA']) || inIpRange(origin.ip, ['205.220.128.0/23']) -> GRANTED
levels.regions_check || levels.ip_check -> GRANTED
IP 주소
원래 요청의 IP 주소에 따라 액세스 수준을 부여할 수 있습니다. 허용할 IP 주소 범위는 클래스 없는 도메인 간 라우팅 (CIDR) 블록 형식으로 지정되므로, 허용되는 IP 주소를 세밀하게 제어할 수 있습니다.
단일 액세스 수준에 IP 범위가 여러 개 포함될 수 있습니다.
단일 회사 네트워크 내의 IP 주소와 같은 지정된 범위의 IP 주소에만 액세스를 허용하는 액세스 수준을 만드는 방법을 알아보려면 회사 네트워크 액세스를 위한 액세스 수준 만들기를 참고하세요.
다음 IP 범위는 Access Context Manager에서 비공개 범위로 취급됩니다.
10.0.0.0/8(RFC 1918)172.16.0.0/12(RFC 1918)192.168.0.0/16(RFC 1918)100.64.0.0/10(RFC 6598 공유 주소 공간)fc00::/7(IPv6 고유 로컬 주소 RFC 4193)
기기 유형
Access Context Manager는 운영체제, 기기 유형, 버전과 같은 사용자 기기에 대한 정보를 수집하기 위해 엔드포인트 확인을 사용합니다. 이 데이터를 기반으로 액세스 수준을 부여할 수 있습니다. 예를 들어 회사에 배포된 기본 운영체제의 최신 버전을 실행하는 기기에는 보다 관대한 액세스 수준을 부여할 수 있습니다.
이러한 기기 속성을 기반으로 액세스 수준을 부여하는 방법을 알아보려면 기기 유형별 액세스 제한을 참고하세요.
사용자 ID
일부 시나리오에서는 특정 항목에 액세스 수준을 부여할 수 있습니다. 이러한 시나리오에서는 호출자 ID에 따라 조건 충족 여부가 결정됩니다. 이 시나리오는 서비스 계정 및 VPC 서비스 제어와 함께 사용되는 경우가 많습니다. 예를 들어 이 시나리오를 사용하여 Cloud 함수가 VPC 서비스 제어로 보호되는 데이터에 액세스할 수 있습니다.
gcloud 명령줄 도구를 사용하여 ID 전용 액세스 수준을 만들고 관리할 수 있지만 Google Cloud 콘솔을 사용해서는 할 수 없습니다.
기본 액세스 수준을 만들려면 Access Context Manager의 액세스 수준 만들기를 참조하세요.
요청 컨텍스트를 기반으로 액세스를 허용하는 액세스 수준을 만드는 방법은 맞춤 액세스 수준 만들기를 참고하세요.조건 결합
단일 액세스 수준에 조건이 여러 개 포함될 수 있습니다. AND 또는 OR 연산자를 사용하여 조건을 평가할 수 있습니다. 액세스 수준을 만들거나 업데이트할 때 모드를 지정할 수 있습니다.
AND는 더 엄격한 기본 옵션입니다. 이 옵션은 모든 조건이 충족된 경우에만 액세스 수준을 부여합니다. 예를 들어 요청이 회사 네트워크 내부에서 그리고 최신 버전의 운영체제를 실행하는 기기에서 시작되도록 요구할 수 있습니다.
OR은 덜 제한적인 옵션으로, 이 옵션은 여러 조건 중 하나만 참이면 됩니다. 이는 사용자 ID를 다룰 때 중요할 수 있습니다. 예를 들어 특정 항목 (예: 서비스 계정)을 일반 요구사항에서 제외하는 경우가 여기에 해당합니다.
중첩 조건
한 조건이 다른 조건에 종속되도록 여러 조건을 중첩할 수 있습니다. 예를 들어 신뢰가 각각 '중간' 및 '높음'인 두 가지 액세스 수준이 있는 경우에 '높음'의 요구사항을 '중간' 및 몇 가지 다른 조건으로 설정할 수 있습니다.
조건을 중첩하면 액세스 수준을 보다 편리하게 관리할 수 있습니다. 예를 들어 가장 관대한 액세스 수준에서 최소 운영체제 버전을 지정할 때 이에 종속되는 더 제한적인 액세스 수준을 설정한다고 가정합니다. 나중에 최소 버전을 업데이트할 때 정책의 모든 액세스 수준이 아닌 단일 조건만 업데이트하면 됩니다.