Azure에서 클라우드 규모 분석에 대한 권한 부여
권한 부여는 인증된 당사자에게 작업을 수행할 수 있는 권한을 부여하는 행위입니다. 액세스 제어
Microsoft Entra ID를 중앙 집중식 ID 공급자로 사용하는 경우 사용자 또는 애플리케이션별로 데이터 서비스 및 스토리지에 대한 액세스 권한을 부여할 수 있으며 Microsoft Entra ID를 기반으로 합니다.
데이터 서비스 권한 부여
Azure RBAC(Role-Based 액세스 제어) 및 ACL(액세스 제어 목록)은 액세스 관리와 보안 보장에 중요한 역할을 합니다. Azure RBAC 및 ACL은 모두 사용자(또는 애플리케이션)에게 Microsoft Entra ID의 ID가 있어야 합니다. 클라우드 규모 분석에서 RBAC는 데이터베이스 및 Azure Data Lake Storage에 효과적이며, ACL은 주로 Azure Data Lake Storage에서 파일 및 디렉터리 수준에서 세분화된 액세스 제어를 제공하는 데 사용됩니다. ACL은 스토리지 계층 내에서 더 자세한 권한을 제공하여 RBAC를 보완합니다.
Azure RBAC는 "소유자", "기여자" 및 "읽기 권한자"와 같은 기본 제공 역할을 제공하지만 특정 요구 사항에 맞는 사용자 지정 역할을 만들 수도 있습니다. 다음 기본 제공 역할은 Azure 데이터 서비스를 비롯한 모든 Azure 리소스 유형의 기본 역할입니다.
| 역할 | 묘사 |
|---|---|
| 소유자 | 이 역할은 리소스에 대한 모든 권한을 가지며, 리소스에 대한 액세스 권한을 부여하는 권한을 포함하여 리소스에 대한 모든 것을 관리할 수 있습니다. |
| 기여자 | 이 역할은 리소스를 관리할 수 있지만 리소스에 대한 액세스 권한을 부여할 수는 없습니다. |
| 읽기 권한자 | 이 역할은 리소스 및 해당 리소스에 대한 정보(액세스 키 또는 비밀과 같은 중요한 정보 제외)를 볼 수 있지만 리소스를 변경할 수는 없습니다. |
메모
일부 서비스에는 Storage Blob 데이터 기여자 또는 Data Factory 참가자와 같은 특정 RBAC 역할이 있습니다. 즉, 이러한 서비스에 특정 RBAC 역할을 사용해야 합니다. RBAC는 역할 할당을 추가하는 것이 활성 권한인 추가 모델입니다. 또한 RBAC는 역할 할당보다 우선하는 거부 할당을 지원합니다.
팁
액세스 제어 전략을 계획할 때는 사용자에게 작업을 수행하는 데 필요한 액세스 권한의 양만 부여하고 특정 범위에서 특정 작업만 허용하는 것이 좋습니다.
Azure Databases의 액세스 제어
Azure 데이터베이스의 RBAC는 역할, 범위 및 사용 권한을 중심으로 진행됩니다. Azure는 SQL Server 및 데이터베이스를 관리할 수 있는 SQL Server 기여자, 서버 자체가 아닌 SQL 데이터베이스 관리를 허용하는 SQL DB 기여자 등 데이터베이스 관리에 맞게 조정된 몇 가지 기본 제공 역할을 제공합니다. 또한 고유한 요구 사항을 충족하기 위해 특정 권한으로 사용자 지정 역할을 만들 수 있습니다.
역할은 구독 수준을 포함하여 다양한 범위에서 할당할 수 있으며, 여기서 역할은 구독 내의 모든 리소스에 적용됩니다. 지정된 리소스 그룹 내의 모든 리소스에 역할이 적용되는 리소스 그룹 수준입니다. 및 개별 데이터베이스 또는 서버에 직접 역할을 할당하여 정확한 제어를 제공하는 리소스 수준입니다. 권한은 읽기, 쓰기, 삭제 또는 보안 설정 관리와 같이 역할이 수행할 수 있는 작업을 정의하며, 이러한 권한은 관리를 간소화하기 위해 역할로 그룹화됩니다.
Azure SQL Database
Azure Cosmos DB
Azure Database for MySQL, PostgreSQL 및 MariaDB에서 , 데이터베이스 서버와 개별 데이터베이스를 관리하기 위한 역할을 할당할 수 있습니다. "기여자" 및 "읽기 권한자"와 같은 역할을 사용하여 액세스를 제어할 수 있습니다.
자세한 내용은 데이터베이스대한 Azure 기본 제공 역할
Azure Data Lake Storage의 액세스 제어
Azure RBAC를 사용하면 스토리지 계정의 모든 데이터에 대해 읽기 또는 쓰기와 같이 "대략적인" 액세스 권한을 부여할 수 있습니다. ACL을 사용하면 특정 디렉터리 또는 파일에 대한 쓰기 액세스와 같은 "세분화된" 액세스 권한을 부여할 수 있습니다.
많은 시나리오에서 RBAC 및 ACL은 ADLS에서 포괄적인 액세스 제어를 제공하기 위해 함께 사용됩니다. RBAC를 사용하여 데이터에 대한 높은 수준의 액세스를 관리하여 권한 있는 사용자만 서비스 자체에 액세스할 수 있도록 할 수 있습니다. 그런 다음 스토리지 계정 내에서 ACL을 적용하여 특정 파일 및 디렉터리에 대한 액세스를 제어하여 추가 보안 계층을 제공할 수 있습니다.
ABAC(Azure 특성 기반 액세스 제어)는 특정 작업의 컨텍스트에서 특성에 따라 역할 할당 조건을 추가하여 Azure RBAC를 기반으로 합니다. 기본적으로 조건을 추가하여 RBAC 역할 할당을 구체화할 수 있습니다. 예를 들어 특정 태그가 있는 스토리지 계정의 모든 데이터 개체에 읽기 또는 쓰기 권한을 부여할 수 있습니다.
다음 역할은 보안 주체가 스토리지 계정의 데이터에 액세스할 수 있도록 허용합니다.
| 역할 | 묘사 |
|---|---|
| 스토리지 Blob 데이터 소유자 | Blob Storage 컨테이너 및 데이터에 대한 모든 권한. 이 액세스를 통해 보안 주체는 항목의 소유자를 설정하고 모든 항목의 ACL을 수정할 수 있습니다. |
| Storage Blob 데이터 기여자 | Blob Storage 컨테이너 및 Blob에 대한 액세스를 읽고 쓰고 삭제합니다. 이 액세스는 보안 주체가 항목의 소유권을 설정하는 것을 허용하지 않지만 보안 주체가 소유한 항목의 ACL을 수정할 수 있습니다. |
| 스토리지 Blob 데이터 판독기 | Blob 저장소 컨테이너와 Blob을 읽고 나열합니다. |
소유자, 기여자, 읽기 권한자 및 스토리지 계정 기여자와 같은 역할은 보안 주체가 스토리지 계정을 관리할 수 있도록 허용하지만 해당 계정 내의 데이터에 대한 액세스는 제공하지 않습니다. 그러나 이러한 역할(읽기 권한자 제외)은 다양한 클라이언트 도구에서 데이터에 액세스하는 데 사용할 수 있는 스토리지 키에 대한 액세스를 얻을 수 있습니다. 자세한 내용은 Azure Data Lake Storage
Azure Databricks의 액세스 제어
Azure Databricks는 보안 개체 및 데이터 거버넌스에 중점을 두고 Databricks 환경 내에서 액세스를 관리하도록 설계된 액세스 제어 시스템을 제공합니다. Azure Databricks 내의 세 가지 주요 액세스 제어 시스템은 다음과 같습니다.
- Access 제어 목록: 노트북과 같은 워크스페이스 객체에 액세스할 수 있는 권한을 구성하는 데 사용됩니다. 자세한 내용은 엑세스 제어 목록을 참고하십시오.
- 계정 역할 기반 액세스 제어: 서비스 주체 및 그룹과 같은 계정 수준 개체를 사용하도록 권한을 구성하는 데 사용됩니다.
- Unity 카탈로그: 데이터 개체를 보호하고 관리하는 데 사용됩니다.
개체에 대한 액세스 제어 외에도 Azure Databricks 플랫폼에는 내장 역할이 있습니다. 사용자, 서비스 주체 및 그룹에 역할을 할당할 수 있습니다. 자세한 내용은 Databricks 관리자 역할참조하세요.
클라우드 규모 분석의 권한 부여 모범 사례
이 가이드에서는 클라우드 규모 분석 환경에서 RBAC(역할 기반 액세스 제어)를 구현하기 위한 모범 사례를 제공합니다. 리소스의 안전하고 효율적인 관리를 보장하기 위해 일반적인 RBAC 원칙, 데이터베이스 액세스 제어 및 데이터 레이크 액세스 제어 모범 사례를 다룹니다.
클라우드 규모 분석에 대한 일반 RBAC 모범 사례
다음 모범 사례는 RBAC를 시작하는 데 도움이 될 수 있습니다.
서비스 관리 및 작업에 RBAC 역할을 사용하고, 데이터 액세스 및 워크로드 관련 작업에 서비스별 역할을 사용하는: 리소스 관리 및 작업 작업을 수행해야 하는 보안 주체에 권한을 부여하기 위해 Azure 리소스에서 RBAC 역할을 사용합니다. 스토리지 내에서 데이터에 액세스해야 하는 보안 주체는 리소스를 관리할 필요가 없으므로 리소스에 대한 RBAC 역할이 필요하지 않습니다. 대신 데이터 개체에 직접 권한을 부여합니다. 예를 들어, Azure Data Lake Storage Gen2의 폴더에 대한 읽기 권한을 부여하거나 Azure SQL Database의 데이터베이스에서 포함된 데이터베이스 사용자에게 테이블 권한을 부여합니다.
기본 제공 RBAC 역할사용: 먼저 기본 제공 RBAC Azure 리소스 역할을 사용하여 서비스를 관리하고 작업 역할을 할당하여 액세스를 제어합니다. 기본 제공 역할이 특정 요구 사항을 충족하지 않는 경우에만 Azure 리소스에 대한 사용자 지정 역할을 만들고 사용합니다.
그룹을 사용하여 액세스관리: Microsoft Entra 그룹에 대한 액세스 권한을 할당하고 지속적인 액세스 관리를 위한 그룹 멤버 자격을 관리합니다.
구독 및 리소스 그룹 범위: 비프로덕션 환경에서는 개별 리소스에 대한 액세스 권한을 부여하는 것과 서비스 관리 및 작업 액세스 요구 사항을 구분하기 위해 리소스 그룹 범위에서 액세스 권한을 부여하는 것이 좋습니다. 그 이유는 비프로덕션 환경에서 개발자 및 테스터가 Azure Data Factory 수집 파이프라인을 만들거나 Data Lake Storage Gen2에서 컨테이너를 만드는 것과 같은 리소스를 관리해야 하기 때문입니다. 그러나 프로덕션 환경에서는 데이터 레이크 파일 시스템 지원 및 작업과 같은 워크로드별 작업에 대한 개별 리소스에 대한 액세스 권한을 부여할 수 있습니다. 그 이유는 프로덕션 환경에서는 사용자가 예약된 Data Factory 수집 파이프라인의 상태를 보거나 Data Lake Storage Gen2에서 데이터 파일을 읽는 것과 같은 리소스만 사용해야 하기 때문입니다.
구독 범위불필요한 액세스 권한을 부여하지 마세요. 구독 범위는 구독 내의 모든 리소스를 포함합니다.
최소 권한 액세스선택: 작업에 적합한 역할만 선택합니다.
데이터베이스 액세스 제어 모범 사례
효과적인 RBAC(역할 기반 액세스 제어)를 구현하는 것은 분석 환경에서 보안 및 관리 효율성을 유지하는 데 매우 중요합니다. 이 섹션에서는 간소화되고 안전한 액세스 관리 프로세스를 보장하기 위해 Microsoft Entra 그룹, 기본 제공 역할을 사용하고 직접 사용자 권한을 방지하는 모범 사례를 제공합니다.
클라우드 규모 분석에는 다중 언어 스토리지가 포함될 수 있습니다. 예를 들어 PostgreSQL, MySQL, Azure SQL Database, SQL Managed Instance 및 Azure Synapse Analytics가 있습니다.
- 개별 사용자 계정대신 Microsoft Entra 그룹을 사용합니다. Microsoft Entra 그룹을 사용하여 개별 Microsoft Entra 사용자 계정 대신 데이터베이스 개체를 보호하는 것이 좋습니다. 이러한 Microsoft Entra 그룹을 사용하여 사용자를 인증하고 데이터베이스 개체를 보호합니다. 데이터 레이크 패턴과 마찬가지로 데이터 애플리케이션 온보딩을 사용하여 이러한 그룹을 만들 수 있습니다.
- 기본 제공 역할을 사용하여 액세스관리: 필요한 경우 또는 기본 제공 역할이 너무 많은 권한을 부여하는 경우에만 사용자 지정 역할을 만듭니다.
- 개별 사용자에게 권한을 할당하지 않도록: 역할(데이터베이스 또는 서버 역할)을 일관되게 사용합니다. 역할은 권한 보고 및 문제 해결에 큰 도움이 됩니다. (Azure RBAC는 역할을 통한 권한 할당만 지원합니다.)
메모
데이터 애플리케이션은 중요한 데이터 제품을 Azure SQL Database, SQL Managed Instance 또는 Azure Synapse Analytics 풀에 저장할 수 있습니다. 자세한 내용은 민감한 데이터을 참조하세요.
Data Lake 액세스 제어 모범 사례
최신 데이터 환경에서는 안전하고 효율적인 액세스 제어를 보장하는 것이 가장 중요합니다. ADLS(Azure Data Lake Storage) Gen2는 ACL(액세스 제어 목록)을 통해 액세스를 관리하는 강력한 메커니즘을 제공합니다. 이 섹션에서는 ADLS Gen2에서 역할 기반 액세스 제어를 구현하고, ACL, Microsoft Entra 보안 그룹을 적용하고, 안전하고 관리하기 쉬운 데이터 레이크 환경을 유지하기 위한 최소 권한 원칙을 구현하기 위한 모범 사례를 간략하게 설명합니다. 또한 ACL을 데이터 분할 체계와 정렬하고 Azure Databricks 사용자용 Unity 카탈로그를 사용하여 포괄적인 보안 및 거버넌스를 보장하는 것의 중요성을 강조합니다.
- 세분화된 액세스 제어ACL(액세스 제어 목록)을 사용합니다. ACL은 세분화된 수준에서 액세스를 정의하는 데 중요한 역할을 합니다. ADLS(Azure Data Lake Storage) Gen2에서 ACL은 보안 주체와 협력하여 파일 및 디렉터리에 대한 세분화된 액세스를 관리합니다.
- 파일 및 폴더 수준ACL 적용: 데이터 레이크의 데이터에 대한 액세스를 제어하려면 파일 및 폴더 수준에서 ACL(액세스 제어 목록)을 사용하는 것이 좋습니다. 또한 Azure Data Lake는 POSIX와 유사한 액세스 제어 목록 모델을 채택합니다. POSIX(이식 가능한 운영 체제 인터페이스)는 운영 체제에 대한 표준 제품군입니다. 하나의 표준은 파일 및 폴더에 액세스하기 위한 간단하지만 강력한 권한 구조를 정의합니다. POSIX는 네트워크 파일 공유 및 Unix 컴퓨터에 널리 채택됩니다.
- Microsoft Entra 보안 그룹을 ACL 항목에서 할당된 주체로 사용합니다. 개별 사용자 또는 서비스 주체를 직접 할당하는 것을 피하도록 합니다. 이 구조를 사용하면 전체 디렉터리 구조에 ACL을 다시 적용할 필요 없이 사용자 또는 서비스 주체를 추가하고 제거할 수 있습니다. 대신 적절한 Microsoft Entra 보안 그룹에서 사용자 및 서비스 주체를 추가하거나 제거할 수 있습니다.
- Microsoft Entra 그룹에 액세스 할당하고 지속적인 액세스 관리를 위해 그룹의 멤버 자격을 관리합니다. Azure Data Lake Storage에서 액세스 제어 및 데이터 레이크 구성을 참조하세요.
ACL 최소 권한 원칙 적용: 대부분의 경우 사용자는 데이터 레이크에 필요한 파일 및 폴더에 대한 읽기 권한만있어야 합니다. 데이터 사용자는 스토리지 계정 컨테이너에 액세스할 수 없어야 합니다. - ACL을데이터 분할 체계에 맞춥니다. ACL 및 데이터 파티션 디자인은 효과적인 데이터 액세스 제어를 위해 정렬되어야 합니다. 자세한 내용은 데이터 레이크 분할을 참조하세요.
- Azure Databricks 사용자의 경우 Unity 카탈로그를 사용하여 데이터 개체에 대한 액세스를 독점적으로 제어합니다. Azure Data Lake Storage Gen2의 외부 위치 스토리지에 직접 스토리지 수준의 액세스를 허용해도 Unity 카탈로그에서 부여한 권한이나 유지하는 감사를 따르지 않습니다. 직접 액세스는 액세스 제어 및 권한을 포함하여 Unity 카탈로그의 감사, 계보 및 기타 보안 및 모니터링 기능을 무시합니다. 따라서 Azure Databricks 최종 사용자에게 Unity 카탈로그 관리 테이블 및 볼륨에 대한 직접 스토리지 수준 액세스 권한을 부여해서는 안 됩니다.