구성 드리프트는 피할 수 없는 것처럼 보입니다. 즉, 시스템의 실제 구성 설정이 보안 기준 구성에서 점진적이지만 의도치 않게 벗어나는 현상입니다. 인프라 구성 요소를 올바르게 구성하는 것은 보안, 컴플라이언스, 비즈니스 연속성에 매우 중요하지만, 설정 변경은 공식 승인, 적절한 테스트, 명확한 문서화 없이 이루어지는 경우가 많습니다.
시간이 지나면서 시스템과 애플리케이션에서 발생하는 이러한 구성 드리프트는 보안 취약 지점을 만들어 조직을 위험에 빠뜨릴 수 있습니다. 실제로, 8건 중 1건의 침해 는 잘못 구성된 클라우드 환경 같은 오류에서 비롯되는 것으로 추정되며, 보안 설정 오류는 상위 10대 웹 애플리케이션 보안 위험에 대한 OWASP 목록 에서 5위를 차지합니다. 구성 드리프트가 심각할수록 위험도는 더 커지지만, 현실적으로는 단 하나의 잘못된 설정만으로도 조직이 데이터 유출 및 다운타임에 노출될 수 있습니다.
이 문서에서는 구성 드리프트(Configuration Drift)의 일반적인 원인 몇 가지와, 침해 사고 위험·업타임 중단(downtime)·컴플라이언스 위반에 따른 페널티를 줄이기 위해 적절한 구성 관리(Configuration Management)를 구현하는 방법을 설명합니다.
엄선한 관련 콘텐츠:
구성 드리프트(Configuration Drift)는 무엇이 원인인가요?
대부분의 경우 구성 드리프트는 의도적인 것이 아닙니다. 보통 다음 중 하나가 원인입니다:
- 소프트웨어 패치 — 소프트웨어와 펌웨어 패치를 정기적으로 적용하는 것은 모범 사례이지만, 구성 항목에 예기치 않은 변경이 발생할 수 있습니다.
- 하드웨어 업그레이드 — 하드웨어 업그레이드 또한 필요하지만, 하드웨어 및 소프트웨어 수준에서 설정 변경을 초래할 수 있습니다.
- 임시성 설정 및 문제 해결 — Almost 대부분의 IT 팀은 업무량 증가나 네트워크 장애로 인해 비즈니스 운영이 정상으로 돌아갈 수 있도록 때때로 빠른 임시 조치를 적용한 적이 있을 것입니다. 빠른 임시 조치가 당장의 문제를 해결할 수는 있지만, 장기적으로 보안을 해칠 수 있는 설정 변경을 수반할 수 있습니다.
- IT 내 커뮤니케이션 부족 — Configuration drift는 한 IT 팀이 자신이 변경한 설정에 대해 다른 팀에 알리지 않거나, 새 팀원이 어떤 구성 상태가 승인되었는지 모를 때 발생할 수 있습니다.
- 문서화 부족 — 구성 변경 사항이 제대로 문서화되어 있지 않으면, 팀원들이 시스템이 올바르게 구성되었는지 판단하지 못할 수 있습니다.
이러한 요인으로 인해 발생하는 Configuration drift는 성능 저하나 가동 중단, 컴플라이언스 문제, 또는 심각한 데이터 침해로 이어질 수 있습니다.
구성 드리프트(configuration drift)를 방지하기 위한 팁
NIST Special Publication 800-128구성 드리프트(configuration drift)를 방지하기 위한 지침을 제공합니다. 주요 권장 사항은 다음과 같습니다:
- 구성 변경 사항을 지속적으로 모니터링하여 부적절한 수정이 즉시 식별될 수 있도록 하세요. 또한 모니터링 활동은 정기적인 감사를 통해 보완해야 합니다.
- 사전에 수립된 템플릿을 사용해 서버 및 네트워크 인프라 전반에 걸쳐 구성 설정의 생성, 수정, 배포를 자동화하는 구성 도구를 구현하세요. 수동 작업은 사람의 실수에 취약하고 자동화 프로세스보다 느리기 때문에, 설정이 취약한 상태로 더 오래 남게 됩니다.
- IT 팀이 구성 드리프트(configuration drift)를 식별하는 데 사용할 수 있는 벤치마크 및 기준선(baseline) 저장소를 활용하세요. CIS 또는 NIST와 같은 업계 리더의 벤치마크를 시작점으로 삼아 기준 구성(baseline configurations)을 구축하는 방안을 고려해 보세요.
- 구성 변경 관리 프로세스를 표준화하여 구성 드리프트가 발생할 가능성을 최소화하세요. 모든 구성 변경은 이 시스템을 사용해 승인하고 문서로 남겨야 합니다.
모든 IT 엔드포인트를 위한 안전한 기준 구성 개발
사용자 데스크톱, 서버, 애플리케이션, 네트워크 장비, 컨테이너, 하이퍼바이저 플랫폼은 모두 안전한 구성으로 강화해야 합니다. 각 엔드포인트 유형별로 표준 구성을 수립하면, 전반에 걸쳐 일관된 구성을 적용할 수 있습니다. 예를 들어 콜센터 워크스테이션용 표준 구성을 만들면 동일한 운영 체제, 패치 수준, 소프트웨어 포트폴리오 및 Group Policy.
기준 구성은 시간이 지나면서 예를 들어 소프트웨어 패치와 운영체제 업그레이드로 인해 변경될 수 있습니다. 각 변경 사항은 서비스 제공 및 보안에 미칠 잠재적 영향을 면밀히 검토해야 합니다. 업데이트된 구성이 승인되고 권한이 부여되면, 이를 기준 구성으로 승격할 수 있으며, 이후 모든 장치는 새로운 표준에 따라 감사되어야 합니다. NERC CIP 표준은 에너지 생산에 필요한 모든 SCADA, 인간-기계 인터페이스(HMI), 프로그래머블 로직 컨트롤러(PLC) 시스템에 대해 매 30일마다 이러한 감사를 수행할 것을 요구합니다.
Netwrix Change Tracker로 구성 관리 자동화
안전한 기준(baseline)을 설정하고 구성 드리프트(configuration drift)를 방지하기 위해 강력한 변경 관리(change control)를 적용할 방법을 찾고 계신가요? Netwrix Change Tracker가 도움이 됩니다. Netwrix Change Tracker는 네트워크를 스캔하여 장치를 찾아내고, CIS 인증 빌드 템플릿을 사용해 해당 장치에 대한 안전한 구성을 손쉽게 만들 수 있게 해줍니다. 그런 다음 이러한 구성의 변경 사항을 모니터링하고, 계획되지 않은 수정이 발생하면 실시간으로 알려드립니다.
기준(baseline) 설정하기
Netwrix Change Tracker를 사용하면 NIST, PCI DSS, CMMC, HIPAA, 그리고 CIS Controls 등 다양한 내용을 포함한 250개 이상의 CIS 인증 벤치마크 보고서에 액세스할 수 있습니다. 직관적인 마법사(wizard)를 사용하면 몇 분 안에 이러한 벤치마크를 사용자의 특정 요구 사항에 맞게 세밀하게 조정할 수 있습니다. 또한 PLC, 릴레이(relays), 액추에이터(actuators) 같은 IoT 시스템부터 복잡한 클라우드 및 컨테이너 인프라에 이르기까지 모든 시스템에 대해 표준 구성을 손쉽게 만들 수 있습니다. 더불어 어떤 기준(baseline) 이미지든 다른 시스템의 벤치마킹에도 재사용할 수 있습니다.
기준(baseline) 유지하기
앞서 언급했듯이, 기준(baseline)은 시간이 지나면서 변경될 수 있습니다. 특히 패치와 업데이트는 구성(configuration), 레지스트리(registry) 및 포트(port) 설정뿐만 아니라 기반이 되는 파일 시스템에도 변경을 유발할 수 있습니다. Netwrix Change Tracker는 어떤 설정을 기준(baseline)으로 승격(프로모션)할지 사용자가 직접 관리할 수 있도록 해줍니다.
모든 빌드 프로세스는 보안 모범 사례에 기반해 진행됩니다. 기준선(baseline) 승격, 편집, 생성의 모든 단계에서 사용자 권한이 제어됩니다. 또한 누가, 무엇을, 언제, 왜 했는지에 대한 상세한 감사 추적(audit trail)을 제공하므로, 시간이 지남에 따라 어떤 기준선 이미지가 정확히 어떻게 변경되었는지 확인할 수 있습니다.
구성(설정) 드리프트를 감지하고 대응하기
Netwrix Change Tracker 또한 위협 인텔리전스를 활용해 시스템 파일에 발생한 원치 않거나 잠재적으로 위험한 변경을 정확히 찾아내는 고급 변경 제어 기능도 제공합니다. 실제로 이 도구는 기기에서 새로 생성되거나 변경된 파일을 확인하기 위해 수십억 개의 승인된 해시(approved hashes)를 사용합니다. 그 결과 Microsoft의 Patch Tuesday로 인한 대규모 변경이 경고로 넘쳐나게 만들지 않으면서도, 방치되어 있던(수많은 변경 속에 숨은) 악의적인 수정은 즉시 알아차릴 수 있습니다.
결론
변화는 피할 수 없지만, 설정(구성) 값이 안전한 기준선에서 벗어나도록 그대로 두어야 할 필요는 없습니다. Netwrix Change Tracker 같은 자동화된 구성 관리 도구를 사용하면, 비용이 많이 드는 성능 문제와 가동 중단, 보안 침해, 컴플라이언스 위반에 따른 제재를 방지하기 위해 시스템 전반에서 안전한 구성을 수립하고 유지할 수 있습니다.
자주 묻는 질문
안전한 기준(baseline) 구성이란 무엇인가요?
기준(baseline) 구성 또는 골드 빌드(gold build)는 시스템의 표준이자 승인된 구성입니다. 여기에는 승인된 운영체제, 패치 수준, 설치된 소프트웨어와 같은 요소를 명시할 수 있습니다. 기준을 더 안전하게 만들려면 CIS Benchmark 또는 DoD STIG 지침을 바탕으로 기준을 구축하는 방안을 고려하세요.
내 시스템의 기준(baseline) 구성을 어떻게 결정하나요?
유사한 시스템 그룹마다 기준(baseline) 구성을 수립하세요. 예를 들어 회계 부서에서 사용하는 모든 워크스테이션은 동일한 기준 구성으로 통일되어야 합니다.
구성 하드닝을 위한 모범 사례: 구성 하드닝 다음을 포함하세요:
- 필요하지 않은 소프트웨어는 제거(언인스톨)하고, 사용하지 않는 모든 역할과 기능을 삭제하세요.
- 불필요한 서비스와 데몬은 제거하거나 비활성화하세요.
- 불필요한 논리 네트워크 포트는 제거하거나 차단하세요.
- 모든 소프트웨어를 최신 버전 수준으로 패치된 상태로 유지하세요.
다만 기준 구성(baseline configuration)을 만들 때는 보안과 비즈니스 우선순위의 균형을 맞춰야 할 가능성이 높다는 점을 유의하세요. 보안이 필요한 기능을 위해 양보해야 하는 경우에는 웹 애플리케이션 방화벽(WAF)이나 방화벽 서비스 같은 다른 보안 제어로 이를 보완할 수 있습니다.
기준 구성(baseline configuration)은 얼마나 자주 업데이트해야 하나요?
기준 구성(baseline configurations)에 대한 변경은 피할 수 없고 동시에 필요합니다. 특히 정기적인 패치와 업데이트는 새롭게 발견된 취약점에 대응하고, 새로운 소프트웨어 기능에 접근할 수 있도록 하는 데 매우 중요합니다. 이러한 프로세스가 구성 변경으로 이어지는 경우, 서비스 제공 및 보안에 미치는 영향을 신중하게 평가한 다음 기준 구성(baseline configuration)을 업데이트할지, 그리고 어떻게 업데이트할지 결정해야 합니다. 업데이트된 기준 구성은 관련된 모든 시스템에 즉시 적용해야 합니다.
NERC CIP 표준은 에너지 생산에 필요한 모든 SCADA, HMI 및 PLC 시스템의 기준 구성(baseline configurations)을 30일마다 감사를 수행하도록 요구합니다.
구성 관리 계획(configuration management plan)이란 무엇인가요?
구성 관리 계획은 기준 구성(baseline configuration)을 설정하기 위한 프로세스, 구성 변경이 발생하는지 시스템을 모니터링하는 절차, 부적절하거나(또는 승인된) 변경 사항을 시정하는 방법, 그리고 시간이 지나도 기준 구성을 유지하는 방법을 정의합니다.
구성 드리프트(configuration drift)를 어떻게 막을 수 있나요?
구성 드리프트(configuration drift)는 흔히 발생하는 문제이지만, 강력한 구성 관리로 관리할 수 있습니다. 특히 다음을 수행해야 합니다:
- 각 시스템 및 애플리케이션 유형별로 기준 구성(baseline configuration)을 설정하세요.
- 모든 구성 변경을 계획하고, 계획대로 적용되었는지 확인한 후, 이를 문서화하세요.
- 구성 설정의 변경 사항을 모니터링하고 이를 분류(트리아지)하세요.
- 문제를 빠르게 해결하려고 ad-hoc 또는 임시방편을 적용하지 마세요.
공유하기
더 알아보기
저자 소개
Dirk Schrader
보안 연구 부문 VP
Dirk Schrader는 Netwrix의 레지던트 CISO(EMEA)이며 보안 연구 부문 VP입니다. CISSP (ISC²) 및 CISM (ISACA) 자격증을 보유한 IT 보안 분야 25년 경력의 베테랑으로, 사이버 위협에 대응하는 현대적 접근 방식으로서 사이버 복원력을 발전시키기 위해 노력하고 있습니다. Dirk는 커리어 초기에 기술 및 지원 역할에서 시작해, 이후 대규모 다국적 기업과 소규모 스타트업 모두에서 영업, 마케팅, 제품 관리 직무로 자리를 옮기며 전 세계의 사이버보안 프로젝트에 참여해 왔습니다. 그는 사이버 복원력을 달성하기 위해 변화 관리와 취약점 관리의 필요성을 다룬 수많은 글을 게재해 왔습니다.