지갑을 잃어버렸다고 전 재산을 잃으면 너무 아쉽지 않습니까. 핸드폰 하나 잃어버려서 직장을 잃고, 노트북 하나 도난당해서 십수 년 일군 회사가 통째로 날아간다면, 그것은 보안의 실패가 아니라 설계의 실패입니다.
들어가며: 신뢰는 취약점이다
이 책은 6장에서 Zero Trust를 다뤘고, 여러 장에서 그 정신을 반복했습니다. 이 마지막 보너스 장은 Zero Trust를 다시, 그러나 더 넓고 더 일상적인 차원에서 다룹니다. 서버 설정의 기법으로서가 아니라, 삶 전체에 적용되는 사고방식으로서 말입니다.
Zero Trust의 한 문장은 이것입니다. 아무도 믿지 마라. 그러나 이 말의 진짜 무게는, 그 "아무도"에 누가 포함되는지를 깨달을 때 드러납니다. 외부의 공격자만이 아닙니다. 같은 네트워크의 낯선 사람만이 아닙니다(보너스 1). 옆자리의 동료도(14장의 내부자), 오래 거래한 협력사도(14장의 서드파티), 그리고 — 가장 받아들이기 어렵게도 — 나 자신도 포함됩니다.
왜 나 자신을 믿지 말아야 할까요? 내가 악의를 품어서가 아닙니다. 내가 실수할 수 있고, 내가 가진 것을 잃을 수 있기 때문입니다. 나는 핸드폰을 잃어버릴 수 있고, 노트북을 도난당할 수 있고, 피싱에 속을 수 있고, 실수로 잘못된 버튼을 누를 수 있습니다. 이 모든 것은 일상적으로 일어나는 평범한 일입니다. Zero Trust는 묻습니다. 그 평범한 일이 일어났을 때, 당신의 모든 것이 무너지는가? 만약 그렇다면, 그것은 보안의 문제가 아니라 설계의 문제입니다.
이 장에서는 Zero Trust를 이 넓은 의미로 전개합니다. 왜 신뢰가 취약점인지, 왜 나 자신조차 믿어서는 안 되는지, 그리고 일상의 평범한 사고가 치명적 재앙이 되지 않도록 어떻게 설계할 것인지를 다룹니다. 그 핵심에 두 가지 실천이 있습니다. 모든 권한은 그것을 보유해야만 하는 사람에게 하나씩 주어지고, 반드시 둘 이상의 채널로 검증되어야 한다는 것입니다.
I.1 Zero Trust의 본질: 위치도 관계도 신뢰의 근거가 아니다
먼저 Zero Trust의 본질을 다시 정리합니다. 6장에서 다룬 것을 더 깊이 들여다봅니다.
전통적 신뢰 모델의 붕괴
전통적인 보안은 신뢰의 경계를 그었습니다. 경계 안쪽은 신뢰하고, 바깥쪽은 신뢰하지 않는 방식입니다. 사무실 네트워크 안이면 신뢰하고, 로그인한 사용자면 신뢰하고, 오래 거래한 상대면 신뢰했습니다.
이 모델의 치명적 약점은, 경계가 한 번 뚫리면 그 안의 모든 것이 노출된다는 것입니다(2장의 측면 이동, 보너스 1의 같은 네트워크 위협). 신뢰받는 위치에 한 번 들어서기만 하면, 그 신뢰가 부여하는 모든 것에 접근할 수 있습니다. 공격자가 노리는 것이 바로 이 "신뢰의 경계 안으로 들어서기"입니다.
Zero Trust의 발상
Zero Trust는 이 경계 자체를 부정합니다. 신뢰의 근거가 되는 것은 위치도, 관계도, 과거의 검증도 아닙니다. 모든 접근은, 그때그때, 그 접근이 정당한지를 검증받아야 합니다. "당신은 안쪽에 있으니 통과"가 아니라 "당신이 누구이며 이 접근이 허용되는지 지금 확인하겠다"입니다.
이것을 한 문장으로 하면, 신뢰 자체가 취약점이라는 것입니다. 무언가를 신뢰한다는 것은, 그것이 배신당했을 때 무방비가 된다는 뜻입니다. 신뢰하는 대상이 침해되거나, 실수하거나, 잃어버려지면, 그 신뢰만큼의 피해가 발생합니다. 그래서 Zero Trust는 신뢰를 최소화합니다. 검증할 수 있는 것은 검증하고, 신뢰해야만 하는 것은 최소한으로 줄입니다.
이것이 추상적으로만 들린다면, 6장에서 이미 손으로 만져 본 적이 있다는 것을 기억하십시오. 거기서 SSH 22번 포트를 인터넷에서 통째로 없애고, "사무실 안이니까" 같은 위치 기반 통과를 버린 뒤, 접속할 때마다 신원으로 검증하게 만든 것이 바로 Zero Trust의 서버판 구현이었습니다. 그 토대가 된 Cloudflare Zero Trust(Cloudflare One) — 네트워크 안쪽에 있다는 사실이 아니라, 그때그때의 신원과 정책으로 접근을 허용하는 방식 — 가 이 장에서 말하는 "위치는 신뢰의 근거가 아니다"를 그대로 제품으로 만든 것입니다. 이 장은 그 발상을 서버 밖으로, 삶 전체로 넓힙니다.
옆자리의 동료도, 협력사도
이 사고를 사람과 관계로 확장하면 불편한 결론에 이릅니다. 옆자리의 동료도 신뢰의 근거가 아닙니다(14장의 내부자). 오래 거래한 협력사도 마찬가지입니다(14장의 서드파티, 보너스 2의 거래 가로채기). 그들이 나쁜 사람이어서가 아니라, 그들이 침해되거나 실수할 수 있기 때문입니다. 그들의 계정이 탈취되면, 그들에 대한 나의 신뢰가 공격자의 통로가 됩니다.
그래서 Zero Trust는 관계에서도 검증을 요구합니다. 보너스 2에서 강조한 대역 외 확인이 바로 이것입니다. 거래 상대로부터 온 것처럼 보이는 송금 요청도, 그 관계를 신뢰하여 바로 따르지 않고, 독립된 채널로 검증하는 것입니다. 신뢰가 아니라 검증입니다.
I.2 나 자신도 믿지 마라: 가장 어려운 적용
이제 Zero Trust의 가장 어렵고 가장 중요한 적용에 도달합니다. 나 자신을 믿지 않는 것입니다.
나는 완벽하지 않다
나 자신을 믿지 말라는 것은, 자기 비하가 아니라 현실 인식입니다. 나는 다음과 같은 존재입니다.
나는 실수합니다. 잘못된 버튼을 누르고, 중요한 것을 잘못 설정하고(6장에서 자기 자신을 서버에서 잠그는 사고를 떠올리십시오), 부주의로 무언가를 노출합니다.
나는 속을 수 있습니다. 아무리 보안에 밝아도, 충분히 정교한 피싱 앞에서는 누구나 속을 수 있습니다(3장에서 AI가 "어색함을 알아채라"는 방어를 무너뜨렸음을 보았습니다). "나는 안 속는다"는 확신이 오히려 위험합니다.
나는 잃어버립니다. 핸드폰을 잃어버리고, 노트북을 도난당하고, 기기를 분실합니다(14장의 물리적 위협). 이것은 일어날 수도 있는 일에 그치지 않고, 살다 보면 결국 일어나는 일입니다.
Zero Trust가 나 자신을 믿지 말라는 것은, 이 모든 평범한 사고를 일어날 일로 가정하라는 것입니다(원칙 2, 침해를 가정하라). 그리고 그것이 일어났을 때 무엇이 무너지는지를 미리 따져 보라는 것입니다.
내가 십수 년 서버를 만지며 가장 자주 본 사고는, 외부의 정교한 공격이 아니라 바로 이 평범한 쪽이었습니다. 잠금 설정을 한 줄 잘못 넣어 자기 자신이 SSH에서 튕겨 나가고, 노트북을 분실하고, 한밤중에 "급한 송금"이라는 메시지에 손이 먼저 움직이는 — 그런 일들. "나는 안 그런다"고 자신하던 사람일수록 더 크게 당하는 것도 여러 번 봤습니다. 그러니 출발점은 자신을 믿는 것이 아니라, 자신이 그럴 수 있다고 인정하고 설계로 떠받치는 것입니다.
일상의 사고가 재앙이 되지 않게
여기 이 장의 핵심 질문이 있습니다. 일상적으로 발생할 수 있는 평범한 사고가, 치명적인 재앙이 되는가?
지갑을 잃어버리는 것은 일상적인 사고입니다. 그런데 만약 지갑 하나를 잃어버려서 전 재산을 잃는다면, 그것은 끔찍합니다. 다행히 현실의 금융 시스템은 그렇게 설계되어 있지 않습니다. 지갑을 잃어도, 카드를 정지하고, 신분증을 재발급받으면, 전 재산을 잃지는 않습니다. 손실이 제한되도록 설계되어 있습니다.
그런데 디지털 보안에서는, 이 당연한 설계가 종종 빠져 있습니다. 핸드폰 하나를 잃어버려서 직장을 잃을 수 있고, 노트북 하나를 도난당해서 십수 년 일군 회사가 통째로 날아갈 수 있습니다. 그 하나의 기기에 모든 접근 권한이 들어 있고, 그것을 잃는 순간 모든 것이 넘어가도록 설계되어 있기 때문입니다.
Zero Trust는 이것을 설계의 실패로 봅니다. 핸드폰을 잃어버리는 것은 막을 수 없습니다 — 그것은 일상입니다. 그러나 핸드폰을 잃어버려도 직장과 회사가 무사하도록 설계할 수는 있습니다. 막아야 할 것은 사고의 발생이 아니라, 사고가 재앙으로 번지는 것입니다. 지갑을 잃어도 전 재산이 무사하듯, 기기를 잃어도 핵심이 무사하도록.
침해를 가정한 설계의 일상화
이것은 본문의 원칙 2(침해를 가정하라)와 13장(백업), 14장(저장 장치 암호화, 분실 대비)을 일상의 차원으로 끌어온 것입니다.
기기를 잃을 것을 가정하면, 저장 장치를 암호화하게 됩니다(14장) — 잃어버려도 안의 데이터를 읽을 수 없게. 분실 시 원격으로 잠그고 지울 수 있게 준비하게 됩니다(14장). 그 기기 하나에 모든 권한을 몰아넣지 않게 됩니다. 그리고 무엇보다, 다음 두 절에서 다룰 두 가지 — 권한의 분산과 다채널 검증 — 를 갖추게 됩니다. 이것들이 함께 작동하여, 하나의 기기나 하나의 자격 증명을 잃어도 전체가 무너지지 않는 구조를 만듭니다.
I.3 첫 번째 실천: 권한은 필요한 사람에게 하나씩
일상의 사고가 재앙이 되지 않게 하는 첫 번째 실천은, 권한의 설계입니다. 이 책에서 반복한 최소 권한 원칙을, Zero Trust의 관점에서 다시 봅니다.
모든 권한은 하나씩, 필요한 사람에게
원칙은 이렇습니다. 모든 계정과 권한은, 그 권한을 보유해야만 하는 사람에게, 하나씩 주어져야 합니다.
이 짧은 문장에 세 가지가 담겨 있습니다.
"보유해야만 하는 사람에게" — 최소 권한 원칙입니다(7장, 11장, 14장). 권한은 그것이 꼭 필요한 사람에게만 부여됩니다. 필요하지 않은 사람은 갖지 않습니다. 그러면 한 사람이 침해되거나 실수해도, 그가 가진 권한 범위로만 피해가 제한됩니다.
"하나씩" — 권한과 계정이 사람별로, 개별적으로 분리되어야 한다는 것입니다(7장에서 SSH 키를 사람·기기별로 분리하라고 한 것). 여럿이 하나의 계정을 공유하면, 누가 무엇을 했는지 추적할 수 없고(13장의 책임 추적), 한 사람의 유출이 모두의 유출이 되며, 한 사람만 폐기하는 것이 불가능합니다. 권한이 하나씩 분리되어 있어야, 문제가 생긴 하나만 깔끔하게 폐기할 수 있습니다(14장의 적시 회수).
"모든" — 예외 없이 적용되어야 한다는 것입니다. 편의를 위해 만든 공유 계정, 임시로 부여한 과도한 권한, 폐기를 잊은 옛 접근 — 이런 예외들이 약한 고리가 됩니다(5장의 그림자 자산).
왜 이것이 Zero Trust인가
이 권한 설계가 Zero Trust인 이유는, 그것이 신뢰를 최소화하기 때문입니다. 누구에게도 필요 이상을 신뢰하여 맡기지 않고, 각자에게 꼭 필요한 만큼만, 개별적으로 부여합니다. 그러면 어느 하나가 배신되거나 침해되거나 분실되어도 — 그 하나의 권한만큼만 위험이 발생하고, 그것만 회수하면 됩니다. 전체가 무너지지 않습니다.
이것이 I.2에서 말한 "기기를 잃어도 회사가 무사한" 구조의 토대입니다. 권한이 한 곳에 집중되어 있지 않고 분산되어 있으면, 하나를 잃어도 그것만 잃습니다. 모든 것을 잃지 않습니다.
I.4 두 번째 실천: 반드시 둘 이상의 채널로 검증하라
두 번째 실천은 검증의 설계입니다. 이것은 이 책 전체에서 여러 이름으로 등장한 원리의 종합입니다.
하나의 채널은 단일 실패점이다
핵심 원칙은 이것입니다. 중요한 것은 반드시 둘 이상의 독립된 채널로 검증되어야 합니다.
왜일까요? 하나의 채널에만 의존하면, 그 하나가 뚫리거나 잃어버려질 때 전부가 무너지기 때문입니다. 하나의 채널은 단일 실패점(single point of failure)입니다. Zero Trust는 단일 실패점을 허용하지 않습니다.
이 원리는 이 책 곳곳에서 다른 이름으로 나타났습니다.
- 2채널 인증(보너스 3, 본문 3·7·14장) — 비밀번호 하나가 아니라, 비밀번호와 두 번째 요소. 비밀번호가 유출되어도 두 번째 채널이 막습니다.
- 대역 외 확인(보너스 2, 본문 3·14장) — 이메일 하나가 아니라, 이메일과 독립된 전화. 한 채널이 장악되어도 다른 채널로 검증합니다.
- IP 화이트리스트 + 자격 증명(보너스 3) — API 키 하나가 아니라, 키와 허용된 출처. 키가 유출되어도 출처 제한이 막습니다.
- 깊이 방어(원칙 3, 책 전체) — 하나의 방어선이 아니라, 여러 겹. 한 겹이 뚫려도 다음 겹이 막습니다.
이 모든 것이 같은 원리의 다른 적용입니다. 하나에 의존하지 말고, 둘 이상의 독립된 것으로 검증하라. 그러면 어느 하나가 실패해도 전체가 실패하지 않습니다.
"독립된"의 중요성
여기서 "독립된"이라는 말이 중요합니다. 두 채널이 같은 것에 의존하면, 그것은 사실 하나의 채널입니다. 예를 들어 비밀번호와 두 번째 요소가 모두 같은 기기에 있다면, 그 기기를 잃으면 둘 다 잃습니다 — 진정한 두 채널이 아닙니다. 두 채널은 서로 독립적이어서, 하나가 침해되어도 다른 하나는 영향받지 않아야 합니다. I.2에서 "나 자신도 믿지 말라"고 했을 때, 기기 하나에 모든 것을 몰아넣지 말라는 것이 이 맥락입니다.
검증의 일상화
이 다채널 검증을 일상의 습관으로 만드는 것이 Zero Trust의 실천입니다. 중요한 계정에는 2채널 인증을 켜고(보너스 3), 중요한 거래는 대역 외로 확인하고(보너스 2), 중요한 시스템 연결은 여러 겹으로 보호하고(보너스 3의 IP 화이트리스트), 중요한 행동에는 하나가 아닌 둘 이상의 확인을 거치는 것입니다. 번거로워 보이지만, 이 번거로움이 바로 단일 실패점을 없애는 방어입니다. 그리고 정말 중요한 것에만 적용하면, 그 번거로움은 감당할 만합니다.
그래서 지금 뭘 하면 되나 — 오늘 30분으로 끝낼 수 있는 것. 거창한 재설계가 아니라, 가장 중요한 몇 개부터 두 채널로 만드는 것이 시작입니다. (1) 비밀번호가 하나라도 이미 유출됐는지 Have I Been Pwned에서 이메일로 조회해 보십시오 — "내 것은 안전하다"는 가정이 깨지는 순간, 두 번째 채널의 필요가 피부로 와닿습니다. (2) 이메일·도메인·결제·서버 콘솔처럼 잃으면 치명적인 계정부터 2채널 인증(2FA/MFA)을 켜십시오. 문자(SMS)보다 Bitwarden이나 1Password 같은 도구의 인증 앱이나 패스키를 권합니다(SMS는 번호 탈취에 약합니다 — 보너스 3). (3) 단, 그 두 번째 요소를 비밀번호가 든 같은 기기·같은 앱에 함께 두지 마십시오. 그러면 기기 하나를 잃을 때 둘 다 잃어, 사실상 한 채널이 됩니다(바로 위 "독립된"의 함정). 복구 코드는 따로 출력해 오프라인에 보관하십시오.
I.5 Zero Trust로 사는 법: 종합
이제 이 모든 것을 종합합니다. Zero Trust를 일상으로 사는 것은, 다음과 같은 사고와 습관을 갖는 것입니다.
사고방식
신뢰를 최소화하라. 위치도, 관계도, 과거의 검증도 신뢰의 근거로 삼지 마라. 신뢰해야만 하는 것을 최소한으로 줄이고, 검증할 수 있는 것은 검증하라.
나 자신도 믿지 마라. 나는 실수하고, 속고, 잃어버린다. 그것을 일어날 일로 가정하라. "나는 안 그런다"는 확신이 가장 위험하다.
사고가 아니라 재앙을 막아라. 평범한 사고(분실, 실수, 피싱)는 막을 수 없다. 그러나 그것이 재앙으로 번지지 않게 설계할 수는 있다. 지갑을 잃어도 전 재산이 무사하듯.
두 가지 핵심 실천
권한은 필요한 사람에게 하나씩. 모든 계정과 권한은, 보유해야만 하는 사람에게, 개별적으로, 최소한으로 주어진다. 그러면 하나가 침해·분실되어도 그것만 잃는다.
반드시 둘 이상의 독립된 채널로 검증하라. 하나에 의존하지 마라. 2채널 인증, 대역 외 확인, IP 화이트리스트, 깊이 방어 — 모두 같은 원리다. 하나가 실패해도 다른 하나가 막는다.
이것이 왜 이 책의 결론과 맞닿는가
이 두 실천은, 사실 이 책 전체가 말해 온 것의 종합입니다. 첫 번째 실천(권한 분산)은 공격면 축소(원칙 1)와 최소 권한의 종합이고, 두 번째 실천(다채널 검증)은 침해 가정(원칙 2)과 깊이 방어(원칙 3)의 종합입니다. 그리고 이 모든 것은 "검증 없는 신뢰는 위험하다"(원칙 4)는 정신 위에 서 있습니다.
Zero Trust는 단지 하나의 기술이 아니라, 이 책 전체를 관통하는 사고방식입니다. 아무도 믿지 않되 — 나 자신조차 믿지 않되 — 그것을 불신과 마비가 아니라, 검증과 분산이라는 구체적 설계로 만드는 것. 그것이 일상의 평범한 사고로부터 당신의 가장 중요한 것을 지키는 길입니다.
I.6 이 장이 남기는 교훈
이 보너스 장에서 확인한 것을 압축합니다.
첫째, 신뢰 자체가 취약점입니다. 무언가를 신뢰한다는 것은, 그것이 배신·침해·분실될 때 무방비가 된다는 뜻입니다. Zero Trust는 신뢰를 최소화하고 검증으로 대체합니다.
둘째, "아무도"에는 나 자신도 포함됩니다. 외부 공격자도, 옆자리 동료도, 협력사도, 그리고 나 자신도. 내가 악해서가 아니라, 내가 실수하고 속고 잃어버릴 수 있기 때문입니다.
셋째, 막아야 할 것은 사고가 아니라 재앙입니다. 분실·실수·피싱은 일상이며 막을 수 없습니다. 그러나 그것이 재앙으로 번지지 않게 설계할 수는 있습니다. 핸드폰을 잃어도 직장이, 노트북을 잃어도 회사가 무사하도록.
넷째, 권한은 필요한 사람에게 하나씩 주어져야 합니다. 보유해야만 하는 사람에게, 개별적으로, 최소한으로. 그러면 하나가 침해·분실되어도 그것만 잃고, 그것만 회수하면 됩니다.
다섯째, 반드시 둘 이상의 독립된 채널로 검증해야 합니다. 하나의 채널은 단일 실패점입니다. 2채널 인증, 대역 외 확인, IP 화이트리스트, 깊이 방어 — 모두 같은 원리입니다. 하나가 실패해도 다른 하나가 막습니다.
여섯째, Zero Trust는 이 책 전체의 종합입니다. 권한 분산은 공격면 축소와 최소 권한의 종합이고, 다채널 검증은 침해 가정과 깊이 방어의 종합입니다. 불신과 마비가 아니라, 검증과 분산이라는 설계로 — 일상의 사고로부터 가장 중요한 것을 지키는 것입니다.
이 장의 실행 항목
- 신뢰를 최소화하고 검증으로 대체하십시오. 위치·관계·과거 검증을 신뢰의 근거로 삼지 마십시오. (I.1)
- 나 자신도 믿지 마십시오. 실수·피싱·분실을 일어날 일로 가정하고 대비하십시오. (I.2)
- 사고가 재앙이 되지 않게 설계하십시오. 기기 하나에 모든 권한을 몰아넣지 마십시오. 저장 장치 암호화와 분실 대비를 갖추십시오. (I.2, 14장)
- 모든 권한을 필요한 사람에게 하나씩 부여하십시오. 최소한으로, 개별적으로. 공유 계정과 과도한 권한을 없애십시오. (I.3)
- 권한을 잃거나 문제가 생기면 그것만 깔끔하게 폐기하십시오. 사람·기기별 분리가 이를 가능하게 합니다. (I.3, 7·14장)
- 중요한 것은 반드시 둘 이상의 독립된 채널로 검증하십시오. 2채널 인증, 대역 외 확인, IP 화이트리스트, 깊이 방어. (I.4)
- 두 채널이 진정으로 독립적인지 확인하십시오. 같은 기기·같은 것에 의존하면 사실상 하나입니다. (I.4)
관련 장: 6장(Zero Trust 기초), 7장(최소 권한·키 분리), 13장(백업·침해 가정), 14장(내부자·물리·서드파티·권한 회수), 보너스 1(같은 네트워크), 보너스 2(대역 외 확인), 보너스 3(2채널·IP 화이트리스트).
이것으로 네 개의 보너스 장(부록 F~I)을 모두 마칩니다. 네트워크, 이메일, 비밀번호, 그리고 Zero Trust — 본문의 원칙들이 일상의 가장 구체적인 위협으로 어떻게 적용되는지를 보았습니다. 본문 1~15장, 부록 A~E, 그리고 이 보너스 F~I를 함께 활용하여, 안전한 길을 지속적으로 걸어가시기 바랍니다.