Az - Basic Information
조직 계층 구조
관리 그룹
조직에 많은 Azure 구독이 있는 경우, 이러한 구독에 대한 액세스, 정책 및 준수를 효율적으로 관리할 방법이 필요할 수 있습니다. 관리 그룹은 구독 위의 거버넌스 범위를 제공합니다.
10,000개의 관리 그룹이 단일 디렉터리에서 지원될 수 있으며, 관리 그룹 트리는 최대 6단계 깊이를 지원할 수 있습니다.
문서에서: 각 디렉터리는 루트 관리 그룹이라고 불리는 단일 최상위 관리 그룹을 부여받습니다. 루트 관리 그룹은 모든 관리 그룹과 구독이 이를 포함하도록 계층 구조에 내장되어 있습니다. 이 루트 관리 그룹은 전역 정책 및 Azure 역할 할당이 디렉터리 수준에서 적용될 수 있도록 합니다. Azure AD 전역 관리자는 처음에 이 루트 그룹의 사용자 액세스 관리자 역할로 자신을 승격해야 합니다. 액세스를 승격한 후, 관리자는 계층을 관리하기 위해 다른 디렉터리 사용자 또는 그룹에 Azure 역할을 할당할 수 있습니다. 관리자로서, 루트 관리 그룹의 소유자로 자신의 계정을 할당할 수 있습니다.
루트 관리 그룹은 다른 관리 그룹과 달리 이동하거나 삭제할 수 없습니다.
관리 그룹은 구독 유형에 관계없이 대규모 기업 수준의 관리를 제공합니다. 그러나 단일 관리 그룹 내의 모든 구독은 동일한 Azure Active Directory (Azure AD) 테넌트를 신뢰해야 합니다.
Azure 구독
Azure에서 구독은 비즈니스 또는 기술 리소스를 프로비저닝하기 위한 논리적 컨테이너 역할을 합니다. 이 컨테이너는 가상 머신(VM), 데이터베이스 등과 같은 리소스의 세부 정보를 유지합니다. VM과 같은 Azure 리소스를 생성할 때, 연관된 구독이 지정됩니다. 이 구조는 역할 기반 액세스 제어 메커니즘을 활용하여 액세스 위임을 용이하게 합니다.
리소스 그룹
문서에서: 리소스 그룹은 Azure 솔루션을 위한 관련 리소스를 보유하는 컨테이너입니다. 리소스 그룹은 솔루션에 대한 모든 리소스를 포함하거나, 그룹으로 관리하고자 하는 리소스만 포함할 수 있습니다. 일반적으로 같은 생애 주기를 공유하는 리소스를 동일한 리소스 그룹에 추가하여 그룹으로 쉽게 배포, 업데이트 및 삭제할 수 있습니다.
모든 리소스는 리소스 그룹 내에 있어야 하며 오직 하나의 그룹에만 속할 수 있으며, 리소스 그룹이 삭제되면 그 안의 모든 리소스도 삭제됩니다.
관리 단위
문서에서: 관리 단위를 사용하면 조직을 원하는 단위로 세분화하고, 그 단위의 구성원만 관리할 수 있는 특정 관리자를 할당할 수 있습니다. 예를 들어, 대규모 대학의 각 학교의 관리자에게 권한을 위임하여 그들이 공학부에서만 액세스를 제어하고, 사용자를 관리하며, 정책을 설정할 수 있도록 할 수 있습니다.
사용자, 그룹 및 장치만 관리 단위의 구성원이 될 수 있습니다.
따라서 관리 단위는 일부 구성원을 포함하고, 다른 주체는 해당 관리 단위를 관리하는 권한을 부여받습니다.
Azure vs Azure AD vs Azure AD 도메인 서비스
Azure AD는 Azure 내의 서비스라는 점을 주목하는 것이 중요합니다. Azure는 Microsoft의 클라우드 플랫폼인 반면, Azure AD는 Azure의 기업 아이덴티티 서비스입니다. 또한, Azure AD는 Windows Active Directory와 다릅니다. 이는 완전히 다른 방식으로 작동하는 아이덴티티 서비스입니다. Windows Active Directory 환경에서 Azure에 도메인 컨트롤러를 실행하려면 Azure AD 도메인 서비스를 사용해야 합니다.
주체
Azure는 다양한 유형의 주체를 지원합니다:
사용자: 액세스할 수 있는 자격 증명을 가진 일반 사람.
그룹: 함께 관리되는 주체 그룹. 그룹에 부여된 권한은 구성원에게 상속됩니다.
서비스 주체/기업 애플리케이션: 애플리케이션, 호스팅 서비스 및 Azure 리소스에 액세스하기 위한 자동화 도구와 함께 사용하기 위해 생성된 아이덴티티입니다. 이 액세스는 서비스 주체에 할당된 역할에 의해 제한되며, 어떤 리소스에 액세스할 수 있는지 및 어떤 수준에서 액세스할 수 있는지를 제어합니다. 보안상의 이유로, 사용자 아이덴티티로 로그인하는 것보다 자동화 도구와 함께 서비스 주체를 사용하는 것이 항상 권장됩니다.
서비스 주체를 생성할 때 비밀번호 인증 또는 인증서 인증 중에서 선택할 수 있습니다.
비밀번호 인증을 선택하면 (기본값), 생성된 비밀번호를 저장해야 다시 액세스할 수 없습니다.
인증서 인증을 선택하면 애플리케이션이 개인 키에 대한 액세스 권한을 가져야 합니다.
관리된 아이덴티티 (메타데이터 자격 증명): Azure Active Directory의 관리된 아이덴티티는 애플리케이션의 아이덴티티를 자동으로 관리하는 솔루션을 제공합니다. 이러한 아이덴티티는 Azure Active Directory (Azure AD) 인증과 호환되는 리소스에 연결하기 위해 애플리케이션에서 사용됩니다. 관리된 아이덴티티를 활용함으로써, 애플리케이션은 자격 증명을 직접 처리할 필요 없이 Azure AD 토큰을 안전하게 사용할 수 있습니다. 관리된 아이덴티티에는 두 가지 유형이 있습니다:
시스템 할당. 일부 Azure 서비스는 서비스 인스턴스에서 직접 관리된 아이덴티티를 활성화할 수 있습니다. 시스템 할당 관리된 아이덴티티를 활성화하면 Azure AD에 아이덴티티가 생성됩니다. 이 아이덴티티는 해당 서비스 인스턴스의 생애 주기에 연결됩니다. 리소스가 삭제되면, Azure는 자동으로 아이덴티티를 삭제합니다. 설계상, 해당 Azure 리소스만 이 아이덴티티를 사용하여 Azure AD에서 토큰을 요청할 수 있습니다.
사용자 할당. 관리된 아이덴티티를 독립형 Azure 리소스로 생성할 수도 있습니다. 사용자 할당 관리된 아이덴티티를 생성하고 Azure 서비스의 하나 이상의 인스턴스(여러 리소스)에 할당할 수 있습니다. 사용자 할당 관리된 아이덴티티의 경우, 아이덴티티는 이를 사용하는 리소스와 별도로 관리됩니다.
역할 및 권한
역할은 주체에 할당됩니다: 주체 -[HAS ROLE]->(범위)
그룹에 할당된 역할은 그룹의 모든 구성원에게 상속됩니다.
역할이 할당된 범위에 따라, 역할은 범위 컨테이너 내의 다른 리소스에 상속될 수 있습니다. 예를 들어, 사용자 A가 구독에 역할을 가지고 있다면, 그는 그 구독 내의 모든 리소스 그룹과 리소스 그룹 내의 모든 리소스에 대해 그 역할을 가집니다.
클래식 역할
내장 역할
문서에서: Azure 역할 기반 액세스 제어 (Azure RBAC)에는 사용자, 그룹, 서비스 주체 및 관리된 아이덴티티에 할당할 수 있는 여러 Azure 내장 역할이 있습니다. 역할 할당은 Azure 리소스에 대한 액세스를 제어하는 방법입니다. 내장 역할이 조직의 특정 요구를 충족하지 않는 경우, Azure 사용자 정의 역할을 생성할 수 있습니다.
내장 역할은 의도된 리소스에만 적용됩니다. 예를 들어, 컴퓨트 리소스에 대한 내장 역할의 두 가지 예를 확인하세요:
이 역할은 관리 그룹, 구독 및 리소스 그룹과 같은 논리 컨테이너에 대해서도 할당될 수 있으며, 영향을 받는 주체는 해당 컨테이너 내의 리소스에 대해 역할을 갖게 됩니다.
모든 Azure 내장 역할 목록을 확인하세요.
모든 Azure AD 내장 역할 목록을 확인하세요.
사용자 정의 역할
Azure는 사용자가 필요한 권한으로 사용자 정의 역할을 생성할 수 있도록 허용합니다.
권한 거부
주체가 리소스에 대한 액세스를 가지려면 그에게 명시적인 역할이 부여되어야 합니다 (어떤 방식으로든) 그에게 그 권한을 부여합니다.
명시적인 거부 역할 할당은 권한을 부여하는 역할보다 우선합니다.
전역 관리자
전역 관리자 역할을 가진 사용자는 루트 관리 그룹에 대한 사용자 액세스 관리자 Azure 역할로 '승격'할 수 있는 능력을 가지고 있습니다. 이는 전역 관리자가 모든 Azure 구독 및 관리 그룹에 대한 액세스를 관리할 수 있음을 의미합니다. 이 승격은 페이지 하단에서 수행할 수 있습니다: https://portal.azure.com/#view/Microsoft_AAD_IAM/ActiveDirectoryMenuBlade/~/Properties
Azure 정책
Azure 정책은 Microsoft Azure의 규칙 및 규정 집합으로, 조직의 표준을 관리하고 시행하며 대규모로 준수를 평가하는 데 도움을 줍니다. 이러한 정책은 Azure 리소스에 대해 다양한 규칙을 시행하여, 해당 리소스가 기업 표준 및 서비스 수준 계약을 준수하도록 보장합니다.
Azure 정책은 클라우드 거버넌스 및 보안에 필수적이며, 리소스가 적절하고 효율적으로 사용되도록 하고, 외부 규정 및 내부 정책을 준수하도록 돕습니다. 몇 가지 예시:
특정 Azure 지역 준수 보장: 이 정책은 모든 리소스가 특정 Azure 지역에 배포되도록 보장합니다. 예를 들어, 회사는 GDPR 준수를 위해 모든 데이터를 유럽에 저장하도록 할 수 있습니다.
명명 기준 시행: 정책은 Azure 리소스에 대한 명명 규칙을 시행할 수 있습니다. 이는 대규모 환경에서 리소스를 쉽게 식별하고 조직하는 데 도움이 됩니다.
특정 리소스 유형 제한: 이 정책은 특정 유형의 리소스 생성을 제한할 수 있습니다. 예를 들어, 특정 VM 크기와 같은 비싼 리소스 유형의 생성을 방지하는 정책을 설정하여 비용을 제어할 수 있습니다.
태그 정책 시행: 태그는 Azure 리소스와 관련된 키-값 쌍으로, 리소스 관리를 위해 사용됩니다. 정책은 모든 리소스에 대해 특정 태그가 존재해야 하거나 특정 값을 가져야 한다고 시행할 수 있습니다. 이는 비용 추적, 소유권 또는 리소스 분류에 유용합니다.
리소스에 대한 공개 액세스 제한: 정책은 특정 리소스(예: 스토리지 계정 또는 데이터베이스)가 공개 엔드포인트를 가지지 않도록 시행하여, 조직의 네트워크 내에서만 접근 가능하도록 보장할 수 있습니다.
보안 설정 자동 적용: 정책은 모든 VM에 특정 네트워크 보안 그룹을 적용하거나 모든 스토리지 계정이 암호화를 사용하도록 보장하는 등 리소스에 보안 설정을 자동으로 적용하는 데 사용될 수 있습니다.
Azure 정책은 Azure 계층의 모든 수준에 첨부될 수 있지만, 루트 관리 그룹이나 다른 관리 그룹에서 일반적으로 사용됩니다.
권한 범위
Azure에서 권한은 계층의 어떤 부분에도 할당될 수 있습니다. 여기에는 관리 그룹, 구독, 리소스 그룹 및 개별 리소스가 포함됩니다. 권한은 할당된 엔터티의 포함된 리소스에 의해 상속됩니다.
이 계층 구조는 액세스 권한의 효율적이고 확장 가능한 관리를 가능하게 합니다.
Azure RBAC vs ABAC
RBAC (역할 기반 액세스 제어)는 이전 섹션에서 이미 본 것입니다: 주체에 역할을 할당하여 리소스에 대한 액세스를 부여하는 것입니다. 그러나 경우에 따라 더 세분화된 액세스 관리를 제공하거나 수백 개의 역할 할당 관리를 단순화하고 싶을 수 있습니다.
Azure ABAC (속성 기반 액세스 제어)는 특정 작업의 맥락에서 속성을 기반으로 한 역할 할당 조건을 추가하여 Azure RBAC를 기반으로 구축됩니다. _역할 할당 조건_은 역할 할당에 선택적으로 추가할 수 있는 추가 검사로, 더 세분화된 액세스 제어를 제공합니다. 조건은 역할 정의 및 역할 할당의 일부로 부여된 권한을 필터링합니다. 예를 들어, 객체를 읽기 위해 특정 태그를 가져야 한다는 조건을 추가할 수 있습니다. 조건을 사용하여 특정 리소스에 대한 액세스를 명시적으로 거부할 수는 없습니다.
기본 사용자 권한
기본 사용자는 AzureAD의 일부 부분을 열거할 수 있는 기본 권한을 가집니다:
모든 사용자, 그룹, 애플리케이션, 장치, 역할, 구독 및 그들의 공개 속성을 읽기
게스트 초대 (비활성화 가능)
보안 그룹 생성
숨겨지지 않은 그룹 구성원 읽기
소유한 그룹에 게스트 추가
새 애플리케이션 생성 (비활성화 가능)
Azure에 최대 50개의 장치 추가 (비활성화 가능)
전체 사용자의 기본 권한 목록을 문서에서 확인할 수 있습니다. 또한, 해당 목록에서 게스트 기본 권한 목록도 확인할 수 있습니다.
Azure 리소스를 열거하기 위해 사용자는 권한의 명시적 부여가 필요합니다.
특권 아이덴티티 관리 (PIM)
Azure의 특권 아이덴티티 관리(PIM)는 Azure Active Directory 및 Azure에서 특권 액세스를 관리, 제어 및 모니터링하는 도구입니다. 이는 즉시 및 시간 제한 특권 액세스, 승인 워크플로우 시행 및 추가 인증 요구를 제공하여 보안을 강화합니다. 이 접근 방식은 필요할 때만 특정 기간 동안 상승된 권한이 부여되도록 하여 무단 액세스의 위험을 최소화합니다.
인증 토큰
OIDC에서 사용되는 세 가지 유형의 토큰이 있습니다:
액세스 토큰: 클라이언트가 리소스 서버에 리소스에 액세스하기 위해 이 토큰을 제시합니다. 이는 특정 사용자, 클라이언트 및 리소스 조합에만 사용할 수 있으며 만료될 때까지 취소할 수 없습니다 - 기본적으로 1시간입니다. 이를 사용하여 탐지하기는 어렵습니다.
ID 토큰: 클라이언트가 인증 서버로부터 이 토큰을 받습니다. 이 토큰은 사용자에 대한 기본 정보를 포함합니다. 이는 특정 사용자 및 클라이언트 조합에 바인딩됩니다.
리프레시 토큰: 액세스 토큰과 함께 클라이언트에 제공됩니다. 새 액세스 및 ID 토큰을 얻는 데 사용됩니다. 이는 특정 사용자 및 클라이언트 조합에 바인딩되며 취소할 수 있습니다. 기본 만료는 비활성 리프레시 토큰에 대해 90일이며 활성 토큰에 대해서는 만료가 없습니다.
조건부 액세스에 대한 정보는 JWT 내에 저장됩니다. 따라서 허용된 IP 주소에서 토큰을 요청하면, 해당 IP가 토큰에 저장되며, 이후 허용되지 않은 IP에서 리소스에 액세스하기 위해 해당 토큰을 사용할 수 있습니다.
다양한 방법으로 액세스 토큰을 요청하고 로그인하는 방법을 배우려면 다음 페이지를 확인하세요:
가장 일반적인 API 엔드포인트는 다음과 같습니다:
Azure 리소스 관리자 (ARM): management.azure.com
Microsoft Graph: graph.microsoft.com (더 이상 사용되지 않는 Azure AD Graph는 graph.windows.net)
참고 문헌
Last updated
