Проверка безопасности архитектуры приложения: решения, границы и доказательства

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

Возьмём вымышленную платформу для совместной работы с конструкторскими файлами. Участник проекта просит подготовить большой CAD-архив для внешнего партнёра. API проверяет права участника и ставит задание в очередь. До запуска обработчика владелец проекта исключает этого участника и отзывает доступ партнёра. Однако обработчик создаёт архив и ссылку: на момент постановки в очередь запрос был разрешён.

Каждый отдельный компонент вроде бы действует правильно. API установил личность пользователя, очередь доставила корректное сообщение, обработчик выполнил задание. Не разрешён вопрос уровня архитектуры: право закрепляется в момент запроса, проверяется перед раскрытием данных или передаётся обработчику как узкое делегированное полномочие с ограниченным сроком? Проверка должна сделать этот выбор явным, разобрать отказы и указать, чем будет подтверждено нужное поведение.

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

Начните с решения, для которого нужна проверка

Фраза «проверить архитектуру» ещё не задаёт границы работы. Сформулируйте предстоящее решение: утвердить предложенную схему, выбрать один из двух способов передачи идентификации, понять, снижает ли миграция риск, либо определить условия допуска к выпуску. Зафиксируйте владельца решения, срок и значимые свойства безопасности. Для прототипа допустимы открытые вопросы реализации, которые были бы неприемлемы перед запуском в рабочей среде.

Нужны два исходных состояния. Текущее состояние описывает то, что действительно работает сейчас: временные мосты, ручные операции, унаследованное доверие и неучтённые интеграции. Целевое состояние показывает будущую конструкцию и переход к ней. Если смешать их на одной схеме, выводы будут неверными. В целевой архитектуре у каждого сервиса может быть собственная идентичность, хотя на промежуточном этапе часть вызовов всё ещё проходит с общими учётными данными. И наоборот, для слабого места текущей системы уже может существовать профинансированная и проверяемая замена.

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

Первый результат — перечень вопросов, а не список уязвимостей. Кто вправе вызвать конкретное последствие? Где принимается решение о доступе? Какой компонент может изменить правила? Что произойдёт после отзыва полномочий, повторной доставки сообщения, недоступности зависимости или вмешательства оператора при восстановлении? Какие сведения подтверждены наблюдением, а какие пока остаются предположениями?

Разделите границы доверия текущего и целевого состояния

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

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

Не прячьте контур управления. У сервиса может быть узкий прикладной API, тогда как его учётная запись развёртывания способна заменить образ, изменить секреты, переписать маршруты или назначить процессу более сильную роль. Администратор, которому недоступна карточка клиента через интерфейс продукта, может иметь возможность снять копию базы. Проверка связывает такие полномочия с владельцами, согласованием, аварийным доступом, журналированием и отзывом. Слово «внутренний» не заменяет ни идентичность, ни правило доступа.

Проследите данные до самого удаления

Фраза «зашифровано при хранении» не описывает жизненный цикл. Для каждого класса чувствительных данных нужно пройти сбор, проверку, использование, производные копии, кэши, поисковые индексы, телеметрию, выгрузки поддержки, резервные копии, архив и уничтожение. На каждом этапе фиксируются владелец и требуемая защита. Проектирование удаления должно учитывать реплики, версии объектов, поисковые документы, содержимое очередей и восстановление старой резервной копии.

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

Рассматривайте фоновую работу как путь авторизации

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

Важна и семантика доставки. Очередь с доставкой как минимум один раз — например стандартная очередь Amazon SQS — может доставить сообщение повторно. Обработчик может завершить внешнее действие и аварийно остановиться до подтверждения. После тайм-аута второй обработчик возьмёт ту же работу. Многократные ошибки могут отправить сообщение в карантинную очередь, откуда человек или инструмент повторит его позже. Архитектура должна определить идемпотентность, область устранения дублей, ожидания по порядку, допустимый возраст задания, предел повторов, обращение с неисправимым сообщением, а также право повторять и изменять задания.

Вернёмся к вымышленному CAD-архиву. В сообщении недостаточно передать идентификатор проекта и прежнюю роль пользователя. Обработчик должен знать допустимый проект, получателя, набор данных, срок и действие. Кроме того, необходимо решить, что означает отзыв доступа. Если в момент раскрытия требуется действующее право, обработчик заново обращается за авторизацией и безопасно ведёт себя при недоступности службы политик. Если бизнес осознанно разрешает завершать ранее утверждённую работу, требуется узкое полномочие с коротким сроком и журнал, где такое исключение видно.

1. МодельПоказать участников, хранилища, контуры управления, синхронные вызовы, очереди и изменения доверия в текущем и целевом состоянии
2. РешениеСформулировать неизменяемое правило, сравнить варианты, назначить владельца и записать остаточный риск
3. ТребованияПеревести выбор в требования к идентичности, авторизации, данным, повторам, отзыву и наблюдаемости
4. ПроверкаНазначить каждому утверждению анализ, автоматическую проверку, интеграционное испытание, испытание при сбое либо разрешённую проверку в работающей среде
5. ПересмотрВернуться к модели при изменении границы, поставщика, потока чувствительных данных или полномочий контура управления

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

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

Проверка безопасности не должна превращать любимый шаблон исполнителя в универсальное правило. В системной инженерии проект рассматривают как пространство выбора: задают желаемый результат и измеримые критерии, находят варианты, сравнивают их и сохраняют обоснование. Безопасность — один из критериев наряду с доступностью, задержкой, удобством эксплуатации, стоимостью, приватностью и риском миграции.

Для фоновой выгрузки есть четыре обоснованных варианта. Любой из них может подойти в определённом контексте, но у каждого свой набор обязательных доказательств.

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

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

Тот же анализ применим к административным путям. Кто может изменить политику клиента, выпустить сервисную идентичность, повторить сообщение из карантинной очереди, восстановить резервную копию или обойти недоступную зависимость? Аварийный доступ иногда необходим, но его условия, длительность, согласование и следы должны быть частью конструкции, а не устной договорённостью операторов.

Отделяйте проверенные факты от предположений

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

Одни предположения задают ограничение конструкции: провайдер идентификации должен быть доступен для интерактивного входа. Другие относятся к среде: управляемая служба ключей обеспечивает определённую границу. Третьи описывают поведение: потребитель идемпотентно обрабатывает задание. Четвёртые связаны с переходом: после второго этапа миграции общих учётных данных не останется. Для каждого типа нужны свои материалы.

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

Доказательство должно соответствовать утверждению. Успешный штатный сценарий не подтверждает безопасный отказ. Текст политики не показывает её состояние в рабочей среде. Отсутствие отказов на панели не доказывает, что запрет действует. Проверка архитектуры способна определить нужные материалы и изучить уже доступные, но всё, что ждёт реализации или запуска, должно оставаться помеченным как неподтверждённое.

Для систем с большим числом интерфейсов руководство по оценке безопасности REST API показывает, как сопоставить контракт с поведением. Для многошаговых правил полезна статья о проверке безопасности бизнес-логики: корректные отдельные запросы способны сложиться в недопустимый результат. Такие испытания закрывают отдельные пункты плана доказательств, но не заменяют архитектурный выбор.

Принимайте журнал решений, а не общий чек-лист

Хороший отчёт даёт архитектору, разработчику, оператору и владельцу риска одинаковое понимание системы. В него входят решение и границы; схемы текущего и целевого состояния; матрица участников и полномочий; жизненный цикл чувствительных данных; синхронные, фоновые и административные пути; предположения и их статус; угрозы с привязкой к элементам конструкции; рассмотренные варианты; выбранные меры; остаточные риски; план доказательств с владельцами и критериями приёмки.

Полезно различать четыре типа результатов. Дефект конструкции означает нарушение согласованной цели безопасности. Нерешённый вопрос означает, что остаются допустимые варианты и владелец должен выбрать. Неподтверждённое предположение показывает зависимость вывода от отсутствующих материалов. Пункт проверки реализации означает, что конструкция определена, но код, конфигурация или рабочее поведение ещё требуют подтверждения. Если собрать всё в один список серьёзности, команда начнёт «исправлять» вопрос заголовком задачи.

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

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

Проверяйте работающую систему там, где это требует план доказательств

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

Pentest.red может превратить выбранные пункты плана доказательств в ограниченный объём проверки. На странице подготовки границ пентеста заранее фиксируются системы, идентичности, процессы, исключения, разрешённые действия, окно работ и ожидаемые материалы. До начала требуется письменное разрешение всех владельцев затронутых систем. Результат подтверждает только наблюдавшееся поведение в согласованной среде, при заданных ролях, условиях и сроке. Это не сертификат и не доказательство отсутствия всех архитектурных слабостей.

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