구성 드리프트란 무엇인가요?

어느 정도의 구성 드리프트는 시스템 수명 주기 동안 불가피하게 발생합니다. 구성 드리프트는 구성 요소 간 상호 작용 방식에 영향을 미치는 네트워크 수동 변경이나 관리자가 의도하지 않은 방식으로 설정을 조정하는 자동화 툴에 의해 발생할 수 있습니다. 적절한 문서화가 이루어지지 않으면 기존 관리자가 떠나고 새로운 관리자가 합류하는 과정에서 호환되지 않거나 문제가 되는 변경이 적용될 수 있습니다.

구성 드리프트의 대표적인 사례로는 관리자가 로드 밸런싱 환경에서 하나의 서버에만 수정 사항을 적용하고 다른 서버에는 적용하지 않는 경우를 들 수 있습니다. 시스템이 당장은 정상적으로 동작하더라도 이후에 문제가 발생할 수 있습니다. 패치가 적용된 서버는 기존 환경을 기준으로 설계된 향후 네트워크 업데이트와 호환되지 않는 새로운 라이브러리를 사용할 수 있으며, 이는 서비스 중단과 비효율로 이어질 가능성이 있습니다.

구성 드리프트는 성능에만 영향을 미치는 것이 아닙니다. 의도된 설정에서 벗어난 시스템은 악의적인 공격자와 데이터 침해에 더 취약해질 수 있습니다. 예를 들어 네트워크에 새로운 리소스가 추가될 때 방화벽 규칙이 함께 업데이트되지 않으면 해커가 쉽게 침투할 수 있습니다.

구성 드리프트는 컴플라이언스 상태에도 영향을 미칠 수 있습니다. 네트워크 문서에는 특정 보안 설정이 기록되어 있지만 실제 운영 환경이 다를 경우 조직은 감사에서 실패할 수 있습니다.

DevOps 전문가와 시스템 관리자는 잘못된 구성을 방지하고 구성 드리프트에 대응하기 위한 다양한 툴을 활용할 수 있습니다. Terraform과 같은 코드형 인프라(IaC) 툴은 네트워크 구성을 단일 정보 기준 역할을 하는 구성 파일과 연결합니다. 구성 파일은 새로운 네트워크 리소스가 올바른 상태로 자동 프로비저닝되도록 지원하며, 이를 통해 구성 드리프트가 발생할 가능성을 줄여줍니다.

관측 가능성 툴은 관리자에게 지표, 로그 및 추적 정보에 대한 가시성을 제공하며, 이를 통해 구성 드리프트가 발생하는 즉시 탐지하고 수정할 수 있도록 지원합니다. 불변 인프라는 기존 서버에 수정 사항을 적용하는 대신 오래된 서버를 폐기함으로써 구성 드리프트를 줄입니다. 구성 드리프트는 Ansible과 같은 구성 관리 툴을 통해서도 관리됩니다.

구성 드리프트는 일반적으로 시스템 구성에 대한 수동 변경, 자동화 오류, 조직 차원에서 발생하는 불일치 또는 이러한 요소들의 복합적인 영향으로 발생합니다.

일회성 수동 수정은 구성 드리프트의 주요 원인입니다.

"핫픽스" 또는 일반적인 업데이트 일정 외에 적용되는 수정 조치는 잘못된 타임아웃 값으로 인해 계속 충돌하는 서버와 같은 즉각적이고 긴급한 문제를 해결할 수 있습니다. 하지만 이러한 유형의 구성 변경은 이후 시스템 문제를 초래할 수 있습니다.

• 이후 시스템 업데이트가 해당 수정 사항을 고려하지 않은 채 이를 덮어쓸 경우 원래의 버그가 다시 발생할 수 있습니다.
  
  
• 수정 사항에 포함된 종속성이 추적되지 않거나 향후 네트워크 업데이트와 호환되지 않을 수 있습니다.
  
  
• 수정을 위해 생성된 임시 관리자 자격 증명이 계속 유효한 상태로 남아 추가적인 보안 위험 요소가 될 수 있습니다.

인적 오류 또는 단순히 예기치 못한 결과로 인해 시스템이 원래 유지되어야 할 상태에서 벗어나는 방식은 사실상 무한합니다. 작은 변경이라도 누적되면 실제 프로덕션 환경이 리포지토리와 거의 다른 상태가 될 수 있으며, 그 결과 버그와 보안 위험이 가득한 환경으로 이어질 수 있습니다.

적절한 테스트와 감독이 없으면 자동화된 업데이트 및 프로세스로 인해 중요한 네트워크 리소스가 의도된 구성에서 벗어날 수 있습니다.

자동화의 품질은 단일 정보 기준의 정확성에 달려 있습니다. 예를 들어 IaC 툴이 오래된 구성 파일을 기반으로 새로운 서버를 생성할 경우 환경 전체에 문제가 발생할 수 있습니다. Microsoft Windows와 같은 앱 및 운영 체제에 대한 자동화된 소프트웨어 업데이트가 서버마다 서로 다른 시점에 적용될 경우 잠재적으로 문제가 되는 차이가 발생할 수 있습니다. 또한 이러한 업데이트가 조직의 고유한 네트워크 아키텍처와 제대로 호환되지 않아 추가적인 문제를 초래할 수도 있습니다.

구성을 관리하기 위한 툴조차 특정 상황에서는 구성 드리프트를 유발할 수 있습니다. 예를 들어 연결 문제로 인해 Ansible이 구성 업데이트를 일부 서버에만 적용하고 특정 서버는 변경되지 않은 상태로 남겨둘 수 있습니다. 해당 서버는 시간이 지나면서 주변 환경과 점점 달라지게 되며, 이는 서비스 중단으로 이어질 수 있습니다.

조직 차원에서는 지속적 통합/지속적 제공 (CI/CD) 파이프라인 및 DevOps 운영 방식의 문제로 인해 구성 문제가 발생할 수 있습니다.

개발, 운영 및 보안팀이 서로 분리되어 있으면 혼란, 의사소통 오류 및 불충분한 문제 해결이 발생할 수밖에 없습니다. 기술 운영 방식의 차이뿐 아니라 조직 내 팀마다 변경 관리 방식이 서로 다를 수도 있습니다. 일부 조직은 공식적인 변경 관리 프로세스 자체를 갖추고 있지 않습니다.

변경을 수행하고 문서화하기 위한 명확하고 정립된 운영 방식이 없으면 변경 로그 불일치, 승인되지 않은 변경 및 시행되지 않는 승인 워크플로로 이어질 수 있습니다. 결국 관리자, 개발자 및 엔지니어가 변경 관리 프로세스를 완전히 우회하게 될 수도 있습니다.

구성 드리프트는 시스템의 보안, 성능 및 컴플라이언스 상태에 상당한 위험을 초래합니다.

구성 드리프트는 관리자가 인지하지 못해 수정되지 않은 보안 정책 예외를 만들어냄으로써 조직의 공격 표면을 크게 확대할 수 있습니다.

예를 들어 핫픽스를 적용하기 위해 생성된 자격 증명이 그대로 남아 있게 되면 해커가 이를 악의적인 목적으로 악용할 수 있습니다. 마찬가지로 엔지니어가 방화벽 규칙에 예외를 추가한 뒤 이를 다시 제거하지 않을 경우 네트워크 전체의 보안 상태가 크게 약화될 수 있습니다. 개발자가 테스트를 위해 보안 제어가 완전히 적용되지 않은 애플리케이션을 활성화한 뒤 이를 비활성화하지 않으면 악의적인 공격자가 악용할 수 있는 또 다른 보안 취약점이 만들어질 수 있습니다.

마찬가지로 시스템에 추가되는 새로운 앱, 엔드포인트 또는 기타 리소스에도 적절한 보안 제어가 적용되지 않으면 구성 드리프트가 발생할 수 있습니다. 예를 들어 엔드포인트 탐지 및 대응(EDR) 시스템을 올바르게 구성하지 않은 상태에서 새로운 서버를 추가하면 보안상 취약한 연결 고리가 생길 수 있습니다. 마이크로서비스 구성에서 발생한 단순한 실수 하나만으로도 보호되지 않은 대규모 자산이 네트워크에 유입될 수 있습니다.

사이버 보안과 함께 네트워크 성능은 구성 드리프트가 초래하는 가장 크고 비용 부담이 큰 위험 요소입니다.

다른 서버보다 더 많은 트래픽을 처리하는 서버를 예로 들어 보겠습니다. 이 서버는 성능 개선을 위해 핫픽스를 통해 연결 풀 크기가 증가되었을 수 있습니다. 이 서버는 로드 밸런서 뒤에서 동작하고 있기 때문에 로드 밸런서는 서버 부하를 보다 균등하게 분산하기 위해 해당 서버로 더 많은 트래픽을 보내도록 정책을 자동 설정합니다.

이후 새로운 배포 과정에서 서버가 교체되면 연결 풀을 늘렸던 핫픽스는 더 이상 적용되지 않은 상태가 되고, 추가 트래픽으로 인해 서버가 다운됩니다. 트래픽 속도를 높이기 위해 적용된 원래의 핫픽스가 바로 드리프트입니다. 이러한 요소가 고려되지 않으면 이후 네트워크 변경으로 인해 원인이 파악될 때까지 큰 비용이 드는 다운타임이 발생할 수 있습니다.

구성 드리프트는 조직이 이를 인지하지 못한 상태에서도 컴플라이언스 기준에서 벗어나게 만들 수 있습니다. 네트워크 상태가 조직이 실제로 운영하고 있다고 생각하는 상태 또는 문서에 기록된 상태와 달라지면 조직은 규정 미준수 위험에 노출됩니다. 규정 미준수가 의도되지 않은 경우라도 조직은 벌금 및 제재 비용을 부담해야 할 수 있습니다.

건강 보험 양도 및 책임에 관한 법률(HIPAA)을 예로 들어 보겠습니다. HIPAA는 조직이 전송 중 및 저장 중인 민감한 데이터를 보호하기 위해 특정 암호화 방식을 사용하도록 요구합니다.

예를 들어 관리자가 HIPAA 준수 네트워크에 레거시 시스템을 통합해야 하는데, 해당 레거시 시스템이 오래된 암호화 방식을 사용하고 있다고 가정해 보겠습니다. 이 암호화 방식이 해결되지 않으면 해당 통합으로 인해 조직은 HIPAA 규정을 준수하지 못하게 됩니다.

드리프트 탐지(네트워크 변경 사항을 추적하고 의도된 상태와의 차이를 식별하는 운영 방식)에는 코드형 인프라(IaC), GitOps, 불변 인프라 및 관측 가능성을 포함한 여러 툴의 조합이 필요합니다.

코드형 인프라(IaC)는 수동 프로세스 대신 스크립트를 사용해 IT 인프라를 프로비저닝하고 관리하는 운영 방식으로, 구성 드리프트 관리를 위한 가장 강력한 툴 중 하나입니다.

IaC는 네트워크의 원하는 상태를 버전 관리되는 코드로 변환하며, 이를 기준으로 모든 네트워크 구성 요소를 비교할 수 있도록 함으로써 구성 드리프트 해결에 도움을 줍니다.

예를 들어 Terraform에서는 변경이 발생하면 IaC 툴이 상태 파일(플랫폼이 보유한 네트워크의 최신 상태 정보)과 선언된 구성 파일, 즉 네트워크가 어떻게 구성되어야 하는지를 정의한 파일을 비교합니다. 그런 다음 Terraform은 인프라를 구성 파일에 맞게 업데이트함으로써 상태 파일과 선언된 구성 간 차이를 해결하며, 이를 통해 드리프트가 발생할 가능성을 줄입니다.

조직이 IaC 툴에 엄격한 액세스 제어를 적용하면 드리프트 발생 가능성을 더욱 줄일 수 있습니다. IaC 액세스를 필요한 권한을 가진 사용자로 제한함으로써 조직은 전반적으로 인프라 구성을 변경할 수 있는 범위를 제한합니다. 또한 변경이 발생할 경우 IaC 버전 관리 프로세스를 거치게 되므로 드리프트 위험이 더욱 완화됩니다.

GitOps는 오픈소스 리포지토리인 Git를 구성 파일의 단일 정보 기준으로 사용하는 DevOps 운영 방식입니다. GitOps는 많은 조직이 IaC를 높은 효율성과 보안 수준으로 배포할 수 있도록 지원합니다.

GitOps 운영 방식은 자동화를 사용해 네트워크 상태를 Git에 저장된 원하는 상태와 실시간으로 비교 및 검증하는 데 중점을 둡니다. GitOps 플랫폼은 네트워크를 지속적으로 스캔하고 잘못된 구성을 탐지해 이를 표시하거나 수정 사항을 적용할 수 있으며, 이를 통해 발생한 드리프트를 일시적인 상태로 유지할 수 있습니다. 또한 모든 변경 사항은 Git와 연결되어 있기 때문에 작성자, 타임스탬프 및 설명과 함께 추적됩니다.

불변 인프라는 네트워크 구성을 변경할 수 있는 기회 자체를 크게 줄임으로써 구성 드리프트를 완화합니다.

변경 불가능한 인프라는 변경이 필요할 때 서버 및 기타 IT 리소스를 수정하는 것이 아니라 교체하는 방식으로 처리하는 관행을 말합니다.

예를 들어 서버에 보안 업데이트가 필요하다고 가정해 보겠습니다. 관리자는 기존 서버에 업데이트를 적용하는 대신 해당 서버를 종료하고 새로운 업데이트 적용 서버로 교체합니다.

불변 인프라는 변경이 필요할 경우 코드에 정의된 내용에 따라 새로운 시스템을 자동 배포하기 위해 IaC 툴을 활용합니다. 네트워크에 추가되는 모든 새로운 구성 요소는 자동으로 원하는 상태와 일치하게 됩니다.

IaC, GitOps 및 불변 인프라라는 세 가지 운영 방식은 서로 긴밀하게 연결되어 있습니다. IaC 툴은 네트워크 구성 요소에 대한 이미지를 정의하며, GitOps는 배포를 지원하고 네트워크에 대한 포괄적인 기록을 구축하며 불일치를 방지합니다.

관측 가능성의 세 가지 핵심 요소(로그, 지표 및 추적) 역시 구성 드리프트 방지에 중요한 역할을 합니다.

예를 들어 관측 가능성 플랫폼은 하나의 서버에서 수집된 지표(응답 시간 또는 CPU 사용량 등)가 동일한 구성을 가져야 하는 다른 서버와 크게 달라지고 있음을 탐지할 수 있습니다. 이러한 차이는 드리프트의 잠재적인 징후일 수 있습니다. 마찬가지로 특정 서버에서 특정 유형의 오류가 비정상적으로 많이 발생하는 경우 서버별 오류율 로그의 차이가 드리프트를 나타낼 수 있습니다. 애플리케이션 호출 체인의 추적 정보 역시 편차 및 드리프트가 발생하는 위치를 드러낼 수 있습니다.

드리프트 탐지는 실제 네트워크 상태와 원하는 상태를 비교해 차이를 식별하는 운영 방식입니다. 이 작업은 이론적으로 수동 수행도 가능하지만 많은 클라우드 및 IaC 공급자가 드리프트 탐지 기능을 제공하는 툴을 제공하며, 이를 통해 시간이 많이 걸리는 작업을 자동화하고 간소화할 수 있습니다.

예를 들어 AWS Config는 AWS 모듈의 구성을 기록하고 원하는 상태에서 벗어난 항목을 표시하며 드리프트 수정에 도움을 줍니다. Terraform의 상태 평가는 실제 인프라 설정이 워크스페이스 상태 파일에 기록된 설정과 일치하는지 검증하며, 리소스가 시스템 구성에 정의된 필수 검사를 충족하는지도 지속적으로 확인합니다.

Terraform Enterprise는 현재 상태를 상태 파일과 비교하거나 실제 상태를 반영하도록 상태 파일을 업데이트함으로써 변경 사항을 드러냅니다. Ansible 및 Puppet과 같은 구성 관리 툴도 드리프트 탐지에 사용할 수 있습니다.