이 도움말에는 컨텍스트 인식 액세스의 일반적인 사용 사례에 관한 설명과 기본 모드에서 개발된 샘플 구성이 포함되어 있습니다.
고급 모드 (CEL 편집기 사용)에서 개발된 액세스 수준의 예는 고급 모드의 컨텍스트 인식 액세스 예를 참고하세요.
회사 네트워크를 통해서만 계약업체에 액세스하도록 허용
많은 회사에서는 계약업체가 회사 리소스에 액세스하지 못하도록 제한하려 합니다. 예를 들어 계약업체를 사용하여 일반 지원 전화를 받거나 고객센터 및 콜센터에서 근무하는 회사입니다. 정규직 직원과 마찬가지로 계약업체도 컨텍스트 인식 액세스 정책의 적용을 받으려면 지원되는 라이선스가 있어야 합니다.
이 예시에서 계약업체는 특정 회사 IP 주소 범위에서만 회사 리소스에 액세스할 수 있습니다.
| 액세스 수준 이름 | 계약업체_액세스 |
| 다음 경우에 계약업체가 액세스할 수 있음 | 속성을 충족함 |
| 조건 1 속성 | IP 서브넷 (공개) 74.125.192.0/18 |
| 액세스 수준 할당 | 계약업체용 조직 단위 계약업체에서 사용하는 모든 앱 |
알려진 계정 도용 IP 주소를 통한 액세스 차단
많은 회사가 회사 리소스가 손상되지 않도록 알려진 고위험 소스에 대한 액세스를 차단합니다.
이 예에서는 IP 주소 74.125.195.105가 차단됩니다. 세션이 다른 IP 주소에서 시작되는 경우 사용자는 회사 리소스에 액세스할 수 있습니다. 여러 IP 주소와 범위를 지정할 수 있습니다.
| 액세스 수준 이름 | 고위험군_차단 |
| 다음 경우에 사용자가 액세스할 수 있음 | 속성을 충족하지 않음 |
| 조건 1 속성 | IP 서브넷 (공개) 74.125.195.105 |
| 액세스 수준 할당 | 최상위 조직 단위 모든 앱 |
Google Cloud의 특정 비공개 네트워크에서 액세스 허용
많은 기업에서 가상 프라이빗 클라우드(VPC)를 통해 사용자 트래픽을 Google로 라우팅합니다. VPC는 Google Cloud 환경 내의 안전하고 격리된 네트워크입니다.
VPC를 통해 라우팅되는 트래픽은 비공개 IP 주소를 사용할 수 있습니다. 이로 인해 공개 IP 또는 리전 정책에 문제가 발생할 수 있습니다.
다음 예에서는 다음과 같은 특정 VPC의 트래픽을 허용할 수 있습니다.
| 액세스 수준 이름 | vpc_access |
| 다음 경우에 사용자가 액세스할 수 있음 | 속성을 충족함 |
| 조건 1 속성 |
IP 서브넷(비공개) 비공개 IP 서브네트워크: //compute.googleapis.com/projects/project- name-test/global/networks/network-name VPC 서브넷: 74.125.192.0/18 |
| 액세스 수준 할당 |
모든 사용자에 대해 조직 단위 계약업체에서 사용하는 모든 앱 |
다음 사항에 주의하세요.
- 직접 트래픽 전용: 이 액세스 수준은 허용 목록에 추가된 VPC에서 Google 서버로 직접 연결되는 트래픽에만 적용됩니다. 트래픽이 다른 네트워크나 터널을 먼저 통과하면 액세스 권한이 부여되지 않습니다. Google은 서버로 트래픽을 전송하는 마지막 VPC만 인식합니다.
- 관리자 권한: VPC를 보고 이 액세스 수준을 구성하려면 관리자에게 적절한 ID 및 액세스 관리 (IAM) 역할 (예: compute.networks.list, compute.subnetworks.list 등)이 있어야 합니다.
- 외부 VPC: 허용 목록에 추가하는 VPC는 현재 Google Cloud 도메인 외부의 VPC일 수 있습니다. 외부 VPC를 추가하려면 관리자에게 보기 권한이 있어야 합니다.
특정 위치를 통한 액세스 허용 또는 거부
원격 회사 또는 파트너 사무실로 정기적으로 출장을 가는 직원이 있는 경우 회사 리소스에 액세스할 수 있는 지리적 위치를 지정할 수 있습니다.
예를 들어 영업팀이 오스트레일리아와 인도의 고객을 정기적으로 방문하는 경우 영업팀의 액세스 권한을 본사와 오스트레일리아, 인도로 제한할 수 있습니다. 출장 중에 개인 휴가를 위해 다른 국가로 이동하는 경우 해당 국가에서 회사 리소스에 액세스할 수 없습니다.
이 예에서 영업팀은 미국(본사), 오스트레일리아, 인도에서만 회사 리소스에 액세스할 수 있습니다.
| 액세스 수준 이름 | 영업팀_액세스 |
| 다음 경우에 영업팀이 액세스할 수 있음 | 속성을 충족함 |
| 조건 1 속성 | 지리적 출처 미국, 오스트레일리아, 인도 |
| 액세스 수준 할당 | 영업사원 그룹 모든 앱 영업사원이 사용하는 앱 |
사용자가 조건을 충족하지 않는 경우 액세스 권한을 부여하도록 지정하여 특정 국가의 액세스를 거부하는 정책을 만들 수도 있습니다. 액세스를 차단할 국가를 나열합니다.
할당 중에 여러 액세스 수준을 선택하는 대신 중첩된 액세스 수준 사용
특정 조직 단위 또는 그룹과 애플리케이션 (또는 애플리케이션 집합)에 액세스 수준을 할당하려고 할 때 애플리케이션 또는 액세스 수준의 수를 줄이라는 오류 메시지가 표시되는 경우가 있습니다.
이 오류를 방지하려면 액세스 수준을 단일 액세스 수준으로 중첩하여 할당 중에 사용되는 액세스 수준의 수를 줄이면 됩니다. 중첩된 액세스 수준은 여러 조건을 OR 작업으로 결합하며 각 조건에는 개별 액세스 수준이 포함됩니다.
이 예시에서는 USWest, USEast, USCentral이 3개의 별도 액세스 수준입니다. 사용자가 USWest 또는 USEast 또는 USCentral 액세스 수준 중 하나를 충족하는 경우 애플리케이션에 액세스할 수 있도록 하려면 OR 연산자를 사용하여 중첩된 단일 액세스 수준 (USRegions라고 함)을 만들면 됩니다. 액세스 수준을 할당할 때가 되면 조직 단위 또는 그룹의 애플리케이션에 액세스 수준 USRegions를 할당합니다.
|
액세스 수준 이름 |
USRegions |
|
다음 경우에 사용자가 액세스할 수 있음 |
속성을 충족함 |
|
조건 1 속성 (조건당 1개의 액세스 수준만 있음) |
액세스 수준 USWest |
|
다음으로 조건 1과 조건 2 결합 |
OR |
|
다음 경우에 사용자가 액세스할 수 있음 |
속성을 충족함 |
|
조건 2 속성 |
액세스 수준 USEast |
|
조건 2와 조건 3을 다음으로 결합 |
또는 |
|
다음 경우에 사용자가 액세스할 수 있음 |
속성을 충족함 |
|
조건 3 속성 |
액세스 수준 USCentral |
휴대기기는 제외하고 데스크톱에 대해서만 회사 소유 기기 요구
회사에서 회사 소유 데스크톱 기기는 요구하지만 회사 소유 모바일 기기는 요구하지 않을 수 있습니다.
먼저 다음과 같이 데스크톱 기기용 액세스 수준을 만듭니다.
|
액세스 수준 이름 |
모든 데스크톱_액세스 |
|
다음 경우에 사용자가 액세스할 수 있음 |
속성을 충족함 |
|
조건 1 속성 |
기기 정책
기기 암호화 = 지원되지 않음 기기 OS macOS = 0.0.0 Windows =0.0.0 Linux OS = 0.0.0 Chrome OS = 0.0.0 |
그런 다음 다음과 같이 휴대기기용 액세스 수준을 만듭니다.
|
액세스 수준 이름 |
모든 휴대기기_액세스 |
|
다음 경우에 사용자가 액세스할 수 있음 |
속성을 충족함 |
|
조건 1 속성 |
기기 OS iOS = 0.0.0 Android = 0.0.0 |
기본 기기 보안 요구
이제 대부분의 엔터프라이즈 기업에서는 직원이 암호화되고 최소 운영체제 버전을 충족하는 기기를 통해 회사 리소스에 액세스하도록 요구합니다. 일부 회사에서는 직원에게 회사 소유의 기기를 사용하기를 요구하기도 합니다.
이러한 정책을 모든 조직 단위를 대상으로 구성할 수도 있고, 회사 임원이나 재무팀, 인사팀과 같이 민감한 정보를 다루는 조직 단위에만 적용되도록 구성할 수도 있습니다.
기기 암호화, 최소 운영체제 버전, 회사 소유 기기를 포함하는 정책을 구성하는 방법은 여러 가지가 있습니다. 각각 장단점이 있습니다.
모든 보안 요구사항을 포함하는 액세스 수준 1개
다음 예에서는 기기 암호화, 최소 운영체제 버전, 회사 소유 기기 속성이 하나의 액세스 수준에 포함됩니다. 사용자가 액세스 권한을 얻으려면 모든 조건을 충족해야 합니다.
예를 들어 사용자 기기가 암호화되어 있고 회사 소유이지만 규정을 준수하는 버전의 운영체제를 실행하지 않는 경우 액세스가 거부됩니다.
장점: 설정이 쉽습니다. 이 액세스 수준을 앱에 할당하면 사용자가 모든 요구사항을 충족해야 합니다.
단점: 보안 요구사항을 서로 다른 조직 단위에 별도로 할당하려면 각 보안 요구사항에 대해 별도의 액세스 수준을 만들어야 합니다.
| 액세스 수준 이름 | 기기_보안 |
| 다음 경우에 사용자가 액세스할 수 있음 | 속성을 충족함 |
| 조건 1 속성 (모든 속성을 하나의 조건에 추가하거나 조건 3개를 만들어 AND로 결합할 수 있습니다.) |
기기 정책 기기 OS |
별도의 액세스 수준 3개
다음 예에서는 기기 암호화, 최소 운영체제 버전, 회사 소유 기기 속성이 3개의 별도 액세스 수준에 포함됩니다. 사용자가 액세스 수준의 조건 중 한 개라도 충족하면 액세스할 수 있게 됩니다. 액세스 수준의 논리적 OR입니다.
예를 들어 암호화된 기기를 사용하고 개인 기기에서 이전 버전의 운영체제를 실행하는 사용자는 액세스 권한을 얻습니다.
장점: 액세스 수준을 세부적으로 정의할 수 있습니다. 액세스 수준을 서로 다른 조직 단위에 개별적으로 할당할 수 있습니다.
단점: 사용자가 하나의 액세스 수준의 조건만 충족하면 됩니다.
| 액세스 수준 이름 | 기기_암호화 |
| 다음 경우에 사용자가 액세스할 수 있음 | 속성을 충족함 |
| 조건 1 속성 |
기기 정책 |
| 액세스 수준 이름 | 회사_소유_기기 |
| 다음 경우에 사용자가 액세스할 수 있음 | 속성을 충족함 |
| 조건 1 속성 |
기기 정책 |
| 액세스 수준 이름 | 최소_OS |
| 다음 경우에 사용자가 액세스할 수 있음 | 속성을 충족함 |
| 조건 1 속성 |
기기 정책 |
액세스 수준이 중첩된 단일 액세스 수준
다음 예에서는 기기 암호화, 최소 운영체제 버전, 회사 소유 기기 보안 요구사항이 3개의 별도 액세스 수준에 포함됩니다. 이 3개의 액세스 수준은 4번째 액세스 수준에 중첩되어 있습니다.
앱에 네 번째 액세스 수준을 할당하면 사용자가 액세스 권한을 얻기 위해 중첩된 3개의 액세스 수준 각각의 조건을 충족해야 합니다. 액세스 수준의 논리적 AND입니다.
예를 들어 암호화된 기기를 사용하고 개인 기기에서 이전 버전의 운영체제를 실행하는 사용자는 액세스가 거부됩니다.
장점: 액세스 수준 1, 2, 3에서 보안 요구사항을 분리하는 유연성을 유지할 수 있습니다. 액세스 수준 4를 사용하면 모든 보안 요구사항을 적용해 정책을 강화할 수도 있습니다.
단점: 감사 로그는 액세스 수준 4에 대한 액세스 거부만 캡처합니다 (액세스 수준 1, 2, 3은 캡처하지 않음). 액세스 수준 1, 2, 3은 앱에 직접 할당되지 않기 때문입니다.
위의 '3개의 별도 액세스 수준'에 설명된 대로 'device_encryption', 'corp_device', 'min_os'라는 3개의 액세스 수준을 만듭니다. 그런 다음 조건이 3개인 'device_security'라는 네 번째 액세스 수준을 만듭니다. 각 조건은 속성으로 액세스 수준을 갖습니다. 조건당 1개의 액세스 수준 속성만 추가할 수 있습니다.
| 액세스 수준 이름 | 기기_보안 |
| 다음 경우에 사용자가 액세스할 수 있음 | 속성을 충족함 |
| 조건 1 속성 (조건당 1개의 액세스 수준만 허용됨) |
액세스 수준 device_encryption |
| 다음으로 조건 1과 조건 2 결합 | AND |
| 다음 경우에 사용자가 액세스할 수 있음 | 속성을 충족함 |
| 조건 1 속성 | 액세스 수준 corp_device |
| 조건 2와 조건 3을 다음으로 결합 | AND |
| 다음 경우에 사용자가 액세스할 수 있음 | 속성을 충족함 |
| 조건 1 속성 | 액세스 수준 min_os |