올해 금보원의 판단 기준이 바뀐 것 중에 하나가 SRV-001이다. 윈도우에 해당하는 것으로, 판단 기준은 다음과 같다.
▶ 양호: 보안설정이 적용된 네트워크 모니터링 서비스를 사용하는 경우
▶ 취약: 보안설정이 적용되지 않은 네트워크 모니터링 서비스를 사용하는 경우
네크워크 모니터링 서비스의 보안 설정이 미비할 경우 데이터 변조, 도청 및 중간자 공격으로 시스템 정보 및 상태정보가 유출될 가능성이 존재하므로 프로토콜에 따라 알맞은 버전 및 보안설정을 적용하여 사용하고 있는지 여부를 점검하는 것이다.
그리고 이 '보안설정이 적용'에서 구체적으로 요구하는 것이 DCOM 보안 설정 적용 여부다.
① 인증 수준인 DCOM Authenticity Level이 '패킷 개인정보' 수준으로 설정되어 있는지
② 클라이언트의 권한을 사용할 수 없는 속성인 DCOM Impersonation Level이 'Identify'로 되어 있는지
올해 새롭게 추가된 내용이기 때문에 100이면 100 안되어있다고 봐야한다. 보통은 Authenticity Level이 2인 connect로 설정되어 있을 것이다. 그렇기에 윈도우 자산이 많은 곳에서는 이걸 다 적용해야 하는지 따져보아야 할 것이다.
1. 위의 ①에서 Packet Privacy 설정이 되어 있지 않다면 어떤 위협이 존재하는가
이는 쉽게 말하자면 암호화 통신이다. 암호화 통신을 통해 데이터 무결성과 기밀성을 보장하는 것이며, 레벨6이 아니라면 스니핑을 우려할 수 있을 것이다.
2. 위의 ②에서 Identify 설정이 되어 있지 않다면 어떤 위협이 존재하는가
Identify 설정은 서버가 클라이언트의 신원을 확인하되, 그 권한을 대신 사용할 수 없게 하는 것이다. 만일 Impersonate, Delegate 등으로 되어 있다면, 권한 상승 시도로 인한 권한 오남용의 위험이 있다.
3. 대체할 수 있는 방안은 무엇이 있는가
이 위협의 핵심은 MITM, 동일한 보안 보증이다. 즉, 그것을 커버할 수 있는 방안 내지는 솔루션이라면 대체가 가능하다. 하지만, 동일한 보증을 모든 통신 경로에 올바르게 배포 및 운영한다는 걸 실현시키기는 어렵다. 즉, MITM 방지, 보안 보증 등의 효과를 지닌 방안도 완벽한 대체가 아닌, 보완하는 정도에 그칠 가능성이 높다. End to End 암호화, 상호 인증, 무결성 보장, 재전송 보호, 완전한 범위 적용 등이 모두 수행되어야 하는데, 이걸 대체로 할 바엔 그냥 DCOM 설정을 하는 게 낫다.
굳이 대체를 해야 한다면, IPsec, VPN 등의 방식이 있는데, 이 경우에도 SRV-001의 위협의 의의를 따져 충족하는지 여부를 확인해야 할 것이다.
4. 수 백, 수 천 대의 자산의 설정을 바꿀 때 가용성 문제는 생기지 않는가
당연히 생길 수 있다. 그리고 높다. COM은 더 낮은 수준으로 도착하는 호출에 실패한다. 즉, LEVEL 2와 LEVEL 6의 통신은 실패한다는 것이다. 그래도 모든 자산을 6으로 올리면 해결되는 것 아닌가? 그건 맞지만, 호환성 문제도 고려해야 한다. 즉 자산이 500대인 경우, 그 윈도우 500대의 자산이 통신하는 대상이 LEVEL 6일 때도 문제가 없어야 한다는 점이다. 이를 위해서는 샘플링으로 LEVEL 6 전환을 시도해야 할 것이다. 그래서 물려있는 각 통신을 시도해보고, 문제가 없다면 전체 자산의 설정을 적용해야 할 것이다.
5. 클라이언트 호환성에 실제로 문제가 발생했다면 어떻게 대처해야 하는가
통신 장애가 발생한 서버와 클라이언트 쌍을 특정하고, DCOM 오류 로그를 확인하여, 어떤 애플리케이션과 인증 수준 때문에 통신이 실패했는지 진단해야 한다. 그리고 가용성 확보를 위해 문제가 된 서버 쌍의 DCOM 설정을 우선 롤백한다.
문제가 된 애플리케이션의 벤더에 해당 DCOM 강화(Level 6)에 대한 공식 지원 여부를 문의하고, 벤더가 패치나 업데이트를 제공하는 경우, 이를 적용할 일정 및 절차를 수립한다. 만일, 벤더의 패치 적용에 시간이 오래 걸리거나 불가능한 경우, IPsec 터널링 등을 활용하여 해당 통신 경로에만 네트워크 계층 암호화를 강제 적용하는 방안을 임시로 고려할 수 있을 것이다. 단, 이는 SRV-001의 DCOM 설정 요구사항을 충족하지 못할 수 있으므로, 예외 사유와 상세 보완 계획을 문서화해야 할 것이다.
'기타' 카테고리의 다른 글
Spring Boot 취약점 체크리스트 초안을 만들며 (0) | 2025.09.29 |
---|---|
조직 내 보안인식 제고를 위한 정보보호 퀴즈를 경험하며 (0) | 2025.09.28 |
서버의 기술적 취약점 추가 항목 고찰 (0) | 2025.09.07 |
컨설팅을 하며 느끼는 한계와 개선 방향성 (4) | 2025.08.06 |
2025 개인정보 처리방침 주요 개정사항 (2) | 2025.07.31 |