Active Directory 위임 모범 사례
Active Directory 위임은 특권 그룹의 구성원 자격이 아니라 OU 수준에서 작업에 특화된 권한을 부여하여, 각 역할이 실제 업무에 필요한 범위에 정확히 맞춰지도록 합니다. 공식적인 위임 모델을 건너뛰면 문서화되지 않은 액세스 제어 항목이 누적되어 검토에서 벗어나며, 누구도 Domain Admins를 만지지 않아도 악용 가능한 상태로 바뀔 수 있습니다. 작동하는 모델에는 역할, 범위가 지정된 OU, 그리고 지속적인 검토가 필요합니다.
IBM X-Force 2025 위협 인텔리전스 인덱스에 따르면 침입의 약 30%는 유효 계정의 오남용에서 시작됩니다. The IBM X-Force 2025 Threat Intelligence Index Active Directory의 기본 제공 특권 그룹은 해당 자격 증명(크리덴셜)을 특히 위험하게 만듭니다. 이유는 그 그룹에 포함된 모든 계정에 도메인 전체 읽기 및 쓰기 권한을 부여하기 때문입니다.
일상적인 비밀번호 재설정을 위해 Domain Admins에 추가된 헬프 데스크 기술자는, 실제 업무가 무엇이든 간에 AD 인프라를 유지보수하는 엔지니어와 동일한 수준의 접근 권한을 갖게 됩니다.
Active Directory 위임은 OU(조직 구성 단위) 수준에서 작업별 권한을 할당함으로써, 권한 요구와 범위 간의 불일치를 해결합니다. 이는 도메인 관리자나 계정 연산자 같은 권한 있는 그룹 멤버십을 통해 권한을 부여하는 방식 대신 사용됩니다.
이 가이드는 AD 위임 모델을 구축하는 방법, Delegation of Control Wizard(위임 제어 마법사)를 사용해 위임된 권한을 적용하는 방법, 그리고 위임된 권한이 검증되지 않은 액세스로 누적되지 않도록 유지하는 운영 모범 사례를 다룹니다.
Active Directory 위임이란 무엇인가요?
Active Directory 위임을 사용하면 관리자가 사용자를 권한 있는 그룹(예: Domain Admins 또는 Account Operators)에 추가하지 않고도, 사용자 또는 그룹에 대해 작업별로 필요한 수준의 높은 권한을 부여할 수 있습니다.
해당 그룹에는 도메인 전체에 대한 권한이 부여됩니다. 즉, Domain Admins에 포함된 모든 계정은 실제 업무 요구사항이 얼마나 구체적이고 좁더라도, 디렉터리의 모든 개체를 읽고 쓸 수 있습니다.
Active Directory 위임 특정 조직 단위(OU) 또는 개체 클래스에 액세스 제어 항목(ACE)을 적용하여, 권한을 해당 역할에 필요한 범위로 정확히 한정합니다.
특정 OU에서 비밀번호를 재설정하도록 위임받은 헬프 데스크 기술자는 그 권한을 해당 범위 내에서만 갖습니다. 권한은 다른 OU로 확장되지 않으며, 해당 계정은 어떤 권한이 높은 그룹에도 나타나지 않습니다.
AD 위임 모델을 개발하는 방법
위임 모델은 환경 내의 관리 역할, 각 역할이 보유하는 권한, 그리고 해당 권한을 한정하는 OU 구조를 정의합니다. 그렇지 않으면 위임된 권한이 비공식적으로 누적되어 감사가 불가능해집니다.
1단계: 역할 생성
먼저 두 가지 계층의 관리자 역할: 서비스 관리자와 데이터 관리자.
- 서비스 관리자는 Active Directory 인프라 자체를 관리합니다. 이 계층에는 Enterprise Admins, Domain Admins, 그리고 AD 복제, 도메인 서비스 또는 중요 시스템에서 사용하는 서비스 계정을 유지하는 모든 계정이 포함됩니다. 이 계층의 모든 구성원은 도메인의 모든 개체에 영향을 줄 수 있으므로, 환경에서 허용하는 범위 내에서 최대한 소규모로 유지하세요.
- 데이터 관리자는 기반 인프라를 건드리지 않고 디렉터리 내의 개체를 관리합니다. 이 계층은 범위(scope)별로 구성하세요:
- 1계층(지역 관리자): 정의된 지리적 지역 또는 사업부 내에서 사용자 및 그룹 개체를 관리합니다.
- 2계층(부서 관리자): 특정 부서 또는 기능 내에서 사용자 계정을 관리합니다.
- Tier 3 (헬프 데스크): 지정된 OU 내에서 비밀번호 재설정, 계정 잠금 해제와 같은 제한된 작업만 수행합니다.
역할 수를 적게 유지하세요. 추가되는 모든 역할은 문서화하고, 할당하며, 검토해야 하는 권한 세트를 생성합니다. 역할이 과도하게 늘어나는 현상은 성숙한 AD 환경에서 통제되지 않은 액세스가 누적되는 주요 원인입니다.
2단계: 책임을 할당합니다
각 역할에 대해 어떤 권한이 적용되는지, 어떤 개체 클래스에 대해 적용되는지, 그리고 어떤 OU에서 적용되는지 문서화하세요. 각 할당을 다음 세 가지 차원에서 매핑합니다:
- 빈도: 해당 역할이 작업을 수행하는 빈도입니다. 이는 검토 주기와 자동화 도구가 필요한지 여부를 결정합니다.
- 중요성: 해당 작업이 비즈니스에 매우 중요하느냐, 아니면 일상적인 관리 업무이냐에 따라 초기 부여에 대한 승인 기준(임계값)이 달라집니다.
- 난이도: 해당 작업이 기술적 판단을 필요로 하는지, 아니면 일반 업무 담당자(일반ist)가 수행할 수 있는지에 따라 교육 및 온보딩 요구 사항이 달라집니다.
일반적인 작업에는 표준 Active Directory 액세스 제어 목록(ACL)을 사용하고, Force Change Password 또는 Apply Group Policy 같은 작업에는 확장 권한(Extended Rights)을 사용하세요. 권한 위임 시점에 모든 할당 내용을 문서화하십시오. 문서화되지 않은 권한은 액세스 검토 및 감사에서 보이지 않습니다.
3단계: OU 보안 모델을 정의합니다
권한을 적용하기 전에 위임 경계를 반영하는 OU 계층 구조를 설계하세요. 권한이 있는(privileged) 계정과 관리 계정은 자신이 관리하는 개체와 분리된 OU에 배치하십시오. 예를 들어, 관리하는 사용자와 동일한 OU에 저장된 Domain Admin 계정은 OU 수준의 privilege escalation 공격의 대상이 될 수 있습니다.
최상위 수준에서는 지리적, 조직적 또는 기능적 등 관리 모델에 맞는 OU를 생성하세요. 각 최상위 OU 안에는 데이터 관리자 범위에 해당하는 하위 OU를 생성합니다.
각 범위마다 전용 보안 그룹을 만들고, 개별 계정이 아니라 해당 그룹에 위임 권한을 적용하세요.
이 구조는 상속 기반 권한 상승을 제한합니다. 즉, 하위 OU 수준에서 위임된 관리자는 해당 수준에서 권한이 명시적으로 부여되지 않는 한 상위 또는 동일 계층(형제) OU의 개체에 영향을 줄 수 없습니다. 조직 모델이 변경될 때마다 OU 구조를 재검토하세요.
Netwrix Auditor는 하이브리드 Microsoft 환경 전반에서 액세스 및 변경 이벤트의 변경 전·후 값을 기록합니다. 데모를 요청하세요.
Active Directory에서 제어 권한을 위임하는 방법
Active Directory Users and Computers (ADUC)의 Delegation of Control Wizard는 위임된 권한을 적용하는 데 사용되는 주요 도구입니다. 선택한 OU 또는 컨테이너에 ACL 항목을 직접 기록하며, 나중에 해당 OU의 Security 탭에서 검토할 수 있는 권한 할당을 생성합니다.
1단계: Delegation of Control Wizard 열기
ADUC에서 View 메뉴 아래의 Advanced Features가 아직 활성화되어 있지 않다면 이를 활성화합니다. 위임을 적용할 OU로 이동한 다음 해당 OU를 마우스 오른쪽 버튼으로 클릭하고 "Delegate Control"을 선택하세요. 이 마법사는 선택한 OU와 그 안의 항목에만 권한을 적용하며, 상위 OU는 영향을 받지 않습니다.
2단계: 사용자 또는 그룹 선택
사용자 또는 그룹 창에서 위임된 권한을 받는 관리자 역할을 나타내는 security group를 추가합니다.
그룹 기반 할당을 사용하면 OU의 ACL을 직접 수정하지 않고 멤버십을 변경하여 액세스를 추가하거나 제거할 수 있어 권한 구조를 감사 가능하고 되돌릴 수 있게 유지합니다.
개별 계정에 할당된 권한은 ACE를 생성하며, 누군가가 수동으로 제거하지 않는 한 역할 변경이나 퇴사(offboarding) 이후에도 계속 유지됩니다.
3단계: 위임할 작업 선택
사용자 계정 생성 또는 삭제, 암호 재설정, 사용자 정보 읽기, 그룹 멤버십 관리와 같은 일반적인 작업에는 "다음 일반 작업 위임"을 선택하세요.
Force Change Password 또는 Apply Group Policy 같은 확장 권한을 포함하여 미리 정의된 목록에 없는 권한의 경우, "위임할 사용자 지정 작업 만들기"를 선택하세요.
4단계: 위임 범위를 지정합니다
사용자 지정 작업의 경우 위임이 적용되는 개체 클래스(사용자 개체, 컴퓨터 개체 또는 그룹 개체)를 정의하고, 권한이 OU 자체에 적용되는지 OU 내부의 개체에 적용되는지, 또는 둘 다에 적용되는지 결정합니다. 역할의 문서화된 책임에 필요한 만큼 범위를 최대한 엄격하게 제한하세요.
5단계: 완료하고 확인합니다
마법사가 완료되면 ADUC에서 OU를 마우스 오른쪽 버튼으로 클릭한 다음 속성을 선택하고 보안 탭을 엽니다. 예상한 ACE가 올바른 권한과 범위로 목록에 있는지 확인하세요.
위임된 그룹의 구성원으로 로그인한 뒤, 허용된 작업과 제외된 작업을 모두 시도하여 위임이 의도한 대로 정확히 작동하는지 확인하세요.
Active Directory 위임(Delegation) 모범 사례
위임 모델과 Delegation of Control Wizard가 기술적 기반을 제공합니다. 이러한 모범 사례는 환경과 조직이 변화하더라도 해당 기반의 보안을 유지합니다.
할당(assignment) 시점에 모든 위임을 문서화하세요
각 Delegation of Control Wizard 실행 후, 해당 액세스를 사용하기 전에 중앙 액세스 레지스트리에 OU, 권한을 받는 그룹, 부여된 구체적인 권한, 그리고 업무상 정당성을 기록하세요.
해당 Wizard는 자체 로그를 생성하지 않습니다. 즉, 작업(액션), 승인자, 또는 권한 부여의 근거를 기록하지 않은 채 OU의 보안 디스크립터에 ACE를 적용합니다. 문서화되지 않은 ACE는 액세스 검토와 감사 중에 보이지 않게 되고, 인사 변경 후에는 맥락을 알 수 있는 유일한 출처를 잃게 됩니다.
스프레드시트, ITSM 티켓, 또는 전용 IAM 시스템 모두 그 목적을 충족합니다. 중요한 것은 액세스가 실제로 사용되기 전에 문서가 존재해야 하며, 기술적 범위뿐 아니라 비즈니스 정당성을 포함해야 한다는 점입니다.
개별 계정이 아니라 보안 그룹에 위임 권한을 할당하세요
권한이 개별 계정에 할당되면, 해당 사용자가 조직을 떠나거나 역할을 변경하거나 계정이 비활성화된 이후에도 OU의 ACL에 그대로 남아 있게 됩니다.
ACE는 계정의 SID에 계속 연결된 상태로 남아 있으며, 표준 온보딩(퇴직/이탈) 절차의 일부로 자동으로 해제되지 않습니다.
보안 그룹에 할당된 권한은 오프로딩(이탈/퇴직) 시 그룹에서 계정을 제거함으로써 해지됩니다. 이는 표준 IAM 워크플로에 잘 맞고, 깔끔한 감사 추적을 만들며, 팀이 성장하거나 변화해도 확장 가능합니다.
그룹 멤버십 변경은 Security 로그에 이벤트를 생성합니다. 반면 OU에서 ACE를 직접 수정하는 경우에는, 동일한 수준의 증거를 생성하려면 특정 감사 정책 설정이 필요합니다.
모든 위임에 최소 권한 원칙을 적용하세요
각 역할이 문서화된 작업을 수행하는 데 필요한 권한만 부여하세요. 가장 좁은 OU 범위를 사용하고, 작업에 필요한 가장 구체적인 권한 집합을 선택하십시오.
위임에 적용되는 principle of least privilege 는 부모 OU가 아니라 관련 하위 OU로 권한 범위를 한정하고, 광범위한 쓰기 액세스가 아닌 특정 확장 권한을 선택하는 것을 의미합니다. 또한 여러 경우를 포괄하기 위해 더 넓은 권한을 부여하는 대신, 복합 작업을 여러 개의 별도 위임으로 분리하는 과정도 포함됩니다.
위임을 적용한 후에는, 위임된 그룹의 구성원으로 로그인해 의도한 작업만 성공하고 제외된 작업은 실패하는지 확인하며 테스트하세요.
위임된 권한을 최소한 분기마다 검토하세요
중요한 OU에서 ACE를 나열하고 각 항목이 현재의 업무 요구 사항을 여전히 반영하는지 확인할 수 있도록 정기적인 액세스 검토 일정을 계획하세요.
(ADUC에서 고급 기능이 활성화된 경우에만 표시되는) 대상 OU의 보안(Security) 탭을 열고 명시적 항목과 상속된 항목을 모두 확인하세요. 활성 구성원이 없거나 문서화된 목적이 없는 그룹에 속한 ACE는 모두 제거합니다.
Active Directory에서 위임된 권한 감지 규모에 맞게 수행하려면 PowerShell 또는 목적에 맞게 제작된 도구가 필요합니다. 기본 ADUC 인터페이스는 현재 권한 상태는 표시하지만, ACE가 언제 생성되었는지 또는 누가 생성했는지는 기록하지 않습니다.
분기별 검토는 권한 드리프트가 쌓여, 환경을 감사하기 어렵게 만드는 문서화되지 않은 액세스 백로그로 이어지기 전에 이를 포착합니다.
특권 작업에는 별도의 계정을 사용하세요
관리자가 위임된 작업을 수행할 때 이메일 및 일상 업무에 사용하는 계정과 분리된 전용 관리자 계정을 사용하도록 요구하세요.
일반 계정은 일상적인 작업을 처리하며 일반 사용자 자격 증명의 위험 프로필을 갖습니다. 반면 관리자 계정은 권한 상승 작업이 필요할 때만 활성화되어야 하며, 이메일, 웹 브라우징, 또는 신뢰할 수 없는 콘텐츠를 처리하는 어떤 워크스테이션에도 접근해서는 안 됩니다.
privileged account management 전략은 관리자 계정을 일상 사용 자격 증명과 분리함으로써 자격 증명 기반 측면 이동에 대한 가장 효과적인 통제 중 하나입니다.
권한 범위 격리는 단일 자격 증명을 탈취당했을 때 공격자가 얻을 수 있는 내용을 제한하며, 특권 계정 활동이 일상 사용자 행위와 분리되어 감사 가능하도록 만듭니다.
고권한 위임에 대해 just-in-time 액세스로 전환하세요
최고 권한 역할의 경우, 상시 위임 액세스를 완전히 제거하고 이를 just-in-time access 로 대체하세요. 승인된 작업이 진행되는 동안에만 권한이 부여되며, 작업이 끝나면 권한이 자동으로 회수됩니다.
상시 위임 액세스는, 해당 권한을 가진 모든 계정이 실제로 얼마나 드물게 사용되더라도 자격 증명 탈취, 피싱 또는 측면 이동을 통해 영구적으로 노출된다는 것을 의미합니다.
just-in-time 액세스는 손상된 자격 증명이 위임 권한을 악용할 수 있는 시간 창을 축소하고, 분기별 검토에서 커버해야 하는 ACE 범위를 줄이며, 승인 및 세션 기록을 생성해 규제 환경에서 감사 증거를 강화합니다.
Netwrix Privilege Secure는 상시 관리자 계정을 just-in-time 방식의 특권 세션으로 대체하며, 세션은 자동으로 회수됩니다. 데모를 요청하세요.
특정 권한을 위임할 때 고려 사항
아래의 각 권한 유형에는 보안상의 영향이 있으며, 이는 Delegation of Control Wizard에서 드러나지 않습니다.
비밀번호 재설정 및 계정 잠금 해제
먼저 OU 경계를 확인하세요. Domain Admin 계정 또는 서비스 계정이 포함된 OU에서 비밀번호를 재설정하도록 위임된 역할은 자격 증명 재설정 경로를 통해 tier-zero 액세스에 연결될 수 있습니다. 권한 범위는 기술적으로는 올바르지만, OU 범위는 그렇지 않습니다. 위임을 적용하기 전에 해당 OU에 표준 사용자 계정만 포함되어 있는지 확인하세요.
그룹 구성원 관리
이 위임을 적용하기 전에 보호 대상 구성원(Domain Admins, Enterprise Admins, Account Operators)에 대해 적용 범위에 포함된 그룹을 감사(점검)하세요.
Active Directory의 SDProp 프로세스는 60분마다 해당 계정에 AdminSDHolder ACE를 다시 적용하여, 사용자 지정 위임을 조용히 덮어씁니다.
해당 계정에 적용한 어떤 위임도 유지되지 않으며, 이를 적용하려는 시도 자체가 조사해야 한다는 신호입니다.
그룹 정책 개체(Group Policy Object) 권한
그룹 정책 위임은 세 가지 권한(생성, 편집, 연결)으로 나뉘며, 기본적으로는 연결 권한을 다른 권한과 함께 부여하면 안 됩니다.
GPO를 연결하면 대상 OU 및 그 하위(자식) 모든 개체에 설정이 즉시 적용됩니다. 링크 권한을 별도의 상향된(권한 상승) 위임으로 간주하고, 자체 승인도 별도로 받으십시오.
컴퓨터 계정 관리
컴퓨터 계정 관리를 위임하기 전에 ms-DS-MachineAccountQuota를 0으로 설정하십시오. 기본값이 10이면 인증된 모든 사용자가 위임 없이도 도메인에 컴퓨터를 조인할 수 있습니다.
또한 표준 컴퓨터 계정 위임에는 SPN 쓰기 권한이 포함된다는 점도 주의하십시오. 역할에서 이를 특별히 요구하지 않는 한 이 권한은 위임(부여) 항목에서 제외하세요. SPN 쓰기 권한이 있으면 Kerberoasting 노출이 발생할 수 있습니다.
Kerberos 인증 위임 설정
Kerberos 위임은 Active Directory의 제어 권한 위임과는 별도의 속성입니다. Delegation of Control Wizard를 통해 설정되지 않으며, 위임 검토 중에 놓치기 쉽습니다.
위임된 계정을 감사할 때, 해당 계정에 무제한 Kerberos 위임(unconstrained Kerberos delegation)도 적용되어 있는지 확인하세요. 그렇다면 OU와 무관하게 해당 계정을 Tier 0로 취급해야 합니다. 무제한 위임이 설정된 손상된(침해된) 서비스는 도메인 컨트롤러가 해당 서비스에 전달한 모든 TGT를 노출하기 때문입니다.
Netwrix가 Active Directory 위임을 지원하는 방법
Active Directory 위임은 환경 전반에 걸쳐 제어 권한을 분산합니다. 그리고 분산된 모든 권한은 검토되지 않거나 문서화되지 않은 채로 남아 있으면 잠재적인 보안 공백이 될 수 있습니다.
역할은 시간이 지나면서 권한이 누적되고, 그룹은 보유해서는 안 되는 멤버를 추가로 갖게 되며, 특정 프로젝트에 대해 적용된 ACE는 그 프로젝트가 끝난 뒤에도 한참 동안 OU에 그대로 남아 있을 수 있습니다.
권한 변경 사항에 대한 지속적인 가시성이 없으면 보안 팀은 위임 모델이 강제해야 하는 액세스 상태(보안 태세)를 유지할 수 없습니다.
위임된 액세스를 관리하려면 실시간으로 권한 변경을 감지하고, 악용 가능한 수준이 되기 전에 드리프트를 식별하며, 액세스 검토 및 컴플라이언스 감사를 위한 방어 가능한 증거를 생성해야 합니다.
Netwrix Auditor 는 AD 권한 변경을 실시간으로 모니터링하고, 액세스 검토와 규제 근거를 뒷받침하는 변경 전/후의 감사 추적(로그)을 생성합니다.
Netwrix Access Analyzer 중첩 그룹과 OU 상속을 통해 실질적 액세스를 매핑하여, 감사 결과(지적 사항)가 되기 전에 과도하거나 오래된 위임 권한을 사전에 노출합니다.
두 도구가 함께 제공하는 지속적인 가시성으로, 실제로 발생하는 변경 사항과 그 변경이 만들어내는 액세스 상태를 모두 보안 팀이 파악할 수 있습니다.
데모를 요청하세요 Netwrix가 Active Directory 위임을 관리하고, 권한 변경(permssion drift)을 감지하며, 방어 가능한 감사 추적(audit trail)을 유지하는 데 어떻게 도움이 되는지 확인해 보세요.
Active Directory 위임 모범 사례에 대한 자주 묻는 질문
공유하기