Identity and Access Management(IAM)는 대부분의 Google Cloud 서비스에 대해 여러 개의 사전 정의된 역할을 제공합니다. 사전 정의된 각 역할에는 태스크 도는 관련 태스크 그룹을 수행하는 데 필요한 권한이 포함되어 있습니다.
간단한 태스크의 경우에는 적절한 사전 정의된 역할을 직관적으로 찾을 수 있습니다. 예를 들어 주 구성원이 Cloud Storage 버킷에 있는 객체를 확인해야 할 경우 스토리지 객체 뷰어 역할(roles/storage.objectViewer)이 적합할 수 있습니다.
하지만 사전 정의된 역할이 수백 가지 있어서 주 구성원에게 부여할 가장 적합한 권한을 찾는 것이 어려울 수 있습니다. 또한 실제로 필요한 것보다 많은 권한을 부여하면 안 된다는 최소 권한의 원칙에 맞게 역할을 찾는 것도 쉽지 않습니다.
이 페이지에서는 가장 적합한 사전 정의된 역할을 찾는 방법을 설명합니다.
필요한 권한 식별
주 구성원에 필요한 권한을 식별하기 위해 먼저 주 구성원이 수행해야 하는 태스크와 이러한 태스크에 사용할 Google Cloud 서비스를 나열해봅니다. 예를 들어 주 구성원이 Compute Engine을 사용해서 가상 머신 인스턴스를 만들어야 할 수 있습니다.
태스크와 서비스를 식별한 후에는 몇 가지 전략에 따라 각 태스크에 필요한 권한을 식별할 수 있습니다.
Google Cloud 서비스 문서를 확인합니다.
일부 서비스의 경우 태스크 중심의 방법 가이드에서 '시작하기 전에' 섹션 또는 각 태스크의 안내 부분에 각 태스크에 필요한 역할 또는 권한이 표시되어 있습니다. 예를 들어 Compute Engine VM 이미지 가져오기 및 내보내기 기본 요건을 참조하세요.
일부 다른 서비스는 액세스 제어에 대한 페이지에 필요한 역할 및 권한이 설명되어 있습니다. 예를 들어 Spanner Google Cloud 콘솔 태스크에 필요한 권한을 참조하세요.
태스크 완료를 위해 사용할 REST 또는 RPC API 메서드를 식별하고 API 참조 문서에서 필요한 IAM 권한을 확인합니다.
일부 서비스의 경우 REST 및 RPC API 문서에 각 메서드에 필요한 권한이 나열되어 있습니다. 예를 들어
instances.get메서드에 대한 Compute Engine 문서를 참조하세요.각 서비스의 권한 목록을 확인하고 상황에 맞게 관련 권한을 찾습니다.
대부분의 경우 각 권한 이름을 통해 이를 사용하기 위한 권한을 확인할 수 있습니다. 예를 들어 Compute Engine VM 인스턴스 만들기 권한의 이름은
compute.instances.create입니다.각 권한 이름을 이해하기 위해서는 권한 이름에
SERVICE.RESOURCE_TYPE.ACTION형식이 사용된다는 것을 기억하세요.
일반적으로 모든 태스크에 필요한 모든 권한을 식별할 필요가 없습니다. 대신 각 태스크에서 가장 관련성이 높은 권한을 식별하는 데에만 집중하세요. 사전 정의된 역할에 해당 권한이 포함되어 있으면 관련 권한도 포함되었을 가능성이 높습니다.
또한 이러한 과정 중에 필요한 권한 중 가장 높은 권한이 무엇인지 확인해야 합니다. 일반적으로 가장 높은 권한은 사전 정의된 역할 중 소수에만 포함되어 있습니다. 따라서 이러한 권한에 집중하면 선택할 대상 역할 범위를 좁힐 수 있습니다.
예를 들어 다음 유형의 권한은 특히 수준이 높은 권한들입니다.
- 리소스를 만들고 삭제할 수 있는 권한
- 암호화 키 또는 개인 식별 정보(PII)와 같은 민감한 정보에 액세스할 수 있는 권한
- 리소스에 대해 허용 정책 또는 거부 정책을 설정할 수 있는 권한
- 다른 리소스가 업데이트 내용을 상속할 수 있게 해주는 조직, 폴더, 프로젝트 업데이트 권한
반면에 다음 유형의 권한은 수준이 낮은 권한입니다.
- 리소스 나열 권한
- 중요하지 않은 데이터 액세스 권한
- Compute Engine 가상 머신 인스턴스의 최소 CPU 플랫폼과 같이 위험 수준이 제한된 설정을 업데이트할 수 있는 권한
권한이 포함된 역할 찾기
필요한 권한을 식별한 후에는 해당 권한이 포함된 사전 정의된 역할을 검색하고 선택 가능한 역할을 나열할 수 있습니다. 이러한 역할을 찾는 가장 쉬운 방법은 권한 참조를 검색하는 것입니다. 이렇게 하면 각 권한이 포함된 모든 역할 및 IAM 권한이 나열됩니다.
최소 권한의 원칙을 따르기 위해서는 특히 필요한 권한이 여러 개의 Google Cloud 서비스에 속하는 경우 부어할 사전 정의된 역할을 여러 개 식별해야 할 수 있습니다. 예를 들어 주 구성원이 Cloud Storage 객체를 보고 Cloud SQL 데이터베이스를 관리해야 하는 경우에는 두 서비스에 모두 적합한 권한이 특정 단일 사전 정의된 역할에 포함되었을 가능성이 낮습니다. 그러한 역할이 존재한다면 해당 주 구성원에 필요하지 않은 다른 관련 없는 권한들까지 여러 개 포함되었을 수 있습니다. 위험을 줄이기 위해서는 Cloud Storage에 필요한 권한이 포함된 역할과 Cloud SQL에 필요한 권한이 포함된 다른 역할까지 찾아보세요.
가장 적합한 역할 선택
이제 선택하기에 적합한 사전 정의된 역할 목록을 찾았으므로 이중에서 가장 적합한 역할들을 선택할 수 있습니다.
이를 위해서는 먼저 다음 유형의 역할을 없애는 것부터 시작합니다.
프로덕션 환경의 경우: 소유자(
roles/owner), 편집자(roles/editor), 뷰어(roles/viewer)를 포함하는 기본 역할모든 Google Cloud 서비스에서 기본 역할에는 수천 가지 권한이 포함됩니다. 프로덕션 환경에서는 대체 역할이 없는 경우가 아니라면 기본 역할을 부여하지 말아야 합니다. 대신 니즈를 충족하지만 가장 제한된 사전 정의된 역할이나 커스텀 역할을 부여합니다.
일반적으로 '서비스 에이전트'로 끝나는 제목과
serviceAgent로 끝나는 이름의 서비스 에이전트 역할이러한 역할은 Google Cloud 서비스가 리소스 액세스를 위해 사용하는 특별한 서비스 계정 유형인 서비스 에이전트를 위한 것들입니다. 서비스 에이전트 역할은 주 구성원이 액세스할 필요가 없는 서비스를 포함하여 여러 서비스에 대한 권한을 포함하는 경우가 많습니다.
그런 후 사전 정의된 역할 참조 또는 Google Cloud 콘솔의 역할 페이지를 참조해서 각 역할에 포함된 권한을 나열합니다. 각 역할에서 주 구성원에게 부여하지 않아야 하는 권한이 있는지 확인하고 원치 않는 권한이 포함된 역할은 제거합니다.
이 프로세스 중에 사전 정의된 역할이 모두 삭제되었으면 사용 사례에 맞는 커스텀 역할을 만들 수 있습니다. 그렇지 않으면 요구에 부합되면서도 가장 적은 권한이 포함된 역할을 선택합니다.
역할을 부여할 위치 결정
역할을 부여할 때는 리소스 계층에 포함되는 특정 Google Cloud 리소스에 대해서도 권한이 부여됩니다. Compute Engine VM 인스턴스와 같은 낮은 수준의 리소스는 프로젝트, 폴더, 조직과 같은 높은 수준의 리소스에 부여된 역할을 상속합니다.
식별한 사전 정의된 역할을 부여할 위치를 선택합니다.
- 주 구성원이 특정 하위 수준의 리소스에 액세스해야 하는 경우 해당 리소스에 대해 역할을 부여합니다.
주 구성원이 프로젝트, 폴더, 조직 내의 여러 리소스에 액세스해야 하는 경우에는 해당 프로젝트, 폴더, 조직에 대해 역할을 부여합니다. 주 구성원의 요구에 맞는 가장 낮은 수준의 리소스를 선택하세요.
또한 프로젝트, 폴더, 조직 내의 특정 리소스에 대해서만 역할을 부여하도록 IAM 조건을 사용하는 것이 좋습니다.
사전 정의된 여러 역할을 식별했으면 리소스 계층의 여러 수준에서 역할을 부여할지 여부를 고려합니다. 예를 들어 주 구성원이 단일 Cloud SQL 데이터베이스에 액세스해야 하지만 여러 다른 Compute Engine VM 인스턴스에 액세스해야 하는 경우 데이터베이스에 대해 Cloud SQL 역할을 부여하고 프로젝트에 대해서는 Compute Engine 역할을 부여해야 할 수 있습니다.
주 구성원에 역할 부여
이제 주 구성원에게 역할을 부여할 준비가 되었습니다. 역할을 부여하는 방법은 다음을 참조하세요.
역할을 부여한 후에는 정책 분석자 및 정책 문제 해결 도구를 사용해서 주 구성원이 액세스할 수 있는 리소스를 확인하고 액세스 문제를 해결할 수 있습니다.
주 구성원에게 올바른 리소스에 대한 의도된 권한이 있지만 해당 태스크를 완료할 수 없으면 주 구성원에 필요한 권한이 올바르게 고려되지 않았기 때문일 수 있습니다. 다시 이전에 시도한 작업을 반복해서 목록에 필요한 권한을 추가하고, 해당 권한이 포함된 역할을 찾고, 가장 적합한 역할을 선택합니다.
실수로 권한이 너무 많은 역할을 부여하면 역할 권장사항에 따라 주 구성원의 요구에 부합되는 더 낮은 권한 역할이 제안될 수 있습니다. 일부 역할 바인딩은 역할 권장사항이 없습니다.
다음 단계
- 정책 시뮬레이터를 사용해서 주 구성원 역할 변경을 테스트하는 방법 알아보기
- 정책 분석자를 통해 주 구성원이 리소스에 대해 갖고 있는 액세스 권한 확인
- 액세스 문제 해결 자세히 알아보기