Зачем каждому инженеру фундамент безопасности

Безопасность — это образ мышления, а не фича

Самое дорогое заблуждение, которое компетентный инженер приносит в безопасность, — будто это слой: тут WAF, там сканер, галочка в пайплайне деплоя. Это не так. Безопасность — это враждебный склад ума, который ты применяешь ко всему, что проектируешь. Функциональный инженер спрашивает: «работает ли это при корректном использовании?» Security-компетентный инженер дополнительно спрашивает: «а что будет, если кто-то использует это некорректно нарочно?» Этот единственный дополнительный вопрос и есть разница между кодом, который проходит ревью, и кодом, который выживает при контакте с интернетом.

Адам Шостак, годами руливший моделированием угроз в Microsoft, свёл всю дисциплину к четырём вопросам, которые масштабируются от наброска на доске до мультирегиональной платформы:

1. Что мы строим? Нарисуй систему. Где данные входят, где пересекают границу доверия (браузер → сервер, сервис → база, твой код → сторонний API) и где выходят?
2. Что может пойти не так? Для каждого компонента и каждой границы перечисли, как атакующий мог бы этим злоупотребить. Ресайзер, забирающий выбранный атакующим URL, — это «что может пойти не так», которое делает видимым шаг «что мы строим».
3. Что мы с этим будем делать? Выбери меры защиты — и сознательно принять риск или передать его (страховка, SOC 2 поставщика) тоже считается валидным ответом. Не на каждый риск вешается контроль.
4. Хорошо ли мы сработали? Проверь, что меры реально держат. Пентест, ревью, мониторинг. Контроль, который ты ни разу не проверил, — это контроль, которого у тебя нет.

Эти четыре вопроса можно прогнать за пять минут против одного эндпоинта или за два дня против платёжной платформы. Глубина масштабируется; вопросы не меняются. Их усвоение и есть настоящая цель «иметь фундамент безопасности» — всё остальное в кластере навешивается на эту рамку.

Угроза, уязвимость, риск: три слова, которые путают, а зря

Неточный словарь — вот почему разговоры о безопасности ходят по кругу. Эти три слова называют три разные вещи, и старший инженер держит их чёткими, потому что различие диктует, что ты реально делаешь.

• Угроза — это кто и чего он хочет: потенциальный субъект и вредное действие, которое он мог бы совершить. «Заскучавший аутентифицированный пользователь, желающий читать чужие счета.» Угрозы существуют независимо от того, есть ли в твоей системе изъян; это свойство мира, а не твоего кода.
• Уязвимость — это изъян в твоей системе, который угроза могла бы проэксплуатировать. «Эндпоинт счёта делает запрос WHERE id = ? без проверки owner_id.» Уязвимости — свойство твоего кода и конфигурации, это та часть, которую ты контролируешь.
• Риск — это комбинация: насколько вероятно, что эта угроза встретит эту уязвимость, и насколько плохими будут последствия. По риску ты приоритизируешь, потому что починить всё нельзя. Уязвимость, до которой никто не может дотянуться и которая ничего ценного не раскрывает, — низкий риск; тот же изъян на пути аутентификации — пожар по высшему разряду.

Распространённое сокращение: риск ≈ вероятность × ущерб, где уязвимость поднимает вероятность, а ценность того, что за ней стоит, поднимает ущерб. Практическая выгода — это триаж. Ты чинишь не «больше всего уязвимостей», а снижаешь «больше всего риска». Поэтому опечатка в тексте ошибки (уязвимость — раскрытие информации) стоит ниже неаутентифицированного админ-эндпоинта, хотя технически оба — изъяны.

Глубокая защита: считай, что каждый слой откажет

Четвёртая несущая идея — что ни один отдельный контроль не должен быть единственным, что стоит между атакующим и добычей. Глубокая защита (defense in depth) означает наслаивание независимых контролей так, чтобы отказ любого из них не заканчивал игру. WAF пропустил полезную нагрузку → её ловит валидация ввода. В валидации пробел → параметризованные запросы всё равно обезвреживают инъекцию. Кто-то украл токен → короткое время жизни токена и отзыв ограничивают радиус поражения. Каждый слой исходит из того, что слой перед ним рано или поздно откажет, потому что в проде он рано или поздно отказывает.

Вот практическая причина, почему «что мы будем делать?» редко имеет однострочный ответ. История с ресайзером — урок глубокой защиты: фикс не один, а несколько — проверить, что URL разрешается в публичный адрес, заблокировать link-local диапазон метаданных на сетевом уровне, дать инстансу least-privilege роль, чтобы украденные учётные данные стоили почти ничего, и детектировать аномальный исходящий запрос. Любой из них в одиночку — единая точка отказа.

Как складывается кластер

Когда мышление на месте, остальной кластер кибербезопасности — это просто то, куда ты его направляешь. Foundations — это сама рамка: четыре вопроса, словарь, моделирование угроз — и всё ниже по течению её наследует. Дальше поле дробится на роли, определяемые тем, в каком вопросе они живут:

• Red (offensive) живёт в что может пойти не так. Red-команды и пентестеры намеренно думают как атакующие, находя уязвимости, которые твой дизайн упустил. Их выход — «вот что реально может сделать противник».
• Blue (defensive) живёт в что мы будем делать и хорошо ли мы сработали. Детектирование, мониторинг, реагирование на инциденты, харденинг. Их выход — «мы это поймали, локализовали, и снова это не сработает».
• Purple — это намеренное сотрудничество двух: red показывает blue ровно то, как заходит атака, чтобы blue построил детект, который её ловит. Это не столько отдельная команда, сколько практика замыкания петли между offense и defense.
• Cloud — это современная местность, на которой всё это работает: IAM, сетевая сегментация, проблема эндпоинта метаданных из Hook, управление секретами. Поверхность атаки переехала в конфигурацию, поэтому огромная доля реальных инцидентов сегодня — это инциденты облачной мисконфигурации.

А трек application-security, который ты, возможно, уже знаешь, — OWASP Top 10, OAuth, JWT — это appsec-ступень той же лестницы: мышление foundations, применённое конкретно к слою веб-приложения, который ты строишь каждый день. OWASP Top 10 — это буквально список «что может пойти не так» для веб-приложений, ранжированный по реальным данным. Когда ты изучал IDOR и авторизацию deny-by-default, ты прогонял второй вопрос Шостака против HTTP-эндпоинтов. Этот кластер расширяет ту же линзу на всю систему.

Где ты стоишь

Ты не стартуешь с нуля. Как инженер middle-plus ты уже рассуждаешь о краевых случаях, режимах отказа и недоверенном вводе — безопасность это та же строгость, развёрнутая враждебно. Цель кластера — не сделать тебя фултайм red-тимером или SOC-аналитиком; она в том, чтобы сделать тебя двуязычным: способным думать как атакующий достаточно, чтобы предвидеть злоупотребление, и как защитник достаточно, чтобы построить контроль. Эта беглость и есть то, что позволяет тебе сидеть на ревью дизайна и сказать «погодите — а что мешает кому-то направить этот fetch на эндпоинт метаданных?» до того, как код уедет, а не через три недели после.