Identity and Access Management

용도

이 페이지에서는 Identity and Access Management(IAM)의 개요와 IAM을 사용하여 Cloud Storage의 버킷, 관리 폴더, 객체 리소스에 대한 액세스를 제어하는 방법을 설명합니다.

개요

IAM을 사용하면 Google Cloud 프로젝트의 리소스에 액세스할 수 있는 사람을 제어할 수 있습니다. 리소스에는 Cloud Storage 버킷, 버킷 내의 관리 폴더, 버킷에 저장된 객체, Compute Engine 인스턴스와 같은 다른 Google Cloud 항목이 포함됩니다.

주 구성원은 IAM의 '주체'입니다. 개별 사용자, 그룹, 도메인은 물론 일반 대중도 주 구성원이 될 수 있습니다. 주 구성원에게는 역할이 부여되어 Cloud Storage뿐만 아니라 Google Cloud에서도 작업을 수행할 수 있습니다. 각 역할은 권한 하나 이상의 모음입니다. 권한은 IAM의 기본 단위입니다. 각 권한을 통해 특정 작업을 수행할 수 있습니다.

예를 들어 storage.objects.create 권한을 사용하면 객체를 만들 수 있습니다. 이 권한은 버킷에 객체를 만드는 데 유용한 권한을 부여하는 스토리지 객체 생성자(roles/storage.objectCreator)와 객체 작업을 위한 광범위한 권한을 부여하는 스토리지 객체 관리자(roles/storage.objectAdmin)와 같은 역할에 포함되어 있습니다.

리소스에 설정하는 IAM 역할 컬렉션을 IAM 정책이라고 부릅니다. 이러한 역할로 부여되는 액세스 권한은 정책이 설정된 리소스 및 해당 리소스 내에 포함된 모든 리소스에 모두 적용됩니다. 예를 들어 버킷에서 해당 버킷과 객체에 대해 사용자에게 관리 제어 기능을 제공하는 IAM 정책을 설정할 수 있습니다. 또한 다른 사용자에게 프로젝트 내 모든 버킷의 객체를 볼 수 있는 권한을 제공하는 전체 프로젝트에 IAM 정책을 설정할 수 있습니다.

Google Cloud 조직 리소스가 있는 경우 IAM 거부 정책을 사용하여 리소스에 대한 액세스를 거부할 수도 있습니다. 거부 정책이 리소스에 연결되면 정책의 주 구성원은 부여된 역할에 관계없이 지정된 권한을 사용하여 리소스 또는 리소스 내의 하위 리소스에 액세스할 수 없습니다. 거부 정책은 모든 IAM 허용 정책을 재정의합니다.

권한

주 구성원은 권한을 통해 Cloud Storage의 버킷, 관리 폴더, 객체에서 특정 작업을 수행할 수 있습니다. 예를 들어 storage.buckets.list 권한이 있는 주 구성원은 프로젝트에서 버킷을 나열할 수 있습니다. 주 구성원에게 권한을 직접 부여하는 대신 하나 이상의 권한이 번들로 포함된 역할을 부여합니다.

Cloud Storage에 적용되는 IAM 권한의 참조 목록은 Cloud Storage에 대한 IAM 권한을 참조하세요.

역할

역할은 하나 이상의 권한 모음입니다. 예를 들어 스토리지 객체 뷰어(roles/storage.objectViewer) 역할에는 storage.objects.get 및 storage.objects.list 권한이 포함됩니다. 주 구성원에게 역할을 부여하여 프로젝트의 버킷, 관리 폴더, 객체에서 작업을 수행하도록 할 수 있습니다.

Cloud Storage에 적용되는 IAM 역할의 참조 목록은 Cloud Storage에 대한 IAM 역할을 참조하세요.

프로젝트 수준, 버킷 수준 또는 관리 폴더 수준에서 역할 부여

프로젝트 수준, 버킷 수준, 관리 폴더 수준에서 주 구성원에게 역할을 부여할 수 있습니다. 이러한 역할로 부여되는 권한은 리소스 계층 구조 전체에 추가적으로 적용됩니다. 권한 모델에서 더 세분화하기 위해 리소스 계층 구조의 여러 수준에서 역할을 부여할 수 있습니다.

예를 들어 프로젝트 내의 모든 버킷에서 객체를 읽을 수 있지만 버킷 A에서만 객체를 만들 수 있는 권한을 사용자에게 부여한다고 가정해 보겠습니다. 이를 위해 사용자에게 프로젝트의 스토리지 객체 뷰어(roles/storage.objectViewer) 역할을 부여하면 사용자가 프로젝트 내 모든 버킷에 저장된 모든 객체를 읽을 수 있고, 버킷 A에 대한 스토리지 객체 생성자(roles/storage.objectCreator) 역할을 통해 사용자는 해당 버킷에서만 객체를 만들 수 있습니다.

일부 역할은 리소스 계층 구조의 모든 수준에서 사용할 수 있습니다. 프로젝트 수준에서 사용 시 포함된 권한은 프로젝트의 모든 버킷, 폴더, 객체에 적용됩니다. 버킷 수준에서 사용 시 권한은 특정 버킷과 해당 버킷에 저장된 폴더 및 객체에만 적용됩니다. 이러한 역할의 예시로는 스토리지 관리자(roles/storage.admin) 역할, 스토리지 객체 뷰어(roles/storage.objectViewer) 역할, 스토리지 객체 생성자(roles/storage.objectCreator) 역할이 있습니다.

일부 역할은 하나의 수준에서만 적용될 수 있습니다. 예를 들어 스토리지 기존 객체 소유자(roles/storage.legacyObjectOwner) 역할은 버킷 수준 또는 관리 폴더 수준에서만 적용할 수 있습니다. IAM 거부 정책을 제어할 수 있는 IAM 역할은 조직 수준에서만 적용할 수 있습니다.

ACL과의 관계

기존 버킷 IAM 역할은 버킷 ACL과 함께 작동합니다. 기존 버킷 역할을 추가하거나 삭제하면 버킷에 연결된 ACL에 변경사항이 반영됩니다. 마찬가지로 버킷별 ACL을 변경하면 해당 버킷의 기존 버킷 IAM 역할이 업데이트됩니다.

기존 버킷 역할 해당 ACL
스토리지 기존 버킷 리더(roles/storage.legacyBucketReader) 버킷 리더
스토리지 기존 버킷 작성자(roles/storage.legacyBucketWriter) 버킷 작성자
스토리지 기존 버킷 소유자(roles/storage.legacyBucketOwner) 버킷 소유자

기존 객체 IAM 역할을 포함하여 다른 모든 버킷 수준의 IAM 역할은 ACL과 별개로 작동합니다. 마찬가지로 모든 프로젝트 수준의 IAM 역할은 ACL과 별개로 작동합니다. 예를 들어 사용자에게 스토리지 객체 뷰어(roles/storage.objectViewer) 역할을 부여하더라도 ACL은 변경되지 않습니다. 즉, 버킷 수준의 IAM 역할을 사용하여 버킷 내의 모든 객체에 대한 광범위한 액세스 권한을 부여하고 세분화된 객체 ACL을 사용하여 버킷 내의 특정 객체에 대한 액세스를 맞춤설정할 수 있습니다.

IAM 거부 정책과 ACL 비교

IAM 거부 정책은 ACL로 부여된 액세스에 적용됩니다. 예를 들어 주 구성원에게 프로젝트에 대한 storage.objects.get 권한을 거부하는 거부 정책을 만드는 경우 주 구성원은 개별 객체에 대한 READER 권한이 부여된 경우에도 해당 프로젝트의 객체를 볼 수 없습니다.

ACL 변경을 위한 IAM 권한

IAM을 사용하여 객체의 ACL을 변경하는 데 필요한 권한을 주 구성원에게 부여할 수 있습니다. 다음 storage.buckets 권한과 함께 .get, .getIamPolicy, .setIamPolicy, .update를 사용하면 버킷 ACL과 기본 객체 ACL로 작업할 수 있습니다.

마찬가지로 다음 storage.objects 권한과 함께 .get, .getIamPolicy, .setIamPolicy, .update를 사용하면 객체 ACL로 작업할 수 있습니다.

커스텀 역할

IAM에는 일반적인 사용 사례에 적용 가능한 여러 사전 정의된 역할이 있지만, 사용자가 원할 경우 지정한 권한 모음이 포함된 고유한 역할을 정의할 수 있습니다. 이를 지원하기 위해 IAM은 커스텀 역할을 제공합니다.

주 구성원 유형

주 구성원에는 다양한 유형이 있습니다. 예를 들어 Google 계정과 Google 그룹 같이 일반적인 유형도 있고, allAuthenticatedUsers와 allUsers 같이 특수한 유형도 있습니다. IAM의 주 구성원 유형 목록은 주 구성원 식별자를 참조하세요. 일반적인 주 구성원에 대한 자세한 내용은 ID와 관련된 개념을 참조하세요.

단축값

Cloud Storage는 IAM 버킷 정책에 특별히 적용할 수 있는 특수한 주 구성원 집합인 단축값을 지원합니다. 일반적으로 프로덕션 환경에서는 단축값 사용을 피해야 합니다. 단축값을 사용하려면 주 구성원에게 기본 역할을 부여해야 하는데 이는 프로덕션 환경에서는 권장되지 않습니다.

단축값은 기본 역할과 프로젝트 ID의 두 부분으로 구성된 식별자입니다.

  • projectOwner:PROJECT_ID
  • projectEditor:PROJECT_ID
  • projectViewer:PROJECT_ID

단축값은 기본 역할과 IAM 역할이 부여된 주 구성원 간의 연결 역할을 합니다. 단축값에 부여된 IAM 역할은 사실상 특정 프로젝트 ID에 대한 특정 기본 역할의 모든 주 구성원에게도 부여됩니다.

예를 들어 jane@example.com과 john@example.com에 my-bucket라는 프로젝트의 뷰어(roles/viewer) 기본 역할이 있고 my-example-project이라는 프로젝트에 버킷이 있다고 가정해 보겠습니다. my-bucket의 스토리지 객체 생성자(roles/storage.objectCreator) 역할을 단축값 projectViewer:my-example-project에 부여하면 jane@example.com과 john@example.com은 둘 다 my-bucket의 스토리지 객체 생성자와의 연관된 권한을 얻습니다.

버킷의 단축값에 대한 액세스 권한을 직접 부여하고 취소할 수 있지만 Cloud Storage는 특정 상황에서 자동으로 적용합니다. 자세한 내용은 Cloud Storage에서 기본 역할의 수정 가능한 동작을 참조하세요.

조건

IAM 조건에서는 주 구성원에게 부여되거나 거부되는 역할을 제어하는 조건을 설정할 수 있습니다. Cloud Storage는 다음과 같은 유형의 조건 속성을 지원합니다.

  • resource.name: 버킷 또는 객체 이름에 따라 버킷과 객체에 대한 액세스 권한을 부여하거나 거부합니다. resource.type을 사용하여 버킷이나 객체에 대한 액세스 권한을 부여할 수 있지만 그러면 resource.name을 사용하는 경우와 거의 중복됩니다. 다음 예시 조건은 프리픽스가 동일한 모든 객체에 IAM 설정을 적용합니다. 

    resource.name.startsWith('projects/_/buckets/BUCKET_NAME/objects/OBJECT_PREFIX')

  • 날짜/시간: 권한의 만료일을 설정합니다. 

    request.time < timestamp('2019-01-01T00:00:00Z')

이러한 조건식은 Common Expression Language(CEL)의 하위 집합을 사용하는 논리문입니다. 버킷의 IAM 정책의 역할 바인딩에서 조건을 지정합니다.

다음 제한사항에 유의하세요.

  • 버킷 수준에서 조건을 추가하기 전에 버킷에 균일한 버킷 수준 액세스를 사용 설정해야 합니다. 프로젝트 수준에서 조건이 허용되더라도 Cloud Storage ACL이 프로젝트 수준 IAM 조건을 재정의하지 않도록 하려면 프로젝트의 모든 버킷을 균일한 버킷 수준 액세스로 마이그레이션해야 합니다. 균일한 버킷 수준 액세스 제약조건을 적용하여 프로젝트의 모든 새 버킷에 균일한 버킷 수준 액세스를 사용 설정할 수 있습니다.
  • JSON API를 사용하여 조건이 있는 버킷에서 getIamPolicy 및 setIamPolicy를 호출할 때 IAM 정책 버전을 3으로 설정해야 합니다.
  • storage.objects.list 권한은 버킷 수준에서 부여되므로 resource.name 조건 속성을 사용하여 버킷에 있는 객체 하위 집합에 대한 객체 나열 액세스를 제한할 수 없습니다.
  • 만료된 조건은 삭제할 때까지 IAM 정책에 그대로 유지됩니다.

Cloud Storage 도구 사용

IAM 권한은 XML API를 통해 설정할 수 없지만, IAM 권한을 부여받은 사용자는 XML API뿐 아니라 Cloud Storage에 액세스하기 위한 다른 도구도 사용할 수 있습니다.

사용자가 다른 Cloud Storage 도구로 작업을 수행할 수 있게 해주는 IAM 권한에 대한 자세한 내용은 Cloud Storage에 대한 IAM 참조를 확인하세요.

다음 단계