TL;DR. 1장에서 "위치는 더 이상 신뢰의 근거가 될 수 없다"는 걸 확인했다면, 2장은 그 다음 질문에 답한다. "그렇다면 무엇을 근거로 신뢰할 것인가?" 답은 하나의 정답이 아니라, 위험 모델 정의 → 인증 → 최소한의 권한 → 지속적인 재평가로 이어지는 하나의 파이프라인이다.

"매 순간을 증명하라"는 말은 멋지지만, 막상 실무에 들어가면 막막해진다. 누구를 상대로, 무엇을, 어디까지 증명해야 안전하다고 말할 수 있을까? 2장은 이 질문에 답하기 위한 뼈대를 다룬다. 신뢰도, 위험 모델, 인증, 권한, 그리고 이 모든 걸 나누어 관리하는 구조까지.

---

🎯 신뢰도라는 숫자는 어디서 오는가

제로 트러스트는 "아무것도 믿지 않는다"고 말하지만, 사실 시스템은 매 순간 크고 작은 신뢰 판단을 내려야 굴러간다. 요청을 허용할지 말지 결정하려면 결국 "이 주체를 얼마나 믿을 수 있는가"라는 값이 필요하고, 이 값을 만들어내는 과정 전체가 2장의 출발점이다.

📖 책이 짚는 핵심

네트워크 관리자가 모든 트래픽을 일일이 검토해서 신뢰 여부를 판단하는 방식은 애초에 규모가 커지면 성립할 수 없다. 대신 우리는 신뢰를 위임하는 방법을 택한다.

한 사람(혹은 하나의 중앙 기관)이 모든 접속 주체를 직접 검증하는 대신, 신뢰할 수 있는 제3자에게 검증 권한을 위임하고 그 결과를 믿는 구조. 이 발상이 2장 전체를 관통한다. 뒤에서 다룰 PKI, IAM Role, mTLS는 전부 이 "위임된 신뢰"를 실제로 구현하는 방법들이다.

---

⚠️ 위험 모델: 무엇을, 누구로부터 지킬 것인가

신뢰를 논하기 전에 먼저 정해야 하는 게 있다. "어디까지를 방어 범위로 볼 것인가." 이걸 정의하는 작업이 위험 모델(Threat Model)이다.

🧩 자주 사용하는 위험 모델

업계에는 위험을 체계적으로 분석하는 여러 표준 방법론이 존재한다.

🌐 제로 트러스트의 위험 모델

📖 책이 짚는 핵심

인터넷 위험 모델은 호스트 자체는 공격당하지 않았다고 전제한다. 대신 호스트 사이의 통신 채널은 완전히 공격자의 손에 넘어갔다고 가정한다. 공격자는 모든 데이터를 읽고, 삭제하고, 변경하고, 심지어 신뢰하는 호스트가 보낸 것처럼 위조할 수 있다.

이게 바로 암호 프로토콜 설계의 표준 전제, 이른바 최악을 가정하는 설계 원칙이다. "네트워크는 이미 적의 손에 있다"고 전제하고도 안전이 성립해야, 현실의 덜 나쁜 상황에서는 당연히 안전하다는 논리다.

제로 트러스트도 이 위험 모델을 그대로 물려받는다. 다만 한 가지는 분명히 선을 긋는다.

하이퍼바이저에 악성코드를 심어 메모리를 통째로 복사하는 수준의 공격까지는 제로 트러스트의 방어 대상이 아니다. 제로 트러스트가 다루는 건 네트워크를 통해 전달된 접근 요청을 인증하고 허가하는 것이다. 디스크 암호화 같은 호스트 자체의 보안은 별도의 정책으로 챙겨야 한다.

즉 제로 트러스트는 "호스트와 호스트 사이를 오가는 요청" 을 지키는 모델이지, 호스트 하드웨어 자체의 안전까지 보장하는 만능 열쇠는 아니다.

---

🔏 견고한 인증

접근 요청을 인증하고 허가하는 것이 제로 트러스트의 일이라면, 그 시작은 언제나 "이 요청을 보낸 게 정말 그 주체가 맞는가"를 확인하는 인증(Authentication) 이다.

TLS를 쓰는 가장 큰 이유도 여기 있다. 클라이언트가 통신하는 서버가 정말 원하는 자원이 맞는지 확인하기 위해서다. 하지만 여기엔 맹점이 있다.

📖 책이 짚는 핵심

일반적인 TLS는 서버만 인증하고 클라이언트는 익명으로 남는다. 서로가 서로를 검증해야 하는 제로 트러스트 관점에서는 이 구조 자체가 문제다.

이 구멍을 메우는 게 상호 인증 TLS(mTLS) 다. 서버뿐 아니라 클라이언트도 자신의 인증서를 제시해서 신원을 증명해야, 비로소 "서로가 서로를 검증한다"는 제로 트러스트 원칙에 부합하는 통신이 완성된다.

---

🪪 인증에 대한 신뢰: PKI라는 기반

인증서를 "믿는다"는 건 결국 그 인증서를 누가 보증했는가의 문제로 귀결된다. 이 보증 구조를 만드는 것이 PKI(공개키 기반구조)다.

🏛️ 인증 기관

📖 책이 짚는 핵심

PKI의 목표는 아무런 권한이 없는 주체가 신뢰할 수 있는 제3자를 경유해 상대방의 ID를 인증하도록 만드는 데 있다.

서로 한 번도 만난 적 없는 클라이언트와 서버는, 스스로는 서로를 검증할 근거가 없다. 하지만 둘 다 공통으로 신뢰하는 CA(인증 기관) 가 있다면, CA의 서명을 매개로 간접적인 신뢰가 성립한다. 이게 앞서 얘기한 "신뢰의 위임"이 실제로 구현된 방식이다.

🔑 제로 트러스트에 있어서 PKI의 중요성

모든 제로 트러스트 네트워크는 PKI를 사용해 네트워크 참여자의 ID를 증명한다. 즉, 제로 트러스트의 모든 절차는 PKI에서부터 시작한다고 말할 수 있다.

디지털 인증서로 ID를 인증할 수 있는 주체는 세 가지로 나뉜다.

이 세 층위를 각각 독립적으로 검증해야, "네트워크 안에 있으니 믿는다"가 아니라 "매 요청을 검증한다"는 제로 트러스트가 실질적으로 완성된다.

⚖️ 사설 PKI와 공개 PKI

🤷 아무것도 없는 것보다는 공개 PKI

📖 책이 짚는 핵심

이미 공개 PKI로 시스템을 구축한 상태라면 사설 PKI로 전환할 방법도 있다. 하지만 쉬운 길을 놔두고 멀리 돌아갈 필요가 있을지는 의문이다.

사설 CA를 직접 운영하는 건 세밀한 통제가 가능하다는 장점이 있지만, 그만큼 운영 부담과 리스크(CA 개인키가 뚫리면 발급된 모든 인증서가 한 번에 무력화)도 크다. 이미 잘 굴러가는 공개 PKI가 있다면, "이론적으로 더 낫다"는 이유만으로 전면 전환을 감행하는 건 신중해야 한다는 게 책의 태도다.

---

🪫 최소 권한의 원칙

인증으로 "누구인지"를 확인했다면, 다음 질문은 "그래서 뭘 할 수 있게 해줄 것인가"다.

📖 책이 짚는 핵심

최소 권한이 적용된 시스템에서는 반드시 필요할 때만 권한을 획득하고, 필요한 동안만 유지한다. 그리고 어떤 행동에 어떤 권한이 필요한지 사용자와 애플리케이션이 명확히 이해할 수 있어야 한다.

sudo가 관리자 권한을 쓸 때마다 암호를 다시 묻는 것도 같은 원리다. 평소엔 권한이 없다가, 민감한 작업을 하려는 그 순간에만 재인증을 거쳐 권한을 획득하게 만들면, 사람 개입 없이 몰래 권한을 남용하려는 악성 소프트웨어를 어느 정도 차단할 수 있다.

문제는 이 원칙이 애플리케이션에는 잘 지켜지지 않는다는 데 있다.

인간 사용자와 마찬가지로 애플리케이션도 최소한의 권한만 가지고 동작해야 한다. 하지만 실상은 애플리케이션이 네트워크상에서 굉장히 많은 권한을 가지고 있는 경우가 많다.

애플리케이션 하나가 필요 이상의 권한을 쥐고 있으면, 그 애플리케이션이 뚫리는 순간 공격자는 원래 목표보다 훨씬 넓은 범위로 수평 이동할 수 있게 된다. 그리고 이 권한 설계는 사용자·애플리케이션 따로가 아니라, 디바이스 상태까지 함께 묶어서 판단해야 진짜 안전해진다. 같은 사용자, 같은 권한이라도 관리되지 않는 개인 기기에서 접속했다면 위험도는 완전히 달라지기 때문이다.

물론 이 모든 조합을 정책으로 관리하는 일은 결코 쉽지 않다.

이들 정책을 정의하고 관리하는 작업이 여간 힘든 일이 아니기 때문에, 보안 정책을 변경하자는 요청은 강한 반대에 부딪히기 쉽다. 결과를 예상하기 쉽지 않기 때문이다.

---

🎫 동적 신뢰도: 공항 검색대처럼

신용점수와 헷갈리기 쉽지만, 제로 트러스트의 신뢰 평가는 누적된 과거를 이월시키지 않는다는 점에서 결이 다르다.

더 정확한 비유는 공항 보안 검색대다. 어제 통과했다는 사실이 오늘의 통과를 보장해주지 않는다. 게이트를 지날 때마다, 그 순간의 상태를 처음부터 다시 확인한다. 이게 바로 "동적 신뢰도"의 핵심이다. 신뢰는 저장되는 자산이 아니라, 매 순간 새로 증명해야 하는 상태값이다.

---

🛣️ 컨트롤 플레인 vs. 데이터 플레인

이 모든 판단(인증, 인가, 정책)은 실제 트래픽이 오가는 것과는 별개의 "판단 계층"에서 이루어져야 한다.

📖 책이 짚는 핵심

데이터 플레인은 애플리케이션, 방화벽, 프록시, 라우터로 구성되며 네트워크상의 모든 트래픽을 처리한다. 트래픽 허용 여부를 가능한 빨리 결정하는 게 데이터 플레인의 일이다. 반면 컨트롤 플레인은 그 규칙 자체를 정의하고 관리한다.

이 둘을 반드시 분리해야 하는 이유는 최소 권한 원칙과 정확히 같은 논리다.

데이터 플레인에서 동작하는 서비스가 컨트롤 플레인의 권한을 가져서는 안 된다. 네트워크에 침입한 공격자가 수평적 이동을 할 수 있는 창구가 되기 때문이다.

넓은 접근 권한을 가진 데이터 플레인이 동시에 정책 자체를 바꿀 수 있는 권한까지 쥐고 있다면, 뚫렸을 때의 피해는 걷잡을 수 없이 커진다.

---

🏁 마치며: 신뢰는 설계해야 만들어진다

한 줄 요약 신뢰는 저절로 주어지지 않는다. 위험 범위를 정의하고, 인증으로 신원을 증명하고, 최소한의 권한만 부여하고, 그 판단을 매 순간 반복하는 파이프라인을 설계해야 비로소 신뢰가 만들어진다.

1장이 "왜 위치는 더 이상 신뢰의 근거가 될 수 없는가"를 다뤘다면, 2장은 그 자리를 대신할 신뢰를 어떻게 만들고 지속시킬 것인가에 대한 답이었다.

먼저 위험 모델로 "어디까지를 지킬 것인가"라는 방어 범위를 정하고, 그 위에서 PKI로 디바이스·사용자·애플리케이션의 신원을 증명한다. 신원이 증명됐다고 끝이 아니라, 최소 권한 원칙으로 그 신원이 실제로 무엇을 할 수 있는지를 필요한 만큼만 열어주고, 컨트롤 플레인과 데이터 플레인을 분리해 트래픽을 처리하는 쪽이 정책 자체를 건드리지 못하게 막는다. 그리고 이 모든 판단은 한 번 내려졌다고 유지되는 게 아니라, 공항 검색대처럼 매 순간 다시 이루어져야 한다.

결국 2장을 관통하는 건 하나의 문장으로 요약된다. 신뢰는 주어지는 게 아니라, 매 순간 다시 증명되어야 유지되는 상태값이다.