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

Модель совместной ответственности разделяет обязанности по безопасности между облачным провайдером и клиентом.

• Провайдер защищает физические площадки, оборудование и базовую управляемую инфраструктуру.
• Клиент защищает учётные записи, данные, конфигурацию workloads и доступ в соответствии с используемыми сервисами.
• Точная граница зависит от модели сервиса, поэтому перенос в облако не передаёт провайдеру всю ответственность за безопасность.

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

• В IaaS клиент обычно защищает гостевую операционную систему, приложения и сетевую конфигурацию.
• В PaaS провайдер управляет большей частью runtime и ОС, но клиент по-прежнему защищает код, данные и настройки сервиса.
• В SaaS клиент в основном управляет пользователями, правами, обработкой данных, конфигурацией tenant и подключёнными устройствами.

Authentication подтверждает identity, а authorization решает, какие действия эта identity может выполнять над какими ресурсами.

• Пароли, MFA, сертификаты и federated sign-in являются механизмами authentication.
• IAM policies, роли и resource policies выражают решения authorization.
• Успешный вход не даёт широкого доступа, если его не разрешает конфигурация authorization.

IAM user представляет долгоживущую identity, а role принимается для получения временных разрешений на время сессии.

• Roles предпочтительны для workloads и cross-account доступа, потому что не требуют встроенных долгоживущих access keys.
• У role есть trust policy, определяющая, кто может её принять, и permission policies, определяющие доступные действия.
• Доступ людей обычно федеративно передаётся из identity provider в roles вместо отдельных облачных users.

IAM policy указывает, разрешены или запрещены выбранные действия над выбранными ресурсами при необязательных условиях.

• Effect выражает Allow или Deny, а Action называет API-операции.
• Resource ограничивает объекты, к которым применяется statement.
• Condition ограничивает доступ контекстом, например исходной сетью, тегами ресурса, временем или состоянием MFA.

Least privilege означает выдачу identity только тех действий, ресурсов и условий, которые нужны для текущей задачи.

• Разрешения должны использовать конкретные actions и scopes ресурсов вместо широких wildcards там, где сервис это поддерживает.
• Временное повышение прав безопаснее постоянного административного доступа для редких задач.
• Access reviews и данные об использовании помогают удалять разрешения, которые больше не нужны.

Explicit deny имеет приоритет над allow, а доступ без применимого allow запрещён по умолчанию.

• В одном решении могут участвовать identity, resource, organization, boundary и session policies.
• Широкий allow не может обойти совпавший explicit deny.
• Permission boundaries и organizational guardrails ограничивают максимум прав, но сами по себе не предоставляют доступ.

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

• Она особенно важна для привилегированных пользователей, владельцев billing и root- или break-glass identities.
• Устойчивые к фишингу факторы вроде аппаратных ключей безопасности защищают сильнее SMS-кодов.
• MFA должна дополнять короткие сессии, conditional access и least privilege, а не оправдывать избыточные права.

Временные credentials автоматически истекают и выдаются с узким scope сессии, сокращая время действия украденного доступа.

• Roles и federation создают временные credentials без хранения постоянного секрета в application code.
• Короткий срок ограничивает persistence после утечки credential.
• Session context и role assumptions также улучшают auditability по сравнению с общими static keys.

Workload должен использовать предоставляемую платформой service identity или role с временными credentials вместо hardcoded user key.

• Virtual machines, containers и serverless functions получают credentials через execution identity.
• Role policy должна разрешать только API и ресурсы, нужные workload.
• Metadata и token endpoints нужно защищать от недоверенного кода и путей request forgery.

Identity federation позволяет внешнему identity provider аутентифицировать пользователей и обменивать эту identity на временный облачный доступ.

• Стандарты SAML и OpenID Connect передают сведения об identity и claims.
• Централизованная federation поддерживает единый lifecycle сотрудников, MFA policy и процесс отключения учётной записи.
• Облачные roles сопоставляют группы или claims с разрешениями без создания долгоживущего user в каждом account.

IAM Access Analyzer помогает выявлять ресурсы, доступные внешним principals, и анализировать разрешения на предмет чрезмерного доступа.

• Он проверяет поддерживаемые resource policies и trust relationships на доступ за пределами заданной зоны доверия.
• Findings всё равно требуют проверки, потому что часть cross-account или public access может быть намеренной.
• Policy validation и access activity также помогают писать более узкие разрешения.

Encryption at rest защищает хранимые данные, а encryption in transit защищает данные при передаче между системами.

• Шифрование дисков, баз данных, object storage и backups является распространённым at-rest control.
• TLS является стандартным control для данных, передаваемых по сети.
• Нужны оба controls, потому что они защищают разные точки, и ни один не заменяет access control.

TLS шифрует трафик, аутентифицирует сервер через сертификаты и защищает сообщения от незаметного изменения при передаче.

• Проверка сертификата подтверждает, что клиент подключился к ожидаемой service identity.
• Современные конфигурации отключают устаревшие версии протокола и слабые cipher suites.
• TLS защищает соединение, но не решает, имеет ли аутентифицированный caller право доступа к данным.

Envelope encryption шифрует данные data key, а затем шифрует этот data key отдельным key-encryption key.

• Data keys эффективно шифруют большие payloads рядом с workload.
• KMS защищает key-encryption key и управляет операциями, раскрывающими data keys.
• Зашифрованный data key можно хранить рядом с ciphertext без раскрытия plaintext key.

Облачный KMS создаёт и защищает криптографические ключи и управляет аудируемыми криптографическими операциями с ними.

• IAM и key policies определяют, кто может encrypt, decrypt, sign или администрировать key.
• Managed services интегрируются с KMS для шифрования хранилищ без раскрытия key material приложениям.
• KMS управляет криптографическими ключами, а пароли и API tokens должны храниться в secrets-management service.

Provider-managed keys упрощают эксплуатацию, а customer-managed keys дают больше контроля над policy, lifecycle, audit и разделением обязанностей.

• Provider-managed keys создаются и обслуживаются облачным сервисом с ограниченной настройкой клиентом.
• Customer-managed keys поддерживают собственные permissions, cross-account use, отключение и настройки rotation.
• Дополнительный контроль также создаёт ответственность за доступность key, корректность policy, стоимость и управление lifecycle.

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

• После ротации новые операции шифрования используют текущий key material.
• Старый key material должен оставаться доступным, пока зашифрованные им данные нужно расшифровывать.
• Ротация не исправляет автоматически чрезмерные key permissions и не заменяет осознанный отзыв скомпрометированного ключа.

Разделение администрирования ключа и криптографического использования не позволяет одной identity одновременно менять controls ключа и свободно расшифровывать данные.

• Администраторы могут управлять aliases, rotation или policy без decrypt permission.
• Workloads могут выполнять encrypt или decrypt без права менять или удалять key.
• Такое разделение поддерживает least privilege, dual control и более ясные audit trails.

Encryption обратимо при наличии подходящего key, а криптографический hash спроектирован как односторонний digest.

• Encryption защищает confidentiality, когда авторизованным пользователям нужно восстановить исходные данные.
• Hashes поддерживают integrity checks и проверку паролей при использовании подходящей salted password-hashing function.
• Обычный быстрый hash не подходит для хранения паролей, потому что атакующие могут эффективно проверять догадки.