diff --git a/src/pentesting-cloud/azure-security/az-basic-information/README.md b/src/pentesting-cloud/azure-security/az-basic-information/README.md index a98238ac0..71bc24997 100644 --- a/src/pentesting-cloud/azure-security/az-basic-information/README.md +++ b/src/pentesting-cloud/azure-security/az-basic-information/README.md @@ -10,7 +10,7 @@ - **다른 관리 그룹 또는 구독**을 포함할 수 있습니다. - 이를 통해 **RBAC 및 Azure Policy**와 같은 거버넌스 제어를 관리 그룹 수준에서 한 번 적용하고 그룹 내 모든 구독이 이를 **상속**받을 수 있습니다. -- **10,000 관리** 그룹을 단일 디렉터리에서 지원할 수 있습니다. +- **10,000개의 관리** 그룹을 단일 디렉터리에서 지원할 수 있습니다. - 관리 그룹 트리는 **최대 6단계 깊이**를 지원할 수 있습니다. 이 제한은 루트 수준이나 구독 수준을 포함하지 않습니다. - 각 관리 그룹 및 구독은 **하나의 부모**만 지원할 수 있습니다. - 여러 관리 그룹을 생성할 수 있지만 **루트 관리 그룹은 하나만 존재**합니다. @@ -21,7 +21,7 @@ ### Azure 구독 -- 리소스(가상 머신, 데이터베이스 등)를 실행하고 청구되는 또 다른 **논리적 컨테이너**입니다. +- 리소스(VM, DB 등)를 실행하고 청구되는 또 다른 **논리적 컨테이너**입니다. - 그 **부모**는 항상 **관리 그룹**이며(루트 관리 그룹일 수 있음) 구독은 다른 구독을 포함할 수 없습니다. - **하나의 Entra ID** 디렉터리만 신뢰합니다. - 구독 수준(또는 그 부모의 수준)에서 적용된 **권한**은 구독 내 모든 리소스에 **상속**됩니다. @@ -65,7 +65,7 @@ Entra 도메인 서비스는 **전통적인 Windows Active Directory 환경과 ### 사용자 - **새 사용자** -- 선택한 테넌트에서 이메일 이름 및 도메인 표시 +- 선택한 테넌트의 이메일 이름 및 도메인 표시 - 표시 이름 지정 - 비밀번호 지정 - 속성 지정(이름, 직책, 연락처 정보 등) @@ -79,7 +79,7 @@ Entra 도메인 서비스는 **전통적인 Windows Active Directory 환경과 [https://learn.microsoft.com/en-us/entra/fundamentals/users-default-permissions](https://learn.microsoft.com/en-us/entra/fundamentals/users-default-permissions)에서 확인할 수 있지만, 회원은 다음과 같은 작업을 수행할 수 있습니다: -- 모든 사용자, 그룹, 애플리케이션, 장치, 역할, 구독 및 그들의 공개 속성 읽기 +- 모든 사용자, 그룹, 애플리케이션, 장치, 역할, 구독 및 그들의 공개 속성을 읽을 수 있습니다. - 게스트 초대(_비활성화 가능_) - 보안 그룹 생성 - 숨겨지지 않은 그룹 멤버십 읽기 @@ -94,14 +94,14 @@ Entra 도메인 서비스는 **전통적인 Windows Active Directory 환경과 - **회원 (**[**문서**](https://learn.microsoft.com/en-gb/entra/fundamentals/users-default-permissions#restrict-member-users-default-permissions)**)** - 애플리케이션 등록: 기본 **예** -- 비관리 사용자에게 테넌트 생성 제한: 기본 **아니오** +- 비관리 사용자에게 테넌트를 생성하지 못하도록 제한: 기본 **아니오** - 보안 그룹 생성: 기본 **예** - Microsoft Entra 관리 포털에 대한 액세스 제한: 기본 **아니오** - 이는 포털에 대한 API 액세스를 제한하지 않습니다(웹만 해당) - 사용자가 LinkedIn과 작업 또는 학교 계정을 연결할 수 있도록 허용: 기본 **예** - 사용자가 로그인 상태를 유지하도록 표시: 기본 **예** - 사용자가 소유한 장치에 대한 BitLocker 키를 복구하지 못하도록 제한: 기본 아니오(장치 설정에서 확인) -- 다른 사용자 읽기: 기본 **예**(Microsoft Graph를 통해) +- 다른 사용자 읽기: 기본 **예** (Microsoft Graph를 통해) - **게스트** - **게스트 사용자 액세스 제한** 옵션: - **게스트 사용자는 회원과 동일한 액세스를 가집니다**. @@ -123,22 +123,22 @@ Entra 도메인 서비스는 **전통적인 Windows Active Directory 환경과 **2가지 유형의 그룹**이 있습니다: - **보안**: 이 유형의 그룹은 구성원에게 애플리케이션, 리소스에 대한 액세스를 부여하고 라이센스를 할당하는 데 사용됩니다. 사용자, 장치, 서비스 주체 및 다른 그룹이 구성원이 될 수 있습니다. -- **Microsoft 365**: 이 유형의 그룹은 협업을 위해 사용되며, 구성원에게 공유 사서함, 일정, 파일, SharePoint 사이트 등에 대한 액세스를 제공합니다. 그룹 구성원은 사용자만 가능합니다. +- **Microsoft 365**: 이 유형의 그룹은 협업을 위해 사용되며, 구성원에게 공유 메일박스, 캘린더, 파일, SharePoint 사이트 등에 대한 액세스를 제공합니다. 그룹 구성원은 사용자만 가능합니다. - 이는 EntraID 테넌트의 도메인을 가진 **이메일 주소**를 가집니다. **2가지 유형의 멤버십**이 있습니다: -- **할당됨**: 특정 구성원을 그룹에 수동으로 추가할 수 있습니다. +- **지정된**: 특정 구성원을 수동으로 그룹에 추가할 수 있습니다. - **동적 멤버십**: 규칙을 사용하여 멤버십을 자동으로 관리하며, 구성원 속성이 변경될 때 그룹 포함을 업데이트합니다. ### **서비스 주체** **서비스 주체**는 **애플리케이션**, 호스팅 서비스 및 자동화 도구가 Azure 리소스에 액세스하는 데 사용하기 위해 생성된 **아이덴티티**입니다. 이 액세스는 서비스 주체에 할당된 역할에 의해 **제한되며**, 어떤 리소스에 액세스할 수 있는지 및 어떤 수준에서 액세스할 수 있는지를 제어합니다. 보안상의 이유로, **사용자 아이덴티티로 로그인하는 것보다 자동화 도구와 함께 서비스 주체를 사용하는 것이 항상 권장됩니다**. -**비밀번호**(기본값), **인증서**를 생성하거나 제3자 플랫폼(예: Github Actions)에 대한 **연합 액세스**를 부여하여 **서비스 주체로 직접 로그인**할 수 있습니다. +**비밀번호**(기본값), **인증서**를 생성하거나 제3자 플랫폼(예: Github Actions)에 대한 **연합된** 액세스를 부여하여 **서비스 주체로 직접 로그인**할 수 있습니다. -- **비밀번호** 인증을 선택하는 경우(기본값), **생성된 비밀번호를 저장**해야 다시 액세스할 수 없습니다. -- 인증서 인증을 선택하는 경우, **애플리케이션이 개인 키에 대한 액세스를 가질 수 있도록 해야 합니다**. +- **비밀번호** 인증을 선택하는 경우(기본값), **생성된 비밀번호를 저장**해야 하며, 다시 액세스할 수 없습니다. +- 인증서 인증을 선택하는 경우, **애플리케이션이 개인 키에 대한 액세스를 가질 수 있도록** 해야 합니다. ### 애플리케이션 등록 @@ -148,11 +148,12 @@ Entra 도메인 서비스는 **전통적인 Windows Active Directory 환경과 1. **애플리케이션 ID (클라이언트 ID):** Azure AD에서 앱의 고유 식별자입니다. 2. **리디렉션 URI:** Azure AD가 인증 응답을 보내는 URL입니다. -3. **인증서, 비밀번호 및 연합 자격 증명:** 서비스 주체로 로그인하기 위해 비밀번호 또는 인증서를 생성하거나 연합 액세스를 부여할 수 있습니다(예: Github Actions). +3. **인증서, 비밀번호 및 연합 자격 증명:** 서비스 주체로 로그인하기 위해 비밀번호 또는 인증서를 생성하거나 이를 위해 연합된 액세스를 부여할 수 있습니다(예: Github Actions). +1. **인증서** 또는 **비밀번호**가 생성되면, **애플리케이션 ID**, **비밀번호** 또는 **인증서** 및 **테넌트**(도메인 또는 ID)를 알고 있는 사람이 CLI 도구로 **서비스 주체로 로그인**할 수 있습니다. 4. **API 권한:** 앱이 액세스할 수 있는 리소스 또는 API를 지정합니다. 5. **인증 설정:** 앱이 지원하는 인증 흐름을 정의합니다(예: OAuth2, OpenID Connect). 6. **서비스 주체**: 앱이 생성될 때 서비스 주체가 생성됩니다(웹 콘솔에서 생성된 경우) 또는 새 테넌트에 설치될 때 생성됩니다. -7. **서비스 주체**는 요청된 모든 권한을 얻습니다. +1. **서비스 주체**는 요청된 모든 권한을 받게 됩니다. ### 기본 동의 권한 @@ -160,8 +161,8 @@ Entra 도메인 서비스는 **전통적인 Windows Active Directory 환경과 - **사용자 동의 허용 안 함** - 모든 앱에 대해 관리자가 필요합니다. -- **검증된 게시자의 앱에 대해 선택된 권한에 대한 사용자 동의 허용(권장)** -- 모든 사용자는 "낮은 영향"으로 분류된 권한에 대해 동의할 수 있으며, 검증된 게시자의 앱 또는 이 조직에 등록된 앱에 대해 동의할 수 있습니다. +- **검증된 게시자, 내부 앱 및 선택된 권한만 요청하는 앱에 대한 사용자 동의 허용(권장)** +- 모든 사용자는 "낮은 영향"으로 분류된 권한만 요청하는 앱, 검증된 게시자의 앱 및 테넌트에 등록된 앱에 동의할 수 있습니다. - **기본** 낮은 영향 권한(낮은 영향으로 추가하려면 수락해야 함): - User.Read - 로그인 및 사용자 프로필 읽기 - offline_access - 사용자가 액세스할 수 있도록 허용한 데이터에 대한 액세스 유지 @@ -179,14 +180,14 @@ 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 서비스의 하나 이상의 인스턴스(여러 리소스)에 할당할 수 있습니다. 사용자 할당 관리형 아이덴티티의 경우, **아이덴티티는 이를 사용하는 리소스와 별도로 관리됩니다**. -관리형 아이덴티티는 서비스 주체에 연결된 **영구 자격 증명**(비밀번호 또는 인증서)을 생성하지 않습니다. +관리형 아이덴티티는 **영구 자격 증명**(비밀번호나 인증서와 같은)을 생성하지 않으며, 이에 액세스하는 서비스 주체에 연결되어 있습니다. ### 엔터프라이즈 애플리케이션 @@ -196,11 +197,11 @@ Azure Active Directory의 관리형 아이덴티티는 **애플리케이션의 ### 관리 단위 -관리 단위는 **조직의 특정 부분에 대한 역할의 권한을 부여할 수 있도록 합니다**. +관리 단위는 **조직의 특정 부분에 대한 역할의 권한을 부여할 수 있도록** 합니다. 예시: -- 시나리오: 회사는 지역 IT 관리자가 자신의 지역의 사용자만 관리하도록 하기를 원합니다. +- 시나리오: 한 회사가 지역 IT 관리자가 자신의 지역의 사용자만 관리하도록 하기를 원합니다. - 구현: - 각 지역에 대한 관리 단위 생성(예: "북미 AU", "유럽 AU"). - 각 지역의 사용자로 AU를 채웁니다. @@ -217,20 +218,20 @@ Azure Active Directory의 관리형 아이덴티티는 **애플리케이션의 - [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의 역할과 완전히 **독립적**입니다. 유일한 관계는 Entra ID에서 **전역 관리자** 역할을 가진 주체가 Azure에서 **사용자 액세스 관리자** 역할로 상승할 수 있다는 것입니다. - Entra ID 역할에서 **와일드카드를 사용할 수 없습니다**. ## Azure 역할 및 권한 -- **역할**은 **주체**에 **범위**를 두고 **할당**됩니다: `주체 -[HAS ROLE]->(범위)` +- **역할**은 **범위**에서 **주체**에 **할당**됩니다: `주체 -[HAS ROLE]->(범위)` - **그룹**에 할당된 **역할**은 그룹의 모든 **구성원**에 의해 **상속**됩니다. -- 역할이 할당된 범위에 따라, **역할**은 범위 컨테이너 내의 **다른 리소스**에 **상속**될 수 있습니다. 예를 들어, 사용자 A가 **구독**에 대한 **역할**을 가지고 있다면, 그는 그 **구독** 내의 모든 리소스 그룹과 **리소스 그룹 내의 모든 리소스**에 대해 그 **역할**을 가집니다. +- 역할이 할당된 범위에 따라, **역할**은 범위 컨테이너 내의 **다른 리소스**에 **상속**될 수 있습니다. 예를 들어, 사용자 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** 리소스에 대한 내장 역할의 두 가지 예를 확인하세요: @@ -238,7 +239,7 @@ Azure Active Directory의 관리형 아이덴티티는 **애플리케이션의 | ----------------------------------------------------------------------------------------------------------------------------------------- | ---------------------------------------------------------------- | ------------------------------------ | | [가상 머신 사용자 로그인](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) 목록을 확인하세요. @@ -246,7 +247,7 @@ Azure Active Directory의 관리형 아이덴티티는 **애플리케이션의 ### 사용자 정의 역할 - [**사용자 정의 역할**](https://learn.microsoft.com/en-us/azure/role-based-access-control/custom-roles)을 생성할 수도 있습니다. -- 이들은 범위 내에서 생성되지만, 역할은 여러 범위(관리 그룹, 구독 및 리소스 그룹)에 있을 수 있습니다. +- 이들은 범위 내에서 생성되며, 역할은 여러 범위(관리 그룹, 구독 및 리소스 그룹)에 있을 수 있습니다. - 사용자 정의 역할이 가질 모든 세분화된 권한을 구성할 수 있습니다. - 권한을 제외할 수 있습니다. - 제외된 권한이 있는 주체는 다른 곳에서 권한이 부여되더라도 이를 사용할 수 없습니다. @@ -254,8 +255,8 @@ Azure Active Directory의 관리형 아이덴티티는 **애플리케이션의 - 사용되는 형식은 JSON입니다. - `actions`는 리소스에 대한 관리 작업에 대한 권한을 나타내며, 리소스 정의 및 설정을 생성, 업데이트 또는 삭제하는 작업을 포함합니다. - `dataActions`는 리소스 내의 데이터 작업에 대한 권한으로, 리소스에 포함된 실제 데이터를 읽고, 쓰고, 삭제할 수 있도록 합니다. -- `notActions` 및 `notDataActions`는 역할에서 특정 권한을 제외하는 데 사용됩니다. 그러나 **이들은 권한을 거부하지 않습니다**. 다른 역할이 이를 부여하면 주체는 이를 가질 수 있습니다. -- `assignableScopes`는 역할을 할당할 수 있는 범위의 배열입니다(관리 그룹, 구독 또는 리소스 그룹과 같은). +- `notActions` 및 `notDataActions`는 역할에서 특정 권한을 제외하는 데 사용됩니다. 그러나 **이들은 권한을 거부하지 않습니다**. 다른 역할이 이를 부여하면 주체는 이를 가집니다. +- `assignableScopes`는 역할을 할당할 수 있는 범위의 배열입니다(관리 그룹, 구독 또는 리소스 그룹과 같은). 사용자 정의 역할에 대한 권한 JSON 예시: ```json @@ -289,16 +290,16 @@ Azure Active Directory의 관리형 아이덴티티는 **애플리케이션의 ``` ### Permissions order -- 리소스에 대한 **액세스 권한을 가지려면** 주체는 명시적인 역할이 부여되어야 하며 (어떤 방식으로든) **그 권한을 부여받아야 합니다**. -- 명시적인 **거부 할당은** 권한을 부여하는 역할보다 우선합니다. +- **주체가 리소스에 대한 접근 권한을 가지려면** 명시적인 역할이 부여되어야 하며 (어떤 방식으로든) **그 권한을 부여받아야 합니다**. +- 명시적인 **거부 할당은 권한을 부여하는 역할보다 우선합니다**.

https://link.springer.com/chapter/10.1007/978-1-4842-7325-8_10

### Global Administrator -Global Administrator는 **Entra ID 테넌트에 대한 완전한 제어 권한**을 부여하는 Entra ID의 역할입니다. 그러나 기본적으로 Azure 리소스에 대한 권한은 부여하지 않습니다. +Global Administrator는 **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)
@@ -309,33 +310,33 @@ 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. **효과**: 정책이 트리거될 때 발생하는 일을 지정합니다 (예: "Deny", "Audit", 또는 "Append"). +3. **이니셔티브**: 더 넓은 강제를 위해 그룹화된 정책 모음입니다. +4. **효과**: 정책이 트리거될 때 발생하는 일을 명시합니다 (예: "거부", "감사" 또는 "추가"). -**일부 예시:** +**몇 가지 예시:** 1. **특정 Azure 지역 준수 보장**: 이 정책은 모든 리소스가 특정 Azure 지역에 배포되도록 보장합니다. 예를 들어, 회사는 GDPR 준수를 위해 모든 데이터를 유럽에 저장하고 싶어할 수 있습니다. -2. **명명 기준 시행**: 정책은 Azure 리소스에 대한 명명 규칙을 시행할 수 있습니다. 이는 대규모 환경에서 리소스를 이름에 따라 쉽게 식별하고 조직하는 데 도움이 됩니다. +2. **명명 기준 강제 적용**: 정책은 Azure 리소스에 대한 명명 규칙을 강제할 수 있습니다. 이는 대규모 환경에서 리소스를 이름에 따라 쉽게 식별하고 조직하는 데 도움이 됩니다. 3. **특정 리소스 유형 제한**: 이 정책은 특정 유형의 리소스 생성을 제한할 수 있습니다. 예를 들어, 특정 VM 크기와 같은 비싼 리소스 유형의 생성을 방지하는 정책을 설정하여 비용을 제어할 수 있습니다. -4. **태그 정책 시행**: 태그는 리소스 관리에 사용되는 Azure 리소스와 연결된 키-값 쌍입니다. 정책은 모든 리소스에 특정 태그가 존재하거나 특정 값을 가져야 한다고 시행할 수 있습니다. 이는 비용 추적, 소유권 또는 리소스 분류에 유용합니다. -5. **리소스에 대한 공용 액세스 제한**: 정책은 특정 리소스(예: 스토리지 계정 또는 데이터베이스)가 공용 엔드포인트를 가지지 않도록 시행하여 조직의 네트워크 내에서만 액세스할 수 있도록 보장할 수 있습니다. -6. **보안 설정 자동 적용**: 정책은 모든 VM에 특정 네트워크 보안 그룹을 적용하거나 모든 스토리지 계정이 암호화를 사용하도록 보장하는 등 리소스에 보안 설정을 자동으로 적용하는 데 사용할 수 있습니다. +4. **태그 정책 강제 적용**: 태그는 리소스 관리에 사용되는 Azure 리소스와 연결된 키-값 쌍입니다. 정책은 모든 리소스에 대해 특정 태그가 존재해야 하거나 특정 값을 가져야 한다고 강제할 수 있습니다. 이는 비용 추적, 소유권 또는 리소스 분류에 유용합니다. +5. **리소스에 대한 공용 접근 제한**: 정책은 특정 리소스(예: 스토리지 계정 또는 데이터베이스)가 공용 엔드포인트를 가지지 않도록 강제하여 조직의 네트워크 내에서만 접근 가능하도록 보장할 수 있습니다. +6. **보안 설정 자동 적용**: 정책은 모든 VM에 특정 네트워크 보안 그룹을 적용하거나 모든 스토리지 계정이 암호화를 사용하도록 보장하는 등 리소스에 보안 설정을 자동으로 적용하는 데 사용될 수 있습니다. -Azure Policies는 Azure 계층의 모든 수준에 첨부될 수 있지만, **일반적으로 루트 관리 그룹**이나 다른 관리 그룹에서 사용됩니다. +Azure Policies는 Azure 계층의 모든 수준에 첨부될 수 있지만, **주로 루트 관리 그룹**이나 다른 관리 그룹에서 사용됩니다. Azure policy json example: ```json @@ -368,10 +369,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) diff --git a/src/pentesting-cloud/azure-security/az-unauthenticated-enum-and-initial-entry/az-oauth-apps-phishing.md b/src/pentesting-cloud/azure-security/az-unauthenticated-enum-and-initial-entry/az-oauth-apps-phishing.md index 9bae3d7c7..5deff1465 100644 --- a/src/pentesting-cloud/azure-security/az-unauthenticated-enum-and-initial-entry/az-oauth-apps-phishing.md +++ b/src/pentesting-cloud/azure-security/az-unauthenticated-enum-and-initial-entry/az-oauth-apps-phishing.md @@ -4,11 +4,11 @@ ## OAuth App Phishing -**Azure Applications**는 사용자가 애플리케이션에 동의할 때 사용할 수 있는 권한으로 구성됩니다(예: 디렉토리 열거, 파일 접근 또는 기타 작업 수행). 애플리케이션은 사용자를 대신하여 작동하므로, 애플리케이션이 관리 권한을 요청하더라도 **사용자가 해당 권한을 가지고 있지 않으면**, 애플리케이션은 **관리 작업을 수행할 수 없습니다**. +**Azure Applications**는 사용자가 애플리케이션에 동의할 때 사용할 수 있는 권한으로 구성됩니다(예: 디렉토리 열거, 파일 접근 또는 기타 작업 수행). 애플리케이션은 사용자를 대신하여 작동하므로, 애플리케이션이 관리 권한을 요청할 수 있더라도 **사용자가 해당 권한을 가지고 있지 않으면**, 애플리케이션은 **관리 작업을 수행할 수 없습니다**. ### App consent permissions -기본적으로 모든 **사용자는 앱에 동의할 수 있지만**, 이는 사용자가 **선택된 권한에 대해 검증된 게시자의 앱에만 동의할 수 있도록** 구성할 수 있으며, 심지어 **사용자가 애플리케이션에 동의할 권한을 제거**할 수도 있습니다. +기본적으로 모든 **사용자는 앱에 동의할 수 있습니다**, 하지만 이는 사용자가 **선택된 권한에 대해 검증된 게시자의 앱에만 동의할 수 있도록** 구성할 수 있으며, 심지어 **사용자가 애플리케이션에 동의할 권한을 제거**할 수도 있습니다.
@@ -20,7 +20,7 @@ ### 2 Types of attacks -- **Unauthenticated**: 외부 계정에서 **저위험 권한** `User.Read` 및 `User.ReadBasic.All`을 가진 애플리케이션을 생성하고 사용자를 피싱하면 디렉토리 정보에 접근할 수 있습니다. +- **Unauthenticated**: 외부 계정에서 **저위험 권한**인 `User.Read` 및 `User.ReadBasic.All`을 가진 애플리케이션을 생성하고 사용자를 피싱하면 디렉토리 정보에 접근할 수 있습니다. - 피싱된 사용자가 **외부 테넌트의 OAuth 앱을 수락할 수 있어야** 합니다. - 피싱된 사용자가 **모든 권한을 가진 어떤 앱에도 동의할 수 있는 관리자**인 경우, 애플리케이션은 **특권 권한을 요청할 수도 있습니다**. - **Authenticated**: 충분한 권한을 가진 주체를 손상시킨 후, **계정 내에서 애플리케이션을 생성하고** 특권 OAuth 권한을 수락할 수 있는 **특권 사용자**를 피싱합니다. @@ -59,17 +59,17 @@ az rest --method GET --url "https://graph.microsoft.com/v1.0/directoryRoles/0d60 ``` ## **공격 흐름 개요** -이 공격은 일반 회사를 목표로 하는 여러 단계를 포함합니다. 다음은 공격이 어떻게 전개될 수 있는지에 대한 설명입니다: +이 공격은 일반적인 회사를 목표로 하는 여러 단계를 포함합니다. 다음은 공격이 어떻게 전개될 수 있는지에 대한 설명입니다: -1. **도메인 등록 및 애플리케이션 호스팅**: 공격자는 신뢰할 수 있는 사이트를 닮은 도메인을 등록합니다. 예를 들어, "safedomainlogin.com"과 같은 도메인입니다. 이 도메인 아래에 악성 애플리케이션을 호스팅하기 위해 서브도메인(예: "companyname.safedomainlogin.com")이 생성됩니다. 이 애플리케이션은 인증 코드를 캡처하고 액세스 토큰을 요청하도록 설계되었습니다. +1. **도메인 등록 및 애플리케이션 호스팅**: 공격자는 신뢰할 수 있는 사이트를 닮은 도메인을 등록합니다. 예를 들어, "safedomainlogin.com"과 같은 도메인입니다. 이 도메인 아래에 서브도메인(예: "companyname.safedomainlogin.com")이 생성되어 권한 부여 코드를 캡처하고 액세스 토큰을 요청하는 애플리케이션을 호스팅합니다. 2. **Azure AD에서 애플리케이션 등록**: 공격자는 자신의 Azure AD 테넌트에 다중 테넌트 애플리케이션을 등록하고, 이를 목표 회사의 이름으로 명명하여 합법적으로 보이게 합니다. 그들은 애플리케이션의 리디렉션 URL을 악성 애플리케이션을 호스팅하는 서브도메인으로 설정합니다. 3. **권한 설정**: 공격자는 애플리케이션에 다양한 API 권한(예: `Mail.Read`, `Notes.Read.All`, `Files.ReadWrite.All`, `User.ReadBasic.All`, `User.Read`)을 설정합니다. 이러한 권한은 사용자가 부여하면 공격자가 사용자를 대신하여 민감한 정보를 추출할 수 있게 합니다. -4. **악성 링크 배포**: 공격자는 악성 애플리케이션의 클라이언트 ID를 포함하는 링크를 작성하고 이를 목표 사용자와 공유하여 그들이 동의를 부여하도록 속입니다. +4. **악성 링크 배포**: 공격자는 악성 애플리케이션의 클라이언트 ID를 포함하는 링크를 작성하고 이를 목표 사용자와 공유하여 그들이 동의를 하도록 속입니다. ## 예시 공격 1. **새 애플리케이션**을 등록합니다. 공격받는 디렉토리의 사용자라면 현재 디렉토리만 사용할 수 있으며, 외부 공격이라면 모든 디렉토리에 대해 사용할 수 있습니다(다음 이미지와 같이). -1. 또한 **리디렉션 URI**를 토큰을 얻기 위해 코드를 받을 예상 URL로 설정합니다(`http://localhost:8000/callback` 기본값). +1. 또한 **리디렉션 URI**를 토큰을 얻기 위해 코드를 받을 예상 URL로 설정합니다(`http://localhost:8000/callback`가 기본값입니다).
@@ -77,11 +77,11 @@ az rest --method GET --url "https://graph.microsoft.com/v1.0/directoryRoles/0d60
-3. API 권한을 선택합니다(예: `Mail.Read`, `Notes.Read.All`, `Files.ReadWrite.All`, `User.ReadBasic.All`, `User.Read`). +3. API 권한을 선택합니다(예: `Mail.Read`, `Notes.Read.All`, `Files.ReadWrite.All`, `User.ReadBasic.All`, `User.Read`)
-4. **권한을 요청하는 웹 페이지(**[**azure_oauth_phishing_example**](https://github.com/carlospolop/azure_oauth_phishing_example)**)**를 실행합니다: +4. **권한을 요청하는 웹 페이지 (**[**azure_oauth_phishing_example**](https://github.com/carlospolop/azure_oauth_phishing_example)**)**를 실행합니다: ```bash # From https://github.com/carlospolop/azure_oauth_phishing_example python3 azure_oauth_phishing_example.py --client-secret --client-id --scopes "email,Files.ReadWrite.All,Mail.Read,Notes.Read.All,offline_access,openid,profile,User.Read" @@ -123,7 +123,14 @@ https://graph.microsoft.com/v1.0/me/onenote/notebooks \ ### 피싱 포스트 익스플로잇 -요청된 권한에 따라 **테넌트의 다양한 데이터에 접근할 수 있을 수 있습니다** (사용자 목록, 그룹... 또는 설정 수정) 및 **사용자 정보** (파일, 노트, 이메일...). 그런 다음, 이러한 권한을 사용하여 해당 작업을 수행할 수 있습니다. +요청된 권한에 따라 **테넌트의 다양한 데이터에 접근할 수 있을 수 있습니다** (사용자 목록, 그룹... 또는 설정 수정) 및 **사용자 정보** (파일, 노트, 이메일...). 그런 다음 이러한 권한을 사용하여 해당 작업을 수행할 수 있습니다. + +### Entra ID 애플리케이션 관리자 + +어떻게든 Entra ID에서 애플리케이션을 관리할 수 있는 Entra ID 주체를 손상시켰다면, 사용자가 사용하는 애플리케이션이 있을 수 있습니다. 관리자는 **앱이 요청하는 권한을 수정하고 토큰을 훔치기 위해 새로운 허용된 리디렉션 주소를 추가할 수 있습니다**. +- 리디렉션 URI를 **추가하는 것이 가능**하다는 점에 유의하세요 (실제 URI를 삭제할 필요 없음) 그리고 공격자의 리디렉션 URI를 사용하여 HTTP 링크를 전송하면 사용자가 링크를 따를 때 인증이 자동으로 발생하고 공격자가 토큰을 받게 됩니다. +- 또한 앱이 사용자로부터 더 많은 권한을 얻기 위해 요청하는 권한을 변경하는 것도 가능하지만, 이 경우 사용자는 **프롬프트를 다시 수락해야 합니다** (이미 로그인한 경우에도). +- 이 공격을 수행하기 위해 공격자는 **애플리케이션 코드를 제어할 필요가 없습니다**. 그는 단지 새로운 URL을 **`redirect_uri`** 매개변수에 포함하여 사용자가 앱에 로그인하도록 링크를 보낼 수 있습니다. ### 애플리케이션 포스트 익스플로잇