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 권한이 있는 구성원은 프로젝트에서 버킷을 나열할 수 있습니다. 구성원에게 직접 권한을 부여하지는 않습니다. 대신 권한이 한 개 이상 묶여있는 역할을 할당합니다.

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

역할

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

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

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

버킷 수준에서 역할을 부여하더라도 프로젝트 수준에서 부여한 기존 역할은 영향을 받지 않으며 그 반대의 경우도 마찬가지입니다. 따라서 이러한 두 가지 세분화된 수준을 사용하여 권한을 맞춤설정할 수 있습니다. 예를 들어, 한 사용자에게 모든 버킷의 객체를 읽을 수 있지만 특정 버킷 한 개에서만 객체를 만들 수 있는 권한을 부여한다고 가정해 보겠습니다. 이를 위해 사용자에게 프로젝트 수준에서 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 권한만 부여하지만, 기본적으로 새 버킷은 프로젝트에 대한 Viewer 역할을 가진 모든 구성원에게 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 역할을 가진 구성원이 최소한 두 명 이상 있어야 합니다.

다음 단계

이 페이지가 도움이 되었나요? 평가를 부탁드립니다.

다음에 대한 의견 보내기...

도움이 필요하시나요? 지원 페이지를 방문하세요.