클라우드 아키텍처(CAF / Zero Trust)를 IaC 검증에 연결하려고 시도하기

Source: Dev.to

우리는 종종 아키텍처는 의도를 정의하고, 인프라스트럭처 코드(IaC)는 구현을 정의한다고 말합니다.
실제로는 두 개가 금방 멀어집니다.

• 아키텍처는 문서(CAF, Zero Trust, 내부 HLD) 안에 존재합니다
• IaC는 실제로 배포된 것을 반영합니다
• 두 것이 일치하는지 확인할 신뢰할 만한 방법이 없습니다

문제점

IaC는 정밀성을 제공하지만 의미는 제공하지 못합니다.
아키텍처는 의미를 제공하지만 검증은 제공하지 못합니다.

그래서 우리는 다음과 같은 상황에 처합니다:

• 시스템은 “올바르게 배포”되었지만
• 아키텍처적으로는 잘못되었습니다

우리는 이러한 불일치를 리뷰, 감사, 혹은 사고가 발생했을 때만 발견합니다.

작은 실험

아키텍처를 구조화된 모델로 표현하고 Terraform 상태와 검증할 수 있는지 탐색하기 위해 작은 PoC를 만들었습니다.

아이디어:

Risk → Control → Constraint → Implementation → Validation

개별 리소스를 검증하는 대신, 이 모델은 여러 수준에서 아키텍처를 평가할 수 있게 합니다.

매핑 수준

• PASS – 리소스가 기대되는 구성과 일치함
• FAIL – 리소스는 존재하지만 잘못 구성됨
• MISSING – 리소스가 존재하지 않음

제어 수준

• FAILED – 하나 이상의 매핑이 실패함
• INCOMPLETE – 부분적으로 구현됨
• MISSING – 전혀 구현되지 않음

위험 수준

• EXPOSED – 제어가 완전히 구현되지 않음

예시

데모 시나리오에서는:

• 파라미터 불일치로 인해 하나의 제어가 실패하고
• 또 다른 제어는 부분적으로만 구현되었으며
• 또 다른 제어는 태그 불일치로 실패하고
• 또 다른 제어는 완전히 누락되었습니다

검증기는 이를 다음과 같이 집계합니다:

FAILED control → EXPOSED risk

따라서 다음과 같이 물을 수 있습니다:

“이 리소스가 규정에 부합합니까?”

대신에 이렇게 물을 수 있습니다:

“이 아키텍처 위험이 노출되어 있습니까?”

이 실험이 탐구하고자 하는 것

이는 IaC나 정책 엔진을 대체하려는 것이 아닙니다.
다음과 같은 추가 계층을 도입하려는 것입니다:

• 아키텍처 의도(위험 / 제어)와
• 구현(Terraform)을 연결하고
• 그 연결을 지속적으로 검증하는 것

열린 질문

여전히 내 사용 사례 외에서도 의미가 있는지 탐색 중입니다. 관심 있는 질문들:

• 이 모델이 실제 환경에서 실제로 도움이 될까요?
• “제어 수준” 검증이 유용할까요, 아니면 과도한 설계일까요?
• 대규모 아키텍처에서는 어떻게 확장될 수 있을까요?
• 어디에서 이 모델이 깨질 수 있을까요?

저장소

다음과 같은 작은 작업용 PoC를 준비했습니다:

• 간단한 아키텍처 모델(YAML)
• Terraform 상태에 대한 검증기
• 다양한 실패 모드를 보여주는 데모

👉

Terraform, Azure, 혹은 보안 아키텍처를 다루는 분들의 의견을 듣고 싶습니다.