Consul-Terraform-Sync 보안 모델

Consul-Terraform-Sync 보안 모델 (CTS Security Model)

Consul NIA(Network Infrastructure Automation)의 보안 모델을 설명하는 문서예요. Consul-Terraform-Sync 데몬의 보안 구성 요구 사항, 위협 모델, 권장 사항을 다뤄요.

출처: 문서

본문

네트워크 인프라 자동화(NIA)는 Consul-Terraform-Sync(consul-terraform-sync) 데몬을 사용해 서비스 변경으로 트리거되는 네트워크 인프라 장치의 동적 업데이트를 가능하게 합니다. 이 데몬은 Consul의 카탈로그를 사용해 서비스에 대한 네트워킹 정보를 모니터링하고 Terraform의 프로바이더 생태계와 함께 관련 변경 사항을 네트워크 인프라에 적용합니다.

프로덕션 환경을 위한 안전한 Consul-Terraform-Sync 설치를 배포하는 실습 안내는 Automate your network configuration with Consul-Terraform-Sync 튜토리얼을 완료하세요.

페르소나 (Personas)

Consul NIA의 보안 모델을 고려할 때 다음 페르소나를 생각해보면 도움이 됩니다.

  • 시스템 관리자 (System administrators) - consul-terraform-sync 데몬의 기본 인프라, 그리고 가능하면 핵심 Consul 서비스에 접근할 수 있습니다. 종종 배스천 호스트를 통해 클러스터 내 서버에 직접 SSH로 접근할 수 있습니다. 궁극적으로 consul-terraform-sync 바이너리에 대한 읽기, 쓰기, 실행 권한을 가집니다. 이러한 사용자는 기본 컴퓨팅 리소스에 대한 sudo, 관리자 또는 기타 권한 있는 접근을 잠재적으로 가집니다.
  • Consul NIA 운영자 - consul-terraform-sync 구성, Consul ACL 토큰 및 다양한 네트워크 인프라 API와 상호작용하는 데 사용되는 기타 시크릿을 정의할 수 있는 접근 권한이 있습니다. 데몬을 구성, 시작, 중지할 수 있는 능력을 포함해 consul-terraform-sync의 모든 부분에 대한 전체 접근 권한이 있습니다.
  • 개발자 (Developers) - Consul로 연결되거나 구성된 애플리케이션을 만들고 배포하는 책임이 있습니다. 경우에 따라 메트릭이나 로그 같은 것을 통해 Consul 정보를 보는 데 접근 권한이 없거나 제한된 능력이 있을 수 있습니다.
  • 사용자 (Users) - NIA 데몬이 관리하는 애플리케이션과 기타 서비스를 소비하는 최종 사용자이며, 데몬의 API 엔드포인트, ACL 토큰, 인증서 또는 시스템의 다른 어떤 부분에 대한 지식이나 접근이 없어야 합니다.

보안 구성 (Secure configuration)

Consul NIA의 보안 모델은 시스템의 모든 부분이 보안 구성으로 실행될 때만 적용됩니다. consul-terraform-sync는 기본적으로 안전하지 않습니다. 데몬의 구성에서 다음 메커니즘을 활성화하지 않으면 데몬에 대한 접근을 남용할 수 있습니다. 모든 보안 고려 사항과 마찬가지로 환경에 적절한 우려 사항을 결정하고 이에 따라 보안 우려 사항을 조정해야 합니다.

요구 사항 (Requirements)

  • 구성 파일 및 디렉터리 보호 - 프로덕션을 위해 제한된 권한의 전용 NIA 사용자와 그룹을 만들고, 운영 환경에 적절히 범위 지정된 디렉터리 및 파일 권한을 만들어야 합니다. 다음 예시 명령은 전용 consul-nia 시스템 사용자와 지원 디렉터리, 구성 파일을 만들고 chown과 chmod로 권한을 보호합니다:
$ useradd --system --shell /bin/false consul-nia
$ mkdir -p /consul-nia/data
$ mkdir -p /consul-nia/config
$ echo "{ ... }" > /consul-nia/config/file.hcl
$ chown --recursive consul-nia:consul-nia /consul-nia
$ chmod -R 0750 consul-nia/
  • Consul KV 경로 또는 네임스페이스 보호 - 데몬은 다른 네임스페이스에서 Consul 서비스를 모니터링할 수 있습니다. 이는 데몬에 사용된 ACL 토큰을 기반으로 제한할 수 있습니다.
  • Consul ACL 사용 - Consul 내의 ACL(액세스 제어 목록) 시스템을 사용해 NIA 데몬이 작동하는 데 필요한 Consul의 필수 부분에만 접근을 제한할 수 있습니다.
    • 지정된 경로와 네임스페이스에 대한 Consul KV의 읽기 및 쓰기 권한.
    • 모니터링할 선택된 모든 서비스와 그 네임스페이스에 대한 Consul 카탈로그의 읽기 권한.
    • NIA 건강 모니터링을 사용할 때 헬스 검사를 업데이트하는 읽기 및 쓰기 권한.

권장 사항 (Recommendations)

  • 전용 호스트 사용 - NIA 데몬은 환경의 네트워크 인프라에 대한 중요 시크릿에 접근할 수 있습니다. 이러한 민감한 작업을 지원하기 위해 강화된 전용 호스트를 사용하는 것을 권장합니다.
  • Root 없이 실행 - NIA 데몬은 작동에 root 또는 기타 관리자 권한이 필요하지 않습니다.
  • NIA 데몬 API 엔드포인트 보호 - NIA 데몬이 제공하거나 노출하는 모든 네트워크 엔드포인트는 Consul 서비스 메시와 적절한 방화벽 규칙으로 보호해야 합니다.
  • 중앙 집중식 로깅 솔루션 사용 - consul-terraform-sync에서 생성된 syslog 내 로그 항목을 중앙 집중식 로깅 솔루션으로 내보냅니다.
  • 사용된 Terraform 프로바이더 감사 - NIA 데몬으로 구성된 Terraform 프로바이더는 신뢰하는 소스의 프로바이더만 사용하는지 확인하기 위해 감사해야 합니다.

위협 모델 (Threat model)

다음은 NIA 위협 모델의 부분입니다:

  • Consul 에이전트 통신 - Consul 카탈로그의 변경 사항을 모니터링하기 위해 NIA 데몬은 로컬 또는 원격 서버 에이전트의 Consul HTTP API와 상호작용합니다. 이 통신은 TLS 전송 암호화가 필요하며, 상호 인증을 위해 mTLS를 사용하는 것이 좋습니다.
  • NIA Terraform 통신 - NIA 데몬의 Terraform 실행이 관리하는 다운스트림 인프라 API에 대한 네트워크 연결은 안전한 접근을 위해 적절히 구성되어야 합니다.
  • 전송 중 데이터 변조 - 모든 변조는 감지 가능해야 하고 데몬이 요청 처리를 피하도록 해야 합니다.
  • 인증 또는 승인 없이 데이터에 접근 - Consul 에이전트에 대한 요청은 (m)TLS와 ACL로 각각 인증·승인되어야 합니다. ACL은 환경에 필요한 최소 권한으로 구성되어야 합니다.
  • 서비스 거부(DoS) - NIA 데몬에 대한 DoS 공격은 Consul이나 Terraform의 보안을 손상시키지 않아야 하지만, 네트워크 내 트래픽을 적절히 처리하기 위해 데몬의 업데이트에 의존하는 네트워킹 구성 요소에 영향을 줄 수 있습니다. 데몬에 대한 접근은 방화벽 규칙으로 방지해야 합니다.

다음은 위협 모델의 일부가 아닙니다. NIA 데몬은 보안 구성을 기대하고, 로컬 환경에서 테스트하기 위해 항상 기본 옵션을 제공하지만 (보안과 사용 용이성을 모두 자동으로 구성할 수 없음) 프로덕션 배포를 강화할 때 관리자와 운영자가 평가해야 할 유효한 우려 사항입니다:

  • Consul NIA 구성 파일 또는 디렉터리에 접근(읽기 또는 쓰기) - 데몬 프로세스에 필요한 구성은 단일 파일 또는 파일 디렉터리에서 로드될 수 있습니다. 이러한 구성은 시크릿을 포함할 수 있고 안전하지 않은 기능이나 Terraform 프로바이더를 활성화/비활성화할 수 있습니다.
  • Consul NIA Consul KV 경로에 접근(읽기 또는 쓰기) - 데몬의 Consul KV 경로에 대한 접근은 Terraform이 인프라를 프로비저닝하는 데 사용하는 사용자 이름, 암호, 인증서, 토큰 같은 민감한 정보를 유출할 수 있습니다.
  • 실행 중인 Consul-Terraform-Sync 프로세스에 대한 메모리 접근 - 데몬 프로세스의 메모리에 직접 접근하면 공격자가 민감한 정보를 추출할 수 있습니다.
  • 실행 중인 Terraform 프로세스에 대한 메모리 접근 - 데몬 프로세스가 관리하는 실행 중인 Terraform 프로세스의 메모리에 직접 접근하면 공격자가 민감한 정보를 추출할 수 있습니다.
  • Terraform 바이너리 접근 - NIA 데몬이 사용하는 Terraform 바이너리에 직접 접근하면 공격자가 민감한 정보를 추출할 수 있습니다.
  • Consul-Terraform-Sync 바이너리 접근 - NIA 데몬을 시작하는 데 사용되는 시스템 바이너리에 직접 접근하면 공격자가 민감한 정보를 추출할 수 있습니다.

내부 위협 (Internal threats)

  • NIA 운영자 - NIA 호스트와 관련 바이너리 또는 구성 파일에 접근할 수 있는 사람은 특히 다중 팀 배포를 고려할 때 배포에 위협이 될 수 있습니다. 우발적으로 또는 의도적으로 악성 Terraform 프로바이더를 사용하거나 다양한 시크릿을 추출해 네트워크에 피해를 줄 수 있습니다. NIA 호스트에 대한 접근은 보호해야 합니다.
  • Consul 운영자 - NIA 운영자와 유사하게 백엔드 Consul 클러스터에 접근할 수 있는 사람은 Terraform 실행을 트리거할 수 있는 작업을 수행할 수 있습니다. 또한 NIA 데몬의 네임스페이스와 KV 경로에 접근할 수 있어 Terraform의 상태 파일에 의도하지 않은 접근을 줄 수 있으며, 이에는 민감한 정보가 포함됩니다. Consul에 대한 ACL 권한은 민감한 정보가 포함된 상태 파일을 실수로 다른 Consul 운영자에게 유출하는 정책이 없는지 신중히 감사해야 합니다.
  • 시스템에 묶인 공격자 - 다중 테넌트 환경, 특히 컨테이너 오케스트레이터는 여러 보안 우려 사항을 도입할 수 있습니다. 여기에는 공유 시크릿, 호스트 볼륨 접근, 다양한 수단을 통한 잠재적 피보팅 또는 권한 상승 원인이 포함될 수 있습니다. OS, 클러스터, 서비스, 사용자, 디렉터리, 파일 권한을 구성하는 추가 단계는 프로덕션 환경에서 심층 방어(defense-in-depth)를 구현하는 데 필수입니다.

외부 위협 (External threats)

  • Terraform 프로바이더 및 모듈 - 잠재적으로 악성인 프로바이더나 모듈, 또는 Terraform 생태계의 일부인 어떤 악성 종속성도 네트워크에 피해를 줄 수 있고 필요한 네트워크 변경을 하기 위해 시크릿에 접근할 수 있습니다. Terraform 프로바이더 구성은 감사하고 버전에 고정(pin)하며 Terraform Registry의 타이포스쿼팅(typo-squatting) 잠재적 이슈를 감사해야 합니다.
  • 네트워크에 묶인 공격자 - 서비스가 공개 인터넷에 노출될 때마다 숨겨진, 인증되지 않은 또는 취약한 엔드포인트를 찾는 외부 네트워크 공격자를 반드시 고려해야 합니다. 이는 외부 리소스에서 내부 리소스로 피보팅할 수 있을 때 더 큰 보안 우려로 이어질 수 있습니다.
  • 시크릿 유출 - Consul NIA 데몬이 사용하는 TLS 인증서와 토큰은 외부 공격자가 Consul 또는 Terraform 리소스에 접근할 수 있게 합니다. 이러한 시크릿은 GitHub 같은 공개 장소에 업로드된 구성에 하드코딩하면 안 됩니다.

더 알아보기 (Learn more)