mirror of
https://github.com/HackTricks-wiki/hacktricks-cloud.git
synced 2026-07-28 22:51:09 -07:00
Translated ['src/pentesting-cloud/azure-security/az-basic-information/RE
This commit is contained in:
@@ -9,8 +9,8 @@
|
||||
### 관리 그룹
|
||||
|
||||
- **다른 관리 그룹 또는 구독**을 포함할 수 있습니다.
|
||||
- 이를 통해 **RBAC 및 Azure Policy**와 같은 거버넌스 제어를 관리 그룹 수준에서 한 번 적용하고 그룹 내 모든 구독이 이를 **상속**받도록 할 수 있습니다.
|
||||
- **10,000개의 관리** 그룹을 단일 디렉터리에서 지원할 수 있습니다.
|
||||
- 이를 통해 **RBAC 및 Azure Policy**와 같은 거버넌스 제어를 관리 그룹 수준에서 한 번 적용하고 그룹 내 모든 구독이 이를 **상속**받을 수 있습니다.
|
||||
- **10,000 관리** 그룹을 단일 디렉터리에서 지원할 수 있습니다.
|
||||
- 관리 그룹 트리는 **최대 6단계 깊이**를 지원할 수 있습니다. 이 제한은 루트 수준이나 구독 수준을 포함하지 않습니다.
|
||||
- 각 관리 그룹 및 구독은 **하나의 부모**만 지원할 수 있습니다.
|
||||
- 여러 관리 그룹을 생성할 수 있지만 **루트 관리 그룹은 하나만 존재**합니다.
|
||||
@@ -21,7 +21,7 @@
|
||||
|
||||
### Azure 구독
|
||||
|
||||
- 리소스(VM, DB 등)를 실행하고 청구되는 또 다른 **논리적 컨테이너**입니다.
|
||||
- 리소스(가상 머신, 데이터베이스 등)를 실행하고 청구되는 또 다른 **논리적 컨테이너**입니다.
|
||||
- 그 **부모**는 항상 **관리 그룹**이며(루트 관리 그룹일 수 있음) 구독은 다른 구독을 포함할 수 없습니다.
|
||||
- **하나의 Entra ID** 디렉터리만 신뢰합니다.
|
||||
- 구독 수준(또는 그 부모의 수준)에서 적용된 **권한**은 구독 내 모든 리소스에 **상속**됩니다.
|
||||
@@ -52,13 +52,13 @@ Azure 리소스 ID의 형식은 다음과 같습니다:
|
||||
|
||||
Azure는 Microsoft의 포괄적인 **클라우드 컴퓨팅 플랫폼으로, 다양한 서비스**를 제공합니다. 여기에는 가상 머신, 데이터베이스, 인공지능 및 스토리지가 포함됩니다. Azure는 애플리케이션을 호스팅하고 관리하며, 확장 가능한 인프라를 구축하고, 클라우드에서 현대적인 작업 부하를 실행하는 기반 역할을 합니다. Azure는 개발자와 IT 전문가가 애플리케이션과 서비스를 원활하게 생성, 배포 및 관리할 수 있는 도구를 제공하여 스타트업부터 대기업까지 다양한 요구를 충족합니다.
|
||||
|
||||
### Entra ID (이전 Azure Active Directory)
|
||||
### Entra ID (구 Azure Active Directory)
|
||||
|
||||
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 주체
|
||||
|
||||
@@ -101,12 +101,12 @@ Entra 도메인 서비스는 **전통적인 Windows Active Directory 환경과
|
||||
- 사용자가 LinkedIn과 작업 또는 학교 계정을 연결할 수 있도록 허용: 기본 **예**
|
||||
- 사용자가 로그인 상태를 유지하도록 표시: 기본 **예**
|
||||
- 사용자가 소유한 장치에 대한 BitLocker 키를 복구하지 못하도록 제한: 기본 아니오(장치 설정에서 확인)
|
||||
- 다른 사용자 읽기: 기본 **예** (Microsoft Graph를 통해)
|
||||
- 다른 사용자 읽기: 기본 **예**(Microsoft Graph를 통해)
|
||||
- **게스트**
|
||||
- **게스트 사용자 액세스 제한** 옵션:
|
||||
- **게스트 사용자는 회원과 동일한 액세스를 가집니다**.
|
||||
- **게스트 사용자는 디렉터리 객체의 속성과 멤버십에 대한 제한된 액세스를 가집니다(기본)**. 이는 기본적으로 게스트가 자신의 사용자 프로필에만 액세스할 수 있도록 제한합니다. 다른 사용자 및 그룹 정보에 대한 액세스는 더 이상 허용되지 않습니다.
|
||||
- **게스트 사용자 액세스는 자신의 디렉터리 객체의 속성과 멤버십으로 제한됩니다**는 가장 제한적인 옵션입니다.
|
||||
- **게스트 사용자 액세스는 자신의 디렉터리 객체의 속성과 멤버십으로 제한됩니다**가 가장 제한적입니다.
|
||||
- **게스트 초대 가능** 옵션:
|
||||
- **조직의 누구나 게스트 사용자 초대 가능(가장 포괄적) - 기본**
|
||||
- **회원 사용자 및 특정 관리 역할에 할당된 사용자는 게스트 사용자 초대 가능**
|
||||
@@ -128,7 +128,7 @@ Entra 도메인 서비스는 **전통적인 Windows Active Directory 환경과
|
||||
|
||||
**2가지 유형의 멤버십**이 있습니다:
|
||||
|
||||
- **지정된**: 특정 구성원을 수동으로 그룹에 추가할 수 있습니다.
|
||||
- **할당됨**: 특정 구성원을 그룹에 수동으로 추가할 수 있습니다.
|
||||
- **동적 멤버십**: 규칙을 사용하여 멤버십을 자동으로 관리하며, 구성원 속성이 변경될 때 그룹 포함을 업데이트합니다.
|
||||
|
||||
### **서비스 주체**
|
||||
@@ -151,8 +151,8 @@ Entra 도메인 서비스는 **전통적인 Windows Active Directory 환경과
|
||||
3. **인증서, 비밀번호 및 연합 자격 증명:** 서비스 주체로 로그인하기 위해 비밀번호 또는 인증서를 생성하거나 연합 액세스를 부여할 수 있습니다(예: Github Actions).
|
||||
4. **API 권한:** 앱이 액세스할 수 있는 리소스 또는 API를 지정합니다.
|
||||
5. **인증 설정:** 앱이 지원하는 인증 흐름을 정의합니다(예: OAuth2, OpenID Connect).
|
||||
6. **서비스 주체**: 앱이 생성될 때 서비스 주체가 생성됩니다(웹 콘솔에서 수행된 경우) 또는 새 테넌트에 설치될 때 생성됩니다.
|
||||
7. **서비스 주체**는 요청된 모든 권한을 받게 됩니다.
|
||||
6. **서비스 주체**: 앱이 생성될 때 서비스 주체가 생성됩니다(웹 콘솔에서 생성된 경우) 또는 새 테넌트에 설치될 때 생성됩니다.
|
||||
7. **서비스 주체**는 요청된 모든 권한을 얻습니다.
|
||||
|
||||
### 기본 동의 권한
|
||||
|
||||
@@ -164,8 +164,8 @@ Entra 도메인 서비스는 **전통적인 Windows Active Directory 환경과
|
||||
- 모든 사용자는 "낮은 영향"으로 분류된 권한에 대해 동의할 수 있으며, 검증된 게시자의 앱 또는 이 조직에 등록된 앱에 대해 동의할 수 있습니다.
|
||||
- **기본** 낮은 영향 권한(낮은 영향으로 추가하려면 수락해야 함):
|
||||
- User.Read - 로그인 및 사용자 프로필 읽기
|
||||
- offline_access - 사용자가 액세스 권한을 부여한 데이터에 대한 액세스 유지
|
||||
- openid - 사용자를 로그인시키기
|
||||
- offline_access - 사용자가 액세스할 수 있도록 허용한 데이터에 대한 액세스 유지
|
||||
- openid - 사용자를 로그인
|
||||
- profile - 사용자의 기본 프로필 보기
|
||||
- email - 사용자의 이메일 주소 보기
|
||||
- **앱에 대한 사용자 동의 허용(기본)**
|
||||
@@ -174,17 +174,17 @@ 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는 자동으로 **아이덴티티**를 **삭제**합니다.
|
||||
- **사용자 할당**. 사용자가 관리형 아이덴티티를 생성할 수도 있습니다. 이러한 아이덴티티는 구독 내의 리소스 그룹 안에 생성되며, 서비스 주체가 구독에서 신뢰하는 EntraID에 생성됩니다. 그런 다음 관리형 아이덴티티를 Azure 서비스의 하나 이상의 인스턴스(여러 리소스)에 할당할 수 있습니다. 사용자 할당 관리형 아이덴티티의 경우, **아이덴티티는 이를 사용하는 리소스와 별도로 관리됩니다**.
|
||||
- **시스템 할당**. 일부 Azure 서비스는 **서비스 인스턴스에서 직접 관리형 아이덴티티를 활성화**할 수 있습니다. 시스템 할당 관리형 아이덴티티를 활성화하면, **서비스 주체**가 리소스가 위치한 구독에서 신뢰하는 Entra ID 테넌트에 생성됩니다. **리소스**가 **삭제되면**, Azure는 자동으로 **아이덴티티**를 삭제합니다.
|
||||
- **사용자 할당**. 사용자가 관리형 아이덴티티를 생성할 수도 있습니다. 이러한 아이덴티티는 구독 내의 리소스 그룹 내에서 생성되며, 서비스 주체가 구독에서 신뢰하는 EntraID에 생성됩니다. 그런 다음 관리형 아이덴티티를 Azure 서비스의 하나 이상의 인스턴스(여러 리소스)에 할당할 수 있습니다. 사용자 할당 관리형 아이덴티티의 경우, **아이덴티티는 이를 사용하는 리소스와 별도로 관리됩니다**.
|
||||
|
||||
관리형 아이덴티티는 서비스 주체에 연결된 **영구 자격 증명**(비밀번호 또는 인증서)을 생성하지 않습니다.
|
||||
|
||||
@@ -192,7 +192,7 @@ Azure Active Directory의 관리형 아이덴티티는 **애플리케이션의
|
||||
|
||||
이는 **서비스 주체를 필터링하고 할당된 애플리케이션을 확인하기 위한 Azure의 테이블**입니다.
|
||||
|
||||
**이는 또 다른 유형의 "애플리케이션"이 아닙니다.** Azure에는 "엔터프라이즈 애플리케이션"이라는 객체가 없으며, 이는 서비스 주체, 애플리케이션 등록 및 관리형 아이덴티티를 확인하기 위한 추상화일 뿐입니다.
|
||||
**또 다른 유형의 "애플리케이션"이 아닙니다.** Azure에는 "엔터프라이즈 애플리케이션"이라는 객체가 없으며, 이는 서비스 주체, 애플리케이션 등록 및 관리형 아이덴티티를 확인하기 위한 추상화일 뿐입니다.
|
||||
|
||||
### 관리 단위
|
||||
|
||||
@@ -200,67 +200,61 @@ Azure Active Directory의 관리형 아이덴티티는 **애플리케이션의
|
||||
|
||||
예시:
|
||||
|
||||
- 시나리오: 한 회사가 지역 IT 관리자가 자신의 지역의 사용자만 관리하도록 하기를 원합니다.
|
||||
- 시나리오: 회사는 지역 IT 관리자가 자신의 지역의 사용자만 관리하도록 하기를 원합니다.
|
||||
- 구현:
|
||||
- 각 지역에 대한 관리 단위 생성(예: "북미 AU", "유럽 AU").
|
||||
- 각 지역의 사용자로 AU를 채웁니다.
|
||||
- AU는 **사용자, 그룹 또는 장치를 포함할 수 있습니다**.
|
||||
- AU는 **사용자, 그룹 또는 장치**를 포함할 수 있습니다.
|
||||
- AU는 **동적 멤버십**을 지원합니다.
|
||||
- AU는 **AU를 포함할 수 없습니다**.
|
||||
- 관리자 역할 할당:
|
||||
- 지역 IT 직원에게 해당 지역의 AU에 범위가 지정된 "사용자 관리자" 역할을 부여합니다.
|
||||
- 결과: 지역 IT 관리자는 다른 지역에 영향을 주지 않고 자신의 지역 내 사용자 계정을 관리할 수 있습니다.
|
||||
|
||||
### Entra ID 역할
|
||||
### 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)에서 역할을 확인하세요.
|
||||
- EntraID에서 **`PRIVILEGED`**로 표시된 역할은 주의해서 할당해야 합니다. Microsoft는 [문서에서](https://learn.microsoft.com/en-us/entra/identity/role-based-access-control/permissions-reference) 설명하듯이, 특권 역할 할당은 안전하고 의도된 방식으로 사용되지 않으면 권한 상승으로 이어질 수 있습니다.
|
||||
- 가장 특권이 높은 역할은 **전역 관리자**입니다.
|
||||
- 역할 그룹은 **세분화된 권한**을 포함하며, 설명에서 찾을 수 있습니다.
|
||||
- 원하는 권한으로 **사용자 정의 역할**을 생성할 수 있습니다. 그러나 어떤 이유로 인해 모든 세분화된 권한이 관리자가 사용자 정의 역할을 생성하는 데 사용할 수 있는 것은 아닙니다.
|
||||
- Entra ID의 역할은 Azure의 역할과 완전히 **독립적**입니다. 유일한 관계는 Entra ID에서 **전역 관리자** 역할을 가진 주체가 Azure에서 **사용자 액세스 관리자** 역할로 승격할 수 있다는 것입니다.
|
||||
- Entra ID 역할에서 **와일드카드를 사용할 수 없습니다**.
|
||||
|
||||
## 역할 및 권한
|
||||
## Azure 역할 및 권한
|
||||
|
||||
**역할**은 **주체**에 **범위**에 따라 **할당**됩니다: `주체 -[HAS ROLE]->(범위)`
|
||||
|
||||
**그룹**에 할당된 **역할**은 그룹의 모든 **구성원**에 의해 **상속**됩니다.
|
||||
|
||||
역할이 할당된 범위에 따라, **역할**은 범위 컨테이너 내의 **다른 리소스**에 **상속**될 수 있습니다. 예를 들어, 사용자 A가 **구독에 대한 역할**을 가지고 있다면, 그는 그 구독 내의 모든 리소스 그룹과 **리소스 그룹 내의 모든 리소스**에 대해 그 **역할**을 가지게 됩니다.
|
||||
|
||||
### 클래식 역할
|
||||
|
||||
| **소유자** | <ul><li>모든 리소스에 대한 전체 액세스</li><li>다른 사용자에 대한 액세스 관리 가능</li></ul> | 모든 리소스 유형 |
|
||||
| ----------------------------- | ---------------------------------------------------------------------------------------- | ------------------ |
|
||||
| **기여자** | <ul><li>모든 리소스에 대한 전체 액세스</li><li>액세스 관리 불가</li></ul> | 모든 리소스 유형 |
|
||||
| **읽기 전용** | • 모든 리소스 보기 | 모든 리소스 유형 |
|
||||
| **사용자 액세스 관리자** | <ul><li>모든 리소스 보기</li><li>다른 사용자에 대한 액세스 관리 가능</li></ul> | 모든 리소스 유형 |
|
||||
- **역할**은 **주체**에 **범위**를 두고 **할당**됩니다: `주체 -[HAS ROLE]->(범위)`
|
||||
- **그룹**에 할당된 **역할**은 그룹의 모든 **구성원**에 의해 **상속**됩니다.
|
||||
- 역할이 할당된 범위에 따라, **역할**은 범위 컨테이너 내의 **다른 리소스**에 **상속**될 수 있습니다. 예를 들어, 사용자 A가 **구독**에 대한 **역할**을 가지고 있다면, 그는 그 **구독** 내의 모든 리소스 그룹과 **리소스 그룹 내의 모든 리소스**에 대해 그 **역할**을 가집니다.
|
||||
|
||||
### 내장 역할
|
||||
|
||||
[문서에서: ](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#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)을 생성할 수도 있습니다.
|
||||
- 이들은 범위 내에서 생성되며, 역할은 여러 범위(관리 그룹, 구독 및 리소스 그룹)에 있을 수 있습니다.
|
||||
- 사용자 정의 역할이 가질 모든 세부 권한을 구성할 수 있습니다.
|
||||
- 이들은 범위 내에서 생성되지만, 역할은 여러 범위(관리 그룹, 구독 및 리소스 그룹)에 있을 수 있습니다.
|
||||
- 사용자 정의 역할이 가질 모든 세분화된 권한을 구성할 수 있습니다.
|
||||
- 권한을 제외할 수 있습니다.
|
||||
- 제외된 권한이 있는 주체는 다른 곳에서 권한이 부여되더라도 이를 사용할 수 없습니다.
|
||||
- 와일드카드를 사용할 수 있습니다.
|
||||
- 사용되는 형식은 JSON입니다.
|
||||
- `actions`는 리소스에 대한 관리 작업에 대한 권한을 나타내며, 리소스 정의 및 설정을 생성, 업데이트 또는 삭제하는 작업을 포함합니다.
|
||||
- `dataActions`는 리소스 내의 데이터 작업에 대한 권한으로, 리소스에 포함된 실제 데이터를 읽고, 쓰고, 삭제할 수 있도록 합니다.
|
||||
- `notActions` 및 `notDataActions`는 역할에서 특정 권한을 제외하는 데 사용됩니다. 그러나 **이들은 권한을 거부하지 않으며**, 다른 역할이 이를 부여하면 주체는 이를 가질 수 있습니다.
|
||||
- `notActions` 및 `notDataActions`는 역할에서 특정 권한을 제외하는 데 사용됩니다. 그러나 **이들은 권한을 거부하지 않습니다**. 다른 역할이 이를 부여하면 주체는 이를 가질 수 있습니다.
|
||||
- `assignableScopes`는 역할을 할당할 수 있는 범위의 배열입니다(관리 그룹, 구독 또는 리소스 그룹과 같은).
|
||||
|
||||
사용자 정의 역할에 대한 권한 JSON 예시:
|
||||
@@ -295,16 +289,16 @@ 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
|
||||
|
||||
Global Administrator는 **Entra ID 테넌트에 대한 완전한 제어 권한을 부여하는 역할**입니다. 그러나 기본적으로 Azure 리소스에 대한 권한은 부여하지 않습니다.
|
||||
Global Administrator는 **Entra ID 테넌트에 대한 완전한 제어 권한**을 부여하는 Entra ID의 역할입니다. 그러나 기본적으로 Azure 리소스에 대한 권한은 부여하지 않습니다.
|
||||
|
||||
Global Administrator 역할을 가진 사용자는 **Root Management Group에서 User Access Administrator Azure 역할로 '승격'할 수 있는 능력**을 가지고 있습니다. 따라서 Global Administrators는 **모든 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>
|
||||
@@ -315,31 +309,31 @@ Global Administrator 역할을 가진 사용자는 **Root Management Group에서
|
||||
|
||||
### Deny Assignments
|
||||
|
||||
역할 할당과 마찬가지로, **거부 할당**은 **Azure 리소스에 대한 접근을 제어하는 데 사용됩니다**. 그러나 **거부 할당**은 리소스에 대한 접근을 **명시적으로 거부하는 데 사용됩니다**, 사용자가 역할 할당을 통해 접근 권한을 부여받았더라도 마찬가지입니다. **거부 할당**은 **역할 할당**보다 우선하며, 이는 사용자가 역할 할당을 통해 접근 권한을 부여받았지만 거부 할당을 통해 명시적으로 접근이 거부된 경우 거부 할당이 우선한다는 것을 의미합니다.
|
||||
역할 할당과 마찬가지로, **거부 할당**은 **Azure 리소스에 대한 액세스를 제어하는 데 사용됩니다**. 그러나 **거부 할당**은 리소스에 대한 액세스를 **명시적으로 거부하는 데 사용됩니다**, 사용자가 역할 할당을 통해 액세스 권한을 부여받았더라도 말입니다. **거부 할당**은 **역할 할당**보다 우선하며, 이는 사용자가 역할 할당을 통해 액세스 권한을 부여받았지만 거부 할당을 통해 명시적으로 액세스가 거부된 경우 거부 할당이 우선한다는 것을 의미합니다.
|
||||
|
||||
역할 할당과 마찬가지로, **거부 할당**은 영향을 받는 주체와 거부되는 권한을 나타내는 특정 범위에 적용됩니다. 또한, 거부 할당의 경우 **자식 리소스에 의해 상속되는 것을 방지할 수 있습니다**.
|
||||
|
||||
### Azure Policies
|
||||
|
||||
**Azure Policies**는 조직이 리소스가 특정 기준 및 준수 요구 사항을 충족하도록 돕는 규칙입니다. 이들은 **Azure의 리소스에 대한 설정을 시행하거나 감사할 수 있게 해줍니다**. 예를 들어, 무단 지역에서 가상 머신의 생성을 방지하거나 모든 리소스에 특정 태그가 있어 추적할 수 있도록 보장할 수 있습니다.
|
||||
**Azure Policies**는 조직이 리소스가 특정 기준 및 준수 요구 사항을 충족하도록 돕는 규칙입니다. 이를 통해 **Azure의 리소스에 대한 설정을 시행하거나 감사할 수 있습니다**. 예를 들어, 무단 지역에서 가상 머신의 생성을 방지하거나 모든 리소스에 특정 태그가 있어 추적할 수 있도록 보장할 수 있습니다.
|
||||
|
||||
Azure Policies는 **적극적입니다**: 비준수 리소스의 생성이나 변경을 중단할 수 있습니다. 또한 **반응적**으로, 기존의 비준수 리소스를 찾아 수정할 수 있습니다.
|
||||
Azure Policies는 **선제적**입니다: 비준수 리소스의 생성 또는 변경을 중단할 수 있습니다. 또한 **반응적**으로, 기존 비준수 리소스를 찾아 수정할 수 있습니다.
|
||||
|
||||
#### **Key Concepts**
|
||||
|
||||
1. **정책 정의**: 허용되거나 요구되는 사항을 명시하는 JSON으로 작성된 규칙입니다.
|
||||
1. **정책 정의**: 허용되거나 요구되는 사항을 지정하는 JSON으로 작성된 규칙입니다.
|
||||
2. **정책 할당**: 특정 범위(예: 구독, 리소스 그룹)에 정책을 적용하는 것입니다.
|
||||
3. **이니셔티브**: 더 넓은 시행을 위해 그룹화된 정책 모음입니다.
|
||||
4. **효과**: 정책이 트리거될 때 발생하는 일을 명시합니다 (예: "거부", "감사" 또는 "추가").
|
||||
4. **효과**: 정책이 트리거될 때 발생하는 일을 지정합니다 (예: "Deny", "Audit", 또는 "Append").
|
||||
|
||||
**몇 가지 예시:**
|
||||
**일부 예시:**
|
||||
|
||||
1. **특정 Azure 지역에 대한 준수 보장**: 이 정책은 모든 리소스가 특정 Azure 지역에 배포되도록 보장합니다. 예를 들어, 회사는 GDPR 준수를 위해 모든 데이터를 유럽에 저장하고 싶어할 수 있습니다.
|
||||
2. **명명 기준 시행**: 정책은 Azure 리소스에 대한 명명 규칙을 시행할 수 있습니다. 이는 대규모 환경에서 리소스를 이름에 따라 조직하고 쉽게 식별하는 데 도움이 됩니다.
|
||||
1. **특정 Azure 지역 준수 보장**: 이 정책은 모든 리소스가 특정 Azure 지역에 배포되도록 보장합니다. 예를 들어, 회사는 GDPR 준수를 위해 모든 데이터를 유럽에 저장하고 싶어할 수 있습니다.
|
||||
2. **명명 기준 시행**: 정책은 Azure 리소스에 대한 명명 규칙을 시행할 수 있습니다. 이는 대규모 환경에서 리소스를 이름에 따라 쉽게 식별하고 조직하는 데 도움이 됩니다.
|
||||
3. **특정 리소스 유형 제한**: 이 정책은 특정 유형의 리소스 생성을 제한할 수 있습니다. 예를 들어, 특정 VM 크기와 같은 비싼 리소스 유형의 생성을 방지하는 정책을 설정하여 비용을 제어할 수 있습니다.
|
||||
4. **태그 정책 시행**: 태그는 리소스 관리에 사용되는 Azure 리소스와 연결된 키-값 쌍입니다. 정책은 모든 리소스에 특정 태그가 존재하거나 특정 값을 가져야 한다고 시행할 수 있습니다. 이는 비용 추적, 소유권 또는 리소스 분류에 유용합니다.
|
||||
5. **리소스에 대한 공용 접근 제한**: 정책은 특정 리소스(예: 스토리지 계정 또는 데이터베이스)가 공용 엔드포인트를 가지지 않도록 시행하여 조직의 네트워크 내에서만 접근할 수 있도록 보장할 수 있습니다.
|
||||
6. **보안 설정 자동 적용**: 정책은 모든 VM에 특정 네트워크 보안 그룹을 적용하거나 모든 스토리지 계정이 암호화를 사용하도록 보장하는 등 리소스에 보안 설정을 자동으로 적용하는 데 사용될 수 있습니다.
|
||||
5. **리소스에 대한 공용 액세스 제한**: 정책은 특정 리소스(예: 스토리지 계정 또는 데이터베이스)가 공용 엔드포인트를 가지지 않도록 시행하여 조직의 네트워크 내에서만 액세스할 수 있도록 보장할 수 있습니다.
|
||||
6. **보안 설정 자동 적용**: 정책은 모든 VM에 특정 네트워크 보안 그룹을 적용하거나 모든 스토리지 계정이 암호화를 사용하도록 보장하는 등 리소스에 보안 설정을 자동으로 적용하는 데 사용할 수 있습니다.
|
||||
|
||||
Azure Policies는 Azure 계층의 모든 수준에 첨부될 수 있지만, **일반적으로 루트 관리 그룹**이나 다른 관리 그룹에서 사용됩니다.
|
||||
|
||||
@@ -371,13 +365,13 @@ Azure **권한은 계층의 어떤 부분에도 할당될 수 있습니다**.
|
||||
|
||||
### Azure RBAC vs ABAC
|
||||
|
||||
**RBAC** (역할 기반 접근 제어)는 우리가 이전 섹션에서 이미 본 것입니다: **리소스에 대한 접근을 부여하기 위해 주체에게 역할을 할당하는 것**입니다.\
|
||||
**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)
|
||||
|
||||
@@ -184,9 +184,9 @@ Connect-AzureAD -AccountId test@corp.onmicrosoft.com -AadAccessToken $token
|
||||
{{#endtab }}
|
||||
{{#endtabs }}
|
||||
|
||||
Azure에 **CLI**를 통해 로그인할 때, **Microsoft**에 속한 **tenant**의 **Azure Application**을 사용하고 있습니다. 이러한 애플리케이션은 귀하의 계정에서 생성할 수 있는 것처럼 **클라이언트 ID**를 가지고 있습니다. **콘솔에서 볼 수 있는 허용된 애플리케이션 목록**에서 모든 애플리케이션을 **볼 수는 없지만**, 기본적으로 허용됩니다.
|
||||
Azure에 **CLI**를 통해 로그인할 때, **Microsoft**에 속하는 **tenant**의 **Azure Application**을 사용하고 있습니다. 이러한 애플리케이션은 귀하의 계정에서 생성할 수 있는 것처럼 **클라이언트 ID**를 가지고 있습니다. **콘솔에서 볼 수 있는 허용된 애플리케이션 목록**에서 모든 애플리케이션을 **볼 수는 없지만**, 기본적으로 허용됩니다.
|
||||
|
||||
예를 들어, **인증**을 수행하는 **powershell 스크립트**는 클라이언트 ID **`1950a258-227b-4e31-a9cf-717495945fc2`**를 가진 애플리케이션을 사용합니다. 애플리케이션이 콘솔에 나타나지 않더라도, 시스템 관리자는 사용자가 해당 앱을 통해 연결할 수 없도록 **해당 애플리케이션을 차단**할 수 있습니다.
|
||||
예를 들어, **인증**을 수행하는 **powershell script**는 클라이언트 ID **`1950a258-227b-4e31-a9cf-717495945fc2`**를 가진 앱을 사용합니다. 앱이 콘솔에 나타나지 않더라도, 시스템 관리자는 사용자가 해당 앱을 통해 연결할 수 없도록 **해당 애플리케이션을 차단**할 수 있습니다.
|
||||
|
||||
그러나 **Azure에 연결할 수 있는 다른 클라이언트 ID**의 애플리케이션이 있습니다:
|
||||
```bash
|
||||
@@ -365,7 +365,7 @@ $password = "ThisIsTheNewPassword.!123" | ConvertTo- SecureString -AsPlainText
|
||||
```
|
||||
### MFA 및 조건부 액세스 정책
|
||||
|
||||
모든 사용자에게 MFA를 추가하는 것이 강력히 권장되지만, 일부 회사는 이를 설정하지 않거나 특정 위치, 브라우저 또는 **일부 조건**에서 로그인할 경우에만 MFA를 요구하는 조건부 액세스를 설정할 수 있습니다. 이러한 정책은 올바르게 구성되지 않으면 **우회**에 취약할 수 있습니다. 확인하세요:
|
||||
모든 사용자에게 MFA를 추가하는 것이 강력히 권장되지만, 일부 회사는 이를 설정하지 않거나 특정 위치, 브라우저 또는 **일부 조건**에서 로그인할 경우에만 MFA를 요구하는 조건부 액세스를 설정할 수 있습니다. 이러한 정책이 올바르게 구성되지 않으면 **우회**에 취약할 수 있습니다. 확인하세요:
|
||||
|
||||
{{#ref}}
|
||||
../az-privilege-escalation/az-entraid-privesc/az-conditional-access-policies-mfa-bypass.md
|
||||
@@ -487,7 +487,7 @@ Get-AzureADGroup -ObjectId <id> | Get-AzureADGroupAppRoleAssignment | fl *
|
||||
Add-AzureADGroupMember -ObjectId <group_id> -RefObjectId <user_id> -Verbose
|
||||
```
|
||||
> [!WARNING]
|
||||
> 그룹은 동적일 수 있으며, 이는 기본적으로 **사용자가 특정 조건을 충족하면 그룹에 추가된다는 의미**입니다. 물론, 조건이 **사용자가** **제어할 수 있는** **속성**에 기반할 경우, 그는 이 기능을 악용하여 **다른 그룹에 들어갈 수 있습니다**.\
|
||||
> 그룹은 동적일 수 있으며, 이는 기본적으로 **사용자가 특정 조건을 충족하면 그룹에 추가된다는 의미**입니다. 물론, 조건이 **사용자가 제어할 수 있는 속성**에 기반할 경우, 그는 이 기능을 악용하여 **다른 그룹에 들어갈 수 있습니다**.\
|
||||
> 동적 그룹을 악용하는 방법은 다음 페이지를 확인하세요:
|
||||
|
||||
{{#ref}}
|
||||
@@ -735,6 +735,13 @@ az ad app owner list --id <id> --query "[].[displayName]" -o table
|
||||
az ad app list --show-mine
|
||||
# Get apps with generated secret or certificate
|
||||
az ad app list --query '[?length(keyCredentials) > `0` || length(passwordCredentials) > `0`].[displayName, appId, keyCredentials, passwordCredentials]' -o json
|
||||
# Get Global Administrators (full access over apps)
|
||||
az rest --method GET --url "https://graph.microsoft.com/v1.0/directoryRoles/1b2256f9-46c1-4fc2-a125-5b2f51bb43b7/members"
|
||||
# Get Application Administrators (full access over apps)
|
||||
az rest --method GET --url "https://graph.microsoft.com/v1.0/directoryRoles/1e92c3b7-2363-4826-93a6-7f7a5b53e7f9/members"
|
||||
# Get Cloud Applications Administrators (full access over apps)
|
||||
az rest --method GET --url "https://graph.microsoft.com/v1.0/directoryRoles/0d601d27-7b9c-476f-8134-8e7cd6744f02/members"
|
||||
|
||||
```
|
||||
{{#endtab }}
|
||||
|
||||
@@ -791,8 +798,8 @@ Get-AzureADApplication -ObjectId <id> | Get-AzureADApplicationOwner |fl *
|
||||
> [!NOTE]
|
||||
> 애플리케이션이 토큰을 요청할 때 자신의 신원을 증명하는 데 사용하는 비밀 문자열은 애플리케이션 비밀번호입니다.\
|
||||
> 따라서 이 **비밀번호**를 찾으면 **서비스 주체**로 **테넌트** **내부**에 접근할 수 있습니다.\
|
||||
> 이 비밀번호는 생성될 때만 볼 수 있습니다(변경할 수는 있지만 다시 얻을 수는 없습니다).\
|
||||
> **애플리케이션**의 **소유자**는 이를 **가짜로** 사용할 수 있도록 **비밀번호**를 추가할 수 있습니다.\
|
||||
> 이 비밀번호는 생성될 때만 볼 수 있습니다 (변경할 수는 있지만 다시 얻을 수는 없습니다).\
|
||||
> **애플리케이션**의 **소유자**는 이를 위해 **비밀번호**를 **추가**할 수 있습니다 (그래서 그가 이를 가장할 수 있습니다).\
|
||||
> 이러한 서비스 주체로의 로그인은 **위험한 것으로 표시되지 않으며** **MFA가 없습니다.**
|
||||
|
||||
Microsoft에 속하는 일반적으로 사용되는 App ID 목록을 찾는 것은 가능합니다 [https://learn.microsoft.com/en-us/troubleshoot/entra/entra-id/governance/verify-first-party-apps-sign-in#application-ids-of-commonly-used-microsoft-applications](https://learn.microsoft.com/en-us/troubleshoot/entra/entra-id/governance/verify-first-party-apps-sign-in#application-ids-of-commonly-used-microsoft-applications)
|
||||
@@ -922,7 +929,7 @@ For more information about Azure roles check:
|
||||
{{#tab name="az cli" }}
|
||||
|
||||
```bash
|
||||
# Entra ID 역할 템플릿 목록
|
||||
# Entra ID 역할 목록 템플릿
|
||||
az rest --method GET \
|
||||
--uri "https://graph.microsoft.com/v1.0/directoryRoleTemplates"
|
||||
|
||||
@@ -1022,7 +1029,7 @@ Get-Command -Module Microsoft.Graph.Identity.DirectoryManagement
|
||||
```bash
|
||||
# 장치 나열
|
||||
Get-AzureADDevice -All $true | fl *
|
||||
# 모든 활성 장치(오래된 장치가 아님) 나열
|
||||
# 모든 활성 장치 목록 (오래된 장치 제외)
|
||||
Get-AzureADDevice -All $true | ?{$_.ApproximateLastLogonTimeStamp -ne $null}
|
||||
# 모든 장치의 소유자 가져오기
|
||||
Get-AzureADDevice -All $true | Get-AzureADDeviceRegisteredOwner
|
||||
|
||||
Reference in New Issue
Block a user