Entra ID 자동화 #3 그룹 설계: 동적 그룹, 그룹 기반 라이선스, 액세스 패키지

앞 편에서 “사용자 자동화가 할 일은 올바른 그룹에 넣는 것"이라고 했습니다. 이번 편은 그 그룹 쪽 이야기입니다. 그룹을 잘 설계하면 라이선스, 앱 접근, 권한이 그룹 구조를 따라 저절로 흐르고, 잘못 설계하면 수백 개의 그룹을 손으로 관리하는 새로운 수작업이 생깁니다.

두 종류의 그룹: 보안 그룹과 Microsoft 365 그룹 #

Entra ID의 그룹은 크게 둘입니다.

자동화 설계의 관점에서 기준은 단순합니다. 접근 제어가 목적이면 보안 그룹, 협업 공간이 목적이면 M365 그룹. 멤버 구성 규칙도 다릅니다. 보안 그룹에는 사용자 외에 디바이스, 서비스 주체, 다른 보안 그룹(중첩)이 들어갈 수 있지만, M365 그룹의 멤버는 사용자만 가능합니다.

Graph로는 POST /groups로 만들고 POST /groups/{id}/members/$ref로 멤버를 넣습니다. 그런데 이 “멤버를 넣는 코드"를 쓰기 전에, 다음 절부터 볼 두 가지 장치로 그 코드 자체를 없앨 수 있는지 먼저 물어야 합니다.

동적 그룹: 멤버십을 코드가 아니라 규칙으로 #

동적 그룹(dynamic membership group)은 멤버 목록을 사람이 관리하지 않습니다. 속성 기반 규칙을 정의하면 Entra ID가 규칙에 맞는 사용자를 자동으로 넣고 뺍니다.

// 부서가 Engineering인 정직원
(user.department -eq "Engineering") and (user.employeeType -eq "Employee")

// 특정 도메인의 게스트 제외
(user.userType -eq "Member") and (user.accountEnabled -eq true)

2편에서 속성 표준화를 강조한 이유가 여기서 회수됩니다. department 값이 “Engineering"과 “엔지니어링"으로 섞여 있으면 동적 그룹은 절반만 잡습니다. 동적 그룹의 품질은 규칙이 아니라 속성 데이터의 품질입니다.

운영 특성 세 가지를 알아야 합니다.

• 라이선스: 동적 그룹의 고유 멤버 1인당 Entra ID P1이 필요합니다.
• 한도와 대상: 테넌트당 동적 그룹은 최대 15,000개이고, 멤버가 될 수 있는 것은 사용자와 디바이스뿐입니다.
• 지연: 멤버십 재계산은 즉시가 아닙니다. 속성 변경 후 반영까지 시차가 있으므로, “지금 즉시 이 사람을 넣어야 하는” 흐름에는 정적 그룹 + API가 맞습니다.

기준을 요약하면 이렇습니다. 속성으로 표현 가능한 소속(부서, 직군, 근무지)은 동적 그룹, 승인이 필요한 선택적 접근은 정적 그룹(또는 뒤의 액세스 패키지), 즉시성이 필요한 처리만 API 직접 조작.

그룹 기반 라이선스: 입장이 곧 할당, 퇴장이 곧 회수 #

그룹에 라이선스를 붙이는 것은 Graph의 POST /groups/{id}/assignLicense(또는 관리 센터)로 설정합니다. 이후에는 그룹 멤버십이 곧 라이선스 상태가 됩니다. 들어오면 할당되고 나가면 회수됩니다.

동적 그룹과 조합하면 강력해집니다. “Engineering 부서” 동적 그룹에 개발 도구 라이선스를 붙여 두면, 부서 이동(HR → 속성 변경 → 동적 그룹 재계산 → 라이선스 이동)이 사람 손 없이 완결됩니다. JML의 Mover 처리가 이 조합의 가장 큰 수혜자입니다.

운영에서 챙길 것은 할당 오류 모니터링입니다. 라이선스 재고가 부족하거나 서비스 플랜이 충돌하면 그룹 할당이 특정 사용자에게 실패한 상태로 남습니다. 그룹의 라이선스 오류 상태를 주기적으로 조회해 알림을 보내는 스크립트를 함께 둬야 합니다.

역할 할당 가능 그룹: 관리자 권한의 경계 #

그룹에 Entra ID 관리자 역할을 부여하려면 일반 그룹으로는 안 되고, 생성 시 isAssignableToRole: true로 만든 역할 할당 가능 그룹이어야 합니다. 이 그룹은 일반 그룹과 다르게 취급됩니다. 동적 멤버십을 쓸 수 없고, 멤버 관리 권한이 상위 역할로 제한됩니다. 속성 변경 하나로 관리자 권한이 부여되는 경로를 차단하기 위한 설계입니다. 이 그룹은 5편의 PIM과 조합되어 “그룹에 들어가면 관리자 후보가 되고, 활성화해야 권한이 켜지는” 구조의 재료가 됩니다.

액세스 패키지: 셀프서비스 접근 요청의 제품화 #

그룹 설계로 못 없애는 마지막 수작업이 “접근 요청 티켓"입니다. 프로젝트 X에 참여하게 됐으니 관련 그룹 세 개, SharePoint 사이트, 앱 두 개에 넣어 달라는 류의 요청입니다. Entra의 자격 관리(entitlement management)는 이것을 제품화했습니다. Governance 라이선스 기능입니다.

• 액세스 패키지(access package): 그룹, 앱, 사이트 접근을 하나의 신청 단위로 묶습니다.
• 신청 → 승인 흐름(관리자 또는 지정 승인자) → 자동 부여 → 만료와 갱신(기간 만료 시 자동 회수, 연장 신청)까지가 제품 기능입니다.
• 외부 협력자(게스트)에게 특히 유용합니다. 패키지 만료가 곧 게스트 접근 종료가 되므로, “프로젝트 끝난 외부 계정이 영원히 남는” 문제가 구조적으로 사라집니다.

IT 팀 관점의 효과는 명확합니다. 접근 요청 티켓이 셀프서비스 신청으로 바뀌고, 부여뿐 아니라 회수까지 자동이 됩니다. SRE 실무 #6에서 말한 셀프서비스 단계의 신원 관리 버전입니다.

정리 #

• 접근 제어는 보안 그룹, 협업 공간은 M365 그룹입니다. 멤버를 넣는 코드를 쓰기 전에 동적 그룹과 액세스 패키지로 그 코드를 없앨 수 있는지 먼저 확인합니다.
• 동적 그룹은 속성 기반 규칙으로 멤버십을 자동화합니다(P1, 사용자·디바이스만, 반영 지연 있음). 품질은 규칙이 아니라 속성 데이터가 결정합니다.
• 그룹 기반 라이선스는 입장 = 할당, 퇴장 = 회수를 만듭니다. 동적 그룹과 조합하면 부서 이동이 무인으로 처리됩니다. 할당 오류 모니터링이 짝입니다.
• 관리자 역할은 역할 할당 가능 그룹으로만 다루고, 이 그룹은 동적 멤버십이 금지되는 별도 보안 경계입니다.
• 선택적·기간제 접근은 액세스 패키지로 셀프서비스화합니다. 부여보다 값진 것은 자동 회수입니다.
• 다음 편은 로그인 순간의 방어선, 조건부 액세스 정책을 코드로 관리하는 법입니다.