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

SAML обменивается XML assertions и распространён в enterprise browser SSO, а OpenID Connect добавляет identity к OAuth 2.0 через JSON-based tokens и современные application flows.

• SAML service providers доверяют assertions, выпущенным identity provider после browser-based authentication.
• OIDC clients проверяют ID tokens и используют authorization flows для web, mobile, CLI и workload federation.
• Оба требуют строгой проверки issuer, audience, signature, lifetime и claims, а не доверия только из-за успешного redirect.

IAM Identity Center централизует workforce access к AWS accounts и applications через federated identities и временные role sessions.

• Permission sets определяют переиспользуемый доступ, который provision как roles в выбранных accounts.
• Group-based assignments связывают lifecycle identity provider с account permissions без отдельных IAM users.
• Централизация улучшает review и revocation, но permission sets, assignments, session duration и break-glass access всё равно требуют governance.

SCIM автоматизирует provisioning, обновление и deprovisioning users и groups из identity source в подключённый сервис.

• Изменения joiner, mover и leaver распространяются без ручного сопровождения облачных identities.
• Stable identifiers и group mappings нужно проектировать внимательно, чтобы избежать duplicate users и непреднамеренного доступа.
• Тесты и monitoring deprovisioning важны, потому что ошибка synchronization может оставить stale privileges активными.

Claims должны сопоставлять аутентифицированные groups и attributes с узко определёнными roles через явные и стабильные правила.

• Issuer, audience, group и assurance claims должны приходить из доверенного namespace identity provider.
• Широкое pattern matching по mutable attributes может выдать неожиданные roles.
• Mapping требует default-deny path, change review и тестов как разрешённых, так и запрещённых role assignments.

SCP определяет максимум доступных permissions для member accounts, но сама по себе не предоставляет ни одного permission.

• Effective access всё равно требует allow из подходящей identity или resource policy.
• Explicit SCP deny блокирует совпавшие actions, даже если administrator policy разрешает их.
• SCP действует на principals в member accounts по правилам AWS Organizations, а management account находится вне её scope ограничений.

Deny-list SCP сохраняют гибкость сервисов, блокируя выбранные high-risk actions, а allow-list SCP дают более строгий контроль, разрешая только approved services и actions.

• Deny list проще внедрить, но он может пропустить новые services или рискованные actions, которые не были предусмотрены.
• Allow list сокращает этот пробел, но создаёт больше operational friction и сопровождения при adoption сервисов.
• Обе стратегии требуют staged rollout, ownership исключений и тестов automation и break-glass paths.

Permission boundary ограничивает максимум identity-policy permissions, доступных user или role, созданным delegated administrator.

• Boundary не предоставляет access, поэтому identity всё равно нужен применимый allow policy.
• Delegated teams могут создавать roles внутри boundary без получения actions за пределами approved ceiling.
• Governance boundary должна запрещать creators удалять boundary или передавать service role без ограничения.

Effective permissions ограничиваются каждым применимым guardrail и требуют allow в подходящей granting policy без совпавшего explicit deny.

• Identity policies предоставляют principal возможные permissions.
• SCP, permission boundaries и session policies сокращают максимум доступного набора в своём scope.
• Resource policies и особые service rules тоже участвуют, поэтому troubleshooting требует полного request context, а не одного документа.

Безопасная cross-account role имеет узкий trust, узкие permissions, короткие sessions и прослеживаемое assumption известной principal.

• Trust policy должна называть approved account, role, organization или federated claims вместо broad principal.
• Permission policies должны ограничивать actions и resources целью integration.
• CloudTrail, source identity, session tags и conditions MFA или external ID улучшают attribution и control там, где применимы.

External ID позволяет customer потребовать от third-party deputy передать customer-specific значение при assumption role.

• Third party генерирует или назначает значение, отличающее role одного customer от запроса другого customer.
• Trust policy проверяет это значение через condition sts:ExternalId.
• Оно не является паролем и не заменяет specific trusted principal, least privilege и monitoring.

ABAC использует principal, resource, request и environment attributes для переиспользуемых access rules вместо перечисления каждого resource.

• Совпадающие project или environment tags позволяют одной policy обслуживать много teams и новых resources.
• Создание и мутация tags становятся security-sensitive operations, требующими validation и ownership.
• ABAC лучше всего работает с controlled taxonomy, default deny и запретом principals назначать самим себе privilege-bearing tags.

Session tags переносят attributes во временные role sessions для authorization и audit, а source identity сохраняет исходное значение identity через поддерживаемые role assumptions.

• Session tags управляют ABAC conditions вроде совпадения project или cost center.
• Transitive tags сохраняются через role chaining при явной configuration.
• Tag и source-identity claims должны выпускаться trusted mappings, потому что caller с выбором privileged values может расширить access.

Архитектура KMS разделяет key administration, cryptographic use, service integration и audit на отдельные контролируемые пути.

• Administrators управляют lifecycle и policy без автоматического decrypt access.
• Workloads вызывают encrypt, decrypt или data-key operations через аутентифицированные identities.
• CloudTrail записывает management и cryptographic API activity, а dependent services требуют явной совместимости key policy.

KMS authorization зависит от key policy и может делегировать permission management в IAM, поэтому нужно оценивать оба слоя.

• Key policy устанавливает principals или account delegation paths, которым доверяет key.
• IAM policies предоставляют operations только тогда, когда key policy включает этот authorization path.
• Grants, SCP, conditions и explicit denies дополнительно меняют effective decision.

Envelope encryption использует KMS для защиты небольших data keys, а локальная symmetric cryptography эффективно обрабатывает большие payloads.

• Fresh data key ограничивает cryptographic reuse по design приложения.
• Encrypted data key хранится рядом с ciphertext и раскрывается только authorized callers.
• Паттерн сокращает KMS request volume, latency и exposure plaintext keys при сохранении централизованного key control.

KMS grants полезны для scoped programmatic delegation key operations без постоянного расширения key policy.

• Интегрированные AWS services часто используют grants для authorization resource или operation lifecycle.
• Grants ограничиваются operations и encryption context и удаляются независимо.
• Они всё равно требуют monitoring, потому что накопленные или stale grants сохраняют неожиданный access.

Encryption context связывает несекретную аутентифицированную metadata с cryptographic operation и может требоваться conditions key policy.

• Тот же context нужно передать для decrypt созданного с ним ciphertext.
• Policies ограничивают decrypt use tenant, resource ARN или application context.
• Context может появляться в logs и не шифруется, поэтому он не должен содержать secrets или sensitive plaintext.

Multi-Region keys поддерживают связанный key material в нескольких regions для portable ciphertext и disaster recovery, но расширяют administrative и usage surface ключа.

• Replicas имеют независимые policies, aliases и operational states, требующие согласованного governance.
• Они уменьшают необходимость re-encryption данных при regional failover в поддерживаемых designs.
• Replication нужно ограничивать требуемыми regions, потому что каждая replica создаёт новое место drift permissions и monitoring.

CloudHSM выбирают, когда организации нужен dedicated HSM control, прямые cryptographic interfaces или требования, не покрываемые managed KMS abstraction.

• Customer управляет HSM users, availability, backups, clustering и большей частью operational lifecycle.
• KMS даёт более простые service integration, policy management, scaling и audit для большинства cloud encryption задач.
• Выбор должен следовать конкретным key-custody, algorithm, compliance или interoperability требованиям, потому что HSM ownership значительно усложняет эксплуатацию.

Imported key material даёт организации контроль над исходным material и его expiry или deletion, одновременно добавляя ответственность за lifecycle и availability.

• Потеря external material может исключить recovery, если imported material истечёт или будет удалён.
• Rotation и backup processes отличаются от полностью KMS-generated material и должны быть документированы.
• Import material не обходит KMS key policies, IAM controls, logging и ограничения service compatibility.