Boundary 보안 모델

Boundary는 자격 증명을 숨기고 최소 권한 정책을 적용하면서 인프라 대상에 안전하고 감사 가능한 연결을 브로커링해요. 이 보안 모델은 모든 접근 및 세션 브로커링 작업에 대해 기밀성, 무결성, 인증, 그리고 책임성(accountability)을 보장해요.

출처: HashiCorp Boundary docs

본문

심층 방어(defense in depth)는 안전한 특권 접근 관리에 매우 중요하고, 배포 요구 사항은 사용 사례에 따라 극적으로 달라질 수 있어요. 이 문서를 상황에 맞게 조정해야 할 수도 있지만, 안전한 Boundary 배포를 위한 일반적인 메커니즘은 다음과 같아요.

mTLS — 클라이언트, 컨트롤러, 워커 컴포넌트 간의 상호 TLS 인증. 모든 당사자가 유효한 인증서를 제시하도록 요구해서 무단 접근을 막아요. 이 요구 사항은 내부 통신과 세션 브로커링 작업을 보호해요.
RBAC(역할 기반 접근 제어) — Boundary의 허용-전용(allow-only) 권한 모델. 역할에 권한을 부여하고 이를 사용자, 그룹, 관리 그룹에 할당해서 인증된 연결에 대한 인가를 가능하게 해요.
스코프(Scopes) — 조직과 프로젝트 내 대상에 대한 접근을 제어해서 인프라 리소스에 대한 세밀한 접근을 허용해요.
데이터 암호화 — Boundary 데이터베이스에 저장된 민감한 데이터는 외부 키 관리 시스템을 사용한 봉투 암호화(envelope encryption)로 보호돼요.

이 메커니즘들의 조합은 강력한 보안 자세를 만들어, 관리자가 최소 권한 접근을 강제하고, 자격 증명을 최종 사용자와 분리하고, 포괄적인 감사 로그를 유지하고, 민감한 네트워크에 대한 직접 연결 없이 안전한 네트워크 트래버설을 보장할 수 있게 해줘요.

위협 모델 (Threat model)

다음은 Boundary 위협 모델의 다양한 부분이에요.

모든 Boundary 통신 도청 — 클라이언트, 컨트롤러, 워커 간의 모든 통신은 TLS 또는 상호 인증된 TLS로 보호되어 기밀성과 무결성을 보장해요.
저장 중 또는 전송 중 데이터 변조 — 세션 정보, 구성, 영구 상태에 대한 무단 수정이 감지되어야 하며, 트랜잭션 중단이나 세션 종료를 일으켜야 해요.
인증이나 인가 없이 대상 또는 제어에 접근 — 정의된 세밀한 정책에 따라 모든 요청이 인증되고 인가되어야 해요.
책임성 없이 대상 또는 제어에 접근 — 감사 로깅이 활성화되면 민감한 데이터가 전송되기 전에 모든 접근 시도와 특권 작업이 기록되어야 해요.
관리 자격 증명의 기밀성 — Boundary가 브로커링하는 자격 증명은 명시적으로 인가되지 않는 한 클라이언트에 노출되어서는 안 되며, 자격 증명 유출을 방지해요.
세션 브로커링 서비스의 가용성 — Boundary는 인프라 장애가 발생해도 접근을 유지할 수 있도록 고가용성 배포를 지원해요.

범위 밖 (Not in scope)

다음은 Boundary 위협 모델의 일부로 명시적으로 간주되지 않아요.

Boundary 호스트(컨트롤러, 워커) 침해에 대한 보호 — 컨트롤러나 워커 호스트에서 임의 코드 실행이나 특권 접근이 있는 공격자는 보안 보증을 훼손할 수 있어요. 여기에는 다음에 대한 접근이 포함돼요: 구성과 상태를 담은 Boundary 데이터 디렉터리, 실행 중인 Boundary 컨트롤러나 워커 프로세스의 메모리, 수정된 Boundary 바이너리를 실행할 능력, 워커 호스트 네트워크 트래픽을 리다이렉트할 능력.
최종 사용자 또는 관리자 장치 침해에 대한 보호 — 공격자가 사용자의 장치를 침해하고 유효한 Boundary 자격 증명을 얻으면 그 자격 증명의 권한으로 작업을 수행할 수 있어요. 브로커링된 자격 증명은 사용자 장치에 반환되어 평문으로 표시될 수 있어요. Boundary Client Agent의 세부 사항: Client Agent는 세션 자격 증명과 관련 정보를 메모리에 저장해요. Boundary CLI는 인증 토큰을 플랫폼별 키링 저장소에 영구 저장해요. 공격자가 Client Agent 프로세스의 메모리를 읽거나 Client Agent가 실행되고 인증된 OS 사용자 계정을 침해하면 활성 세션 자격 증명에 접근할 수 있을 수 있어요. Client Agent의 보안은 OS 사용자 컨텍스트에 의존해요. OS 사용자는 세션을 만든 DNS 조회를 시작한 것과 동일한 OS 사용자인 경우에만 Client Agent가 관리하는 세션에 연결할 수 있어요. 이 OS 사용자 계정의 침해는 로컬 보호를 우회해요. 공격자가 로컬 호스트에서 Client Agent의 DNS 가로채기 메커니즘을 방해할 수도 있어요.
외부 자격 증명 소스의 취약점에 대한 보호 — Boundary는 HashiCorp Vault, 클라우드 IAM(Identity and Access Management) 서비스, 다른 자격 증명 저장소와 같은 시스템과 통합되지만, 이러한 외부 서비스를 노리는 익스플로잇으로부터 보호할 수는 없어요.
리소스 존재의 유출에 대한 보호 — Boundary가 자격 증명 세부 정보를 보호하긴 하지만, 백엔드에 대한 읽기 접근이 있는 공격자는 특정 대상이나 인증 메서드가 존재한다는 것을 볼 수 있을 수 있어요(접근할 수는 없어도).
네트워크 수준 서비스 거부 공격에 대한 보호 — Boundary는 고가용성 구성을 지원하고 속도 제한을 제공하지만, 네트워크 표면을 겨냥한 대량(volumetric) DoS 공격에 대한 내재적 보호 기능은 포함하지 않아요.
대상 애플리케이션 취약점에 대한 보호 — 대상(SSH 서버, 데이터베이스 등)에 대한 세션이 설정되면 Boundary는 그 대상 애플리케이션의 취약점을 보호할 수 없어요.

HCP Boundary

HCP Boundary는 단일 AWS 리전의 가용 영역 3개에 걸쳐 배포돼요. 각 고객 클러스터는 Docker 컨테이너의 Nomad 작업으로 배포돼요. Nomad 작업은 VPC의 PrivateLink를 통해 Nomad 클러스터에 접근하는 외부 서비스에 의해 제어돼요.

주어진 HCP Boundary 클러스터에서 사용자가 접근할 수 있는 유일한 엔드포인트는 컨트롤러이며, 무작위로 생성된 32자 클러스터 UUID를 가져요: https://<cluster_id>.boundary.hashicorp.cloud. 이 기계 생성 URL은 식별 가능한 패턴을 제공하지 않아 컨트롤러 열거를 방지해요.

테넌시 모델 (Tenancy model)

HCP Boundary는 테넌트별 별도 데이터베이스를 가진 멀티 테넌트 RDS Postgres 클러스터를 사용해요. 이 아키텍처는 Postgres의 데이터베이스 격리에 내재된 보안 제어를 사용해요. 모든 비밀 및 민감한 행 데이터는 스코프별, 테넌트별 키로 암호화돼요.

이 모델은 브리지 모델이나 풀 모델과 달리 일반적으로 실로(siloed) 멀티 테넌트 데이터베이스라고 불러요. 실로 모델을 사용하면 가장 엄격한 보안을 유지하면서 아키텍처를 단순화할 수 있어요.

자체 관리 워커 (Self-managed workers)

자체 관리 워커는 HCP 인프라 밖에서 관리자가 자신의 클라우드나 온프레미스 환경에서 관리하는 워커예요. 모든 Boundary 워커-컨트롤러 및 클라이언트-워커 통신과 마찬가지로 자체 관리 워커는 상호 인증된 TLS로 컨트롤러와 클라이언트에 연결해요. 자체 관리 워커가 HCP Boundary 컨트롤러에 인증하는 방법에 대한 자세한 내용은 PKI 기반 워커 인증을 참고해요.

침해된 워커는 그 워커에 할당된 대상과 침해된 워커가 제공하는 로그 데이터의 무결성까지 침해될 수 있어요.

HCP Boundary의 데이터 저장 (Data storage in HCP Boundary)

Boundary 컨트롤러와 워커 인프라는 무상태(stateless)이며, 모든 상태는 RDBMS에 있어요. 각 HCP Boundary 클러스터에는 Aurora Postgres 클러스터 안의 별도 데이터베이스가 제공돼요. Vault 데이터베이스 엔진이 정기적으로 회전되는 동적 자격 증명으로 데이터베이스에 접근을 제공해요.

데이터 암호화 (Data encryption)

HCP Boundary 클러스터는 root, recovery, worker-auth KMS 키에 Vault Transit 비밀 엔진을 사용해요. Boundary 컨트롤러에는 자신의 개별 키에만 접근할 수 있는 정책이 할당된 토큰으로 Vault transit 키에 대한 접근이 제공돼요. 이 토큰은 정기적으로 회전돼요.

관리자는 Vault나 HCP Vault를 포함한 외부 키 관리 시스템을 사용해서 키 암호화 root 키를 관리할 수도 있어요. 지원되는 외부 KMS 시스템에 대한 자세한 내용은 kms 스탠자 문서를 참고해요.

전송 중 데이터 (Data in transit)

모든 사용자-컨트롤러 통신은 TLS로 수행돼요. TCP 리스너 문서의 TLS 구성 옵션을 참고해요.

워커-컨트롤러와 클라이언트-워커를 포함한 다른 모든 통신은 상호 인증된 TLS로 수행돼요. Boundary는 TLS 키를 자동으로 생성하고 관리해요.

HCP Boundary의 신원 및 접근 (Identity and access in HCP Boundary)

HCP 플랫폼은 관리자가 생성과 삭제 같은 상위 수준 클러스터 작업을 수행할 수 있게 해줘요. HCP 포털을 사용해서 HCP 사용자와 그 권한을 관리할 수 있어요. HCP Boundary 클러스터를 만들면 Boundary 사용자와 권한을 Boundary 자체 안에서 관리하게 돼요.

관리자가 HCP 클러스터 테넌트를 만들면 클러스터를 부트스트랩하기 위한 관리 자격 증명을 만들라는 프롬프트가 표시돼요. 그런 다음 관리자는 Boundary 특정 인증 메서드를 사용해서 컨트롤러에 직접 연결하고 관리 작업을 수행할 수 있어요.

Boundary 보안 모델