이 글의 목적은 CIS 보안 기준(CIS Benchmark) 또는 이에 준하는 하드닝 정책을 적용한 뒤 원격접속, 파일공유, 업데이트, 인증, 스크립트 실행 등 업무 기능이 비활성화되었을 때 원인을 신속히 특정하고, 보안 수준을 과도하게 낮추지 않으면서 필요한 기능만 안전하게 복구하는 절차를 현장에서 바로 적용할 수 있도록 정리하는 것이다.
1. CIS 적용 후 “기능이 갑자기 안 됨”이 발생하는 이유
CIS 보안 기준은 공격 표면을 줄이기 위해 서비스, 방화벽 규칙, 계정 정책, 감사 정책, 레지스트리 기반 보안 옵션, 사용자 권한 할당(User Rights Assignment), 암호화/인증 설정을 폭넓게 조정하는 방식이다. 이 과정에서 업무에 필요한 기능이 ‘의도치 않게’ 같이 꺼지는 경우가 흔하다. 특히 Level 2 또는 조직에서 변형한 템플릿을 그대로 배포했을 때 문제가 확대되기 쉽다.
1-1. 장애가 주로 발생하는 기능 영역
| 영역 | 대표 증상 | 원인(정책/설정 유형) | 복구 시 주의점 |
|---|---|---|---|
| 원격 데스크톱(RDP) | 접속 거부, NLA 오류, 포트 열려도 로그인 불가 | 방화벽 인바운드 차단, RDP 비활성화, 사용자 권한/로컬 보안 옵션 변경 | 필요 사용자만 허용, 방화벽 규칙 최소 개방, MFA/Just-in-Time 고려 |
| 원격 지원/원격 제어 | 원격 지원 메뉴 비활성, 도움말 도구 연결 불가 | Remote Assistance 정책 Off, UAC/권한 분리 강화 | 지원 시나리오만 한정 허용, 감사 로그 활성 유지 |
| 파일 공유(SMB) | 공유 폴더 접속 실패, 자격 증명 반복, 서명/암호화 협상 실패 | SMB 클라이언트/서버 서명 강제, 게스트 차단, NTLM 제한, LAN Manager 설정 | 구형 장비 호환성 검토 후 단계적 완화, SMB1은 원칙적으로 금지 |
| PowerShell/스크립트 | 스크립트 실행 차단, 원격 PowerShell 불가, 모듈 설치 실패 | ExecutionPolicy, Constrained Language, WinRM/PSRemoting 제한 | 서명 기반 실행 정책 권장, 관리자 전용 범위로 한정 |
| Windows Update/스토어 | 업데이트 검색/설치 실패, Store 앱 차단 | 업데이트 소스/서비스 제한, 스토어 정책 비활성 | 조직의 업데이트 운영(WSUS/Intune)과 정합성 확보 |
| 로그온/인증 | 특정 계정 로그인 불가, 로컬 로그인 차단, 잠금 정책 강화로 업무 중단 | 사용자 권한 할당, 보안 옵션(Interactive logon), 계정 잠금/암호 정책 | 업무 계정/서비스 계정 예외 설계 필요 |
| 서비스/드라이버 | 에이전트 동작 중단, 백업/모니터링 실패 | 서비스 시작 유형 변경, 드라이버 설치 제한, Defender/ASR 상호작용 | 벤더 권장 설정과 CIS 템플릿 충돌 검증 필요 |
2. 복구 전 필수 원칙(사고 없이 되돌리는 방법)
2-1. “전체 롤백” 대신 “최소 기능 복구”가 원칙이다
업무 기능을 살리기 위해 하드닝을 통째로 풀면 재발 위험이 커진다. 장애를 일으킨 정책 항목만 식별하여 최소 범위로 되돌리는 방식이 안전하다. 예를 들어 RDP가 필요하면 “RDP 활성 + 허용 사용자 제한 + 방화벽 규칙 최소 개방 + 로그온 감사 유지” 같은 형태로 복구해야 한다.
2-2. 변경 이력과 적용 범위를 먼저 확정한다
아래를 먼저 정리해야 정확히 복구할 수 있다.
| 확인 항목 | 확인 방법 | 결과 활용 |
|---|---|---|
| 적용 경로 | 도메인 GPO / 로컬 정책 / Intune / 스크립트(LGPO, secedit, reg import 등) 여부 | 복구 지점 결정(도메인인지 로컬인지) |
| 적용 시점 | 장애 발생 시각, 배포 작업 시각, 변경 관리 기록 | 정책 버전/작업자/배포 단위 특정 |
| 적용 대상 | 특정 OU/그룹/필터링 대상인지, 일부 PC만인지 | 테스트 복구 대상 선정, 확산 방지 |
| 장애 형태 | “기능 Off”인지 “권한/차단”인지 “협상/암호화 불일치”인지 | 원인 범주를 좁혀 진단 시간을 절감 |
3. 1차 진단: 어떤 정책이 실제로 적용되었는지 확인
3-1. 도메인 환경(GPO)에서 가장 먼저 볼 것
문제 PC에서 “어떤 GPO가 적용되었는지”를 우선 확보해야 한다. 적용된 정책 목록이 없으면 복구가 감(感)으로 변한다.
:: 적용된 그룹 정책 결과(컴퓨터/사용자) HTML로 출력 gpresult /h C:\Temp\gpresult.html :: 정책 적용 이벤트(운영 로그) 확인 경로 예시 Event Viewer > Applications and Services Logs > Microsoft > Windows > GroupPolicy > Operationalgpresult 결과에서 “Computer Details > Applied Group Policy Objects” 구간에 CIS 관련 이름(예: CIS, Benchmark, Hardening, Security Baseline 등)이 보이면 해당 GPO가 1차 용의자다.
3-2. 로컬 정책 또는 스크립트로 적용된 경우 확인 포인트
도메인 GPO가 아닌 로컬에서 적용된 흔적은 다음에서 자주 발견된다.
| 흔적 | 의미 | 대표 예 |
|---|---|---|
| 작업 스케줄러/시작 스크립트 | 정기적으로 보안 템플릿을 재적용 | secedit /configure 반복 실행 |
| 로컬 보안 정책/보안 템플릿 | 사용자 권한, 보안 옵션, 감사 정책 고정 | 권한 할당 변경으로 로그인/서비스 실패 |
| 레지스트리 대량 변경 | 방화벽, 원격 기능, 스크립트 정책 강제 | ExecutionPolicy 강제, 원격 레지스트리 차단 |
4. 기능별 복구 플레이북(업무에서 가장 많이 막히는 항목)
4-1. 원격 데스크톱(RDP) 복구
RDP 장애는 보통 (1) RDP 자체 비활성, (2) 방화벽 차단, (3) 사용자 권한/정책으로 로그인 차단, (4) NLA/보안 계층 협상 문제 중 하나로 분해된다.
| 점검 순서 | 확인 내용 | 복구 조치(필요 시) |
|---|---|---|
| 1 | RDP 허용 여부(로컬 설정/정책) | “원격 데스크톱 허용”을 On으로 되돌림 |
| 2 | Windows 방화벽 인바운드 규칙 | Remote Desktop 관련 규칙을 Domain/Private에서 최소 허용 |
| 3 | 원격 로그온 권한(Allow log on through Remote Desktop Services) | 업무 그룹/IT 그룹만 명시적으로 허용 |
| 4 | 차단 권한(Deny log on through RDS) | 불필요한 광범위 그룹이 포함되어 있으면 제거 |
| 5 | NLA/자격 증명 정책 충돌 | 서버/클라이언트 버전 정합성 확인 후 필요한 수준으로 조정 |
:: 서비스 상태 확인(예: RDP 서비스) sc query TermService :: 방화벽 규칙 확인/조정은 GUI 또는 정책으로 수행 권장 :: 단, 긴급 복구 시에는 인바운드 룰 상태를 빠르게 점검한다.4-2. 파일 공유(SMB) 및 네트워크 드라이브 복구
하드닝 후 공유가 안 되는 경우는 단순 포트 차단보다 “인증/서명/호환성” 문제 비중이 크다. 특히 SMB 서명 강제, 게스트 차단, NTLM 제한, 로컬 계정 토큰 정책 변경이 결합되면 기존 장비/솔루션이 연쇄적으로 실패한다.
대표 증상별 빠른 분류
| 증상 | 가능성 높은 원인 | 권장 복구 방향 |
|---|---|---|
| 자격 증명 입력 반복 | NTLM 제한/차단, 로컬 계정 정책, Kerberos 실패 | 도메인 인증 경로 정상화, NTLM은 최소 완화 후 로그로 추적 |
| 접근 거부(권한은 맞음) | 로컬 보안 옵션/토큰 필터, UAC 원격 제한 | 원격 관리용 로컬 계정 정책을 역할 기반으로 재정의 |
| 구형 장비만 접속 실패 | 서명/암호화/프로토콜 협상 불일치 | 구형 장비 교체가 원칙, 불가피하면 해당 구간만 예외 |
4-3. PowerShell 실행 차단 및 원격 관리(WinRM/PSRemoting) 복구
CIS 적용 후 운영 자동화가 멈추는 가장 흔한 원인은 스크립트 실행 정책과 원격 관리 채널 제한이다. 이때 무조건 Unrestricted로 되돌리면 보안이 크게 약화된다.
권장 복구 전략
| 목표 | 권장 설정 방향 | 운영 팁 |
|---|---|---|
| 로컬 스크립트 실행 | AllSigned 또는 RemoteSigned 기반으로 운영 | 배포 스크립트 서명 체계(코드 서명 인증서) 도입 |
| 원격 PowerShell | 관리망/점프서버에서만 허용, 대상 그룹 제한 | Just Enough Administration(JEA) 또는 역할 분리 적용 |
| 모듈 설치/업데이트 | 프록시/리포지토리 정책 정합성 확보 | 사내 리포지토리 미러링을 고려 |
:: 현재 실행 정책 확인 powershell -NoProfile -Command "Get-ExecutionPolicy -List" :: 스크립트 실행 정책을 '기계(LocalMachine)' 범위로 조정하는 예시(운영 정책에 맞게 선택) powershell -NoProfile -Command "Set-ExecutionPolicy RemoteSigned -Scope LocalMachine -Force"4-4. Windows Update, Microsoft Store, 기본 앱 기능 복구
하드닝 템플릿이 업데이트/스토어/텔레메트리 계열 정책을 강하게 막으면, 업무상 필요한 앱 배포나 보안 패치 적용이 지연된다. 특히 조직이 WSUS/Intune 등으로 운영 중인데 CIS 템플릿이 별도 정책으로 충돌하면 “업데이트 서버는 정상이지만 클라이언트가 거부”하는 형태가 된다.
복구 체크리스트
| 체크 | 설명 | 복구 방향 |
|---|---|---|
| 업데이트 관리 방식 | WSUS/Intune/직접 업데이트 중 무엇인지 확정 | 운영 방식에 맞춰 정책을 단일화 |
| 필수 서비스 상태 | 업데이트 관련 서비스가 Disabled로 떨어졌는지 | 조직 표준 시작 유형으로 환원 |
| 스토어 차단 정책 | UWP 앱 배포가 필요한지 | 필요하면 “허용 목록 기반”으로 제한적 활성 |
5. “정책을 풀었는데도 안 돌아오는” 대표 케이스와 해결 순서
5-1. GPO 링크 해제했는데도 설정이 유지되는 경우
다음과 같은 설정은 “되돌림”이 자동으로 이루어지지 않거나, 한 번 적용된 후 다른 값으로 덮어써야만 정상화되는 경우가 많다.
| 유형 | 설명 | 해결 접근 |
|---|---|---|
| 보안 템플릿/로컬 보안 정책 | 권한 할당/보안 옵션이 로컬 DB에 반영 | 기준 템플릿으로 재구성하거나 기준값을 명시적으로 재적용 |
| GPP 레지스트리/서비스 설정 | Preferences는 일반적으로 “삭제 시 원복”을 보장하지 않음 | 원래 값(또는 표준 값)을 다시 배포하는 ‘복구 GPO’ 작성 |
| 권한(ACL) 변경 | 폴더/레지스트리 권한을 잠가 기능이 멈춤 | 기준 ACL을 복구하거나 OS 표준 상속 구조로 복원 |
5-2. 일정 시간이 지나면 다시 막히는 경우
대개 다음 중 하나이다.
- 정책이 다른 경로(Intune/다른 GPO/스크립트)에서 재적용되고 있다.
- 보안 에이전트(EDR)나 구성 관리 도구가 기준 상태로 되돌리고 있다.
- 도메인 정책 갱신 주기마다 다시 적용된다.
:: 즉시 정책 갱신(테스트) gpupdate /force :: 정책 갱신 후 동일 증상 재발 여부를 체크하면 '재적용형'인지 빠르게 판별 가능6. 안전한 복구를 위한 표준 절차(권장 운영 프로세스)
6-1. 단계별 복구 로드맵
| 단계 | 목표 | 핵심 작업 | 산출물 |
|---|---|---|---|
| 1 | 확산 방지 | 문제 GPO 링크 중지/필터링, 배포 스크립트 중단 | 추가 피해 차단 |
| 2 | 원인 특정 | gpresult, 이벤트 로그, 실패 시점 비교 | 원인 정책 목록 |
| 3 | 최소 복구 | 기능별 필수 설정만 복원(예: RDP, SMB, PS) | 업무 기능 정상화 |
| 4 | 재발 방지 | CIS 항목 재설계(Level 1/2 재선정), 예외 정책 문서화 | 표준 하드닝 정책 |
| 5 | 검증/감사 | 테스트 케이스, 로그 수집, 변경 승인 체계 | 검증 리포트 |
6-2. 복구용 “역방향 GPO(Recovery GPO)” 설계 팁
현장에서는 ‘하나씩 수동 수정’보다 복구용 GPO를 만들어 대상 OU에 단기적으로만 적용하는 방식이 안정적이다. 단, 복구 GPO는 영구 운영용이 아니라 “업무 정상화 + 원인 정책 재설계까지의 임시 브리지”로 설계해야 한다.
- 정책 이름에 목적과 만료 계획을 포함한다(예: Recovery-RDP-Until-YYYYMMDD 형태의 내부 규칙).
- 허용 대상(보안 그룹)과 허용 범위(관리망 IP 대역 등)를 명시적으로 제한한다.
- 복구 후에는 CIS 템플릿 자체를 조직 표준에 맞게 수정하여 재배포하고, 복구 GPO는 제거한다.
7. 현장 점검용 빠른 체크리스트
| 체크 | 예/아니오 | 메모 |
|---|---|---|
| 장애 발생 시점과 CIS 배포 시점이 일치한다 | ||
| gpresult에서 CIS/Hardening 관련 GPO가 적용됨을 확인했다 | ||
| GPO 링크 해제 후에도 값이 유지되는 항목(보안 템플릿/권한/Preferences)이 있다 | ||
| 재발(일정 시간 후 재차 비활성)이 있는지 확인했다 | ||
| 업무 필수 기능만 최소 범위로 복구하는 방식을 선택했다 | ||
| 예외 허용은 “대상/기간/사유”가 문서화되었다 |
FAQ
CIS 정책을 제거했는데도 원격 지원/원격 데스크톱이 계속 비활성화되는 이유는 무엇인가?
정책이 다른 경로에서 재적용되는 경우가 많다. 도메인 내 다른 GPO, Intune 구성 프로파일, 보안 에이전트의 기준 상태 복원, 스크립트(secedit/LGPO) 반복 실행 등이 원인이 된다. gpupdate 이후 재발 여부를 확인하고, 이벤트 로그와 구성 관리 이력을 대조하여 재적용 트리거를 먼저 제거해야 한다.
파일 공유가 특정 장비에서만 실패한다. 전체 보안을 낮추지 않고 해결할 방법은 무엇인가?
구형 장비의 SMB 협상 방식(서명/암호화/인증)이 현대 보안 설정과 불일치할 가능성이 크다. 원칙은 장비 교체 또는 별도 격리망/프록시를 통한 우회이며, 불가피하게 예외를 둔다면 해당 장비와 통신하는 구간만 분리하고, 접근 제어와 모니터링을 강화한 뒤 예외 종료 시점을 명확히 해야 한다.
PowerShell 자동화가 멈췄다. ExecutionPolicy를 풀어도 안 된다.
ExecutionPolicy 외에도 Constrained Language Mode, AppLocker/WDAC, ASR 규칙, 원격 관리(WinRM) 차단이 중첩되면 동일 증상이 발생한다. 이 경우 단일 설정을 완화하는 접근이 아니라 “차단 계층을 특정한 뒤 해당 계층에서 최소 예외를 설계”해야 한다. 운영 자동화는 서명 기반 실행(AllSigned/RemoteSigned)과 관리자 범위 제한을 병행하는 방식이 안전하다.
CIS Level 1과 Level 2 중 무엇을 쓰는 것이 안전한가?
업무 연속성이 중요한 일반 사무 환경에서는 Level 1을 기준으로 시작하고, 민감 데이터 구간이나 특정 서버 역할에만 Level 2 항목을 선별 적용하는 방식이 현실적이다. Level 2는 기능 저하 가능성이 상대적으로 크므로, 적용 전 테스트 OU/파일럿 그룹에서 검증 후 확산해야 한다.