Вопросы на собеседовании: Инженер безопасности

Я применяю STRIDE к каждому потоку данных и границе доверия, а затем превращаю реалистичные угрозы в проверяемые требования безопасности.

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

Я выбираю PASTA, когда нужен глубокий анализ риска от бизнес-последствий и симуляции атак, а STRIDE использую для более быстрого покрытия дизайна.

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

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

• Ветки OR могут включать credential stuffing, злоупотребление сбросом пароля, кражу сессии и восстановление через обман службы поддержки.
• Ветки AND отражают предпосылки, например кражу refresh-токена и обход проверки устройства или риска перед повторным использованием.
• Для листьев отмечаю нужный доступ, вероятность, наблюдаемые сигналы и покрытие контролями, не создавая ложную точность неподтвержденными числами.
• Дерево показывает общие меры, например устойчивый к фишингу WebAuthn одновременно закрывает несколько веток с учетными данными.

Граница доверия содержательна, когда данные переходят в контекст с другими гарантиями идентификации, привилегий, владения или контроля.

• Типичные границы проходят между браузером и API, ворклоадом и базой данных, арендатором и общим сервисом, компанией и сторонним webhook.
• Линия подсети сама по себе не всегда является границей, если обе стороны используют одну скомпрометированную идентичность и модель авторизации.
• На каждом переходе я отмечаю протокол, аутентификацию, авторизацию, шифрование, парсер и валидацию.
• Я детализирую диаграмму, пока ревьюеры не увидят, где недоверенные данные становятся доверенным состоянием или повышаются привилегии.

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

• К активам относятся ключи подписи и административные действия, а не только очевидные записи вроде платежных или медицинских данных.
• Я отслеживаю, где каждый актив создается, обрабатывается, хранится, журналируется, резервируется и удаляется, чтобы найти забытые копии.
• Классификация учитывает бизнес- и регуляторные последствия, например захват аккаунта, мошенническую выплату, утечку по GDPR или нарушение целевого времени восстановления.
• Инвентарь проверяю с владельцами продукта, эксплуатации и данных, потому что архитектурные схемы редко отражают все критичные бизнес-возможности.

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

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

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

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

Я использую CVSS для описания технической критичности, а EPSS для оценки вероятности эксплуатации в ближайшее время, но ни одна метрика не заменяет контекст влияния и экспозиции.

• CVSS учитывает вектор атаки, необходимые привилегии, участие пользователя и влияние на конфиденциальность, целостность и доступность.
• EPSS является вероятностной моделью на основе наблюдаемых сигналов эксплуатации, поэтому высокий балл повышает срочность для доступного из интернета актива.
• Я добавляю достижимость, развернутую версию, компенсирующие меры, критичность актива, данные об эксплуатации из CISA KEV и радиус поражения.
• Решение и доказательства сохраняю в задаче, чтобы последовательно пересматривать его при изменении балла или контроля.

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

• Сравниваю предпосылки и экспозицию, например неаутентифицированный путь из интернета и внутренний путь, требующий привилегированной роли.
• Оцениваю затронутых пользователей, данные, стоимость транзакций, возможность бокового перемещения и цену восстановления, а не только метку критичности.
• Активная эксплуатация, публичный эксплойт, запись в CISA KEV или слабая обнаруживаемость повышают срочность.
• Для отложенной угрозы документирую временный контроль, владельца, срок действия и явное принятие риска.

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

• Запись называет затронутый компонент и актив, предпосылки атакующего, влияние и соответствующий поток или границу на диаграмме.
• Решение указывает, снижается, исключается, передается или принимается риск, а также содержит владельца и срок.
• Мера защиты связана с требованием и доказательством, например модульным тестом, интеграционным тестом авторизации, policy-check или проверенной конфигурацией.
• Остаточный риск и предположения остаются видимыми, а существенное изменение архитектуры открывает находку повторно.

Современный клиент использует Authorization Code Flow с PKCE S256, чтобы токены не попадали в ответ авторизации, а украденный код нельзя было обменять отдельно.

• Через фронтальный канал передается краткоживущий одноразовый код, а не access-токен, что снижает утечки через историю браузера, referrer и redirect-логи.
• Каждый публичный и конфиденциальный клиент создает высокоэнтропийный verifier для каждого запроса, отправляет его S256 challenge и требует от сервера авторизации привязать код к этому challenge.
• Конфиденциальный клиент дополнительно аутентифицируется на token endpoint, а публичный не полагается на встроенный секрет; аутентификация клиента не заменяет PKCE.
• Точно зарегистрированные redirect URI, безопасное хранение состояния транзакции и подходящее хранилище токенов остаются обязательными вокруг обмена кода.

PKCE связывает запрос авторизации с обменом токена и не дает обменять украденный или внедренный код без verifier исходного клиента.

• Клиент отправляет S256 challenge от свежего высокоэнтропийного verifier и предъявляет сам verifier только на token endpoint.
• PKCE может защищать от CSRF, когда клиент удостоверился в поддержке PKCE сервером авторизации и в привязке возвращенного кода к исходному challenge без возможности downgrade.
• State остается полезен для передачи или корреляции состояния приложения, а непредсказуемый проверяемый state все еще нужен, если надежную привязку PKCE challenge гарантировать нельзя.
• PKCE рекомендован конфиденциальным и публичным клиентам, но не заменяет проверку redirect URI, аутентификацию конфиденциального клиента и защиту уже выпущенных токенов.

OpenID Connect добавляет стандартный слой аутентификации, позволяющий клиенту подтвердить личность пользователя через ID token и метаданные провайдера.

• OAuth access-токены разрешают доступ к API, и клиент не должен трактовать их как доказательство входа пользователя.
• ID token содержит предназначенные клиенту claims, включая issuer, subject, audience, время выпуска и срок действия.
• Клиент проверяет nonce, если он использовался, чтобы связать ID token с запросом авторизации и предотвратить повтор между login-транзакциями.
• Discovery и JWKS endpoints стандартизируют конфигурацию провайдера и получение ключей подписи, но issuer все равно задается из доверенной конфигурации.

Resource server рассматривает RFC 9068 как типизированный профиль access-токена, а не принимает любой JWT с валидной подписью.

• В защищенном JOSE-заголовке требуется `typ` со значением `at+jwt`; OIDC ID token явно отклоняется на API, даже если его подпись валидна.
• Подпись проверяется доверенными ключами issuer и разрешенным алгоритмом, а неподписанные токены, путаница алгоритмов и ключи ненастроенного issuer отклоняются.
• Проверяется настроенный `iss`, наличие этого resource server в `aud`, обязательный неистекший `exp`, значение `nbf` при наличии с ограниченным clock skew, а также `client_id` и остальные обязательные claims профиля.
• Затем применяются scopes и ресурсная политика операции; ID token предназначен клиенту для аутентификации пользователя, а не API для авторизации доступа.

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

• Resource server отправляет ссылочный токен на RFC 7662 introspection endpoint или проверяет доверенный кэш.
• Отзыв и изменения политики вступают в силу быстро, а JWT обычно действует до истечения срока, если не добавлен отдельный deny list.
• JWT сокращает обращения к серверу авторизации и подходит распределенным API, но устаревание claims и утечка их содержимого требуют короткого срока и точного audience.
• Решение должно учитывать кэширование introspection, режим отказа, срок токена и пропускную способность сервера авторизации.

Я помещаю непрозрачный высокоэнтропийный идентификатор сессии в cookie с флагами Secure и HttpOnly, а идентичность и авторизацию храню на сервере.

• SameSite=Lax является практичным значением по умолчанию, а cross-site потоки требуют обоснованного SameSite=None с Secure и отдельной защиты от CSRF.
• После входа и изменения привилегий ротирую идентификатор против session fixation, а при logout и административном отзыве аннулирую его.
• Idle и absolute timeouts ограничивают ущерб от кражи, а для оплаты или восстановления аккаунта окно повторной аутентификации короче.
• Cookie получает минимально возможные Domain и Path, а изменяющие состояние запросы используют CSRF-токены или проверку Origin.

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

• Сервер авторизации хранит семейство токенов или хеш ссылки и атомарно инвалидирует предъявленный токен при выпуске следующего.
• Повторное использование уже инвалидированного элемента отзывает семейство или затронутую сессию и запускает уведомление пользователя или security-команды.
• Ротация должна учитывать конкурентные запросы, иначе два легитимных refresh могут выглядеть как replay.
• Привязанные к отправителю токены вроде DPoP или mTLS дополнительно снижают риск повтора, а короткие access-токены ограничивают оставшееся окно.

Я использую RBAC для стабильных рабочих функций и добавляю ABAC, когда решения зависят от атрибутов ресурса, субъекта или среды, которые трудно чисто выразить ролями.

• RBAC легко проверять для ролей support-agent или billing-admin, но множество исключений приводит к взрыву числа ролей.
• ABAC выражает условия по арендатору, классу данных, владению, состоянию устройства или рабочему времени через policy engine вроде OPA.
• Издатели атрибутов и пути их изменения становятся границами доверия, поэтому влияющим на привилегии атрибутам нужны контролируемая схема и аудит.
• Я сохраняю default deny и тестирую политики разрешенными и запрещенными случаями, потому что гибкий синтаксис может скрыть слишком широкий доступ.

ReBAC подходит коллаборативным системам, где доступ следует графу отношений вроде owner, editor, участника команды, родительской папки или организации.

• Разрешение на документ может наследоваться от членства в команде, имеющей viewer-доступ к содержащему его проекту.
• Zanzibar-подобные системы, OpenFGA и SpiceDB согласованно вычисляют tuples и преобразования отношений между сервисами.
• Модель должна определить наследование, циклы, удаление, изоляцию арендаторов и максимальную стоимость обхода, чтобы исключить неожиданные разрешения и дорогие проверки.
• Для контекстных условий я все равно использую атрибуты, а для грубого администрирования роли, не пытаясь поместить все правила в граф.

Я выдаю каждому ворклоаду краткоживущую идентичность, привязанную к его runtime service account, и аутентифицирую межсервисные вызовы через mTLS или подписанные workload-токены.

• SPIFFE ID и SPIRE могут выпускать ротируемые X.509 SVID по аттестованным атрибутам ворклоада вместо статических общих секретов.
• Service mesh может проверять peer identity и шифрование, но право идентифицированного вызывающего на операцию все равно решает авторизация приложения.
• Для Kubernetes service account нужны проецируемые краткоживущие токены с ограниченным audience, а не устаревшие долгоживущие secrets.
• Выпуск сертификатов, ротация trust bundle, точность часов и экстренный отзыв требуют мониторинга, потому что идентичность зависит от этого control plane.