LDAP(Active Directory)로 사내 계정 통합하기: SSO·RBAC·Zero Trust까지의 실무 설계

# LDAP(Active Directory)로 사내 계정 통합하기: SSO·RBAC·Zero Trust까지 실무 설계 계정 통합은 로그인 수를 줄이는 편의가 아니다. 조직의 신원과 권한을 하나의 질서로 수렴시키는 인프라 설계다. LDAP(Active Directory)를 중심에 두면, 인증의 흐름(SSO), 권한의 형태(RBAC), 신뢰의 조건(Zero Trust)이 분리된 도구의 집합이 아니라 하나의 구조로 정렬된다. ## 1. 현상: 계정이 늘어날수록 보안과 운영은 함께 무너진다 현장에서 계정 문제는 대체로 다음과 같은 형태로 드러난다. - 서비스마다 계정이 따로 존재해 퇴사 처리가 누락된다. - 권한 요청은 티켓으로만 흐르고, 실제 시스템 권한은 사람 기억에 의존한다. - MFA는 일부 서비스에만 적용되어 가장 약한 고리가 전체를 결정한다. - 감사 시점에 "누가 무엇을 할 수 있는가"를 즉시 설명하지 못한다. 이 현상은 도구가 부족해서가 아니라, 신원과 권한이 분해된 채 자라난 결과다. 도구의 추가는 문제를 잠시 덮을 뿐, 구조를 세우지 않으면 복잡도는 비용과 위험으로 환원된다. 현장 데이터는 단순하다. SaaS가 20개를 넘기면 계정 저장소가 5개 이상으로 분산되고, 퇴사자 권한 회수 누락이 월 단위로 발생한다. 이는 관리자의 성실성 문제가 아니라, 단일 진실 공급원(SSOT)이 부재한 구조적 문제다. ## 2. 구조: AD/LDAP는 사람-조직-정책을 연결하는 데이터 모델이다  LDAP은 프로토콜이고, Active Directory는 그 구현이자 운영 체계다. 중요한 것은 "AD를 쓰는가"가 아니라, AD가 조직의 신원을 표현하는 데이터 모델이 되는가다. ### 2.1 디렉터리의 최소 설계 원칙: OU는 행정, 그룹은 권한 많은 조직이 OU를 권한으로 쓰다가 유지보수 불가능 상태에 이른다. 실무적으로 다음 원칙이 가장 견고하다. - OU(Organizational Unit): 위임과 행정 단위(부서/국가/사업부) 중심 - Group: 권한의 단위(애플리케이션 역할, 리소스 접근) 중심 - User/Computer: 식별자와 속성의 단위 OU는 조직 개편에 따라 흔들린다. 권한이 OU에 결박되면, 개편이 곧 대규모 권한 변경으로 번역된다. 반면 그룹은 권한의 안정된 표현이며, 조직 변경과 분리해 유지할 수 있다. 권장 패턴은 다음과 같다. - 역할 그룹: `APP_SALESFORCE_SALESREP`, `APP_JIRA_ADMIN` - 리소스 그룹: `FS_FINANCE_RW`, `DB_ANALYTICS_RO` - 정책 그룹: `POL_MFA_REQUIRED`, `POL_BLOCK_LEGACY_AUTH` 그룹을 권한의 언어로 삼으면, 디렉터리는 단순한 주소록이 아니라 정책 적용의 좌표계가 된다. ### 2.2 동기화의 경계: 단일 저장소가 아니라 단일 기준 사내 환경은 온프레미스(AD), 클라우드(Azure AD/Entra ID, Google Workspace), 애플리케이션 디렉터리(Jira, GitLab)로 분기된다. 핵심은 "하나만 쓰자"가 아니라, 어디를 기준으로 둘 것인가다. - 인사 시스템: 재직 상태·조직·직무의 기준 - AD/Entra: 계정 수명주기·인증·그룹의 기준 - 각 SaaS: 애플리케이션 내부 권한의 표현(가능하면 그룹 연동) 실무에서는 HR → AD(프로비저닝) → IdP(SSO) → SaaS(SCIM) 흐름이 가장 예측 가능하다. 동기화 실패는 기술 문제가 아니라, 기준이 불명확할 때 발생한다. 기준이 둘이면 충돌은 필연이다. ## 3. 본질: SSO·RBAC·Zero Trust는 한 문장으로 귀결된다 SSO, RBAC, Zero Trust는 서로 다른 유행어가 아니다. 세 개념은 다음 한 문장으로 수렴한다. > 신원은 단일하게 식별되고, 권한은 역할로 제한되며, 접근은 조건에 의해 매 순간 재평가된다. ### 3.1 SSO: 로그인 통합이 아니라 인증의 단일 경로 확립 SSO의 실무 가치는 편리함보다 통제 가능성에 있다. 인증 경로가 하나로 모이면 다음이 가능해진다. - MFA 강제, 조건부 접근 정책의 중앙 적용 - 인증 로그의 일원화(탐지·감사) - 계정 잠금/회수의 즉시 반영 구현은 보통 AD를 IdP에 연동하고, SaaS는 SAML/OIDC로 붙인다. AD 자체가 SAML IdP가 되기보다는, AD를 기반으로 한 IdP(Entra ID, ADFS, Keycloak 등)를 두는 구성이 운영상 안정적이다. SSO 연결의 최소 체크리스트는 짧다. - NameID/subject 매핑: 이메일을 쓸지, 불변 ID를 쓸지 결정 - 그룹 클레임: 역할 부여를 토큰으로 전달할지, SCIM으로 동기화할지 결정 - 세션 정책: 인증 주기, 리프레시 토큰, 로그아웃 전파 범위 정의 SSO는 연결이 아니라 경로의 단일화이며, 경로가 단일해질 때 정책이 의미를 갖는다. ### 3.2 RBAC: 사람에게 권한을 주지 말고, 역할에 권한을 부여하라 RBAC의 실패는 대개 역할 정의가 아니라, 역할이 사람의 이름으로 변질될 때 발생한다. "홍길동_특별권한" 같은 예외는 시간이 지나면 규칙을 먹어치운다. 실무적 RBAC는 다음 순서를 따른다. 1) 업무를 행위로 분해한다(조회/등록/승인/배포). 2) 행위를 역할로 묶는다(읽기, 운영자, 승인자). 3) 역할을 그룹으로 구현한다(AD 그룹). 4) 사람은 그룹에만 소속된다(직접 권한 금지). 5) 예외는 만료일을 가진 임시 그룹으로 격리한다. 권한의 최소화는 구호가 아니라 표현 방식의 선택이다. 사람에게 직접 권한을 주는 순간, 권한은 문서가 아니라 기억이 된다. ### 3.3 Zero Trust: 불신이 아니라 조건의 명시다 Zero Trust는 누구도 믿지 않는다는 선언이 아니다. 믿음을 감정에서 떼어내어 조건으로 환원하는 작업이다. 실무에서 조건은 보통 다음 축으로 구성된다. - 사용자 위험: 이상 로그인, 탈취 의심 - 디바이스 신뢰: MDM 등록, 보안 상태(암호화, 패치) - 위치/네트워크: 국가, 익명 프록시, 사내망 여부 - 애플리케이션 민감도: 재무/인사/소스코드 등 - 행위: 다운로드, 권한 상승, API 토큰 발급 "누가"만으로 접근을 허용하지 않고, "누가 + 어떤 상태에서 + 무엇을 하려는가"로 접근을 결정한다. AD 그룹은 조건부 접근의 직접 조건이 되기도 하고, 최소한 정책 대상의 경계로 기능한다. ## 4. 함의: 운영 체계로 완성하는 통합 기술은 연결로 끝나지 않는다. 계정 통합은 운영 규율로 완성된다. 다음 로드맵은 규모가 다른 조직에도 비교적 잘 이식된다. ### 4.1 0단계: 계정 수명주기 정의 - 입사: HR 이벤트 → 계정 생성 → 기본 그룹 부여 → 장비 등록 → MFA 강제 - 이동: 부서/직무 변경 → 역할 그룹 재평가 → 기존 역할 회수 - 퇴사: 즉시 잠금 → 세션 무효화 → 토큰/키 회수 → 데이터 소유권 이전 "Mover(이동)"를 정의하지 않으면, 조직은 시간이 지날수록 권한이 누적되는 방향으로만 진화한다. ### 4.2 1단계: AD 정비 - 사용자 식별자: UPN/email 변경 가능성을 고려해 불변 ID(employeeID) 보관 - 그룹 규칙: 접두어로 목적을 고정(ROLE_, RES_, POL_) - 감사 가능성: 그룹 소유자와 검토 주기(분기/반기) 명시 이 단계에서 이미 "누가 무엇을 갖는가"의 70%가 결정된다. 디렉터리의 문법이 곧 조직의 문법이기 때문이다. ### 4.3 2단계: SSO 표준화 - SAML: 전통적 엔터프라이즈 SaaS에 강함 - OIDC: 현대 앱/모바일/내부 서비스에 유리 - SCIM: 계정/그룹 프로비저닝 자동화에 필수(가능한 곳은 반드시 적용) SSO만 붙이고 프로비저닝을 수동으로 남겨두면, 퇴사 누락은 형태만 바뀐 채 지속된다. SSO는 인증, SCIM은 수명주기다. ### 4.4 3단계: Zero Trust 적용 우선순위는 명확하다. 1) 레거시 인증 차단(기본 인증, 오래된 프로토콜) 2) MFA 강제(고위험 앱부터) 3) 디바이스 기반 접근(등록 기기만 허용) 4) 민감 데이터에 단계적 강화(다운로드 제한, 세션 제어) 정책은 한 번에 완성되지 않는다. 처음부터 완벽을 목표로 하면 예외가 폭발한다. "고위험부터, 측정 가능한 범위부터" 적용해야 한다. ### 4.5 4단계: 측정과 감사 통합의 성패는 대시보드에서 드러난다. - 퇴사 처리 리드타임: HR 이벤트 이후 계정 잠금까지의 시간 - MFA 적용률: 전체/고위험 앱/관리자 계정 구분 - 권한 검토 결과: 분기별 그룹 멤버십 변경량, 예외 그룹 잔존율 - 인증 실패 패턴: 공격 징후(비정상 국가, 반복 실패) 측정되지 않는 통제는 통제가 아니다. ### 4.6 구현 예시: OpenLDAP에 AD 스타일 그룹 스키마로 통합 AD를 직접 쓰지 못하는 환경(리눅스 중심, 폐쇄망 등)에서도 LDAP 기반 구조는 유지될 수 있다. 아래는 그룹 기반 RBAC를 상정한 LDIF 예시다. ```ldif dn: ou=People,dc=corp,dc=example,dc=com objectClass: organizationalUnit ou: People dn: ou=Groups,dc=corp,dc=example,dc=com objectClass: organizationalUnit ou: Groups dn: uid=jinho,ou=People,dc=corp,dc=example,dc=com objectClass: inetOrgPerson uid: jinho cn: Jinho Choi sn: Choi mail: jinho@corp.example.com employeeNumber: 20251231 dn: cn=ROLE_GITLAB_MAINTAINER,ou=Groups,dc=corp,dc=example,dc=com objectClass: groupOfNames cn: ROLE_GITLAB_MAINTAINER member: uid=jinho,ou=People,dc=corp,dc=example,dc=com ``` 이 구조에서 애플리케이션은 사용자 속성이 아니라 그룹 멤버십을 권한의 근거로 삼는다. 개인에게 권한을 직접 부여하는 유혹을 구조로 차단하는 셈이다. ## 결론: 계정 통합은 접근이 아니라 질서의 문제다 LDAP 기반 통합의 요지는 도구의 연결이 아니라, 신원과 권한과 조건을 한 언어로 기술하는 데 있다. SSO는 인증의 단일 경로를 만들고, RBAC는 권한을 역할로 고정하며, Zero Trust는 신뢰를 조건으로 환원한다. 이 셋이 한 구조로 결합될 때, 조직은 계정을 관리하는 것이 아니라 접근을 설계하게 된다.