[Документация Yandex Cloud](../../index.md) > [Безопасность в Yandex Cloud](../index.md) > [Рекомендации по защите облачной инфраструктуры](index.md) > Чеклист предотвращения атак программ-шифровальщиков # Чеклист предотвращения атак программ-шифровальщиков Этот раздел содержит набор требований безопасности для защиты облачной инфраструктуры Yandex Cloud от атак программ-шифровальщиков (ransomware). Шифровальщики — один из наиболее распространенных и разрушительных видов кибератак: злоумышленники шифруют данные жертвы и требуют выкуп за их восстановление. В облачных средах атаки шифровальщиков могут затрагивать объектные хранилища, диски виртуальных машин, базы данных и резервные копии. ## Настроена двухфакторная аутентификация для привилегированных аккаунтов {#enable-mfa} Аккаунты с привилегированными ролями — `admin`, `editor`, `resource-manager.admin` и аналогичными — должны использовать [многофакторную аутентификацию (MFA)](../../organization/concepts/mfa.md). Компрометация привилегированного аккаунта без MFA позволяет злоумышленнику немедленно получить доступ ко всем ресурсам организации и удалить резервные копии перед запуском шифрования. ## Учетные записи Яндекс ID используются только в исключительных случаях {#limit-yid} Личные аккаунты Яндекс ID не управляются корпоративными политиками безопасности: для них нельзя принудительно включить MFA, задать политику паролей или отозвать доступ централизованно. Для доступа к облачным ресурсам используйте [федеративные аккаунты](../../iam/concepts/users/accounts.md#saml-federation) через Yandex Identity Hub. Аккаунты Яндекс ID допустимы только для технических нужд (например, первоначальная настройка организации) и должны быть задокументированы как исключения. ## Сервисным аккаунтам назначены минимальные привилегии {#limit-privileges} Сервисные аккаунты с избыточными правами (например, с ролью `editor` или `admin` на уровне организации или облака) становятся целью для шифровальщиков: компрометация такого аккаунта позволяет злоумышленнику удалить все резервные копии и зашифровать данные. [Назначайте](../../iam/operations/sa/assign-role-for-sa.md) сервисным аккаунтам только те роли, которые необходимы для выполнения функций, и только на нужном уровне ресурсной иерархии (на каталог, а не облако). ## Отслеживается дата последней аутентификации сервисного аккаунта и последнего использования ключей доступа {#track-last-used} Неиспользуемые статические ключи доступа и сервисные аккаунты, которые давно не проходили аутентификацию, представляют риск: злоумышленник может использовать забытые учетные данные для получения доступа. Рекомендуется отслеживать дату последней аутентификации сервисных аккаунтов и использования ключей доступа. Удаляйте или деактивируйте ключи и аккаунты, не использовавшиеся более 90 дней. По возможности следует использовать [эфемерные ключи](../../iam/concepts/authorization/ephemeral-keys.md) или временные токены через сервис [Yandex Security Token Service](../../iam/concepts/authorization/sts.md) вместо статических ключей. ## Выполняется периодическая ротация ключей сервисных аккаунтов {#rotate-keys} Статические ключи доступа сервисных аккаунтов должны регулярно ротироваться. Рекомендуемый период [ротации](../standard/authentication.md#sa-key-rotation.md) — не реже одного раза в 90 дней. Ключи без срока действия увеличивают окно возможностей для злоумышленников в случае их утечки. По возможности следует использовать [эфемерные ключи](../../iam/concepts/authorization/ephemeral-keys.md) или временные токены через сервис [Yandex Security Token Service](../../iam/concepts/authorization/sts.md) вместо статических ключей. ## В Object Storage включена блокировка версий объектов (Object Lock) {#enable-object-lock} [Object Lock](../../storage/concepts/object-lock.md) — механизм защиты объектов в Yandex Object Storage от удаления и перезаписи на заданный период. При включенном Object Lock злоумышленник, получивший доступ к бакету, не сможет удалить или изменить защищенные объекты до истечения срока блокировки. Рекомендуемый минимальный период блокировки — 30 дней. Object Lock работает только при включенном [версионировании](../../storage/concepts/versioning.md) бакета. ## Настроено резервное копирование дисков и баз данных {#configure-backup} Для всех критичных ресурсов должно быть настроено автоматическое резервное копирование: - Диски виртуальных машин: используйте [Yandex Cloud Backup](../../backup/index.md) или [расписание снимков](../../compute/operations/snapshot-control/create-schedule.md) дисков. Рекомендуемая частота — ежедневно, срок хранения — не менее 14 дней. - [Управляемые базы данных](../../managed-postgresql/operations/cluster-backups.md) (MDB): убедитесь, что автоматические резервные копии включены и срок хранения составляет не менее 14 дней. - Хранение резервных копий: резервные копии рекомендуется хранить в отдельном каталоге (folder) с ограниченным доступом, а в идеале — в отдельной облачной организации или за ее пределами. ## Включен сервис Yandex Audit Trails {#enable-audit-trails} [Audit Trails](../../audit-trails/quickstart.md) фиксирует все управляющие действия с ресурсами облака: создание и удаление ресурсов, изменение прав доступа, операции с ключами и т.д. Audit Trails должен быть включен на уровне организации или облака и настроен на запись событий в защищенный бакет Object Storage (с включенным [Object Lock](../../storage/concepts/object-lock.md)) или в лог-группу. Сам бакет с логами должен быть защищен от удаления. ## Включено логирование действий с бакетами Object Storage {#enable-logging} Помимо Audit Trails, который фиксирует управляющие события, рекомендуется включить [логирование](../../storage/operations/buckets/enable-logging.md) доступа к объектам в бакетах Object Storage. Это позволяет отслеживать операции чтения и записи объектов (`GET`, `PUT`, `DELETE`), что критично для расследования инцидентов с шифровальщиками, атакующими хранилища данных. Логи доступа следует направлять в отдельный защищенный бакет.