핵심 보안 모델

핵심 보안 모델 (Core Security Model)

이 문서는 Consul 보안의 핵심 모델을 설명해요. mTLS, ACL, 네임스페이스, Sentinel 정책 등 심층 방어(defense in depth) 원칙과 보안 구성 요구 사항, 위협 모델을 다룰게요.

출처: 문서

본문

Consul은 모든 클라우드 또는 런타임에서 네트워크 구성, 서비스 디스커버리, 보안 네트워크 연결의 자동화를 가능하게 합니다.

Consul은 다양한 필수 기능을 제공하는 가벼운 gossip 및 RPC 시스템을 사용합니다. 두 시스템을 모두 사용하면 기밀성, 무결성, 인증을 활성화할 수 있습니다.

Consul 보안에는 심층 방어(defense in depth)가 중요하며, 배포 요구 사항은 사용 사례에 따라 크게 다를 수 있습니다. 멀티 테넌트 배포를 위한 일부 보안 기능은 Enterprise 버전에서만 제공됩니다. 이 문서는 여러분의 환경에 맞게 조정해야 할 수 있지만, 보안 Consul 배포의 일반적인 메커니즘은 다음과 같습니다:

mTLS - TLS 서버와 클라이언트 x509 인증서의 상호 인증은 클러스터 내 네트워크 컴포넌트에 대한 무단 접근으로 인한 내부 남용을 방지합니다.
ACL - 인증된 연결에 대해 역할 기반 접근 제어를 활성화하여 ACL 토큰을 통해 개별 인간 또는 머신 운영자 아이덴티티에 권한을 부여해 클러스터 내 작업을 승인합니다. 선택적으로 사용자 지정 인증 메서드를 사용해 신뢰된 외부 당사자가 ACL 토큰 생성을 승인하도록 할 수 있습니다.
네임스페이스 (Namespaces) Enterprise - 읽기·쓰기 작업을 논리적 네임스페이스로 범위를 지정해 멀티 테넌트 환경에서 Consul 컴포넌트에 대한 접근을 제한할 수 있습니다.
Sentinel 정책 Enterprise - Sentinel 정책은 내장 키-값 저장소에 대한 세밀한 제어를 위한 policy-as-code를 활성화합니다.

페르소나 (Personas)

Consul 배포의 보안 요구 사항을 관리할 때 다음 유형의 페르소나를 고려하는 것이 도움이 됩니다. 세분성은 팀의 요구 사항에 따라 달라질 수 있습니다.

시스템 관리자 (System administrator) - Consul 클러스터의 기본 인프라에 접근할 수 있습니다. 종종 bastion 호스트를 통해 클러스터 내 서버에 SSH 또는 RDP로 직접 접근합니다. 궁극적으로 실제 Consul 바이너리에 대한 읽기, 쓰기, 실행 권한을 가집니다. 이 바이너리는 다른 구성 파일을 사용하는 서버와 클라이언트 에이전트에 동일합니다. 이러한 사용자는 기본 컴퓨팅 리소스에 sudo, 관리 또는 다른 슈퍼유저 접근 권한을 가질 수 있습니다. 디스크 또는 메모리의 모든 영구 데이터에 접근할 수 있습니다. 여기에는 시스템에 저장된 ACL 토큰, 인증서, 기타 시크릿이 포함됩니다. 이러한 사용자는 기본 운영 체제에 대한 관리 권한을 가지며 에이전트를 구성, 시작, 중지할 수 있으므로 본질적으로 완전히 신뢰됩니다.
Consul 관리자 (Consul administrator) - 서버와 클라이언트의 Consul 에이전트 구성을 정의할 수 있고/또는 Consul 관리 ACL 토큰을 가집니다. 또한 클러스터 내 모든 서비스를 관리하는 능력을 포함해 Consul 시스템의 모든 부분에 대한 총체적 권한을 가집니다. 일부 조직에서는 이 역할과 시스템 관리자 역할이 같은 사람일 수 있습니다.
Consul 운영자 (Consul operator) - 클러스터 내 네임스페이스를 사용하는 데 제한된 능력을 가질 가능성이 높습니다.
개발자 (Developer) - Consul과 연결되거나 구성된 애플리케이션을 만들고, 가능하면 배포하는 책임이 있습니다. 어떤 경우에는 메트릭이나 로그 같은 Consul 정보를 볼 수 있는 접근 권한이 없거나 제한된 능력을 가질 수 있습니다.
사용자 (User) - Consul이 관리하는 서비스가 지원하는 애플리케이션을 사용하는 최종 사용자입니다. 어떤 경우에는 웹 서버처럼 서비스가 인터넷에 공개될 수 있으며, 일반적으로 로드 밸런서나 인그레스 게이트웨이를 통해 공개됩니다. Consul 에이전트 API에 대한 네트워크 접근 권한이 없어야 하는 사람입니다.

보안 구성 (Secure configuration)

Consul의 보안 모델은 시스템의 모든 부분이 보안 구성으로 실행되는 경우에만 적용됩니다; Consul은 기본적으로 보안되지 않습니다(not secure-by-default). Consul 구성에서 다음 메커니즘을 활성화하지 않으면 클러스터에 대한 접근이 남용될 수 있습니다. 모든 보안 고려 사항과 마찬가지로 관리자는 환경에 적절한 것이 무엇인지 결정하고 구성을 그에 맞게 조정해야 합니다.

요구 사항 (Requirements)

mTLS - TLS 서버와 클라이언트 x509 인증서의 상호 인증은 클러스터 내 Consul 에이전트에 대한 무단 접근을 통한 내부 남용을 방지합니다.
- tls.defaults.verify_incoming - 기본적으로 false이며, 인바운드 클라이언트 연결에 대한 TLS 검증을 요구하려면 거의 항상 true로 설정해야 합니다. 이는 내부 RPC, HTTPS 및 gRPC API에 적용됩니다.
- tls.https.verify_incoming - 기본적으로 false이며, Consul HTTPS API가 활성화될 때 클라이언트가 유효한 TLS 인증서를 제공하도록 요구하려면 true로 설정해야 합니다. API가 localhost 같은 루프백 인터페이스에서만 제공된다면 API용 TLS가 필요하지 않을 수 있습니다.
- tls.internal_rpc.verify_incoming - 기본적으로 false이며, Consul 에이전트 RPC에 클라이언트가 유효한 TLS 인증서를 제공하도록 요구하려면 거의 항상 true로 설정해야 합니다.
- tls.grpc.verify_incoming - 기본적으로 false이며, Consul gRPC API가 활성화될 때 클라이언트가 유효한 TLS 인증서를 제공하도록 요구하려면 true로 설정해야 합니다. API가 localhost 같은 루프백 인터페이스에서만 제공된다면 API용 TLS가 필요하지 않을 수 있습니다.
- tls.internal_rpc.verify_outgoing - 기본적으로 false이며, 서버 또는 클라이언트 에이전트의 아웃바운드 연결에 TLS를 요구하려면 true로 설정해야 합니다. verify_outgoing = true를 지정하는 서버는 항상 다른 서버와 TLS로 통신하지만, 모든 클라이언트의 TLS 전환을 허용하기 위해 비-TLS 연결도 계속 수용합니다. 현재 클라이언트가 암호화되지 않고 서버와 통신할 수 없도록 시행하는 유일한 방법은 [truncated]
다음은 서버 에이전트 예제 구성입니다:
```
tls {
  defaults {
    verify_incoming = true
    verify_outgoing = true
    ca_file = "consul-agent-ca.pem"
    cert_file = "dc1-server-consul-0.pem"
    key_file = "dc1-server-consul-0-key.pem"
    verify_server_hostname = true
  }
}
```
```
auto_encrypt {
  allow_tls = true
}
```
다음은 클라이언트 에이전트 예제 구성입니다:
```
tls {
  defaults {
    verify_incoming = false
    verify_outgoing = true
    ca_file = "consul-agent-ca.pem"
    verify_server_hostname = true
  }
}
```
```
auto_encrypt {
  tls = true
}
```
팁 클라이언트 에이전트 예제 TLS 구성은 모든 인바운드 트래픽이 localhost로 제한된다고 가정해 verify_incoming을 false로 설정합니다. 이 구성의 주요 이점은 로컬 Consul 에이전트를 사용하는 모든 도구나 애플리케이션에 (ACL 토큰 외에) 클라이언트 TLS 인증서를 프로비저닝하지 않아도 된다는 것입니다. 이 경우 ACL을 활성화해 권한 부여를 제공하고 ACL 토큰만 배포하면 됩니다.
ACL - 접근 제어 목록(ACL) 시스템은 Consul 관리자가 개별 인간 또는 머신 운영자 아이덴티티에 연결된 능력을 부여할 수 있는 보안 메커니즘을 제공합니다. 궁극적으로 ACL 시스템을 보호하려면 관리자가 default_policy를 "deny"로 구성해야 합니다.

ACL 시스템은 다섯 가지 주요 컴포넌트로 구성됩니다:
- 🗝 토큰 (Token) - 정책, 역할 또는 서비스 아이덴티티와 연결된 API 키.
- 📜 정책 (Policy) - 다양한 Consul 리소스에 대한 접근을 허용하거나 거부하는 규칙 집합.
- 🎭 역할 (Role) - 정책과 서비스 아이덴티티의 그룹화.
- 👤 서비스 또는 노드 아이덴티티 (Service or Node Identity) - Consul에 배포된 서비스에 일반적인 사전 정의된 권한 집합을 부여하는 합성 정책.
- 🏷 네임스페이스 (Namespace) Enterprise - 일반적으로 멀티 테넌트 환경을 활성화하기 위한 Consul Enterprise 리소스의 명명된 논리적 범위. Consul CE 클러스터는 항상 "default" 네임스페이스에서 작동합니다.
Gossip 암호화 (Gossip encryption) - 공유되는 base64 인코딩된 32바이트 대칭 키가 AES GCM을 사용해 클러스터 내 Serf gossip 통신을 암호화하는 데 필요합니다. 키 크기는 사용할 AES 암호화 유형을 결정합니다; 16, 24, 32바이트는 각각 AES-128, AES-192, AES-256을 선택합니다. 32바이트 키가 궁극적으로 선호되며 keygen 명령이 생성하는 기본 크기입니다. 이 키는 Consul의 내장 키링 관리 기능을 사용해 정기적으로 순환해야 합니다.

다음 두 선택적 gossip 암호화 옵션을 사용하면 gossip 암호화가 없는 Consul 서버가 안전하게 업그레이드할 수 있습니다. 업그레이드 후에는 검증 옵션을 활성화하거나 제거해 기본 상태로 설정해야 합니다:
- encrypt_verify_incoming - 기본적으로 true이며 인바운드 gossip 통신에 암호화를 적용합니다.
- encrypt_verify_outgoing - 기본적으로 true이며 아웃바운드 gossip 통신에 암호화를 적용합니다.
네임스페이스 (Namespaces) Enterprise - 읽기·쓰기 작업을 논리적 네임스페이스로 범위를 지정해 멀티 테넌트 환경에서 Consul 컴포넌트에 대한 접근을 제한해야 합니다. 또한 이 기능은 범위가 지정된 네임스페이스 내 팀을 위한 Consul ACL 관리의 셀프 서비스 방식을 가능하게 합니다.
Sentinel 정책 Enterprise - Sentinel 정책은 내장 키-값 저장소에 대한 세밀한 제어를 허용합니다.
스크립트 check 비활성화 (Ensure script checks are disabled) - Consul 에이전트는 선택적으로 localhost 너머로 노출될 수 있는 HTTP API를 가집니다. 이런 경우 enable_script_checks는 false여야 합니다. 그렇지 않으면 ACL이 구성되어 있더라도 스크립트 check는 원격 코드 실행 위협이 됩니다. enable_local_script_checks는 HTTP API가 노출되어야 하는 경우 안전한 대안을 제공하며 1.3.0부터 사용할 수 있습니다. 이 기능은 여기에 설명된 대로 패치 릴리즈 0.9.4, 1.1.1, 1.2.4에도 백포트되었습니다. 기본적으로 활성화되지 않습니다.
원격 실행 비활성화 (Ensure remote execution is disabled) - Consul에는 클러스터 전체에서 임의 명령의 실행을 허용하는 consul exec 기능이 포함됩니다. 이 기능은 0.8.0부터 기본적으로 비활성화되어 있습니다. 비활성화된 상태로 두는 것을 권장합니다. 활성화하면 클러스터에서 임의 코드를 실행하도록 접근을 제한하는 올바른 ACL을 보장하는 데 각별한 주의가 필요합니다.

권장 사항 (Recommendations)

자격 증명 순환 (Rotate credentials) - 잠재적으로 손상된 시크릿으로 인한 폭발 반경을 제한하고 기본 감사를 활성화하기 위해 프로덕션 환경에서 단기 자격 증명을 사용하고 자주 순환하는 것이 강력히 권장됩니다.
- ACL 토큰 - Consul API는 클러스터 내 작업을 승인하기 위해 ACL 토큰을 요구합니다.
- X.509 인증서 - Consul 에이전트가 사용하는 인증서를 순환합니다; 예를 들어 Vault의 PKI 시크릿 엔진과 통합해 짧은 TTL로 각 Consul 노드에 대한 동적 고유 X.509 인증서를 자동 생성·갱신할 수 있습니다. auto_encrypt를 사용할 때 클라이언트 인증서는 Consul이 자동 순환할 수 있어 Vault가 관리하는 인증서는 서버 인증서뿐입니다.
- Gossip 키 - Consul 에이전트의 내부 gossip 프로토콜이 사용하는 암호화 키는 내장 키링 관리 기능을 사용해 정기적으로 순환할 수 있습니다.
루트 없이 실행 (Running without root) - Consul 에이전트는 데이터 디렉터리에 대한 접근만 필요로 하는 권한 없는 사용자로 실행할 수 있습니다.
Linux 보안 모듈 - Consul 에이전트 호스트에 AppArmor, SELinux, Seccomp 같은 운영 체제에 직접 통합될 수 있는 보안 모듈 사용.
TLS 설정 사용자 지정 (Customize TLS settings) - 가용한 암호 스위트 같은 TLS 설정을 환경의 요구에 맞게 조정해야 합니다.
- tls_min_version - 사용할 최소 TLS 버전을 지정하는 데 사용.
- tls_cipher_suites - 허용할 TLS 암호 스위트를 지정하는 데 사용.
HTTP 응답 헤더 사용자 지정 (Customize HTTP response headers) - X-XSS-Protection 같은 추가 보안 헤더를 HTTP API 응답에 대해 구성할 수 있습니다.
```
http_config {
  response_headers {
      "X-Frame-Options" = "DENY"
  }
}
```
기본 제한 사용자 지정 (Customize default limits) - Consul에는 환경에 맞게 조정해야 하는 기본 연결 제한이 있는 내장 기능이 있습니다.
- http_max_conns_per_client - Consul 에이전트의 HTTP(S) 엔드포인트에 대한 단일 클라이언트의 동시 접근을 제한하는 데 사용.
- https_handshake_timeout - Consul 에이전트의 HTTP(S) 엔드포인트에 대한 TLS 연결을 제한 시간 초과하는 데 사용.
- rpc_handshake_timeout - Consul 에이전트의 RPC 엔드포인트에 대한 TLS 연결을 제한 시간 초과하는 데 사용.
- rpc_max_conns_per_client - Consul 에이전트의 RPC 엔드포인트에 대한 단일 클라이언트의 동시 접근을 제한하는 데 사용.
- rpc_rate - 기본적으로 비활성화되어 있으며 서버 에이전트에 RPC 호출을 하는 클라이언트 에이전트의 (초당 요청 수)를 제한하는 데 사용.
- rpc_max_burst - 서버 에이전트에 RPC 호출을 하는 클라이언트 에이전트의 토큰 버킷 크기로 사용.
- kv_max_value_size - 키-값 API 요청의 최대 바이트 수를 구성하는 데 사용.
- txn_max_req_len - 트랜잭션 API 요청의 최대 바이트 수를 구성하는 데 사용.
UI 접근 보안 (Secure UI access) - Consul의 내장 UI에 대한 접근은 여러 방식으로 보호할 수 있습니다:
- mTLS - 상호 TLS 인증으로 HTTPS를 활성화하는 것이 권장되지만, mTLS 연결을 종료하기 위한 추가 도구가 필요하며, 바람직하게는 운영자의 로컬 머신에서 프록시 스크립트를 사용해야 합니다. 이를 수행하려면 HTTPS용 Consul UI 구성을 참조하세요.
- TLS - 기본 거부로 ACL이 구성된 경우처럼 UI 접근에 mTLS가 필요하지 않을 수 있는 경우 HTTPS 활성화가 권장됩니다. 이를 수행하려면 HTTPS용 Consul UI 구성을 참조하세요.
- ACL - 기본 거부 정책이 있는 ACL은 클러스터 내 민감 컴포넌트에 대한 무단 접근을 방지하여 더 안전한 UI 접근을 가능하게 합니다. ACL과 ACL 시스템 부트스트랩 방법에 대한 자세한 내용은 ACL 문서를 참조하세요.
- HTTP 쓰기 제한 (Restrict HTTP writes) - 지정된 CIDR 목록의 호스트에 대한 에이전트 엔드포인트의 쓰기 접근을 제한하기 위해 allow_write_http_from 구성 옵션 사용.
예제 에이전트 구성:
```
http_config {
  allow_write_http_from = ["127.0.0.0/8"]
}
```

위협 모델 (Threat model)

다음은 핵심 Consul 위협 모델의 일부입니다:

Consul 에이전트 간 통신 (Consul agent-to-agent communication) - Consul 에이전트 간 통신은 도청으로부터 안전해야 합니다. 이를 위해서는 클러스터에서 전송 암호화를 활성화해야 하며 TCP와 UDP 트래픽을 모두 포함합니다.
Consul 에이전트-CA 간 통신 (Consul agent-to-CA communication) - Consul 서버와 서비스 메시용 구성된 인증 기관 제공자 간 통신은 항상 암호화됩니다.
전송 중 데이터 변조 (Tampering of data in transit) - 모든 변조는 감지 가능해야 하며 Consul이 요청 처리를 피하도록 해야 합니다.
인증 또는 권한 부여 없이 데이터 접근 (Access to data without authentication or authorization) - 모든 요청은 인증되고 권한이 부여되어야 합니다. 이를 위해서는 클러스터에서 기본 거부 모드로 ACL을 활성화해야 합니다.
악성 메시지로 인한 상태 수정 또는 손상 (State modification or corruption due to malicious messages) - 형식이 잘못된 메시지는 폐기되고 형식이 올바른 메시지는 인증·권한 부여가 필요합니다.
비서버 구성원의 원시 데이터 접근 (Non-server members accessing raw data) - 모든 서버는 Raft 참여를 시작하려면 (적절한 인증·권한 부여로) 클러스터에 조인해야 합니다. Raft 데이터는 TLS로 전송됩니다.
노드에 대한 서비스 거부 공격 (Denial of Service against a node) - 노드에 대한 DoS 공격은 소프트웨어의 보안 태세를 손상시켜서는 안 됩니다.
메시 서비스 간 통신 (Communication between mesh services) - 두 개의 메시 지원 서비스(네이티브 또는 사이드카 프록시) 간 통신은 도청으로부터 안전하고 인증을 제공해야 합니다. 이는 상호 TLS를 통해 달성됩니다.

다음은 서버 에이전트의 위협 모델에 포함되지 않는 것들입니다:

Consul 데이터 디렉터리 접근 (Access (read or write) to the Consul data directory) - 비리더를 포함한 모든 Consul 서버는 전체 Consul 상태 집합을 이 디렉터리에 영구 저장합니다. 데이터에는 모든 KV, 서비스 등록, ACL 토큰, 서비스 메시 CA 구성 등이 포함됩니다. 이 디렉터리에 대한 모든 읽기 또는 쓰기는 공격자가 해당 데이터에 접근하고 변조하도록 허용합니다.
Consul 구성 디렉터리 접근 (Access (read or write) to the Consul configuration directory) - Consul 구성은 ACL 시스템을 활성화·비활성화하고, 데이터 디렉터리 경로를 수정하는 등의 작업을 할 수 있습니다. 이 디렉터리에 대한 모든 읽기 또는 쓰기는 공격자가 Consul의 여러 측면을 재구성할 수 있게 합니다. ACL 시스템을 비활성화하면 공격자에게 모든 Consul 데이터에 대한 접근을 줄 수 있습니다.
실행 중인 Consul 서버 에이전트의 메모리 접근 (Memory access to a running Consul server agent) - 공격자가 실행 중인 Consul 서버 에이전트의 메모리 상태를 검사할 수 있다면 거의 모든 Consul 데이터의 기밀성이 손상될 수 있습니다. 외부 서비스 메시 CA를 사용하는 경우 루트 개인 키 자료는 Consul 프로세스에 절대 제공되지 않으므로 안전한 것으로 간주할 수 있습니다. 서비스 메시 TLS 인증서는 손상된 것으로 간주해야 합니다; 서버 에이전트가 영구 저장하지 않지만 적어도 Sign 요청 기간 동안 메모리에 존재합니다.

다음은 클라이언트 에이전트의 위협 모델에 포함되지 않는 것들입니다:

Consul 데이터 디렉터리 접근 (Access (read or write) to the Consul data directory) - Consul 클라이언트는 로컬 상태를 캐시하기 위해 데이터 디렉터리를 사용합니다. 여기에는 로컬 서비스, 관련 ACL 토큰, 서비스 메시 TLS 인증서 등이 포함됩니다. 이 디렉터리에 대한 읽기 또는 쓰기 접근은 공격자가 이 데이터에 접근하도록 허용합니다. 이 데이터는 일반적으로 클러스터 전체 데이터의 더 작은 부분집합입니다.
Consul 구성 디렉터리 접근 (Access (read or write) to the Consul configuration directory) - Consul 클라이언트 구성 파일에는 서비스의 주소와 포트 정보, 에이전트의 기본 ACL 토큰 등이 포함됩니다. Consul 구성에 대한 접근은 공격자가 서비스의 포트를 악성 포트로 변경하고, 새 서비스를 등록하는 등의 작업을 할 수 있게 합니다. 또한 일부 서비스 정의에는 클러스터 전체에서 해당 서비스를 가장하는 데 사용될 수 있는 ACL 토큰이 연결되어 있습니다. 공격자는 ACL 시스템을 비활성화하는 같은 클러스터 전체 구성을 변경할 수 없습니다.
실행 중인 Consul 클라이언트 에이전트의 메모리 접근 (Memory access to a running Consul client agent) - 이 폭발 반경은 서버 에이전트보다 훨씬 작지만 데이터 부분집합의 기밀성은 여전히 손상될 수 있습니다. 특히 에이전트 API에 대해 요청된 서비스, KV, 서비스 메시 정보를 포함한 모든 데이터가 손상될 수 있습니다. 서버의 특정 데이터 집합이 에이전트에 의해 요청된 적이 없다면 복제가 서버 간에만 존재하므로 에이전트 메모리에 들어가지는 않습니다. 공격자는 또한 등록된 서비스 옆에 인메모리에 저장되어야 하므로 이 에이전트에서 서비스 등록에 사용된 ACL 토큰을 추출할 수도 있습니다.
로컬 서비스 메시 프록시 또는 서비스에 대한 네트워크 접근 (Network access to a local service mesh proxy or service) - 서비스와 메시 인식 프록시 간 통신은 일반적으로 암호화되지 않으며 신뢰된 네트워크에서 이루어져야 합니다. 이는 일반적으로 루프백 장치입니다. 이는 같은 머신의 다른 프로세스가 신뢰되어야 하거나 네트워크 네임스페이스 같은 더 복잡한 격리 메커니즘이 사용되어야 함을 요구합니다. 또한 외부 프로세스가 (인바운드 포트를 제외하고) 메시 서비스 또는 사이드카 프록시와 통신할 수 없어야 합니다. 따라서 비네이티브 서비스 메시 애플리케이션은 비공개 주소에만 바인딩해야 합니다.
부적절하게 구현된 서비스 메시 프록시 또는 서비스 (Improperly Implemented service mesh proxy or service) - 서비스 메시 프록시 또는 네이티브 통합 서비스는 유효한 리프 인증서를 제공하고, 인바운드 TLS 클라이언트 인증서를 검증하며, Consul 에이전트 로컬 인증 엔드포인트를 호출해야 합니다. 이 중 어떤 것이든 올바르게 수행되지 않으면 프록시 또는 서비스가 인증되지 않거나 권한이 부여되지 않은 연결을 허용할 수 있습니다.

내부 위협 (Internal threats)

운영자 (Operator) - 유효한 mTLS 인증서와 ACL 토큰을 가진 악의적인 내부 Consul 운영자는 특히 다중 팀 배포에서 특정 상황에서 여전히 클러스터에 위협이 될 수 있습니다. Consul 컴포넌트에 대한 접근을 우연히 또는 의도적으로 남용할 수 있으며, 이는 네임스페이스와 Sentinel 정책을 사용해 보호할 수 있습니다.
애플리케이션 (Application) - 로컬 에이전트가 사용하는 TLS 인증서 또는 ACL 토큰과 함께 Consul 에이전트에 접근할 수 있는 손상된 타사 종속성 같은 악의적인 내부 애플리케이션은 토큰이 허용하는 모든 것을 효과적으로 수행할 수 있습니다. 로컬 Consul 에이전트 API에 HTTPS를 활성화하고, 전체 상호 TLS 검증을 시행하며, 네임스페이스를 사용해 서비스를 분리하고, OS 사용자·그룹·파일 권한을 구성해 심층 방어 접근 방식을 구축하는 것을 고려하세요.
RPC - Consul 에이전트 RPC 엔드포인트에 접근할 수 있는 악의적인 행위자는 mTLS가 클라이언트 TLS 인증서 아이덴티티를 검증하도록 제대로 구성되지 않았다면 Consul 서버 에이전트를 가장할 수 있습니다. Consul은 또한 권한 부여를 요구하도록 기본 정책을 명시적으로 deny로 설정한 ACL을 활성화해야 합니다.
HTTP - Consul 에이전트 HTTP(S) 엔드포인트에 접근할 수 있는 악의적인 행위자는 ACL이 비활성화된 경우 에이전트의 구성된 아이덴티티를 가장하고 Consul에서 정보를 추출할 수 있습니다.
DNS - Consul 에이전트 DNS 엔드포인트에 접근할 수 있는 악의적인 행위자는 서비스 카탈로그 정보를 추출할 수 있습니다.
Gossip - Consul 에이전트 Serf gossip 엔드포인트에 접근할 수 있는 악의적인 행위자는 데이터센터 내 에이전트를 가장할 수 있습니다. 정기적으로 순환되는 gossip 키와 함께 gossip 암호화를 활성화해야 합니다.
프록시 (xDS) - Consul 에이전트 xDS 엔드포인트에 접근할 수 있는 악의적인 행위자는 Envoy 서비스 정보를 추출할 수 있습니다. ACL과 HTTPS가 활성화되면 xDS 서비스를 제공하는 gRPC 엔드포인트는 (m)TLS와 유효한 ACL 토큰을 요구합니다.

외부 위협 (External threats)

에이전트 (Agents) - gossip, HTTP, RPC, gRPC 포트를 포함한 Consul 에이전트의 다양한 네트워크 엔드포인트에 대한 외부 접근을 고려해야 합니다. 또한 SSH 또는 Nomad·Kubernetes 같은 오케스트레이션 시스템의 exec 기능 같은 다른 서비스를 통한 접근은 TLS 인증서 또는 ACL 토큰을 포함해 디스크에 영구 저장된 암호화되지 않은 정보를 노출할 수 있습니다. Consul 에이전트 디렉터리에 대한 접근은 명시적으로 Consul 위협 모델의 범위 밖이며 인증되고 권한이 부여된 사용자에게만 노출되어야 합니다.
게이트웨이 (Gateways) - Consul은 다양한 워크로드를 지원하기 위해 서비스 메시 안팎으로 트래픽을 허용하는 다양한 게이트웨이를 지원합니다. 인터넷에 노출된 게이트웨이를 사용할 때는 Consul 에이전트와 호스트 구성을 하드닝해야 합니다. 대부분의 구성에서 ACL, gossip 암호화, mTLS를 시행해야 합니다. escape hatch 재정의가 필요한 경우 보안 구성이 유지되고 Consul의 보안 모델을 위반하지 않는지 확인하기 위해 프록시 구성을 감사해야 합니다.

핵심 보안 모델