«Кевин Митник показал не то, что замок можно сломать, а то, что охрана внутри замка доверяет всем, кто уже внутри. Это и есть корень. Наши современные облака и удалённые офисы лишь масштабировали его метод: один скомпрометированный аккаунт, один доверенный протокол, и ты не гость — ты резидент. Zero Trust не добавляет новые замки. Он меняет внутренние правила: внутри замка больше нет доверенных зон, каждое движение требует персонального разрешения.»
Кевин Митник: не взломщик систем, а исследователь доверия
Кевин Митник не вламывался в системы силой — он находил в них незаметные лазейки, созданные избыточным доверием. Его главным инструментом было понимание того, какие каналы связи считались внутренними и потому безопасными по умолчанию.
В середине 1990-х телекоммуникационные сети, включая X.25 и ранние сети сотовых операторов, строились на простом принципе: если у тебя есть правильные номера доступа или учётные данные, ты проходишь без дополнительных проверок. Митник не атаковал оборудование напрямую. Он звонил оператору, представляясь техническим сотрудником, получал временные данные для доступа и уже с их помощью подключался к критическим узлам для настройки переадресации или мониторинга.
Один из классических примеров — проникновение в Digital Equipment Corporation (DEC). Вместо перехвата трафика или взлома шифрования он сначала получил доступ к внутреннему серверу через доверенный терминал, выдав себя за сотрудника. На этом сервере он скопировал часть исходного кода операционной системы VMS. Последующий ручной анализ этого кода позволил выявить шаблоны в алгоритме генерации временных паролей для административных учёток. Эти пароли не были уязвимостью в классическом смысле — они генерировались по восстановимой логике. Это был не взлом, а системный обход, основанный на получении легитимного доступа и злоупотреблении внутренним доверием.
Расследование показало, что в большинстве случаев он не использовал технические уязвимости. Он получал легитимные учётные данные через телефонные звонки, подмену идентификаторов или использование доверенных терминалов. После этого система сама предоставляла ему возможности, а внутри периметра его действия никто не отслеживал. Не было повторных запросов аутентификации, сегментации по уровню данных или аудита нестандартного поведения. Получив статус «своего», он получал и полный контроль.
Успех Митника был основан не на техническом превосходстве, а на эксплуатации архитектурной слабости: в среде с неявным доверием даже базовых навыков социальной инженерии достаточно для получения контроля. Его подход был системным: он изучал протоколы, считавшиеся «внутренними», и использовал их как коридоры для перемещения. Проблема была не в прочности замков на воротах, а в том, что чёрный ход никогда не запирался.
Провал модели «замок и ров» перед лицом одного человека
Сетевые архитектуры конца 1980-х — 1990-х строились вокруг централизованных периметров. Защита концентрировалась на границе: межсетевые экраны, маршрутизаторы, выделенные линии. Всё, что было снаружи, считалось враждебным; всё внутри — доверенным. Эта модель работала, пока угроза оставалась за пределами крепости. Но как только злоумышленник оказывался внутри, он получал тот же уровень доверия, что и легитимный администратор с локального терминала.
Митник обходил периметр, устанавливая соединения изнутри через доверенные каналы. Например, он подключался через телефонные узлы, трафик которых не шёл через общие интернет-шлюзы и потому не контролировался системами безопасности, настроенными на фильтрацию IP-трафика. Для внутренних систем это выглядело как легитимное техническое соединение. Аутентификация часто была односторонней: правильный идентификатор вызывающей стороны гарантировал доступ.
Внутренняя сеть того времени могла иметь виртуальные LAN (VLAN) для разделения пользователей и серверов, но это не препятствовало латеральному перемещению. VLAN не блокировали трафик между сегментами на уровне приложений. Если на рабочей станции была учётная запись с правами доступа к серверу баз данных, и этот сервер был доступен в сети, маршрут существовал. Сегментация не проверяла контекст — только наличие IP-адреса и открытого порта.
В одной из атак, получив доступ к терминалу и учётке рядового сотрудника, Митник обнаружил, что эта учётка имеет права на сервере аутентификации инженерной группы. Это позволило ему запрашивать списки пользователей, изучать политики и искать записи с повышенными привилегиями. Не существовало механизмов, которые бы спросили, почему сотрудник отдела поддержки внезапно интересуется данными администраторов. Не было триггеров на аномальное поведение. Данные в состоянии покоя не шифровались, что позволяло беспрепятственно копировать файлы с файловых серверов.
Модель «замок и ров» предполагала, что битва происходит на границе. Но уже к 1995 году граница размылась через телефонные сети, доверенные соединения и удалённый доступ без должного контроля. Митник не перепрыгивал через ров — он проходил через внутренние двери, за которыми никого не было. Его не ловили, потому что внутри периметра не существовало механизма, способного заявить: «Ты не должен здесь находиться».
От теории к инцидентам: как практика сформировала Zero Trust
Спустя десятилетие после Митника индустрия столкнулась с тем же сценарием, но в несравнимо большем масштабе. Атака на сеть магазинов Target в 2013 году началась не с хакерской группировки, а со взлома учётной записи поставщика систем отопления и вентиляции. Через неё был получен доступ к внутренней сети ритейлера. Оттуда злоумышленники переместились с рабочей станции в бухгалтерии на серверы обработки платёжных карт. Никаких уязвимостей нулевого дня не использовалось. Всё ограничилось подбором пароля, подключением по VPN, сканированием сети, использованием легальных инструментов администрирования и выгрузкой данных. По сути, это был сценарий середины 90-х, воспроизведённый в современных условиях.
Другой пример — инцидент в Sony Pictures 2014 года. Атака началась с фишингового письма, скомпрометировавшего учётную запись сотрудника. Получив точку опоры внутри сети, злоумышленники свободно перемещались между серверами, эскалировали привилегии и месяцами выгружали конфиденциальные данные. Ни сегментация, ни системы контроля доступа не остановили это движение.
Концепция Zero Trust родилась именно из анализа подобных инцидентов, а не из академических теорий. Специалисты по безопасности, изучая логи и отчёты, видели чёткую закономерность: после первоначального проникновения злоумышленник двигается по внутренней сети практически беспрепятственно. Ключевой вывод был таков: если нельзя гарантировать, что противник не проник внутрь, нужно строить защиту в предположении, что он уже там.
Zero Trust, это не синоним «усиленной защиты». Это набор требований к каждому сетевому запросу, сеансу и субъекту: постоянно доказывать, кто ты, зачем обращаешься и почему имеешь на это право. Аутентификация перестаёт быть разовым событием при входе и становится непрерывным процессом. Даже подключение из корпоративной локальной сети не гарантирует доверия — каждый вызов к сервису проходит проверку. Все соединения шифруются, независимо от того, идут они по внутренним или внешним каналам.
Краеугольным камнем стал принцип наименьших привилегий. В устаревших системах одна скомпрометированная учётная запись могла открыть доступ к десяткам сервисов. Zero Trust требует явного, целенаправленного назначения прав. Никто не получает доступ «ко всему, что может понадобиться». Каждое действие должно быть обосновано, запрошено и разрешено на ограниченное время. Привилегированная сессия предоставляется только для конкретной задачи, жёстко логируется, ограничивается по времени и часто требует дополнительного подтверждения.
Этот подход — прямое следствие сотен расследований, где злоумышленник, начав с одной украденной учётки, достигал критических активов за два-три дня. Zero Trust не обещает полностью предотвратить проникновение. Он гарантирует, что даже в случае успеха злоумышленник не сможет свободно перемещаться и наносить ущ>рб. Каждый его шаг будет замедлен, проверен и ограничен.
Как Zero Trust остановил бы атаку по сценарию Митника
Представим, что в середине 90-х архитектура DEC была построена по принципам Zero Trust. Система могла бы остановить или кардинально усложнить каждый этап продвижения злоумышленника.
Шаг 1: Социальная инженерия и кража учётных данных
Допустим, Митник, выдав себя за сотрудника поддержки, получил логин и пароль. В условиях многофакторной аутентификации (MFA) его попытка входа с неизвестного IP-адреса, не входящего в доверенную корпоративную подсеть, вызвала бы запрос на подтверждение через второй канал (например, push-уведомление в мобильном приложении или код из токена). Отсутствие доступа к этому второму фактору заблокировало бы вход, даже при наличии правильного пароля.
Шаг 2: Первоначальный доступ и разведка внутри сети
Предположим, доступ был получен через уязвимый терминал без MFA. Микросегментация, реализуемая в Zero Trust на уровне рабочих нагрузок (а не просто VLAN), изолировала бы этот терминал. Попытки сканировать сеть, обращаться к файловым ша>рам или службам каталогов были бы автоматически заблокированы, если для них не существовало явно прописанной политики. Каждый запрос анализировался бы с учётом контекста: устройство, его состояние защищённости, местоположение, время и тип операции.
Шаг 3: Латеральное перемещение и эскалация привилегий
Обнаружив в системе файл с паролями привилегированных учёток, Митник попытался бы использовать их на другом сервере. Система управления привилегированным доступом (PAM) в концепции Zero Trust заблокировала бы такой вход. Административный доступ предоставлялся бы по принципу Just-in-Time: сотрудник запрашивает сессию, запрос утверждается, сессия стартует под полным аудитом и автоматически завершается по таймауту. Любая попытка использовать привилегированную учётку вне этого процесса была бы немедленно пресечена и зафиксирована как инцидент.
Шаг 4: Эксфильтрация данных
При попытке скопировать исходный код VMS на внешний носитель или FTP-сервер сработали бы механизмы защиты данных. Шифрование информации в состоянии покоя сделало бы украденные файлы бесполезными без ключей. Система предотвращения утечек данных (DLP), анализирующая исходящий трафик, распознала бы передачу большого объёма бинарных или зашифрованных данных как аномальную. Даже при передаче по доверенному каналу система проверила бы получателя, тип данных и соответствие поведенческому профилю пользователя, после чего могла бы заблокировать передачу и оповестить службу безопасности.
Ни один из этих барьеров по отдельности не является непреодолимым. Но их совокупность, выстроенная в логике Zero Trust, превращает простой путь в серию последовательных препятствий. Злоумышленнику приходится безошибочно проходить каждое из них, и с каждым шагом вероятность обнаружения или блокировки растёт.
Внедрение Zero Trust: с чего начать, если не с продукта
Обсуждение Zero Trust часто сводится к выбору конкретных решений: брокеров безопасного доступа (ZTNA), систем PAM или инструментов микросегментации. Однако начать следует не с технологий, а с ответов на фундаментальные вопросы об инфраструктуре и бизнес-процессах. Zero Trust, это в первую очередь модель управления доступом, основанная на оценке рисков.
Вопрос первый: что является критически важным активом? Защищать всё невозможно и неэффективно. Необходимо определить 5-7 систем, утечка или вывод из строя которых приведёт к катастрофическим последствиям для бизнеса. Это может быть база данных клиентов, биллинговая система, окружение для разработки ПО или промышленные контроллеры. Именно эти активы становятся первыми кандидатами для применения принципов Zero Trust — вокруг них создаётся «зона нулевого доверия», где проверяется каждое соединение.
Вопрос второй: кто и при каких условиях должен получать к ним доступ? Ответ «наши сотрудники» не подходит. Требуется детализация по ролям и сценариям: администраторы баз данных во время плановых работ, разработчики при тестировании определённого модуля, аудиторы по официальному запросу. Каждый сценарий трансформируется в политику доступа, основанную не на IP-адресах, а на атрибутах: тип и состояние устройства, способ аутентификации, время суток, сетевой контекст.
| Роль | Целевой актив | Разрешённые условия доступа | Запрещённые действия |
|---|---|---|---|
| Администратор БД | Серверы баз данных | С корпоративного ноутбука, через PAM-портал, с MFA, в рабочие часы | Прямой SSH/RDP, доступ с личного устройства, экспорт полных дампов без одобрения |
| Разработчик | Тестовый контур | С устройства, соответствующего политике безопасности, через ZTNA, к определённым namespace/папкам | Доступ к продакшен-серверам, изменение конфигурации инфраструктуры |
Вопрос третий: как проверять каждый запрос, не парализуя работу? Без автоматизации Zero Trust нежизнеспособен. Необходима интеграция систем идентификации (IAM), аутентификации, брокеров доступа и платформ анализа событий (SIEM). Контекстная проверка означает, что система оценивает не только «кто ты», но и «насколько твоё поведение сейчас соответствует норме». Аномалия (например, доступ к финансовой системе в 3 часа ночи с нового устройства) автоматически запускает сценарий ответа: запрос дополнительного подтверждения, временная блокировка или перевод сессии в режим усиленного аудита с уведомлением SOC.
Вопрос четвёртый: как сделать защиту незаметной для своих и непреодолимой для чужих? Это вопрос удобства пользователей. Если каждый шаг требует сложных подтверждений, сотрудники начнут искать обходные пути, сводя на нет все усилия. Решением становится адаптивная или непрерывная аутентификация. Если пользователь работает со своего обычного устройства в стандартное время и выполняет типовые операции, система сохраняет низкий уровень проверок. Но при попытке доступа к новому ресурсу, скачивания большого объёма данных или подключения из необычного места автоматически включаются дополнительные контроли.
Только после ответов на эти вопросы и построения целевой архитектуры наступает этап выбора и внедрения конкретных технологических решений: IAM, PAM, ZTNA, инструментов микросегментации и DLP. Этот процесс цикличен: внедрение, измерение эффективности, корректировка политик и масштабирование на новые активы.
«Один человек» сегодня: почему Zero Trust, это необходимость
Сегодня «один человек», это уже не обязательно физическое лицо. Чаще это автоматизированный скрипт или бот, запущенный из скомпрометированной учётной записи рядового сотрудника. Он использует легальные протоколы (HTTP, RDP, SMB) и подключается к внутренним сервисам как легитимный пользователь. Его цель — не атаковать фронтальные защиты, а использовать доверенные каналы связи: корпоративную почту, мессенджеры, облачные файлообменники. Он может оставаться незамеченным неделями, постепенно расширяя доступ.
Переход на удалённую и гибридную работу, использование личных устройств и облачных сервисов окончательно стёрли понятие сетевого периметра. Устройства не подключаются к сети — они становятся её частью, где бы ни находились. В такой модели проверка по IP- или MAC-адресу теряет смысл. Атакующий может начать движение из точки, которая физически дальше, но логически «ближе» к цели, чем сервер в корпоративном дата-центре.
Zero Trust, это ответ на новую реальность. Он не пытается восстановить старый замок, а признаёт, что угроза может быть где угодно. У злоумышленника может быть правильная учётка, устройство и даже токен. Но у него не должно быть возможности беспрепятственно перемещаться по инфраструктуре. Каждое его действие встречает проверку, каждое соединение изолируется, каждое отклонение от нормы анализируется.
Внедрение Zero Trust не искоренит фишинг и человеческие ошибки. Оно решает другую задачу: не допустить, чтобы одна ошибка превратилась в катастрофу. Скомпрометированный аккаунт упирается в барьер микросегментации, попытка эскалации привилегий требует одобрения в PAM, а эксфильтрация данных блокируется DLP. SOC получает сигналы на ранних этапах атаки, до достижения критических активов.
История Кевина Митника, это не рассказ о гениальном хакере. Это демонстрация системного изъяна, позволившего одному человеку действовать так, будто он вездесущ. Современные инструменты дают возможность не повторить эту ошибку. Zero Trust, это не про параноидальный страх. Это про оперативную готовность. Это архитектурная возможность остановить того самого «одного человека» — не на подступах к крепости, а в тот момент, когда он пытается превратить украденный ключ в абсолютный контроль.