액세스제어 목록(ACL)

예시로 이동

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

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

대부분의 경우 ID 및 액세스 관리(IAM)를 사용하여 리소스에 대한 액세스를 관리하는 것이 좋습니다. IAM과 ACL 모두 버킷과 객체에 대한 액세스를 부여합니다. 사용자가 버킷이나 객체에 액세스하기 위해서는 IAM이나 ACL에서 권한을 부여받기만 하면 됩니다.

버킷 내에서 개별 객체에 대한 액세스를 맞춤설정해야 하는 경우에는 대개 ACL을 사용합니다. IAM 권한은 버킷 내의 모든 객체에 적용되기 때문입니다. 그러나 버킷의 모든 객체에 공통적인 액세스를 위해서는 IAM을 사용해야 합니다. 그래야 수행해야 하는 세부 관리의 양이 줄어들기 때문입니다.

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

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

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

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

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

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

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

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

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

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

권한

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

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

버킷 객체
READER 사용자가 버킷의 콘텐츠를 나열할 수 있게 합니다. 또한 사용자가 ACL을 제외한 버킷 메타데이터를 읽을 수 있게 합니다. 사용자가 객체의 데이터를 다운로드할 수 있게 합니다.
WRITER 사용자가 버킷의 객체를 나열, 생성, 교체, 삭제할 수 있습니다. 1 해당 없음. 객체에는 이 권한을 적용할 수 없습니다.
OWNER 사용자에게 버킷에 대한 READERWRITER 권한을 줍니다. 또한 사용자가 ACL을 포함한 버킷 메타데이터를 읽고 쓸 수 있게 합니다. 사용자에게 READER 액세스 권한을 줍니다. 또한 사용자가 ACL을 포함한 객체 메타데이터를 읽고 쓸 수 있게 합니다.
기본 버킷을 만들 때 사전 정의된 project-private ACL이 적용됩니다. 버킷은 항상 project-owners 그룹이 소유합니다. 객체를 업로드할 사전 정의된 project-private ACL이 적용됩니다. 항상 객체를 업로드한 원래 요청자가 객체를 소유합니다.

1 다음 버킷 메타데이터 속성은 변경할 수 없습니다. acl, cors, defaultObjectAcl, lifecycle, logging, versioning, website.

이 페이지에서는 일반적으로 권한을 READER, WRITER, OWNER로 지칭합니다. 이러한 권한은 JSON APIGoogle Cloud Console에서 지정됩니다. XML API를 사용하는 경우 이에 해당하는 권한은 각각 READ, WRITE, FULL_CONTROL입니다. 그리고 OAuth 2.0 인증을 사용하여 도구와 애플리케이션이 사용자 대신 Google Cloud Storage API에 액세스할 수 있도록 인증하는 경우에는 액세스가 OAuth 범위 devstorage.read_only, devstorage.read_write, devstorage.full_control로 제한됩니다. 다음 표에 일반적인 권한 용어가 요약되어 있습니다.

JSON API XML API OAuth2 범위
READER READ https://www.googleapis.com/auth/devstorage.read_only
WRITER WRITE https://www.googleapis.com/auth/devstorage.read_write
OWNER FULL_CONTROL https://www.googleapis.com/auth/devstorage.full_control

범위

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

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

범위('권한 부여자') 항목 유형
Google 계정 이메일 주소 사용자 collaborator@gmail.com
Google 그룹 이메일 주소 그룹 work-group@googlegroups.com
프로젝트의 단축값 프로젝트 owners-123456789012
G Suite 도메인 도메인 USERNAME@YOUR_DOMAIN.com
Cloud ID 도메인 도메인 USERNAME@YOUR_DOMAIN.com
모든 Google 계정 소유자의 특수 식별자 사용자 allAuthenticatedUsers
모든 사용자의 특수 식별자 사용자 allUsers
  • Google 계정 이메일 주소:

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

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

  • Google 그룹 이메일 주소:

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

    Google 계정 이메일 주소와 마찬가지로 Cloud Storage는 해당 항목을 삭제할 때까지 ACL에 제공된 그룹 이메일 주소를 기억합니다. Google 그룹 이메일 주소는 영구적이며 변경 가능성이 적으므로 Google 그룹스 이메일 주소 업데이트에 대해 걱정할 필요가 없습니다.

  • 프로젝트의 단축값:

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

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

  • G Suite 또는 Cloud ID:

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

  • 모든 Google 계정 소유자의 특수 식별자:

    이 특수 범위 식별자는 Google 계정으로 인증된 모든 사용자를 나타냅니다. 모든 Google 계정 소유자의 특수 범위 식별자는 allAuthenticatedUsers입니다. 이 식별자는 User 항목 유형이지만 Cloud Console을 사용할 때는 Public 항목 유형으로 라벨이 지정됩니다.

  • 모든 사용자의 특수 식별자:

    이 특수 범위 식별자는 Google 계정의 유무에 관계없이 인터넷에 연결된 모든 사용자를 나타냅니다. 모든 사용자의 특수 범위 식별자는 allUsers입니다. 이 식별자는 User 항목 유형이지만 Cloud Console을 사용할 때는 Public 항목 유형으로 라벨이 지정됩니다.

권한 묶음 및 범위

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

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

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

사전 정의된 ACL

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

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

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

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

    JSON API XML API/gsutil 설명
    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 권한을 주고, 인증된 모든 Google 계정 소유자에게 READER 권한을 줍니다.
    publicRead public-read 버킷 또는 객체 소유자에게 OWNER 권한을 주고, 인증된 사용자와 익명 사용자를 포함한 모든 사용자에게 READER 권한을 줍니다. 객체에 이 ACL을 적용하면 인터넷에 연결된 모든 사용자가 인증 없이 객체를 읽을 수 있습니다. 버킷에 이 ACL을 적용하면 인터넷에 연결된 모든 사용자가 인증 없이 객체를 나열할 수 있습니다.

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

    publicReadWrite public-read-write 버킷 소유자에게 OWNER 권한을 주고, 인증된 사용자와 익명 사용자를 포함한 모든 사용자에게 READERWRITER 권한을 줍니다. 이 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도 다른 관리 설정과 마찬가지로 적극적으로 관리해야 효과가 있습니다. 다른 사용자가 버킷이나 객체에 액세스할 수 있도록 하려면 먼저 버킷이나 객체를 공유할 대상을 확인하고 해당하는 각 사용자에게 어떤 역할을 부여할지 결정합니다. 시간이 지나면서 프로젝트 관리, 사용 패턴, 조직 소유권이 변경되면 버킷과 객체에 대한 ACL 설정을 수정해야 할 수 있습니다. 특히 대규모 조직 또는 대규모 사용자 그룹의 버킷과 객체를 관리하는 경우 더욱 그렇습니다. 액세스 제어 설정 평가 및 계획 시 다음과 같은 권장사항을 염두에 두어야 합니다.

  • 버킷과 객체에 대한 액세스 권한을 부여할 때 최소 권한 원칙을 사용합니다.

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

  • 모르는 사람에게 OWNER 권한을 부여하지 않습니다.

    OWNER 권한을 부여하면 사용자가 ACL을 변경하고 데이터를 제어할 수 있습니다. 객체와 버킷에 대한 관리 권한을 위임하려면 OWNER 권한을 사용합니다.

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

    allUsersallAuthenticatedUsers 범위는 인터넷의 모든 사용자가 데이터를 읽고 분석할 수 있도록 허용되는 경우에만 사용해야 합니다. 이러한 범위가 일부 애플리케이션과 상황에는 유용하지만, 일반적으로 모든 사용자에게 OWNER 권한을 부여하는 것은 바람직하지 않습니다.

  • 액세스할 수 없는 객체를 생성하는 방식으로 ACL을 설정하지 않습니다.

    액세스할 수 없는 객체는 다운로드하거나 읽을 수 없으며 삭제만 할 수 있는 객체입니다. 객체 소유자가 누구에게도 객체에 대한 OWNER 또는 READER 권한을 부여하지 않고 프로젝트를 떠나는 경우 이러한 문제가 발생합니다. 이 문제를 방지하려면 사용자 또는 다른 사람이 버킷에 객체를 업로드할 때 bucket-owner-read 또는 bucket-owner-full-control 사전 정의된 ACL을 사용합니다.

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

    기본적으로 프로젝트 소유자 그룹만이 버킷 생성 시 버킷에 대한 OWNER 권한을 가집니다. 한 팀원이 그룹을 떠나도 다른 프로젝트 소유자가 계속 버킷을 관리할 수 있도록 프로젝트 소유자 그룹에 구성원이 항상 2명 이상 있어야 합니다.

  • Cloud Storage의 상호 운용 가능한 동작을 파악합니다.

    Amazon S3 등의 다른 저장소 서비스와 상호 운용 가능한 액세스를 위해 XML API를 사용할 때 서명 식별자가 ACL 구문을 결정합니다. 예를 들어, 사용 중인 도구나 라이브러리가 Cloud Storage에 ACL을 검색하도록 요청하는 경우 요청에서 다른 저장소 제공업체의 서명 식별자를 사용하면 Cloud Storage가 해당 저장소 제공업체의 ACL 구문을 사용하는 XML 문서를 반환합니다. 사용 중인 도구나 라이브러리가 Cloud Storage에 ACL을 적용하도록 요청하고 다른 저장소 제공업체의 서명 식별자가 요청에 사용되는 경우 Cloud Storage는 해당 저장소 제공업체의 ACL 구문을 사용하는 XML 문서를 수신할 것으로 기대합니다.

    Amazon S3와 상호 운용 가능한 액세스를 위해 XML API를 사용하는 방법에 대한 자세한 내용은 Amazon S3에서 Google Cloud Storage로 이전을 참조하세요.

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

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

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

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

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

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

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

다음 단계