공유 및 공동작업

이 문서에서는 일반적인 데이터 공유 및 공동작업 시나리오를 제공합니다. 여기에는 시나리오 구현을 위해 프로젝트, 버킷 ID 및 액세스 관리(IAM) 정책, 객체 액세스제어 목록(ACL)을 구성하는 방법이 포함됩니다.

비공개 데이터의 저장 및 유지보수

이 시나리오에서는 회사의 마케팅 분석가가 Cloud Storage를 사용하여 기밀인 수익 예측과 판매 전망 데이터를 백업하고자 합니다. 마케팅 분석가만 데이터에 액세스할 수 있어야 합니다. 회사의 IT 부서가 회사의 Cloud Storage 계정을 감독하고 관리합니다. 주요 관리 책임에 버킷 생성 및 공유가 포함되므로 회사의 여러 부서에서 Cloud Storage에 액세스할 수 있습니다.

마케팅 분석가의 기밀성 및 개인정보 보호 요구를 충족하기 위해서는 IT 담당자가 버킷과 객체 권한을 통해 스프레드시트가 저장되는 버킷을 유지 관리할 수 있어야 합니다. 하지만 IT 담당자가 버킷에 저장된 데이터를 보거나 다운로드할 수 없도록 해야 합니다. 이를 위해 finance-marketing이라는 버킷을 만들고 지정된 주 구성원에게 나열된 리소스에 대한 다음과 같은 역할을 부여합니다.

역할 리소스 주 구성원 설명
스토리지 기존 버킷 소유자 버킷 finance-marketing IT 담당자 IT 담당자에게 버킷에 대한 스토리지 기존 버킷 소유자 역할을 부여하면 객체 삭제 및 버킷의 IAM 정책 변경과 같은 일반적인 버킷 관리 작업을 수행할 수 있습니다. 또한 이 담당자는 finance-marketing 버킷의 콘텐츠를 나열할 수 있지만 그 콘텐츠를 보거나 다운로드할 수는 없습니다.
스토리지 객체 생성자 버킷 finance-marketing 마케팅 분석가 마케팅 분석가에게 버킷에 대한 스토리지 객체 생성자 역할을 부여하면 객체를 버킷에 업로드할 수 있습니다. 마케팅 분석가가 버킷에 객체를 업로드하면 해당 객체의 소유자가 되어 객체를 보고 업데이트하고 삭제할 수 있습니다.

이러한 역할을 통해 마케팅 분석가를 제외한 누구도 마케팅 분석가가 버킷에 추가하는 객체를 보거나 다운로드할 수 없습니다. 그러나 마케팅 분석가가 객체의 ACL을 변경하여 다른 사용자에게 액세스 권한을 부여할 수 있습니다. IT 담당자는 여전히 finance-marketing 버킷의 콘텐츠를 나열할 수 있으며, 필요한 경우 버킷에 저장된 파일을 삭제하거나 교체할 수 있습니다.

이 시나리오 구현하기

사용자가 수행할 작업

사용자는 시나리오 구현을 위해 다음 작업을 수행해야 합니다.

  1. 이름이 finance-marketing인 버킷을 만듭니다. 단계별 안내는 버킷 만들기를 참조하세요.

  2. 각 IT 담당자에게 버킷에 대한 스토리지 기존 버킷 소유자 역할을 부여합니다. 단계별 안내는 버킷 수준 정책에 주 구성원 추가를 참조하세요.

IT 담당자가 수행할 작업

IT 담당자는 시나리오 구현을 위해 다음 작업을 수행해야 합니다.

  1. 마케팅 분석가에게 버킷에 대한 스토리지 객체 생성자 역할을 부여합니다. 단계별 안내는 버킷 수준 정책에 주 구성원 추가를 참조하세요.

공급업체 사진 보관함

이 시나리오에서는 한 건설 회사가 다양한 프로젝트에 대한 건축 계획을 제공하는 여러 건축 설계 회사와 함께 작업합니다. 건설 회사에서는 공급업체가 다양한 프로젝트의 중요 단계에서 설계 계획을 업로드할 수 있도록 사진 보관함을 설정하려고 합니다. 사진 보관함에서 건설 회사 고객의 개인정보가 보호되어야 하므로, 공급업체가 사진 보관함에서 서로의 작업을 볼 수 없어야 합니다. 이를 위해 건설 회사마다 별도의 버킷을 만들고 지정된 주 구성원에게 나열된 리소스에 대한 다음 역할을 부여합니다.

역할 리소스 주 구성원 설명
소유자 전체 프로젝트 건설 회사 관리자 건설 회사 관리자에게 프로젝트 수준의 소유자 역할을 부여하면 관리자가 각 공급업체의 버킷을 만들 수 있습니다.
스토리지 객체 뷰어 전체 프로젝트 건설 회사 관리자 스토리지 객체 뷰어는 건설 회사 관리자가 공급업체에서 업로드하는 객체를 다운로드할 수 있습니다.
스토리지 기존 버킷 소유자 각 공급업체 버킷 건설 회사 관리자 스토리지 기존 버킷 소유자 역할을 사용하면 건설 회사 관리자가 각 버킷의 콘텐츠를 나열하고 각 프로젝트 마일스톤이 끝날 때 객체를 삭제할 수 있습니다.
스토리지 객체 관리자 각 공급업체 버킷 버킷과 연결된 공급업체 각 공급업체에 자체 버킷의 스토리지 객체 관리자 역할을 부여하면 객체 업로드, 버킷의 객체 나열, 각 객체에 액세스할 수 있는 사용자 제어를 비롯한 작업으로 버킷의 객체를 완전히 제어할 수 있습니다. 그러나 버킷에 대한 역할 등의 메타데이터를 전체적으로 변경하거나 볼 수 없으며 프로젝트의 다른 버킷을 나열하거나 볼 수 없으므로 공급업체 간에 개인정보가 보호됩니다.

이 시나리오 구현하기

사용자가 수행할 작업

사용자는 시나리오 구현을 위해 다음 작업을 수행해야 합니다.

  1. 건설 회사 관리자에게 프로젝트의 소유자 역할과 프로젝트의 스토리지 객체 뷰어 역할을 부여합니다. 단계별 안내는 단일 역할 부여를 참조하세요.

건설 회사 관리자가 수행할 작업

건설 회사 관리자는 시나리오 구현을 위해 다음 작업을 수행해야 합니다.

  1. 각 공급업체에 대해 별도의 버킷을 만듭니다. 단계별 안내는 버킷 만들기를 참조하세요.

    건설 관리자는 소유자 역할을 갖고 있으므로 자신이 생성한 각 버킷에 대한 스토리지 기존 버킷 소유자 역할을 자동으로 부여받습니다.

  2. 각 공급업체에 해당 버킷에 대한 스토리지 객체 관리자 역할을 부여합니다. 단계별 안내는 버킷 수준 정책에 주 구성원 추가를 참조하세요.

  3. 공급업체가 Google Cloud 콘솔을 사용하려는 경우 다음과 같은 형식의 버킷 링크를 제공하세요.

    https://console.cloud.google.com/storage/browser/BUCKET_NAME

    여기서 BUCKET_NAME은 공급업체의 버킷 이름입니다.

공급업체가 수행할 작업

각 공급업체는 시나리오 구현을 위해 다음 작업을 수행해야 합니다.

  1. 할당된 버킷에 객체를 업로드합니다. 가장 쉬운 방법은 Google Cloud 콘솔을 사용하는 것입니다. Google Cloud CLI 등의 다른 방법은 사용 전에 추가 설정이 필요합니다. 단계별 안내는 객체 업로드하기를 참조하세요.

인증된 브라우저 다운로드

이 시나리오에서 클라이언트는 간단한 브라우저 다운로드를 통해 특정 개인이 특정 파일을 사용할 수 있게 하려고 합니다. 이를 위해서는 Cloud Storage 쿠키 기반 인증을 사용하면 됩니다. 객체를 다운로드하려면 사용자가 Google Workspace, Cloud ID, Gmail, 직원 ID 제휴를 포함한 유효한 계정에 로그인하여 인증해야 합니다. 다음과 같은 인증된 사용자가 객체를 다운로드할 수 있습니다.

다른 모든 사용자에게는 403 Forbidden (access denied) 오류가 발생합니다.

이 기능을 사용하려면 사용자에게 객체 액세스 권한을 부여한 다음 객체의 특수 URL을 제공합니다. 사용자가 URL을 클릭하면 계정에 로그인되어 있지 않은 경우 Cloud Storage가 로그인하라는 메시지를 표시하고 객체가 컴퓨터에 다운로드됩니다.

이 시나리오 구현하기

네 가지 일반 단계로 쿠키 기반 인증을 구현할 수 있습니다.

  1. 버킷을 만듭니다. 단계별 안내는 버킷 만들기를 참조하세요.

    소유하고 있는 프로젝트에 버킷을 만들 경우 버킷에 객체를 업로드하고 버킷에 액세스할 수 있는 사용자를 변경할 수 있는 권한이 자동으로 부여됩니다.

  2. 공유할 객체를 업로드합니다. 단계별 안내는 객체 업로드를 참조하세요.

    객체를 업로드하면 객체의 소유자가 됩니다. 즉, 객체의 ACL을 수정할 수 있습니다.

  3. 사용자에게 객체에 대한 액세스 권한을 부여합니다. 두 가지 방법 중 하나로 이를 수행할 수 있습니다.

    1. 원하는 각 사용자에게 버킷의 모든 객체에 적용되는 스토리지 객체 뷰어 역할을 부여하도록 버킷의 IAM 정책을 수정합니다. 단계별 안내는 버킷 수준 정책에 주 구성원 추가를 참조하세요.

    2. 객체의 ACL을 수정하여 원하는 각 사용자에게 개별 객체에 대한 READ 권한을 부여합니다. 단계별 안내는 ACL 설정하기를 참조하세요.

  4. 사용자에게 객체에 대한 특수 URL을 제공합니다.

    인증된 브라우저 다운로드는 특정 URL 엔드포인트를 통해 Cloud Storage에 액세스합니다. 다음 URL을 사용하세요.

    https://storage.cloud.google.com/BUCKET_NAME/OBJECT_NAME

    각 항목의 의미는 다음과 같습니다.

    • BUCKET_NAME은 원하는 객체가 포함된 버킷의 이름입니다. 예를 들면 my-bucket입니다.
    • OBJECT_NAME은 원하는 객체의 이름입니다. 예를 들면 pets/dog.png입니다.

    적절한 ACL 또는 IAM 권한을 가진 사용자만 볼 수 있으므로 이 URL을 어떻게 사용 가능하게 만드는지는 중요하지 않습니다. URL을 사용자에게 직접 보내거나 웹페이지에 게시할 수 있습니다.

그룹을 사용하여 액세스 제어

이 시나리오에서는 새 소프트웨어 사용 초대를 받은 사용자와 같은 특정 사용자가 객체를 사용할 수 있게 하려고 합니다. 또한 많은 사용자를 초대하려고 하지만 각 사용자에 대해 개별적으로 권한을 설정하지 않으려고 합니다. 또한 객체를 공개적으로 읽을 수 없게 하고, 초대되지 않은 사용자에게 링크가 전송될 수 있는 위험이 있기 때문에 초대된 고객에게 객체에 액세스할 수 있는 링크를 전송하지 않으려고 합니다.

이 시나리오를 처리하는 한 가지 방법은 Google 그룹스를 사용하는 것입니다. 그룹을 만들고 초대된 사용자만 그룹에 추가할 수 있습니다. 그런 다음 그룹에 객체에 대한 전체 액세스 권한을 줄 수 있습니다.

역할 리소스 주 구성원 설명
스토리지 객체 뷰어 버킷 Google 그룹 Google 그룹에 버킷에 대한 스토리지 객체 뷰어 역할을 부여하면 Google 그룹에 속한 모든 고객이 버킷의 객체를 볼 수 있습니다. 그룹 외부의 고객은 객체에 액세스할 수 없습니다.

이 시나리오 구현하기

  1. Google 그룹을 만들고 고객을 추가합니다. 단계별 안내는 그룹 만들기를 참조하세요.

  2. 버킷을 만듭니다. 단계별 안내는 버킷 만들기를 참조하세요.

  3. 버킷에 객체를 업로드합니다. 단계별 안내는 객체 업로드를 참조하세요.

  4. Google 그룹에 객체에 대한 액세스 권한을 줍니다.

    • IAM 역할 storage.objectViewer를 사용하여 버킷의 모든 객체에 대한 보기 권한을 부여할 수 있습니다. 단계별 안내는 버킷 수준 정책에 주 구성원 추가를 참조하세요.

    • 버킷의 일부 객체에 대한 액세스 권한만 부여하려면 각 객체에 리더 ACL을 설정합니다. 단계별 안내는 ACL 설정을 참조하세요.

  5. 적절한 요청 엔드포인트를 그룹과 공유하여 객체에 액세스할 위치를 알릴 수 있습니다.

    예를 들어 Google Cloud 콘솔을 사용하면 https://console.cloud.google.com/storage/browser/BUCKET_NAME URL은 BUCKET_NAME 버킷의 객체 목록으로 이동합니다.

관리형 폴더를 사용하여 액세스 제어

이 시나리오에서는 각각 커스텀 이미지가 포함된 고유한 웹사이트를 소유한 여러 고객이 있습니다. 고객이 자체 웹사이트에만 이미지를 업로드할 수 있도록 하고 다른 웹사이트에는 이미지를 업로드할 수 없게 하려고 합니다. 고객이 계정을 취소할 때 웹사이트의 이미지에 대한 공개 액세스를 사용 중지하되, 계정을 다시 활성화하려는 경우에는 이미지를 삭제하지 않아야 합니다.

이 시나리오를 처리하는 한 가지 방법은 관리형 폴더를 사용하는 것입니다. 버킷 내에 여러 관리형 폴더를 만들고 IAM을 사용하여 고객과 최종 사용자의 개별 관리형 폴더에 대한 액세스를 제어할 수 있습니다.

이 시나리오 구현하기

  1. 버킷 만들기

  2. 각 고객 웹사이트의 버킷에 관리형 폴더를 만듭니다.

  3. 각 관리형 폴더에 대해 고객에게 스토리지 객체 사용자(roles/storage.objectUser) 역할을 부여하는 IAM 정책을 설정하여 고객이 관리형 폴더에 객체를 업로드하고 관리형 폴더에서 객체를 삭제할 수 있도록 합니다.

  4. 모든 관리형 폴더에 스토리지 객체 뷰어(roles/storage.objectViewer) 역할을 주 구성원 allUsers에 부여하는 IAM 정책을 설정하여 관리형 폴더의 이미지 객체를 누구나 볼 수 있도록 합니다.

    또는 allUsersstorage.objects.get IAM 권한을 부여하는 커스텀 역할을 부여할 수 있습니다.

  5. 고객이 계정을 취소할 때 고객에게 연결된 관리형 폴더의 스토리지 객체 사용자(roles/storage.objectUser) 역할을 부여하는 IAM 정책을 삭제합니다. 관리 폴더 내 객체에 대한 공개 액세스를 중지하려면 allUsers에 스토리지 객체 뷰어(roles/storage.objectViewer) 역할을 부여하는 IAM 정책을 삭제합니다.