На✻уй
Безопасность

Безопасник как мифологическое существо

Безопасник не человек. Безопасник — это функция, которая принимает на вход твой план релиза и возвращает Exception: not approved. Ошибка в том, чтобы пытаться с ним договориться как с человеком. С безопасником договариваются как с погодой: учитывают, одеваются потеплее и планируют заранее.

Есть три архетипа:

• Фундаменталист. Читал OWASP в подлиннике. Верит, что релиз без пентеста — это грех. Бесполезно объяснять про time-to-market. Лечится только цитатами из внутреннего регламента, написанного им же.
• Выгоревший. Когда-то был фундаменталистом. Теперь согласует всё за полчаса до дедлайна, если ты принесёшь ему кофе и не будешь смотреть в глаза. Самый полезный типаж. Береги его.
• Новенький. Пришёл из консалтинга с презентацией на 84 слайда. Хочет внедрить Zero Trust к пятнице. Опасен. Требует дозированного взаимодействия под присмотром старших товарищей.

«Это же MVP» и другие заклинания силы

В русском корпоративном языке есть несколько священных формул, которые временно отключают критическое мышление у любого согласующего. Выучи их наизусть.

• «Это MVP» — работает на ранних стадиях. Снимает вопросы про нагрузочное тестирование, отказоустойчивость и чтение логов. Срок годности: один квартал.
• «Мы это потом вынесем в отдельный эпик» — классика. Эпик никогда не создаётся. Если создаётся — приоритет P4. Если поднимается до P1 — значит, уже случился инцидент, и теперь это проблема SRE, а не твоя.
• «Это временное решение» — работает на средних стадиях. Время, как известно, понятие растяжимое. Всё, что заработало, — временное до следующего редизайна.
• «Legacy» — магическое слово, которое превращает любой говнокод в культурное наследие, которое опасно трогать. Используй, когда безопасник спрашивает, почему пароли лежат в открытом виде.

Фундаментальный принцип: «Легче извиниться, чем согласовать»

Это не мой слоган — я его подслушал у тимлида бэкенда в курилке. Но он работает.

Принцип устроен так: стоимость извинения после инцидента — один разговор с руководителем и один постмортем. Стоимость согласования до релиза — четыре месяца переписки с тремя командами и один нервный срыв. Математика простая.

Принцип имеет границы применимости. Если ты работаешь в банке и речь идёт о платёжных данных — не используй его. Если ты работаешь в финтехе и речь идёт о KYC — не используй его. Если речь идёт о любых персональных данных граждан — не используй его. Во всех остальных случаях — дерзай.

Искусство формулировки тикета

Безопасник читает только заголовки. Это не лень, это защитный механизм: у него в очереди 340 тикетов. Используй это.

Плохо:

[SEC-REVIEW] Интеграция с внешним API: нужна проверка на утечку токенов

Это классический «сигнальный» заголовок. Он попадёт в первую пятёрку на ревью, и ты огребёшь полный список замечаний.

Хорошо:

[TECH] Небольшое улучшение существующего механизма доступа

Это попадёт в бэклог ниже тикетов про обновление сертификатов. Ревью пройдёт по диагонали. Визу получишь через два дня.

Отлично:

[CHORE] Рефакторинг

Это вообще не читают. CHORE — это слово, которое безопасник видит в последний раз, когда прокручивает ленту. Никто никогда не спрашивает, что именно ты рефакторишь. Рефакторишь — и всё, молодец.

Feature flag как алиби

Feature flag — это не техническая практика. Это юридический инструмент.

Когда безопасник спрашивает: «Почему вы это выкатили в прод без моего согласования?», правильный ответ: «Мы это не выкатили. Мы это задеплоили. Под флагом. Флаг выключен. Как только вы согласуете — мы включим».

Теперь важное уточнение. Флаг включается тремя способами:

1. Официально. Через change request, с согласованием, с окном деплоя. Идеальный мир. Бывает раз в год.
2. По запросу продакта. «Включите на 5% пользователей, посмотрим метрики». Безопасник обычно не в курсе, что такое «5% пользователей» и почему они важнее его процесса.
3. Тихо. Флаг был false в конфиге. Стал true. В changelog написано «обновление конфигурации окружения». Никто не читает changelog.

Пятничный деплой как духовная практика

Весь корпоративный мир учит тебя не деплоить в пятницу. Весь корпоративный мир не прав.

Пятница 17:00 — это окно, когда:

• Безопасник уже ушёл на дачу.
• Юрист не отвечает в почте.
• Комплаенс в отпуске.
• В понедельник у всех стендапы, ретро и планирование — до твоего деплоя никто не доберётся до среды.
• К среде у всех уже новая повестка.

К тому моменту, как кто-то заметит, что ты выкатил, — это уже не «новый функционал», это «наш существующий продукт, работающий с прошлой недели». А существующий продукт не требует согласования. Он требует поддержки.

Waiver через измор

Waiver — это индульгенция. Официальная бумага, что безопасник разрешил тебе не соблюдать требование. Получить её сложно. Но есть приём.

Методика называется «переписка на 47 писем». Работает так:

1. Ты пишешь: «Коллеги, прошу согласовать отступление от регламента в следующем случае…»
2. Безопасник отвечает вопросом.
3. Ты отвечаешь с уточнением, но добавляешь два новых кейса.
4. Безопасник задаёт пять вопросов.
5. Ты отвечаешь на три и добавляешь CC на архитектора.
6. Архитектор отвечает, что ему нужно время подумать.
7. Ты через неделю пишешь: «Коллеги, напоминаю, дедлайн».
8. Безопасник отвечает: «Окей, в порядке исключения».

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

Google Doc как священный артефакт

В российской корпоративной культуре существует убеждение: если что-то написано в Google Doc (или, в нашем случае, в Яндекс.Документах / Confluence / Вики — подчеркните нужное) и там есть больше трёх комментариев от разных людей — это согласовано.

Это неправда. Но все в это верят, и пока верят — пользуйся.

Рецепт:

1. Создай документ «Архитектура фичи X».
2. Пригласи туда безопасника, архитектора, техлида и двух продактов.
3. Попроси «посмотреть».
4. Получи три комментария: «лгтм», «вопрос по схеме данных — обсудим», «👍».
5. Выдели эти три комментария как «резолвед».
6. В следующий раз, когда кто-то спросит «а это согласовано?», отправь ссылку.

Никто никогда не откроет документ и не перечитает его. Ссылка в переписке = согласование. Это корпоративный KYC наоборот.

Pet-прод: тёмный секрет каждой команды

У каждой команды есть pet-прод. Это второй контур, где всё работает без согласований. Называется он по-разному: staging, pre-prod, dev-2, тестовая среда «для демо клиентам», окружение для нагрузочных тестов. Его объединяет одно: в нём лежат реальные данные, и безопасник про него не знает.

Официально pet-прода не существует. Неофициально на нём работает половина клиентов, которым «срочно нужно посмотреть».

Как не попасть в отчёт пентеста

Раз в год к вам приходит пентестер. Пентестер — это безопасник, которому платят за то, чтобы он нашёл дыры. И он их найдёт. Вопрос в том, чьи.

Твоя задача — сделать так, чтобы дыры он нашёл не в твоём сервисе. Для этого есть три проверенные техники:

1. Скоуп-инжиниринг. До начала пентеста согласуй с пентестерами список «в скоупе» сервисов. Убедись, что твой сервис туда не попал. Используй формулировку: «этот сервис сейчас в активной миграции, пентестить бессмысленно». Миграция закончится через 18 месяцев.
2. Декоративное соответствие. Добавь в свой сервис пять «декоративных» проверок: rate-limiter, который срабатывает только на 10 тысячах RPS, CSRF-токен, который не валидируется, заголовок X-Security-Level: High. Пентестер увидит следы заботы о безопасности и уйдёт искать добычу попроще.
3. Жертвенный эндпоинт. Оставь один очевидно плохо защищённый эндпоинт, который делает что-то не очень важное (например, возвращает версию сборки). Пентестер найдёт его, радостно отчитается, напишет в отчёт один пункт и уйдёт. Ты исправишь, получишь галочку «учтены замечания пентеста», и в этом году тебя больше не беспокоят.

«Учтём в следующем спринте»

Эту фразу произносят примерно 340 раз в квартал в каждой продуктовой команде. Из них в следующем спринте учитывается ноль.

Почему это работает? Потому что у безопасника нет инструмента, чтобы проверить, учли ли вы что-то в следующем спринте. Он может прийти и спросить. Ты покажешь тикет в бэклоге. Тикет там с прошлого квартала, с приоритетом P3. «Мы в процессе, коллеги».

Протокол выживания при аудите

Рано или поздно к тебе приходят с аудитом. Это не конец света. Это конец квартала.

Первые 24 часа:

• Ничего не удаляй. Удалённое восстанавливается, и факт удаления — отдельное нарушение.
• Ничего не коммить. Все изменения в коде за период аудита — подозрительны.
• Не оправдывайся в письмах. Всё, что ты напишешь, будет использовано против тебя.

Следующие 48 часов:

• Собери «папку контекста». Туда положи всё, что когда-либо было сказано в твою пользу: письма от продуктового руководства «срочно релизим», скриншоты переписки с безопасником «окей, в порядке исключения», тикеты с визами.
• Запросить встречу. На встрече у тебя два козыря: контекст и усталость аудитора. Аудитор тоже человек, у него в день пять таких встреч.

Ключевая фраза: «Мы приняли это решение осознанно, с учётом бизнес-контекста, и зафиксировали риск». Даже если вы ничего не фиксировали. Риск, зафиксированный задним числом, — это всё ещё зафиксированный риск.

Как написать постмортем, в котором ты герой

Постмортем — это литературный жанр. Не технический документ, а именно жанр, со своими законами.

Структура:

1. «Что случилось» — сухо, без эмоций, в страдательном залоге. Не «я выкатил без ревью», а «был произведён деплой в рамках инициативы по ускорению time-to-market».
2. «Почему случилось» — здесь важно указать не менее трёх причин, из которых две — системные (процессы, инструменты), а одна — человеческая, но не твоя. Идеально: «отсутствие автоматической проверки на этапе CI», «недостаток коммуникации между командами», «ошибка конфигурации».
3. «Что сделаем» — список из пяти действий, из которых три — «улучшить процесс», одно — «провести обучение», одно — «добавить в чек-лист». Ни одно не требует бюджета. Ни одно не имеет дедлайна раньше чем через квартал.
4. «Уроки» — здесь ты пишешь про важность безопасности с искренним лицом. Безопасники любят этот раздел. Цитируй OWASP.