이 글의 목적은 CIS 보안 기준(CIS Benchmark) 또는 하드닝 템플릿 적용 이후 발생하는 각종 기능 비활성화 문제를 “원인 파악→안전한 원복→예외처리→재발 방지” 순서로 정리하여, 현장에서 즉시 복구하고 다시 안정적으로 운영할 수 있도록 돕는 것이다.
1. CIS 보안 기준 적용 후 흔히 나타나는 증상 정리
CIS 보안 기준을 로컬 보안 정책, 보안 템플릿, GPO, MDM, 스크립트로 적용하면 보안 수준은 올라가지만 운영 기능이 동시에 제한되는 경우가 많다.
문제는 “무엇이 꺼졌는지”보다 “무엇이 어디에서 강제됐는지”를 분리해 확인하지 않으면, 원복을 반복해도 다시 비활성화가 재발하는 구조가 된다는 점이다.
1-1. 사용자 체감 증상
- 원격 데스크톱(RDP) 접속 불가가 발생하다.
- 파일 공유(SMB) 접속 오류, 네트워크 드라이브 연결 실패가 발생하다.
- WinRM/PowerShell 원격 관리가 차단되다.
- WMI 기반 모니터링, 에이전트 점검, 자산 수집이 실패하다.
- Windows Update, Microsoft Store, 앱 설치 정책이 막히다.
- 스크립트 실행 정책, 매크로 정책이 강화되어 업무 자동화가 실패하다.
- 서명·TLS·암호화 정책 강화로 내부 레거시 시스템 접속이 실패하다.
- 방화벽 규칙이 강제되어 특정 포트 통신이 끊기다.
1-2. 관리자 관점 증상
- 로컬 변경이 곧바로 되돌아가는 현상이 발생하다.
- gpedit.msc에서 값이 회색으로 고정되는 현상이 발생하다.
- 보안 옵션이 “정의되지 않음”이어도 실제로는 제한이 걸리다.
- 정책 상충으로 이벤트 로그에 감사 실패가 증가하다.
주의 : CIS 정책은 단일 항목이 아니라 “계정 정책·감사 정책·보안 옵션·레지스트리·서비스·방화벽·고급 감사·AppLocker·Defender·브라우저”가 함께 움직이는 구조이다. 증상만 보고 한 항목만 풀면 보안과 기능이 동시에 깨지는 상황이 발생하므로, 반드시 원인 범위를 먼저 고정해야 하다.
2. 원인 구조를 먼저 이해해야 원복이 재발하지 않다
CIS 적용 후 기능이 꺼지는 원인은 보통 네 가지 축으로 정리하다.
| 원인 축 | 대표 적용 경로 | 특징 | 재발 가능성 |
|---|---|---|---|
| 도메인 GPO | Active Directory GPO | 주기적으로 강제 적용하다 | 매우 높다 |
| 로컬 정책 | gpedit.msc, secpol.msc, secedit | 단말 단위로만 반영하다 | 중간이다 |
| MDM/Intune | Configuration Profile, Security Baseline | 일부 항목은 UI에 표시되지 않다 | 높다 |
| 스크립트/도구 | PowerShell, hardening tool, 레지스트리 배치 | 반영 흔적이 불명확하다 | 중간이다 |
2-1. “원복했는데 다시 꺼짐”의 전형적인 이유
- 도메인 GPO가 주기적으로 다시 덮어쓰다.
- 보안 기준 템플릿이 스케줄러나 에이전트로 재적용되다.
- MDM 베이스라인이 정책 충돌을 무시하고 강제하다.
- 로컬에서 바꾼 값이 실제 원인 정책이 아니라서 효과가 없하다.
2-2. 가장 먼저 해야 하는 판단
- 문제가 “단일 PC”인지 “조직 전체”인지 구분하다.
- 해당 PC가 “도메인 가입”인지 “로컬 단독”인지 확인하다.
- Intune 또는 다른 MDM 관리 대상인지 확인하다.
- 최근 배포한 하드닝 스크립트 또는 보안 도구 적용 이력이 있는지 확인하다.
3. 안전한 복구 원칙 5가지
보안 기준을 무작정 풀면 감사 지적과 보안 사고 리스크가 즉시 커지므로, 기능 복구는 “필요 최소한”으로 설계해야 하다.
- 원복 전 현재 상태를 백업하다.
- 원인 정책을 “어디서 강제되는지”부터 고정하다.
- 기능 복구는 “예외처리 방식”으로 우선 접근하다.
- 원복 후 즉시 검증 명령으로 확인하다.
- 재발 방지를 위해 정책 소유자를 명확히 하다.
주의 : 원복을 “전체 해제”로 처리하면 보안 기준 준수 자체가 무너져 책임 소재가 발생하다. 기능 복구는 반드시 “업무 요구사항이 명확한 기능만 선택적으로 복구”하는 방식으로 운영해야 하다.
4. 원인 정책을 빠르게 찾는 실전 절차
4-1. 적용 정책의 출처를 확인하는 1차 진단
도메인 환경에서는 “어떤 GPO가 적용됐는지”를 먼저 확인해야 하다.
gpresult /h C:\Temp\gpresult.html start C:\Temp\gpresult.htmlgpresult 결과에서 컴퓨터 구성과 사용자 구성의 “적용된 그룹 정책 개체” 목록을 확인해야 하다.
특히 보안 기준 배포용 GPO가 별도로 존재하는지 확인해야 하다.
4-2. 로컬 정책과 보안 템플릿 흔적을 확인하는 2차 진단
로컬 보안 정책 기반 변경은 secedit 또는 로컬 정책 저장소에 흔적이 남다.
secedit /export /cfg C:\Temp\secpol_export.inf내보낸 파일에서 계정 정책, 보안 옵션, 사용자 권한 할당 항목을 점검해야 하다.
4-3. 레지스트리 기반 강제 여부를 확인하는 3차 진단
CIS 항목 다수는 정책 레지스트리(Policies)로 강제되므로, 아래 경로를 우선 확인해야 하다.
reg query "HKLM\SOFTWARE\Policies" /s reg query "HKCU\SOFTWARE\Policies" /s특정 기능이 “회색 고정”이면 보통 Policies 경로 값이 존재하다.
4-4. 방화벽 차단 여부를 확인하는 4차 진단
원격 기능 불가의 상당수는 방화벽 프로파일과 인바운드 규칙 강제가 원인이다.
netsh advfirewall show allprofiles netsh advfirewall firewall show rule name=all | findstr /i "Remote Desktop WinRM WMI File and Printer"5. 기능별 복구 가이드(원복 값·예외처리·검증 포함)
아래 표는 CIS 적용 후 비활성화가 자주 발생하는 기능을 중심으로 “복구 방향”을 정리한 표이다.
| 기능 | 주요 원인 정책 유형 | 권장 복구 방향 | 현장 검증 방법 |
|---|---|---|---|
| RDP 원격 데스크톱 | 서비스/방화벽/보안 옵션 | RDP 자체 해제 대신 “필요 서버만 허용” 예외처리로 복구하다 | 3389 포트 리슨과 방화벽 규칙 활성 여부를 확인하다 |
| SMB 파일 공유 | SMB 설정/서명/게스트 차단 | SMBv1은 유지 차단하고 SMBv2/3 기반으로만 정렬 복구하다 | 공유 접근과 서명 요구 값 일치 여부를 확인하다 |
| WinRM/PowerShell 원격 | 서비스/방화벽/신뢰 호스트 | 관리 대역만 허용하고 HTTPS 기반으로 구성하다 | Test-WSMan으로 응답을 확인하다 |
| WMI 모니터링 | DCOM/WMI 방화벽/권한 | 모니터링 계정·서버만 예외 권한을 부여하다 | WBEM 포트와 규칙 활성 상태를 확인하다 |
| 스크립트 실행 정책 | ExecutionPolicy 강제 | 전사 해제 대신 서명된 스크립트 체계로 복구하다 | Get-ExecutionPolicy -List로 확인하다 |
| 업데이트/스토어 | Windows Update 정책/스토어 차단 | 업데이트 채널만 복구하고 앱 설치는 통제 유지하다 | 설정 UI와 서비스 상태로 확인하다 |
5-1. RDP(원격 데스크톱) 복구
RDP는 CIS에서 “불필요 시 비활성화” 또는 “접근 통제 강화”로 권장되는 영역이다.
운영 환경에서는 RDP를 무조건 끄기보다, 접근 제어와 로깅을 강화한 상태로 필요한 서버만 열어야 하다.
복구 체크리스트
- Remote Desktop Services(TermService) 서비스 상태를 확인하다.
- 로컬 보안 옵션에서 “네트워크 수준 인증(NLA)” 요구 정책을 확인하다.
- Windows Defender 방화벽 인바운드 규칙에서 “Remote Desktop” 그룹을 확인하다.
- 사용자 권한 할당에서 원격 로그온 허용/거부 정책을 확인하다.
현장 명령 예시
sc query TermService reg query "HKLM\SYSTEM\CurrentControlSet\Control\Terminal Server" /v fDenyTSConnections netsh advfirewall firewall show rule group="Remote Desktop"fDenyTSConnections 값이 1이면 원격 데스크톱 연결이 차단 상태이다.
방화벽 규칙이 비활성화이면 포트가 열려도 접속이 실패하다.
주의 : RDP를 복구할 때 “모든 대역 허용” 방식은 금지 수준으로 위험하다. 반드시 관리망 대역만 허용하고, 가능하면 RD Gateway 또는 점프 서버를 통해 접근하도록 설계해야 하다.
5-2. SMB(파일 공유) 접속 불가 복구
SMB 이슈는 CIS 적용 후 업무 영향이 가장 크다.
다만 SMBv1 차단은 보안상 일반적으로 유지해야 하는 영역이므로, 복구는 SMBv2/3 기반으로 정렬하는 방향이 안전하다.
복구 체크리스트
- SMBv1 비활성화는 유지하다.
- 서명 요구 정책이 서버·클라이언트 간 불일치인지 확인하다.
- 게스트 로그인 차단으로 레거시 NAS 접근이 실패하는지 확인하다.
- “LAN Manager 인증 수준” 강화로 오래된 장비가 실패하는지 확인하다.
현장 명령 예시
powershell -Command "Get-SmbServerConfiguration | Select EnableSMB1Protocol, EnableSMB2Protocol, RequireSecuritySignature" powershell -Command "Get-SmbClientConfiguration | Select EnableSecuritySignature, RequireSecuritySignature"서명 요구(RequireSecuritySignature)가 한쪽만 강제이면 특정 장비와 연결 실패가 발생하다.
이 경우 예외처리 대상 장비를 분리망으로 이동하거나, 해당 장비 측 업그레이드를 우선 검토해야 하다.
주의 : SMB 문제를 해결한다고 SMBv1을 다시 켜는 방식은 장기적으로 운영 리스크가 매우 크다. 레거시 장비 유지가 불가피하면 별도 세그먼트와 접근 제어를 먼저 설계해야 하다.
5-3. WinRM/PowerShell 원격 관리 복구
CIS 적용 후 원격 관리가 막히면 운영 자동화, 패치, 점검이 모두 느려진다.
복구는 “관리 대상 서버만, 관리망에서만” 허용하는 구조로 가야 하다.
현장 명령 예시
winrm quickconfig winrm enumerate winrm/config/listener netsh advfirewall firewall show rule name=all | findstr /i "Windows Remote Management"HTTPS 리스너를 구성하고 인증서를 적용하면 보안과 운영을 동시에 만족하기 쉽다.
다만 인증서 배포 체계가 없으면 단기 복구는 HTTP 리스너+관리망 제한으로 처리해야 하다.
5-4. WMI/모니터링 에이전트 장애 복구
CIS 적용으로 DCOM, WMI 네임스페이스 권한, 방화벽 규칙이 강화되면 모니터링이 실패하다.
이 경우 전사 완화보다 “모니터링 계정·서버에 한정한 예외 권한”이 합리적이다.
현장 체크리스트
- Windows Management Instrumentation 서비스가 동작 상태인지 확인하다.
- 방화벽에서 WMI 그룹 규칙이 비활성화인지 확인하다.
- DCOM 보안 강화가 갑자기 바뀐 이력이 있는지 확인하다.
sc query winmgmt netsh advfirewall firewall show rule name=all | findstr /i "Windows Management Instrumentation"5-5. 스크립트 실행 정책(Execution Policy) 복구
업무 자동화가 실패하면 단말 사용자는 “보안 때문에 업무를 못 한다”라고 인식하기 쉽다.
해결은 Unrestricted로 풀기보다, 서명 정책과 배포 방식을 정리하는 방향이 바람직하다.
powershell -Command "Get-ExecutionPolicy -List"MachinePolicy나 UserPolicy가 설정되어 있으면 로컬에서 바꿔도 유지가 어렵다.
이 경우 정책 소유자(GPO/MDM)를 찾아 “업무 자동화에 필요한 스코프만” 예외로 설계해야 하다.
주의 : 실행 정책을 전사적으로 낮추면 악성 스크립트 유입 위험이 증가하다. 자동화 운영은 코드 서명, 중앙 배포, 감사 로그 확보를 함께 구성해야 하다.
6. 복구의 핵심은 “원복”이 아니라 “예외처리 설계”이다
CIS 보안 기준은 기본적으로 “최소 권한·최소 기능·최소 노출”을 전제로 하다.
따라서 기능 복구도 “기본은 막고 필요한 곳만 열기”를 유지해야 하다.
6-1. 예외처리의 표준 패턴 4가지
| 패턴 | 적용 방식 | 적합 상황 | 운영 포인트 |
|---|---|---|---|
| 대상 그룹 제한 | 보안 그룹 기반 GPO 필터링 | 일부 서버만 기능 필요하다 | 서버 역할 기반 그룹을 유지관리하다 |
| OU 분리 | 역할별 OU에 다른 정책 링크하다 | 업무군이 명확하다 | OU 설계가 곧 보안 설계이다 |
| WMI 필터 | OS 버전·역할별 조건으로 분기하다 | 혼합 환경이다 | 필터 남용 시 관리가 어려워지다 |
| 방화벽 스코프 제한 | 인바운드 규칙에 원격 IP 제한하다 | 원격 기능은 필요하지만 노출은 싫다 | 관리망 IP 변경 절차가 필요하다 |
7. 원복 및 백업 실전: 정책을 “되돌릴 수 있게” 만드는 방법
7-1. 로컬 정책 백업을 남기는 방법
로컬 환경에서는 최소한 보안 정책 내보내기를 먼저 수행해야 하다.
secedit /export /cfg C:\Temp\before_restore_secpol.inf이 파일은 사고 대응, 감사 대응, 변경 이력 증빙에 유용하다.
7-2. GPO 기반 변경은 “GPO 단위”로 원복해야 하다
도메인 환경에서 로컬에서 값을 바꾸는 방식은 근본 해결이 어렵다.
반드시 gpresult로 문제 GPO를 특정하고, 해당 GPO에서 기능에 영향을 주는 항목만 예외로 수정해야 하다.
7-3. 변경 후 즉시 검증하는 습관을 표준으로 삼아야 하다
정책은 “바꿨다”로 끝나지 않고 “바뀐 것이 확인됐다”가 기준이다.
아래는 현장 검증에 자주 쓰는 명령 세트이다.
gpupdate /force gpresult /r netsh advfirewall show allprofiles sc query TermService sc query winmgmt powershell -Command "Get-ExecutionPolicy -List"주의 : 정책 검증을 UI만으로 확인하면 누락이 발생하다. 항상 명령 기반 결과를 함께 남기는 방식이 사고 대응과 감사 대응에 유리하다.
8. 운영 환경별 복구 전략
8-1. 일반 사무용 PC 중심 환경
- RDP는 기본 차단을 유지하고 원격지원은 승인된 도구로만 운영하다.
- 스크립트는 서명 기반 또는 중앙 배포 기반으로 운영하다.
- 스토어·앱 설치는 통제하고 업데이트는 허용하는 구조로 운영하다.
8-2. 서버 운영 중심 환경
- 점프 서버를 기준으로 관리망 접근을 표준으로 하다.
- WinRM은 HTTPS 기반을 목표로 하고 방화벽 스코프 제한을 필수로 하다.
- 모니터링 계정은 최소 권한과 감사 정책을 함께 설계하다.
8-3. 제조·설비·레거시 혼합 환경
- 레거시 장비 요구사항을 문서화하고 분리망을 기본으로 하다.
- 서명 요구나 인증 수준 강화는 장비 교체 계획과 함께 단계적으로 적용하다.
- 불가피한 예외는 기간을 정하고 대체 통제를 추가하다.
9. 재발 방지 체크리스트
복구 후 재발 방지까지 마무리해야 같은 장애가 반복되지 않다.
| 항목 | 점검 내용 | 권장 주기 | 결과 기록 방식 |
|---|---|---|---|
| 정책 소유자 | GPO/MDM/스크립트 책임 부서가 명확하다 | 변경 시 | 변경관리 문서화하다 |
| 예외 목록 | 어떤 기능을 왜 예외로 풀었는지 목록화하다 | 월 1회 | 서버·사용자·기간을 함께 기록하다 |
| 검증 절차 | 정책 적용 후 검증 명령이 표준이다 | 변경 시 | 명령 출력 캡처를 남기다 |
| 롤백 계획 | 문제 시 즉시 되돌릴 수 있다 | 분기 1회 | 롤백 리허설 로그를 남기다 |
FAQ
CIS 적용 후 로컬에서 값을 바꿨는데 다시 원래대로 돌아가다
도메인 GPO 또는 MDM이 강제 적용하는 상태일 가능성이 높다.
gpresult /h로 적용 GPO를 확인하고, MachinePolicy 또는 UserPolicy가 설정된 항목인지 확인해야 하다.
근본 해결은 로컬 변경이 아니라 정책 소유 지점에서 예외처리로 수정하는 방식이어야 하다.
RDP를 꼭 써야 하는데 CIS 권고를 지키면서 운영할 방법이 있나
점프 서버 또는 RD Gateway를 통한 접근 구조를 우선 설계해야 하다.
직접 RDP가 불가피하면 방화벽 스코프 제한, 계정 분리, 감사 로그 강화, 접속 시간 제한을 함께 적용해야 하다.
이 방식은 “전사 허용”이 아니라 “필요 서버만 제한 허용” 방식이므로 보안 기준과 운영을 동시에 만족하기 쉽다.
SMB 공유가 끊겨서 업무가 마비되다
SMBv1을 다시 켜는 방식은 위험이 매우 크다.
서명 요구, 게스트 차단, 인증 수준 강화 항목의 불일치 가능성을 먼저 확인해야 하다.
레거시 장비가 원인이면 분리망 운영과 장비 교체 계획을 병행해야 하다.
PowerShell 실행 정책 때문에 자동화가 멈추다
전사 완화보다 서명된 스크립트 운영 체계로 전환하는 방식이 바람직하다.
정책이 MachinePolicy로 강제이면 로컬 변경이 무의미하므로 GPO 또는 MDM에서 예외 스코프를 설계해야 하다.
어떤 CIS 항목이 문제인지 빠르게 좁히는 방법이 있나
증상별로 방화벽, 서비스, Policies 레지스트리, 사용자 권한 할당을 먼저 확인하는 방식이 효율적이다.
gpresult로 정책 출처를 고정하고, 원인 GPO에서 기능 영향 항목만 분리해 예외처리하는 방식이 재발을 줄이는 표준 절차이다.