Cloud Identity and Access Management

이 페이지에서는 Cloud Identity and Access Management(Cloud IAM) 개요와 Cloud IAM을 사용하여 Cloud Storage의 버킷과 객체에 대한 액세스를 제어하는 방법을 설명합니다. Cloud Storage 버킷 및 프로젝트에 대한 Cloud IAM 권한을 설정하고 관리하는 방법을 알아보려면 Cloud IAM 권한 사용을 참조하세요. 버킷과 객체에 대한 액세스를 제어하는 다른 방법은 액세스 제어 개요를 참조하세요.

이 페이지는 특히 Cloud Storage와 관련된 Cloud IAM 측면을 중점적으로 설명합니다. Cloud IAM과 일반적인 IAM 기능에 대한 자세한 내용은 Cloud Identity and Access Management 개발자 가이드를 참조하세요. 특히 Cloud IAM 정책 관리 섹션을 확인하시기 바랍니다.

개요

Cloud Identity and Access Management(Cloud IAM)를 사용하면 Google Cloud Platform 프로젝트의 리소스에 액세스할 수 있는 사용자를 제어할 수 있습니다. 리소스에는 버킷에 저장된 Cloud Storage 버킷과 객체는 물론 Compute Engine 인스턴스와 같은 다른 GCP 항목이 포함됩니다.

리소스에 적용하는 액세스 규칙 세트를 Cloud IAM 정책이라고 합니다. 프로젝트에 적용된 Cloud IAM 정책은 사용자가 프로젝트 내의 모든 객체 또는 버킷에서 수행할 수 있는 작업을 정의합니다. 단일 버킷에 적용된 Cloud IAM 정책은 사용자가 해당 특정 버킷과 그 안에 있는 객체에서 수행할 수 있는 작업을 정의합니다.

예를 들어 사용자 한 명에게 버킷 중 하나를 관리할 수 있는 권한을 부여하는 Cloud IAM 정책을 만들 수 있습니다. 한편 사용자가 프로젝트의 모든 버킷에 있는 객체를 볼 수 있도록 허용하는 프로젝트 전반의 Cloud IAM 정책에 다른 사용자를 추가할 수 있습니다.

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

예를 들어 storage.objects.create 권한을 사용하면 객체를 만들 수 있습니다. 이 권한은 roles/storage.objectCreator와 같은 역할에서 유일한 권한이며 roles/storage.objectAdmin과 같은 역할에서는 여러 권한과 함께 묶여 있습니다. 특정 버킷에 대한 roles/storage.objectCreator 역할을 구성원에게 부여하면 이 구성원은 해당 버킷에서만 객체를 만들 수 있습니다. 버킷에 대한 roles/storage.objectAdmin 역할을 다른 구성원에게 부여하면 이 구성원은 해당 버킷 안에서만 객체 삭제와 같은 추가 작업을 수행할 수 있습니다. 이 두 사용자에게 해당 역할을 할당하고 다른 역할은 할당하지 않으면 이들은 프로젝트의 다른 버킷을 알지 못합니다. 세 번째 구성원에게 단일 버킷이 아닌 프로젝트에 대해 roles/storage.objectAdmin 역할을 부여하면 이 구성원은 프로젝트의 모든 버킷에 있는 모든 객체에 액세스할 수 있습니다.

Cloud Storage에서 Cloud IAM을 사용하면 각 버킷 또는 객체 권한을 개별적으로 수정할 필요 없이 구성원의 권한을 간편하게 제한할 수 있습니다.

권한

구성원은 권한을 통해 Cloud Storage의 버킷이나 객체에서 특정 작업을 수행할 수 있습니다. 예를 들어 storage.buckets.list 권한이 있는 구성원은 프로젝트에서 버킷을 나열할 수 있습니다. 이때 구성원에게 직접 권한을 부여하지는 않으며, 대신 권한이 1개 이상 묶여있는 역할을 할당합니다.

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

역할

역할은 하나 이상의 권한 모음입니다. 예를 들어 roles/storage.objectViewer에는 storage.objects.get 권한과 storage.objects.list 권한이 있습니다. 구성원에게 역할을 할당하여 프로젝트의 버킷 및 객체에서 작업을 수행하도록 할 수 있습니다.

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

프로젝트 수준 역할과 버킷 수준 역할 비교

버킷 수준에서 역할을 부여하더라도 프로젝트 수준에서 부여한 기존 역할은 영향을 받지 않으며 그 반대의 경우도 마찬가지입니다. 따라서 이러한 두 가지 세분화된 수준을 사용하여 권한을 맞춤설정할 수 있습니다. 예를 들어 한 사용자에게 어떤 버킷에서든 객체를 읽을 수 있지만 특정 버킷 1개에서만 객체를 만들 수 있는 권한을 부여한다고 가정해 보겠습니다. 이를 위해 사용자에게 프로젝트 수준에서 roles/storage.objectViewer 역할을 부여하여 사용자가 프로젝트 내 어떤 버킷에서든 저장된 모든 객체를 읽을 수 있도록 하고, 버킷 수준에서 특정 버킷에 대한 roles/storage.objectCreator 역할을 부여하여 사용자가 해당 버킷에서만 객체를 만들 수 있도록 할 수 있습니다.

일부 역할은 프로젝트 수준과 버킷 수준 모두에서 사용할 수 있습니다. 프로젝트 수준에서 사용 시 포함된 권한은 프로젝트의 모든 버킷 및 객체에 적용됩니다. 버킷 수준에서 사용 시 권한은 특정 버킷과 해당 버킷에 저장된 객체에만 적용됩니다. 이러한 역할의 예로는 roles/storage.admin, roles/storage.objectViewer, roles/storage.objectCreator가 있습니다.

일부 역할은 하나의 수준에서만 적용될 수 있습니다. 예를 들어 Viewer 역할은 프로젝트 수준에서만 적용할 수 있고, roles/storage.legacyObjectOwner 역할은 버킷 수준에서만 적용할 수 있습니다.

ACL과의 관계

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

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

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

ACL 변경에 필요한 Cloud IAM 권한

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

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

커스텀 역할

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

구성원 유형

구성원에는 다양한 유형이 있습니다. 예를 들어 Google 계정과 Google 그룹 같이 일반적인 유형도 있고, allAuthenticatedUsersallUsers 같이 특수한 유형도 있습니다. Cloud IAM의 일반적인 구성원 유형 목록은 ID 관련 개념을 참조하세요. Cloud IAM은 여기에 나열된 유형 외에도 특별히 Cloud Storage 버킷 Cloud IAM 정책에 적용할 수 있는 다음과 같은 구성원 유형을 지원합니다.

  • projectOwner:[PROJECT_ID]
  • projectEditor:[PROJECT_ID]
  • projectViewer:[PROJECT_ID]

여기서 [PROJECT_ID]는 특정 프로젝트의 ID입니다.

위의 구성원 유형 중 하나에 특정 역할을 부여하면 지정된 프로젝트에 대해 지정된 권한을 가진 모든 구성원에게 선택한 역할이 부여됩니다. 예를 들어 my-example-project프로젝트에 대해 Viewer역할을 가진 모든 구성원에게 버킷 중 하나에 대한 roles/storage.objectCreator 역할을 부여한다고 가정해 보겠습니다. 이렇게 하려면 projectViewer:my-example-project 구성원에게 해당 버킷에 대한 roles/storage.objectCreator 역할을 부여하면 됩니다.

Cloud Storage 도구 사용

XML API를 통해 Cloud IAM 권한을 설정할 수 없지만 Cloud IAM 권한이 부여된 사용자는 XML API와 Cloud Storage에 액세스하기 위한 다른 도구를 계속 사용할 수 있습니다.

사용자가 다양한 Cloud Storage 도구로 작업을 수행하는 데 필요한 Cloud IAM 권한은 Cloud IAM과 Cloud Console, Cloud IAM과 gsutil, Cloud IAM과 JSON, Cloud IAM과 XML을 참조하세요.

권장사항

Cloud IAM도 다른 관리 설정과 마찬가지로 적극적으로 관리해야 효과가 있습니다. 다른 사용자가 버킷이나 객체에 액세스할 수 있도록 하기 전에 버킷이나 객체를 공유할 대상이 누구이고 해당 사용자 각각에게 부여될 역할이 무엇인지 알고 있어야 합니다. 시간이 지나면서 프로젝트 관리, 사용 패턴, 조직 소유자가 변경되면 버킷 및 프로젝트에 대한 Cloud IAM 설정을 수정해야 할 수 있습니다. 특히 대규모 조직 또는 대규모 사용자 그룹에서 Cloud Storage를 관리하는 경우라면 더욱 그렇습니다. 액세스 제어 설정 평가 및 계획 시 다음과 같은 권장사항을 염두에 두어야 합니다.

  • 액세스 권한을 부여할 때 최소 권한 원칙을 사용하세요.

    최소 권한 원칙은 권한 또는 권리를 부여하기 위한 보안 가이드라인입니다. 최소 권한 원칙에 따라 액세스 권한을 부여하면 사용자가 할당된 작업을 수행하는 데 필요한 최소 권한이 부여됩니다. 예를 들어 다른 사용자와 파일을 공유하려는 경우 사용자에게 storage.admin 역할이 아닌 storage.objectReader 역할을 부여합니다.

  • 모르는 사람에게 setIamPolicy 권한을 부여하지 마세요.

    setIamPolicy 권한을 부여받은 사용자는 권한을 변경하고 데이터를 제어할 수 있습니다. 객체와 버킷에 대한 관리 제어 권한을 위임할 때만 setIamPolicy 권한을 사용해야 합니다.

  • 익명 사용자에게 권한 부여 시 주의하세요.

    allUsersallAuthenticatedUsers 구성원 유형은 인터넷 상의 모든 사용자가 데이터를 읽고 분석할 수 있도록 허용되는 경우에만 사용해야 합니다. 이러한 범위는 애플리케이션과 상황에 적합한 경우에만 유용하며, 일반적으로 모든 사용자에게 setIamPolicy, update, create 또는 delete 같은 특정 권한을 부여하는 것은 권장하지 않습니다.

  • Cloud Storage에서 Viewer/Editor/Owner 프로젝트 역할을 숙지하세요.

    Viewer/Editor/Owner 프로젝트 수준 역할은 Cloud Storage에서 자신의 이름이 의미하는 액세스 권한을 효과적으로 부여합니다. 하지만 Cloud Storage에 고유한 구성원 유형을 사용하여 버킷과 객체 수준에서 제공되는 추가 액세스를 통해 간접적으로 액세스 권한을 부여합니다. 기본적으로 액세스 권한이 추가되지만 사용자는 액세스 권한을 취소할 수 있습니다.

    예를 들어 Viewer 역할 자체는 구성원에게 storage.buckets.list 권한만 부여하지만, 기본적으로 새 버킷은 프로젝트에 대한 역할을 가진 모든 구성원에게 roles/storage.legacyBucketReader 역할을 부여합니다. 이 버킷 역할을 통해 Viewer가 버킷을 볼 수 있습니다. 또한 버킷에는 기본 객체 ACL projectPrivate가 있습니다. 즉, 버킷에 추가되는 객체가 기본적으로 projectPrivate ACL을 얻게 된다는 의미입니다. 이 ACL을 통해 Viewer가 객체를 볼 수 있습니다.

    마찬가지로 EditorOwner 프로젝트 역할은 자체적으로 Cloud Storage 액세스를 제한하지만, 이러한 역할이 할당된 구성원은 새 버킷에 대한 roles/storage.legacyBucketOwnerprojectPrivate ACL을 통해 객체의 소유권을 얻습니다.

    일부 버킷 및 객체 액세스 권한은 Viewer/Editor/Owner 프로젝트 역할에 고유하지 않으므로 구성원이 얻게 될 액세스 권한이 취소될 수 있습니다.

  • 버킷과 객체에 액세스할 수 없게 만드는 권한을 설정하지 마세요.

    읽기 권한이 부여된 구성원이 없으면 버킷이나 객체에 액세스할 수 없습니다. 버킷에 대한 모든 Cloud IAM 권한을 삭제하면 버킷에서 이러한 상황이 발생할 수 있습니다. 객체의 경우에는 객체 소유자가 프로젝트를 종료하고 객체에 대한 액세스 권한을 부여하는 버킷 또는 프로젝트 수준의 Cloud IAM 정책이 없을 때 이 문제가 발생할 수 있습니다. 두 경우 모두 사용자는 프로젝트 수준에서 사용자 본인이나 다른 구성원에게 roles/storage.admin 같은 적절한 역할을 할당하여 액세스 권한을 다시 얻을 수 있습니다. 이렇게 하면 프로젝트의 모든 버킷과 객체에 대한 액세스 권한이 부여되므로, 영향을 받은 버킷 또는 객체에 대한 액세스 권한을 재설정하면 역할을 취소해야 할 수 있습니다.

  • 버킷의 관리 권한을 위임하세요.

    기본적으로 프로젝트 수준 Owner 역할을 가진 구성원은 새로 생성된 버킷에 대한 roles/legacyBucketOwner 역할을 소유한 유일한 개체입니다. 한 명의 팀원이 그룹을 떠나도 다른 구성원이 버킷을 계속 관리할 수 있도록 Owner역할을 가진 구성원은 항상 최소한 두 명 이상 있어야 합니다.

다음 단계