1. Microsoft Entra ID 이해

Microsoft Entra ID 검사

Active Directory Domain Services == AD DS or Active Directory 그래서 이게 뭐냐:

• 사용자 계정, 암호 등의 데이터 저장
• 네트워크 사용자, 관리자, 기타 디바이스, 서비스 등등..에서 데이터 사용할 수 있게 함.
• Windows Server(도메인 컨트롤러)에서 서비스로 실행됨.

Microsoft Entra ID는 PaaS의 일부임. 클라우드에서 Microsoft 관리 디렉토리 서비스로 작동함. 고객이 소유, 관리하는 핵심 인프라에 속하지도 않고 IaaS도 아님! 구현에 통제력이 줄어들지만 배포/유지관리에 리소스를 할당하지 않아도 됨.

Microsoft Entra ID 쓰면… MFA(다단계 인증), ID보호, 셀프 서비스 암호 재설정 등의 AD DS에서 할 수 없던 것들도 가능함. 클라우드 기반 리소스에 안전하게 접근할 수 있는데 이걸 어케하냐?

• 앱 액세스 구성
• 클라우드 기반 Saas 앱에 SSO(Single SIgn-On) 구성
• 사용자, 그룹 관리
• 사용자 프로비전
• 조직 간 페러데이션
• ID 관리 솔루션
• 비정상적인 로그인 식별
• MFA
• 온프레미스 AD 구현을 MS ENtra ID로 확장
• 클라우드/로컬 앱의 프록시 구성
• 사용자, 장치의 조건부 액세스 구성

MS Entra는 별도의 Azure 서비스가 됨. 새 구독에 자동으로 포함되는 기본값은 무료 계층이라 불리며 비용 발생이 없음. MS Online 비즈니스 서비스(M365, MS Intune 등) 구독중이면 무료로 모두 접근 가능한 MS ENtra ID가 제공됨.

MS 계정으로 새 구독 만들면 기본 디렉토리 라고 MS Entra 테넌트가 자동으로 생기는거 봤제

고급 ID 관리 기능 쓰려면 유료버전 Entra ID 써야함. 고급 기능은 M365 구독으로 생긴 엔트라 인스턴스도 포함됨.

Entra ID는 VM 배포하고 AD DS 추가하고 도메인 컨트롤러 배포하는거랑 다름. 이건 웹 기반이고, 다른건 온프레미스 앱 기반임.

Microsoft Entra 테넌트

설계상 MS Entra ID는 다중 테넌트임. 개별 디렉토리 인스턴스 간 격리를 보장하기 위함임. 이는 세계에서 가장 큰 디렉토리인데… 100만개 디렉토리에 매달 10억건의 인증 요청이 이루어진다 함. 이런 맥락에서 봤을 때, ‘테넌트’ 라는 용어는 “MS Entra ID를 쓰는 MS 클라우드 서비스 구독에 등록한 회사/조직”을 의미함.

우리 학교 계정으로 Azure에 로그인 했을 때, 테넌트가 “영남대학교”라고 뜨는게 이 때문임.

근데 기술적인 관점으로 봤을 때는… 테넌트는 ‘개별 MS Entra 서비스’를 말함. Azure 구독 안에서 여러 테넌트를 만들 수 있음. 독립적인 환경에서 MS Entra 기능 테스트하려는 경우에는 여러 테넌트를 갖는 것이 편할 수 있음. 동일한 사용자, 앱, 그룹 등으로 여러 구독에서 리소스 관리하기 위해 하나의 테넌트를 여러 구독과 연결하기도 함.

각각의 테넌트는 고유한 DNS 도메인 이름이 할당됨. Azure 구독 생성에 쓰는 MS 계정 이름에서 파생되거나… 테넌트를 만들 때 명시적으로 제공됨. onmicrosoft.com이 항상 뒤에 접미사로 붙음.

동일한 테넌트에 여러 커스텀 도메인 추가하는게 일반적인 경우이다. 회사나 조직이 소유한 도메인을 씀. 테넌트는 사용자, 그룹, 앱 등의 보안 경계와 컨테이너 역할을 함. 단일 테넌트는 여러 구독을 지원할 수 있음.

그러니까.. 리소스를 모은게 리소스 그룹이라면 사람들, 앱 등을 모아놓은게 테넌트같은 느낌이랄까?

Microsoft Entra 스키마

스키마에는 AD DS보다 적은 개체 형식이 표함됨. 그러니까.. 컴퓨터 클래스의 정의는 없지만 디바이스 클래스는 포함됨. 디바이스를 Entra에 조인하는(포함시키는) 과정은 컴퓨터를 AD DS에 조인하는 과정과 꽤 다름. 스키마도 쉽게 확장할 수 있고, 확장명은 쉽게 복구할 수 있음(되돌릴 수 있음).

자.. 기존 컴퓨터 도메인 멤버 지원이 부족하다? Entra ID를 써서 GPO(Group Policy Obj)같은 기존의 관리기술로 PC/사용자 설정이 불가능하다는 말임. 대신 Entra ID, 서비스는 최신 관리의 개념을 정의함. 사용자, 디바이스, 앱 데이터를 저장/게시하고 인증과 권한 부여 처리하는 디렉토리 서비스를 제공하는게 주된 장점임. M365같은 기존 클라우드 서비스 배포를 기반으로 EntraID를 ID공급자로 쓰고 많은 사용자를 지원함.

EntraID는 OU(조직 구성 단위) 클래스를 포함하지 않음 → 온프레미스 AD DS 배포에서 자주 쓰는 ‘커스텀 컨테이너’의 계층 구조로 정렬이 불가능함. AD DS는 그룹 정책의 범위 지정과 위임에 쓰이기 때문에 크게 단점이 아님. 그룹 멤버의 자격에 따라 개체를 구성하고 동등한 정렬을 수행할 수 있음.

Application, servicePrincipal 클래스의 개체는 ENtra ID의 앱을 말함. Application 클래스의 개체 - 앱의 정의 servicePrincipal 클래스의 개체 - 테넌트에서 해당 인스턴스 구성 이 둘을 분리하는거임. 하나의 테넌트에서 서비스 주체 객체, 나머지 여러 테넌트에서 사용하는거 ㅇㅇ Entra ID는 해당 테넌트에 앱 등록할 때 서비스 주체 개체를 만듦.

Microsoft Entra ID 및 AD DS 비교

그럼 Entra ID는 AD DS의 클라우드 대용이냐? ㄴㄴ 다른 차이가 더 있음.

AD DS 특징

AD DS: 서버(물리적 or 가상)에 Windows Server 기반 Active Directory를 배포

일반적으로는 ‘디렉토리 서비스’로 여겨지지만, AD CS, AD LDS, AD FS, AD RMS 등의 Windows AD DIrectory 기술 제품군의 일부일 뿐임.

AD DS와 Entra ID 비교할 때 유의해야 할 AD DS의 특징:

• 계층적 X.500 기반 구조 사용, 진정한 디렉토리 서비스
• DNS를 사용해 도메인 컨트롤러와 같은 리소스 찾음
• LDAP(Lightweight Directory Access Protocol) 호출로 AD DS 쿼리, 관리
• 인증을 위해 Kerberos 프로토콜 사용
• 관리를 위해 OU, GPO 사용
• AD 도메인에 가입하는 PC를 나타내는 컴퓨터 개체 포함함
• 위임된 관리를 위해 도메인 간 트러스트 사용

Azure VM에 AD DS 배포 << 온프레미스 AD DS에 대한 스케일링 성능, 가용성 사용 가능함. ^ 근데 Entra ID는 사용되지 않음.

AD DS 스토리지에 C드라이브 쓰면 안되니까 ⇒ Azure VM에 AD DS 배포하려면 추가적인 Azure 데이터 디스크가 최소 하나는 필요함 ⇒ AD DS DB, log, sysvol 폴더 저장 등등에 사용하는 디스크 말하는거임 ⇒ 이 디스크에 대한 호스트 캐시 기본 설정은 없음으로 설정해야

Microsoft Entra ID의 특징

AD DS와 비슷한거도 많은데 차이도 많음. Azure VM에 AD 도메인 컨트롤러 배포, 온프레미스 도메인에 추가하는거랑은 다름.

Entra ID, AD DS 비교할 때 주의해야 할 Microsoft Entra ID의 특징:

• 주로 ID 솔루션임. HTTP, HTTPS 통신으로 인터넷 기반 앱 전용 설계됨.
• 다중 테넌트 디렉토리 서비스
• 사용자와 그룹은 플랫 구조(수평적 구조?)로 생성, OU/GPO 없음
• LDAP로 Entra ID 쿼리 불가능. 대신 REST API 사용 가능.
• Kerberos 인증 안씀 → SAML, WS-Federation, OpenID Connect 등의 HTTP/HTTPS 프로토콜을 통한 인증 → OAuth로 권한 부여
• 페더레이션 된 서비스 포함. 대표적으로 Facebook같은 서비스가 페더레이션 됨.

클라우드 앱 전용 디렉토리 서비스인 Microsoft Entra ID

클라우드 서비스를 배포하려 함. 사용자에게 인증과 권한 부여 뭐 이런거 하고싶으면 클라우드에 디렉토리 서비스도 있어야 그게 됨. 이거를 하려고 클라우드 서비스는 자기 MS Entra 테넌트를 만듦.

만약 하나의 조직에서 “둘 이상의” 클라우드 서비스 쓴다면? 각 서비스에 대해 별도의 디렉토리를 갖는 것 보다는 하나의 클라우드 디렉토리 갖는게 훨씬 더 편함.

아무튼 이렇게 MS 클라우드 서비스 포함하는 하나의 ID 서비스를 가졌다. Entra ID는 “1. 다른 ID 공급자” 또는 “2. 온프레미스 AD DS”를 사용해서 중앙 집중식 인증, 권한 부여를 제공하게 됨. Facebook, Google, Yahoo, MS Cloud Service와 같은 앱 쓸때 사용자에게 SSO 환경 제공도 가능.

“사용자 지정 앱에 대한 Entra ID 지원”을 구현하는 것은 꽤 복잡하고 범위도 넘어감. 하지만 Azure Portal, MS Visual Studio 2013 이상에서는 간단하게 구현 가능.

특히 Azure Portal의 인증/권한 블레이드에서, Azure App Service / Web Apps 기능에 대해 Entra 인증 쓰도록 설정 가능. 테넌트를 지정한다면 “해당 디렉토리에 계정이 있는 사용자만” 접근하도록 할 수 있음. 개별 배포 슬롯에 다른 인증 설정을 적용할 수도 있음. 자세한건 여기를 참고.

Microsoft Entra ID P1, P2 계획 비교

Entra ID P1 or P2 계층은 무료 버전 / Office365 버전보다 추가적인 기능을 제공함. 근데 프리미엄 버전에는 프로비저닝 당 추가 비용이 발생함. 이거 하려면 추가 라이센스를 구매 or MS Enterprise Mobility + Security 사용. 이는 Azure 정보보호, Intune의 라이센스 포함함.

Entra ID P2는 모든 기능 사용가능한 체험기간 제공함. P1에서 사용한 기능들은 다음과 같음.

• Self-service 그룹 관리
  • 그룹을 생성하고 관리하는 중간관리자 느낌의 그룹에 대한 관리를 간단화
  • 사용자는 다른 그룹에 가입 요청 생성 가능
  • 그룹 소유자는 요청 승인하고 멤버 자격 유지 가능
• 고급 보안 보고서, 경고
  • 이상 패턴의 고급 보고서를 보여주는 로그를 통해 클라우드 앱 접근 모니터링.
  • 기계 학습 기반
  • 보안 개선 + 잠재적 위협 예방
• MFA
  • Multi-Factor-Auth
  • 온프레미스, Azure 등의 앱에서 작동
  • 브라우저 기반이 아닌 앱에서는 작동 X
• MIM (Microsoft Identity Manager) 라이선싱
  • P1 or P2와 통합, 하이브리드 ID 솔루션
  • 온프레미스 인증 저장소 + Entra ID 연결
  • 온프레미스 LOB(기간 업무) 앱, SaaS 솔루션에 일관성있는 경험
• 99.9% Enterprise SLA
  • P1, P2 서비스 가용성 99.9% 보장
  • Entra Basic에 동일한 SLA 적용
• 쓰기 저장으로 암호 재설정
  • 셀프 서비스 암호 재설정은 AD 온프레미스 암호 정책 따름
• Microsoft Entra ID의 Cloud App Discovery
  • 자주 사용되는 클라우드 기반 앱 검색
• 디바이스, 그룹, 위치 기반 조건부 액세스
  • 여러 기준에 따라 중요한 리소스에 조건부 액세스 구성
• Microsoft Entra Connect Health
  • Entra ID 운영 인사이트 얻음
  • 경고, 성능 카운터 등등 ⇒ 포털에서 수집된 정보 제공

아래는 P2에서 제공하는 기능임. 위 P1의 기능들에 추가적으로 있는 기능들임.

• Microsoft Entra ID 보호
  • 사용자 계정 모니터링, 보호
  • 위험 정책, 로그인 정책 정의 가능
  • 사용자 동작 검토, 위험에 대한 플래그 지정
• Microsoft Entra Privileged Identity Management
  • 관리자 권한 사용자에 대한 추가 보안 구성
  • 영구 & 임시 관리자 정의
  • 관리자 권한으로 작업 시도될 때 마다 동작하는 정책 워크플로 정의

위 플랜들은 자주 변경되며 Microsoft 홈페이지에서 확인 가능함.

Microsoft Entra Domain Services 검사

대부분 조직의 LOB(기간 업무) 앱은 도메인을 구성하는 PC, 디바이스에 배포됨. 이런 조직들은 AD DS 기반의 자격 증명을 쓰고, 그룹 정책에서 관리함. Azure에서 앱을 실행하거나 이동할 때 중요한건 인증 서비스의 제공 방법임.

이를 구현하려면?

• (로컬 인프라 - Azure IaaS) 사이 VPN 구성
  • 인증 트래픽이 VPN을 통과하게 됨
• Azure에서 로컬 AD의 복제본 도메인 컨트롤러를 VM으로 배포
  • 복제 트래픽이 VPN을 통과
  • 인증 트래픽이 클라우드에 남음 두 방법 모두 비용이랑 작업이 늘어날 수 있음 ㅇㅇ

Microsoft에서는 위의 대안으로 Microsoft Entra Domain Services 제공함. Entra ID의 P1 or P2 계층의 일부로 실행됨. 도메인 서비스(그룹 정책 관리, 도메인 가입, Kerberos 인증 등)를 Entra 테넌트에 제공. 로컬 AD DS와 완전히 호환됨 → 클라우드에서 추가적인 작업(도메인 컨트롤러 배포/관리) 필요없음.

로컬 AD DS와 통합 가능하댔지? Entra Connect를 구현하면 온프레미스 AD DS와 Domain Services 모두 자격증명 활용 가능. AD DS가 로컬에 배포돼있지 않아도 됨. Entra Domain Services를 클라우드 전용 서비스로 사용하도록 선택 가능함. 온프레미스/클라우드에 도메인 컨트롤러 배포할 필요 없이 로컬의 AD DS와 유사한 기능 사용 가능.

예를 들어) 한 조직이 Entra 테넌트 만들고 Domain Services 쓰도록 설정하고, 온프레미스 리소스 / 테넌트 간 VPN 네트워크 배포하도록 선택 가능. VPN을 사용하도록 Domain Service를 설정 ⇒ 모든 온프레미스 사용자, 서비스가 Domain Services 사용 가능.

Domain Services의 이점

• 관리자가 도메인 컨트롤러 관리, 업데이트, 모니터링 안해도 됨
• 관리자가 AD 복제본 배포, 관리 할 필요 없음
• Entra ID가 관리하는 도메인에 대해서는 도메인/엔터프라이즈 관리자 그룹 필요없음

근데 이거 쓰려면 아래 제한 사항들을 알고 있어야 함.

• 기본 컴퓨터 AD 개체만 지원됨
• MS Entra Domain Services 도메인에 대한 스키마 확장은 불가능
• OU(조직 구성 단위) 구조는 수평적, 중첩 OU 지원 X
• 기본 GPO(그룹 정책 개체) 존재하며 PC와 사용자 계정에 대해 존재.
• 기본 제공 GPO 쓰는 OU를 대상으로 할 수 없음. WMI(Windows Management Instrumentation) 필터 또는 보안 그룹 필터링 불가.

Domain Services로 LDAP, NTLM 또는 kerberos 프로토콜 쓰는 앱을 온프레미스 → 클라우드로 자유롭게 마이그레이션 가능. 클라우드의 도메인 컨트롤러 or 로컬 인프라 VPN 없어도 MS SQL Server or SharePoint Server 앱을 VM에서 사용하거나 Azure IaaS 배포 가능.

Azure Portal로 Domain Services 사용 설정 가능. 디렉토리 크기에 따라 시간당 요금 청구됨.