Никому не доверяй, всё проверяй
Это второй пост серии о безопасности для разработчиков. В первом мы разобрались, что пароль — лишь малая часть картины. Теперь поднимемся на уровень выше, к архитектуре мышления.
В обычной жизни доверие — добродетель. Мы доверяем коллегам, партнёрам, друзьям, и это упрощает жизнь. Но в цифровых системах чрезмерное доверие не упрощает жизнь, оно упрощает взлом.
Старая модель: замок и ров
Долгое время безопасность строилась по модели средневекового замка. Есть стена (межсетевой экран), есть ров (демилитаризованная зона), есть ворота (VPN). Всё снаружи враждебно. Всё внутри безопасно.
Модель работала десятилетиями. Прошёл через ворота, значит свой. Запрос из внутренней сети — можно доверять. Сервис в корпоративном дата-центре безопасен по определению. Пользователь аутентифицировался — дальше можно не проверять.
Просто, понятно, удобно. И безнадёжно устарело.
Почему периметр перестал работать
Граница между «внутри» и «снаружи» размывалась давно, но 2020 год её окончательно стёр. Достаточно посмотреть на современную инфраструктуру.
Облака. Данные и сервисы больше не живут в вашем дата-центре. Они разбросаны между AWS, Azure, Google Cloud и десятком SaaS-провайдеров. Где теперь проходит «периметр»?
Удалённая работа. Сотрудники подключаются из дома, из кафе, из коворкингов, из разных стран. Их устройства — не контролируемые корпоративные машины, а личные ноутбуки и телефоны.
Микросервисы. Вместо одного монолита сотни сервисов, которые постоянно общаются друг с другом. Каждое такое взаимодействие — потенциальная точка атаки.
API и интеграции. Ваша система связана с десятками внешних сервисов: платёжные системы, CRM, аналитика, мониторинг. У всех них есть доступ к вашим данным.
Автономные агенты. Новый слой сложности — системы, которые действуют от имени пользователей и сервисов без прямого человеческого контроля.
В этом мире идея «свои внутри, чужие снаружи» не просто устарела, она опасна.
Когда доверие становится уязвимостью
Давайте вспомним три громких инцидента, которые хорошо показывают, как именно чрезмерное доверие разрушает безопасность.
Доверие к подрядчику: Target, 2013
Розничный гигант Target потерял данные 40 миллионов банковских карт и персональную информацию 70 миллионов клиентов. Атакующие не ломали серверы Target напрямую. Они скомпрометировали Fazio Mechanical Services — небольшую компанию, обслуживавшую системы вентиляции в магазинах.
У Fazio был удалённый доступ к сети Target для мониторинга оборудования. Злоумышленники украли учётные данные подрядчика, вошли в сеть и двигались по ней практически без препятствий. Система доверяла всему, что приходило изнутри периметра.
Вот как описал инцидент Брайан Кребс, журналист-расследователь, первым сообщивший об этом взломе: подрядчик систем вентиляции стал точкой входа для одной из крупнейших утечек данных в истории розничной торговли.
Доверие к поставщику: SolarWinds, 2020
В декабре 2020 года стало известно о взломе SolarWinds. И это была одна из самых изощрённых атак в истории. Злоумышленники внедрили вредоносный код в обновления платформы Orion, которую SolarWinds поставляла тысячам организаций.
Среди жертв оказались Microsoft, Intel, Министерство финансов США, Министерство торговли, Министерство внутренней безопасности. Все они сами установили скомпрометированное обновление. Почему? Потому что доверяли поставщику. Обновление пришло по официальному каналу, было подписано настоящим сертификатом, прошло стандартные проверки.
Как отмечается в директиве CISA, атакующие использовали доверие к цепочке поставок как основной вектор проникновения.
Доверие к одному паролю: Colonial Pipeline, 2021
В мае 2021 года программа-вымогатель остановила крупнейший топливопровод на восточном побережье США. Colonial Pipeline транспортирует около 45 % всего топлива, потребляемого на востоке страны. Атака вызвала панику на заправках и чрезвычайное положение в нескольких штатах.
Как сообщило агентство Bloomberg, злоумышленники проникли через старый VPN-аккаунт, который больше не использовался, но не был отключён. Аккаунт не был защищён многофакторной аутентификацией. Пароль, вероятно, утёк из другого взлома и был переиспользован.
Один заброшенный аккаунт, один переиспользованный пароль, отсутствие дополнительных проверок, и критическая инфраструктура целой страны парализована.
Что объединяет эти случаи
Во всех трёх инцидентах атакующие эксплуатировали не технические уязвимости в привычном смысле, а архитектурное доверие. Системы были построены на предположении, что если запрос пришёл из «правильного» источника — от подрядчика, в официальном обновлении, VPN — ему можно верить. Это предположение оказалось ложным.
Откуда взялся принцип нулевого доверия
Термин Zero Trust придумал не маркетолог. Его ввёл в 2010 году Джон Киндерваг, аналитик исследовательской компании Forrester. Главную идею он сформулировал предельно просто:
Никогда не доверяй, всегда проверяй. Мы не доверяем ни одному пакету данных, независимо от того, откуда он пришёл.
Это был радикальный разрыв с традиционной моделью. Вместо «доверенных зон» — проверка каждого запроса, каждого соединения, каждого действия, независимо от источника.
В 2020 году NIST формализовал этот подход в SP 800-207, сделав его рекомендуемым стандартом для федеральных агентств. В 2021 году в США вышел указ, обязывающий федеральные ведомства переходить на модель нулевого доверия. Концепция перестала быть теоретической моделью и стала отраслевым стандартом.
Что это значит на практике
Нулевое доверие — не продукт, который можно купить, и не технология, которую внедряют за выходные. Это архитектурный принцип, который меняет способ проектирования систем. Вот его основные принципы.
Проверяйте каждый запрос. Неважно, пришёл он из внутренней сети или извне, от сервиса или от пользователя. Каждый запрос должен быть аутентифицирован и авторизован.
Применяйте принцип минимальных привилегий. Каждый пользователь, сервис, процесс имеет только те права, которые минимально необходимы для его задачи.
Считайте любой компонент потенциально скомпрометированным. Даже собственный сервер, даже сервис вашей команды, даже запрос от коллеги. Проектируйте так, чтобы компрометация одного элемента не вела к компрометации всего остального.
Проверяйте постоянно. Однократная аутентификация в начале сессии недостаточна. Контекст меняется: пользователь мог сменить сеть, устройство могло быть скомпрометировано, права могли быть отозваны.
Сегментируйте доступ. Вместо одной «внутренней сети» — изолированные сегменты. Проникновение в один не должно автоматически открывать доступ к остальным.
Шифруйте всё. Даже внутренний трафик. Старая модель предполагала, что внутри периметра шифрование не нужно. Нулевое доверие исходит из того, что внутренняя сеть может быть скомпрометирована.
Как это меняет архитектуру
Идентификация и аутентификация
В традиционной модели пользователь входит один раз и работает. При нулевом доверии каждый запрос несёт информацию об идентичности, и она проверяется.
Это касается не только людей. Сервисы тоже подтверждают свою идентичность при каждом взаимодействии. Взаимная аутентификация по сертификатам (mutual TLS), при которой обе стороны соединения предъявляют сертификаты, становится нормой для межсервисного взаимодействия.
Авторизация
Права доступа становятся гранулярными и контекстными. Не просто «пользователь X может читать данные», а «пользователь X может читать ресурс Y, если он на корпоративном устройстве, находится в определённой стране, и за последний час в его поведении не было аномалий».
Это требует перехода от простых ролевых моделей к более тонким, основанным на атрибутах и политиках.
Токены и сессии
Долгоживущие токены — удобство для пользователя и подарок для атакующего. Украденный токен злоумышленник может использовать неделями.
Нулевое доверие подталкивает к коротким токенам — минуты или часы, а не дни, которые регулярно обновляются. Это усложняет систему и требует продуманного механизма обновления. Зато украденный токен быстро становится бесполезным.
Межсервисное взаимодействие
В микросервисной архитектуре сервисы постоянно общаются друг с другом. В традиционной модели если сервис «внутри», значит, ему доверяют.
При нулевом доверии каждый сервис подтверждает свою идентичность при каждом запросе. Инструменты вроде Istio или Linkerd помогают автоматизировать это, добавляя взаимную аутентификацию и применение политик на уровне инфраструктуры.
Сегментация сети
Вместо одной плоской внутренней сети нужно организовать множество изолированных сегментов. Микросегментация, программно-определяемые сети, сетевой доступ с нулевым доверием вместо традиционных VPN.
Это нужно, чтобы проникновение в один сегмент не давало злоумышленнику доступ ко всей инфраструктуре.
Почему разработчику это даётся нелегко
Доверие удобно. Оно уменьшает количество проверок, упрощает код, ускоряет разработку. «Запрос от нашего сервиса, значит, можно не проверять права.» «Пользователь уже вошёл — можно не проверять токен на каждом обработчике.» «Внутренний API — можно не шифровать.»
Каждое такое допущение — экономия сейчас и потенциальная уязвимость потом.
Недоверие заставляет проектировать систему сложнее:
- добавлять проверку прав на каждом уровне, а не только на входе;
- проверять входные данные, даже если они пришли от «своих» сервисов;
- использовать короткоживущие токены вместо долгих сессий;
- журналировать и отслеживать внутренние взаимодействия, а не только внешние;
- проектировать так, чтобы отказ одного компонента не ломал всё.
Это больше работы. Это медленнее. Это требует думать о безопасности на этапе проектирования, а не добавлять её потом. Зато делает систему устойчивой к реальным атакам, а не только к теоретическим.
Не паранойя, а дисциплина
Когда впервые слышишь о нулевом доверии, легко решить, что это паранойя. Проверять каждый запрос? Не доверять собственным сервисам? Шифровать внутренний трафик?
Но Киндерваг объяснял это иначе:
Мы не говорим, что всё злонамеренно. Мы говорим, что не можем знать заранее, что заслуживает доверия, а что нет. Поэтому мы проверяем.
Это похоже на контраварийное вождение: вы не считаете, что все вокруг плохие водители, но всегда готовы к тому, что кто-то совершит ошибку.
Итого
Зрелая безопасность — это не высокая стена вокруг системы. Стены можно обойти, перелезть, подкопать. Подрядчик может получить доступ. Обновление может оказаться троянским конём. Забытый аккаунт может стать входной дверью.
Зрелая безопасность — это архитектура, которая исходит из предположения: любой компонент может быть скомпрометирован, любой запрос может быть вредоносным, любая точка входа может стать точкой атаки.
Раньше безопасность была похожа на охрану замка: впускаем своих, не впускаем чужих. Сегодня безопасность больше похожа на иммунную систему: постоянно проверяет, распознаёт аномалии, реагирует на угрозы, изолирует заражённые участки. Как иммунная система не может доверять клетке только потому, что та находится внутри организма, так и современная система не может доверять запросу только потому, что он пришёл из «внутренней» сети.
Недоверие — это не цинизм. Это профессионализм.
В предыдущем посте мы разобрали, почему пароль перестал быть главной темой безопасности. В следующем — поговорим о том, как дедлайны становятся главным союзником атакующих.