6 подписчиков

Перечисленные роли в опросе и те, что предложили в комментариях, такие как AppSec и Security Architect, это все люди, которые должны дополнять друг друга. Редко можно встретить человека, который шарит за все и сразу и помнит в моменте обо всем. Поэтому, как мне кажется, решение которое я описал, а точнее проблема, диктуется требованиями. И дальше возникает вопрос, на каком этапе проектирования и работы с требованиями возникает тема безопасности. Логично, что чем выше тем лучше, и каждая роль реализует свою детализацию решения по требованиям безопасности и дополняет предыдущий слой от предыдущего специалиста. Чуть понятней опишу.

Мы всегда начинаем с абстракции и неопределённости, как правило когда поступает задача мы оперируем хотелками заказчика. Плюс у нас есть какие-то базовые критерии качества, они могут быть на бумаге или в подсознании каждого. Но мы это фиксируем пока на уровне рисков, ограничений и требований. Никакой реализации еще не обсуждается. Как правило такую верхнеуровневую работу проводят архитекторы если они делают архитектуру. Бывает наоборот - архитектуру делает инженер, а архитектор ее проверяет, но в этом случае тоже не будет деталей реализации. Вспомним модель C4, достаточно уровней C4 и C3 чтобы описать систему для архитектора, ниже детализация ему не интересна и я не встречал чтобы ее глубже описывали, как мне кажется по причине того что слишком много неизвестных все еще остается и чем глубже закопаемся - тем сильней ошибемся. А наша задача ошибки минимизировать и создавать гибкость в изменчивом мире.

Далее уже глубже проходит грумминг, скорее всего архитектора на нем нет, есть лид или сеньор или кто-то из арх комитета. Там уже могут обсуждаться детали и как раз может всплыть более детально тема безопасности, и тут уже первый этап где кто-то любой из тех кто участвует в грумминге (все же это как правило инженеры и грумминг проводит разработчик из команды, которая будет заниматься реализацией) может предложить решение изоляции данных на уровне БД как защиту в глубину. Но может не предложить, и дальше уже ниже по сценарию может инженер додумать эту идею в момент реализации, но ее придется согласовать так как это изменение архитектуры данных и усложняет реализацию. А реализацию уже согласовали раз она в разработке, поэтому тут нужно искать уже компромисс.

Мой ответ такой - кто угодно из перечисленных ролей может предложить и задуматься о вопросах реализации безопасности, но самое эффективное обсуждать это на грумминге и услышать это решение хочется от инженера, который проводит грумминг. На грумминге можно эффективно договориться о решении. На арх ревью вероятно вам могут сказать что это не тема обсуждения так как это детали реализации, а на этапе разработки может быть поздно переобуваться в решении. Плюс это может расцениваться не как критическая история а как Defense in Depth (формально так и есть) и где-то может восприниматься как необязательный принцип.

Больше постов у меня в Telegram-канале: t.me/...kii или через поиск в Telegram по запросу «Сергей Озеранский».

Кто должен думать об этом?

анонимный опрос

Архитектор (можете написать в комментариях какой)

Разработчик, который реализует фичу

Инженер уровня Senior и выше (не реализует, но учавствует в ритуалах подготовки к реализации)

DBAPlatform Engineer

Свой вариант в комментариях

2 минуты

27 июня