Active Directory 복구: 최악의 시나리오 계획

조직의 단 36%만이 지난 12개월 동안 Active Directory (AD) 보안 평가를 수행했다고 합니다. 이는 The Netwrix 2026 Data and Identity Security Report에 따른 것입니다. 같은 조사에서 73%는 자신의 AD에 권한 상승을 허용하는 잘못된 구성이 없다고 완전히 확신하지 못한다고 밝혔습니다.

Microsoft Threat Intelligence는 위협 행위자가 78% 이상의 인간 운영 사이버 공격에서 도메인 컨트롤러를 침해하며, 평가되지 않은 환경이 남긴 취약점을 악용한다고 보고합니다.

이는 AD 재해 복구를 아이덴티티 복원력 문제로 만들며, 최악의 시나리오는 모든 도메인 컨트롤러(DC)가 다운되거나 복제가 손상되었거나 백업 자체가 암호화된 포리스트 전체 이벤트입니다.

백업 일정과 복구 계획은 서로 다른 것을 증명합니다. 일정은 데이터가 어딘가에 존재함을 증명합니다. 계획은 비즈니스가 압박 속에서도 해당 데이터를 기반으로 작동하는 디렉터리를 재구성할 수 있음을 증명하므로, 실용적인 계획은 견뎌야 할 최악의 실패 상황, 복구 순서 및 작동을 증명하는 테스트 주기를 정의합니다.

Active Directory 재해 복구란 무엇인가요?

Active Directory 재해 복구는 개별 객체 복구로 해결할 수 없는 전체 AD 포리스트 장애(포리스트 전체 중단, 손상 또는 침해 등)를 복원하기 위한 문서화된 순차적 프로세스입니다.

포레스트 복구는 엄격한 의존성 기반 순서를 따릅니다. 계획은 어떤 도메인 컨트롤러가 먼저 복구되는지, 팀이 Flexible Single Master Operations (FSMO roles)를 재할당하는 순서와 손상된 데이터를 전파하지 않고 복제를 재설정하는 방법을 정의합니다.

이 용어는 다음과 같은 모든 것에 느슨하게 적용됩니다: 삭제된 단일 사용자 계정 복원부터 전체 포리스트 재구성까지이며, 이 둘은 완전히 다른 계획이 필요합니다. AD 휴지통에서 단일 객체를 복원하는 것은 주변 포리스트가 건강하다고 가정합니다; 전체 포리스트 복구는 포리스트 자체가 손상되었다는 전제에서 시작합니다.

최악의 AD 장애 시나리오는 어떻게 생겼나요?

이러한 AD 장애 시나리오는 조직이 일상적인 문제 해결보다 전체 포리스트 복구를 추구하도록 만듭니다.

랜섬웨어가 모든 도메인 컨트롤러를 한 번에 암호화하거나 삭제함

랜섬웨어 운영자는 이제 도메인 컨트롤러를 직접 공격하며, highly privileged accounts를 획득하면 공격자가 동일한 작업의 일부로 백업을 삭제할 수 있습니다. 백업 DC가 프로덕션과 동일한 네트워크 세그먼트에 있으면 AD를 무력화하는 동일한 공격이 복구용 백업도 무력화할 수 있습니다. Microsoft의 기준은 포리스트 복구 시 모든 DC가 논리적으로 손상되었거나 물리적으로 손상되어 비즈니스 연속성이 불가능한 상태여야 한다는 것입니다.

Maersk의 2017년 NotPetya 사건은 이 시나리오의 전형적인 사례입니다. 이 악성코드는 한 시간 이내에 Maersk의 전 세계 네트워크에 있는 거의 모든 도메인 컨트롤러를 삭제했으며, 공격이 발생했을 때 가나 아크라 사무소의 한 DC가 지역 정전으로 인해 꺼져 있었기 때문에 회사는 완전한 손실을 피할 수 있었습니다. 이 단 한 대의 생존 복사본이 Maersk가 나머지 Active Directory 포리스트를 재구축할 수 있게 했지만 Maersk의 CISO는 나중에 말했습니다 복구에 걸린 9일은 "충분하지 않다." 더 광범위한 재구축은 결국 약 4,000대의 서버와 45,000대의 PC를 포함했으며, Maersk는 총 비용을 최대 3억 달러로 추산했습니다.

손상된 관리자 계정이 OU, GPO 또는 전체 하위 트리를 삭제하는 경우

Domain Admin 또는 Schema Admin 권한을 가진 악의적인 관리자는 복제 스트림에서 정상 작업과 구분할 수 없는 변경을 할 수 있습니다. 백업에서 알려진 정상 기준선이 없으면 개별 객체 복원으로 어떤 변경이 악의적인지 확인할 수 없습니다.

조직 단위(OUs), Group Policy Objects (GPOs) 또는 하위 트리의 삭제는 일반적인 관리 작업처럼 보여 종종 눈에 띄지 않습니다. Kerberos 티켓, SIDHistory, AdminSDHolder 또는 GPOs를 변경하는 지속성 기법은 팀이 신뢰할 수 있는 백업에서 복원하고 결과를 검증하지 않는 한 디렉터리 데이터베이스 내에 남아 있을 수 있습니다.

손상된 복제 또는 모든 DC에 전파되는 잘못된 스키마 변경

공격자나 관리자가 다음을 실행할 수 있습니다. 데이터 손상을 확산시키는 스크립트입니다. 포리스트 전체에 걸쳐 스키마를 충돌하는 변경 사항으로 확장할 수도 있습니다. 오류가 눈에 띌 때쯤이면 복구 계획에서 깨끗하다고 가정한 도메인 컨트롤러를 포함하여 포리스트의 모든 도메인 컨트롤러에 이미 존재할 수 있습니다. 스키마 파티션은 포리스트 전체에 걸쳐 있으며 모든 도메인이 공유하므로 손상된 스키마는 모든 도메인의 작업을 동시에 중단시킵니다.

지리적으로 중복된 DC가 없는 사이트 전체 하드웨어 장애 또는 자연 재해

Microsoft의 포리스트 복구 기준은 논리적 손상과 물리적 손상에 중점을 두며, 단일 사이트의 물리적 이벤트도 동일한 결과를 초래합니다. 모든 도메인 컨트롤러를 단일 사이트 또는 데이터 센터에서 운영하는 조직은 단일 화재, 홍수 또는 정전으로 인해 전체 포리스트를 잃을 위험이 있으며, 이로 인해 생산과 함께 동일 위치에 있는 백업 DC도 중단됩니다. 지리적 중복성은 이러한 유형의 장애에 대한 주요 구조적 방어 수단입니다.

프로세스 중간에 스키마를 손상시키는 실패한 AD 업그레이드 또는 마이그레이션

공격으로 인한 실패를 넘어서, 스키마 수정은 포리스트를 일관성 없는 상태로 만들 수 있습니다. 스키마 수정은 모든 DC에 복제되며 정상 운영 시 대부분 되돌릴 수 없으므로 롤백이 항상 간단하지 않으며, 손상되거나 충돌하는 스키마는 모든 도메인에 대해 포리스트 전체 작업을 동시에 중단시킬 수 있습니다.

AD 재해 복구 계획이 중요한 이유

계획이 없으면 위의 모든 시나리오는 동일하게 즉흥적으로, 압박을 받으며, 모든 의존 시스템이 이미 다운된 상태로 끝납니다.

랜섬웨어 그룹이 이제 도메인 컨트롤러와 백업을 직접 공격합니다

문서화된 전술은 이 기술이 엔드포인트 암호화를 훨씬 뛰어넘었음을 보여줍니다. 공격자는 이제 도메인 컨트롤러 가상 머신을 종료하여 자격 증명 데이터베이스를 직접 추출하고, 자신들이 제어하는 악성 도메인 컨트롤러로 FSMO 역할을 이전합니다.

노출은 설문조사 데이터에서도 나타납니다. The Netwrix 2026 Data and Identity Security Report의 설문조사에서 25%의 조직이 지난 12개월 동안 무단 신원이 민감한 데이터에 접근한 사건을 경험했다고 보고했습니다.

백업이 자동으로 안전하다고 가정하는 복구 전략은 이러한 공격이 전개되는 방식과 더 이상 맞지 않습니다.

AD가 다운되는 순간 모든 종속 시스템도 다운됩니다

이메일, 파일 액세스, VPN 및 대부분의 비즈니스 애플리케이션은 AD를 통해 인증되므로 다운타임 비용이 모든 종속 시스템에서 시간 단위로 누적됩니다. identity, DNS, 네트워크, 비밀 또는 데이터베이스를 사용할 수 없으면 애플리케이션이 복원되더라도 사용할 수 없게 되어 명시된 복구 시간 목표를 초과하여 다운타임이 연장될 수 있습니다.

First National Bank Minnesota 는 그 필요성을 직접 느끼고 Netwrix Auditor 의 지원으로 3주 만에 Active Directory 재구축을 완료했으며, 원래 예상 기간은 6개월이었습니다.

Microsoft의 포레스트 복구 프로세스는 길고, 순서에 의존하며, 가혹합니다

공식 Microsoft AD forest recovery guide는 기계적 재구성 단계를 자세히 다루며, 침해 후 보안 복구, 계획 및 거버넌스, 경영진 또는 보험사에 대한 보고는 명시적으로 제외합니다. 의존성 순서를 무시하고 도메인 컨트롤러를 복원하거나 metadata cleanup 단계를 건너뛰는 등 순서가 잘못된 작업은 재구성을 무효화하고 다시 시작하도록 강제할 수 있습니다.

이사회와 사이버 보험사는 검증된 복구 시간 목표를 요구합니다

테스트된 AD 복구 시간 목표는 경영진, 이사회 및 보험사에 검토할 구체적인 지표를 제공합니다. 이는 현실적인 조건에서 수행된 실제 복원을 반영합니다. 재해 복구 계획이 존재한다는 일반적인 진술은 측정된 단계 시간과 완료 기준이 포함된 날짜가 지정된 복원 테스트보다 운영 증거가 적습니다.

테스트되지 않은 계획은 실제 사건 중에 실패합니다

복구 계획의 격차는 실제 압박을 받을 때 가장 빨리 드러나며, 이는 발견하기에 가장 비용이 많이 드는 시기입니다. 신뢰와 능력은 서로 다른 것을 측정하며, 오직 테스트만이 이를 조화시킵니다.

AD 재해 복구 계획에 포함되어야 할 사항

아래 각 구성 요소는 무엇을 포함하는지와 가장 중요한 시점에 이를 제외하면 계획이 왜 무너지는지를 설명합니다.

• 모든 도메인 컨트롤러의 시스템 상태에 대한 변경 불가능한 오프라인 백업: 백업이 프로덕션과 동일한 네트워크에 있으면 AD를 마비시킨 랜섬웨어가 복구용 복사본에 접근할 수 있습니다. 에어갭 또는 변경 불가능한 저장소는 복구 미디어를 동일한 장애 경로 밖에 유지하며, AD 인식 백업 애플리케이션은 복원 시 업데이트 시퀀스 번호(USN) 롤백을 방지합니다.
• 문서화된 순서대로 재구성 순서: 포리스트 복구에는 엄격한 순서 의존성이 있으며, DC를 복원하거나 FSMO 역할을 순서에 맞지 않게 재할당하면 포리스트가 복구되지 않고 더 손상될 수 있습니다. Microsoft는 프로세스에 엔드 투 엔드 자동화가 없다고 지적하며, 환경별 계획에 부담을 준다고 합니다.
• AD에 특화된 테스트된 복구 시간 목표(RTO): 백업 일정은 데이터가 존재함을 알려주며, RTO는 비즈니스가 중단되는 시간을 알려줍니다. 이는 경영진과 보험사가 검토할 수 있는 수치입니다. 복구 지점 목표 (RPO)은 그와 함께 위치하며, 얼마나 많은 디렉터리 변경 손실을 허용할 수 있는지 정의합니다.
• AD 장애에 대한 정의된 커뮤니케이션 및 에스컬레이션 계획: 실제 AD 장애 시, 팀이 일반적으로 조정에 사용하는 이메일, Teams, 티켓 시스템 등의 도구도 종종 작동하지 않습니다. 계획에는 오프라인에 저장되고 사전에 배포된 연락망을 사용하여 팀이 이러한 도구 없이 어떻게 소통하는지 명시해야 합니다.
• 예정된 복구 훈련 또는 테이블탑 연습: 팀이 한 번도 연습하지 않은 계획은 통제된 테스트가 아닌 실제 사고 중에 그 허점을 드러냅니다. 정기적인 연습은 복구 팀이 사고 압박 하에서 작업하기 전에 조직의 근육 기억을 구축합니다.

디렉터리 복구 소프트웨어는 세분화된 객체 복구와 전체 포리스트 재구성 두 가지 운영 모드를 모두 지원해야 하며, 하나의 장애 유형 때문에 팀이 사고 중간에 두 번째 도구를 사용하지 않도록 해야 합니다.

디렉터리 복구는 인접한 아이덴티티 제어에도 의존합니다: zero standing privilege 사고 전 지속적인 관리자 노출을 줄이고, ephemeral admin accounts 특권 자격 증명의 수명을 제한하며, access certification 특권 액세스 증거를 최신 상태로 유지합니다.

최악의 시나리오를 견디는 AD 재해 복구 계획 수립 방법

계획을 올바른 순서로 세우는 것은 그 내용만큼 중요합니다. 아래 각 단계는 이전 단계에 의존하며, 단계를 건너뛰면 의존성에 대해 스트레스 테스트되지 않은 완성된 것처럼 보이는 계획이 만들어집니다.

1. 먼저 forest 구조와 모든 종속성을 인벤토리하세요

복구 단계를 작성하기 전에 모든 도메인 컨트롤러, FSMO 역할 보유자, 신뢰 관계 및 DNS 종속성을 매핑하세요. 이 인벤토리가 없는 계획은 실제로 필요할 때 종속성을 놓치게 됩니다.Microsoft의 지침은 포리스트 루트 도메인 DC 목록을 가장 중요한 항목으로 간주하는데, 해당 도메인이 가장 먼저 복구되기 때문입니다.

글로벌 카탈로그 서버, 사이트 링크 및 복제 토폴로지를 포함하세요. 이는 DC가 다시 온라인 상태가 되는 순서를 결정합니다. 복구 팀이 정상 상태를 알 수 있도록 인벤토리와 함께 기본 repadmin /showrepl 및 dcdiag 출력을 캡처하세요.

각 도메인에 대해 Domain Admin 암호와 Directory Services Restore Mode (DSRM) 암호를 지금 기록하세요. 시스템 상태 복원에 필요하며, 비활성 포레스트에서는 복구할 수 없습니다.

2. 일반 DR 계획 외에 AD 전용 복구 시간 목표를 설정하세요

AD의 RTO는 AD에 의존하는 모든 시스템의 RTO보다 짧아야 합니다. AD가 복구될 때까지 다른 시스템은 완전히 복구될 수 없기 때문입니다. Microsoft의 규칙에 따르면 항상 자식 도메인보다 상위 도메인을 먼저 복구해야 하므로 포레스트 루트 RTO가 하위 모든 것을 제어합니다. AD 복구를 더 넓은 재해 복구 계획의 한 항목으로 취급하는 것은 실제 긴급성을 과소평가하는 경우가 많습니다.

장애 선언 시점부터 기능하는 포리스트 루트 DC가 복원되고 복제가 확인될 때까지 AD RTO를 측정하세요. 모든 종속 애플리케이션의 RTO는 이 수치를 초과해야 합니다.

3. 재구성 순서를 순서대로 작성하고 AD가 잠그지 못하는 곳에 보관하세요

The sequence needs to specify which DC restores first, in what order FSMO roles get reassigned, and how replication gets re-verified. For the first writable DC in a domain, the runbook needs to cover each recovery action in this order:

1. Active Directory Domain Services (AD DS)의 비권한 복원을 수행합니다.
2. Complete an authoritative restore of SYSVOL, the shared system volume that stores domain scripts and Group Policy files.
3. Run metadata cleanup for DCs you aren't restoring.
4. Seize FSMO roles.
5. Invalidate the Relative Identifier (RID) pool and raise the available RID pool value by 100,000 to prevent reissuing RIDs consumed after the backup.
6. Reset the DC computer account password twice.
7. Reset the krbtgt password twice to protect the Kerberos Ticket Granting Ticket account, with a 10-hour wait between resets.

Write these steps clearly enough for the recovery team to follow them without normal AD-dependent tools. The plan itself has to live outside AD-dependent systems. A runbook stored on a SharePoint site that requires AD to authenticate is useless when AD is down.

4. Build immutable, air-gapped backups of system state

Backups need isolation from the production network so that whatever took down AD, whether ransomware or a compromised admin account, can't also reach the copies meant to restore it. Critical backups belong in separate storage protected from unauthorized modification.

백업 연령도 기본값으로 180일인 포리스트의 tombstone 수명 내에 있어야 합니다. AD는 더 오래된 미디어에서의 복원을 거부하기 때문입니다.

침해 후에 생성된 백업은 SIDHistory 조작, AdminSDHolder 변경 및 악성 GPO가 디렉터리 데이터베이스 내에 존재하기 때문에 AD와 함께 악성코드 및 공격자의 지속성을 복원할 수 있습니다. 격리 및 클린 복원 검증은 공격자가 디렉터리에 다시 침투하는 것을 방지합니다.

5. 명확한 소유권과 지정된 에스컬레이션 경로를 할당하세요

복구의 각 단계를 수행하는 사람과 단계가 실패할 경우 누구에게 보고하는지 지정하여 실제 사고 발생 시 누군가 자원하기를 기다리며 계획이 지연되지 않도록 하세요.

사전 구축된 종속성 목록과 지정된 소유자가 없으면 복구 팀은 모든 원래 시스템 설계자가 없는 상태에서 압박을 받으며 반응적으로 상호 의존성을 발견합니다.

각 단계에 대해 주 담당자와 백업을 지정하고, 두 사람이 계획에 정의된 오프라인 통신 채널을 통해 서로 연락하는 방법을 알고 있는지 확인하세요.

필요하기 전에 AD 복구 계획을 테스트하는 방법

종이에만 존재했던 복구 계획은 테스트를 통해 효과가 입증될 때까지 가설에 불과합니다.

1. 라이브 장애 조치 테스트를 시도하기 전에 테이블탑 연습을 실행하세요

운영 환경에 영향을 주지 않고 작성된 계획을 팀과 단계별로 검토하세요. 장비를 사용하지 않고 직원들이 특정 비상 상황에 대한 역할과 대응을 토론하는 방식의 연습을 활용하세요. 이를 통해 시스템에 위험이 가해지기 전에 소유권과 순서상의 문제를 파악할 수 있으며, 결과는 이후 실전 훈련의 범위를 명확히 합니다.

2. 정해진 주기로 격리된 테스트 환경에서 포리스트를 복원합니다

테이블탑은 계획의 논리를 점검합니다. 백업과 재구성 순서가 실제로 작동하는지 확인하려면 격리된 환경에서 실제 복원이 필요합니다.

Microsoft는 가상화된 DC를 운영 환경과 분리된 가상 네트워크로 이동하고, 테스트가 실제 복구 데이터를 복원함을 증명할 수 있도록 운영 백업을 실험실에서 사용할 것을 권장합니다. Microsoft는 이 연습을 권장합니다 최소 연 1회 및 Enterprise Admins 또는 Domain Admins 그룹 멤버십이 변경될 때마다 다시 수행해야 합니다.

3. 실제 복구 기간 측정

계획의 RTO는 실제 테스트 복구를 통해 측정된 경우에만 유효합니다. 확인되지 않은 수치는 추측에 불과합니다. 격리, 복구, FSMO 인수, 복제 검증 등 각 단계별 실제 시간을 기록하여 계획이 팀이 실제로 수행할 수 있는 내용을 반영하도록 하십시오.

Help Net Security가 2024년에 보고했습니다 기업의 단 6%만이 1시간 이내에 AD를 복구할 수 있으며, 이는 대부분의 명시된 RTO가 팀이 예상하는 것보다 훨씬 높다는 것을 의미합니다. dcdiag 검사 완료, 정상 작동 중; SYSVOL 및 NETLOGON 공유가 존재하며 DNS가 정상 작동 중입니다.

4. 포리스트 토폴로지가 변경될 때마다 계획을 업데이트하세요

새 도메인 컨트롤러, 스키마 변경 또는 새로운 신뢰 관계는 재구성 순서의 일부를 무효화할 수 있으므로, 계획에는 연례 검토 외에 트리거 기반 검토 주기가 필요합니다. FSMO 역할 보유자, 사이트 토폴로지 또는 복제 링크 변경이 계획 이탈의 가장 흔한 원인입니다.

마이그레이션, 업그레이드 및 새로운 애플리케이션 배포를 트리거 목록에 추가하세요. 각 항목은 기존 순서에서 고려하지 않은 종속성을 도입할 수 있기 때문입니다. 트리거된 모든 검토는 업데이트된 인벤토리로 마무리되어야 하며, 변경 사항이 토폴로지, trusts 또는 스키마에 영향을 미치는 경우 새로운 복원 테스트가 필요합니다.

Netwrix가 Active Directory 복구를 지원하는 방법

Netwrix Identity Recovery는 이 계획에서 구분하는 두 가지 복구 모드를 모두 포함합니다. 객체 수준 사고의 경우 디렉터리 변경 내역을 기록하고 삭제되거나 수정된 사용자, 그룹, GPO 및 DNS 레코드를 포리스트의 나머지 부분에 영향을 주지 않고 알려진 정상 상태로 롤백합니다.

위의 최악의 시나리오에 대해 전체 AD 포리스트 복구 시퀀스를 자동화합니다. 적용 범위는 Entra ID와 Okta까지 확장되어 하이브리드 아이덴티티가 동일한 런북으로 복구됩니다.

복구 결정은 증거에도 의존합니다. 왜냐하면 침해 시 첫 번째 질문은 어떤 백업이 공격자보다 이전인지이기 때문입니다.

Netwrix Auditor는 지속적인 AD change auditing를 통해 해당 컨텍스트를 제공하며, 누가 언제 무엇을 변경했는지, 악의적인 변경과 정상적인 변경을 구분하는 이전 및 이후 값을 보여줍니다. 상태 시점 보고서는 디렉터리 구성을 두 시점 간에 비교하여 팀이 침해가 언제 시작되었는지, 어떤 백업이 그 이전인지 파악할 수 있게 합니다.

체셔 카운티 정부는 디렉터리가 다운된 동안 복구 팀이 필요로 하는 증거 속도를 위해 15분 만에 27,000개 파일 변경 사건을 조사하기 위해 Netwrix Auditor를 사용했습니다.

동일한 도구로 훈련과 실제 사고를 수행하면 각 단계가 비교 가능해져, 격리된 실험실에서 측정된 RTO가 팀이 경영진에게 보고하는 수치와 동일합니다.

AD 복구 계획을 테스트된 작동 프로세스로 전환하세요

진정한 준비 상태는 경영진이 검토할 수 있는 증거로 귀결됩니다. 이는 날짜가 명시된 복원 테스트, 측정된 AD RTO, tombstone 수명 내의 정상 백업 세트, 그리고 각 복구 단계별 책임자를 명시한 실행 지침서를 의미합니다.

이 패키지는 이사회, 감사인, 사이버 보험사가 현재 묻는 질문에 답하며, 각 항목이 주장보다는 리허설에서 나온 것이기 때문에 신뢰할 수 있습니다.

첫 번째 격리 복원은 누락된 DSRM 암호, 아무도 인벤토리하지 않은 종속성, 그리고 가정된 RTO를 무너뜨리는 단계를 드러냅니다. 두 번째 연습은 더 깔끔하게 진행되며 비즈니스가 계획할 수 있는 수치를 산출합니다. 이후 트리거 기반 검토는 도메인 컨트롤러, 트러스트, 스키마가 진화함에 따라 포리스트와 계획을 일치시키며, 문서화된 계획과 실제 환경 간의 격차가 다시 위험으로 확대되지 않도록 합니다.

데모 요청하여 Netwrix Identity Recovery가 자체 토폴로지에서 포리스트 재구성, 세분화된 롤백 및 복구 연습을 처리하는 방법을 확인하세요.