(5/5) 멀티 클라우드로 넓히기 — 클라우드가 여럿일 때 깨지는 것들
- 금융권 망분리, 내부망과 외부망 — 왜 갈랐고 지금은 왜 푸는가
- 제로트러스트 설계 — 망분리 다음의 금융보안을 구성요소로 뜯어보기
- 마이크로세그멘테이션 실전 — 트래픽 흐름 위에 default-deny 그리기
- 가시성·정책 자동화 — 흐름을 관찰하고 정책을 코드로 굴리기
- 멀티 클라우드로 넓히기 — 클라우드가 여럿일 때 깨지는 것들 ← 지금 글
Summary
지난 글까지는 사실상 한 클러스터, 한 환경을 가정했어요. 흐름을 관찰하고 정책을 코드로 굴리는 그림이 깔끔하게 돌았죠. 그런데 현실의 금융 인프라는 점점 여러 클라우드에 걸칩니다. 주력 클라우드 하나에 SaaS 가 다른 클라우드에 있고, 재해복구는 또 다른 곳에 있고요.
클라우드가 둘만 돼도 앞에서 쌓은 것들이 쪼개지기 시작해요. 신원도, 정책도, 가시성도 클라우드마다 따로 놀거든요. 이번 마지막 편은 그 분절을 한 겹 위에서 다시 묶는 이야기예요.
💡 이 글에서 다루는 것
- 멀티 클라우드에서 깨지는 네 가지 — 신원·정책·가시성·규제
- 공통 신원 — SPIFFE/SPIRE 로 클라우드를 가로지르는 워크로드 ID
- 단일 정책 — GitOps 한 소스에서 여러 클러스터로
- 중앙 가시성 — 흐름·감사 로그를 한곳으로
- 금융권 규제 레이어 — 금융보안원 CSP 안전성 평가
- 멀티 클라우드에서 빠지기 쉬운 함정
1. 무엇이 깨지는가
2편에서 “경계가 흐려진다” 고 했죠. 멀티 클라우드는 그 극단이에요. 클라우드마다 자기만의 IAM·네트워크 모델·키 관리(KMS) 를 가지고 있어서, 한 환경에서 통하던 통제가 옆 클라우드에선 그대로 안 먹습니다.
깨지는 걸 네 가지로 정리하면 이래요.
| 깨지는 것 | 한 클라우드면 | 여러 클라우드면 |
|---|---|---|
| 신원 | 단일 IAM | 클라우드마다 IAM 제각각 |
| 정책 | 한 모델로 통제 | 네트워크·정책 모델이 서로 다름 |
| 가시성 | 로그 한곳 | 로그가 클라우드별로 사일로 |
| 규제·키 | 한 번 평가 | CSP 마다 평가·키 관리 곱 |
🚨 핵심은 “클라우드별 기능을 일일이 따라가면 통제가 분절되고, 그렇다고 공통분모만 쓰면 종속을 못 벗어난다” 는 긴장이에요. 답은 클라우드 위에 공통 레이어를 한 겹 얹어, 신원·정책·가시성을 클라우드 중립으로 다루는 거예요.
2. 공통 신원 — SPIFFE/SPIRE
가장 먼저 묶어야 할 게 신원이에요. 클라우드 A 의 워크로드가 클라우드 B 의 자원에 접근할 때, “너 누구냐” 를 양쪽 IAM 이 서로 못 알아보면 제로트러스트의 명시적 검증 자체가 성립을 안 하니까요.
여기에 쓰는 표준이 SPIFFE(명세)와 그 구현체 SPIRE 예요. 클라우드·온프레미스를 가로질러 워크로드에 공통 신원(SPIFFE ID) 을 부여합니다. 형태는 URI 한 줄이에요.
spiffe://core-banking.example/ns/payments/sa/api
└── 트러스트 도메인 ──┘ └ 네임스페이스 ┘ └서비스┘
이 ID 는 어느 클라우드에 떠 있든 동일해요. 워크로드가 시작될 때 SPIRE 가 환경 속성을 검사(attestation)해서 그 맥락에 맞는 ID(SVID)를 발급하고요. 등록은 이런 식입니다.
spire-server entry create \
-spiffeID spiffe://core-banking.example/ns/payments/sa/api \
-parentID spiffe://core-banking.example/agent/aws-node \
-selector k8s:ns:payments \
-selector k8s:sa:api
Entry ID : 7f3c...e1
SPIFFE ID : spiffe://core-banking.example/ns/payments/sa/api
Parent ID : spiffe://core-banking.example/agent/aws-node
Selectors : k8s:ns:payments, k8s:sa:api
클라우드가 다르면 트러스트 도메인도 다를 수 있는데, 이때는 trust bundle(공개키 묶음)을 서로 교환하는 연합(federation) 으로 이어요. 클라우드 A 의 워크로드가 클라우드 B 의 워크로드를 글로벌 신뢰 앵커 없이 검증할 수 있게 됩니다.
✅ 효과는 둘이에요. ① 클라우드 IAM 위에 이식 가능한 공통 신원이 생기고, ② 특정 클라우드 IAM 에 종속(lock-in) 되지 않아요. 신원이 클라우드 중립이 되는 거죠.
3. 단일 정책 — GitOps 한 소스에서
4편에서 정책을 Git 으로 굴렸죠. 멀티 클라우드에선 이게 선택이 아니라 필수가 돼요. 클라우드마다 콘솔 들어가서 손으로 맞추면 그 순간 정책이 어긋나기 시작하거든요.
한 저장소를 단일 진실 공급원으로 두고, 클라우드별 클러스터로 각각 reconcile 합니다.
policy-repo/
├── base/ # 클라우드 중립 정책 (NetworkPolicy 등)
│ ├── default-deny.yaml
│ └── allow-dns.yaml
└── clusters/
├── cloud-a/ # 클라우드 A 오버레이
├── cloud-b/ # 클라우드 B 오버레이
└── cloud-c/
정책의 본체는 base 에 클라우드 중립으로 두고(표준 NetworkPolicy 처럼), 클라우드별 차이만 오버레이로 얇게 얹는 게 핵심이에요. 그래야 “클라우드 A 에선 막혔는데 B 에선 열려 있는” 사고를 막아요.
클러스터 사이를 넘나드는 통신까지 마이크로세그멘테이션하려면 Cilium Cluster Mesh 같은 걸로 여러 클러스터를 묶어, 3편의 정책을 클러스터 경계 너머로 똑같이 적용할 수 있어요.
4. 중앙 가시성 — 로그를 한곳으로
가시성도 마찬가지예요. 클라우드마다 흐름 로그·감사 로그가 따로 쌓이면, “방금 그 이상 흐름이 어느 클라우드의 무엇이었나” 를 한눈에 못 봅니다. 사일로가 곧 사각지대예요.
[클라우드 A] Hubble 흐름 ┐
[클라우드 B] 감사 로그 ├──▶ 중앙 수집(SIEM) ──▶ 통합 탐지·상관분석
[클라우드 C] CSP 로그 ┘
- 흐름 로그 — 각 클러스터의 eBPF 관찰(Hubble)을 중앙으로 모아 클라우드 경계를 넘는 흐름까지 한 화면에서.
- 자세 점검(posture) — CSPM/CNAPP 류로 “클라우드별 설정이 정책에서 벗어났나” 를 통합 점검. 멀티 클라우드일수록 사람이 일일이 못 봐요.
- 상관분석 — 클라우드 A 의 신원으로 B 에서 벌어진 행위를, 공통 SPIFFE ID 를 키 삼아 한 줄로 잇기.
2장의 공통 신원이 여기서 또 일해요. 로그마다 클라우드별 계정 ID 가 제각각이면 못 잇는데, 공통 ID 가 있으면 클라우드를 가로지르는 행위를 하나로 추적할 수 있거든요.
5. 금융권 규제 레이어 — CSP 안전성 평가
기술로 다 묶어도, 금융권엔 규제 레이어가 한 겹 더 있어요. 클라우드를 쓰려면 그 클라우드(CSP)가 안전한지 먼저 따져야 합니다. 그게 금융보안원 CSP 안전성 평가 예요.
- 근거 — 「전자금융감독규정」 제14조의2 (2023-01-01 시행). 금융회사를 대신해 금융보안원이 CSP 를 평가.
- 방식 — CSP 자체 점검 + 금융보안원 현장 평가.
- 항목 — 최근 합리화로 141개 → 54개(11개 분야)로 축소. 다만 하위 점검은 여전히 수백 개 수준.
- 중요업무 구분 — 중요업무와 비중요업무에 서로 다른 기준·연속성 계획을 적용.
🚨 멀티 클라우드의 숨은 비용이 여기 있어요. CSP 가 늘면 평가·이용보고·키 관리가 그만큼 곱해집니다. “클라우드 하나 더”는 기술 부채만이 아니라 규제 부채이기도 해요. 그래서 클라우드를 늘릴 땐 기술 일관성만큼 규제 부담도 같이 계산해야 합니다.
키 관리도 빼놓을 수 없어요. 클라우드마다 KMS 가 다르니, 키를 직접 들고 가는(BYOK/HYOK) 전략으로 데이터 주권과 종속을 같이 관리하는 게 보통이에요.
6. 빠지기 쉬운 함정
- 최소공통분모 함정 — 종속이 싫어서 모든 클라우드의 공통 기능만 쓰면, 정작 각 클라우드의 강점을 못 살려요. 신원·정책·가시성은 중립으로, 그 외는 클라우드 강점대로 가 현실적인 선.
- 셋 중 하나만 통합 — 신원만 묶고 가시성은 사일로면 반쪽이에요. 2·3·4장은 세트로 가야 의미가 있어요.
- 규제 오버헤드 과소평가 — 5장에서 봤듯 CSP 마다 평가·보고가 곱해져요. 클라우드 수는 적게, 신중히 늘리는 게 비용·규제 양쪽에 유리.
- 복잡도 폭증 — 묶는 레이어(SPIRE·Cluster Mesh·중앙 SIEM) 자체가 또 운영 대상이에요. 작은 범위로 시작해, 정말 둘 이상의 클라우드가 필요할 때 넓히세요.
마치며 — 다섯 편을 닫으며
이걸로 시리즈를 닫아요. 다섯 편을 한 줄로 잇으면 이렇습니다.
- 끊기(망분리) — 인터넷을 끊어서라도 코어를 지킨다.
- 검증하기(제로트러스트) — 위치 대신 검증으로 신뢰를 옮긴다.
- 쪼개기(마이크로세그멘테이션) — 내부를 잘게 갈라 횡적 이동을 막는다.
- 보고 되돌리기(가시성·자동화) — 흐름을 관찰하고 정책을 코드로 굴린다.
- 넓히기(멀티 클라우드) — 여러 클라우드를 공통 신원·정책·가시성으로 다시 묶는다.
관통하는 생각은 처음부터 끝까지 하나였어요. 경계를 믿는 보안에서, 검증하고 관찰하고 코드로 다스리는 보안으로. 망분리가 비웠던 자리를 메우는 여정이, 결국 더 넓은 환경에서도 통하는 운영 원리로 이어진 셈이에요.
긴 시리즈 함께 읽어주셔서 고맙습니다.
다음엔 또 다른 주제로 찾아올게요.
← 이전 글: (4/5) 가시성·정책 자동화 — 흐름을 관찰하고 정책을 코드로 굴리기
참고: SPIFFE / SPIRE (공식) · 금융보안원 — 금융분야 클라우드 이용 가이드/CSP 안전성 평가
