Entra ID 자동화 #1 전체 그림: 테넌트, 디렉터리 객체, JML 수명 주기
Microsoft Graph 실무 입문 시리즈에서 메일, 파일, Teams를 코드로 다뤘습니다. 이번 트랙은 그 기반에 있는 계층, 즉 신원(identity) 관리 자체를 자동화하는 이야기입니다. 계정 생성, 그룹 관리, 접근 정책, 권한 부여. 조직의 IT 운영에서 가장 반복적이고 가장 실수 비용이 큰 영역이며, 그래서 자동화의 투자 대비 효과가 가장 확실한 영역이기도 합니다.
Entra ID: Azure AD의 현재 이름 #
먼저 이름 정리부터. Microsoft Entra ID는 Azure Active Directory(Azure AD)의 현재 이름입니다. 2023년에 개명됐고, 제품 자체는 연속적입니다. 오래된 문서와 도구 이름(AzureAD PowerShell 모듈 등)에는 옛 이름이 남아 있어서, 검색할 때 두 이름을 모두 알고 있어야 합니다.
Entra ID가 하는 일은 한 문장으로 요약됩니다. “누가(인증) 무엇을 할 수 있는가(인가)를 조직 단위로 관리하는 클라우드 디렉터리.” Microsoft 365의 모든 로그인이 여기를 거치고, 사내 SaaS의 SSO도, 우리가 만드는 앱의 로그인도 여기에 붙일 수 있습니다. 참고로 온프레미스의 Active Directory(AD DS)와는 다른 제품입니다. 많은 조직이 둘을 동기화해서 함께 쓰지만, 이 시리즈는 클라우드 쪽인 Entra ID를 다룹니다.
디렉터리의 구조: 테넌트와 네 가지 객체 #
자동화 대상을 정확히 알려면 구조부터 잡아야 합니다.
- 테넌트(tenant): 조직 하나의 디렉터리 인스턴스입니다. 회사가 Microsoft 365를 계약하면 테넌트가 하나 생기고, 그 안의 모든 것이 이 경계 안에서 관리됩니다.
- 사용자(user): 직원 계정과 외부 협력자(게스트) 계정입니다.
userPrincipalName,employeeId,department같은 속성을 갖고, 이 속성들이 뒤에서 다룰 자동화의 연료가 됩니다. - 그룹(group): 권한, 라이선스, 앱 접근을 묶어서 배포하는 단위입니다. 보안 그룹과 Microsoft 365 그룹 두 종류가 있습니다.
- 애플리케이션(app registration / service principal): 사람이 아닌 주체입니다. 우리가 만드는 자동화 스크립트도 여기 등록된 앱 신원으로 동작합니다.
- 디바이스(device): 조직에 등록된 PC와 모바일 기기입니다. 조건부 액세스에서 “회사 관리 기기인가"를 판단하는 근거가 됩니다.
자동화 관점에서 이 구조가 의미하는 것은 하나입니다. 모든 객체가 API로 조회·생성·수정 가능한 리소스라는 것. 관리 포털에서 클릭으로 하는 모든 일에는 대응하는 Graph API 엔드포인트가 있습니다.
JML: 계정 자동화의 뼈대 모델 #
계정 관리 업무는 셋으로 정리됩니다. 업계 표준 용어로 JML(Joiner-Mover-Leaver)이라고 부릅니다.
| 단계 | 상황 | 해야 할 일 |
|---|---|---|
| Joiner (입사) | 새 구성원 합류 | 계정 생성, 라이선스 할당, 그룹 배정, 초기 자격 증명 전달 |
| Mover (이동) | 부서·직무 변경 | 이전 접근 회수, 새 접근 부여, 속성 갱신 |
| Leaver (퇴사) | 구성원 이탈 | 접근 차단, 라이선스 회수, 데이터 이관, 계정 정리 |
이 세 흐름을 수작업으로 하면 어떻게 되는지는 모두가 압니다. 입사자는 첫 주에 권한이 없어 놀고, 이동자는 예전 부서 권한을 계속 들고 다니고, 퇴사자의 계정이 몇 달씩 살아 있습니다. 마지막 것은 단순 비효율이 아니라 보안 사고의 표준 시나리오입니다. 이 시리즈의 2편(사용자 수명 주기)과 3편(그룹)이 이 JML을 코드로 만드는 방법을 다룹니다.
도구 지형: 무엇으로 자동화하는가 #
Entra ID 자동화 도구는 세 층으로 정리됩니다.
- Microsoft Graph API: 모든 것의 기반입니다. REST 엔드포인트(
https://graph.microsoft.com/v1.0/...)와 언어별 SDK가 있고, 이 시리즈의 코드도 Graph 기준입니다. 파이썬 SDK 셋업은 Graph 실무 입문 #3에서 다뤘습니다. - Microsoft Graph PowerShell: 관리 작업의 실무 표준입니다.
Connect-MgGraph로 시작하는 cmdlet들이 Graph API의 래퍼로 동작합니다. 일회성 정리 작업이나 IT 관리자 스크립트에는 이쪽이 빠릅니다. 옛 AzureAD·MSOnline 모듈은 폐기 수순이므로 새 스크립트에 쓰지 않습니다. - IaC(Terraform 등): 그룹, 조건부 액세스 정책, 앱 등록처럼 “구성"에 해당하는 것들은 코드로 선언하고 리뷰를 거쳐 적용하는 방식이 어울립니다. 정책을 코드로 관리하는 접근은 4편에서 다시 나옵니다.
기준은 이렇게 잡으면 됩니다. 반복 실행되는 수명 주기 작업은 Graph API(스크립트·서비스), 일회성 관리 작업은 PowerShell, 상태를 갖는 구성은 IaC.
라이선스: 기능이 티어에 묶여 있습니다 #
Entra ID 자동화를 설계할 때 라이선스를 모르면 “만들었는데 우리 테넌트에서 안 되는” 상황을 만납니다. 큰 그림만 정리합니다.
| 티어 | 이 시리즈에서 관련된 기능 |
|---|---|
| Free (M365 기본 포함) | 사용자·그룹 CRUD, 기본 SSO |
| P1 | 동적 그룹, 조건부 액세스, 셀프서비스 그룹 관리 |
| P2 | P1 + PIM(주요 기능), Identity Protection, 액세스 리뷰 |
| Entra ID Governance | 수명 주기 워크플로, 고급 자격 관리 |
시리즈에서 각 기능을 다룰 때 필요한 티어를 그때그때 명시하겠습니다. 설계 단계에서 “이 자동화가 요구하는 최소 라이선스"를 확인하는 습관이 필요합니다.
준비물: 자동화용 앱 신원 #
이 시리즈의 코드는 사람 로그인 없이 도는 자동화를 전제로 하므로, 애플리케이션 권한(application permission)으로 동작하는 앱 등록이 필요합니다. 만드는 절차와 delegated vs application 권한의 구분은 Graph 실무 입문 #2에서 자세히 다뤘으니 그대로 따라 하면 됩니다. 이 트랙에서 추가로 강조할 것은 두 가지입니다.
- 권한은 목적별 최소로. 사용자 관리 자동화에는
User.ReadWrite.All이 필요하지만, 읽기만 하는 리포트 스크립트에 그 권한을 주면 안 됩니다. 자동화 용도별로 앱을 나누는 것이 사고 반경을 줄입니다. - 자격 증명은 시크릿보다 인증서, 가능하면 관리 ID(managed identity). Azure 안에서 도는 자동화라면 시크릿 자체를 없앨 수 있습니다.
이 시리즈의 지도 #
| 편 | 주제 |
|---|---|
| 1 (이 글) | 구조, JML, 도구, 라이선스 |
| 2 | 사용자 수명 주기: 생성, 비활성화, 라이선스, 수명 주기 워크플로 |
| 3 | 그룹: 동적 그룹, 그룹 기반 라이선스, 접근 관리 |
| 4 | 조건부 액세스: 정책을 코드로 관리하기 |
| 5 | PIM과 감사: 상시 관리자 없애기, 로그 자동화 |
정리 #
- Entra ID는 Azure AD의 현재 이름이고, 조직의 인증과 인가를 관리하는 클라우드 디렉터리입니다. 온프레미스 AD와는 별개 제품입니다.
- 테넌트 안의 사용자, 그룹, 앱, 디바이스가 자동화 대상이고, 포털의 모든 작업에는 대응하는 Graph API가 있습니다.
- 계정 관리 자동화의 뼈대는 JML(입사·이동·퇴사) 모델입니다. 퇴사 처리 누락은 비효율이 아니라 보안 사고입니다.
- 도구는 반복 작업 = Graph API, 일회성 관리 = PowerShell, 구성 = IaC로 나눠 잡습니다.
- 동적 그룹과 조건부 액세스는 P1, PIM과 액세스 리뷰는 P2, 수명 주기 워크플로는 Governance 라이선스가 필요합니다. 설계 전에 확인해야 합니다.