Архитектура безопасности

Практическая ситуация: интерфейс скрывает чужие документы, но клиент может отправить идентификатор другого документа. Какой компонент должен окончательно решать, разрешён ли доступ к документу?

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

Разберите, от каких угроз защищает шифрование данных в базе, если приложение расшифровывает их перед отправкой пользователю.

Сервис загружает ресурс по URL, переданному пользователем. Какую угрозу нужно моделировать на границе исходящих запросов?

На публичный endpoint поступают вебхуки партнёра. Как проверить, что запрос действительно сформирован партнёром, а не отправлен злоумышленником на известный URL?

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

За счёт чего принцип наименьших привилегий ограничивает ущерб при компрометации учётной записи сервиса?

Как CSRF-токен предотвращает подделку запроса в веб-системе с cookie-сессией?

Сравните режимы «разрешить по умолчанию» и «запретить по умолчанию» для нового действия в системе: какой вариант безопаснее при неполном наборе правил?

Сервис хранит пароли следующим образом:

def register(password):
    db.save(hash=sha256(password.encode()).hexdigest())

def login(password, saved_hash):
    return sha256(password.encode()).hexdigest() == saved_hash

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

После выдачи нового refresh-токена клиент повторно предъявил старый. Как ротация refresh-токенов позволяет обнаружить компрометацию?

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

Сервис получает подписанный JWT, выпущенный доверенным центром для другого сервиса. Какая проверка не позволит принять такой токен?

На границе системы TLS завершается на обратном прокси, а до приложения данные идут по обычной сети. Какой защитный эффект теряется?

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

Внутренний сервис принимает запросы только из закрытого сетевого сегмента. Достаточно ли этого, чтобы считать вызывающий сервис доверенным?

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

При разборе XML от пользователя разрешены внешние сущности. Как это расширяет атакующую поверхность сервиса?

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

В нескольких сервисах правила доступа дублируются и постепенно расходятся. Какой архитектурный механизм уменьшит риск таких расхождений?