Cloud Identity and Access Management

예시로 이동

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

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

개요

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

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

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

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

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

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

권한

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

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

역할

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

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

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

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

일부 역할은 프로젝트 수준과 버킷 수준 모두에서 사용할 수 있습니다. 프로젝트 수준에서 사용 시 포함된 권한은 프로젝트의 모든 버킷 및 객체에 적용됩니다. 버킷 수준에서 사용 시 권한은 특정 버킷과 해당 버킷에 저장된 객체에만 적용됩니다. 이러한 역할의 예로는 스토리지 관리자, 스토리지 객체 뷰어, 스토리지 객체 생성자가 있습니다.

일부 역할은 하나의 수준에서만 적용될 수 있습니다. 예를 들어 뷰어 역할은 프로젝트 수준에서만 적용할 수 있고, 스토리지 기존 객체 소유자 역할은 버킷 수준에서만 적용할 수 있습니다.

ACL과의 관계

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

이전 버킷 역할 해당 ACL
스토리지 기존 버킷 리더 버킷 리더
스토리지 기존 버킷 작성자 버킷 작성자
스토리지 기존 버킷 소유자 버킷 소유자

다른 모든 버킷 수준 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 프로젝트에 대해 뷰어 역할을 가진 모든 구성원에게 버킷 중 하나에 대한 스토리지 객체 생성자 역할을 부여한다고 가정해 보겠습니다. 이렇게 하려면 projectViewer:my-example-project 구성원에게 해당 버킷에 대한 스토리지 객체 생성자 역할을 부여하면 됩니다.

조건

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

  • resource.name: 버킷 또는 객체 이름에 따라 버킷과 객체에 대한 액세스 권한을 부여합니다. resource.type을 사용하여 버킷이나 객체에 대한 액세스 권한을 부여할 수 있지만 그러면 resource.name을 사용하는 경우와 거의 중복됩니다. 다음 예시 조건은 프리픽스가 동일한 모든 객체에 IAM 설정을 적용합니다.
    resource.name.startsWith('projects/_/buckets/[BUCKET_NAME]/objects/[OBJEC
    T_PREFIX]')
  • 날짜/시간: 권한의 만료일을 설정합니다.
    request.time < timestamp('2019-01-01T00:00:00Z')

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

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

  • 버킷 수준에서 조건을 추가하기 전에 버킷에 균일한 버킷 수준 액세스를 사용 설정해야 합니다. 프로젝트 수준에서 조건이 허용되더라도 Cloud Storage ACL이 프로젝트 수준 Cloud IAM 조건을 재정의하지 않도록 하려면 프로젝트의 모든 버킷을 균일한 버킷 수준 액세스로 마이그레이션해야 합니다. 균일한 버킷 수준 액세스 제약조건을 적용하여 프로젝트의 모든 새 버킷에 균일한 버킷 수준 액세스를 사용 설정할 수 있습니다.
  • gsutil iam ch 명령어는 조건을 포함하는 정책에서 작동하지 않습니다. 조건이 있는 정책을 수정하려면 gsutil iam get을 사용하여 관련성이 높은 버킷에 대한 정책을 검색하고 로컬에서 수정한 다음 gsutil iam set를 사용하여 버킷에 다시 적용합니다.
  • 조건을 사용하려면 gsutil 버전이 4.38 이상이어야 합니다.
  • JSON API를 사용하여 조건이 있는 버킷에서 getIamPolicysetIamPolicy를 호출할 때 Cloud IAM 정책 버전을 3으로 설정해야 합니다.
  • 만료된 조건은 삭제할 때까지 Cloud IAM 정책에 그대로 유지됩니다.

Cloud Storage 도구 사용

Cloud IAM 권한은 XML API를 통해 설정할 수 없지만, 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에서 뷰어/편집자/소유자 기본 역할의 이해

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

    예를 들어 뷰어 역할을 부여받은 구성원은 버킷을 나열할 수 있지만 버킷이나 객체를 볼 수는 없습니다. 그러나

    • 뷰어 역할이 있는 구성원에게는 일반적으로 프로젝트의 각 버킷에 대한 스토리지 기존 버킷 리더 역할 및 관련 권한이 부여됩니다. 이는 새 버킷을 만들 때 Cloud Storage에서 기본 동작으로 새 버킷의 스토리지 기존 버킷 리더 역할을 뷰어 기본 역할에 부여하기 때문입니다. 따라서 프로젝트의 뷰어 기본 역할이 있는 모든 구성원은 스토리지 기존 버킷 리더 또는 새 버킷을 갖게 됩니다. 이 동작을 통해 뷰어 역할이 있는 구성원은 버킷을 볼 수 있게 됩니다.

    • 버킷에는 기본 객체 ACL projectPrivate가 있습니다. 즉, 버킷에 추가되는 객체가 기본적으로 projectPrivate ACL을 얻게 된다는 의미입니다. 이 ACL을 통해 뷰어 역할이 있는 구성원은 객체를 볼 수 있게 됩니다.

    마찬가지로 편집자소유자 기본 역할은 자체적으로 Cloud Storage 액세스를 제한하지만, 이러한 역할이 할당된 구성원은 새 버킷에 대한 스토리지 기존 버킷 소유자projectPrivate ACL을 통해 객체의 소유권을 얻습니다.

    일부 버킷 및 객체 액세스 권한은 뷰어/편집자/소유자 기본 역할에 고유하지 않으므로, 구성원이 얻게 될 액세스 권한이 취소될 수 있습니다.

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

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

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

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

다음 단계