Безопасная конфигурация
В данном разделе представлены рекомендации клиентам по настройкам безопасности в сервисах Yandex Cloud, а также использованию дополнительных средств защиты данных.
Пароли по умолчанию
Сервисы Yandex Cloud не имеют учетных данных по умолчанию. Во всех сервисах клиент самостоятельно назначает пароли пользователей и другие секреты. Однако ПО в зоне ответственности клиента, установленное на виртуальных машинах или внутри контейнеров, может содержать начальные значения учетных данных, которые требуется сменить (например, логин admin
и пароль admin
).
Для автоматической проверки учетных данных рекомендуется использовать платные сканеры безопасности или следующие бесплатные инструменты:
Управление инфраструктурой
В рамках IaaS-сервисов клиент несет ответственность за конфигурацию своих ресурсов.
Для проверки соответствия хостов стандартам безопасности и лучшим практикам рекомендуем использовать бесплатную утилиту OpenSCAP
Серийная консоль
На ВМ доступ к серийной консоли по умолчанию отключен. Включать его не рекомендуется в целях безопасности. Риски использования серийной консоли перечислены в разделе Начало работы с серийной консолью документации Yandex Compute Cloud.
При работе с серийной консолью:
- Необходимо убедиться, что критичные данные не попадают в вывод серийной консоли.
- При включенном доступе к серийной консоли по SSH следует убедиться, что работа с учетными данными и пароль для локального входа в операционную систему соответствуют стандартам регуляторов. Например, в инфраструктуре для хранения данных платежных карт пароль должен соответствовать требованиям стандарта PCI DSS: содержать как буквы, так и цифры, иметь длину не менее 7 символов и меняться не реже чем каждые 90 дней.
Примечание
Согласно стандарту PCI DSS, доступ к ВМ через серийную консоль считается «неконсольным» (non-console), и Yandex Cloud применяет для него шифрование TLS.
Подготовка образов виртуальных машин
При развертывании ВМ рекомендуется:
- Подготовить образ ВМ, настройки системы в котором соответствуют вашей политике информационной безопасности. Создать образ можно с помощью Packer, см. раздел Начало работы с Packer.
- Использовать этот образ для создания ВМ или группы ВМ.
- В информации о ВМ убедиться, что для создания диска использовался именно этот образ.
Terraform
Terraform позволяет управлять облачной инфраструктурой с помощью файлов конфигураций. При изменении файлов Terraform автоматически определяет, какая часть вашей конфигурации уже развернута, что следует добавить или удалить. Подробнее в разделе Начало работы с Terraform.
В файлах конфигураций Terraform не рекомендуется указывать приватную информацию: пароли, секреты, персональные данные, данные платежных систем и др. Вместо этого необходимо использовать сервисы для хранения и использования в конфигурации секретов, например: HashiCorp Vault из Yandex Cloud Marketplace или Yandex Lockbox (для передачи секретов в целевой объект без использования Terraform).
Если все же требуется указать приватную информацию в конфигурации, необходимо принять меры безопасности:
-
Указывать для приватной информации параметр sensitive = true
, чтобы отключить ее вывод в консоль при выполнении командterraform plan
,terraform apply
. -
Использовать terraform remote state
. Рекомендуется загружать состояние Terraform в Yandex Object Storage (см. раздел Загрузка состояний Terraform в Object Storage), а также настроить блокировку конфигурации с помощью Yandex Managed Service for YDB для предотвращения одновременного редактирования администраторами (см. пример настройки ). -
Использовать механизм передачи секретов в Terraform через env
вместо plain text либо использовать встроенную возможность Yandex Key Management Service по шифрованию данных в Terraform (с помощью отдельного файла с приватными данными) (подробнее о данной технике ).Об обеспечении безопасности Object Storage читайте ниже в подразделе Object Storage.
Важно
После развертывания конфигурации файл конфигурации с приватными данными можно удалить.
Проверяйте ваши Terraform-манифесты с помощью Checkov
Контроль целостности
Множество стандартов по ИБ требуют выполнения контроля целостности критичных файлов. Для этого можно использовать бесплатные host-based решения:
В Cloud Marketplace также доступны платные решения — например, CloudGuard.
Атаки по побочным каналам
Для наилучшей защиты от атак по побочным каналам процессора (так называемым атакам side-channel на уровне CPU, например Spectre или Meltdown) необходимо:
- Использовать полноядерные ВМ, то есть ВМ с долей ядра CPU в 100 процентов.
- Использовать ВМ с четным числом ядер (2 ядра, 4 ядра и т. д.).
- Устанавливать обновления операционной системы и ядра, которые обеспечивают защиту от атак с использованием побочных каналов (например, Kernel page-table isolation для Linux
, приложения, собранные с Retpoline ).
Для размещения нагрузок, наиболее критичных с точки зрения безопасности, рекомендуется использовать выделенные хосты (dedicated hosts).
Подробнее
Object Storage
Шифрование данных
При использовании сервиса Object Storage необходимо настроить шифрование критичных данных как в состоянии покоя (at rest), так и при передаче (it transit). Object Storage предоставляет встроенные функции шифрования. Подробнее см. в разделе Шифрование данных и управление ключами.
Ограничение доступа
Рекомендуется назначать минимальные роли на бакет с помощью Yandex Identity and Access Management и дополнять/детализировать их с помощью BucketPolicy (например, для ограничения доступа к бакету по IP-адресам, выдачи гранулярных прав на объекты и т. д.).
Проверка доступа к ресурсам Object Storage происходит на трех уровнях:
- Проверки сервиса Identity and Access Management.
- Политики доступа (bucket policy).
- Списки управления доступом (ACL).
Порядок проверки:
- Если запрос прошел проверку Identity and Access Management, к нему применяется проверка политики доступа.
- Проверка правил политики доступа происходит в следующем порядке:
- Если запрос подошел хотя бы под одно из правил
Deny
, то доступ будет запрещен. - Если запрос подошел хотя бы под одно из правил
Allow
, то доступ будет разрешен. - Если запрос не подошел ни под одно из правил, то доступ будет запрещен.
- Если запрос подошел хотя бы под одно из правил
- Если запрос не прошел проверку Identity and Access Management или политики доступа, то применяется проверка доступа через ACL объекта.
В сервисе Identity and Access Management бакет наследует такие же права доступа, как у каталога и облака, в котором он находится. Подробнее об этом в разделе Наследование прав доступа на бакет системными группами Yandex Cloud. Поэтому не рекомендуется выдавать роли на каталог для доступа к Object Storage. Рекомендуется выдавать только минимально необходимые роли на определенные бакеты или объекты сервиса Object Storage.
Политики доступа используются для дополнительной защиты данных, например для ограничения доступа к бакету по IP-адресам, выдачи гранулярных прав на объекты и т. д.
ACL позволяет предоставить доступ к объекту в обход проверок Identity and Access Management и политик доступа. Рекомендуем установить строгие ACL на бакеты.
Защита от удаления и резервирование версий
При обработке в бакетах критичных данных необходимо обеспечить их защиту от удаления и резервирование версий. Это возможно сделать с помощью механизмов версионирования и управления жизненным циклом.
Версионирование бакета — это возможность хранить историю версий объекта. Каждая версия является полной копией объекта и занимает соответствующий объем в Object Storage. С помощью управления версиями вы можете защитить ваши данные как от непреднамеренных действий пользователя, так и от сбоев приложений.
В случае удаления/модификации объекта с включенным версионированием на самом деле создается новая версия объекта с новым id. В случае удаления объект становится недоступен для чтения, но его версия хранится и подлежит восстановлению.
Настройка версионирования описана в разделе Версионирование бакета документации Object Storage.
Механизм управления жизненным циклом позволяет задать политику удаления либо перемещения данных, например:
- Удалять все нетекущие версии объектов (тип условия: NoncurrentVersionExpiration) по истечении указанного количества дней после того, как версия стала нетекущей.
- Удалять все текущие версии объектов (тип условия: Expiration) по истечении указанного количества дней после загрузки.
Настройка жизненного цикла описана в разделах Жизненные циклы объектов в бакете и Конфигурация жизненных циклов объектов в бакете документации Object Storage.
Срок хранения критичных данных в бакете определяется требованиями ИБ компании клиента и требованиями стандартов ИБ. Например, стандарт PCI DSS устанавливает, что аудитные логи должны храниться не менее одного года, при этом как минимум три месяца должны быть немедленно доступны онлайн.
Аудит
При использовании сервиса Object Storage для хранения критичных данных необходимо включать логирование действий с бакетами, а также настроить для объектов с логами механизм версионирования и жизненный цикл. Подробнее в разделе Механизм логирования действий с бакетом документации Object Storage.
Дополнительно возможен анализ логов Object Storage при помощи Yandex DataLens.
Управление кросс-доменными запросами (CORS)
При необходимости кросс-доменных запросов к объектам в бакетах клиенту необходимо настроить политику CORS (Cross-origin resource sharing) в соответствии с требованиями ИБ компании клиента. Подробнее в разделе CORS-конфигурация бакетов документации Object Storage.
Managed Services for Databases
Рекомендуется запретить доступ из интернета к базам данных, которые содержат критичные данные, в частности данные PCI DSS или персональные данные. Настройте группы безопасности, чтобы разрешить подключение к СУБД только с определенных IP-адресов, см. инструкцию в разделе Создать группу безопасности. Указать группу безопасности можно в настройках кластера или при его создании, в блоке сетевых настроек.
Не следует без необходимости включать доступ к базам данных с критичными данными из консоли управления, DataLens и других сервисов. Доступ к БД из консоли управления может потребоваться для отправки SQL-запросов в БД и визуализации структуры данных; доступ из DataLens может потребоваться для анализа и визуализации данных. Эти доступы осуществляются через служебную сеть Yandex Cloud, с аутентификацией и использованием шифрования TLS. Включить и отключить доступы из консоли управления, DataLens или других сервисов можно в настройках кластера или при его создании, в блоке дополнительных настроек.
Yandex Cloud Functions и Yandex API Gateway
Использование сервисного аккаунта
Для получения IAM-токена в ходе выполнения функции необходимо назначить для функции сервисный аккаунт, см. инструкцию в разделе Получение IAM-токена сервисного аккаунта с помощью функции. В этом случае функция получит IAM-токен с помощью встроенных механизмов Yandex Cloud, без необходимости передачи каких-либо секретов в функцию извне.
Контроль доступа к функции
Во всех случаях, когда явно не требуется использование публичных функций, рекомендуется использовать приватные функции. Подробнее о настройке доступа к функциям см. в разделе Сделать функцию приватной.
Атаки по побочным каналам в Cloud Functions
Хосты и гипервизоры, на которых выполняются Cloud Functions, содержат все необходимые обновления для защиты от атак по побочным каналам процессора (side-channel attacks). Однако следует иметь в виду, что функции различных клиентов не изолированы по ядрам и формально существует поверхность атаки со стороны функции одного пользователя на функцию другого пользователя. Специалисты по ИБ Yandex Cloud считают сценарий атаки по побочным каналам в контексте функций маловероятным, однако следует учитывать данный риск, в частности, при построении модели угроз и анализа рисков для инфраструктуры PCI DSS.
Особенности синхронизации времени в функциях
Сервис Cloud Functions не гарантирует синхронизацию времени перед выполнением или в процессе выполнения запросов функциями. Чтобы получить лог выполнения функции с точными метками времени на стороне Cloud Functions, следует выводить лог в stdout. Также клиент может самостоятельно принимать логи выполнения функции и помечать их меткой времени на принимающей стороне, взятой из источника времени, синхронизированного с Yandex Cloud. Подробнее о синхронизации времени см. в разделе Настройка синхронизации часов с помощью NTP документации Compute Cloud.
Управление HTTP-заголовками в функциях
Если функция вызывается для обработки HTTP-запроса, то возвращаемый результат должен представлять собой JSON-документ, содержащий код ответа HTTP, заголовки ответа и содержимое ответа. Cloud Functions автоматически обработает этот JSON, и пользователь получит данные в виде стандартного HTTP-ответа.
Клиенту необходимо самостоятельно управлять заголовками ответа в соответствии с требованиями регуляторов и модели угроз. Инструкцию по обработке HTTP-запроса см. в разделе Вызов функции с помощью HTTP документации Cloud Functions.
Managed Service for YDB
Работа с данными
Запрещается в качестве названий базы данных, таблиц, столбцов, директорий и т.д. использовать конфиденциальные данные, в частности данные PCI DSS. Запрещается отправлять данные PCI DSS в Managed Service for YDB (как Dedicated, так и Serverless) в открытом виде. Перед отправкой данных их необходимо шифровать на уровне приложения, для чего можно воспользоваться сервисом Key Management Service или любым другим способом, соответствующим стандарту PCI DSS. Для данных, срок хранения которых известен заранее, рекомендуется настроить функцию Time To Live
Защита от SQL-инъекций
При работе с базой данных для защиты от SQL-инъекций необходимо использовать параметризованные подготовленные запросы
Сетевой доступ
При работе с базой данных в режиме Dedicated рекомендуется использовать ее внутри Yandex Virtual Private Cloud и не открывать к ней доступ из интернета. В режиме Serverless база данных является доступной из интернета, что необходимо учитывать, в частности, при моделировании угроз при построении инфраструктуры PCI DSS. Подробнее о режимах работы см. в разделе Serverless и Dedicated режимы работы документации Managed Service for YDB.
При настройке доступа к БД следует использовать принцип минимальных привилегий.
Резервные копии
При использовании механизма создания резервных копий по требованию необходимо убедиться, что данные резервной копии должным образом защищены.
При самостоятельном создании резервных копий в сервисе Object Storage необходимо следовать рекомендациям подраздела Object Storage выше — например, использовать встроенные возможности шифрования бакетов.
Yandex Container Registry и Yandex Container Solution
Не рекомендуется использовать привилегированные контейнеры для запуска нагрузок, обрабатывающих недоверенный пользовательский ввод. Привилегированные контейнеры следует использовать для целей администрирования ВМ или других контейнеров. Рекомендуется использовать политики удаления для автоматического удаления устаревших образов контейнеров.
Рекомендуется использовать сканер уязвимостей в образах, встроенный в Yandex Container Registry.
Yandex Certificate Manager
Сервис Certificate Manager позволяет управлять TLS-сертификатами для API-шлюзов сервиса API Gateway, а также для сайтов и бакетов в Object Storage. Сервис Yandex Application Load Balancer интегрирован с Certificate Manager для хранения и установки сертификатов. Рекомендуется использовать Certificate Manager для получения и автоматической ротации сертификатов.
При работе с TLS в приложении рекомендуется ограничивать список доверенных корневых сертификатов (root CA). При использовании технологий certificate pinning следует учитывать, что сервис Let’s Encrypt выдает сертификаты со сроком действия в 90 дней