Ошибки архитектуры дороже всего: незащищенные точки интеграции, избыточные права сервисов, общие учетные данные, отсутствие сегментации. Их находят на схемах и в описании до разработки или внедрения, пока исправление стоит недорого. Ревью проводят при проектировании новой системы, при переходе в облако, при добавлении интеграций, а также перед аттестацией и крупными релизами.

• Собрать архитектурные схемы, описание компонентов, потоков данных, интеграций и границ доверия.
• Выделить границы доверия и точки входа: внешние интерфейсы, API, каналы удаленного доступа, привилегированные роли.
• Построить или уточнить модель угроз для архитектуры и сопоставить угрозы с предусмотренными мерами защиты.
• Проверить управление доступом, аутентификацию, разделение сред, хранение секретов, шифрование и журналирование.
• Оценить устойчивость к отказам и компрометации одного компонента: возможность распространения атаки и восстановление.
• Оформить выводы с приоритетами и рекомендациями, обсудить их с архитекторами и согласовать план исправлений.

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

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

• Эксперт не должен участвовать в разработке архитектуры, иначе проверка теряет независимость.
• Просить показать методику и пример отчета: ревью должно давать конкретные рекомендации, а не общий чек-лист.
• Заранее согласовать, какие материалы нужны: схемы, описание интеграций, модель угроз.
• Договориться о повторной проверке после исправления критичных замечаний.
• Для внутреннего ревью закрепить регулярность и участие архитекторов других команд.