Az - Basic Information
Last updated
Last updated
AWS 해킹 배우기 및 연습하기:HackTricks Training AWS Red Team Expert (ARTE) GCP 해킹 배우기 및 연습하기: HackTricks Training GCP Red Team Expert (GRTE)
다른 관리 그룹 또는 구독을 포함할 수 있습니다.
이를 통해 관리 그룹 수준에서 RBAC 및 Azure 정책과 같은 거버넌스 제어를 적용하고 그룹 내 모든 구독에서 상속받을 수 있습니다.
10,000개의 관리 그룹을 단일 디렉터리에서 지원할 수 있습니다.
관리 그룹 트리는 최대 6단계 깊이를 지원할 수 있습니다. 이 제한은 루트 수준이나 구독 수준을 포함하지 않습니다.
각 관리 그룹 및 구독은 하나의 부모만 지원할 수 있습니다.
여러 관리 그룹을 생성할 수 있지만 루트 관리 그룹은 하나만 존재합니다.
루트 관리 그룹은 모든 다른 관리 그룹 및 구독을 포함하며 이동하거나 삭제할 수 없습니다.
단일 관리 그룹 내의 모든 구독은 동일한 Entra ID 테넌트를 신뢰해야 합니다.
리소스(가상 머신, 데이터베이스 등)를 실행하고 청구되는 또 다른 논리적 컨테이너입니다.
그 부모는 항상 관리 그룹이며(루트 관리 그룹일 수 있음) 구독은 다른 구독을 포함할 수 없습니다.
하나의 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 솔루션을 위한 관련 리소스를 보유하는 컨테이너입니다. 리소스 그룹에는 솔루션에 대한 모든 리소스가 포함될 수 있으며, 또는 그룹으로 관리하고자 하는 리소스만 포함될 수 있습니다. 일반적으로 같은 생애 주기를 공유하는 리소스를 동일한 리소스 그룹에 추가하여 그룹으로 쉽게 배포, 업데이트 및 삭제할 수 있습니다.
모든 리소스는 리소스 그룹 내에 있어야 하며 오직 하나의 그룹에만 속할 수 있으며, 리소스 그룹이 삭제되면 그 안의 모든 리소스도 삭제됩니다.
Azure의 모든 리소스는 이를 식별하는 Azure 리소스 ID를 가지고 있습니다.
Azure 리소스 ID의 형식은 다음과 같습니다:
/subscriptions/{subscriptionId}/resourceGroups/{resourceGroupName}/providers/{resourceProviderNamespace}/{resourceType}/{resourceName}
구독 ID 12345678-1234-1234-1234-123456789012 아래의 리소스 그룹 myResourceGroup에 있는 가상 머신 이름이 myVM인 경우 Azure 리소스 ID는 다음과 같습니다:
/subscriptions/12345678-1234-1234-1234-123456789012/resourceGroups/myResourceGroup/providers/Microsoft.Compute/virtualMachines/myVM
Azure는 Microsoft의 종합적인 클라우드 컴퓨팅 플랫폼으로, 다양한 서비스를 제공합니다. 여기에는 가상 머신, 데이터베이스, 인공지능 및 스토리지가 포함됩니다. Azure는 애플리케이션을 호스팅하고 관리하며, 확장 가능한 인프라를 구축하고, 클라우드에서 현대적인 작업 부하를 실행하는 기반 역할을 합니다. Azure는 개발자와 IT 전문가가 애플리케이션과 서비스를 원활하게 생성, 배포 및 관리할 수 있는 도구를 제공하여 스타트업부터 대기업까지 다양한 요구를 충족합니다.
Entra ID는 인증, 권한 부여 및 사용자 액세스 제어를 처리하도록 설계된 클라우드 기반 아이덴티티 및 액세스 관리 서비스입니다. 이는 Office 365, Azure 및 많은 타사 SaaS 애플리케이션과 같은 Microsoft 서비스에 대한 안전한 액세스를 제공합니다. SSO(단일 로그인), MFA(다단계 인증), 조건부 액세스 정책 등의 기능을 제공합니다.
Entra 도메인 서비스는 전통적인 Windows Active Directory 환경과 호환되는 관리형 도메인 서비스를 제공하여 Entra ID의 기능을 확장합니다. LDAP, Kerberos 및 NTLM과 같은 레거시 프로토콜을 지원하여 조직이 클라우드에서 이전 애플리케이션을 마이그레이션하거나 실행할 수 있도록 하며, 온프레미스 도메인 컨트롤러를 배포할 필요가 없습니다. 이 서비스는 중앙 집중식 관리를 위한 그룹 정책도 지원하여 레거시 또는 AD 기반 작업 부하가 현대 클라우드 환경과 공존해야 하는 시나리오에 적합합니다.
신규 사용자
선택한 테넌트에서 이메일 이름 및 도메인 표시
표시 이름 지정
비밀번호 지정
속성 지정(이름, 직책, 연락처 정보 등)
기본 사용자 유형은 "회원"입니다.
외부 사용자
초대할 이메일 및 표시 이름 지정(비 Microsoft 이메일 가능)
속성 지정
기본 사용자 유형은 "게스트"입니다.
https://learn.microsoft.com/en-us/entra/fundamentals/users-default-permissions에서 확인할 수 있지만, 구성원은 다음과 같은 작업을 수행할 수 있습니다:
모든 사용자, 그룹, 애플리케이션, 장치, 역할, 구독 및 그들의 공개 속성 읽기
게스트 초대(비활성화 가능)
보안 그룹 생성
숨겨지지 않은 그룹 멤버십 읽기
소유한 그룹에 게스트 추가
새 애플리케이션 생성(비활성화 가능)
Azure에 최대 50개의 장치 추가(비활성화 가능)
Azure 리소스를 나열하려면 사용자가 권한을 명시적으로 부여받아야 합니다.
구성원 (문서)
애플리케이션 등록: 기본 예
비관리 사용자에게 테넌트 생성 제한: 기본 아니오
보안 그룹 생성: 기본 예
Microsoft Entra 관리 포털에 대한 액세스 제한: 기본 아니오
이는 포털에 대한 API 액세스를 제한하지 않습니다(웹만 해당)
사용자가 LinkedIn과 작업 또는 학교 계정을 연결할 수 있도록 허용: 기본 예
사용자가 로그인 상태를 유지하도록 표시: 기본 예
사용자가 소유한 장치에 대한 BitLocker 키를 복구하지 못하도록 제한: 기본 아니오(장치 설정에서 확인)
다른 사용자 읽기: 기본 예 (Microsoft Graph를 통해)
게스트
게스트 사용자 액세스 제한
게스트 사용자는 구성원과 동일한 액세스를 가집니다 기본적으로 모든 구성원 사용자 권한을 게스트 사용자에게 부여합니다.
게스트 사용자는 디렉터리 객체의 속성과 멤버십에 대한 제한된 액세스를 가집니다(기본) 기본적으로 게스트 액세스는 자신의 사용자 프로필로만 제한됩니다. 다른 사용자 및 그룹 정보에 대한 액세스는 더 이상 허용되지 않습니다.
게스트 사용자 액세스는 자신의 디렉터리 객체의 속성과 멤버십으로 제한됩니다 가장 제한적인 것입니다.
게스트 초대 가능
조직의 누구나 게스트 사용자를 초대할 수 있으며, 게스트 및 비관리자 포함(가장 포괄적) - 기본
구성원 사용자 및 특정 관리자 역할에 할당된 사용자는 게스트 사용자 초대 가능
특정 관리자 역할에 할당된 사용자만 게스트 사용자 초대 가능
조직의 누구도 게스트 사용자를 초대할 수 없습니다(가장 제한적)
외부 사용자 퇴장: 기본 참
외부 사용자가 조직을 떠날 수 있도록 허용
기본적으로 제한되더라도 권한이 부여된 사용자(구성원 및 게스트)는 이전 작업을 수행할 수 있습니다.
2가지 유형의 그룹이 있습니다:
보안: 이 유형의 그룹은 구성원에게 애플리케이션, 리소스에 대한 액세스를 부여하고 라이센스를 할당하는 데 사용됩니다. 사용자, 장치, 서비스 주체 및 다른 그룹이 구성원이 될 수 있습니다.
Microsoft 365: 이 유형의 그룹은 협업을 위해 사용되며, 구성원에게 공유 사서함, 일정, 파일, SharePoint 사이트 등에 대한 액세스를 제공합니다. 그룹 구성원은 사용자만 될 수 있습니다.
이는 EntraID 테넌트의 도메인을 가진 이메일 주소를 가집니다.
2가지 유형의 멤버십이 있습니다:
할당됨: 특정 구성원을 그룹에 수동으로 추가할 수 있습니다.
동적 멤버십: 규칙을 사용하여 멤버십을 자동으로 관리하며, 구성원 속성이 변경될 때 그룹 포함을 업데이트합니다.
서비스 주체는 애플리케이션, 호스팅 서비스 및 자동화 도구가 Azure 리소스에 액세스하는 데 사용하기 위해 생성된 아이덴티티입니다. 이 액세스는 서비스 주체에 할당된 역할에 의해 제한되며, 어떤 리소스에 액세스할 수 있는지 및 어떤 수준에서 액세스할 수 있는지를 제어합니다. 보안상의 이유로, 사용자 아이덴티티로 로그인하는 것보다 자동화 도구와 함께 서비스 주체를 사용하는 것이 항상 권장됩니다.
비밀번호(기본값), 인증서를 생성하거나 제3자 플랫폼(예: Github Actions)에 대한 연합 액세스를 부여하여 서비스 주체로 직접 로그인할 수 있습니다.
비밀번호 인증을 선택하는 경우(기본값), 생성된 비밀번호를 저장해야 다시 액세스할 수 없습니다.
인증서 인증을 선택하는 경우, 애플리케이션이 개인 키에 대한 액세스를 가질 수 있도록 해야 합니다.
애플리케이션 등록은 애플리케이션이 Entra ID와 통합하고 작업을 수행할 수 있도록 하는 구성입니다.
애플리케이션 ID (클라이언트 ID): Azure AD에서 앱의 고유 식별자입니다.
리디렉션 URI: Azure AD가 인증 응답을 보내는 URL입니다.
인증서, 비밀번호 및 연합 자격 증명: 서비스 주체로 로그인하기 위해 비밀번호 또는 인증서를 생성하거나 연합 액세스를 부여할 수 있습니다(예: Github Actions).
인증서 또는 비밀번호가 생성되면, 애플리케이션 ID, 비밀번호 또는 인증서 및 테넌트(도메인 또는 ID)를 알고 있는 사람이 서비스 주체로 로그인할 수 있습니다.
API 권한: 앱이 액세스할 수 있는 리소스 또는 API를 지정합니다.
인증 설정: 앱의 지원되는 인증 흐름을 정의합니다(예: OAuth2, OpenID Connect).
서비스 주체: 앱이 생성될 때 서비스 주체가 생성됩니다(웹 콘솔에서 생성된 경우) 또는 새 테넌트에 설치될 때 생성됩니다.
서비스 주체는 요청된 모든 권한을 받게 됩니다.
애플리케이션에 대한 사용자 동의
사용자 동의 허용 안 함
모든 앱에 대해 관리자가 필요합니다.
검증된 게시자의 앱에 대해 선택된 권한에 대한 사용자 동의 허용(권장)
모든 사용자는 "낮은 영향"으로 분류된 권한에 대해 동의할 수 있으며, 검증된 게시자의 앱 또는 이 조직에 등록된 앱에 대해 동의할 수 있습니다.
기본 낮은 영향 권한(낮은 영향으로 추가하려면 수락해야 함):
User.Read - 로그인 및 사용자 프로필 읽기
offline_access - 사용자가 액세스 권한을 부여한 데이터에 대한 액세스 유지
openid - 사용자를 로그인시키기
profile - 사용자의 기본 프로필 보기
email - 사용자의 이메일 주소 보기
앱에 대한 사용자 동의 허용(기본)
모든 사용자는 조직의 데이터에 액세스하기 위해 모든 앱에 동의할 수 있습니다.
관리자 동의 요청: 기본 아니오
사용자는 동의할 수 없는 앱에 대해 관리자 동의를 요청할 수 있습니다.
예인 경우: 동의 요청을 할 수 있는 사용자, 그룹 및 역할을 지정할 수 있습니다.
사용자가 이메일 알림 및 만료 알림을 받을지 여부도 구성합니다.
Azure Active Directory의 관리형 아이덴티티는 애플리케이션의 아이덴티티를 자동으로 관리하는 솔루션을 제공합니다. 이러한 아이덴티티는 Azure Active Directory(Azure AD) 인증과 호환되는 리소스에 연결하기 위해 애플리케이션에서 사용됩니다. 이를 통해 애플리케이션이 메타데이터 서비스에 연락하여 Azure에서 지정된 관리형 아이덴티티로 작업을 수행하기 위한 유효한 토큰을 얻을 수 있으므로 클라우드 자격 증명을 코드에 하드코딩할 필요가 없습니다.
관리형 아이덴티티에는 두 가지 유형이 있습니다:
시스템 할당. 일부 Azure 서비스는 서비스 인스턴스에서 직접 관리형 아이덴티티를 활성화할 수 있습니다. 시스템 할당 관리형 아이덴티티를 활성화하면, 서비스 주체가 리소스가 위치한 구독에서 신뢰하는 Entra ID 테넌트에 생성됩니다. 리소스가 삭제되면, Azure는 자동으로 아이덴티티를 삭제합니다.
사용자 할당. 사용자가 관리형 아이덴티티를 생성할 수도 있습니다. 이러한 아이덴티티는 구독 내의 리소스 그룹 내에서 생성되며, 서비스 주체가 구독에서 신뢰하는 EntraID에 생성됩니다. 그런 다음 관리형 아이덴티티를 Azure 서비스의 하나 이상의 인스턴스(여러 리소스)에 할당할 수 있습니다. 사용자 할당 관리형 아이덴티티의 경우, 아이덴티티는 이를 사용하는 리소스와 별도로 관리됩니다.
관리형 아이덴티티는 서비스 주체에 연결된 영구 자격 증명(비밀번호 또는 인증서)을 생성하지 않습니다.
이는 서비스 주체를 필터링하고 할당된 애플리케이션을 확인하기 위한 Azure의 테이블입니다.
또 다른 유형의 "애플리케이션"이 아닙니다. Azure에는 "엔터프라이즈 애플리케이션"이라는 객체가 없으며, 이는 서비스 주체, 애플리케이션 등록 및 관리형 아이덴티티를 확인하기 위한 추상화일 뿐입니다.
관리 단위는 조직의 특정 부분에 대한 역할의 권한을 부여할 수 있도록 합니다.
예시:
시나리오: 한 회사가 지역 IT 관리자가 자신의 지역의 사용자만 관리하도록 하기를 원합니다.
구현:
각 지역에 대한 관리 단위 생성(예: "북미 AU", "유럽 AU").
각 지역의 사용자로 AU를 채웁니다.
AU는 사용자, 그룹 또는 장치를 포함할 수 있습니다.
AU는 동적 멤버십을 지원합니다.
AU는 AU를 포함할 수 없습니다.
관리자 역할 할당:
지역 IT 직원에게 해당 지역의 AU에 범위가 지정된 "사용자 관리자" 역할을 부여합니다.
결과: 지역 IT 관리자는 다른 지역에 영향을 주지 않고 자신의 지역 내 사용자 계정을 관리할 수 있습니다.
Entra ID를 관리하기 위해 Entra ID 주체에 할당할 수 있는 내장 역할이 있습니다.
가장 권한이 높은 역할은 전역 관리자입니다.
역할 설명에서 세부 권한을 확인할 수 있습니다.
역할은 주체에 범위를 두고 할당됩니다: 주체 -[HAS ROLE]->(범위)
그룹에 할당된 역할은 그룹의 모든 구성원에게 상속됩니다.
역할이 할당된 범위에 따라, 역할은 범위 컨테이너 내의 다른 리소스에 상속될 수 있습니다. 예를 들어, 사용자 A가 구독에 대한 역할을 가지고 있다면, 그는 그 구독 내의 모든 리소스 그룹과 리소스 그룹 내의 모든 리소스에 대해 그 역할을 가지게 됩니다.
소유자
모든 리소스에 대한 전체 액세스
다른 사용자에 대한 액세스 관리 가능
모든 리소스 유형
기여자
모든 리소스에 대한 전체 액세스
액세스 관리 불가
모든 리소스 유형
읽기 전용
• 모든 리소스 보기
모든 리소스 유형
사용자 액세스 관리자
모든 리소스 보기
다른 사용자에 대한 액세스 관리 가능
모든 리소스 유형
문서에서: Azure 역할 기반 액세스 제어(Azure RBAC)에는 사용자, 그룹, 서비스 주체 및 관리형 아이덴티티에 할당할 수 있는 여러 Azure 내장 역할이 있습니다. 역할 할당은 Azure 리소스에 대한 액세스를 제어하는 방법입니다. 내장 역할이 조직의 특정 요구를 충족하지 않는 경우, Azure 사용자 정의 역할을 생성할 수 있습니다.
내장 역할은 의도된 리소스에만 적용됩니다. 예를 들어, Compute 리소스에 대한 내장 역할의 두 가지 예를 확인하세요:
이 역할은 관리 그룹, 구독 및 리소스 그룹과 같은 논리 컨테이너에 대해서도 할당될 수 있으며, 영향을 받는 주체는 해당 컨테이너 내의 리소스에 대해 역할을 갖게 됩니다.
모든 Azure 내장 역할 목록을 확인하세요.
모든 Entra ID 내장 역할 목록을 확인하세요.
사용자 정의 역할 생성도 가능합니다.
이는 범위 내에서 생성되며, 역할은 여러 범위(관리 그룹, 구독 및 리소스 그룹)에 있을 수 있습니다.
사용자 정의 역할이 가질 모든 세부 권한을 구성할 수 있습니다.
권한을 제외할 수 있습니다.
제외된 권한이 있는 주체는 다른 곳에서 권한이 부여되더라도 이를 사용할 수 없습니다.
와일드카드를 사용할 수 있습니다.
사용되는 형식은 JSON입니다.
actions는 리소스에 대한 제어 작업을 위한 것입니다.
dataActions는 객체 내의 데이터에 대한 권한입니다.
사용자 정의 역할에 대한 권한 JSON 예시:
리소스에 대한 접근 권한을 가지기 위해 주체는 그에게 명시적으로 역할이 부여되어야 하며 (어떤 방식으로든) 그 권한을 부여받아야 합니다.
명시적인 거부 역할 할당이 권한을 부여하는 역할보다 우선합니다.
Global Administrator는 Entra ID 테넌트에 대한 완전한 제어 권한을 부여하는 Entra ID의 역할입니다. 그러나 기본적으로 Azure 리소스에 대한 권한은 부여하지 않습니다.
Global Administrator 역할을 가진 사용자는 Root Management Group에서 User Access Administrator Azure 역할로 '승격'할 수 있는 능력을 가지고 있습니다. 따라서 Global Administrators는 모든 Azure 구독 및 관리 그룹에서 접근을 관리할 수 있습니다. 이 승격은 페이지 하단에서 수행할 수 있습니다: https://portal.azure.com/#view/Microsoft_AAD_IAM/ActiveDirectoryMenuBlade/~/Properties
Azure Policies는 조직이 리소스가 특정 기준 및 준수 요구 사항을 충족하도록 돕는 규칙입니다. 이들은 Azure의 리소스에 대한 설정을 시행하거나 감사할 수 있게 해줍니다. 예를 들어, 허가되지 않은 지역에서 가상 머신의 생성을 방지하거나 모든 리소스에 특정 태그가 있어 추적할 수 있도록 보장할 수 있습니다.
Azure Policies는 선제적입니다: 비준수 리소스의 생성이나 변경을 중단할 수 있습니다. 또한 반응적으로, 기존의 비준수 리소스를 찾아 수정할 수 있습니다.
정책 정의: 허용되거나 요구되는 사항을 명시하는 JSON으로 작성된 규칙입니다.
정책 할당: 특정 범위(예: 구독, 리소스 그룹)에 정책을 적용하는 것입니다.
이니셔티브: 더 넓은 시행을 위해 그룹화된 정책 모음입니다.
효과: 정책이 트리거될 때 발생하는 일을 명시합니다 (예: "거부", "감사" 또는 "추가").
몇 가지 예시:
특정 Azure 지역 준수 보장: 이 정책은 모든 리소스가 특정 Azure 지역에 배포되도록 보장합니다. 예를 들어, 회사는 GDPR 준수를 위해 모든 데이터를 유럽에 저장하도록 보장할 수 있습니다.
명명 기준 시행: 정책은 Azure 리소스에 대한 명명 규칙을 시행할 수 있습니다. 이는 대규모 환경에서 리소스를 이름에 따라 조직하고 쉽게 식별하는 데 도움이 됩니다.
특정 리소스 유형 제한: 이 정책은 특정 유형의 리소스 생성을 제한할 수 있습니다. 예를 들어, 특정 VM 크기와 같은 비싼 리소스 유형의 생성을 방지하는 정책을 설정하여 비용을 제어할 수 있습니다.
태그 정책 시행: 태그는 리소스 관리에 사용되는 Azure 리소스와 연결된 키-값 쌍입니다. 정책은 모든 리소스에 특정 태그가 존재하거나 특정 값을 가져야 한다고 시행할 수 있습니다. 이는 비용 추적, 소유권 또는 리소스 분류에 유용합니다.
리소스에 대한 공용 접근 제한: 정책은 특정 리소스(예: 스토리지 계정 또는 데이터베이스)가 공용 엔드포인트를 가지지 않도록 시행하여 조직의 네트워크 내에서만 접근할 수 있도록 보장할 수 있습니다.
보안 설정 자동 적용: 정책은 모든 VM에 특정 네트워크 보안 그룹을 적용하거나 모든 스토리지 계정이 암호화를 사용하도록 보장하는 등 리소스에 보안 설정을 자동으로 적용하는 데 사용할 수 있습니다.
Azure Policies는 Azure 계층의 모든 수준에 첨부될 수 있지만, 일반적으로 루트 관리 그룹이나 다른 관리 그룹에서 사용됩니다.
Azure policy json example:
Azure에서 권한은 계층의 어떤 부분에도 할당될 수 있습니다. 여기에는 관리 그룹, 구독, 리소스 그룹 및 개별 리소스가 포함됩니다. 권한은 할당된 엔터티의 리소스에 의해 상속됩니다.
이 계층 구조는 접근 권한의 효율적이고 확장 가능한 관리를 가능하게 합니다.
RBAC(역할 기반 접근 제어)는 우리가 이전 섹션에서 이미 본 것입니다: 리소스에 대한 접근을 부여하기 위해 주체에 역할을 할당하는 것입니다. 그러나 경우에 따라 더 세분화된 접근 관리를 제공하거나 수백 개의 역할 할당 관리를 단순화하고 싶을 수 있습니다.
Azure ABAC(속성 기반 접근 제어)는 특정 작업의 맥락에서 속성을 기반으로 한 역할 할당 조건을 추가하여 Azure RBAC를 기반으로 합니다. _역할 할당 조건_은 더 세분화된 접근 제어를 제공하기 위해 역할 할당에 선택적으로 추가할 수 있는 추가 검사입니다. 조건은 역할 정의 및 역할 할당의 일부로 부여된 권한을 필터링합니다. 예를 들어, 객체를 읽기 위해 특정 태그가 있어야 한다는 조건을 추가할 수 있습니다. 조건을 사용하여 특정 리소스에 대한 접근을 명시적으로 거부할 수는 없습니다.
Learn & practice AWS Hacking:HackTricks Training AWS Red Team Expert (ARTE) Learn & practice GCP Hacking: HackTricks Training GCP Red Team Expert (GRTE)
