Azure Data Lake Storage Gen2의 액세스 제어 모델
Data Lake Storage Gen2는 다음 권한 부여 메커니즘을 지원합니다.
- 공유 키 권한 부여
- SAS(공유 액세스 서명) 권한 부여
- Azure RBAC(역할 기반 액세스 제어)
- Azure ABAC(특성 기반 액세스 제어)
- ACL(액세스 제어 목록)
공유 키 및 SAS 권한 부여는 Microsoft Entra ID에 ID가 없어도 사용자(또는 애플리케이션)에게 액세스 권한을 부여합니다. 이러한 두 가지 인증 형식을 사용하면 Azure RBAC, Azure ABAC, ACL이 영향을 주지 않습니다.
Azure RBAC 및 ACL은 모두 사용자(또는 애플리케이션)가 Microsoft Entra ID에 ID를 가지고 있어야 합니다. Azure RBAC를 사용하면 스토리지 계정에 있는 데이터의 모든에 대한 읽기 또는 쓰기 권한과 같은 스토리지 계정 데이터에 대한 “정교한” 액세스 권한을 부여할 수 있습니다. Azure ABAC를 사용하면 조건을 추가하여 RBAC 역할 할당을 구체화할 수 있습니다. 예를 들어 특정 태그가 있는 스토리지 계정의 모든 데이터 개체에 대한 읽기 또는 쓰기 권한을 부여할 수 있습니다. ACL을 사용하면 특정 디렉터리 또는 파일에 대한 쓰기 권한과 같은 “세분화된” 액세스 권한을 부여할 수 있습니다.
이 문서에서는 Azure RBAC, ABAC, ACL과 시스템에서 스토리지 계정 리소스에 대한 권한 부여 결정을 내리기 위해 함께 평가하는 방법에 중점을 둡니다.
Azure RBAC(역할 기반 액세스 제어)
Azure RBAC는 역할 할당을 사용하여 권한 집합을 보안 주체에 적용합니다. 보안 주체는 Microsoft Entra ID에 정의된 사용자, 그룹, 서비스 주체 또는 관리 ID를 나타내는 개체입니다. 권한 집합은 보안 주체에 스토리지 계정의 모든 데이터 또는 컨테이너의 모든 데이터에 대한 읽기 또는 쓰기 권한과 같은 "거친" 수준의 액세스 권한을 부여할 수 있습니다.
다음 역할은 보안 주체가 스토리지 계정의 데이터에 액세스할 수 있도록 허용합니다.
| 역할 | 설명 |
|---|---|
| Storage Blob 데이터 소유자 | Blob Storage 컨테이너 및 데이터에 대한 전체 액세스 권한입니다. 이 액세스를 통해 보안 주체는 소유자 항목을 설정하고 모든 항목의 ACL을 수정할 수 있습니다. |
| Storage Blob 데이터 Contributor | Blob Storage 컨테이너 및 Blob에 대한 읽기, 쓰기 및 삭제 액세스 권한입니다. 이 액세스 권한은 보안 주체가 항목의 소유권을 설정하는 것을 허용하지 않지만 보안 주체가 소유한 항목의 ACL을 수정할 수 있습니다. |
| Storage Blob 데이터 읽기 권한자 | Blob Storage 컨테이너 및 Blob을 읽고 나열합니다. |
소유자, 기여자, 읽기 권한자 및 스토리지 계정 기여자와 같은 역할은 보안 주체가 스토리지 계정을 관리하도록 허용하지만 해당 계정 내의 데이터에 대한 액세스를 제공합니다. 그러나 이러한 역할(읽기 권한자 제외)은 다양한 클라이언트 도구에서 데이터에 액세스하는 데 사용할 수 있는 스토리지 키에 대한 액세스 권한을 얻을 수 있습니다.
Azure ABAC(특성 기반 액세스 제어)
Azure ABAC는 특정 작업의 맥락에서 특성을 기반으로 역할 할당 조건을 추가하여 Azure RBAC에서 빌드됩니다. 역할 할당 조건은 필요에 따라 역할 할당에 추가하여 보다 세분화된 액세스 제어를 제공할 수 있는 추가 검사입니다. 조건을 사용하여 특정 리소스에 대한 액세스를 명시적으로 거부할 수 없습니다.
Azure ABAC를 사용하여 Azure Storage에 대한 액세스를 제어하는 방법에 대한 자세한 내용은 Azure 역할 할당 조건을 사용하여 Azure Blob Storage에 대한 액세스 권한 부여를 참조하세요.
ACL(액세스 제어 목록)
ACL을 사용하면 디렉터리 및 파일에 대한 "상세한" 수준의 액세스를 적용할 수 있습니다. ACL은 일련의 ACL 항목을 포함하는 권한 구문입니다. 각 ACL 항목은 보안 주체를 액세스 수준과 연결합니다. 자세한 내용은 Azure Data Lake Storage Gen2의 ACL(액세스 제어 목록)을 참조하세요.
권한 평가 방법
보안 주체 기반 권한 부여 시 다음 다이어그램에 표시된 것처럼 권한이 평가됩니다.
- Azure는 보안 주체에 대한 역할 할당이 있는지 여부를 확인합니다.
- 역할 할당이 있는 경우 역할 할당 조건(2)이 다음에 평가됩니다.
- 그렇지 않으면 ACL(4)이 다음에 평가됩니다.
- Azure는 ABAC 역할 할당 조건이 있는지 여부를 확인합니다.
- 조건이 없는 경우에는 액세스 권한이 부여됩니다.
- 조건이 있는 경우 요청과 일치하는지 여부를 평가합니다(3).
- Azure는 모든 ABAC 역할 할당 조건이 요청의 특성과 일치하는지 여부를 확인합니다.
- 모두 일치하면 액세스 권한이 부여됩니다.
- 이들 중 적어도 하나가 일치하지 않으면 ACL(4)은 다음에 평가됩니다.
- 역할 할당 및 조건을 평가한 후 액세스 권한이 명시적으로 부여되지 않은 경우에는 ACL이 평가됩니다.
- ACL이 요청된 액세스 수준을 허용하는 경우 액세스 권한이 부여됩니다.
- 그렇지 않으면 액세스가 거부됩니다.
Important
시스템에서 액세스 권한을 평가하는 방식 때문에 ACL을 사용하여 역할 할당 및 역할 조건에 의해 이미 부여된 액세스를 제한할 수 없습니다. 시스템이 Azure 역할 할당 및 조건을 먼저 평가하고 할당이 충분한 액세스 권한을 부여하면 ACL이 무시되기 때문입니다.
다음 다이어그램은 디렉터리 내용 나열, 파일 읽기 및 파일 쓰기의 세 가지 일반적인 작업에 대한 권한 흐름을 보여 줍니다.
권한 테이블: Azure RBAC, ABAC, ACL 결합
다음 표에서는 보안 주체가 작업 열에 나열된 작업을 수행할 수 있도록 Azure 역할, 조건, ACL 항목을 결합하는 방법을 보여 줍니다. 다음 표의 열은 가상 디렉터리 계층 구조의 각 수준을 나타냅니다. 컨테이너(/)의 루트 디렉터리에 대한 열, Oregon이라는 하위 디렉터리, Oregon 디렉터리의 Portland라는 하위 디렉터리, Portland 디렉터리의 Data.txt라는 텍스트 파일이 있습니다. 이러한 열에는 권한 부여에 필요한 ACL 항목의 약식 표현이 표시됩니다. 작업을 수행하는 데 ACL 항목이 필요하지 않은 경우 열에 N/A(해당 사항 없음)이 표시됩니다.
| 연산 | 할당된 Azure 역할(조건 포함 또는 조건 제외) | / | Oregon/ | Portland/ | Data.txt |
|---|---|---|---|---|---|
| Read Data.txt | Storage Blob 데이터 소유자 | 해당 없음 | 해당 없음 | 해당 없음 | 해당 없음 |
| Storage Blob 데이터 Contributor | 해당 없음 | 해당 없음 | 해당 없음 | 해당 없음 | |
| Storage Blob 데이터 읽기 권한자 | 해당 없음 | 해당 없음 | 해당 없음 | 해당 없음 | |
| 없음 | --X |
--X |
--X |
R-- |
|
| Append to Data.txt | Storage Blob 데이터 소유자 | 해당 없음 | 해당 없음 | 해당 없음 | 해당 없음 |
| Storage Blob 데이터 Contributor | 해당 없음 | 해당 없음 | 해당 없음 | 해당 없음 | |
| Storage Blob 데이터 읽기 권한자 | --X |
--X |
--X |
-W- |
|
| 없음 | --X |
--X |
--X |
RW- |
|
| Delete Data.txt | Storage Blob 데이터 소유자 | 해당 없음 | 해당 없음 | 해당 없음 | 해당 없음 |
| Storage Blob 데이터 Contributor | 해당 없음 | 해당 없음 | 해당 없음 | 해당 없음 | |
| Storage Blob 데이터 읽기 권한자 | --X |
--X |
-WX |
해당 없음 | |
| 없음 | --X |
--X |
-WX |
해당 없음 | |
| Create Data.txt | Storage Blob 데이터 소유자 | 해당 없음 | 해당 없음 | 해당 없음 | 해당 없음 |
| Storage Blob 데이터 Contributor | 해당 없음 | 해당 없음 | 해당 없음 | 해당 없음 | |
| Storage Blob 데이터 읽기 권한자 | --X |
--X |
-WX |
해당 없음 | |
| 없음 | --X |
--X |
-WX |
해당 없음 | |
| List / | Storage Blob 데이터 소유자 | 해당 없음 | 해당 없음 | 해당 없음 | 해당 없음 |
| Storage Blob 데이터 Contributor | 해당 없음 | 해당 없음 | 해당 없음 | 해당 없음 | |
| Storage Blob 데이터 읽기 권한자 | 해당 없음 | 해당 없음 | 해당 없음 | 해당 없음 | |
| 없음 | R-X |
해당 없음 | 해당 없음 | 해당 없음 | |
| List /Oregon/ | Storage Blob 데이터 소유자 | 해당 없음 | 해당 없음 | 해당 없음 | 해당 없음 |
| Storage Blob 데이터 Contributor | 해당 없음 | 해당 없음 | 해당 없음 | 해당 없음 | |
| Storage Blob 데이터 읽기 권한자 | 해당 없음 | 해당 없음 | 해당 없음 | 해당 없음 | |
| 없음 | --X |
R-X |
해당 없음 | 해당 없음 | |
| List /Oregon/Portland/ | Storage Blob 데이터 소유자 | 해당 없음 | 해당 없음 | 해당 없음 | 해당 없음 |
| Storage Blob 데이터 Contributor | 해당 없음 | 해당 없음 | 해당 없음 | 해당 없음 | |
| Storage Blob 데이터 읽기 권한자 | 해당 없음 | 해당 없음 | 해당 없음 | 해당 없음 | |
| 없음 | --X |
--X |
R-X |
해당 없음 |
참고 항목
Azure Storage Explorer에서 컨테이너의 콘텐츠를 보려면 보안 주체는 Microsoft Entra ID를 사용하여 Storage Explorer에 로그인하고 최소한 컨테이너의 루트 폴더(\)에 대한 읽기 액세스(R--)가 있어야 합니다. 이 수준의 권한은 루트 폴더의 내용을 나열할 수 있는 기능을 제공합니다. 루트 폴더의 내용을 표시하지 않으려면 해당 폴더에 읽기 권한자 역할을 할당할 수 있습니다. 해당 역할을 통해 계정의 컨테이너는 나열할 수 있지만 컨테이너 콘텐츠는 나열할 수 없습니다. 그런 다음 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 역할 할당 및 ACL 항목에 대한 제한
그룹을 사용하면 구독당 최대 역할 할당 수와 파일 또는 디렉터리당 최대 ACL 항목 수를 초과할 가능성이 줄어듭니다. 다음 표에서는 이러한 제한에 대해 설명합니다.
| 메커니즘 | 범위 | 제한 | 지원되는 권한 수준 |
|---|---|---|---|
| Azure RBAC | 스토리지 계정, 컨테이너. 구독 또는 리소스 그룹 수준에서 리소스 간 Azure 역할 할당. |
구독에서 4,000개의 Azure 역할 할당 | Azure 역할(기본 제공 또는 사용자 지정) |
| ACL | 디렉터리, 파일 | 파일 및 디렉터리당 32개 ACL 항목(효과적으로 28개 ACL 항목). 액세스 및 기본 ACL에는 각각 고유한 32개의 ACL 항목 제한이 있습니다. | ACL 권한 |
공유 키 및 SAS(공유 액세스 서명) 권한 부여
Azure Data Lake Storage Gen2는 인증을 위한 공유 키 및 SAS 방법도 지원합니다. 이러한 권한 부여 방법의 특징은 호출자와 연결된 ID가 없으므로 보안 주체 권한 기반 권한 부여를 수행할 수 없다는 것입니다.
공유 키의 경우 호출자는 데이터, 소유자 설정 및 ACL 변경을 포함한 모든 리소스에 대한 모든 작업에 대한 모든 권한을 의미하는 '슈퍼 사용자' 액세스 권한을 효과적으로 얻습니다.
SAS 토큰에는 토큰의 일부로 허용된 권한이 포함됩니다. SAS 토큰에 포함된 권한은 모든 권한 부여 결정에 효과적으로 적용되지만, 추가적인 ACL 검사는 수행되지 않습니다.
다음 단계
액세스 제어 목록에 대한 자세한 내용은 Azure Data Lake Storage Gen2의 ACL(액세스 제어 목록)을 참조하세요.