mirror of
https://github.com/HackTricks-wiki/hacktricks-cloud.git
synced 2026-07-29 07:00:29 -07:00
Translated ['src/pentesting-cloud/azure-security/az-basic-information/RE
This commit is contained in:
@@ -9,11 +9,11 @@
|
||||
### 관리 그룹
|
||||
|
||||
- **다른 관리 그룹 또는 구독**을 포함할 수 있습니다.
|
||||
- 이를 통해 관리 그룹 수준에서 RBAC 및 Azure Policy와 같은 **거버넌스 제어를 적용**하고 그룹 내 모든 구독에서 **상속**받을 수 있습니다.
|
||||
- 이를 통해 **RBAC 및 Azure 정책**과 같은 거버넌스 제어를 관리 그룹 수준에서 한 번 적용하고 그룹 내 모든 구독이 이를 **상속**받을 수 있습니다.
|
||||
- **10,000개의 관리** 그룹을 단일 디렉터리에서 지원할 수 있습니다.
|
||||
- 관리 그룹 트리는 **최대 6단계 깊이**를 지원할 수 있습니다. 이 제한은 루트 수준이나 구독 수준을 포함하지 않습니다.
|
||||
- 각 관리 그룹 및 구독은 **단 하나의 부모**만 지원할 수 있습니다.
|
||||
- 여러 관리 그룹을 생성할 수 있지만 **루트 관리 그룹은 단 하나**만 존재합니다.
|
||||
- 각 관리 그룹 및 구독은 **하나의 부모**만 지원할 수 있습니다.
|
||||
- 여러 관리 그룹을 생성할 수 있지만 **루트 관리 그룹은 하나만 존재**합니다.
|
||||
- 루트 관리 그룹은 **모든 다른 관리 그룹 및 구독을 포함**하며 **이동하거나 삭제할 수 없습니다**.
|
||||
- 단일 관리 그룹 내의 모든 구독은 **동일한 Entra ID 테넌트**를 신뢰해야 합니다.
|
||||
|
||||
@@ -21,18 +21,18 @@
|
||||
|
||||
### Azure 구독
|
||||
|
||||
- 리소스(VMs, DBs…)를 실행하고 청구되는 또 다른 **논리적 컨테이너**입니다.
|
||||
- 리소스(가상 머신, 데이터베이스 등)를 실행하고 청구되는 또 다른 **논리적 컨테이너**입니다.
|
||||
- 그 **부모**는 항상 **관리 그룹**이며(루트 관리 그룹일 수 있음) 구독은 다른 구독을 포함할 수 없습니다.
|
||||
- **하나의 Entra ID** 디렉터리만 신뢰합니다.
|
||||
- 구독 수준(또는 그 부모의 수준)에서 적용된 **권한**은 구독 내 모든 리소스에 **상속**됩니다.
|
||||
|
||||
### 리소스 그룹
|
||||
|
||||
[문서에서:] (https://learn.microsoft.com/en-us/azure/azure-resource-manager/management/manage-resource-groups-python?tabs=macos#what-is-a-resource-group) 리소스 그룹은 Azure 솔루션을 위한 **관련 리소스**를 보유하는 **컨테이너**입니다. 리소스 그룹은 솔루션을 위한 모든 리소스를 포함하거나 **그룹으로 관리하고자 하는 리소스만 포함**할 수 있습니다. 일반적으로 **같은 생애 주기**를 공유하는 **리소스**를 동일한 리소스 그룹에 추가하여 그룹으로 쉽게 배포, 업데이트 및 삭제할 수 있습니다.
|
||||
[문서에서:](https://learn.microsoft.com/en-us/azure/azure-resource-manager/management/manage-resource-groups-python?tabs=macos#what-is-a-resource-group) 리소스 그룹은 Azure 솔루션을 위한 **관련 리소스**를 보유하는 **컨테이너**입니다. 리소스 그룹은 솔루션에 대한 모든 리소스를 포함하거나 **그룹으로 관리하고자 하는 리소스만 포함**할 수 있습니다. 일반적으로 **같은 생애 주기**를 공유하는 **리소스**를 동일한 리소스 그룹에 추가하여 그룹으로 쉽게 배포, 업데이트 및 삭제할 수 있습니다.
|
||||
|
||||
모든 **리소스**는 **리소스 그룹 내에 있어야** 하며, 오직 하나의 그룹에만 속할 수 있으며, 리소스 그룹이 삭제되면 그 안의 모든 리소스도 삭제됩니다.
|
||||
모든 **리소스**는 **리소스 그룹 내에 있어야** 하며, 그룹에만 속할 수 있으며, 리소스 그룹이 삭제되면 그 안의 모든 리소스도 삭제됩니다.
|
||||
|
||||
<figure><img src="https://lh7-rt.googleusercontent.com/slidesz/AGV_vUfe8U30iP_vdZCvxX4g8nEPRLoo7v0kmCGkDn1frBPn3_GIoZ7VT2LkdsVQWCnrG_HSYNRRPM-1pSECUkbDAB-9YbUYLzpvKVLDETZS81CHWKYM4fDl3oMo5-yvTMnjdLTS2pz8U67xUTIzBhZ25MFMRkq5koKY=s2048?key=gSyKQr3HTyhvHa28Rf7LVA" alt=""><figcaption><p><a href="https://i0.wp.com/azuredays.com/wp-content/uploads/2020/05/org.png?resize=748%2C601&ssl=1">https://i0.wp.com/azuredays.com/wp-content/uploads/2020/05/org.png?resize=748%2C601&ssl=1</a></p></figcaption></figure>
|
||||
<figure><img src="https://i0.wp.com/azuredays.com/wp-content/uploads/2020/05/org.png?resize=748%2C601&ssl=1" alt=""><figcaption><p><a href="https://i0.wp.com/azuredays.com/wp-content/uploads/2020/05/org.png?resize=748%2C601&ssl=1">https://i0.wp.com/azuredays.com/wp-content/uploads/2020/05/org.png?resize=748%2C601&ssl=1</a></p></figcaption></figure>
|
||||
|
||||
### Azure 리소스 ID
|
||||
|
||||
@@ -50,15 +50,15 @@ Azure 리소스 ID의 형식은 다음과 같습니다:
|
||||
|
||||
### Azure
|
||||
|
||||
Azure는 Microsoft의 포괄적인 **클라우드 컴퓨팅 플랫폼으로, 다양한 서비스**를 제공합니다. 여기에는 가상 머신, 데이터베이스, 인공지능 및 스토리지가 포함됩니다. Azure는 애플리케이션을 호스팅하고 관리하며, 확장 가능한 인프라를 구축하고, 클라우드에서 현대적인 작업 부하를 실행하는 기반 역할을 합니다. Azure는 개발자와 IT 전문가가 다양한 요구를 충족할 수 있도록 애플리케이션과 서비스를 원활하게 생성, 배포 및 관리할 수 있는 도구를 제공합니다.
|
||||
Azure는 Microsoft의 포괄적인 **클라우드 컴퓨팅 플랫폼으로, 다양한 서비스**를 제공합니다. 여기에는 가상 머신, 데이터베이스, 인공지능 및 스토리지가 포함됩니다. Azure는 애플리케이션을 호스팅하고 관리하며, 확장 가능한 인프라를 구축하고, 클라우드에서 현대적인 작업 부하를 실행하는 기반 역할을 합니다. Azure는 개발자와 IT 전문가가 애플리케이션과 서비스를 원활하게 생성, 배포 및 관리할 수 있는 도구를 제공하여 스타트업부터 대기업까지 다양한 요구를 충족합니다.
|
||||
|
||||
### Entra ID (구 Azure Active Directory)
|
||||
### Entra ID (이전 Azure Active Directory)
|
||||
|
||||
Entra ID는 인증, 권한 부여 및 사용자 액세스 제어를 처리하도록 설계된 클라우드 기반 **아이덴티티 및 액세스 관리 서비스**입니다. 이는 Office 365, Azure 및 많은 타사 SaaS 애플리케이션에 대한 안전한 액세스를 제공합니다. SSO(단일 로그인), MFA(다단계 인증), 조건부 액세스 정책 등의 기능을 제공합니다.
|
||||
Entra ID는 인증, 권한 부여 및 사용자 액세스 제어를 처리하도록 설계된 클라우드 기반 **아이덴티티 및 액세스 관리 서비스**입니다. 이는 Office 365, Azure 및 많은 타사 SaaS 애플리케이션과 같은 Microsoft 서비스에 대한 안전한 액세스를 제공합니다. SSO(단일 로그인), MFA(다단계 인증), 조건부 액세스 정책 등의 기능을 제공합니다.
|
||||
|
||||
### Entra 도메인 서비스 (구 Azure AD DS)
|
||||
### Entra 도메인 서비스 (이전 Azure AD DS)
|
||||
|
||||
Entra 도메인 서비스는 **전통적인 Windows Active Directory 환경과 호환되는 관리형 도메인 서비스를 제공하여 Entra ID의 기능을 확장합니다**. LDAP, Kerberos 및 NTLM과 같은 레거시 프로토콜을 지원하여 조직이 온프레미스 도메인 컨트롤러를 배포하지 않고도 클라우드에서 이전 애플리케이션을 마이그레이션하거나 실행할 수 있도록 합니다. 이 서비스는 중앙 집중식 관리를 위한 그룹 정책도 지원하여 레거시 또는 AD 기반 작업 부하가 현대 클라우드 환경과 공존해야 하는 시나리오에 적합합니다.
|
||||
Entra 도메인 서비스는 **전통적인 Windows Active Directory 환경과 호환되는 관리형 도메인 서비스를 제공하여 Entra ID의 기능을 확장**합니다. LDAP, Kerberos 및 NTLM과 같은 레거시 프로토콜을 지원하여 조직이 온프레미스 도메인 컨트롤러를 배포하지 않고도 클라우드에서 이전 애플리케이션을 마이그레이션하거나 실행할 수 있도록 합니다. 이 서비스는 중앙 집중식 관리를 위한 그룹 정책도 지원하여 레거시 또는 AD 기반 작업 부하가 현대 클라우드 환경과 공존해야 하는 시나리오에 적합합니다.
|
||||
|
||||
## Entra ID 주체
|
||||
|
||||
@@ -68,7 +68,7 @@ Entra 도메인 서비스는 **전통적인 Windows Active Directory 환경과
|
||||
- 선택한 테넌트의 이메일 이름 및 도메인 표시
|
||||
- 표시 이름 지정
|
||||
- 비밀번호 지정
|
||||
- 속성 지정(이름, 직책, 연락처 정보 등…)
|
||||
- 속성 지정(이름, 직책, 연락처 정보 등)
|
||||
- 기본 사용자 유형은 "**회원**"입니다.
|
||||
- **외부 사용자**
|
||||
- 초대할 이메일 및 표시 이름 지정(비 Microsoft 이메일 가능)
|
||||
@@ -82,7 +82,7 @@ Entra 도메인 서비스는 **전통적인 Windows Active Directory 환경과
|
||||
- 모든 사용자, 그룹, 애플리케이션, 장치, 역할, 구독 및 그들의 공개 속성 읽기
|
||||
- 게스트 초대(_비활성화 가능_)
|
||||
- 보안 그룹 생성
|
||||
- 숨겨지지 않은 그룹 구성원 읽기
|
||||
- 숨겨지지 않은 그룹 멤버십 읽기
|
||||
- 소유한 그룹에 게스트 추가
|
||||
- 새 애플리케이션 생성(_비활성화 가능_)
|
||||
- Azure에 최대 50개의 장치 추가(_비활성화 가능_)
|
||||
@@ -101,44 +101,44 @@ Entra 도메인 서비스는 **전통적인 Windows Active Directory 환경과
|
||||
- 사용자가 LinkedIn과 작업 또는 학교 계정을 연결할 수 있도록 허용: 기본 **예**
|
||||
- 사용자가 로그인 상태를 유지하도록 표시: 기본 **예**
|
||||
- 사용자가 소유한 장치에 대한 BitLocker 키를 복구하지 못하도록 제한: 기본 아니오(장치 설정에서 확인)
|
||||
- 다른 사용자 읽기: 기본 **예** (Microsoft Graph를 통해)
|
||||
- 다른 사용자 읽기: 기본 **예**(Microsoft Graph를 통해)
|
||||
- **게스트**
|
||||
- **게스트 사용자 액세스 제한**
|
||||
- **게스트 사용자는 기본적으로 모든 구성원 사용자 권한을 부여받습니다.**
|
||||
- **게스트 사용자는 기본적으로 자신의 사용자 프로필에만 액세스할 수 있습니다.** 다른 사용자 및 그룹 정보에 대한 액세스는 더 이상 허용되지 않습니다.
|
||||
- **게스트 사용자 액세스는 자신의 디렉터리 객체의 속성과 구성원으로 제한됩니다.** 가장 제한적입니다.
|
||||
- **게스트 초대 가능**
|
||||
- **조직 내 누구나 게스트 사용자 초대 가능(가장 포괄적) - 기본**
|
||||
- **구성원 사용자 및 특정 관리 역할에 할당된 사용자는 구성원 권한이 있는 게스트를 포함하여 게스트 사용자 초대 가능**
|
||||
- **게스트 사용자 액세스 제한** 옵션:
|
||||
- **게스트 사용자는 구성원과 동일한 액세스를 가집니다**.
|
||||
- **게스트 사용자는 디렉터리 객체의 속성과 멤버십에 대한 제한된 액세스를 가집니다(기본)**. 이는 기본적으로 게스트가 자신의 사용자 프로필에만 액세스할 수 있도록 제한합니다. 다른 사용자 및 그룹 정보에 대한 액세스는 더 이상 허용되지 않습니다.
|
||||
- **게스트 사용자 액세스는 자신의 디렉터리 객체의 속성과 멤버십으로 제한됩니다**는 가장 제한적인 옵션입니다.
|
||||
- **게스트 초대 가능** 옵션:
|
||||
- **조직의 누구나 게스트 사용자 초대 가능(가장 포괄적) - 기본**
|
||||
- **구성원 사용자 및 특정 관리 역할에 할당된 사용자는 게스트 사용자 초대 가능**
|
||||
- **특정 관리 역할에 할당된 사용자만 게스트 사용자 초대 가능**
|
||||
- **조직 내 누구도 게스트 사용자 초대 불가(가장 제한적)**
|
||||
- **외부 사용자 퇴사**: 기본 **참**
|
||||
- **조직의 누구도 게스트 사용자 초대 불가(가장 제한적)**
|
||||
- **외부 사용자 퇴장**: 기본 **참**
|
||||
- 외부 사용자가 조직을 떠날 수 있도록 허용
|
||||
|
||||
> [!TIP]
|
||||
> 기본적으로 제한되더라도, 권한이 부여된 사용자(구성원 및 게스트)는 이전 작업을 수행할 수 있습니다.
|
||||
> 기본적으로 제한되더라도 권한이 부여된 사용자(구성원 및 게스트)는 이전 작업을 수행할 수 있습니다.
|
||||
|
||||
### **그룹**
|
||||
|
||||
**2가지 유형의 그룹**이 있습니다:
|
||||
|
||||
- **보안**: 이 유형의 그룹은 구성원에게 애플리케이션, 리소스에 대한 액세스를 부여하고 라이센스를 할당하는 데 사용됩니다. 사용자, 장치, 서비스 주체 및 다른 그룹이 구성원이 될 수 있습니다.
|
||||
- **Microsoft 365**: 이 유형의 그룹은 협업을 위해 사용되며, 구성원에게 공유 메일박스, 일정, 파일, SharePoint 사이트 등에 대한 액세스를 제공합니다. 그룹 구성원은 사용자만 가능합니다.
|
||||
- **Microsoft 365**: 이 유형의 그룹은 협업을 위해 사용되며, 구성원에게 공유 사서함, 일정, 파일, SharePoint 사이트 등에 대한 액세스를 제공합니다. 그룹 구성원은 사용자만 될 수 있습니다.
|
||||
- 이는 EntraID 테넌트의 도메인을 가진 **이메일 주소**를 가집니다.
|
||||
|
||||
**2가지 유형의 구성원 자격**이 있습니다:
|
||||
**2가지 유형의 멤버십**이 있습니다:
|
||||
|
||||
- **지정된**: 특정 구성원을 수동으로 그룹에 추가할 수 있습니다.
|
||||
- **동적 구성원 자격**: 규칙을 사용하여 구성원을 자동으로 관리하며, 구성원 속성이 변경될 때 그룹 포함을 업데이트합니다.
|
||||
- **할당됨**: 특정 구성원을 그룹에 수동으로 추가할 수 있습니다.
|
||||
- **동적 멤버십**: 규칙을 사용하여 멤버십을 자동으로 관리하며, 구성원 속성이 변경될 때 그룹 포함을 업데이트합니다.
|
||||
|
||||
### **서비스 주체**
|
||||
|
||||
**서비스 주체**는 **애플리케이션**, 호스팅 서비스 및 자동화 도구가 Azure 리소스에 액세스하는 데 사용하기 위해 생성된 **아이덴티티**입니다. 이 액세스는 서비스 주체에 할당된 역할에 의해 **제한되며**, 어떤 리소스에 액세스할 수 있는지 및 어떤 수준에서 액세스할 수 있는지를 제어합니다. 보안상의 이유로, **사용자 아이덴티티로 로그인하는 것보다 자동화 도구와 함께 서비스 주체를 사용하는 것이 항상 권장됩니다.**
|
||||
**서비스 주체**는 **애플리케이션**, 호스팅 서비스 및 자동화 도구가 Azure 리소스에 액세스하는 데 사용하기 위해 생성된 **아이덴티티**입니다. 이 액세스는 서비스 주체에 할당된 역할에 의해 **제한되며**, 어떤 리소스에 액세스할 수 있는지 및 어떤 수준에서 액세스할 수 있는지를 제어합니다. 보안상의 이유로, **사용자 아이덴티티로 로그인하는 것보다 자동화 도구와 함께 서비스 주체를 사용하는 것이 항상 권장됩니다**.
|
||||
|
||||
**비밀번호**(기본값), **인증서**를 생성하거나 제3자 플랫폼(예: Github Actions)에 대한 **연합 액세스**를 부여하여 **서비스 주체로 직접 로그인**할 수 있습니다.
|
||||
|
||||
- **비밀번호** 인증을 선택하는 경우(기본값), **생성된 비밀번호를 저장**해야 다시 액세스할 수 없습니다.
|
||||
- 인증서 인증을 선택하는 경우, **애플리케이션이 개인 키에 대한 액세스를 가질 수 있도록 해야 합니다.**
|
||||
- 인증서 인증을 선택하는 경우, **애플리케이션이 개인 키에 대한 액세스를 가질 수 있도록 해야 합니다**.
|
||||
|
||||
### 애플리케이션 등록
|
||||
|
||||
@@ -148,12 +148,11 @@ Entra 도메인 서비스는 **전통적인 Windows Active Directory 환경과
|
||||
|
||||
1. **애플리케이션 ID (클라이언트 ID):** Azure AD에서 앱의 고유 식별자입니다.
|
||||
2. **리디렉션 URI:** Azure AD가 인증 응답을 보내는 URL입니다.
|
||||
3. **인증서, 비밀번호 및 연합 자격 증명:** 서비스 주체로 로그인하기 위해 비밀번호 또는 인증서를 생성하거나 연합 액세스를 부여할 수 있습니다(예: Github Actions). 
|
||||
1. **인증서** 또는 **비밀번호**가 생성되면, **애플리케이션 ID**, **비밀번호** 또는 **인증서** 및 **테넌트**(도메인 또는 ID)를 알고 있는 사람이 **서비스 주체로 로그인**할 수 있습니다.
|
||||
3. **인증서, 비밀번호 및 연합 자격 증명:** 서비스 주체로 로그인하기 위해 비밀번호 또는 인증서를 생성하거나 연합 액세스를 부여할 수 있습니다(예: Github Actions).
|
||||
4. **API 권한:** 앱이 액세스할 수 있는 리소스 또는 API를 지정합니다.
|
||||
5. **인증 설정:** 앱이 지원하는 인증 흐름을 정의합니다(예: OAuth2, OpenID Connect).
|
||||
6. **서비스 주체**: 앱이 생성될 때 서비스 주체가 생성됩니다(웹 콘솔에서 생성된 경우) 또는 새 테넌트에 설치될 때 생성됩니다.
|
||||
1. **서비스 주체**는 요청된 모든 권한을 받게 됩니다.
|
||||
7. **서비스 주체**는 요청된 모든 권한을 받게 됩니다.
|
||||
|
||||
### 기본 동의 권한
|
||||
|
||||
@@ -165,7 +164,7 @@ Entra 도메인 서비스는 **전통적인 Windows Active Directory 환경과
|
||||
- 모든 사용자는 "낮은 영향"으로 분류된 권한에 대해 동의할 수 있으며, 검증된 게시자의 앱 또는 이 조직에 등록된 앱에 대해 동의할 수 있습니다.
|
||||
- **기본** 낮은 영향 권한(낮은 영향으로 추가하려면 수락해야 함):
|
||||
- User.Read - 로그인 및 사용자 프로필 읽기
|
||||
- offline_access - 사용자가 액세스할 수 있도록 허용한 데이터에 대한 액세스 유지
|
||||
- offline_access - 사용자가 액세스를 허용한 데이터에 대한 액세스 유지
|
||||
- openid - 사용자를 로그인
|
||||
- profile - 사용자의 기본 프로필 보기
|
||||
- email - 사용자의 이메일 주소 보기
|
||||
@@ -176,28 +175,28 @@ Entra 도메인 서비스는 **전통적인 Windows Active Directory 환경과
|
||||
|
||||
- 사용자는 동의할 수 없는 앱에 대해 관리자 동의를 요청할 수 있습니다.
|
||||
- **예**인 경우: 동의 요청을 할 수 있는 사용자, 그룹 및 역할을 지정할 수 있습니다.
|
||||
- 사용자가 이메일 알림 및 만료 알림을 받을 수 있는지 구성합니다. 
|
||||
- 사용자가 이메일 알림 및 만료 알림을 받을지 여부도 구성합니다.
|
||||
|
||||
### **관리형 아이덴티티 (메타데이터)**
|
||||
|
||||
Azure Active Directory의 관리형 아이덴티티는 **애플리케이션의 아이덴티티를 자동으로 관리하는 솔루션**을 제공합니다. 이러한 아이덴티티는 Azure Active Directory(**Azure AD**) 인증과 호환되는 **리소스**에 연결하기 위해 애플리케이션에서 사용됩니다. 이를 통해 애플리케이션이 **메타데이터** 서비스에 연락하여 Azure에서 지정된 관리형 아이덴티티로 **작업을 수행할 수 있는 유효한 토큰을 얻는** 하드코딩된 클라우드 자격 증명의 필요성을 **제거**할 수 있습니다.
|
||||
Azure Active Directory의 관리형 아이덴티티는 **애플리케이션의 아이덴티티를 자동으로 관리하는 솔루션**을 제공합니다. 이러한 아이덴티티는 Azure Active Directory(**Azure AD**) 인증과 호환되는 **리소스**에 연결하기 위해 애플리케이션에서 사용됩니다. 이를 통해 애플리케이션이 **메타데이터** 서비스에 연락하여 Azure에서 지정된 관리형 아이덴티티로 **작업을 수행**하기 위한 유효한 토큰을 얻을 수 있으므로 클라우드 자격 증명을 코드에 하드코딩할 필요가 없습니다.
|
||||
|
||||
관리형 아이덴티티에는 두 가지 유형이 있습니다:
|
||||
|
||||
- **시스템 할당**. 일부 Azure 서비스는 **서비스 인스턴스에서 직접 관리형 아이덴티티를 활성화**할 수 있습니다. 시스템 할당 관리형 아이덴티티를 활성화하면, **서비스 주체**가 리소스가 위치한 구독에서 신뢰하는 Entra ID 테넌트에 생성됩니다. **리소스**가 **삭제되면**, Azure는 자동으로 **아이덴티티**를 **삭제**합니다.
|
||||
- **시스템 할당**. 일부 Azure 서비스는 **서비스 인스턴스에서 직접 관리형 아이덴티티를 활성화**할 수 있습니다. 시스템 할당 관리형 아이덴티티를 활성화하면 **서비스 주체**가 리소스가 위치한 구독에서 신뢰하는 Entra ID 테넌트에 생성됩니다. **리소스**가 **삭제되면**, Azure는 자동으로 **아이덴티티**를 삭제합니다.
|
||||
- **사용자 할당**. 사용자가 관리형 아이덴티티를 생성할 수도 있습니다. 이러한 아이덴티티는 구독 내의 리소스 그룹 내에서 생성되며, 서비스 주체가 구독에서 신뢰하는 EntraID에 생성됩니다. 그런 다음 관리형 아이덴티티를 Azure 서비스의 **하나 이상의 인스턴스**에 할당할 수 있습니다(여러 리소스). 사용자 할당 관리형 아이덴티티의 경우, **아이덴티티는 이를 사용하는 리소스와 별도로 관리됩니다**.
|
||||
|
||||
관리형 아이덴티티는 **영구 자격 증명**(비밀번호나 인증서와 같은)을 생성하지 않으며, 서비스 주체에 연결되어 있습니다.
|
||||
관리형 아이덴티티는 서비스 주체에 연결된 **영구 자격 증명**(비밀번호 또는 인증서)을 생성하지 않습니다.
|
||||
|
||||
### 엔터프라이즈 애플리케이션
|
||||
|
||||
이는 **서비스 주체를 필터링하고 할당된 애플리케이션을 확인하기 위한 Azure의 테이블**입니다.
|
||||
|
||||
**또 다른 유형의 "애플리케이션"이 아닙니다.** Azure에는 "엔터프라이즈 애플리케이션"이라는 객체가 없으며, 이는 서비스 주체, 애플리케이션 등록 및 관리형 아이덴티티를 확인하기 위한 추상화일 뿐입니다.
|
||||
**이는 또 다른 유형의 "애플리케이션"이 아닙니다.** Azure에는 "엔터프라이즈 애플리케이션"이라는 객체가 없으며, 이는 서비스 주체, 애플리케이션 등록 및 관리형 아이덴티티를 확인하기 위한 추상화일 뿐입니다.
|
||||
|
||||
### 관리 단위
|
||||
|
||||
관리 단위는 **조직의 특정 부분에 대한 역할의 권한을 부여할 수 있도록 합니다.**
|
||||
관리 단위는 **조직의 특정 부분에 대한 역할의 권한을 부여할 수 있도록 합니다**.
|
||||
|
||||
예시:
|
||||
|
||||
@@ -205,9 +204,9 @@ Azure Active Directory의 관리형 아이덴티티는 **애플리케이션의
|
||||
- 구현:
|
||||
- 각 지역에 대한 관리 단위 생성(예: "북미 AU", "유럽 AU").
|
||||
- 각 지역의 사용자로 AU를 채웁니다.
|
||||
- AU는 **사용자, 그룹 또는 장치**를 포함할 수 있습니다.
|
||||
- AU는 **동적 구성원 자격**을 지원합니다.
|
||||
- AU는 **AU를 포함할 수 없습니다.**
|
||||
- AU는 **사용자, 그룹 또는 장치를 포함할 수 있습니다**.
|
||||
- AU는 **동적 멤버십**을 지원합니다.
|
||||
- AU는 **AU를 포함할 수 없습니다**.
|
||||
- 관리자 역할 할당:
|
||||
- 지역 IT 직원에게 해당 지역의 AU에 범위가 지정된 "사용자 관리자" 역할을 부여합니다.
|
||||
- 결과: 지역 IT 관리자는 다른 지역에 영향을 주지 않고 자신의 지역 내 사용자 계정을 관리할 수 있습니다.
|
||||
@@ -215,45 +214,45 @@ Azure Active Directory의 관리형 아이덴티티는 **애플리케이션의
|
||||
### Entra ID 역할
|
||||
|
||||
- Entra ID를 관리하기 위해 Entra ID 주체에 할당할 수 있는 **내장 역할**이 있습니다.
|
||||
- [https://learn.microsoft.com/en-us/entra/identity/role-based-access-control/permissions-reference](https://learn.microsoft.com/en-us/entra/identity/role-based-access-control/permissions-reference)에서 역할을 확인하세요.
|
||||
- 역할은 [https://learn.microsoft.com/en-us/entra/identity/role-based-access-control/permissions-reference](https://learn.microsoft.com/en-us/entra/identity/role-based-access-control/permissions-reference)에서 확인할 수 있습니다.
|
||||
- 가장 권한이 높은 역할은 **전역 관리자**입니다.
|
||||
- 역할 설명에서 **세부 권한**을 확인할 수 있습니다.
|
||||
|
||||
## 역할 및 권한
|
||||
|
||||
**역할**은 **주체**에 **범위**에 따라 **할당**됩니다: `주체 -[HAS ROLE]->(범위)`
|
||||
**역할**은 **주체**에 **범위**를 두고 **할당**됩니다: `주체 -[HAS ROLE]->(범위)`
|
||||
|
||||
**그룹**에 할당된 **역할**은 그룹의 모든 **구성원**에게 **상속**됩니다.
|
||||
**그룹**에 할당된 **역할**은 그룹의 모든 **구성원**에 의해 **상속**됩니다.
|
||||
|
||||
역할이 할당된 범위에 따라, **역할**은 범위 컨테이너 내의 **다른 리소스**에 **상속**될 수 있습니다. 예를 들어, 사용자 A가 **구독**에 대한 **역할**을 가지고 있다면, 그는 그 **구독** 내의 모든 리소스 그룹과 **리소스 그룹 내의 모든 리소스**에 대해 그 **역할**을 가지게 됩니다.
|
||||
역할이 할당된 범위에 따라, **역할**은 범위 컨테이너 내의 **다른 리소스**에 **상속**될 수 있습니다. 예를 들어, 사용자 A가 **구독에 대한 역할**을 가지고 있다면, 그는 그 **구독 내의 모든 리소스 그룹**과 **리소스 그룹 내의 모든 리소스**에 대해 그 **역할**을 가집니다.
|
||||
|
||||
### **클래식 역할**
|
||||
|
||||
| **소유자** | <ul><li>모든 리소스에 대한 전체 액세스</li><li>다른 사용자에 대한 액세스 관리 가능</li></ul> | 모든 리소스 유형 |
|
||||
| **소유자** | <ul><li>모든 리소스에 대한 전체 액세스</li><li>다른 사용자에 대한 액세스를 관리할 수 있습니다</li></ul> | 모든 리소스 유형 |
|
||||
| ----------------------------- | ---------------------------------------------------------------------------------------- | ------------------ |
|
||||
| **기여자** | <ul><li>모든 리소스에 대한 전체 액세스</li><li>액세스 관리 불가</li></ul> | 모든 리소스 유형 |
|
||||
| **기여자** | <ul><li>모든 리소스에 대한 전체 액세스</li><li>액세스를 관리할 수 없습니다</li></ul> | 모든 리소스 유형 |
|
||||
| **읽기 전용** | • 모든 리소스 보기 | 모든 리소스 유형 |
|
||||
| **사용자 액세스 관리자** | <ul><li>모든 리소스 보기</li><li>다른 사용자에 대한 액세스 관리 가능</li></ul> | 모든 리소스 유형 |
|
||||
| **사용자 액세스 관리자** | <ul><li>모든 리소스 보기</li><li>다른 사용자에 대한 액세스를 관리할 수 있습니다</li></ul> | 모든 리소스 유형 |
|
||||
|
||||
### 내장 역할
|
||||
|
||||
[문서에서: ](https://learn.microsoft.com/en-us/azure/role-based-access-control/built-in-roles)[Azure 역할 기반 액세스 제어(Azure RBAC)](https://learn.microsoft.com/en-us/azure/role-based-access-control/overview)에는 **사용자, 그룹, 서비스 주체 및 관리형 아이덴티티**에 할당할 수 있는 여러 Azure **내장 역할**이 있습니다. 역할 할당은 **Azure 리소스에 대한 액세스를 제어하는 방법**입니다. 내장 역할이 조직의 특정 요구를 충족하지 않는 경우, [**Azure 사용자 정의 역할**](https://learn.microsoft.com/en-us/azure/role-based-access-control/custom-roles)**을 생성할 수 있습니다.**
|
||||
[문서에서: ](https://learn.microsoft.com/en-us/azure/role-based-access-control/built-in-roles)[Azure 역할 기반 액세스 제어(Azure RBAC)](https://learn.microsoft.com/en-us/azure/role-based-access-control/overview)에는 **사용자, 그룹, 서비스 주체 및 관리형 아이덴티티**에 **할당**할 수 있는 여러 Azure **내장 역할**이 있습니다. 역할 할당은 **Azure 리소스에 대한 액세스를 제어하는 방법**입니다. 내장 역할이 조직의 특정 요구를 충족하지 않는 경우, [**Azure 사용자 정의 역할**](https://learn.microsoft.com/en-us/azure/role-based-access-control/custom-roles)**을 생성할 수 있습니다.**
|
||||
|
||||
**내장** 역할은 **의도된 리소스**에만 적용됩니다. 예를 들어, **Compute** 리소스에 대한 내장 역할의 두 가지 예를 확인하세요:
|
||||
**내장** 역할은 **의도된 리소스**에만 적용됩니다. 예를 들어, **Compute** 리소스에 대한 내장 역할의 두 가지 예를 확인하십시오:
|
||||
|
||||
| [디스크 백업 읽기 전용](https://learn.microsoft.com/en-us/azure/role-based-access-control/built-in-roles#disk-backup-reader) | 디스크 백업을 수행하기 위해 백업 금고에 대한 권한을 제공합니다. | 3e5e47e6-65f7-47ef-90b5-e5dd4d455f24 |
|
||||
| ----------------------------------------------------------------------------------------------------------------------------------------- | ---------------------------------------------------------------- | ------------------------------------ |
|
||||
| [가상 머신 사용자 로그인](https://learn.microsoft.com/en-us/azure/role-based-access-control/built-in-roles#virtual-machine-user-login) | 포털에서 가상 머신을 보고 일반 사용자로 로그인합니다. | fb879df8-f326-4884-b1cf-06f3ad86be52 |
|
||||
|
||||
이 역할은 **관리 그룹, 구독 및 리소스 그룹**과 같은 논리적 컨테이너에 대해서도 할당할 수 있으며, 영향을 받는 주체는 **해당 컨테이너 내의 리소스에 대해 역할을 갖게 됩니다**.
|
||||
이 역할은 **관리 그룹, 구독 및 리소스 그룹**과 같은 논리 컨테이너에 대해서도 **할당**될 수 있으며, 영향을 받는 주체는 **해당 컨테이너 내의 리소스에 대해 역할을 갖게 됩니다**.
|
||||
|
||||
- [**모든 Azure 내장 역할**](https://learn.microsoft.com/en-us/azure/role-based-access-control/built-in-roles) 목록을 확인하세요.
|
||||
- [**모든 Entra ID 내장 역할**](https://learn.microsoft.com/en-us/azure/active-directory/roles/permissions-reference) 목록을 확인하세요.
|
||||
- [**모든 Azure 내장 역할**](https://learn.microsoft.com/en-us/azure/role-based-access-control/built-in-roles) 목록을 확인하십시오.
|
||||
- [**모든 Entra ID 내장 역할**](https://learn.microsoft.com/en-us/azure/active-directory/roles/permissions-reference) 목록을 확인하십시오.
|
||||
|
||||
### 사용자 정의 역할
|
||||
|
||||
- [**사용자 정의 역할**](https://learn.microsoft.com/en-us/azure/role-based-access-control/custom-roles)을 생성할 수도 있습니다.
|
||||
- 이들은 범위 내에서 생성되며, 역할은 여러 범위(관리 그룹, 구독 및 리소스 그룹)에 있을 수 있습니다.
|
||||
- 이는 범위 내에서 생성되며, 역할은 여러 범위(관리 그룹, 구독 및 리소스 그룹)에 있을 수 있습니다.
|
||||
- 사용자 정의 역할이 가질 모든 세부 권한을 구성할 수 있습니다.
|
||||
- 권한을 제외할 수 있습니다.
|
||||
- 제외된 권한이 있는 주체는 다른 곳에서 권한이 부여되더라도 이를 사용할 수 없습니다.
|
||||
@@ -292,29 +291,29 @@ Azure Active Directory의 관리형 아이덴티티는 **애플리케이션의
|
||||
}
|
||||
}
|
||||
```
|
||||
### 권한 순서
|
||||
### Permissions order
|
||||
|
||||
- **주체가 리소스에 대한 접근 권한을 가지려면** 그에게 명시적인 역할이 부여되어야 하며 (어떤 방식으로든) **그 권한을 부여해야 합니다**.
|
||||
- **리소스에 대한 접근 권한을 가지기 위해** 주체는 명시적인 역할이 부여되어야 하며 (어떤 방식으로든) **그 권한을 부여받아야 합니다**.
|
||||
- 명시적인 **거부 역할 할당이 권한을 부여하는 역할보다 우선합니다**.
|
||||
|
||||
<figure><img src="../../../images/image (191).png" alt=""><figcaption><p><a href="https://link.springer.com/chapter/10.1007/978-1-4842-7325-8_10">https://link.springer.com/chapter/10.1007/978-1-4842-7325-8_10</a></p></figcaption></figure>
|
||||
|
||||
### 글로벌 관리자
|
||||
### Global Administrator
|
||||
|
||||
글로벌 관리자는 **Entra ID 테넌트에 대한 완전한 제어 권한을 부여하는** Entra ID의 역할입니다. 그러나 기본적으로 Azure 리소스에 대한 권한은 부여하지 않습니다.
|
||||
Global Administrator는 **Entra ID 테넌트에 대한 완전한 제어 권한을 부여하는** Entra ID의 역할입니다. 그러나 기본적으로 Azure 리소스에 대한 권한은 부여하지 않습니다.
|
||||
|
||||
글로벌 관리자 역할을 가진 사용자는 **루트 관리 그룹에서 사용자 액세스 관리자 Azure 역할로 '승격'할 수 있는 능력**을 가지고 있습니다. 따라서 글로벌 관리자는 **모든 Azure 구독 및 관리 그룹에서 접근을 관리할 수 있습니다.**\
|
||||
Global Administrator 역할을 가진 사용자는 **Root Management Group에서 User Access Administrator Azure 역할로 '승격'할 수 있는 능력**을 가지고 있습니다. 따라서 Global Administrators는 **모든 Azure 구독 및 관리 그룹에서 접근을 관리할 수 있습니다.**\
|
||||
이 승격은 페이지 하단에서 수행할 수 있습니다: [https://portal.azure.com/#view/Microsoft_AAD_IAM/ActiveDirectoryMenuBlade/\~/Properties](https://portal.azure.com/#view/Microsoft_AAD_IAM/ActiveDirectoryMenuBlade/~/Properties)
|
||||
|
||||
<figure><img src="../../../images/image (349).png" alt=""><figcaption></figcaption></figure>
|
||||
|
||||
### Azure 정책
|
||||
### Azure Policies
|
||||
|
||||
**Azure 정책**은 조직이 리소스가 특정 기준 및 준수 요구 사항을 충족하도록 돕는 규칙입니다. 이들은 **Azure의 리소스에 대한 설정을 시행하거나 감사할 수 있게 해줍니다**. 예를 들어, 허가되지 않은 지역에서 가상 머신의 생성을 방지하거나 모든 리소스에 특정 태그가 있어 추적할 수 있도록 보장할 수 있습니다.
|
||||
**Azure Policies**는 조직이 리소스가 특정 기준 및 준수 요구 사항을 충족하도록 돕는 규칙입니다. 이들은 **Azure의 리소스에 대한 설정을 시행하거나 감사할 수 있게 해줍니다**. 예를 들어, 허가되지 않은 지역에서 가상 머신의 생성을 방지하거나 모든 리소스에 특정 태그가 있어 추적할 수 있도록 보장할 수 있습니다.
|
||||
|
||||
Azure 정책은 **적극적**입니다: 비준수 리소스의 생성이나 변경을 중단할 수 있습니다. 또한 **반응적**으로, 기존의 비준수 리소스를 찾아 수정할 수 있습니다.
|
||||
Azure Policies는 **선제적**입니다: 비준수 리소스의 생성이나 변경을 중단할 수 있습니다. 또한 **반응적**으로, 기존의 비준수 리소스를 찾아 수정할 수 있습니다.
|
||||
|
||||
#### **핵심 개념**
|
||||
#### **Key Concepts**
|
||||
|
||||
1. **정책 정의**: 허용되거나 요구되는 사항을 명시하는 JSON으로 작성된 규칙입니다.
|
||||
2. **정책 할당**: 특정 범위(예: 구독, 리소스 그룹)에 정책을 적용하는 것입니다.
|
||||
@@ -323,16 +322,16 @@ Azure 정책은 **적극적**입니다: 비준수 리소스의 생성이나 변
|
||||
|
||||
**몇 가지 예시:**
|
||||
|
||||
1. **특정 Azure 지역 준수 보장**: 이 정책은 모든 리소스가 특정 Azure 지역에 배포되도록 보장합니다. 예를 들어, 회사는 GDPR 준수를 위해 모든 데이터를 유럽에 저장하고 싶어할 수 있습니다.
|
||||
1. **특정 Azure 지역에 대한 준수 보장**: 이 정책은 모든 리소스가 특정 Azure 지역에 배포되도록 보장합니다. 예를 들어, 회사는 GDPR 준수를 위해 모든 데이터를 유럽에 저장하고 싶어할 수 있습니다.
|
||||
2. **명명 기준 시행**: 정책은 Azure 리소스에 대한 명명 규칙을 시행할 수 있습니다. 이는 대규모 환경에서 리소스를 이름에 따라 조직하고 쉽게 식별하는 데 도움이 됩니다.
|
||||
3. **특정 리소스 유형 제한**: 이 정책은 특정 유형의 리소스 생성을 제한할 수 있습니다. 예를 들어, 비용을 통제하기 위해 특정 VM 크기와 같은 비싼 리소스 유형의 생성을 방지하는 정책을 설정할 수 있습니다.
|
||||
4. **태그 정책 시행**: 태그는 리소스 관리에 사용되는 Azure 리소스와 관련된 키-값 쌍입니다. 정책은 모든 리소스에 특정 태그가 존재해야 하거나 특정 값을 가져야 한다고 시행할 수 있습니다. 이는 비용 추적, 소유권 또는 리소스 분류에 유용합니다.
|
||||
5. **리소스에 대한 공개 접근 제한**: 정책은 특정 리소스(예: 스토리지 계정 또는 데이터베이스)가 공개 엔드포인트를 가지지 않도록 시행할 수 있으며, 이를 통해 조직의 네트워크 내에서만 접근할 수 있도록 보장합니다.
|
||||
6. **보안 설정 자동 적용**: 정책은 모든 VM에 특정 네트워크 보안 그룹을 적용하거나 모든 스토리지 계정이 암호화를 사용하도록 보장하는 등 리소스에 보안 설정을 자동으로 적용하는 데 사용될 수 있습니다.
|
||||
5. **리소스에 대한 공용 접근 제한**: 정책은 특정 리소스(예: 스토리지 계정 또는 데이터베이스)가 공용 엔드포인트를 가지지 않도록 시행하여 조직의 네트워크 내에서만 접근할 수 있도록 보장할 수 있습니다.
|
||||
6. **보안 설정 자동 적용**: 정책은 모든 VM에 특정 네트워크 보안 그룹을 적용하거나 모든 스토리지 계정이 암호화를 사용하도록 보장하는 등 리소스에 보안 설정을 자동으로 적용하는 데 사용할 수 있습니다.
|
||||
|
||||
Azure 정책은 Azure 계층의 모든 수준에 첨부될 수 있지만, **일반적으로 루트 관리 그룹**이나 다른 관리 그룹에서 사용됩니다.
|
||||
Azure Policies는 Azure 계층의 모든 수준에 첨부될 수 있지만, **일반적으로 루트 관리 그룹**이나 다른 관리 그룹에서 사용됩니다.
|
||||
|
||||
Azure 정책 JSON 예시:
|
||||
Azure policy json example:
|
||||
```json
|
||||
{
|
||||
"policyRule": {
|
||||
@@ -352,7 +351,7 @@ Azure 정책 JSON 예시:
|
||||
```
|
||||
### 권한 상속
|
||||
|
||||
Azure **권한은 계층의 어떤 부분에도 할당될 수 있습니다**. 여기에는 관리 그룹, 구독, 리소스 그룹 및 개별 리소스가 포함됩니다. 권한은 **할당된 엔터티의 포함된 **리소스**에 의해 **상속**됩니다.
|
||||
Azure **권한은 계층의 어떤 부분에도 할당될 수 있습니다**. 여기에는 관리 그룹, 구독, 리소스 그룹 및 개별 리소스가 포함됩니다. 권한은 할당된 엔터티의 **리소스**에 의해 **상속**됩니다.
|
||||
|
||||
이 계층 구조는 접근 권한의 효율적이고 확장 가능한 관리를 가능하게 합니다.
|
||||
|
||||
@@ -363,10 +362,10 @@ Azure **권한은 계층의 어떤 부분에도 할당될 수 있습니다**.
|
||||
**RBAC** (역할 기반 접근 제어)는 우리가 이전 섹션에서 이미 본 것입니다: **리소스에 대한 접근을 부여하기 위해 주체에 역할을 할당하는 것**입니다.\
|
||||
그러나 경우에 따라 **더 세분화된 접근 관리**를 제공하거나 **수백 개의** 역할 **할당** 관리를 **단순화**하고 싶을 수 있습니다.
|
||||
|
||||
Azure **ABAC** (속성 기반 접근 제어)는 특정 작업의 맥락에서 **속성을 기반으로 한 역할 할당 조건**을 추가하여 Azure RBAC를 기반으로 합니다. _역할 할당 조건_은 **더 세분화된 접근 제어를 제공하기 위해 역할 할당에 선택적으로 추가할 수 있는 추가 검사**입니다. 조건은 역할 정의 및 역할 할당의 일부로 부여된 권한을 필터링합니다. 예를 들어, **객체를 읽기 위해 특정 태그가 있어야 한다는 조건을 추가할 수 있습니다**.\
|
||||
조건을 사용하여 특정 리소스에 대한 접근을 **명시적으로 거부할 수는 없습니다**.
|
||||
Azure **ABAC** (속성 기반 접근 제어)는 특정 작업의 맥락에서 **속성을 기반으로 한 역할 할당 조건**을 추가하여 Azure RBAC를 기반으로 합니다. _역할 할당 조건_은 **더 세분화된 접근 제어를 제공하기 위해 역할 할당에 선택적으로 추가할 수 있는 추가 검사**입니다. 조건은 역할 정의 및 역할 할당의 일환으로 부여된 권한을 필터링합니다. 예를 들어, **객체를 읽기 위해 특정 태그가 있어야 한다는 조건을 추가할 수 있습니다**.\
|
||||
특정 리소스에 대한 접근을 **조건을 사용하여 명시적으로 거부할 수는 없습니다**.
|
||||
|
||||
## 참고 문헌
|
||||
## 참조
|
||||
|
||||
- [https://learn.microsoft.com/en-us/azure/governance/management-groups/overview](https://learn.microsoft.com/en-us/azure/governance/management-groups/overview)
|
||||
- [https://learn.microsoft.com/en-us/azure/cloud-adoption-framework/ready/azure-best-practices/organize-subscriptions](https://learn.microsoft.com/en-us/azure/cloud-adoption-framework/ready/azure-best-practices/organize-subscriptions)
|
||||
|
||||
Reference in New Issue
Block a user