Azure Data Lake Storage Gen2의 ACL(액세스 제어 목록)

아티클
04/24/2024

Azure Data Lake Storage Gen2는 Azure RBAC(Azure 역할 기반 액세스 제어)와 POSIX 같은 ACL(액세스 제어 목록)을 모두 지원하는 액세스 제어 모델을 구현합니다. 이 문서에서는 Data Lake Storage Gen2의 액세스 제어 목록에 대해 설명합니다. Azure RBAC와 ACL을 어떻게 통합하는지 및 시스템에서 권한 부여 결정을 내리기 위해 이를 어떻게 평가하는지 알아보려면 Azure Data Lake Storage Gen2의 액세스 제어 모델을 참조하세요.

ACL 정보

보안 주체를 파일 및 디렉터리에 대한 액세스 수준과 연결할 수 있습니다. 각 연결은 ‘ACL(액세스 제어 목록)’에 항목으로 캡처됩니다. 스토리지 계정의 각 파일과 디렉터리에는 액세스 제어 목록이 있습니다. 보안 주체가 파일이나 디렉터리에 대한 작업을 시도하는 경우 ACL 검사는 해당 보안 주체(사용자, 그룹, 서비스 주체 또는 관리 ID)에게 작업을 수행할 수 있는 올바른 권한 수준이 있는지 확인합니다.

참고 항목

ACL은 동일한 테넌트의 보안 주체에만 적용되며 공유 키 또는 SAS(공유 액세스 서명) 토큰 인증을 사용하는 사용자에게는 적용되지 않습니다. 이는 ID가 호출자와 연결되어 있지 않으며 따라서 보안 주체 권한 기반 권한 부여를 수행할 수 없기 때문입니다.

ACL 설정 방법

파일 및 디렉터리 수준 권한을 설정하려면 다음 문서를 참조하세요.

환경	문서
Azure Storage Explorer	Azure Storage Explorer를 사용하여 Azure Data Lake Storage Gen2에서 ACL 관리
Azure Portal	Azure Portal을 사용하여 Azure Data Lake Storage Gen2에서 ACL 관리
.NET	.NET을 사용하여 Azure Data Lake Storage Gen2에서 ACL 관리
Java	Java를 사용하여 Azure Data Lake Storage Gen2에서 ACL 관리
Python	Python을 사용하여 Azure Data Lake Storage Gen2에서 ACL 관리
JavaScript(Node.js)	Node.js에서 JavaScript SDK를 사용하여 Azure Data Lake Storage Gen2에서 ACL 관리
PowerShell	PowerShell을 사용하여 Azure Data Lake Storage Gen2에서 ACL 관리
Azure CLI	Azure CLI를 사용한 Azure Data Lake Storage Gen2의 ACL 관리
REST API	경로 - 업데이트

Important

보안 주체가 서비스 주체인 경우 관련 앱 등록의 개체 ID가 아니라 서비스 주체의 개체 ID를 사용하는 것이 중요합니다. 서비스 주체의 개체 ID를 가져오려면 Azure CLI를 연 후 az ad sp show --id <Your App ID> --query objectId 명령을 사용합니다. <Your App ID> 자리 표시자를 앱 등록의 앱 ID로 바꾸어야 합니다. 서비스 주체는 명명된 사용자로 처리됩니다. 명명된 사용자와 마찬가지로 이 ID를 ACL에 추가합니다. 명명된 사용자는 이 문서의 뒷부분에 설명되어 있습니다.

ACL 유형

두 가지 종류의 액세스 제어 목록, 즉 액세스 ACL 및 기본 ACL이 있습니다.

액세스 ACL은 개체에 대한 액세스를 제어합니다. 파일과 디렉터리 모두에 액세스 ACL이 있습니다.

기본 ACL은 디렉터리에 생성된 모든 자식 항목의 액세스 ACL을 결정하는 디렉터리와 연결된 ACL 템플릿입니다. 파일에는 기본 ACL이 없습니다.

액세스 ACL 및 기본 ACL의 구조는 모두 동일합니다.

참고 항목

부모에서 기본 ACL을 변경해도 이미 존재하는 자식 항목의 액세스 ACL 또는 기본 ACL에는 영향을 주지 않습니다.

권한 수준

컨테이너에 있는 디렉터리와 파일에 대한 권한은 읽기, 쓰기, 실행이며 다음 표와 같이 파일 및 디렉터리에서 사용할 수 있습니다.

	파일	디렉터리
읽기(R)	파일의 내용을 읽을 수 있습니다.	디렉터리의 내용을 나열하려면 읽기 및 실행이 필요합니다.
쓰기(W)	쓰거나 파일에 추가할 수 있습니다.	디렉터리에 자식 항목을 만들려면 쓰기 및 실행이 필요합니다.
실행(X)	Data Lake Storage Gen2의 컨텍스트에서는 의미가 없습니다.	디렉터리의 자식 항목을 트래버스하는 데 필요합니다.

참고 항목

ACL만 사용하여 권한을 부여하는 경우(Azure RBAC 없음) 보안 주체에 파일에 대한 읽기 또는 쓰기 액세스 권한을 부여하려면 컨테이너의 루트 폴더와 파일을 받는 폴더 계층 구조의 각 폴더에 보안 주체 실행 권한을 부여해야 합니다.

사용 권한에 대한 짧은 형식

RWX는 읽기 + 쓰기 + 실행을 나타내는 데 사용됩니다. 읽기=4, 쓰기=2 및 실행=1의 압축된 숫자 형식이 있으며, 그 합계는 권한을 나타냅니다. 다음은 몇 가지 예입니다.

숫자 형식	약식	의미
7	`RWX`	읽기 + 쓰기 + 실행
5	`R-X`	읽기 + 실행
4	`R--`	읽음
0	`---`	사용 권한 없음

권한 상속

Data Lake Storage Gen2에서 사용하는 POSIX 스타일 모델에서는 항목에 대한 권한이 항목 자체에 저장됩니다. 즉, 자식 항목이 이미 생성된 후에 사용 권한이 설정된 경우 항목에 대한 사용 권한을 부모 항목에서 상속할 수 없습니다. 자식 항목이 생성되기 전에 부모 항목에 기본 권한이 설정된 경우에만 권한이 상속됩니다.

다음 표에서는 보안 주체가 작업 열에 나열된 작업을 수행할 수 있도록 하는 데 필요한 ACL 항목을 보여 줍니다.

다음 표의 열은 가상 디렉터리 계층 구조의 각 수준을 나타냅니다. 컨테이너(/)의 루트 디렉터리에 대한 열, Oregon이라는 하위 디렉터리, Oregon 디렉터리의 Portland라는 하위 디렉터리, Portland 디렉터리의 Data.txt라는 텍스트 파일이 있습니다.

Important

이 표에서는 Azure 역할 할당 없이 ACL만 사용한다고 가정합니다. Azure RBAC와 ACL을 결합하는 비슷한 표를 보려면 권한 표: Azure RBAC, ABAC, ACL 결합을 참조하세요.

연산	/	Oregon/	Portland/	Data.txt
Read Data.txt	`--X`	`--X`	`--X`	`R--`
Append to Data.txt	`--X`	`--X`	`--X`	`RW-`
Delete Data.txt	`--X`	`--X`	`-WX`	`---`
/Oregon/ 삭제	`-WX`	`RWX`	`RWX`	`---`
/Oregon/Portland/ 삭제	`--X`	`-WX`	`RWX`	`---`
Create Data.txt	`--X`	`--X`	`-WX`	`---`
List /	`R-X`	`---`	`---`	`---`
List /Oregon/	`--X`	`R-X`	`---`	`---`
List /Oregon/Portland/	`--X`	`--X`	`R-X`	`---`

파일 및 디렉터리 삭제

이전 표에 표시된 것처럼 디렉터리 권한이 올바르게 설정되어 있으면 파일을 삭제하는 데 파일에 대한 쓰기 권한이 필요하지 않습니다. 그러나 디렉터리와 해당 콘텐츠를 모두 삭제하려면 부모 디렉터리에 쓰기 + 실행 권한이 있어야 합니다. 삭제할 디렉터리와 그 안의 모든 디렉터리에 읽기 + 쓰기 + 실행 권한이 필요합니다.

참고 항목

루트 디렉터리 "/"는 절대 삭제할 수 없습니다.

사용자 및 ID

모든 파일 및 디렉터리에는 이러한 ID에 대한 고유 권한이 있습니다.

소유 그룹
소유 그룹
명명된 사용자
명명된 그룹
명명된 서비스 주체
명명된 관리 ID
기타 모든 사용자

사용자 및 그룹의 ID는 Microsoft Entra ID입니다. 따라서 별도로 명시하지 않는 한 Data Lake Storage Gen2 컨텍스트에서 사용자는 Microsoft Entra 사용자, 서비스 주체, 관리 ID 또는 보안 그룹을 참조할 수 있습니다.

슈퍼 사용자

슈퍼 사용자는 모든 사용자 중 가장 많은 권한을 가집니다. 슈퍼 사용자의 권한은 다음과 같습니다.

모든 파일과 폴더에 대한 RWX 권한을 가집니다.
모든 파일이나 폴더에 대한 권한을 변경할 수 있습니다.
모든 파일이나 폴더의 소유 사용자 또는 소유 그룹을 변경할 수 있습니다.

공유 키, 계정 SAS, 서비스 SAS를 사용하여 컨테이너, 파일, 디렉터리를 만드는 경우 소유자 및 소유 그룹은 $superuser로 설정됩니다.

소유 그룹

항목을 만든 사용자는 자동으로 항목의 소유 사용자가 됩니다. 소유 사용자는 다음을 수행할 수 있습니다.

소유한 파일의 권한을 변경합니다.
소유 사용자가 대상 그룹의 멤버이면 소유한 파일의 소유 그룹을 변경합니다.

참고 항목

소유 사용자는 파일 또는 디렉터리의 소유 사용자를 변경할 수 없습니다. 슈퍼 사용자만 파일 또는 디렉터리의 소유 사용자를 변경할 수 있습니다.

소유 그룹

POSIX ACL에서 모든 사용자는 주 그룹과 연결됩니다. 예를 들어 "Alice" 사용자는 "finance" 그룹에 속할 수 있습니다. 또한 Alice는 여러 그룹에 속할 수 있지만 항상 한 그룹을 주 그룹으로 지정합니다. POSIX에서 Alice가 파일을 만들 때는 해당 파일의 소유 그룹이 자신의 주 그룹(여기서는 “finance”임)으로 설정됩니다. 그러지 않으면 소유 그룹은 다른 사용자/그룹에 할당된 사용 권한과 유사하게 동작합니다.

새 파일 또는 디렉터리에 대한 소유 그룹 할당

사례 1: 루트 디렉터리 /입니다. 이 디렉터리는 Data Lake Storage Gen2 컨테이너를 만들 때 만들어집니다. 이 경우 소유 그룹은 OAuth를 사용하여 컨테이너를 만든 사용자로 설정됩니다. 공유 키, 계정 SAS 또는 서비스 SAS를 사용하여 컨테이너를 만드는 경우 소유자 및 소유 그룹은 $superuser로 설정됩니다.
사례 2(기타 모든 경우): 새 항목을 만들 때 소유 그룹이 부모 디렉터리에서 복사됩니다.

소유 그룹 변경

소유 그룹은 다음에 의해 변경될 수 있습니다.

모든 슈퍼 사용자
소유 사용자가 대상 그룹의 구성원이기도 한 경우 소유 사용자입니다.

참고 항목

소유 그룹은 파일 또는 디렉터리의 ACL을 변경할 수 없습니다. 루트 디렉터리의 경우 소유 그룹은 계정을 만든 사용자로 설정되지만, 위의 사례 1에서 단일 사용자 계정은 소유 그룹을 통해 권한을 제공하는 데 적합하지 않습니다. 해당하는 경우 올바른 사용자 그룹에 이 권한을 할당할 수 있습니다.

권한 평가 방법

ID는 다음 순서로 평가됩니다.

슈퍼 사용자
소유 사용자
명명된 사용자, 서비스 주체 또는 관리 ID
소유 그룹 또는 명명된 그룹
기타 모든 사용자

둘 이상의 ID가 보안 주체에 적용되는 경우 첫 번째 ID와 연결된 권한 수준이 부여됩니다. 예를 들어 보안 주체가 소유 사용자이자 명명된 사용자인 경우 소유 사용자와 연결된 권한 수준이 적용됩니다.

명명된 그룹은 모두 함께 고려됩니다. 보안 주체가 둘 이상의 명명된 그룹의 멤버인 경우 시스템은 원하는 권한이 부여될 때까지 각 그룹을 평가합니다. 명명된 그룹이 원하는 권한을 제공하지 않으면 시스템은 다른 모든 사용자와 연결된 권한에 대해 요청을 평가하도록 이동합니다.

다음 의사 코드는 스토리지 계정에 대한 액세스 검사 알고리즘을 나타냅니다. 이 알고리즘은 ID가 평가되는 순서를 보여 줍니다.

def access_check( user, desired_perms, path ) :
  # access_check returns true if user has the desired permissions on the path, false otherwise
  # user is the identity that wants to perform an operation on path
  # desired_perms is a simple integer with values from 0 to 7 ( R=4, W=2, X=1). User desires these permissions
  # path is the file or directory
  # Note: the "sticky bit" isn't illustrated in this algorithm

  # Handle super users.
  if (is_superuser(user)) :
    return True

  # Handle the owning user. Note that mask isn't used.
  entry = get_acl_entry( path, OWNER )
  if (user == entry.identity)
      return ( (desired_perms & entry.permissions) == desired_perms )

  # Handle the named users. Note that mask IS used.
  entries = get_acl_entries( path, NAMED_USER )
  for entry in entries:
      if (user == entry.identity ) :
          mask = get_mask( path )
          return ( (desired_perms & entry.permissions & mask) == desired_perms)

  # Handle named groups and owning group
  member_count = 0
  perms = 0
  entries = get_acl_entries( path, NAMED_GROUP | OWNING_GROUP )
  mask = get_mask( path )
  for entry in entries:
    if (user_is_member_of_group(user, entry.identity)) :
        if ((desired_perms & entry.permissions & mask) == desired_perms)
            return True

  # Handle other
  perms = get_perms_for_other(path)
  mask = get_mask( path )
  return ( (desired_perms & perms & mask ) == desired_perms)

마스크

액세스 검사 알고리즘에서 설명한 대로 마스크는 명명된 사용자, 소유 그룹 및 명명된 그룹에 대한 액세스를 제한합니다.

새 Data Lake Storage Gen2 컨테이너의 경우 루트 디렉터리("/")의 액세스 ACL에 대한 마스크는 기본적으로 디텍터리에 대해 750, 파일에 대해 640으로 설정됩니다. 다음 표에서는 이러한 권한 수준의 기호 표기법을 보여 줍니다.

Entity	Directories	Files
소유 사용자	`rwx`	`rw-`
소유 그룹	`r-x`	`r--`
기타	`---`	`---`

저장소 전용 시스템의 파일과는 관련이 없으므로 파일은 X비트를 받지 않습니다.

마스크는 호출별로 지정할 수 있습니다. 이렇게 하면 클러스터와 같은 다양한 소비 시스템에서 파일 작업에 대한 다른 유효한 마스크를 갖출 수 있습니다. 지정된 요청에 마스크가 지정되면 기본 마스크를 완전히 재정의합니다.

고정 비트

고정 비트는 POSIX 컨테이너의 고급 기능입니다. Data Lake Storage Gen2의 컨텍스트에서는 고정 비트가 필요하지 않을 수 있습니다. 요약하면 디렉터리에서 고정 비트가 사용하도록 설정된 경우 자식 항목은 자식 항목의 담당 사용자, 디렉터리 소유자 또는 슈퍼 사용자($superuser)만 삭제하거나 이름을 변경할 수 있습니다.

고정 비트는 Azure Portal에서 표시하지 않습니다.

새 파일 및 디렉터리에 대한 기본 권한

기존 디렉터리 아래에 새 파일 또는 디렉터리가 만들어지면 부모 디렉터리의 기본 ACL에 따라 다음이 결정됩니다.

자식 디렉터리의 기본 ACL 및 액세스 ACL
자식 파일의 액세스 ACL(파일에 기본 ACL이 없는 경우)

umask

기본 ACL을 만들 때 umask가 액세스 ACL에 적용되어 기본 ACL의 초기 사용 권한을 결정합니다. 부모 디렉터리에 기본 ACL이 정의된 경우 umask는 사실상 무시되고 부모 디렉터리의 기본 ACL이 이러한 초기 값을 정의하는 데 사용됩니다.

umask는 소유 사용자, 소유 그룹 및 기타에 대한 RWX 값이 포함된 부모 디렉터리의 9비트 값입니다.

Azure Data Lake Storage Gen2에 대한 umask는 007로 설정된 상수 값입니다. 이 값은 다음과 같이 변환됩니다.

umask 구성 요소	숫자 형식	약식	의미
umask.owning_user	0	`---`	소유 사용자의 경우 부모 항목의 액세스 ACL을 자식 항목의 기본 ACL에 복사합니다.
umask.owning_group	0	`---`	소유 그룹의 경우 부모 항목의 액세스 ACL을 자식 항목의 기본 ACL에 복사합니다.
umask.other	7	`RWX`	기타의 경우 자식 항목의 액세스 ACL에 있는 모든 권한을 제거합니다.

FAQ

ACL에 대한 지원을 사용하도록 설정해야 하나요?

아니요. HNS(계층 구조 네임스페이스) 기능이 설정되어 있는 한 ACL을 통한 액세스 제어는 스토리지 계정에 대해 활성화됩니다.

HNS가 해제된 경우에도 Azure RBAC 권한 부여 규칙이 여전히 적용됩니다.

ACL을 적용하는 가장 좋은 방법은 무엇인가요?

항상 ACL 항목에 할당된 주체로 Microsoft Entra 보안 그룹을 사용합니다. 개별 사용자 또는 서비스 주체를 직접 할당할 수 있는 기회를 거부합니다. 이 구조를 사용하면 ACL을 전체 디렉터리 구조에 다시 적용하지 않고도 사용자 또는 서비스 주체를 추가하고 제거할 수 있습니다. 대신 적절한 Microsoft Entra 보안 그룹에서 사용자 및 서비스 주체를 추가하거나 제거할 수 있습니다.

그룹은 여러 방법으로 설정할 수 있습니다. 예를 들어 서버에서 생성된 로그 데이터를 포함하는 /LogData 디렉터리가 있다고 가정해 보겠습니다. ADF(Azure Data Factory)는 해당 폴더에 데이터를 수집합니다. 서비스 엔지니어링 팀의 특정 사용자가 로그를 업로드하고 해당 폴더의 다른 사용자를 관리하며, 다양한 Databricks 클러스터는 해당 폴더의 로그를 분석합니다.

LogsWriter 그룹과 LogsReader 그룹을 만들어 이러한 활동을 활성화할 수 있습니다. 그룹을 만든 후, 다음과 같이 권한을 할당할 수 있습니다.

rwx 권한이 있는 /LogData 디렉터리의 ACL에 LogsWriter 그룹을 추가합니다.
r-x 권한이 있는 /LogData 디렉터리의 ACL에 LogsReader 그룹을 추가합니다.
ADF에 대한 서비스 사용자 개체 또는 MSI(관리 서비스 ID)를 LogsWriters 그룹에 추가합니다.
LogsWriter 그룹에 서비스 엔지니어링 팀의 사용자를 추가합니다.
Databricks에 대한 서비스 사용자 개체 또는 MSI를 LogsReader 그룹에 추가합니다.

서비스 엔지니어링 팀의 사용자가 퇴사하는 경우 LogsWriter 그룹에서 제거하면 됩니다. 해당 사용자를 그룹에 추가하지 않고 해당 사용자에 대한 전용 ACL 항목을 추가한 경우 /LogData 디렉터리에서 해당 ACL 항목을 제거해야 합니다. 또한 /LogData 디렉터리의 전체 디렉터리 계층 구조에 있는 모든 하위 디렉터리 및 파일에서 항목을 제거해야 합니다.

그룹을 만들고 멤버를 추가하려면 Microsoft Entra ID를 사용하여 기본 그룹 만들기 및 멤버 추가를 참조하세요.

Important

Azure Data Lake Storage Gen2는 Microsoft Entra ID를 사용하여 보안 그룹을 관리합니다. Microsoft Entra ID에서는 특정 보안 주체의 그룹 멤버 자격을 200개 미만으로 제한하는 것이 좋습니다. 이 권장 사항은 Microsoft Entra 애플리케이션 내에서 보안 주체의 그룹 멤버 자격 정보를 제공하는 JWT(JSON Web Token)의 제한 사항 때문입니다. 이 제한을 초과하면 Data Lake Storage Gen2에서 예기치 않은 성능 문제가 발생할 수 있습니다. 자세한 내용은 Microsoft Entra ID를 사용하여 애플리케이션에 대한 그룹 클레임 구성을 참조하세요.

Azure RBAC 및 ACL 권한은 어떻게 평가되나요?

시스템에서 Azure RBAC 및 ACL을 평가하여 스토리지 계정 리소스에 대한 권한 부여 결정을 내리는 방법을 알아보려면 권한 평가 방법을 참조하세요.

Azure 역할 할당 및 ACL 항목에 대해 어떤 제한이 있나요?

다음 표에서는 Azure RBAC를 사용하여 "정교하지 않은" 권한(스토리지 계정 또는 컨테이너에 적용되는 권한)을 관리하고 ACL을 사용하여 "세분화된" 권한(파일 및 디렉터리에 적용되는 권한)을 관리할 때 고려해야 하는 제한 사항에 대한 요약 보기를 제공합니다. ACL 할당에 보안 그룹을 사용합니다. 그룹을 사용하면 구독당 최대 역할 할당 수와 파일 또는 디렉터리당 최대 ACL 항목 수를 초과할 가능성이 줄어듭니다.

메커니즘	범위	제한	지원되는 권한 수준
Azure RBAC	스토리지 계정, 컨테이너. 구독 또는 리소스 그룹 수준에서 리소스 간 Azure 역할 할당.	구독에서 4,000개의 Azure 역할 할당	Azure 역할(기본 제공 또는 사용자 지정)
ACL	디렉터리, 파일	파일 및 디렉터리당 32개 ACL 항목(효과적으로 28개 ACL 항목). 액세스 및 기본 ACL에는 각각 고유한 32개의 ACL 항목 제한이 있습니다.	ACL 권한

Data Lake Storage Gen2에서 Azure RBAC의 상속을 지원하나요?

Azure 역할 할당은 상속됩니다. 할당은 구독, 리소스 그룹 및 스토리지 계정 리소스에서 컨테이너 리소스로 전달됩니다.

Data Lake Storage Gen2에서 ACL의 상속을 지원하나요?

기본 ACL을 사용하여 부모 디렉터리 아래에 만들어진 새로운 자식 하위 디렉터리 및 파일에 대한 ACL을 설정할 수 있습니다. 기존 하위 항목에 대한 ACL을 업데이트하려면 원하는 디렉터리 계층 구조에 대한 ACL을 재귀적으로 추가, 업데이트 또는 제거해야 합니다. 지침은 이 문서의 ACL 설정 방법 섹션에서 참조하세요.

디렉터리 및 해당 내용을 재귀적으로 삭제하는 데 필요한 권한은 무엇인가요?

호출자에게 '슈퍼 사용자' 권한이 있어야 합니다.

또는

부모 디렉터리에 쓰기 + 실행 권한이 있어야 합니다.
삭제할 디렉터리와 그 안의 모든 디렉터리에 읽기 + 쓰기 + 실행 권한이 필요합니다.

참고 항목

디렉터리의 파일을 삭제하는 데에는 쓰기 권한이 필요하지 않습니다. 또한 루트 디렉터리("/")는 절대로 삭제할 수 없습니다.

파일 또는 디렉터리의 소유자는 누구인가요?

파일 또는 디렉터리의 작성자는 소유자가 됩니다. 루트 디렉터리의 경우 소유자는 컨테이너를 만든 사용자의 ID입니다.

만드는 파일 또는 디렉터리의 소유 그룹으로 설정되는 그룹은 무엇인가요?

소유 그룹은 새 파일 또는 디렉터리가 만들어지는 부모 디렉터리의 소유 그룹에서 복사됩니다.

파일의 소유 사용자이지만 필요한 RWX 권한이 없습니다. 어떻게 해야 합니까?

소유 사용자는 파일의 권한을 변경하여 필요한 RWX 권한을 부여할 수 있습니다.

ACL에 GUID가 표시되는 경우가 있습니다. 왜 그런가요?

항목이 사용자를 나타내고 해당 사용자가 Microsoft Entra에 더 이상 존재하지 않는 경우 GUID가 표시됩니다. 일반적으로 이는 사용자가 퇴사하거나 Microsoft Entra ID에서 해당 계정이 삭제된 경우에 발생합니다. 또한 서비스 주체와 보안 그룹은 이를 식별할 UPN(사용자 계정 이름)을 가지고 있지 않으므로 OID 특성(GUID)으로 표시됩니다. ACL을 정리하려면 이러한 GUID 항목을 수동으로 삭제합니다.

서비스 주체에 대한 ACL을 올바르게 설정하려면 어떻게 하나요?

서비스 주체에 대한 ACL을 정의하는 경우 만든 앱 등록에 대한 서비스 주체의 OID(개체 ID)를 사용하는 것이 중요합니다. 등록된 앱에는 특정 Microsoft Entra 테넌트에 별도의 서비스 주체가 있다는 점에 유의해야 합니다. 등록된 앱은 Azure Portal에서 볼 수 있는 OID가 있지만 서비스 주체에는 다른 OID가 있습니다. 문서 앱 등록에 해당하는 서비스 주체의 OID를 가져오기 위해 az ad sp show 명령을 사용할 수 있습니다. 애플리케이션 ID를 매개 변수로 지정합니다. 앱 ID가 18218b12-1895-43e9-ad80-6e8fc1ea88ce인 앱 등록에 해당하는 서비스 주체의 OID를 가져오는 예제는 다음과 같습니다. Azure CLI에서 다음 명령을 실행합니다.

az ad sp show --id 18218b12-1895-43e9-ad80-6e8fc1ea88ce --query objectId

OID가 표시됩니다.

서비스 주체에 대한 올바른 OID가 있는 경우 Storage Explorer의 액세스 관리 페이지로 이동하여 OID를 추가하고 OID에 대한 적절한 권한을 할당합니다. 저장을 선택해야 합니다.

컨테이너의 ACL을 설정할 수 있나요?

아니요. 컨테이너에는 ACL이 없습니다. 그러나 컨테이너의 루트 디렉터리에 대한 ACL을 설정할 수 있습니다. 모든 컨테이너에는 루트 디렉터리가 있으며 컨테이너와 같은 이름을 공유합니다. 예를 들어 컨테이너 이름이 my-container인 경우 루트 디렉터리의 이름은 my-container/입니다.

Azure Storage REST API에는 Set Container ACL이라는 작업이 포함되어 있지만 해당 작업은 컨테이너 또는 컨테이너의 루트 디렉터리에 대한 ACL을 설정하는 데 사용할 수 없습니다. 대신 이 작업을 사용하여 컨테이너의 Blob이 익명 요청으로 액세스할 수 있는지 여부를 나타낼 수 있습니다. Blob 데이터에 대한 모든 요청에 대한 권한 부여를 요구하는 것이 좋습니다. 자세한 내용은 개요: Blob 데이터에 대한 익명 읽기 권한 문제 수정을 참조하세요.

POSIX 액세스 제어 모델에 대한 어디서 자세히 알아볼 수 있나요?

참고 항목

Azure Data Lake Storage Gen2의 액세스 제어 모델

Azure Data Lake Storage Gen2의 ACL(액세스 제어 목록)

ACL 정보

ACL 설정 방법

ACL 유형

권한 수준

사용 권한에 대한 짧은 형식

권한 상속

ACL 권한과 관련된 일반적인 시나리오

파일 및 디렉터리 삭제

사용자 및 ID

슈퍼 사용자

소유 그룹

소유 그룹

새 파일 또는 디렉터리에 대한 소유 그룹 할당

소유 그룹 변경

권한 평가 방법

마스크

고정 비트

새 파일 및 디렉터리에 대한 기본 권한

umask

FAQ

ACL에 대한 지원을 사용하도록 설정해야 하나요?

ACL을 적용하는 가장 좋은 방법은 무엇인가요?

Azure RBAC 및 ACL 권한은 어떻게 평가되나요?

Azure 역할 할당 및 ACL 항목에 대해 어떤 제한이 있나요?

Data Lake Storage Gen2에서 Azure RBAC의 상속을 지원하나요?

Data Lake Storage Gen2에서 ACL의 상속을 지원하나요?

디렉터리 및 해당 내용을 재귀적으로 삭제하는 데 필요한 권한은 무엇인가요?

파일 또는 디렉터리의 소유자는 누구인가요?

만드는 파일 또는 디렉터리의 소유 그룹으로 설정되는 그룹은 무엇인가요?

파일의 소유 사용자이지만 필요한 RWX 권한이 없습니다. 어떻게 해야 합니까?

ACL에 GUID가 표시되는 경우가 있습니다. 왜 그런가요?

서비스 주체에 대한 ACL을 올바르게 설정하려면 어떻게 하나요?

컨테이너의 ACL을 설정할 수 있나요?

POSIX 액세스 제어 모델에 대한 어디서 자세히 알아볼 수 있나요?

참고 항목

추가 리소스