액세스 제어 목록(ACL)

용도

이 페이지에서는 액세스제어 목록(ACL)을 간략히 소개합니다. 버킷과 객체에 대한 액세스를 제어하는 다른 방법은 액세스 제어 개요를 참조하세요.

액세스제어 목록을 사용해야 하나요?

대부분의 경우 ACL을 사용하지 말고 버킷에 균일한 버킷 수준 액세스를 사용 설정해야 합니다. 그러면 ACL이 사용되지 않습니다.

  • 전체 프로젝트 또는 Cloud Storage 외부의 리소스에 대해서는 ACL을 설정할 수 없기 때문에 ACL만 사용해서 Google Cloud 리소스에 대한 액세스 권한을 제어할 수는 없습니다.
  • 균일한 버킷 수준 액세스를 사용 설정하면 더 간단한 액세스 제어 표시 경로가 생성되고 추가 Google Cloud 기능을 사용할 수 있습니다. 자세한 내용은 균일한 버킷 수준 액세스를 사용해야 할까요?를 참고하세요.
  • 도메인 제한 공유 조직 정책 및 맞춤 조직 정책은 ACL로 부여된 액세스를 차단하지 않으므로 의도치 않은 액세스가 발생할 수 있습니다.
  • 프로젝트 수준 이상으로 IAM 조건이 설정된 프로젝트에서 ACL을 사용하면 예기치 않은 동작과 액세스가 발생할 수 있습니다.

대개 다음과 같은 사례에서 ACL을 사용합니다.

  • 버킷 내에서 개별 객체에 대한 액세스를 맞춤설정해야 합니다. 예를 들어 객체의 업로더에게 해당 객체에 대한 전체 액세스 권한을 부여하되 버킷의 다른 객체에 대한 액세스 권한에는 제한을 두려는 경우입니다.
  • XML API를 명시적으로 사용 중이거나 Amazon S3와 상호 운용성이 필요합니다.

Identity and Access Management(IAM)와 ACL은 모두 버킷과 객체에 대한 액세스 권한을 부여합니다. 즉, 사용자가 버킷이나 객체에 액세스하기 위해서는 이러한 시스템 중 하나에서 관련 권한을 부여받기만 하면 됩니다. 일반적으로 IAM 정책에서 부여한 권한은 ACL에 나타나지 않고, ACL에서 부여한 권한은 IAM 정책에 나타나지 않습니다. 자세한 내용은 IAM과 ACL 관계를 참조하세요.

액세스제어 목록은 무엇인가요?

액세스제어 목록(ACL)은 버킷 및 객체에 액세스할 수 있는 사용자와 해당 사용자에게 제공되는 액세스 권한 수준을 정의하는 데 사용할 수 있는 메커니즘입니다. Cloud Storage에서는 개별 버킷과 객체에 ACL을 적용합니다. 각 ACL은 하나 이상의 항목으로 구성됩니다. 항목은 특정 사용자나 그룹에 특정 작업을 수행할 수 있는 기능을 제공합니다. 각 항목은 다음 두 가지 정보로 구성됩니다.

  • 권한: 수행할 수 있는 작업을 정의합니다(예: 읽기 또는 쓰기).

  • 범위(권한 부여자라고도 함): 특정 작업을 수행할 수 있는 사람을 정의합니다(예: 특정 사용자 또는 사용자 그룹).

예를 들면 한 버킷의 객체에 누구나 액세스할 수 있게 하되, 공동작업자가 이 버킷에서 객체를 추가하거나 삭제하도록 할 수 있습니다. 이 경우 ACL은 두 가지 항목으로 구성됩니다.

  • 이 중 한 항목에서는 READER 범위에 대한 allUsers 권한을 부여합니다.

  • 다른 항목에서는 공동작업자 범위에 WRITER 권한을 줍니다. 이메일 등의 여러 가지 방법으로 공동 작업자를 지정할 수 있습니다.

버킷이나 객체마다 최대 100개의 ACL 항목을 만들 수 있습니다. 항목 범위가 그룹 또는 도메인인 경우 그룹 또는 도메인에 있는 사용자 수에 관계없이 하나의 ACL 항목으로 계산됩니다.

사용자가 버킷이나 객체에 대한 액세스를 요청하면 Cloud Storage 시스템은 버킷 또는 객체 ACL을 읽고 액세스 요청을 허용할지 아니면 거부할지 결정합니다. ACL이 요청된 작업에 대한 사용자 권한을 부여하면 요청이 허용됩니다. ACL이 요청된 작업에 대한 사용자 권한을 부여하지 않으면 요청이 실패하고 403 Forbidden 오류가 반환됩니다.

ACL을 사용하여 버킷 및 객체와 관련된 대부분의 작업을 관리할 수 있지만 버킷을 create 적절한 프로젝트 권한이 있어야 합니다.

권한

권한은 주어진 객체 또는 버킷을 대상으로 수행할 수 있는 작업을 설명합니다.

Cloud Storage에서는 다음 표와 같이 버킷 및 객체에 대한 다음과 같은 공통적 권한을 할당할 수 있습니다.

버킷 객체
READER 사용자가 버킷의 콘텐츠를 나열할 수 있게 합니다. 또한 사용자가 ACL을 제외한 버킷 메타데이터를 읽을 수 있게 합니다. 사용자가 객체의 데이터를 다운로드할 수 있게 합니다.
WRITER READER 권한으로 부여된 모든 액세스 권한을 사용자에게 부여합니다. 또한 멀티파트 업로드를 사용하는 객체 만들기를 포함하여 사용자가 버킷에서 객체를 만들고, 바꾸고, 삭제하도록 허용합니다. 해당 사항 없음. 객체에는 이 권한을 적용할 수 없습니다.
OWNER WRITER 권한으로 부여된 모든 액세스 권한을 사용자에게 부여합니다. 또한 사용자가 ACL을 포함하여 버킷 메타데이터를 읽고 쓰고, 버킷에서 태그 작업을 수행할 수 있게 해줍니다. READER 권한으로 부여된 모든 액세스 권한을 사용자에게 부여합니다. 또한 사용자가 ACL을 포함하여 객체 메타데이터를 읽고 쓸 수 있게 합니다.
기본값 버킷을 만들 때 사전 정의된 project-private ACL이 적용됩니다. 버킷은 항상 project-owners 그룹이 소유합니다. 객체를 업로드할 사전 정의된 project-private ACL이 적용됩니다. 항상 객체를 업로드한 원래 요청자가 객체를 소유합니다.

이 페이지에서는 일반적으로 권한을 READER, WRITER, OWNER로 지칭합니다. 이러한 권한은 JSON API와 Google Cloud 콘솔에서 지정됩니다. XML API를 사용하는 경우 이에 해당하는 권한은 각각 READ, WRITE, FULL_CONTROL입니다.

범위

범위는 누가 주어진 권한을 갖고 있는지 지정합니다.

ACL은 하나 이상의 항목으로 구성되며, 각 항목은 범위에 권한을 부여합니다. 다음 항목을 사용하여 ACL 범위를 지정할 수 있습니다.

범위('권한 부여자') 항목 유형 예
모든 항목의 특수 식별자 사용자 allUsers
모든 유효한 계정의 특수 식별자 사용자 allAuthenticatedUsers
사용자 계정 이메일 주소 사용자 collaborator@gmail.com
Google 그룹 이메일 주소 그룹 work-group@googlegroups.com
프로젝트의 단축값 프로젝트 owners-123456789012
Google Workspace 도메인 도메인 USERNAME@YOUR_DOMAIN.com
Cloud ID 도메인 도메인 USERNAME@YOUR_DOMAIN.com
직원 ID 풀의 단일 ID 주 구성원 //iam.googleapis.com/locations/global/workforcePools/my-pool/subject/my-user@example.com
그룹의 모든 직원 ID PrincipalSet //iam.googleapis.com/locations/global/workforcePools/my-pool/group/my-group

  • 모든 항목의 특수 식별자:

    특수 범위 식별자 allUsers는 인터넷의 모든 항목을 나타냅니다. 이 식별자는 User 항목 유형이지만 Google Cloud 콘솔을 사용할 때는 Public 항목 유형으로 라벨이 지정됩니다.

  • 모든 유효한 계정의 특수 식별자:

    특수 범위 식별자 allAuthenticatedUsers는 서비스 계정을 포함하여 대부분의 인증된 계정을 나타냅니다. 자세한 내용은 IAM 개요를 참조하세요. 이 식별자는 User 항목 유형이지만 Google Cloud Console을 사용할 때는 Public 항목 유형으로 라벨이 지정됩니다.

  • 사용자 계정 이메일 주소:

    사용자 계정이 있는 모든 사용자에게는 해당 계정과 연결된 고유한 이메일 주소가 있어야 합니다. 사용자 계정과 연결된 이메일 주소를 사용하여 범위를 지정할 수 있습니다.

    Cloud Storage는 해당 항목을 삭제하거나 교체할 때까지 ACL에 제공된 이메일 주소를 기억합니다. 사용자가 이메일 주소를 변경하는 경우 ACL 항목을 업데이트하여 해당 변경사항을 반영해야 합니다.

  • Google 그룹 이메일 주소:

    모든 Google 그룹에는 그룹과 연결된 이메일 주소가 있습니다. 예를 들어 Cloud Storage 공지 그룹의 이메일 주소는 gs-announce@googlegroups.com입니다. 모든 Google 그룹의 홈페이지에서 정보를 클릭하면 Google 그룹과 연결된 이메일 주소를 찾을 수 있습니다.

    사용자 계정 이메일 주소와 마찬가지로 Cloud Storage는 항목이 삭제될 때까지 ACL에 제공된 그룹 이메일 주소를 저장합니다. Google 그룹 이메일 주소는 영구적이고 변경되지 않기 때문에 Google 그룹 이메일 주소 업데이트에 대해 걱정할 필요가 없습니다.

  • 프로젝트의 단축값:

    단축값을 사용하면 프로젝트의 뷰어, 편집자, 소유자에게 일괄 액세스 권한을 부여할 수 있습니다. 단축값은 프로젝트 역할과 연결된 프로젝트 번호를 결합합니다. 예를 들어 프로젝트 867489160491에서 편집자는 editors-867489160491로 식별됩니다. Google Cloud 콘솔의 홈페이지에서 프로젝트 번호를 찾을 수 있습니다.

    일반적으로 프로덕션 환경에서는 단축값 사용을 피해야 합니다. 단축값을 사용하려면 주 구성원에게 기본 역할을 부여해야 하는데 이는 프로덕션 환경에서는 권장되지 않습니다.

  • Google Workspace 또는 Cloud ID:

    Google Workspace 및 Cloud ID 고객은 자신의 이메일 계정을 인터넷 도메인 이름에 연결할 수 있습니다. 이렇게 하면 각 이메일 계정 형식은 USERNAME@YOUR_DOMAIN.com이 됩니다. Google Workspace 또는 Cloud ID와 연결된 인터넷 도메인 이름을 사용하여 범위를 지정할 수 있습니다.

  • 직원 ID:

    직원 ID 제휴를 사용하면 사용자가 Google Cloud 서비스에 액세스할 수 있도록 외부 ID 공급업체(IdP)를 통해 IAM을 사용하여 사용자 그룹을 인증 및 승인할 수 있습니다.

권한 묶음 및 범위

Cloud Storage에서 ACL을 지정할 때 여러 권한을 부여하기 위해 여러 권한을 나열할 필요가 없습니다. Cloud Storage는 공통적 권한을 사용하므로 WRITER 권한을 부여하면 READER 권한도 부여되고 OWNER 권한을 부여하면 READER 및 WRITER 권한도 부여됩니다.

ACL을 지정할 때 대부분의 도구를 사용하면 동일한 항목에 여러 범위를 지정할 수 있습니다. 가장 포괄적인 권한은 범위에 부여된 액세스 권한입니다. 예를 들어, 사용자에게 각각 버킷에 대한 READER 권한과 WRITER 권한을 갖고 있는 2개의 항목을 제공하는 경우 사용자는 버킷에 대한 WRITER 권한을 갖게 됩니다.

XML API에서는 2개의 ACL 항목에 동일한 범위를 제공할 수 없습니다. 예를 들어 사용자에게 버킷에 대한 READ 권한과 WRITE 권한을 부여하면 오류가 발생합니다. 대신 사용자에게 WRITE 권한을 부여하면 READ 권한도 부여됩니다.

사전 정의된 ACL

미리 준비된 ACL이라고도 하는 사전 정의된 ACL은 많은 ACL 항목을 버킷이나 객체에 한 번에 빠르게 적용하는 데 사용할 수 있는 특정 ACL 항목 집합의 별칭입니다.

아래 표에서는 사전 정의된 ACL과 사전 정의된 각 ACL에 적용되는 ACL 항목을 보여줍니다. 아래 표를 사용할 때는 다음에 주의하세요.

  • 프로젝트 소유자 그룹은 프로젝트에서 버킷의 소유권을 가지며 객체를 만드는 사용자는 해당 객체의 소유권을 갖습니다. 익명 사용자가 객체를 만든 경우 프로젝트 소유자 그룹이 객체의 소유권을 갖습니다.

  • 표에는 OWNER, WRITER, READER 권한에 대한 JSON API 설명이 사용되었습니다. 해당하는 XML API 범위는 FULL_CONTROL, WRITE, READ입니다.

    JSON API/gcloud storage XML API 설명
    private private 버킷 또는 객체 소유자에게 버킷 또는 객체에 대한 OWNER 권한을 줍니다.
    bucketOwnerRead bucket-owner-read 객체 소유자에게 OWNER 권한을 주고, 버킷 소유자에게 READER 권한을 줍니다. 이것은 객체에만 사용됩니다.
    bucketOwnerFullControl bucket-owner-full-control 객체 및 버킷 소유자에게 OWNER 권한을 줍니다. 이것은 객체에만 사용됩니다.
    projectPrivate project-private 역할에 따라 프로젝트팀에 권한을 줍니다. 팀에 속한 사람은 누구나 READER 권한을 가집니다. 프로젝트 소유자와 프로젝트 편집자는 OWNER 권한을 가집니다. 새로 생성된 버킷에는 기본적으로 이 ACL이 적용됩니다. 또한 버킷의 기본 객체 ACL이 변경되지 않은 경우 새로 생성되는 객체에 적용되는 기본 ACL입니다.
    authenticatedRead authenticated-read 버킷 또는 객체 소유자에게 OWNER 권한을 부여하고 인증된 모든 사용자 계정 소유자에게 READER 권한을 부여합니다.
    publicRead public-read 버킷 또는 객체 소유자에게 OWNER 권한을 주고, 인증된 사용자와 익명 사용자를 포함한 모든 사용자에게 READER 권한을 줍니다. 객체에 이 ACL을 적용하면 인터넷에 연결된 모든 사용자가 인증 없이 객체를 읽을 수 있습니다. 버킷에 이 ACL을 적용하면 인터넷에 연결된 모든 사용자가 인증 없이 객체를 나열할 수 있습니다.

    * 표 끝부분에 있는 캐싱 관련 참고 사항을 참조하세요.
    publicReadWrite public-read-write 버킷 소유자에게 OWNER 권한을 주고, 인증된 사용자와 익명 사용자를 포함한 모든 사용자에게 READER 및 WRITER 권한을 줍니다. 이 ACL은 버킷에만 적용됩니다. 버킷에 이 ACL을 적용하면 인터넷에 연결된 모든 사용자가 인증 없이 객체를 나열, 생성, 교체, 삭제할 수 있습니다.

    * 표 끝부분에 있는 캐싱 관련 참고 사항을 참조하세요.

* 기본적으로 공개적으로 읽을 수 있는 객체는 3,600초 동안 객체를 캐시 처리할 수 있는 Cache-Control 헤더와 함께 제공됩니다. 업데이트가 즉시 표시되도록 하려면 객체의 Cache-Control 메타데이터를 Cache-Control:private, max-age=0, no-transform으로 설정해야 합니다.

기본 ACL

버킷이 생성되거나 객체가 업로드될 때 ACL을 명시적으로 할당하지 않으면 기본 ACL이 제공됩니다. 객체에 지정된 기본 ACL을 변경할 수 있습니다. 이렇게 하는 프로세스는 기본 객체 ACL 변경에 설명되어 있습니다. 기본 ACL을 변경해도 버킷에 이미 존재하는 객체의 ACL이나 버킷에 이미 존재하는 객체의 ACL은 변경되지 않고 유지됩니다.

기본 버킷 ACL

모든 버킷은 프로젝트 소유자 그룹이 소유합니다. 또한 프로젝트 소유자에게 사전 정의된 ACL을 사용하는 프로젝트 내 모든 버킷에 대한 OWNER 권한이 부여됩니다.

기본 버킷 ACL이 있는 버킷을 만들면, 즉 버킷을 만들 때 사전 정의된 ACL을 지정하지 않으면 버킷에 사전 정의된 projectPrivate ACL이 적용됩니다.

기본 객체 ACL

기본적으로 버킷에 대한 OWNER 권한이나 WRITER 권한을 가진 사용자는 해당 버킷에 객체를 업로드할 수 있습니다. 객체를 업로드할 때 사전 정의된 ACL을 제공하거나 ACL을 아예 지정하지 않을 수 있습니다. ACL을 지정하지 않으면 Cloud Storage는 객체에 버킷의 기본 객체 ACL을 적용합니다. 모든 버킷에 기본 객체 ACL이 있으며 이 ACL은 사전 정의된 ACL 또는 요청에 지정된 ACL(JSON API만 해당) 없이 해당 버킷에 업로드된 모든 객체에 적용됩니다. 모든 버킷의 기본 객체 ACL에 대한 초깃값은 projectPrivate입니다.

객체가 업로드되는 방식에 따라 객체 ACL이 적용됩니다.

  • 인증된 업로드

    업로드할 때 인증된 요청을 생성하고 객체 ACL을 지정하지 않으면 사용자가 객체의 소유자로 표시되고 사전 정의된 projectPrivate ACL이 객체에 기본적으로 적용됩니다. 이는 다음을 의미합니다.

    • 사용자, 즉 객체를 업로드한 사람이 객체 소유자로 나열됩니다. ACL을 수정하여 객체 소유권을 변경할 수 없습니다. 객체 소유권을 변경할 수 있는 유일한 방법은 객체를 교체하는 것입니다.

    • 사용자, 즉 객체 소유자에게 객체에 대한 OWNER 권한이 부여됩니다. 소유자에게 OWNER 권한보다 적은 권한을 주려고 하면 Cloud Storage가 자동으로 권한을 OWNER로 에스컬레이션합니다.

    • 프로젝트 소유자 및 프로젝트 편집자 그룹은 객체에 대한 OWNER 권한을 가집니다.

    • 프로젝트팀 구성원 그룹은 객체에 대한 READER 권한을 가집니다.

  • 익명 업로드

    인증되지 않은 (익명의) 사용자가 객체를 업로드하면(버킷이 allUsers 그룹 WRITER 또는 OWNER 권한을 부여하는 경우에 가능) 위의 설명대로 객체에 기본 버킷 ACL이 적용됩니다.

    익명 사용자는 객체 업로드 중에 사전 정의된 ACL을 지정할 수 없습니다.

ACL 동작

Cloud Storage는 데이터에 액세스할 수 없게 하는 ACL 설정을 방지하는 몇 가지 ACL 수정 규칙을 적용하여 권장사항 준수를 지원합니다.

  • 다른 버킷 또는 객체 소유자를 지정하는 ACL을 적용할 수 없습니다.

    ACL을 수정하여 버킷 및 객체 소유권을 변경할 수 없습니다. 버킷이나 객체에 새 ACL을 적용하는 경우 버킷 또는 객체 소유자가 새 ACL에서 변경되지 않는지 확인합니다.

  • 버킷 또는 객체 소유자는 항상 버킷 또는 객체에 대한 OWNER 권한을 가집니다.

    버킷의 소유자는 프로젝트 소유자 그룹이고, 객체의 소유자는 객체를 업로드한 사용자나 프로젝트 소유자 그룹(익명 사용자가 객체를 업로드한 경우)입니다.

    버킷이나 객체에 새 ACL을 적용할 때 부여를 생략하면 Cloud Storage가 버킷 또는 객체 소유자에게 OWNER 권한을 추가합니다. 익명 사용자가 객체를 만든 경우를 제외하고 프로젝트 소유자 그룹에 객체에 대한 OWNER 권한이 부여되지 않으므로 명시적으로 이를 포함해야 합니다.

버킷이나 객체의 소유권을 변경하는 ACL을 적용할 수 없습니다. 소유권과 OWNER 권한을 혼동해서는 안 됩니다. Cloud Storage에서 생성된 버킷 및 객체 소유권은 영구적입니다. 그러나 객체를 교체하여 객체의 소유권을 효과적으로 변경할 수 있습니다. 단, 버킷의 경우 이러한 방식으로 소유권을 변경할 수 없습니다. 교체는 기본적으로 바로 뒤에 업로드 작업이 오는 삭제 작업입니다. 업로드 작업 중에 업로드를 수행하는 사람이 객체 소유자가 됩니다. 객체를 교체하려면 교체를 수행하고 이를 통해 객체 소유권을 얻는 사람에게 객체가 업로드되는 버킷에 대한 WRITER 또는 OWNER 권한이 있어야 합니다.

다음 단계