도입
금융권에서 망분리 완화와 SaaS 허용이 확대되는 흐름을 보며, 이것이 단순한 규정 변경이 아니라 “보안을 증명하는 방식” 자체가 바뀌는 전환이라고 느꼈습니다. 이 글에서는 금융 규제 변화의 핵심과, 쿠버네티스 환경에서 Zero Trust를 현실적으로 구현하는 방법(그리고 조직이 먼저 바꿔야 할 것)을 함께 정리합니다.
금융 망분리 완화의 핵심: “예외 허용”이 아니라 “통제의 재설계”입니다
최근 흐름을 한 문장으로 요약하면 망분리 ‘완화’와 통제 ‘강화’가 같이 간다입니다.
- 전자금융감독규정시행세칙 개정으로, 개인신용정보·고유식별정보를 처리하지 않는 SaaS는 샌드박스 없이도 내부업무망에서 활용 가능해지는 방향이 법제화되고 있습니다. 대신 반기 1회 통제평가·보고 같은 “대체 보안통제”가 요구됩니다.
- 금융당국 가이드는 내부업무용 SaaS를 망분리 예외로 명시하되, 고객 민감정보 처리 SaaS는 제외하고 제공자 평가, 단말 보호, 접근통제, 모니터링 등 엄격한 통제를 전제로 합니다.
- 보안 업계에서는 변화를 3단계로 설명합니다:
- R&D망 논리적 분리·SaaS 허용 → 2) AI·SaaS 특례의 정규화 → 3) 결과책임 기반 자율보안(CEO/CISO 책임 강화)
즉, “이제 망분리 안 해도 된다”가 아니라, 망분리가 담당하던 ‘안전의 증명’을 다른 통제들로 더 촘촘히 대체해야 한다는 구조입니다.
해외는 왜 “망분리”라는 말을 안 쓰는 것처럼 보일까요?
제가 조사하면서 가장 크게 느낀 차이는 이겁니다.
-
한국(전통적): 물리/논리 망분리라는 경계가 먼저이고, 그 위에 시스템(그리고 Kubernetes)을 올립니다.
- 장점: 감사/준수 관점에서 “경계”가 명확해 보입니다.
- 단점: 클라우드 네이티브가 전제하는 연결성(멀티클러스터, 서비스메시, SaaS 연계, 자동화된 배포/운영)을 구조적으로 제약합니다.
-
해외(인상적 차이): 플랫폼(Kubernetes)이 먼저이고, 그 위에 Zero Trust(신원·정책·관측)로 경계를 ‘정책으로’ 만든다는 느낌이 강합니다.
- 장점: 유연한 연결성을 살리면서도, “신원 기반”으로 미세분리와 통제를 구현할 수 있습니다.
- 단점: 그만큼 정책/ID/관측을 코드처럼 운영해야 하고, 운영 성숙도가 낮으면 오히려 허점이 생깁니다(예: RBAC 드리프트, 인증서 운영 실패, 예외 정책 난립).
결국 “망분리가 있냐 없냐”의 문제가 아니라, 증명 비용을 경계(물리 분리)에 지불하느냐, 정책·로그·키관리(Zero Trust)에 지불하느냐의 차이로 볼 수 있습니다.
Kubernetes에서 Zero Trust는 이렇게 “층”으로 쌓습니다
Zero Trust를 멋진 슬로건이 아니라 운영 가능한 구조로 만들려면, 저는 계층적(레이어드) 통제로 접근하는 게 현실적이라고 봅니다.
1) Default-deny 네트워크 정책: “기본 불통”이 출발점입니다
내부망을 신뢰하지 않는다는 철학을 가장 직접적으로 구현하는 방법이 default-deny NetworkPolicy입니다. 최소한 네임스페이스 단위로 “기본 차단 → 필요한 트래픽만 허용”으로 바꿔야 합니다.
apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
name: default-deny-all
namespace: app
spec:
podSelector: {}
policyTypes:
- Ingress
- Egress
설명: 이 정책 하나로 app 네임스페이스는 기본적으로 인바운드/아웃바운드가 막힙니다. 이후 “어떤 Pod가 어떤 목적지로 나가도 되는지”를 명시적으로 열어주는 정책을 추가합니다.
2) RBAC 최소권한: “누가 무엇을 할 수 있는가”를 좁힙니다
네트워크를 막아도, API 권한이 과하면 클러스터 자체가 뚫립니다. Zero Trust에서 RBAC은 “운영 편의”가 아니라 “경계”입니다.
apiVersion: rbac.authorization.k8s.io/v1
kind: Role
metadata:
name: pod-reader
namespace: app
rules:
- apiGroups: [""]
resources: ["pods"]
verbs: ["get", "list", "watch"]
설명: 최소권한의 기본은 “필요한 verb만 주기”입니다. 특히 금융 환경에서는 운영자 편의로 cluster-admin을 광범위하게 부여하는 관행부터 깨야, 망분리 완화 이후의 리스크를 감당할 수 있습니다.
3) mTLS와 서비스메시: “네트워크가 아니라 신원”으로 통신을 묶습니다
Zero Trust의 핵심은 IP가 아니라 workload identity로 통신을 인증/인가하는 것입니다. 서비스메시(Istio 등)의 mTLS를 이용하면 서비스 간 통신을 암호화하면서, “누가 누구에게 요청했는지”를 신원 기반으로 확인할 수 있습니다.
Istio 예시(Strict mTLS):
apiVersion: security.istio.io/v1
kind: PeerAuthentication
metadata:
name: default
namespace: app
spec:
mtls:
mode: STRICT
설명: 네임스페이스 내부 트래픽이 기본적으로 mTLS를 강제합니다. (최근 Istio ambient mode 등 운영 부담을 줄이기 위한 진화도 함께 참고할 만합니다.)
4) 정책/구성 드리프트를 막는 운영: GitOps + 관측(telemetry)이 “증명”입니다
망분리는 “분리되어 있다”를 비교적 단순하게 말할 수 있었지만, Zero Trust는 다릅니다. 정책이 맞게 적용되고 있고, 예외가 통제되고 있으며, 지속적으로 모니터링된다는 걸 증명해야 합니다.
- 정책은 코드로 관리하고(GitOps), 변경 이력과 승인 흐름을 남깁니다.
- 네트워크 흐름/인증 실패/권한 거부를 로그와 메트릭으로 수집해 “통제의 작동”을 보여줍니다.
- 금융당국이 요구하는 “대체 보안통제”는 결국 이런 증적 자동화 능력으로 귀결될 가능성이 큽니다.
(제가 보는) 과도기의 본질: “규정이 방패”였던 조직이 “방패를 직접 만드는” 시대로 갑니다
여기서부터는 기술보다 문화에 가깝습니다.
한국 금융 조직은 오랫동안 명확한 규정 준수에 최적화되어 효율을 냈습니다. 그런데 SaaS 허용 확대와 자율보안(결과책임)이 같이 오면, 더 이상 “정답(규정)”이 모든 상황을 커버하지 못합니다. 결국 팀마다 판단이 필요해지고, 의사결정을 못하는 팀은 멈추게 됩니다.
제가 대화에서 가장 중요하다고 본 지점은 D: 책임·권한 구조(RACI)의 부재였습니다.
- 지식 부족(A), 정량 프레임 부재(C)는 “프로라면 학습해서 채워야 하는 영역”이기도 합니다.
- 그런데 실패 페널티(B)는 많은 경우, 실제로는 **누가 결정권자인지 애매한 구조(D)**에서 더 커집니다.
- 따라서 “자율보안”을 현실로 만들려면, 기술 도입 이전에 최소한 이것부터 필요합니다.
- 서비스/제품 오너가 승인할 수 있는 리스크의 범위(리스크 버짓)
- 보안팀/플랫폼팀의 기준과 역할(기본 정책 제공 vs 예외 승인)
- 정해진 절차/증적을 지키면 개인 책임을 줄여주는 “운영 면책 조건”
통제 우선순위는 무엇부터 재정의해야 할까요?
열린 질문에 대한 제 결론은 이렇습니다. 가장 먼저 재정의해야 할 통제 우선순위는 ‘경계’가 아니라 ‘책임과 증명’입니다.
- 경계를 물리적으로 세울지(망분리), 정책으로 세울지(Zero Trust)는 선택의 문제일 수 있습니다.
- 하지만 SaaS 허용이 늘고 “너네가 알아서 해(자율보안/결과책임)”가 강화되면, 조직은 반드시
- 누가 승인하는가(권한)
- 무엇을 남겨야 하는가(증적)
- 사고 시 무엇으로 적정성을 설명할 것인가(관측/로그/평가)
를 먼저 정해야 합니다.
기술적으로는 NetworkPolicy/RBAC/mTLS/telemetry가 답에 가깝지만, 조직적으로는 “의사결정 구조와 증명 체계”가 먼저 깔려야 실제로 굴러갑니다.
마무리
금융 망분리 완화는 보안이 느슨해지는 이야기가 아니라, 보안을 ‘경계’에서 ‘정책+신원+관측’으로 다시 증명해야 하는 시대가 열리는 신호라고 봅니다. “망분리 위에 Kubernetes”를 유지하든, “Kubernetes 위에 Zero Trust”로 가든, 결국 살아남는 조직은 결정할 수 있는 구조와, 그 결정을 증명하는 운영 능력을 갖춘 곳일 겁니다.