Великий парадокс безопасности нашего времени

Представьте: ваша организация только что одобрила новый проект по обеспечению безопасности с нулевым доверием. Высшее руководство в восторге. Команда безопасности настроена осторожно оптимистично. Ваша команда разработчиков? Они готовы потратить следующие шесть месяцев на то, чтобы убедиться, что «лучшие практики безопасности» и «выполнение реальной работы» не всегда хорошо сочетаются. Вот неудобная правда, которую никто на корпоративных конференциях по безопасности не хочет признавать: [нулевое доверие теоретически может повысить производительность], но на практике многие реализации создают такие запутанные системы контроля доступа, что сотрудники тратят больше времени на борьбу с театральностью безопасности, чем на выпуск функций. Это как если бы вам дали ключи от особняка, только вот у каждой комнаты по двенадцать замков, требуется биометрическая аутентификация, форма одобрения уровня безопасности 5 и нотариально заверенное письмо от главы вашего отдела. Я не говорю, что концепция нулевого доверия в корне ошибочна. Я говорю, что разрыв между обещанной «безопасной удалённой работой» и реальностью «я не могу получить доступ к базе данных, необходимой для работы» — вот где большинство реализаций терпит неудачу.

Обещание против реальности

Позвольте мне прояснить кое-что: сама концепция нулевой доверия теоретически обоснована. Проверяйте всё. Ничему не доверяйте. Микросегментация. Непрерывный мониторинг. На бумаге это прекрасно. Это аналог идеально спроектированной инфраструктуры микросервисов — теоретически превосходной, но кошмаре в обслуживании на практике. Проблемы начинаются, когда организации рассматривают нулевое доверие как галочку в аудите соответствия, а не как тщательно интегрированную философию безопасности. Они не просто меняют политики безопасности; они коренным образом реструктурируют работу доступа, не учитывая сопутствующего ущерба для производительности.

Вот что обычно происходит: Традиционная модель периметра:

  • Быстро: вы внутри сети, у вас широкий доступ.
  • Просто: одно решение — находитесь ли вы в корпоративной сети или нет?
  • Продуктивно: разработчики быстро выпускают код.
  • Небезопасно: как только кто-то проникает через периметр, это цифровое эквивалент «Grand Theft Auto» внутри вашей сети. Неправильно реализованная модель нулевого доверия:
  • Глетчеровское медленное: каждая. Единственная. Доступная. Требует. Проверки.
  • Непостижимо сложное: правила доступа, накладываемые на правила доступа поверх правил доступа.
  • Разрушающее производительность: ваша команда тратит больше времени на устранение проблем с доступом, чем на выполнение реальной работы.
  • Теоретически безопасное: но никто не может сказать, работает ли это на самом деле, потому что инфраструктура журналирования сама по себе настолько сложна, что для её разбора требуется кандидатская степень.

Спираль смерти при реализации

Позвольте мне рассказать вам, что я видел в нескольких организациях, и, подозреваю, вы можете узнать части своего собственного опыта.

graph TD A["Руководство решает внедрить нулевое доверие"] --> B["Команда безопасности создаёт сложные политики доступа"] B --> C["Политики 'технически идеальны', но практически непригодны"] C --> D["Разработчики создают заявки: 'Почему я не могу получить доступ?'"] D --> E["Начинается медленный цикл разрешения заявок"] E --> F["Производительность разработчиков падает на 30-40%"] F --> G["Команды обходят средства безопасности"] G --> H["Распространение теневых IT и несанкционированных инструментов"] H --> I["Фактическое состояние безопасности УХУДШАЕТСЯ"] I --> J["Команда безопасности удваивает ограничения"] J --> C

Это не теоретическая ситуация. Одна организация в результатах поиска внедрила нулевое доверие настолько агрессивно, что [попытки несанкционированного доступа снизились на 60%, а попытки вымогательства были пресечены], что звучит замечательно, пока вы не поймёте, что легитимные сотрудники не могли получить доступ к тому, что им было нужно, поэтому они просто создавали обходные пути, которые система не могла обнаружить. Показатели выглядели хорошо; фактическая безопасность была театрализованной. Цикл порочен, потому что все оптимизируют не ту цель. Команда безопасности оптимизирует «отсутствие несанкционированного доступа», не учитывая, что когда вы делаете авторизованный доступ настолько болезненным, что производительность страдает на 40%, умные сотрудники найдут несанкционированные пути. Организация оптимизирует контрольные галочки вместо фактических результатов безопасности.

Где на самом деле рушится нулевое доверие

Проблема умножения аутентификации

[Нулевое доверие требует проверки для любого, кто пытается получить доступ к ресурсам]. Звучит разумно. Только когда у вас сорок семь различных систем, каждая со своими требованиями аутентификации, своими реализациями MFA и своими определениями «должным образом аутентифицирован». Я работал с командой, которой пришлось реализовать аутентификацию для:

  • Учётных записей AWS (4 штуки);
  • Локальной инфраструктуры;
  • SaaS-приложений;
  • Внутренних API;
  • Доступа через VPN;
  • Доступа к базам данных;
  • Среды разработки. Каждая требовала разные типы учётных данных. У каждой были разные политики тайм-аута сеанса. Каждая реализовала MFA по-разному. Команда потратила столько времени на управление учётными данными, что старший инженер подсчитал, что они фактически тратили 15% своего времени только на логистику аутентификации. Ирония? Фактический риск безопасности при управлении учётными данными увеличился, потому что люди начали записывать пароли (нарушая правило безопасности 101) и повторно использовать учётные данные в разных системах (нарушая правило безопасности 102).

Кошмар с рабочими процессами утверждения

[Доступ с минимальными привилегиями] означает, что пользователи получают минимально необходимый доступ. В теории идеально. На практике это означает, что каждый запрос на доступ становится мини-проектом:

  1. Разработчику нужен доступ к базе данных.
  2. Разработчик подаёт запрос на доступ.
  3. Запрос отправляется в команду безопасности.
  4. Команде безопасности требуется бизнес-обоснование.
  5. Бизнес-обоснование требует утверждения от менеджера.
  6. Менеджер может быть в другом часовом поясе.
  7. Тем временем у разработчика есть 47 других задач.
  8. К тому времени, когда доступ будет утверждён, спринт закончится.
  9. Разработчику нужна другая база данных.
  10. Повторите с шага 1. Я видел, как законную работу откладывали на недели из-за того, что рабочие процессы утверждения доступа были разработаны архитекторами безопасности, которые никогда не ждали завершения своих собственных утверждений.

Налог на непрерывный мониторинг

[Нулевое доверие требует непрерывного мониторинга и аналитики в реальном времени]. Каждый доступ, каждое действие, всё регистрируется и анализируется. Звучит безопасно. Но кто платит вычислительные издержки? Ваша инфраструктура. Кто платит издержки на соответствие? Ваши разработчики, которым теперь приходится ждать своих сборок, потому что сканирование безопасности потребляет 40% ресурсов CI/CD-пайплайна. Одна организация, о которой я знаю, отслеживала это: время сборки увеличилось вдвое после внедрения комплексного мониторинга с нулевым доверием. Они получили фантастические данные телеметрии безопасности. Они также получили команду, которая выпускает функции в два раза медленнее. Математика не работает в пользу успеха.

Режим соответствия устройств

[Нулевое доверие требует, чтобы каждый пользователь и устройство аутентифицировались перед доступом к ресурсам]. Это нормально, пока у вас нет:

  • Разработчиков, которые иногда работают из дома;
  • Разработчиков, которые работают из кафе;
  • Удалённых разработчиков в разных странах;
  • Контрактников;
  • Консультантов;
  • Того парня, который работает с лодки (не спрашивайте). Каждое устройство должно быть «соответствующим». Каким образом соответствовать? У разных организаций разные определения. Некоторые требуют зашифрованные диски (отлично, но дорого для контрактников с ограниченным бюджетом). Некоторые требуют определённых версий программного обеспечения. Некоторые требуют не устанавливать определённые инструменты, которые разработчикам на самом деле нужны для работы. Я наблюдал, как команда внедрила обязательную шифровку дисков на всех машинах разработки. Продуктивность упала. Разработчикам нужна была производительность. Они нашли обходные пути — некоторые технически разумные, некоторые технически проблемные. Положение безопасности не улучшилось; оно просто стало невидимым.

Взрыв сложности управления доступом

Вот где становится действительно интересно. Позвольте мне показать вам, как выглядят политики управления доступом, когда нулевое доверие реализуется без проверок здравомыслия. Представьте, что вы разработчик, которому нужно:

  1. Получить доступ к репозиториям Git для трёх разных проектов.
  2. Разворачивать в staging и production.
  3. Читать логи из нескольких сервисов.
  4. Запрашивать базы данных (только для чтения и для чтения и записи для разных целей).
  5. Получить доступ к управлению секретами.
  6. Запускать тесты в CI/CD.
  7. Разворачивать изменения инфраструктуры. В традиционной модели вы могли бы получить сертификат, который говорит «разработчик», и это в основном работает. В плохо реализованной модели нулевого доверия вам нужно:
  • Индивидуальный сервисный аккаунт для каждого доступа к репозиторию Git.
  • Отдельные учётные данные для развёртывания в staging и production.
  • Ролевой доступ, который различает между чтением логов только для чтения и чтением логов с экспортом.
  • Учётные данные для баз данных, которые меняются в зависимости от того, читаете ли вы из реплики или основной базы.
  • Доступ к секретам, который требует утверждения каждый раз (не кэшируется).
  • Учётные данные CI/CD с чрезвычайно ограниченным сроком действия.
  • Учётные данные для изменения инфраструктуры, требующие утверждения несколькими лицами. Площадь атаки фактически увеличивается, потому что теперь вместо управления одним набором учётных данных вы управляете сорока семью, что означает: