Безопасность: уязвимости рождаются в архитектуре

Роман Лебедь представляется секьюрити-архитектором Tinkoff: в компании два года, пришёл лидом AppSec-команды, сейчас отвечает за линейку из трёх продуктов — безопасность сервисов, DevSecOps-технологии и защиту внешней инфраструктуры и периметра. В команде примерно пятнадцать человек, и она делится на платформенную часть, которая развивает безопасность внутренней платформы разработки — выпуск про саму платформу с Димой Гаевским вышел накануне, — и на инженерную, которая разрабатывает и внедряет инструменты оценки защищённости продуктов. Принцип простой: не браться за процессы, которые невозможно масштабировать на все приложения; ручной анализ и секьюрити-архитекторы остаются для самых критичных, платформенных сегментов. Фокус, по словам Романа, сместился с защиты всех сервисов вширь на сборку безопасной архитектуры из готовых кубиков — подход описан в книге Google о построении безопасных систем, которую в Code of Architecture, как замечает Александр, пока так и не успели разобрать.

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

К нынешней модели пришли недавно: экспертизу всё больше передают в команды — разработчикам, SRE, QA, а теперь и продактам. Толчком стало понимание, что многие уязвимости рождаются не на реализации, а на проектировании. Роман оговаривается, что архитектором в их понимании считается не тот, кто собирает готовые решения по стандартным шаблонам, а тот, кто выбирает лучшее решение, даже если его ещё нет на рынке, и проектирует систему с нуля. Пару месяцев назад начали эксперимент: секьюрити-архитекторы подключаются к командам с начала дизайна, показывают, как выявляют угрозы, разбирают топ-10 антипаттернов проектирования и дают готовые рецепты — как устроить обмен криптографическими ключами, как сделать доступ администраторов и механизмы аварийного доступа. Всё это собрано во внутреннюю Shift Left Security Book, доступную любому сотруднику; новичкам при найме назначают курс по безопасной разработке — как самому разобрать результаты статического анализатора, как пользоваться сервисом публикаций. Отдельная команда тренингов думает над интерактивной платформой, которая подбирает задачи под стек сотрудника: Python-разработчику — найти и починить уязвимость и написать security-тесты, всё в форме квеста с баллами.

Александр спрашивает, как команда выдерживает нагрузку в такой модели. Ответ: регулярные ретроспективы и обратная связь командам, собственная система оценки проектов и принцип 80/20 — заранее посчитать полноценный анализ невозможно, поэтому на проект выделяется время и за него делается максимум. Работа становится предсказуемее, а с командой встречаются несколько раз в неделю — в отличие от консервативных команд безопасности, которые месяцами анализируют проект и приносят решение, которое может вообще не удовлетворять функциональным требованиям; Александр сравнивает это с прогрессивным JPEG, который проявляется постепенно. Второй ответ — переносить экспертизу в код: людей, работающих с командами напрямую, немного. R&D-команда делает базовое моделирование угроз без человека: не заставлять команды формально описывать архитектурные диаграммы, а анализировать машинным обучением документацию и даже записи встреч, показывая архитектору базовый набор угроз. Александр замечает, что после пилота из этого вышла бы отличная тема для доклада на конференции.

Шапок у Романа несколько, и подключается он туда, где без него команда не справится. Как архитектор он участвует в дизайне, проработке требований и приёмке самых критичных систем, иногда сам смотрит код; как руководитель небольшой R&D-команды выбирает перспективные направления и менторит новичков; как technical product manager отвечает за продуктовую часть — департамент около года переходил от сервисных функциональных команд к продуктам. Ключевую метрику для автоматизированных процессов он описывает как количество уязвимостей, умноженное на среднее время устранения и на средний коэффициент критичности, с поправкой на количество разработчиков: смысл — сокращать число дефектов и время, которое разработчик тратит на их починку. Александр замечает, что такую роль тянут только сильные инженеры, которые делают не системы, а продукты для конкретных потребителей, а кандидатов, сильных одновременно в инженерии и в продукте, по словам участников, очень мало.

Профессия по информационной безопасности внутри компании только запускается: Роман пока единственный, кто ведёт её изнутри, спрос небольшой, а разделить её на инфраструктурную безопасность, AppSec, мониторинг и форензику мешает размер — в каждую попало бы человек по десять. Александр пересказывает свой выпуск про Staff+ инженеров: вместо должности архитектора над разработкой в компании выбрали роли — техлид домена, архитектор, «пожарник», которого перекидывают между проектами. Год назад безопасность договорились включить в требования для перехода между уровнями других профессий, по-разному для разработчиков (безопасное кодирование, паттерны и антипаттерны) и для инфраструктурных инженеров (хранение секретов, безопасная доставка, администрирование). Обучить всех всё равно не выйдет — люди меняются, компания растёт, — поэтому в работе проект с генерацией автофиксов: поверх статического анализатора модель объясняет причину уязвимости и предлагает исправление кнопкой apply suggestion в IDE. Открытых позиций много: в приоритете техлид в защиту периметра и инженеры в AppSec.