Azure AZ-104 공부하기 2. Azure 내 ID 및 거버넌스 관리

 

이전 글을 보려면 아래 링크를 클릭하세요~

Azure AZ-104 공부하기 1. Azure 관리자 필수 조건

https://domdom.tistory.com/766

Azure AZ-104 공부하기 1. Azure 관리자 필수 조건

 

 

 

✅ 1. Microsoft Entra ID 란? 

• 클라우드 기반 사용자 인증 및 접근 관리 서비스
• Active Directory Domain Services(AD DS), 흔히 그냥 Active Directory라고 불리는 것은 Microsoft가 만든 네트워크 디렉터리 서비스로, 회사나 조직 내에서 사용자, 컴퓨터, 그룹, 그리고 네트워크 리소스(프린터, 파일 서버 등)를 중앙에서 관리하고 조직화하는 시스템임.
• Microsoft Entra ID는 PaaS(서비스형 플랫폼) 제품으로, 클라우드에서 Microsoft가 관리하는 디렉터리 서비스. 고객이 소유하고 관리하는 핵심 인프라에 속하지 않으며 고객이 직접 서버나 인프라를 관리하지 않아도 되기 때문에 유지 관리에 드는 리소스가 절감됩니다.
• AD DS에서 제공하지 않는 다단계 인증(MFA), ID 보호, 셀프 서비스 암호 재설정 같은 추가 기능도 제공합니다.
• 조직과 개인이 클라우드 기반 리소스에 더 안전하게 접근할 수 있도록 돕습니다.
• 별도의 Azure 서비스로 제공되며, 새 Azure 구독에는 기본 무료 계층이 포함되어 있습니다.
• Microsoft 365, Microsoft Intune 같은 Microsoft Online 비즈니스 서비스를 구독하면, 모든 무료 기능을 사용할 수 있는 Microsoft Entra ID가 자동으로 제공됩니다.
• 더 고급 ID 관리 기능은 유료 버전의 Microsoft Entra ID에서 제공되며, Microsoft 365 구독에 포함된 인스턴스에도 일부 기능이 자동 포함됩니다.

 

1-1. Microsoft Entra 테넌트

• Microsoft Entra ID는 다중 테넌트이며 개별 디렉터리 인스턴스 간의 격리를 보장하기 위해 특별히 구현되었습니다.
• 세계에서 가장 큰 다중 테넌트 디렉터리로, 100만 개의 디렉터리 서비스 인스턴스를 호스트하고 있으며 매주 10억 건의 인증 요청이 이루어지고 있습니다.
• 테넌트라는 용어는 일반적으로 각각 Microsoft Entra ID를 사용하는 Microsoft 365, Intune 또는 Azure와 같은 Microsoft 클라우드 기반 서비스 구독에 등록한 회사 또는 조직을 의미하지만, 기술적인 관점에서는 개별 Microsoft Entra 인스턴스를 말합니다.
• Azure 구독 내에서 여러 Microsoft Entra 테넌트를 만들 수 있습니다.
• Azure 구독은 하나의 Microsoft Entra 테넌트에만 연결되어야 합니다. 이 연결을 통해 해당 테넌트 내 사용자, 그룹, 애플리케이션에 Azure 리소스 접근 권한을 줄 수 있습니다.
• 각 테넌트에는 고유한 기본 도메인 이름이 자동으로 할당됩니다. Azure 구독을 만드는 데 사용하는 Microsoft 계정 이름에서 파생되거나 보통 테넌트 생성 시 지정하는 접두사 + onmicrosoft.com 형태입니다.
• 조직은 필요에 따라 이 기본 도메인 외에 사용자 지정 도메인 이름을 추가할 수 있습니다. 보통 회사가 실제로 소유한 도메인 이름을 사용합니다. Microsoft Entra 테넌트는 사용자, 그룹, 애플리케이션 등 Microsoft Entra 자원에 대한 보안 경계와 컨테이너 역할을 합니다. 하나의 Microsoft Entra 테넌트는 여러 개의 Azure 구독을 지원할 수 있습니다.
  여러 테넌트를 만들어 서로 영향을 주지 않고 기능을 테스트하거나 관리하는 것도 가능합니다.

1-2. Microsoft Entra 스키마

• AD DS에 비해 적은 종류의 개체(객체)만 포함합니다. 예를 들어, 컴퓨터 클래스를 포함하지 않고 대신 디바이스 클래스만 포함합니다.
• 디바이스를 Microsoft Entra에 조인하는 과정은 AD DS에서 컴퓨터를 조인하는 것과는 다릅니다. Microsoft Entra 스키마도 쉽게 확장 가능하며, 확장한 내용도 언제든 되돌릴 수 있습니다.
• 기존 AD DS의 컴퓨터 도메인 멤버 자격 관련 지원이 부족하므로, Microsoft Entra ID를 이용해 GPO(그룹 정책 개체)와 같은 전통적인 관리 방법으로 컴퓨터/사용자를 관리할 수 없습니다. 대신 Microsoft Entra ID는 최신 관리 방식(예: 클라우드 중심 관리)을 제공합니다.
• 사용자, 디바이스, 애플리케이션 데이터를 저장 및 관리하고, 인증과 권한 부여 서비스를 제공하는 것입니다. 이러한 기능은 Microsoft 365 같은 클라우드 서비스와 긴밀히 연동되며, 수백만 사용자를 지원하는 강력한 ID 공급자 역할을 합니다.
• Microsoft Entra ID에는 AD DS의 OU(조직 구성 단위) 클래스를 포함하지 않으므로, AD DS에서처럼 OU를 계층적으로 만들어 그룹 정책이나 위임 관리를 하는 건 불가능합니다. 하지만 OU는 주로 정책 범위 지정에 사용되므로, 그룹 멤버십을 통해 유사한 관리가 가능합니다.
• Microsoft Entra ID에서 애플리케이션 관련 개체는 두 가지로 나뉩니다:
  1. Application 클래스: 애플리케이션의 정의(설명)를 담고 있음
  2. servicePrincipal 클래스: 각 Microsoft Entra 테넌트에서 그 애플리케이션 인스턴스를 설정함
• 이 분리는 한 테넌트에서 애플리케이션을 정의하고, 여러 테넌트에서 각각 별도의 서비스 주체 개체를 만들어 공유할 수 있도록 해줍니다. Microsoft Entra ID는 애플리케이션을 테넌트에 등록할 때 자동으로 해당 서비스 주체 개체를 생성합니다.

✅ 2. Microsoft Entra ID 및 Active Directory Domain Services 비교 

• AD DS는 일반적으로 디렉터리 서비스로 여겨지지만, AD CS(Active Directory 인증서 서비스), AD LDS(Active Directory Lightweight Directory Services), AD FS(Active Directory Federation Services), AD RMS(Active Directory Rights Management Services)를 포함하는 Windows Active Directory 기술 제품군의 구성 요소 중 하나일 뿐입니다.
• Azure 가상 머신에 AD DS를 배포하여 온-프레미스 AD DS에 대한 스케일링 성능과 가용성을 사용할 수 있습니다. 그러나 Azure 가상 머신에 AD DS를 배포해도 Microsoft Entra ID는 사용되지 않습니다.
• Microsoft Entra ID는 주로 ID 솔루션으로, HTTP(포트 80) 및 HTTPS(포트 443) 통신을 사용하여 인터넷 기반 애플리케이션용으로 설계되었습니다.
  Microsoft Entra ID는 다중 테넌트 디렉터리 서비스입니다.
• Microsoft Entra ID는 개발자에게 다른 ID 공급자 또는 온-프레미스 AD DS를 사용하여 Azure의 애플리케이션에 대한 중앙 집중식 인증 및 권한 부여를 제공합니다. Microsoft Entra ID는 Facebook, Google 서비스, Yahoo 또는 Microsoft 클라우드 서비스와 같은 애플리케이션을 사용할 때 사용자에게 SSO 환경을 제공할 수 있습니다.

구분Active Directory Domain Services (AD DS)Microsoft Entra ID

기본 개념	물리적 또는 가상 서버에 배포되는 Windows Server 기반 디렉터리 서비스	클라우드 기반 다중 테넌트 ID 관리 서비스
디렉터리 구조(사용자 및 그룹)	계층적(X.500 기반) 구조	평면(플랫) 구조, OU 및 GPO 없음
리소스 검색 방식	DNS(Domain Name System) 사용	클라우드 기반 REST API 사용
쿼리 프로토콜	LDAP(Lightweight Directory Access Protocol) 호출을 사용하여 AD DS를 쿼리하고 관리	LDAP 미지원, HTTP/HTTPS 기반 REST API 사용
인증 프로토콜	Kerberos 주로 사용	SAML, WS-Federation, OpenID Connect 사용, OAuth로 권한 부여
관리 도구	조직 구성 단위(OU), 그룹 정책 객체(GPO)	OU, GPO 미지원, 그룹 멤버십으로 관리
컴퓨터 관리	컴퓨터 객체 포함, 도메인 가입된 컴퓨터 관리	디바이스 객체는 포함하지만, 컴퓨터 객체와 도메인 가입 개념 없음
트러스트(신뢰) 관계	도메인 간 트러스트 지원	페더레이션 서비스 포함, Facebook 등 타사 서비스와 페더레이션 가능
배포 방식	온-프레미스 또는 Azure VM에 배포 가능	완전한 클라우드 서비스, Azure VM에 배포 불가
사용 대상	주로 온-프레미스 네트워크 환경	클라우드 및 인터넷 기반 애플리케이션 환경

2-1. Microsoft Entra ID P1 및 P2 계획 비교

• Microsoft Entra ID P1 또는 P2 계층은 무료 및 Office 365 버전과 비교해 추가 기능을 제공합니다. 그러나 프리미엄 버전에는 사용자 프로비저닝당 추가 비용이 필요합니다.
• Microsoft Entra ID P1 또는 P2는 두 가지 버전으로 제공됩니다. 추가 라이선스를 구매하거나 Microsoft Enterprise Mobility + Security의 일부로 조달할 수 있습니다. 여기에는 Azure Information Protection 및 Intune에 대한 라이선스도 포함됩니다.
• Microsoft는 Microsoft Entra ID P2 버전의 전체 기능을 체험할 수 있는 평가판 기간을 제공합니다.

기능설명Microsoft Entra ID P1Microsoft Entra ID P2

셀프 서비스 그룹 관리	사용자에게 그룹을 만들고 관리할 수 있는 권한이 부여되는 그룹 관리를 간소화합니다. 최종 사용자는 다른 그룹에 가입 요청을 생성할 수 있으며 그룹 소유자는 요청을 승인하고 그룹의 멤버 자격을 유지할 수 있습니다.	사용자가 그룹 생성 및 관리 권한 부여, 멤버 가입 요청 및 승인 가능	포함
고급 보안 보고서 및 경고	비정상과 일관성 없는 액세스 패턴에 대한 고급 보고서를 보여 주는 상세 로그를 확인하여 액세스를 모니터링하고 보호. 기계 학습 기반이며 액세스 보안을 개선하고 잠재적 위협에 대응	기계 학습 기반 보안 보고서 및 경고 제공	포함
다단계 인증 (MFA)	온-프레미스 애플리케이션(VPN[가상 사설망], RADIUS 등을 사용), Azure, Microsoft 365, Dynamics 365, 타사 Microsoft Entra 갤러리 애플리케이션에서 작동. Microsoft Outlook과 같이 브라우저에 기반하지 않은 상용 앱에서는 작동하지 않음.	온-프레미스, Azure, Microsoft 365 등 다양한 환경에서 지원	포함
Microsoft Identity Manager(MIM) 라이선싱	Microsoft Entra ID P1 또는 P2와 통합하여 하이브리드 ID 솔루션을 제공. 여러 온-프레미스 인증 저장소를 Microsoft Entra ID와 연결할 수 있습니다. 이는 온-프레미스 LOB(기간 업무) 애플리케이션과 Saas 솔루션에 일관성 있는 경험을 제공	하이브리드 ID 솔루션 통합 제공	포함
서비스 수준 계약(SLA)	서비스의 가용성이 99.9% 이상 보장. 동일한 SLA가 Microsoft Entra Basic에 적용됩니다.	99.9% 가용성 보장	99.9% 가용성 보장
셀프 서비스 암호 재설정 (쓰기 저장 사용)	쓰기 저장을 사용하여 암호 재설정. Active Directory 온-프레미스 암호 정책을 따릅니다.	지원	지원
Cloud App Discovery	가장 자주 사용되는 클라우드 기반 애플리케이션을 검색함.	가장 자주 사용하는 클라우드 앱 검색 기능	포함
조건부 액세스	디바이스나 그룹, 위치를 기반으로 하는 조건부 액세스. 여러 기준에 따라 중요한 리소스에 대한 조건부 액세스를 구성할 수 있습니다.	디바이스, 그룹, 위치 기반 조건부 액세스 설정 가능	포함
Microsoft Entra Connect Health	Microsoft Entra ID에 대한 운영 인사이트를 얻을 수 있습니다. 경고, 성능 카운터, 사용 패턴, 구성 설정과 함께 작동하며 Microsoft Entra Connect Health 포털에서 수집된 정보를 제공합니다.	운영 인사이트 및 경고 제공	포함
Microsoft Entra ID 보호	사용자 계정을 모니터링하고 보호하기 위한 향상된 기능제공. 사용자 위험 정책 및 로그인 정책을 정의할 수 있습니다. 또한 사용자의 동작을 검토하고 사용자에게 위험에 대한 플래그를 지정할 수 있습니다.	지원 안됨	사용자 계정 위험 정책, 로그인 정책, 위험 플래그 지정 등 제공
Privileged Identity Management	관리자와 같은 권한 있는 사용자에 대한 추가 보안 수준을 구성할 수 있습니다. 영구 및 임시 관리자를 정의합니다. 또한 누군가가 관리 권한을 사용하여 일부 작업을 수행하려고 할 때마다 활성화되는 정책 워크플로를 정의합니다.	지원 안됨	관리자 권한 관리 및 워크플로우 정책 정의 가능

✅ 3. Microsoft Entra Domain Services 검사 

• 기존 LOB 애플리케이션 사용 방식: 기간업무(LOB) 앱을 도메인에 가입된 PC나 디바이스에 설치해 사용함. AD DS(온-프레미스 Active Directory) 기반 자격 증명으로 인증하고, 그룹 정책(GPO) 으로 설정을 관리함.
  -> Azure로 옮기려는 경우 문제점: 인증 기능이 없으면 앱이 작동 안 함. VPN 연결로 온프레미스 AD DS에 연결하거나 Azure에 도메인 컨트롤러 VM을 배포해야하는데, 둘다 비용 증가와 관리 복잡성을 초래한다.
• 해결책은 Microsoft Entra Domain Services : AD DS 없이도 Azure에서 도메인 기능(도메인 가입, GPO, Kerberos 인증 등)을 제공하는 클라우드 서비스임.
• Microsoft Entra ID는 로컬 AD DS와 통합될 수 있으므로 Microsoft Entra Connect를 구현하면 사용자는 온-프레미스 AD DS와 Microsoft Entra Domain Services 모두에서 조직 자격 증명을 활용할 수 있습니다.
  AD DS를 로컬에 배포하지 않은 경우에도 Microsoft Entra Domain Services를 클라우드 전용 서비스로 사용하도록 선택할 수 있습니다.
  이를 통해 온-프레미스 또는 클라우드에 단일 도메인 컨트롤러를 배포할 필요 없이 로컬로 배포된 AD DS에서와 유사한 기능을 사용할 수 있습니다.
  모든 온-프레미스 사용자 및 서비스가 Microsoft Entra ID의 도메인 서비스를 사용할 수 있도록 이 가상 네트워크에 대해 Microsoft Entra Domain Services를 사용하도록 설정할 수 있습니다.
• 🔐 관리자: 관리자가 도메인 컨트롤러를 직접 관리, 업데이트, 모니터링할 필요가 없습니다. → 관리가 쉬워짐.
  관리자가 Active Directory 복제본을 배포하고 관리할 필요가 없습니다. (별도 서버 관리나 AD 복제 필요 없음)
  Microsoft Entra ID가 관리하는 도메인에 대해서는 도메인 관리자 또는 엔터프라이즈 관리자 그룹이 필요하지 않습니다.

🔹 제한 사항

1. 기본 컴퓨터 Active Directory 개체만 지원됩니다.
2. Microsoft Entra Domain Services 도메인에 대한 스키마를 확장하는 것은 불가능합니다. (AD 스키마 확장 불가능)
3. OU(조직 구성 단위) 구조는 수평적이며 중첩된 OU는 현재 지원되지 않습니다.
4. 기본으로 제공되는 GPO(그룹 정책 개체)가 있으며 컴퓨터와 사용자 계정에 대해 존재합니다.
5. 기본 제공 GPO를 사용하는 OU를 대상으로 할 수 없습니다. 또한 WMI(Windows Management Instrumentation) 필터 또는 보안 그룹 필터링을 사용할 수 없습니다.

• Microsoft Entra Domain Services를 사용하면 LDAP, NTLM 또는 Kerberos 프로토콜을 사용하는 애플리케이션을 온-프레미스 인프라에서 클라우드로 자유롭게 마이그레이션할 수 있습니다. (LDAP, NTLM, Kerberos 지원 → 기존 앱과도 호환됨)
• 클라우드의 도메인 컨트롤러 또는 로컬 인프라에 대한 VPN이 없어도 Microsoft SQL Server나 Microsoft SharePoint Server와 같은 애플리케이션을 VM에서 사용하거나 Azure IaaS에 배포할 수도 있습니다.

Azure Portal을 사용하여 Microsoft Entra Domain Services를 사용하도록 설정할 수 있습니다. 이 서비스는 디렉터리 크기에 따라 시간당 요금이 청구됩니다.

✅ 4. Azure 사용자 계정 생성, 구성, 관리 

• 사용자 계정에는 로그온 프로세스에서 사용자를 인증하는 데 필요한 모든 정보가 포함됩니다. 인증되면 Microsoft Entra ID에서 액세스 토큰을 작성합니다. 액세스 토큰은 사용자에게 권한을 부여하고 액세스할 수 있는 리소스 및 해당 리소스로 수행할 수 있는 작업을 결정합니다.
• Azure Portal에서 Microsoft Entra ID 대시보드를 사용하여 사용자 개체 작업을 수행합니다. 한 번에 하나의 디렉터리만 사용할 수 있습니다. 디렉터리 + 구독 패널을 사용하여 디렉터리를 전환할 수 있습니다.
• 일반적으로 Microsoft Entra ID는 다음 세 가지 방법으로 사용자를 정의합니다.

사용자 유형설명출처특징

클라우드 ID	Microsoft Entra ID에만 존재하는 계정	Microsoft Entra ID 또는 외부 Microsoft Entra 디렉터리	직접 생성 및 관리 주 디렉터리에서 삭제 시 계정도 제거됨
디렉터리 동기화된 ID	온프레미스 Active Directory에서 동기화된 계정	Windows Server AD	Microsoft Entra Connect를 통해 동기화됨 실제 계정은 온프레미스에 있음
게스트 사용자	외부 사용자 (다른 클라우드, Xbox 계정 등)	초대된 사용자	외부 계약자/공급업체에 적합 더 이상 필요 없을 시 삭제 가능

4-1. 삭제된 사용자 복원 또는 제거

• 사용자를 삭제하면 30일 동안 계정이 일시 중단된 상태로 유지됩니다. 30일이라는 기간 동안 사용자는 모든 속성과 함께 계정을 복원할 수 있습니다. 30일 기간이 지나면 영구 삭제 프로세스가 자동으로 시작됩니다.
• Microsoft Entra ID 사용자 인터페이스를 사용하여 복원 가능한 사용자를 보거나, 삭제된 사용자를 복원하거나, 사용자를 영구적으로 삭제할 수 있습니다.
• 사용자를 복원하거나 영구히 삭제하려면 다음 역할 중 하나가 있어야 합니다.

1. 전역 관리자
2. 파트너 계층 1 지원
3. 파트너 계층 2 지원
4. 사용자 관리자

4-2. 그룹 생성, 구성, 관리

• 그룹을 사용하면 리소스 소유자(또는 Microsoft Entra 디렉터리 소유자)가 일일이 사용자에게 따로따로 설정할 필요 없이, 그룹의 모든 멤버에게 액세스 권한을 할당할 수 있습니다. 특정 팀이나 부서 단위로 그룹을 만들어 해당 그룹에만 권한을 주면, 사용자 관리가 훨씬 간편해집니다. 사용자가 근무하는 부서, 직함 등의 규칙을 기반으로 멤버 자격을 정의하는 기능을 지원합니다.
• 그룹에는 두 가지 유형이 있습니다:
  1. 보안 그룹: 가장 일반적인 그룹 유형. 특정 리소스(예: 애플리케이션, 파일 등)에 대한 접근 권한을 사용자들에게 부여할 때 사용합니다. 각 구성원에게 개별적으로 사용 권한을 추가하는 대신, 특정 보안 정책에 접근할 수 있는 보안 그룹을 만들고, 이 그룹에 속한 모든 사용자에게 같은 권한을 부여할 수 있습니다. 이 옵션을 사용하려면 Microsoft Entra 관리자가 필요합니다.
  2. Microsoft 365 그룹: 공유 사서함, 일정, 파일, SharePoint 사이트 등에 대한 액세스 권한을 여러 구성원에게 부여하여 협업 기회를 제공합니다. 협업용 그룹이며, 조직 외부 사용자에게도 접근 권한을 줄 수 있습니다. 이 옵션은 일반사용자와 관리자가 모두 사용할 수 있습니다.
• 🔄 멤버십유형(그룹에 사용자를 추가하는 방식): 개별 구성원이 그룹에 추가되는 방법을 지정합니다. 두 가지 유형은 다음과 같습니다.
  1. 할당됨(Assigned): 관리자가 직접 사용자를 선택해서 수동으로 그룹에 추가합니다. 비교적 단순하지만 인원이 많아지면 관리가 번거로울 수 있습니다.
  2. 동적(Dynamic): 규칙을 설정하면, 해당 조건에 맞는 사용자가 자동으로 그룹에 추가됩니다. 보안 그룹 또는 Microsoft 365 그룹이며 차이점은 해당 구성원이 규칙에 의해 제어된다는 것입니다. (예: "부서가 '인사팀'인 사람은 자동으로 HR 그룹에 포함"). 보안 그룹이나 Microsoft 365 그룹 모두에서 사용할 수 있습니다. 단, 사용자 정보가 잘못 입력되면 의도하지 않게 그룹에 포함될 수 있습니다. 따라서 **정확한 사용자 정보 관리(프로비저닝)**가 중요합니다.

✅ 5. 디바이스 등록 구성 및 관리

• 요즘은 다양한 형태의 디바이스(노트북, 스마트폰, 태블릿 등)가 널리 사용되고 있고, 개인 디바이스를 업무에 사용하는 BYOD(Bring Your Own Device) 문화도 확산되고 있습니다. 이런 환경에서 IT 담당자는 두 가지 상반된 과제를 동시에 해결해야 합니다:
  1. 사용자가 언제 어디서나 어떤 디바이스로든 편리하게 일할 수 있도록 지원하는 것
  2. 회사의 중요한 데이터와 시스템을 안전하게 보호하는 것
• 이를 위해 먼저 필요한 것은 디바이스를 등록하고 관리하는 것입니다. IT 관리자는 Microsoft Intune 같은 도구를 통해 디바이스의 고유 정보를 관리하여 해당 디바이스가 조직의 보안 정책과 규정 준수를 충족하는지 확인해야 합니다. Microsoft Entra ID를 사용하면 이러한 디바이스를 통해 어디서나 디바이스, 앱 및 서비스에 대한 Single Sign-On을 사용할 수 있습니다.

🔐 디바이스 관리를 위한 도구

1. Microsoft Intune: 디바이스 등록과 보안 정책 적용을 자동화할 수 있는 클라우드 기반 도구입니다. 이 도구를 통해 디바이스가 신뢰할 수 있는 상태인지 점검하고, 기준에 맞지 않으면 접근을 차단할 수도 있습니다.
2. Microsoft Entra ID: Microsoft Entra ID를 사용하면 이러한 디바이스를 통해 어디서나 디바이스, 앱 및 서비스에 대한 Single Sign-On을 사용할 수 있습니다. 등록된 디바이스는 Microsoft Entra ID를 통해 조직의 앱, 서비스에 자동 로그인(SSO: Single Sign-On)할 수 있습니다. 즉, 사용자는 한 번 로그인하면 여러 시스템을 추가 인증 없이 사용할 수 있어 편리함을 유지하고, 관리자는 디바이스 기준으로 접근 제어 및 보안 유지가 가능합니다.

5-1. Microsoft Entra 등록 디바이스

• 사용자가 개인 디바이스(BYOD)나 모바일 디바이스를 이용해 회사 리소스에 접근할 수 있도록 도와주는 기능입니다. 사용자는 개인 디바이스를 사용하여 조직의 Microsoft Entra ID 제어 리소스에 액세스할 수 있습니다.
• 디바이스에 로그인하지 않아도 Microsoft Entra ID에 등록이 가능합니다. 즉, 사용자는 디바이스에 개인 계정(로컬 계정)으로 로그인하면서, 회사 리소스에 접근할 때만 Microsoft Entra 계정을 연결합니다. 이렇게 연결된 디바이스는 자동으로 SSO(Single Sign-On) 기능을 지원하고, 조건부 액세스 정책에 따라 접근이 제한될 수 있습니다.
• 디바이스 로그인 옵션: 최종 사용자 로컬 자격 증명, 암호, Windows Hello, PIN 생체 인식
• 관리자는 Microsoft Intune과 같은 MDM(모바일 디바이스 관리) 도구를 사용하여 등록된 디바이스를 보호하고 설정 제어할 수 있습니다. MDM은 스토리지를 암호화하고, 암호 복잡성을 유지하고, 보안 소프트웨어를 업데이트해야 하는 등 조직에서 필요한 구성을 적용하는 수단을 제공합니다.
• Microsoft Entra ID 등록: 사용자가 회사 앱에 처음 접속할 때 자동으로 등록되기도 하고, 업무용 애플리케이션에 처음 액세스할 때 또는 Windows 10 설정 메뉴를 이용해 직접 수동으로 등록할 수도 있습니다.

5-2. Microsoft Entra 조인 디바이스

• 회사가 클라우드 기반 환경을 중심으로 IT 시스템을 운영하고자 할 때 사용하는 방식입니다. 클라우드 리소스뿐 아니라 사내 시스템(온-프레미스)에도 접근할 수 있습니다.
• 디바이스에 조직 계정으로 로그인해야 하며, 해당 디바이스는 Microsoft Entra ID에 등록됩니다. 즉, 회사가 해당 디바이스를 완전히 소유하고 관리하며, 개인 계정이 아닌 회사 계정 중심으로 동작합니다.

Microsoft Entra 조인설명

기본 대상 그룹	클라우드 전용 및 하이브리드 조직 모두에 적합합니다.
디바이스 소유권	조직(회사소유)
지원 운영체제	Windows 10/11 (Home 에디션 제외)
디바이스 관리	모바일 디바이스 관리(MDM) 도구 (예: Microsoft Intune) 또는 Configuration Manager
주요 기능	클라우드 및 온-프레미스 리소스 모두에 대한 SSO, 조건부 액세스, 셀프 서비스 암호 재설정 및 Windows Hello PIN 재설정
로그인 방식	조직의 Microsoft Entra ID 또는 동기화된 AD 계정 사용

• 조직의 Microsoft Entra 계정을 사용하여 로그인됩니다. 조직의 리소스에 대한 액세스는 디바이스 ID에 적용된 Microsoft Entra 계정 및 조건부 액세스 정책에 따라 추가로 제한될 수 있습니다.
• 🔐 관리자: MDM를 사용하거나 Microsoft Endpoint Configuration Manager로 디바이스를 관리할 수 있습니다. 이러한 도구는 스토리지 암호화, 암호 복잡성, 소프트웨어 설치 및 소프트웨어 업데이트 강제, 회사 애플리케이션 설치 및 접근제어 등의 보안설정이 가능합니다.
• ⚙️ 등록 방식: 디바이스는 다음과 같은 방법으로 대량 등록 또는 Windows Autopilot과 같은 셀프 서비스 옵션을 사용하여 수행할 수 있습니다.
  1. OOBE(Out of Box Experience: 초기 설정 화면)
  2. Windows Autopilot
  3. 대량 등록 도구
     
     
• 조직의 네트워크에 있을 때 온-프레미스 리소스에 대한 Single Sign-On 액세스를 계속 유지할 수 있습니다. Microsoft Entra 조인 디바이스는 클라우드 앱뿐 아니라, 사내 파일 서버, 프린터 같은 온-프레미스 리소스에도 자동으로 로그인(SSO) 되어 접근할 수 있습니다. 즉, 회사 네트워크 안팎에서 모두 활용이 가능합니다.
• Microsoft Entra 조인 디바이스의 목표는 다음을 간소화하는 것입니다.
  1. 회사 소유 디바이스의 Windows 배포
  2. 모든 Windows 디바이스에서 조직의 앱 및 리소스에 액세스
  3. 회사 소유 디바이스를 클라우드 기반으로 관리

5-3. 하이브리드 Microsoft Entra 조인 디바이스

• 기존의 온-프레미스 Active Directory(AD) 환경과 Microsoft Entra ID(클라우드)를 함께 활용할 수 있도록 설계된 방식으로, 사내 인프라를 유지하면서도 클라우드 기능도 동시에 사용하는 기업에 적합합니다. 10년 이상, 많은 조직은 다음을 가능케 하기 위해 온-프레미스 Active Directory에 도메인 가입을 사용했습니다.
  1. IT 부서가 중앙 위치에서 회사 소유 디바이스를 관리하도록
  2. 사용자가 Active Directory 회사 또는 학교 계정으로 자신의 디바이스에 로그인하도록
  3. 온-프레미스 공간이 있는 조직은 디바이스를 구성하는 이미징 방법을 사용하며, 종종 Configuration Manager 또는 GP(그룹 정책)를 사용하여 관리합니다.

하이브리드 Microsoft Entra 합류설명

정의	디바이스에 로그인하려면 조직 계정이 필요한 온-프레미스 AD 및 Microsoft Entra ID에 조인됨
기본 대상 그룹	기존 온-프레미스 AD 인프라를 사용하는 하이브리드 조직에 적합합니다.
디바이스 소유권	조직(회사소유)
운영 체제	Windows 7/8.1/10/11 및 Windows Server 2008~2019
디바이스 로그인 옵션	암호 또는 Windows Hello for Business
디바이스 관리	그룹 정책(GPO), Configuration Manager, Microsoft Intune (단독 또는 공동 관리)
주요 기능	클라우드 및 온-프레미스 리소스 모두에 대한 SSO, 조건부 액세스, 셀프 서비스 암호 재설정, Windows Hello PIN 재설정 등

• 디바이스는 온-프레미스 AD에 먼저 가입하고, 이후 Microsoft Entra ID에도 자동 등록됩니다. 이 과정을 통해 **클라우드 서비스(예: Microsoft 365)**도 사용할 수 있으며, 동시에 **기존 AD 리소스(예: 파일 서버, 프린터)**도 그대로 접근 가능합니다.
• 계정은 온-프레미스와 클라우드 디렉터리 간에 동기화되어 로그인 및 인증이 통합됩니다.
• 💡 사용 시나리오 예시 : 다음과 같은 경우 하이브리드 Microsoft Entra 조인을 사용하는 것이 적절합니다:
  1. 온-프레미스 AD 인증을 기반으로 하는 기존 앱(WIN32 등)을 배포해야 하는 경우
  2. 그룹 정책을 활용해 여전히 정교한 디바이스 제어가 필요한 경우
  3. 기존 이미징 툴이나 배포 방식을 그대로 유지하고 싶은 경우
  4. Windows 10 이외에도 하위 버전 OS(Windows 7, 8.1 등)를 지원해야 하는 경우

5-4. 디바이스 쓰기 저장

• 클라우드 기반 Microsoft Entra ID 구성에서는 디바이스가 Microsoft Entra ID에만 등록됩니다. 온-프레미스 AD에서 디바이스를 볼 수 없습니다. 디바이스 쓰기 저장(Device Writeback)은 클라우드(Microsoft Entra ID)에 등록된 디바이스 정보를 온-프레미스 Active Directory(AD)에 되돌려 저장(write back)하는 기능입니다. 이를 통해 클라우드에서 등록된 디바이스를 온-프레미스 AD에서도 인식할 수 있게 됩니다.
  • 클라우드: Microsoft Entra 통합 애플리케이션에 대한 조건부 액세스 정책을 작성하여 디바이스가 Microsoft Entra ID에 조인되어 있는지 여부에 따라 권한을 부여할 수 있습니다.
  • 온-프레미스: 디바이스 쓰기 저장이 없으면 불가능합니다. 애플리케이션이 ADFS(2012 이상)와 통합된 경우 클레임 규칙을 작성하여 디바이스 상태를 확인한 다음 “관리형” 클레임이 있는 경우에만 액세스를 제공할 수 있습니다. 이 클레임을 발급하기 위해 ADFS는 “등록된 디바이스” 컨테이너에서 디바이스 개체를 확인한 다음 그에 따라 클레임을 실행합니다.
• 클라우드(Microsoft Entra ID)에 등록된 디바이스 정보를 온-프레미스 AD의 "Registered Devices" 컨테이너에 복사(쓰기 저장)합니다. 이 복사본을 통해 온-프레미스 환경에서도 디바이스 인증이 가능해집니다.
• 온프레미스에서 디바이스 쓰기 저장이 활성화되어 있으면 다음이 가능합니다: ADFS(Active Directory Federation Services)와 연계 시, 디바이스 상태를 확인하는 클레임 규칙을 작성할 수 있으며, 디바이스가 신뢰된 상태("관리형 디바이스")일 경우에만 애플리케이션 접근을 허용할 수 있습니다. 💡 ADFS는 AD 내의 “등록된 디바이스” 컨테이너를 확인해서 해당 디바이스가 클라우드에서 등록된 인증된 디바이스인지 판별합니다.
• WHFB(비즈니스용 Windows Hello)에는 하이브리드 및 페더레이션 시나리오의 함수에 대한 디바이스 쓰기 저장이 필요합니다. Windows Hello for Business를 사용하는 하이브리드 또는 페더레이션(연합 인증) 환경에서는 디바이스 쓰기 저장이 필수입니다. 해당 기능이 있어야 PIN 인증, 생체 인증 등을 통해 온-프레미스와 클라우드 모두에서 원활한 인증이 가능합니다.

 

 

✅ 6. 라이선스 관리

• Microsoft 365, Enterprise Mobility + Security, Dynamics 365, 기타 유사한 제품 등과 같은 Microsoft 유료 클라우드 서비스를 사용하려면 라이선스가 필요합니다. 이러한 라이선스는 해당 서비스에 액세스해야 하는 각 사용자에게 할당됩니다. 라이선스를 관리하기 위해 관리자는 관리 포털(Office 또는 Azure) 및 PowerShell cmdlet 중 하나를 사용합니다. Microsoft Entra ID는 모든 Microsoft 클라우드 서비스의 ID 관리를 지원하는 기본 인프라입니다. Microsoft Entra ID는 사용자에 대한 라이선스 할당 상태에 대한 정보를 저장합니다.
• 지금까지는 개별 사용자 수준에서만 라이선스를 할당할 수 있으므로 대규모 관리가 어려웠으나, Microsoft Entra ID 그룹(보안 그룹 또는 동적 그룹)에 라이선스를 할당 가능.
• 그룹 멤버에게 자동으로 라이선스 부여 또는 제거가능. 이 라이선싱 관리를 사용하면 사용자 기준으로 조직 및 부서 구조에 변경 내용을 반영하기 위해 PowerShell을 통해 라이선스 관리를 자동화할 필요가 없습니다.
• 자동화된 라이선스 관리: PowerShell 스크립트 필요 없음
• 🔹 라이선스 요구 사항: 그룹 기반 라이선스를 사용하려면 다음 라이선스 중 하나가 있어야 합니다.
  1. Microsoft Entra ID Premium P1 이상에 대한 유료 또는 평가판 구독
  2. Office 365 Enterprise E3 또는 Office 365 A3 또는 Office 365 GCC G3 또는 GCCH용 Office 365 E3 또는 DOD용 Office 365 E3 이상의 유료 또는 평가판 버전
• 필요한 라이선스 수 : 라이선스가 할당된 그룹의 경우 각 고유 구성원에 대한 라이선스도 있어야 합니다. 할당된 그룹의 고유 구성원 수만큼 라이선스가 있어야 합니다. 예를 들어 테넌트에서 라이선스가 부여된 그룹에 1,000명의 고유 구성원이 있는 경우 라이선싱 계약에 부합하려면 라이선스가 1,000개 이상 있어야 합니다.

6-1. 그룹 기반 라이선스 특징

• 보안 그룹에 라이선스를 할당가능 : Microsoft Entra ID의 보안 그룹에 직접 할당 가능. 온프레미스 보안 그룹(Microsoft Entra Connect) 또는 클라우드 전용/동적 그룹도 사용 가능.
• 서비스 계획 선택적 비활성화 가능 : 그룹에 라이선스를 할당하면 관리자는 제품에서 서비스 계획을 하나 이상 사용하지 않도록 설정할 수 있습니다. 아직 제품에 포함된 서비스를 사용할 준비가 되지 않은 경우에 수행됩니다.
• 지원제품: 사용자 수준 라이선스가 필요한 모든 Microsoft 클라우드 서비스 지원 (Microsoft 365, EMS, Dynamics 365 등)
• 그룹 기반 라이선스는 현재 Azure Portal을 통해서만 사용할 수 있습니다. (Microsoft Entra 관리 센터에서는 곧 제공 예정)
• 자동 라이선스 할당/제거: 그룹 멤버 자격 변경으로 인해 발생하는 라이선스 수정을 자동으로 관리합니다. 그룹 멤버십 변화에 따라 자동 적용 (수 분 내 반영)
• 사용자 중복할당 처리: 사용자는 지정된 라이선스 정책을 사용하는 여러 그룹의 멤버가 될 수 있습니다. 동일 사용자가 여러 그룹에 속해도 라이선스는 중복 사용되지 않음
• 라이선스할당 예외상황 처리: 테넌트에서 사용할 수 있는 라이선스가 충분하지 않거나 충돌하는 서비스를 동시에 할당했을 수 있습니다. 라이선스 부족/서비스 충돌 등으로 일부 사용자에게 할당 실패할 수 있고, 라이선스 오류 상태에 있는 사용자에 대해서 관리자는 실패 이유 확인 가능(라이선스 할당 문제 식별 및 해결가능)

6-2. Microsoft Entra ID의 그룹에 대한 라이선스 할당 문제 식별 및 해결

• 그룹 기반 라이선스를 사용하지 않고 개별 사용자에게 직접 라이선스를 할당하면 할당 작업이 실패할 수 있습니다. 예를 들어 사용자 개체에 Set-MgUserLicense PowerShell cmdlet을 실행하면 비즈니스 논리와 관련된 여러 가지 이유로 cmdlet이 실패할 수 있습니다. 라이선스 수가 부족하거나 동시에 할당할 수 없는 두 서비스 간에 충돌이 있는 경우를 예로 들 수 있습니다. 문제는 즉시 사용자에게 보고됩니다.
  1. ⚠️ 라이선스부족으로 인한 오류: PowerShell cmdlet은 이 오류를 CountViolation으로 보고합니다.
  2. ⚠️ 충돌하는 서비스 계획으로 인한 오류: PowerShell cmdlet은 이 오류를 MutuallyExclusiveViolation으로 보고합니다.
  3. ⚠️ 라이선스 종속성 위반: 그룹에 지정된 제품 중 하나에 사용 가능한 라이선스가 충분하지 않습니다. 제품에 대한 추가 라이선스를 구매하거나 다른 사용자 또는 그룹에서 사용하지 않는 라이선스를 해제해야 합니다. 그룹에 할당된 특정 제품의 서비스 계획이 다른 제품의 서비스 계획 실행을 위한 필수 조건일 수 있습니다. Microsoft Entra ID는 사용자를 그룹에서 제거하거나 라이선스를 제거할 때 이 필수 서비스 플랜도 함께 제거하려고 합니다. 그러나 이 서비스 플랜이 다른 제품에 종속되어 있으면 제거할 수 없어 오류가 발생합니다. PowerShell에서는 이 오류를 DependencyViolation 으로 보고합니다.
  4. ⚠️ 사용 위치가 허용되지 않음: 현지법 및 규정으로 인해 지역에 따라 일부 Microsoft 서비스가 제공되지 않을 수 있습니다. 사용자에게 라이선스를 할당하려면 먼저 사용자에 대한 사용 위치 속성을 지정해야 합니다. 사용 위치가 지원되지 않는 국가로 설정된 경우, 라이선스 할당은 실패하고 오류가 기록됨. 이 문제를 해결하려면 사용이 허가된 그룹의 지원되지 않는 위치에서 사용자를 제거합니다. 또는 현재 사용 위치 값이 실제 사용자의 위치를 나타내지 않는 경우에는 다음에 라이선스가 정확히 할당되도록 사용 위치 값을 수정하면 됩니다(새 위치가 지원되는 경우). PowerShell cmdlet은 이 오류를 ProhibitedInUsageLocationViolation으로 보고합니다. 사용위치 설정 권장( 일부 서비스는 특정 국가에서만 사용 가능, → 사용자 프로필 또는 디렉터리에서 사용 위치 설정 필요, 위치 미지정 시 사용 위치가 지정되지 않은 사용자는 디렉터리 기본 위치를 상속받습니다.)
     
     
• 프록시 주소 중복
  : Exchange Online을 사용하는 경우 조직의 일부 사용자가 동일한 프록시 주소 값으로 올바르게 구성되지 않을 수 있습니다. 그룹 기반 라이선스가 이러한 사용자에게 라이선스를 할당하려 할 때 실패하면 ‘프록시 주소가 이미 사용 중'이라는 메시지가 표시됩니다. 영향을 받는 사용자에 대한 프록시 주소 문제를 해결한 후에는 그룹에 대한 라이선스 처리를 강제로 수행하여 라이선스를 적용할 수 있는지 확인합니다.
• LicenseAssignmentAttributeConcurrencyException (감사 로그)
  : 사용자의 감사 로그에 오류가 발생. 동일한 라이선스를 가진 두 개 이상의 그룹에 사용자가 속해 있어, Microsoft Entra ID가 동시 라이선스 할당을 시도할 때 발생. Microsoft Entra ID가 자동으로 재시도하여 해결. 고객이 별도로 수행해야 할 작업은 없음.
• Microsoft Entra Mail 및 ProxyAddresses 특성 변경
  : Exchange Online과 같은 서비스 라이선스가 할당될 때 자동으로 사용자 속성을 설정 또는 변경하는 과정에서 발생하는 일반적인 동작입니다. 그룹 기반 또는 개별 라이선스 할당/업데이트 시, Microsoft Entra ID는 사용자의 Microsoft Entra Mail 및 ProxyAddresses 속성을 자동으로 계산 및 변경됩니다. 이는 주로 Exchange Online 서비스가 포함된 라이선스가 할당될 때 발생되고, Microsoft는 Exchange Online 서비스를 위해 SMTP 주소(proxyAddresses)와 메일 주소(mail)를 자동 생성하도록 설계되어 있습니다.
• 그룹에 할당된 제품 라이선스가 두 개 이상임
  : 한 그룹에 두 개 이상의 제품 라이선스를 할당할 수 있습니다. Microsoft Entra ID는 그룹에 할당된 모든 라이선스를 각 사용자에게 할당하려고 시도합니다. 그러나 비즈니스 논리 문제로 인해 제품 중 하나를 할당할 수 없는 경우 그룹의 다른 라이선스도 할당되지 않습니다. 할당에 실패한 사용자를 확인하고 이 문제의 영향을 받는 제품을 확인할 수 있습니다.
• 라이선스 그룹이 삭제되는 경우
  : 그룹 삭제 전에 해당 그룹에 할당된 모든 라이선스를 제거해야함. 사용자에게 그룹 삭제로 인해 제거되는 종속라이선스가 있으면 해당 사용자에 대한 라이선스 할당이 상속에서 직접 할당 라이선스로 전환됨.
• 필수 구성 요소를 사용하여 제품의 라이선스 관리 (추가 기능 제품 라이선스 할당 시 필수 구성 요소 필요)
  : 일부 Microsoft 제품은 추가 기능(add-on) 으로, 라이선스 할당 전 필수 구성 요소 서비스가 활성화되어 있어야 함. 그룹 기반 라이선스를 사용하는 경우 그룹에 추가된 모든 사용자가 필수 구성 요소와 추가 기능 서비스 계획이 동일한 그룹에 있어야 합니다. 없는 경우 라이선스 작업 실패 오류. 추가 기능 라이선스를 그룹에 할당하려면 그룹에 필수 구성 요소 서비스 계획도 포함되어야 합니다.
• 그룹 라이선스 오류 수동 강제해결 방법
  : 그룹의 처리를 수동으로 트리거하여 사용자 상태를 업데이트해야 할 수 있습니다. 포털에서 라이선스를 열고 [도구 모음]에서 [다시 처리] 단추를 선택합니다. 직접 라이선스 제거 후, 그룹 라이선스 재적용이 필요한 경우에 사용합니다.
• 사용자 라이선스 프로세스를 강제하여 오류 해결
  : 사용자의 처리를 수동으로 트리거하여 사용자 상태를 업데이트해야 할 수 있습니다. 문제예시: 중복된 프록시 주소 문제 등으로 인해 사용자에게 라이선스 할당 실패 -> 문제를 해결했지만 상태가 자동으로 반영되지 않음 -> 포털에서 라이선스를 열고 [다시 처리] 버튼을 클릭. 프록시 주소 중복이나 사용 위치 미설정 등 사용자 개별 오류 해결 후 꼭 필요한 후속 조치입니다.

6-3. 개별 라이선스를 사용하는 사용자를 그룹 라이선스로 마이그레이션하는 방법

• 기존에는 PowerShell이나 기타 도구로 개별 사용자에게 직접 라이선스를 할당. 이를 그룹 기반 라이선스 방식으로 마이그레이션하는 경우, 사용자가 현재 할당된 라이선스를 일시적으로 상실하는 상황이 발생하지 않도록 주의해야 합니다.라이선스를 제거하는 방식으로의 마이그레이션은 데이터 접근 중단 위험이 있으므로 피해야 합니다.
  • 권장 접근 방식: 먼저 그룹에 라이선스를 할당하여 해당 사용자들이 포함되도록 함. 그룹 기반 라이선스가 정상적으로 적용된 것을 확인한 후, 기존의 개별 라이선스를 제거함. 즉, 항상 "추가 후 제거" 순서로 진행해야 서비스 중단을 방지할 수 있습니다.

 

✅ 7. 사용자 지정 보안 특성

• Microsoft Entra ID의 사용자 지정 보안 특성은 Microsoft Entra 개체에 비즈니스별 속성(키-값 쌍) 을 정의하고 할당할 수 있도록 해주는 기능입니다. 이를 통해 정보 저장, 개체 분류, 또는 세분화된 액세스 제어가 가능해집니다.
• 🎯 사용자 지정 보안 특성을 사용하는 이유
  1. 사용자 프로필 확장 : 모든 직원에게 직원 고용일 및 시간당 급여 정보를 추가하는 것처럼 사용자 프로필을 확장합니다.
  2. 민감 정보 보호 : 관리자만 직원의 급여 정보를 볼 수 있도록 설정
  3. 리소스 인벤토리 분류 : 수백 또는 수천 개의 애플리케이션을 분류하여 감사를 위한 태그를 달고 필터링을 손쉽게 가능하게 함
  4. 세분화된 리소스 액세스 : 사용자가 속한 프로젝트에 따라 Azure Storage Blob에 대한 접근 권한 제어
• 🔧 사용자 지정 보안 특성으로 가능한 작업
  • 테넌트에 대한 비즈니스 관련 정보(특성)를 정의합니다.
  • 사용자, 애플리케이션, Microsoft Entra 리소스 또는 Azure 리소스 등 다양한 개체에 사용자 지정 보안 특성 할당
  • 쿼리 및 필터가 포함된 사용자 지정 보안 특성을 사용하여 Microsoft Entra 개체를 관리합니다.
  • 특성 거버넌스 기능을 통해 액세스 권한을 얻을 수 있는 사용자를 결정합니다. (누가 어떤 특성에 접근할 수 있는지 제어)
• 사용자 지정 보안 특성의 기능
  • 테넌트 전체에서 사용 가능
  • 다양한 데이터 형식 지원: 부울, 정수, 문자열
  • 단일 값 또는 다중 값 지원
  • 사용자 지정 자유 형식 값 또는 미리 정의된 값 지원
  • 온-프레미스 Active Directory에서 디렉터리가 동기화된 사용자에게 사용자 지정 보안 특성 할당

 

✅ 8. 자동 사용자 만들기 살펴보기

• 시스템 SCIM의 구성 요소(도메인 간 ID 관리를 위한 시스템)
  1. HCM 시스템 : 직원 수명 주기 동안 HR 프로세스를 지원하고 자동화하는 애플리케이션 및 기술
  2. Microsoft Entra 프로비전 서비스 : 자동 프로비전을 위해 SCIM 2.0 프로토콜을 사용하여 애플리케이션의 SCIM 엔드포인트와 연결, 사용자와 그룹의 프로비저닝 및 프로비저닝 해제를 자동화합니다.
  3. Microsoft Entra ID : 사용자ID 및 ID 권리 유형의 수명 주기를 관리하는 사용자 리포지토리입니다.
  4. 대상 시스템 : SCIM 엔드포인트를 포함하며 Microsoft Entra 프로비전과 연동하여 사용자 및 그룹의 자동 프로비전을 지원하는 시스템
     
     
• SCIM을 사용하는 이유는 무엇인가요?
  : SCIM(System for Cross-domain Identity Management)은 ID 도메인과 IT 시스템 간의 사용자 ID 정보 교환을 자동화하기 위한 개방형 표준 프로토콜입니다.
  : HCM(Human Capital Management) 시스템에 새 직원이 추가되면 Microsoft Entra ID 또는 Windows Server AD에 자동으로 계정이 생성됩니다. 사용자 특성 및 프로필이 양쪽 시스템 간에 동기화됩니다. 사용자 상태나 역할 변경 시 자동으로 계정이 업데이트 또는 제거됩니다. 이를 통해 ID 시스템을 최신 상태로 유지하고, HR 시스템에서 사용자가 제거되면 자동으로 프로비전 해제되어 보안 위협을 줄입니다.

 

✅ 9. Azure의 물리적/관리적 인프라

9-1. Azure의 물리적 인프라

• Azure는 전 세계에 여러 데이터 센터를 운영해요. 데이터 센터들은 ‘지역(Region)’이나 ‘가용성 영역(Availability Zone)’이라는 그룹으로 묶여서 더 안정적이고 빠르게 서비스를 제공해요. 데이터 센터는 중요 비즈니스용 워크로드에 대한 복원력과 안정성을 달성할 수 있도록 설계된 Azure 지역 또는 Azure 가용성 영역으로 그룹화됩니다. Azure의 글로벌 인프라 사이트를 통해서 이러한 인프라 구성을 직접 확인할 수도 있어요.
• 영역
  • 지역(Region)은 지리적으로 가까운 데이터 센터들이 모여 있는 구역이에요. Azure는 각 Azure 지역의 리소스를 지능적으로 할당하고 제어하여 워크로드의 적절한 균형을 유지합니다. 이 데이터 센터들은 빠른 네트워크로 연결되어 있어 대기 시간이 짧고 속도가 빨라요. Azure는 이 지역 내에서 리소스를 잘 분배해서 안정적이고 효율적으로 서비스를 제공해요. Azure에서 리소스를 배포할 때 리소스를 배포할 Azure 지역을 선택해야 하는 경우가 자주 있습니다.
• 가용성 영역
  • Azure 지역 내에서 물리적으로 분리된 데이터 센터입니다. 각 영역은 전원, 냉각, 네트워크가 완전히 따로 분리되어 있어서 한 곳에 문제가 생겨도 다른 영역은 영향을 받지 않아요. 영역들은 빠른 네트워크로 서로 연결되어 있어서 데이터와 서비스가 끊기지 않도록 도와줘요. 즉, 가용성 영역은 서비스가 항상 안정적으로 운영되도록 하는 ‘안전장치’ 같은 역할을 해요.
  • 앱에서 가용성 영역 사용하기
    : 가용성 영역을 사용하면 서비스와 데이터를 여러 ‘독립된’ 장소에 복제해서 장애가 나도 데이터와 서비스가 안전하게 보호돼요. 직접 중복된 하드웨어를 만들 필요 없이, Azure가 가용성 영역을 통해 이 중복성을 쉽게 만들어 줘요. 예를 들어, 중요한 앱을 실행할 때 컴퓨터(서버), 저장 공간, 네트워크 등을 한 가용성 영역에 놓고, 다른 영역에도 똑같이 복사해 두는 거예요. 이렇게 하면 한 영역에 문제가 생겨도 다른 영역에서 계속 서비스를 할 수 있어 안정성이 올라가요. 하지만 이렇게 중복할 때는 데이터 전송이나 자원 복제 때문에 비용이 추가될 수 있어요. 가용성 영역은 주로 VM, 관리 디스크, 부하 분산 장치 및 SQL 데이터베이스에 주로 사용됩니다.
  • 가용성 영역을 지원하는 Azure 서비스는 다음의 세 범주로 나뉩니다.
    1. 영역 서비스 : 사용자가 직접 특정 가용성 영역에 리소스를 배치해요. (예: VM, 관리 디스크(저장장치), IP 주소)
    2. 영역 중복 서비스 : Azure가 자동으로 여러 영역에 데이터를 복제해요. (예: 영역 중복 저장소, SQL 데이터베이스)
    3. 비지역 서비스: 지역 내 여러 영역과 지역 전체가 중단돼도 복구 가능해요. 가용성 영역이 제공하는 추가 복원력에도 불구하고 이벤트가 너무 커서 단일 지역의 여러 가용성 영역에 영향을 줄 수도 있습니다. 더 많은 복원력을 제공하기 위해 Azure에는 지역 쌍(Paired Regions)이 있습니다.
• 지역쌍
  • 가용성 영역이 여러 장애를 막아주지만, 큰 사고가 발생하면 한 지역 내 여러 가용성 영역이 동시에 영향을 받을 수 있어요. 그래서 Azure는 서로 멀리 떨어진 ‘지역 쌍’을 만들어서 한 지역 전체가 문제가 생겨도 다른 지역에서 서비스를 계속할 수 있게 해요.
  • 서로 약 300마일(약 480km) 이상 떨어져 있지만 같은 큰 지리적 위치(예: 미국, 유럽, 아시아)에 있는 두 개의 Azure 지역 쌍을 이룹니다. 한 지리적 위치에서 리소스를 복제할 수 있으며, 이렇게 하면 전체 지역에 영향을 주는 자연재해, 내전, 정전 또는 물리적 네트워크 중단 등의 이벤트 때문에 서비스가 중단될 가능성을 줄일 수 있습니다. 한 쌍의 지역이 자연재해의 영향을 받은 경우 서비스는 해당 지역 쌍의 다른 지역으로 자동으로 장애 조치(failover)됩니다.
  • 주의할점: 모든 Azure 서비스가 자동으로 데이터를 복제하거나 장애 조치를 지원하는 것은 아니에요. 이런 기능을 사용하려면 고객(사용자)이 직접 복구 및 복제 구성을 설정해야 합니다.

9-2. Azure의 관리 인프라

• 관리 인프라에는 Azure 리소스 및 리소스 그룹, 구독 및 계정이 포함됩니다. 계층 조직을 이해하면 Azure 내에서 프로젝트 및 제품을 계획하는 데 도움이 됩니다.
• Azure 리소스
  • 리소스는 Azure에서 만드는 모든 것들을 뜻해요. 가상 머신(VM), 데이터베이스, 가상 네트워크 등이 모두 리소스예요.
  • 리소스 그룹: 리소스 그룹은 여러 리소스를 한데 묶는 상자 같은 거예요. 리소스를 만들 때 반드시 리소스 그룹 안에 넣어야 해요. 한 리소스는 한 번에 딱 한 개의 리소스 그룹에만 속할 수 있어요. 한 리소스는 한 번에 딱 한 개의 리소스 그룹에만 속할 수 있어요.(중첩 불가) 리소스 그룹 간에 이동될 수 있지만 리소스를 새 그룹으로 이동하면 더 이상 이전 그룹과 연결되지 않습니다.
  • 리소스 그룹의 장점: 그룹에 작업(예: 권한 설정, 삭제)을 하면 그 안에 있는 모든 리소스에 한꺼번에 적용돼요.
• Azure 구독
  • Azure 구독은 관리, 청구, 자원 사용 범위를 정하는 단위예요. 구독은 리소스 그룹들을 묶어서 관리하고 비용을 청구하는 역할을 해요. Azure를 사용하려면 꼭 구독이 있어야 하며, 구독을 통해 Azure 서비스에 접근하고 자원을 만들 수 있어요. 리소스를 프로비전할 수도 있습니다. Azure 계정 하나에 여러 구독이 있을 수 있지만, 하나의 구독은 하나의 계정과 연결돼요.
  • 다중 구독 계정: 여러 구독을 통해 다른 청구 방식이나 권한 설정을 할 수 있어요. (ex. 부서별 구독)
  • 구독 경계
    • 청구경계: 구독별로 사용한 Azure 비용이 따로 계산돼요. 여러 구독을 만들어서 부서별, 프로젝트별로 비용을 분리 관리할 수 있어요.
    • 액세스 제어 경계: 구독마다 권한 관리 정책을 따로 설정할 수 있어요. 부서별로 다른 권한이나 정책을 적용할 때 구독을 나누면 편해요.
  • 추가 구독
    • Azure에서 추가 구독을 만드는 이유는 여러 가지가 있어요. 리소스 그룹이 리소스를 묶는 것처럼, 구독은 더 큰 단위로 리소스를 묶어 관리할 수 있답니다.
      • 환경 구분: 개발, 테스트, 운영 같은 환경을 구분할 때 좋아요. 보안이나 법규 때문에 데이터를 따로 분리할 때도 유용해요. 구독 단위로 권한을 따로 줄 수 있어서, 각 환경에 맞게 관리하기 편해요.
      • 조직 구조반영: 회사 내 여러 팀이나 부서마다 구독을 나눌 수 있어요. 예를 들어, 개발팀은 비용을 아끼기 위해 저렴한 리소스만 사용하도록 제한하고, IT팀은 모든 자원을 자유롭게 사용할 수 있게 할 수 있어요.
      • 청구 관리: 비용 관리를 쉽게 하려고 구독을 따로 만들기도 해요. 운영에 필요한 리소스와 개발 테스트용 리소스 비용을 구분해서 추적할 수 있죠. 청구서도 구독별로 나오기 때문에 비용 분석이 편해져요.
• Azure 관리 그룹
  • 리소스는 리소스 그룹으로 모이고 리소스 그룹은 구독으로 모입니다. 관리 그룹은 Azure의 계층 구조에서 구독 위에 있는 컨테이너입니다. 리소스 → 리소스 그룹 → 구독 → 관리 그룹 순으로 묶여요. 여러 구독을 한꺼번에 묶어 거버넌스(정책, 권한, 규정 준수 등)를 중앙에서 관리할 수 있도록 도와줍니다. 관리 그룹에 적용한 정책이나 권한은 그 아래 모든 구독, 리소스 그룹, 그리고 개별 리소스까지 자동으로 상속됩니다. 관리 그룹은 중첩(하위 관리 그룹 포함) 가능해서, 복잡한 조직 구조도 유연하게 관리할 수 있습니다.
  • 왜 관리 그룹을 사용할까?
    • 구독이 많아질수록 개별 구독 관리가 어려워짐 → 관리 그룹으로 통합 관리. 여러 구독에 공통 정책을 한 번에 적용 가능. 여러 구독에 걸쳐 사용자 액세스 권한을 한 번에 설정 가능. 조직의 보안, 규정 준수, 거버넌스 요구사항을 효과적으로 맞출 수 있음
  • 관리 그룹 관련 제한 사항
    • 단일 디렉터리에서 지원할 수 있는 최대 관리 그룹 수는 10,000개입니다.
    • 관리 그룹 트리에서 지원할 수 있는 최대 깊이 수준은 6입니다. (루트, 구독 제외)
    • 각 관리 그룹 및 구독은 하나의 부모만 지원할 수 있습니다. (단일 상속 구조)

 

 

 

✅ 10. Azure Policy initiatives

• Azure Policy는 리소스 생성과 구성에 대해 규칙(정책)을 만들고 이를 리소스에 자동으로 적용해 조직의 기준과 규정 준수 요구사항을 강제할 수 있도록 도와주는 서비스입니다. 이러한 정책은 JSON 형식으로 작성되며 정책 정의라고 합니다. Azure Policy는 조직의 표준을 적용하고 대규모로 규정 준수를 평가하는 데 필수적입니다.
• Azure Policy initiatives는 특정 목표나 용도에 맞춰 그룹화된 Azure Policy 정의 모음입니다. 여러 Azure 정책을 단일 항목으로 통합하여 Azure 리소스 전반에 걸쳐 구성을 중앙에서 제어하고 적용할 수 있도록 지원합니다.
• 고객은 배포를 사용자 지정하여 환경 감사 시간을 단축하고 기존 규정 준수 프레임워크 및 정부 요건을 충족하는 데 도움이 되는 Azure Policy 이니셔티브를 만들 수 있습니다. 이 이니셔티브는 공공 부문 파트너와 고객이 클라우드 가드레일을 구축하고 특정 규정을 효과적으로 시행할 수 있도록 지원합니다. 정책 이니셔티브를 계층화하여 특정 요구 사항에 맞는 완벽한 솔루션을 구축하고, 배포 자동화를 통해 일관성과 모범 사례를 확보하고 시간을 절약할 수 있습니다.

10-1. Azure를 위한 클라우드 도입 프레임워크 (Cloud Adoption Framework)

• 조직이 클라우드를 도입하고 운영하는 모든 단계에서 활용할 수 있는 포괄적인 기술 지침을 제공합니다. 이 프레임워크는 클라우드 설계자, IT 전문가, 비즈니스 리더가 비즈니스 목표에 맞게 클라우드 전략을 수립하고 실행할 수 있도록 지원합니다.
• 🌀 클라우드 도입 수명주기 (Cloud Adoption Lifecycle)
  • 클라우드 도입 프레임워크는 다음과 같은 단계로 구성된 수명주기를 기반으로 설계되어 있습니다:
  1. 전략(Strategy) – 비즈니스 목표 정의
  2. 계획(Plan) – 클라우드 준비도 평가 및 마이그레이션 계획 수립
  3. 준비(Ready) – 클라우드 환경 설정
  4. 채택(Adopt) – 마이그레이션 또는 혁신
  5. 거버넌스(Govern) – 조직의 클라우드 사용 관리를 의미. 규정 준수 및 리스크 관리 ‘거버넌스’ 단계에서 Azure Policy가 핵심 역할을 수행합니다.
  6. 관리(Manage) – 클라우드 운영, 모니터링, 개선

10-2. 클라우드 거버넌스 방법론 (Governance Methodology)

• 클라우드 거버넌스는 조직의 클라우드 사용에 대해 정책적, 기술적 통제를 설정하고 유지하는 과정입니다.
• 포괄적인 클라우드 거버넌스는 클라우드 사용의 모든 측면을 감독하고, 규정 준수, 보안강화, 운영안정성 유지, 비용최적화, 데이터 및 리소스 관리 등 다양한 위험을 최소화하며, 조직 전체의 클라우드 운영을 최적화합니다. 클라우드 활동이 전반적인 클라우드 전략과 일관성을 유지하도록 보장하여, 장애를 최소화하면서 비즈니스 목표 달성을 지원합니다.
• 🛡 클라우드 거버넌스를 위한 5단계
  • 클라우드 거버넌스는 일회성이 아닌 지속적인 순환 프로세스입니다. 기술 변화, 보안 위협, 규제 환경에 유연하게 대응하기 위해 정기적인 점검과 조정이 필요합니다. 클라우드 거버넌스를 구축하려면 5단계를 모두 완료해야 하며, 시간이 지남에 따라 클라우드 거버넌스를 유지하려면 2~5단계를 정기적으로 반복해야 합니다
    1. 거버넌스 팀 구축 (Establish Governance Team)
       • 클라우드 거버넌스 정책을 정의하고 운영을 책임질 전담 조직 구성.
       • 핵심역할: 정책수립 및 유지, 실행현황 점검 및 보고, 관련 부서와 협업
    2. 클라우드 위험 평가 (Assess Cloud Risks)
       • 조직의 클라우드 사용에 내재된 위험 요소를 식별하고 분석 (규정 준수, 보안, 운영, 비용, 데이터 관리, 리소스 관리, AI 관련 위험을 포함한 모든 위험)
    3. 거버넌스 정책 문서화 (Document Governance Policies)
       • 클라우드 사용의 기준을 명확히 설정
    4. 정책 시행 (Implement Policies)
       • 정책이 실제로 적용되고 실행되도록 체계 구축
       • 방법: 수동 감독 + 자동화 도구 병행. Azure Policy, 관리 그룹, Blueprint, 알림 시스템 등 사용 등
    5. 정기적 모니터링 (Monitor & Improve)
       • 정책 준수 상태를 지속적으로 점검하고 필요 시 조정
       • 활동: 정책 위반 사례 분석, 리포트 및 감사 로그 리뷰, 새로운 리스크 발생 시 정책 업데이트
• 🧭 클라우드 거버넌스 정책 정의 시 고려 사항
  • 정책 수립 시에는 기술적인 요소뿐 아니라 비즈니스 리스크와 규정 준수, 프로세스 체계를 함께 고려해야 합니다. 이러한 조치를 채택하면 규정 준수 프로세스가 간소화되고 클라우드 환경의 보안과 효율성도 향상됩니다.
  1. 비즈니스 위험 : 데이터 분류(개인/금융정보)와 애플리케이션 중요도(핵심시스템)에 따라 변화하는 비즈니스 위험과 기업의 위험 허용 범위를 문서화
  2. 정책 및 규정 준수 : 위험 관리 결과를 기반으로 정책 성명(Policy Statements) 수립
  3. 프로세스 : 회사 정책 위반 모니터링 프로세스 수립. 정책위반 감지 및 리포트체계 마련. 정기적인 감사 및 평가 절차 수립
• 🧱 클라우드 거버넌스의 5가지 핵심 원칙
  1. 💰 비용 관리 (Cost Management)
     • 명확한 비용 관리 체계를 구축하는 것을 포함하여 비용을 평가하고 모니터링. 또한 수요에 따라 리소스를 조정하는 것도 포함.
  2. 🔐 보안 기준선 (Security Baseline)
     • 기본적으로 암호화, 접근제어, 보안 패치 포함. 보안 관련 표준 정책 템플릿 구축, 모든 배포에 최소 보안 요건 자동 적용
  3. 🧱 리소스 일관성 (Resource Consistency)
     • 리소스 구성의 일관성을 보장(네이밍 규칙, 태그 정책, 리소스 그룹 구조 표준화), 온보딩 및 삭제 프로세스 자동화
  4. 🆔 ID 기준선 (Identity Baseline)
     • 역할 정의와 할당을 일관되게 적용하여 ID 및 액세스에 대한 기준이 시행되도록 보장합니다. (RBAC(Role-Based Access Control) 정책 적용)
  5. 🚀 배포 가속화 (Deployment Acceleration)
     • 배포 템플릿 전반의 중앙 집중화, 일관성 및 표준화를 통해 정책 배포를 가속화합니다.
• Azure Policy를 사용한 클라우드 거버넌스
  • Azure에서 클라우드 거버넌스를 효과적으로 구현하기 위한 핵심 도구는 Azure Policy입니다. 현재 리소스뿐만 아니라 향후 생성될 리소스에 대해서도 조직의 정책을 일관되게 적용할 수 있도록 지원합니다. 이를 통해 다양한 리소스에 대해 가드레일(guardrails)을 설정하고, 기업의 표준을 강제하며, 대규모 환경에서 규정 준수 상태를 평가할 수 있습니다.
  • 중앙 집중식 관리로 모든 규정 준수 데이터를 단일 리포지토리에 통합해 규정 준수 상태를 한눈에 파악할 수 있는 규정 준수 대시보드를 제공합니다. 이를 통해 리소스 및 정책 단위의 세부 정보까지 심층적으로 분석하고, 규정 위반 사항을 빠르게 식별하여 조치할 수 있습니다.
  • 규정 준수 기준을 일관되게 준수하고 자동 수정 및 사전 방지기능이 있습니다. 정책 위반 리소스를 감지할 뿐만 아니라, 기존 리소스에 대한 일괄 수정과 신규 리소스 생성 시의 자동 수정을 통해 환경 전체의 일관된 규정을 유지할 수 있도록 지원합니다. 특정 태그가 누락된 리소스에 대해 자동으로 태그를 추가할 수 있으며, 정책에 어긋나는 리소스 생성을 사전에 차단할 수도 있습니다.
  • Azure 플랫폼에 직접 내장하면 외부 승인 프로세스의 필요성을 크게 줄여 개발자 생산성을 향상시킬 수 있습니다.
  • DevOps 파이프라인 통합: 애플리케이션 배포 전·후 단계에서의 정책 검사를 통해 Azure DevOps와도 자연스럽게 통합됩니다. 이를 통해 CI/CD 파이프라인 내에서 정책 위반 여부를 사전에 감지하고, 거버넌스 요구사항을 지속적으로 충족할 수 있습니다.
• Azure Policy로 적용할 수 있는 거버넌스 예시
  • 리소스를 허용된 지역에만 배포하도록 제한
  • 데이터 상주 요구사항을 충족하기 위한 지리적 복제 정책 적용
  • 특정 가상 머신(VM) 크기만 허용
  • 리소스에 대한 분류 태그(Tag) 일관성 강제
  • 서버에 정기적 시스템 업데이트 권장
  • 구독 계정에 대해 다중 요소 인증(MFA) 필수화
  • 진단 로그를 Azure Monitor Logs로 전송하도록 설정
• 정책 설계 시 고려 사항
  • Azure Policy를 설계할 때는 다음의 균형을 고려해야 합니다. 이를 위해 새로운 정책을 도입하기 전에는 반드시 잠재적인 영향과 예외 상황을 사전에 검토하고, 조직의 환경과 요구사항에 적합한 방식으로 점진적으로 적용하는 것이 바람직합니다.:
  1. 제어 vs. 안정성: 환경의 무결성과 일관성을 확보하되, 과도한 제약으로 인한 운영 저하를 방지해야 합니다.
  2. 속도 vs. 결과: 개발 및 운영 속도를 저해하지 않으면서도 명확한 정책 결과를 달성해야 합니다.

 

10-3. azure-policy-design-principles (Azure Policy 설계 원칙)

• Azure 거버넌스는 애플리케이션과 리소스를 제어하는 메커니즘 및 프로세스를 포함합니다. Azure Policy를 통해 정책을 계획하고 전략적 우선순위를 설정함으로써, 비용을 보호하고 리소스를 효과적으로 관리하며 추적할 수 있습니다.

10-4. 거버넌스를 위한 계층 구조

• Azure는 적절한 거버넌스 구축을 위해 네 가지 수준의 관리 계층을 제공합니다. 이 구조를 통해 리소스를 계층적으로 구성하고, 정책 및 액세스 관리를 통합할 수 있습니다.:
  • 테넌트 루트 그룹 : zure 구조는 최상위 테넌트 루트 그룹으로 시작
    • └─ 1. 관리 그룹 (Management Group) : 여러 구독을 통합하여 정책, 액세스를 일괄적으로 관리할 수 있는 상위단위. 중첩구성도 가능.
      • └─ 2. 구독 (Subscription) : 청구, 리소스 한도, 액세스를 관리하는 단위. Azure를 사용하려면 하나 이상의 구독이 필요.
        • └─ 3. 리소스 그룹 (Resource Group) : 관련 리소스를 그룹화한 단위. 그룹 단위로 권한 부여 및 삭제 등 작업가능.
          • └─ 4. 리소스 (Resource) : Azure에서 VM, 네트워크, DB, AI 서비스 등의 단일 서비스 인스턴스를 의미

10-5. Azure Resource Manager(ARM) 개요

• Azure Resource Manager는 Azure 리소스의 생성, 수정, 삭제를 담당하는 관리 계층입니다
• Azure 작업은 제어 평면과 데이터 평면의 두 가지 유형으로 분류:
  1. 제어 평면(Control Plane)
     • 리소스 자체를 관리하는 영역입니다. Azure Policy는 이 평면에서 작동하여 리소스에 규칙과 규정 준수를 적용합니다. (예: 스토리지 계정에 암호화 정책 적용)
  2. 데이터 평면(Data Plane)
     • 특정 리소스 유형의 인스턴스가 제공하는 기능에 액세스할 수 있도록 합니다. 실제 데이터 작업이 발생하는 곳이며, 리소스 내부 데이터와 직접 상호작용하는 영역입니다. Azure Policy는 데이터 플레인에서 상호 작용하는 리소스가 정책을 준수하는지 확인합니다. (예: 저장소에 파일 업로드, Key Vault에서 비밀 조회 등)
  • 각 Azure 서비스는 이러한 요청을 내부적으로 처리하여 Azure Resource Manager를 거치지 않고 리소스 공급자를 통해 데이터를 직접 관리합니다. RBAC 또는 액세스 제어 목록(ACL)과 같은 서비스별 액세스 제어는 종종 데이터 플레인 권한을 관리합니다. 서비스는 데이터 또는 데이터 작업의 결과를 응답하여 요청자가 올바른 권한을 가지고 있는지 확인합니다.
  • Azure Policy를 사용하면 개별 Azure 서비스에서 Azure Policy 확장을 구현하여 정책 동작을 개선하고 특정 리소스 공급자와의 통합을 강화할 수 있습니다. Azure Policy는 현재 다음 리소스 공급자 모드를 통해 데이터 평면 작업을 지원합니다.
    • Microsoft.Kubernetes.Data - Pod, 컨테이너, Ingress와 같은 Kubernetes 클러스터 및 구성 요소를 관리하는 데 사용됩니다.
    • Microsoft.KeyVault.Data - Azure Key Vault의 자격 증명 모음과 인증서를 관리하는 데 사용됩니다.
    • Microsoft.Network.Data - Azure Policy를 사용하여 Microsoft Azure Virtual Network Manager 사용자 지정 멤버십 정책을 관리하는 데 사용됩니다.
    • Microsoft.ManagedHSM.Data - Azure Policy를 사용하여 Azure Key Vault 관리형 HSM 키를 관리하는 데 사용됩니다.
    • Microsoft.DataFactory.Data - Azure Policy를 사용하여 Microsoft Azure Data Factory 아웃바운드 트래픽 도메인 이름을 거부하는 데 사용됩니다.
    • Microsoft.MachineLearningServices.v2.Data - Microsoft Azure Machine Learning 모델 배포 관리에 사용됩니다. 이 리소스 공급자 모드는 새로 생성되고 업데이트된 구성 요소에 대한 규정 준수를 보고합니다.
• Azure Resource Manager의 요청 처리 흐름
  • 리소스를 배포할 때 Azure Resource Manager는 새 리소스를 언제 생성하고 기존 리소스를 언제 업데이트해야 하는지 파악합니다.
  • Azure Resource Manager는 Azure 요청을 처리하는 두 가지 시나리오가 있다:
    1. 그린필드(Greenfield)
       • 정책이 먼저 정의되어 있고, 그 이후 리소스를 생성하거나 업데이트하는 방식입니다.
       • REST API 또는 Azure CLI 등에서 요청 → ARM이 요청 수신
       • RBAC(역할 기반 액세스 제어) → Azure Policy 순으로 평가
       • 권한 통과 후, 요청은 Azure Policy를 거쳐 모든 정책 준수여부에 대해 평가됩니다.
       • 리소스 업데이트의 경우, 변경된 항목(델타)만 전송 → 병합 후 정책 평가
    2. 브라운필드(Brownfield)
       • 이미 존재하는 리소스에 대해 정책을 나중에 적용하는 방식입니다.
       • 정책이 리소스에 할당되면 자동 평가됨 (24시간 주기 또는 수동 평가 가능)
       • 정책 위반 리소스는 기존 리소스는 유지되되 비준수 상태로 표시됨
       • 검사 기간은 예측할 수 없지만, 검사가 완료된 후에는 기존 리소스의 규정 준수 상태가 업데이트됩니다. 이 평가를 수행하기 위해 Azure Policy는 범위 내의 모든 기존 리소스를 읽습니다.

10-6. azure-policy-resources

• Azure Policy는 조직의 거버넌스 및 규정 준수를 관리하기 위한 도구입니다. 리소스의 속성을 비즈니스 규칙과 비교하여 자동으로 평가하고, 정책 위반 여부를 판단합니다.
• 📌 Azure Policy의 핵심 리소스 및 개념
  1. 정의 (Definition) - 리소스 규정 준수 조건과 조건 충족 시 적용되는 효과를 설명합니다. 여러 설정에 따라 Azure Policy에서 평가되는 리소스가 결정됩니다. 평가 대상 리소스는 범위(Scope) 에 따라 결정됩니다. (범위 계층 구조: 루트 테넌트 → 관리 그룹 → 구독 → 리소스 그룹 → 리소스. 상위 범위의 정책은 하위 범위에 상속됩니다.)
  2. 이니셔티브 (Initiative) - 여러 정책 정의를 그룹화한 정책 집합으로, 정책 관리 간소화 및 일괄 할당 가능 - 정책 정의를 JSON으로 구성 - 기본 제공 이니셔티브: Azure에서 제공하는 정책 세트(보안, 규정 준수 등) - 사용자 지정 이니셔티브: 사용자가 작성하는 조직 맞춤형 정책 세트
  3. 과제 (Assignment) - 정의 또는 이니셔티브를 특정 범위에 할당. 여러 속성을 통해 적용 범위 세부 조정 가능. 정책 할당은 포털, API 호출 또는 명령줄 인터페이스를 통해 수행할 수 있습니다. - 리소스 범위 및 정책 정의를 포함한 여러 가지 선택적 요소를 정의할 수 있음:
     1. 선택적 리소스선택기(Optional resource selectors): 리소스 위치나 유형에 따라 기준 세분화
     2. 선택적 재정의(Optional overrides): 기본 정의를 수정하지 않고 효과를 변경함
     3. enforcementMode 비활성화: enforcementMode를 비활성화하면 정의를 변경하지 않고도 "what-if" 시나리오를 지원할 수 있습니다. 정책은 적용은 하지 않고 단순히 규정 준수 여부만 평가해요. 즉, 이 정책이 적용되면 어떤 일이 생기는지를 시뮬레이션 해볼 수 있는 거예요. 원래는 정책 정의를 'audit(감사)' 효과로 바꿔야 가능했지만, 이제는 enforcementMode만 off로 설정하면 같은 효과를 낼 수 있는 거죠.
     4. 선택적 제외 범위(exclusion): 범위 전체에 적용하되, 일부 특정 항목(리소스나 리소스 그룹 등)은 예외로 두고 싶을 때 그 제외하고 싶은 리소스를 선택적 제외 범위(exclusion)로 지정할 수 있음.
     5. 비준수 메시지(Noncompliance messages) 정의: 정책이 요구하는 조건을 지키지 않았을 때 알려주는 메시지를 설정할 수 있음
     6. 매개변수 값 할당(Parameters) : 정책이나 코드에서 유동적으로 바꿀 수 있는 값의 자리예요. 설정한 매개변수 자리에 원하는 값을 넣을 수 있다.
     7. deployIfNotExists: 리소스를 자동 수정 가능. Azure Policy에서 정책이 지켜지지 않으면 자동으로 설정을 배포하는 효과(옵션)예요. (예: 네트워크 정책이 없으면 자동으로 생성해줘.)
  4. 면제 (Exemption) - 정책면제란? 특정 리소스를 정책 평가에서 제외하거나 임시 허용시켜 규정 준수 상태에는 포함되나, 평가 대상에서 제외. 할당시점이 아닌 할당 시점 이후에 생성됨. - 면제유형
     1. Mitigated (완화) : 정책 의도를 다른 방식으로 준수하여 면제 허용
     2. Waiver (면제) : 리소스의 비준수 상태를 일시적으로 수용하여 면제 허용
  5. 증명서 (Evidence / Attestation) : 보통 Auzre Policy는 자동으로 리소스를 검사해 정책ㅇ르 지켰는지 확인하는데, 자동으로 검사하기 어려운 상황에서는 사람이 수동으로 체크를 하는데, 이를 수동정책(manual policy)이라고함. 이 수동정책을 지켰다는 증거(증명)를 직접 넣어야 함. 이 수동 정책에 대한 규정 준수 증명 문서를 증명서라고 하고, 이 증명서(정책증명)을 올려야 함.
  6. 수정 (Remediation) - 정책의 수정 작업은 규정을 지키지 않는 리소스를 자동으로 규정준수상태로 고치는데 사용됩니다. 특히 modify 또는 deployIfNotExists 효과가 있는 정책을 사용하면, 기존 리소스를 수정하거나, 없는 설정을 자동으로 배포해서 규정을 지키도록 만들 수 있습니다. 앞으로 만들어지거나 업데이트되는 리소스도 이 정책이 적용되면 자동으로 수정됩니다.

 

 

 

✅ 11. Azure Policy 정의

• Azure 정책 정의는 다음 두가지로 구성됨:
  1. 조건(Condition) : 별칭(Alias)을 사용해서 리소스 속성에 접근하고, 리소스의 속성(위치, 태그, 크기 등)이 정책기준을 만족하는지 값을 비교하여 확인하는 역할.
  2. 효과(Effect) : 조건이 일치하는 것으로 평가될 때 발생하는 동작을 결정함. 새 리소스, 업데이트된 리소스 또는 기존 리소스마다 효과가 다르게 동작합니다.

11-1. Anatomy of a policy definition

• JSON을 사용하여 다음 표에 표시된 요소를 포함하는 정책 정의를 만듭니다.요소설명속성 또는 값

  displayName (string, max 128 characters)	정책 정의를 식별하는 데 사용됩니다.	-
  description (string, max 512 characters)	정의가 사용되는 경우에 대한 맥락을 제공합니다.	-
  policyType (read-only string)	정책 정의의 출처를 나타냅니다.	● 기본 제공: Microsoft 제공 ● 사용자 지정: 고객이 만든 정의 ● 정적: Microsoft의 규정 준수 정책
  mode (string)	정책 대상에 따라 구성됨	● 리소스 관리자 모드:   o 모두   o 인덱싱됨 ● 리소스 공급자 모드:   o Microsoft.Kubernetes.Data   o Microsoft.KeyVault.Data   o Microsoft.Network.Data ● 미리 보기 리소스 공급자:   o Microsoft.ManagedHSM.Data   o Microsoft.DataFactory.Data
  version (string, optional)	여러 버전이 있을 수 있으며, 지정하지 않으면 최신 버전 사용	-
  metadata (object, optional, max 1,024 characters)	정의 정보 저장	● version ● category ● preview (true/false) ● deprecated (true/false) ● portalReview
  parameters (object, optional)	정책 재사용성을 높이기 위해 사용	● 이름 ● 유형 (문자열, 배열 등) ● 메타데이터 (설명, strongType 등) ● 기본값 ● 허용된 값 ● 스키마
  policyRule (object)	정책 효과 정의 if / then 블록으로 구성됨	● if: 조건 정의 ● then: 효과 정의

 

# 예시 JSON: 제시된 예에서 b2cDirectories는 위치제약조건 정책 로직에서 제외됩니다. 이 로직은 별도의 정책을 통해 적용할 수 있습니다.
{
  "displayName": "Allowed locations",
  "description": "This policy enables you to restrict the locations your organization can specify when deploying resources. Use to enforce your geo-compliance requirements. Excludes resource groups, Microsoft.AzureActiveDirectory/b2cDirectories, and resources that use the 'global' region.",
  "policyType": "BuiltIn",
  "mode": "Indexed",
  "metadata": {
    "version": "1.0.0",
    "category": "General"
  },
  "parameters": {
    "listOfAllowedLocations": {
      "type": "Array",
      "metadata": {
        "description": "The list of locations that can be specified when deploying resources.",
        "strongType": "location",
        "displayName": "Allowed locations"
      }
    }
  },
    "policyRule": {
      "if": {
        "allOf": [
          {
            "field": "location", #### 이 조건은 리소스의 location 필드를 검사합니다. ####
            "notIn": "[parameters('listOfAllowedLocations')]"
          },
          {
            "field": "location", #### 위치를 정확하게 설정하지 않았기 때문에 위치제약조건에서 제외(exclude)됨. ####
            "notEquals": "global"
          },
          {
            "field": "type", #### 해당 리소스 타입(b2cDirectories)에 대해서는 정책 평가를 하지 않겠다는 의미입니다. ###
            "notEquals": "Microsoft.AzureActiveDirectory/b2cDirectories"
          }
        ]
      },
      "then": {
        "effect": "deny"  ###  listOfAllowedLocations에 포함되지 않은 지역이면 리소스 생성을 거부한다는 의미 ####
      }
    }
  }

 

 

11-2. Logical operators and conditions (if blocks) : 논리 연산자와 조건문 (if 블록)

• Azure 정책 정의에서 policyRule의 첫 번째 부분은 if 블록입니다. 이 블록은 정책이 리소스를 평가할 때 적용할 조건을 정의합니다. 하나의 정책 정의에는 여러 개의 조건문이 있을 수 있습니다.
• 하나의 리소스에 여러 정책이 할당될 수 있으며 각각 독립적으로 평가됩니다.
• 여러 정책 효과가 겹칠 경우 가장 엄격한 규칙이 우선 적용됩니다.
• if 조건블록 안에는 여러 가지 논리 연산자를 넣을 수 있습니다.연산자타입설명

  not	{조건 또는 연산자}	not은 조건 결과를 반대로 뒤집습니다 (true → false, false → true).
  allOf	[조건 목록]	allOf는 모든 조건이 참(true)이어야 합니다. (즉, 논리 AND 연산처럼 동작)
  anyOf	[조건 목록]	anyOf는 하나라도 조건이 참(true)이면 됩니다. (즉, 논리 OR 연산처럼 동작)

 

# 예시: 이 JSON은 Azure Policy에서 특정 조건을 만족하는 리소스의 생성을 차단(deny) 하도록 정의한 정책 규칙 (policyRule)입니다. 
{
  "if": {
    "allOf": [
      {
        "field": "location", ### location이 허용된 지역 목록에 포함되지 않은 경우
        "notIn": "[parameters('listOfAllowedLocations')]"
      },
      {
        "field": "location",
        "notEquals": "global" ### location이 "global"이 아닌 경우
      },
      {
        "field": "type", ### type이 Microsoft.AzureActiveDirectory/b2cDirectories가 아닌 경우
        "notEquals": "Microsoft.AzureActiveDirectory/b2cDirectories"
      }
    ]
  },
  "then": { #### 위 세 조건이 모두 true일 때, effect: deny에 따라 리소스 생성을 거부합니다.
    "effect": "deny"
  }
}

 

1) Nested logical operations

• "Nested logical operations"는 논리 연산자(allOf, anyOf, not)를 서로 겹쳐서(nested) 사용하는 것을 말합니다. 이 방식을 사용하면 복잡한 조건을 구성할 수 있습니다.

2) Conditions

• 정책이 리소스를 평가할 때 사용하는 기준입니다. Azure Policy의 조건은 리소스의 속성(예: 위치, 태그, 이름 등)이 특정 기준에 맞는지 확인합니다. 조건이 만족되지 않으면 정책에 따라 리소스가 차단(deny)될 수 있습니다.
  1. Value 조건: 고정된 값 자체를 검사합니다. ex) 현재 시간이 2025년 말 이전인지 확인 : { "value": "[utcNow()]", "less": "2025-12-31T23:59:59Z" }
  2. Count 조건: 배열에서 조건을 만족하는 항목이 몇 개인지를 세어 검사합니다. ex) 태그 중에 env: production이 하나 이상 있는지 확인 : "count": { "field": "tags", "where": { "field": "tags['env']", "equals": "production" }, ...

3) Policy functions

• 함수(Functions)는 정책 규칙 내에 추가 로직을 넣을 때 사용합니다. 정책 정의 내 policyRule 부분이나 정책 이니셔티브에서 매개변수 값 할당 시에 사용할 수 있습니다.
• Azure Resource Manager(ARM) 템플릿에서 제공하는 함수들은 대부분 정책 규칙에서 사용 가능하지만, 일부 정책 전용 함수와 사용자 정의 함수는 제외됩니다.
• utcNow() 함수는 정책 규칙 내에서 사용할 수 있으며, ARM 템플릿과 달리 기본값(defaultValue) 외부에서도 사용할 수 있습니다.
• 정책에서만 사용 가능한 함수 예시기능설명

  addDays(dateTime, numberOfDaysToAdd)	● dateTime: [필수] 문자열 - Universal ISO 8601 DateTime 형식 'yyyy-MM-ddTHH:mm:ss.FFFFFFFZ'의 문자열입니다. ● numberOfDaysToAdd: [필수] 정수 - 추가할 일 수입니다.
  Field(fieldName)	● fieldName: [필수] 문자열 - 검색할 필드의 이름입니다. ● If 조건에서 평가된 리소스에서 해당 필드의 값을 반환합니다. ● 주로 and와 함께 사용하여 평가 중인 리소스의 필드를 참조합니다.
  requestContext().apiVersion	정책 평가를 트리거한 요청의 API 버전을 반환합니다. 리소스 생성/업데이트 시 평가를 위한 PUT/PATCH 요청에 사용된 API 버전입니다. 기존 리소스에 대한 규정 준수 평가 시에는 항상 최신 API 버전이 사용됩니다.
  policy()	평가 중인 정책에 대한 정보를 반환합니다. 반환되는 객체의 속성으로는 "assignmentId", "definitionId", "setDefinitionId", "definitionReferenceId" 등이 있습니다.
  ipRangeContains(range, targetRange)	● range: [필수] 문자열 - IP 주소 범위를 지정합니다. ● targetRange: [필수] 문자열 - 확인할 IP 주소 범위를 지정합니다. 지정한 targetRange가 range 내에 포함되는지 여부를 부울 값으로 반환합니다. 빈 범위를 사용하거나 IP 패밀리를 혼합하는 것은 평가 실패를 초래합니다.
  current(indexName)	카운트 표현식 내에서만 사용할 수 있는 특수 함수입니다.

11-3. Effect types (then blocks)

• Azure Policy의 then 블록(Effect 부분)은 조건이 맞을 때 어떤 동작을 할지 정의합니다.
• 동기 평가: 리소스 요청 처리 시 즉시 정책을 평가하고, 결과에 따라 처리합니다.
• 비동기 평가: 리소스 요청과는 별개로 정책을 평가하여 로그나 자동 배포를 처리합니다.
•  
• 수동 평가: 사용자가 직접 정책 준수 상태를 인증합니다.효과 (Effect)설명평가 타입

  disabled	정책을 비활성화합니다. 이 경우 정책 할당은 적용되지 않으며, 평가도 수행하지 않습니다.	동기 평가 (Synchronous)
  append	생성/업데이트 시 요청 리소스에 필드를 추가합니다. (현재는 거의 modify로 대체됨)	동기 평가
  modify	생성/업데이트 시 리소스 또는 구독의 속성/태그를 추가, 수정, 제거하여 정책 준수를 강제합니다.	동기 평가
  deny	정책 위반 시 리소스 요청을 차단합니다.	동기 평가
  denyAction	대규모 리소스 작업 중 특정 작업(현재 DELETE만 지원)을 차단합니다.	동기 평가
  audit	비준수 리소스를 발견하면 경고 이벤트를 생성하지만 요청은 차단하지 않습니다.	비동기 평가 (Asynchronous)
  auditIfNotExists	특정 관련 리소스가 없으면 감사를 수행하는 효과입니다.	비동기 평가
  deployIfNotExists	조건 충족 시 템플릿 배포를 실행하여 필요한 리소스를 자동 생성합니다.	비동기 평가
  manual	사용자가 직접 준수 여부를 확인하고 수동으로 상태를 설정하는 효과입니다.	수동 평가 (Manual attestation)

 

✅ 12. Azure Policy 를 통한 리소스 평가

12-1. 평가 시점(Evaluation timing)

- Azure에서 정책을 할당할 때, 특히 기존 리소스에 새 정책을 적용하는 브라운필드 시나리오(Brownfield scenario)에서는, 정책 준수 상태를 검사하는 Compliance scan의 동작 방식과 타이밍을 이해하는 게 중요합니다.
    1) 자동 전체 스캔 (Automatic full scan) : 매 24시간마다 자동으로 전체 리소스에 대해 실행됩니다.
    2) 브라운필드 수동 스캔 (Manual scan for Brownfield) : 이미 존재하는 리소스에 새 정책을 적용할 때(브라운필드 시나리오) 직접 수동으로 스캔을 실행할 수 있습니다. 이때 az policy state trigger-scan 명령어를 사용해 컴플라이언스 스캔을 강제로 시작할 수 있습니다.

• 새 정책을 할당하면 정책이 즉시 적용되지 않고 최대 30분 정도 지연될 수 있습니다. 그 이유는 Azure Resource Manager(ARM)의 캐시가 세션 데이터를 저장하기 때문이며, 이 캐시 때문에 정책 적용이 늦어질 수 있습니다. 이 문제를 해결하려면 Azure에서 로그아웃 후 다시 로그인하면 캐시가 갱신되어 정책이 바로 적용됩니다.
• 스캔 검사가 시작된 후, 규정 준수 검사가 완료되는데 걸리는 시간은 여러 요인에 따라 달라집니다.
  1. 정책 정의(Policy definitions)의 크기와 복잡성
  2. 정책이 적용되는 리소스 범위(Scope size)
  3. 시스템 부하(System load) : 규정 준수 검사는 우선순위가 낮은 작업입니다. 즉, 시스템이 더 중요한 작업으로 가득 차면 검사 시간이 더 오래 걸릴 수 있습니다.
  4. 동기식 스캔(Synchronous scan) 특성 : 스캔은 동기적으로 실행되는데, 우선순위가 낮아 시스템이 바쁘면 지연됩니다. 그래서 스캔 완료 시간이 작거나 간단한 정책, 작은 범위라도 길어질 수 있습니다.

12-2. 리소스 규정 준수 상태 (Resource compliance states)

• 평가 결과에 따라 각 리소스는 아래 중 하나의 준수 상태(compliance state)를 받게 됩니다.
  1. Non-compliant (비준수): 정책조건에 맞지 않은 경우
  2. Compliant (준수) : 정책을 잘 지키고 있는 리소스
  3. Error (오류) : 템플릿 문제나 평가 과정에서 에러가 발생한 경우
  4. Conflicting (충돌) : 같은 범위(scope)에 두 개 이상의 정책이 서로 상충되는 규칙을 가지고 있는 경우입니다. 예를 들어, 두 정책이 같은 태그를 서로 다른 값으로 추가하려고 할 때입니다.
  5. Protected (보호됨) : denyAction 효과가 할당되어 리소스가 보호되고 있는 상태입니다. 예를 들어 삭제가 차단된 리소스입니다.
  6. Exempted (면제됨) : 정책에서 면제되어 평가 대상에서 제외된 상태
  7. Unknown (알 수 없음) : 수동(manual) 평가 효과가 할당된 경우 기본 상태입니다. 준수 여부가 자동으로 확인되지 않은 상태입니다.
• 복수 리소스/정책 상태 관리 : 여러 리소스나 여러 정책이 서로 다른 준수 상태를 가질 때, 각 리소스와 정책 할당별로 개별 평가가 이루어집니다. Azure Policy는 여러 상태 중 우선순위를 정해, 어떤 상태가 더 중요하게 보일지 판단합니다.이 우선순위는 위에서 나열한 순서대로입니다. (예: Non-compliant가 Compliant보다 우선)
• 준수율 : 준수율은 Compliant + Exempted + Unknown를 총 리소스로 나누어 계산합니다. 총 리소스에는 Compliant, Non-compliant, Unknown, Exempted, Conflicting, Error 상태에 해당하는 모든 리소스를 포함합니다.
  • 준수율 계산 방법 : Compliant + Exempted + Unknown) 상태인 리소스 수 ÷ 전체 리소스 수

12-3. 시행 모드 (Enforcement Mode)

• enforcementMode는 정책 할당(policy assignment)의 속성으로, 특정 정책 효과(policy effects)의 적용을 비활성화할 수 있게 해줍니다.
• 정책 효과를 실제로 적용하거나 Azure 활동 로그(Activity log)에 기록을 남기지 않고, 기존 리소스에 정책이 어떻게 작용할지 테스트할 수 있습니다. 정책을 철저히 테스트한 후 enforcementMode를 Enabled로 변경할 수 있습니다. 이를 "What If" 시나리오라고 부르며, 안전한 배포 관행에 부합합니다.
• Disabled 효과와는 다릅니다. disabled는 리소스 평가 자체를 아예 하지 않도록 막지만, enforcementMode는 평가를 하되 정책 효과를 실제로 적용하지 않습니다.
• 만약 정책 또는 정책 모음에 enforcementMode가 지정되지 않으면 기본값 Default가 사용됩니다. deployIfNotExists 정책의 경우, enforcementMode가 DoNotEnforce로 설정되어 있어도 수동 수정 작업(remediation tasks)을 시작할 수 있습니다.

12-4. 정책 시행 및 안전한 배포 모범 사례 (Policy enforcement and safe deployment best practices)

• 충분한 테스트 없이 기존 프로덕션 환경(실제 서비스가 돌아가는 환경)에 정책을 바로 적용하면, 정책 때문에 원하지 않는 문제들이 발생할 수 있습니다. 그래서 정책을 코드처럼 다루는 것이 중요합니다. 정책 정의를 코드로 관리하며 (예: 소스 컨트롤에 저장), 변경할 때마다 테스트와 검증을 꼭 수행해야 합니다.
• Best practies는 크게 두 가지 핵심 원칙으로 나뉩니다:
  1. enforcementMode Disabled로 새 정책 할당 시작하기
     • deny(거부)나 modify(수정) 같은 강제 정책을 바로 적용하는 대신, 처음에는 enforcementMode를 Disabled로 설정해 정책을 할당합니다. 이렇게 하면 실제로 작업을 막거나 수정하지 않고도 정책의 준수 상태(compliance 상태)를 확인하고 결과를 평가할 수 있습니다. (what-if)
  2. 정책을 '배포 링(Deployment Rings)' 방식으로 점진 적용하기
     • 한꺼번에 큰 범위에 정책을 적용하지 말고, 작은 범위부터 점점 확대하는 방식입니다. 예를 들어 먼저 테스트 환경이나 개발 환경에 정책을 적용해 잘 작동하는지 확인한 후, 그 다음 프로덕션 환경의 일부 리소스에 적용해보고, 마지막으로 전체 프로덕션 환경에 적용합니다.
• 다음 다이어그램은 Azure Policy 할당에 대한 안전한 배포 모범 사례 프레임워크를 적용하는 방법을 보여줍니다.

1. 정책 정의 만들기 (Create definition) : 정책을 만들되, 최상위 범위(root)인 테넌트(전체 조직 단위) 수준에서 정의합니다. 이 단계는 정책의 ‘틀’을 만드는 단계입니다.
2. 정책 할당 만들기 (Create assignment) : 정책을 한 번에 전체에 적용하지 말고, “Ring 1~5”처럼 여러 개의 그룹(또는 범위)으로 나누어 점진적으로 적용(예: 테스트 그룹 → 개발 그룹 → 일부 운영 그룹 → 전체 운영 그룹) 하고, enforcementMode = Disabled로 설정해서 what if 모드를 시행합니다.
3. 정책 준수 확인 (Compliance check) 및 애플리케이션 정상 작동 확인 (Application health check) : Ring 5 범위 안에서 정책이 잘 적용됐는지, 리소스들이 정책을 잘 따르고 있는지 확인하고, 정책이 리소스에 이상한 영향을 주지는 않는지 확인합니다.
4. 나머지 Ring에도 반복 적용 (Repeat for each ring - Non-production) : Ring 4, Ring 3... 이렇게 운영이 아닌 환경(Non-production)에 점점 적용해 나갑니다.
5. 필요 시 정책 수정 (Update assignment - Optional) : 테스트 결과를 보고 정책을 수정하거나 할당 범위를 바꿔야 할 수도 있습니다. 수정 후 다시 Ring 5에 할당하지만 이번에는 enforcementMode = Enabled로 바꿔서 실제로 정책이 적용되도록 합니다.
6. 3번 반복 : 정책 준수 재확인, 애플리케이션 정상 작동 재확인을 합니다.
7. 운영 환경에도 반복 적용 (Repeat for production rings) : 테스트 환경에서 문제가 없음을 확인했다면, 이제 운영 환경(Production)에도 적용합니다. 이때도 Ring을 작게 나누고, 점점 확장하는 방식으로 적용합니다.

✅ 13. secure-azure-resources-with-rbac (Azure RBAC(Azure 역할 기반 액세스 제어)로 Azure 리소스 보안)

13-1. Azure 구독

• 하나의 Azure 구독은 하나의 Microsoft Entra 디렉터리(예전 이름: Azure Active Directory)와 반드시 연결됩니다. 이 디렉터리에 있는 사용자, 그룹, 애플리케이션만 그 구독 내의 리소스를 관리할 수 있습니다.
• Azure는 로그인(SSO)과 권한 관리에 Microsoft Entra ID를 사용합니다.

13-2. Azure RBAC란?

• Azure RBAC (Role-Based Access Control)는 Azure의 리소스에 누가, 어디까지, 무엇을 할 수 있는지를 세밀하게 제어할 수 있는 권한 관리 시스템입니다. 역할 할당의 범위는 관리 그룹, 구독, 리소스 그룹 또는 단일 리소스일 수 있습니다. 부모 범위에서 할당된 역할은 역할 내에 포함된 하위 범위에 대한 액세스를 부여합니다.
• Azure RBAC는 허용 모델입니다 : 🔓 "명시적으로 허용된 작업만 수행할 수 있다"는 의미입니다. 아무 역할도 할당되지 않으면, 기본적으로 아무 리소스에도 접근할 수 없습니다. 즉, 역할이 할당되면 Azure RBAC는 읽기, 쓰기 또는 삭제와 같은 특정 작업을 수행하도록 허용합니다.
• Actions vs NotActions : A zure RBAC의 역할 정의는 두 가지 구성 요소를 조합하여 실제로 허용되는 작업(Effective Permissions) 을 계산합니다. 🧮 허용된 작업 = Actions - NotActions
  1. Actions : 이 역할이 허용하는 작업 목록 (예: *는 모든 작업 허용)
  2. NotActions : Actions 중에서도 제외할 작업 목록 (예: 삭제 금지 등)
• Azure RBAC 변경 사항에 대한 활동 로그
  • 감사 및 문제 해결을 위해 Azure RBAC(Azure 역할 기반 액세스 컨트롤) 변경 사항을 분기별로 검토합니다. 변경 사항은 Azure 활동 로그에 로깅됩니다.

 

 

• 앞의 다이어그램에서 구독은 하나의 Microsoft Entra 테넌트에만 연결됩니다. 하나의 리소스 그룹은 여러 개의 리소스가 있을 수 있지만, 단 하나의 구독에만 연결됩니다.
• Azure Portal에서 ID 및 액세스 관리라고도 하는 IAM(액세스 제어) 창에서 해당 영역에 액세스할 수 있는 사용자와 그 역할을 볼 수 있고, 액세스 권한을 부여하거나 제거할 수 있습니다.
• Azure RBAC는 역할 할당(Role Assignment)을 통해 "누가(Who)", "무엇을 할 수 있고(What)", "어디까지(Where)" 할 수 있는지를 정의하여 Azure 리소스에 대한 세밀한 접근 제어를 가능하게 합니다. 세 가지가 결합되면, 예를 들어 “사용자 A가 리소스 그룹 X에서 Contributor 역할을 갖는다”라는 방식으로 작동합니다.
  1. 보안 주체 (Who) : 액세스 권한을 부여할 사용자/그룹/애플리케이션
  2. 역할 정의 (What) : 어떤 작업을 할 수 있는지 정의하는 권한 모음. Azure에는 사용할 수 있는 기본 제공 역할이 여러 개 있습니다. 네 가지 기본 제공 역할은 다음과 같습니다. 기본 제공 역할이 조직의 특정 요구 사항을 충족하지 않는 경우 사용자 지정 역할을 만들면 됩니다. - Onwer(소유자) : 모든 권한 + 액세스 위임 가능 - Contributor (기여자) : 생성, 수정, 삭제 가능 (액세스 위임 제외) - Reader (읽기 권한자) : 리소스 읽기(보기) 전용 - User Access Administrator (사용자 액세스 관리자) : 다른 사용자에게 권한 부여/제거 가능
  3. 범위 (Where) : 권한이 적용될 리소스의 위치. Azure의 범위는 계층적 구조이며, 상위에서 부여한 권한은 하위로 상속됩니다.
• 역할 할당 (Role Assignment)
  • 누구, 무엇, 어디를 결정했으면 이러한 요소를 결합하여 액세스 권한을 부여할 수 있습니다. 역할 할당은 액세스 권한을 부여하기 위해 특정 범위에서 보안 주체에게 역할을 바인딩하는 프로세스입니다. 액세스 권한을 부여하려면 역할 할당을 만듭니다. 액세스 권한을 철회하려면 역할 할당을 제거합니다.
  • Azure에는 역할 할당에 사용할 수 있는 기본 제공 역할이 70개 이상 있습니다.

 

✅ 14. 사용자가 Microsoft Entra 셀프 서비스 암호 재설정을 통해 암호를 초기화할 수 있도록 허용

14-1. SSPR(셀프 서비스 암호 재설정)

• SSPR을 사용하는 이유는 무엇인가요? Microsoft Entra ID에서 이미 로그인된 사용자는 암호를 변경할 수 있습니다. 그러나 로그인하지 않았거나 암호를 잊어버렸거나 만료된 경우 암호를 다시 설정해야 합니다. SSPR을 통해 사용자는 웹 브라우저 또는 Windows 로그인 화면에서 암호를 다시 설정하여 Azure, Microsoft 365 그리고 인증에 Microsoft Entra ID를 사용하는 그 밖의 애플리케이션에 대한 액세스 권한을 다시 얻을 수 있습니다. SSPR은 사용자가 지원 센터에 전화하지 않고도 암호 문제를 직접 해결할 수 있으므로 관리자의 부하를 줄입니다. 또한 잊어버리거나 만료된 암호가 생산성에 미치는 영향이 최소화됩니다. 사용자는 관리자가 암호를 다시 설정할 수 있을 때까지 기다릴 필요가 없습니다.
• SSPR(자기 암호 재설정) 작동 방식 : 사용자는 암호 재설정 포털로 직접 이동하거나 로그인 페이지에서 계정에 액세스할 수 없음 링크를 선택하여 암호 재설정을 시작합니다. 재설정 포털에서 다음 단계를 수행합니다.
  1. 지역화(Localization) : 포털은 사용자의 브라우저 로캘 설정을 확인하여, SSPR 페이지를 사용자에게 적합한 언어로 표시합니다.
  2. 검증(Verification) : 사용자가 사용자 이름을 입력하고 CAPTCHA를 전달하여 봇이 아닌 사용자인지 확인합니다.
  3. 신원 인증(Authentication) : 사용자는 신원을 인증하는 데 필요한 데이터를 입력합니다. 코드를 입력하거나 보안 질문에 대답할 수 있습니다.
  4. 암호 재설정(Password Reset) : 사용자가 인증 테스트를 통과하면 새 암호를 입력하고 확인할 수 있습니다. 암호 재설정을 허용하기 전에 사용자의 ID를 확인하는 것이 중요합니다. 관리자는 SSPR을 구성할 때 사용할 방법을 선택할 수 있습니다. 사용자가 쉽게 사용할 수 있는 방법을 선택할 수 있도록 이러한 방법 중 두 개 이상을 사용하도록 설정합니다.
     • 인증방법: 모바일 앱 알림 또는 모바일 앱 코드 (Microsoft Authenticator), 메일, 휴대폰, 사무실전화, 본인확인질문
     • 최소 인증 방법 수 필요: 사용자가 설정해야 하는 최소 메서드 수를 하나 또는 두 개 지정할 수 있습니다. 사용자가 정해진 최소 개수만큼 인증 방법을 등록하면 SSPR(암호 재설정 기능)에 정상 등록된 상태가 돼요. 두 개 이상의 인증 방법을 권장합니다. 관리자 역할이 있는 계정에는 강력한 2단계 인증(2FA) 정책이 항상 적용됩니다.
  5. 알림(Notification) : 사용자에게 재설정 완료 메시지가 전송되어 변경 사실을 알립니다. 관리자는 사용자 암호 변경 시 알림 방식을 선택할 수 있습니다. 다른 관리자가 암호를 재설정하면 모든 관리자에게 알림: 다른 관리자가 암호를 다시 설정하면 모든 관리자에게 알림이 제공됩니다.

14-2. 라이선스 요구사항

• Microsoft Entra ID에는 Premium P1과 Premium P2 두 가지 버전이 있습니다. 로그인한 사용자는 어떤 버전이든 암호를 변경할 수 있습니다. 하지만 로그인하지 않았거나, 암호를 잊었거나, 만료된 경우에는 SSPR(암호 셀프 서비스 재설정)을 사용하려면 P1 또는 P2 라이선스가 필요합니다. 비즈니스용 Microsoft 365 앱에서도 SSPR 기능을 사용할 수 있습니다.
• 온-프레미스 Active Directory와 클라우드 Microsoft Entra ID가 연동된 하이브리드 환경에서는, 클라우드에서 암호를 변경할 때 이 변경사항이 온-프레미스 디렉터리에 반영되어야 하는데, 이 기능 역시 P1 또는 P2 라이선스에서 지원됩니다. 즉, SSPR을 제대로 활용하려면 적어도 Premium P1 라이선스 이상이 필요합니다!

14-3. SSPR 배포 옵션

• SSPR 배포 시 두 가지 주요 옵션이 있습니다. 두 옵션 모두 비밀번호 쓰기 저장 기능을 지원해, 암호 변경 내용을 온-프레미스 Active Directory에 반영할 수 있습니다. 회사 합병이나 분할 상황에서, 서로 다른 도메인의 사용자에게 맞는 방식을 각각 적용하기 위해 두 옵션을 병렬로 사용할 수도 있습니다.:
  1. Microsoft Entra Connect (기존 온-프레미스 연동용)
  2. 클라우드 동기화(cloud sync)

14-4. SSPR 출시 범위

• 셀프 서비스 암호 재설정이 사용하도록 설정됨 속성에 대한 세 가지 설정은 다음과 같습니다.
  1. 없음: Microsoft Entra 조직의 어떤 사용자도 SSPR을 사용할 수 없습니다. 이 값은 기본값입니다.
  2. 선택됨: 지정된 보안 그룹의 멤버만 SSPR을 사용할 수 있습니다. 이 옵션을 사용하여 구성을 테스트하고 예상대로 작동하는지 확인할 수 있는 대상 사용자 그룹에 대해 SSPR을 사용하도록 설정할 수 있습니다. 광범위하게 배포할 준비가 되면 모든 사용자가 SSPR에 액세스할 수 있도록 속성을 사용으로 설정합니다.
  3. 전체: Microsoft Entra 조직의 모든 사용자는 SSPR을 사용할 수 있습니다.

 

 

 

문제!

문 1) Microsoft Entra ID의 일부이지만 AD DS에서 찾을 수 없는 구성 요소는 무엇인가요?

1. 페더레이션 서비스와 타사 서비스. <- 정답
2. 리소스를 찾기 위한 DNS(도메인 이름 시스템) 통합입니다.
3. 디렉터리 액세스에 LDAP를 사용합니다.

구성 요소Microsoft Entra IDAD DS설명

페더레이션 서비스 및 타사 서비스	✅ 있음	❌ 없음	Google, Facebook 등 타사 서비스와 연동 및 SSO 기능 제공
DNS(도메인 이름 시스템) 통합	✅ 있음	✅ 있음	도메인 컨트롤러 및 리소스 탐색에 DNS 사용
LDAP를 통한 디렉터리 액세스	❌ 사용 안 함	✅ 사용함	AD DS는 LDAP 기반, Entra ID는 REST API 기반

문2) 3Microsoft Entra ID에서는 두 가지 유형의 그룹을 정의할 수 있습니다. 한 가지 유형은 공유 리소스에 대한 구성원과 컴퓨터 액세스를 관리하는데 사용되는 보안 그룹입니다. 다른 한 가지 그룹 유형은 무엇인가요?

: 공유 사서함, 일정, SharePoint 사이트 등에 대한 액세스 권한을 제공하는 Microsoft 365 그룹

 

문3) Microsoft Entra 그룹 기반 라이선스로 대규모 관리가 더욱 쉬워집니다. 일반적으로 그룹 구성원 자격을 변경하고 나서 얼마 후에 라이선스 수정이 적용되나요?

: 구성원 자격 변경 후 몇 분 이내

 

문4) 리소스 그룹 수준에서 작업 또는 설정이 적용되면 리소스 그룹 내의 리소스는 어떻게 되나요?

: 이 설정은 현재 및 미래의 리소스에 적용됩니다.

 

문5) Azure 정책은 어떤 수준에서 할당할 수 있나요?

: 관리 그룹, 구독 및 리소스 그룹

 

문6) Azure에서 역할 정의는 무엇인가요?

: 사용자, 그룹 또는 애플리케이션에 할당할 수 있는 특정 이름의 권한 모음

 

문7) Azure에서 범위의 상속 순서는 무엇입니까?

: 관리 그룹, 구독, 리소스 그룹, 리소스

 

문8) 관리자가 지난주에 해당하는 역할 할당 보고서를 생성해야 하는 경우를 가정하겠습니다. Azure Portal의 어디에서 해당 보고서를 생성할까요?

: 활동 로그를 검색하고 역할 할당 만들기(roleAssignments) 작업을 기준으로 필터링합니다.

 

문9) 사용자가 SSPR에 등록된 것으로 간주되는 경우는 언제인가요?

: 암호를 재설정하는 데 필요한 메서드 수를 최소한 등록했습니다.

 

문10) Microsoft Entra 조직에서 SSPR을 사용하도록 설정하는 경우

:사용자는 로그인할 수 없을 때 암호를 다시 설정할 수 있습니다.

 

 

 

 

 

Azure AZ-104 공부하기 3. Azure 내 스토리지 구현 및 관리

Azure AZ-104 공부하기 3. Azure 내 스토리지 구현 및 관리