Меры безопасности на стороне Yandex Cloud

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

Система управления информационной безопасностьюСистема управления информационной безопасностью

В Yandex Cloud внедрена система управления информационной безопасностью (СУИБ). Она описывает политику и процедуры, которые позволяют обеспечивать информационную безопасность (ИБ) и минимизировать риски. СУИБ определяет процессы безопасной разработки, правила установки обновлений ПО, действия при возникновении инцидентов.

Служба безопасности Yandex Cloud отвечает за мониторинг и соблюдение этих процессов. Специалисты службы постоянно совершенствуют СУИБ, проводят внутренние и внешние аудиты, ежегодно оценивают риски и находят способы их снизить.

Инвентаризация активовИнвентаризация активов

В Yandex Cloud выстроен процесс инвентаризации активов, включая учет систем, обрабатывающих данные клиентов. Правила использования информации и активов, связанных с обработкой информации, записаны во внутренних документах и регулярно объясняются сотрудникам. При увольнении сотрудники возвращают все корпоративные активы. Доступы к системам отзываются автоматически.

Активы классифицируются в соответствии с требованиями законодательства. В классификации учитывается ценность информации и негативные последствия в случае несанкционированного изменения или раскрытия данных.

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

Контроль доступаКонтроль доступа

Специалисты Yandex Cloud разработали и используют политику контроля доступа. Она гарантирует, что только авторизованный персонал получает доступ к помещениям, зонам безопасности, серверным и сетевым ресурсам.

У сотрудников Yandex Cloud есть доступ только к тем ресурсам, которые они должны использовать, исходя из должностных обязанностей (Need-to-know principle), права предоставляются по принципу наименьших привилегий (Principle of least privilege).

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

Организация физической безопасностиОрганизация физической безопасности

Для обеспечения физической безопасности Yandex Cloud принимает следующие меры:

• Аппаратные ресурсы Yandex Cloud располагаются в собственных дата-центрах.
• Доступ на территорию дата-центра строго регламентирован. Гостям и сотрудникам Yandex Cloud, которые не работают в дата-центре постоянно, нужна заранее одобренная заявка.
• Объекты облачных сервисов (стойки, железные ящики, зона диагностики) находятся под постоянным видеонаблюдением.
• Записи видеокамер хранятся на серверах Яндекса в оперативном доступе не менее трех месяцев.
• Сотрудники службы безопасности Yandex Cloud следят за доступом в защищенные зоны и к стойкам сервиса.
• Данные клиентов Yandex Cloud, сохраненные на дисках, обязательно шифруются.
• Вышедшее из строя оборудование заменяется только по заявке. При выводе оборудования из эксплуатации или его повторном использовании данные с носителей удаляются.
• Неисправное оборудование хранится в сейфах в специальных сейф-пакетах. Оборудование не выносится из помещений без одобренной заявки.

Процесс безопасной разработкиПроцесс безопасной разработки

Неотъемлемой частью создания новых и развития существующих сервисов является процесс безопасной разработки (Security Development Lifecycle, SDLC). В Yandex Cloud реализованы и постоянно развиваются ключевые компоненты данного процесса.

• Обучение. Регулярное информирование сотрудников, занимающихся разработкой облачных сервисов, включает в себя:

  • Обязательный ежегодный тренинг для всех специалистов. Все разработчики должны сдать теоретический и практический тесты.
  • Ознакомление со внутренним руководством. В нем описаны базовые принципы безопасной разработки, перечень возможных уязвимостей для разного типа приложений, показаны типичные примеры уязвимого кода и исправлений. Также в нем есть информация о том, как использовать технологии, снижающие вероятность эксплуатации уязвимости (mitigations). Регламенты указывают минимальные требования к использованию криптографии, которым необходимо следовать при разработке сервисов и приложений.
  • Постоянный обмен знаниями с экспертами. Обычно на собраниях подробно обсуждаются конкретные темы, новые угрозы и методы противодействия.
  • Ежегодная игра Capture The Flag. Это возможность на практике проверить знания разработчиков в области информационной безопасности. Такой тренинг помогает командам избегать ошибок при проектировании и разработке реальных сервисов.

• Архитектурное планирование. Как и предписывает классический SDLC, перед созданием любого продукта и до изменения архитектуры действующего сервиса проводятся совещания с экспертами в области безопасности, на которых рассматриваются возможные угрозы и способы атак на сервис. В результате таких встреч сервис обретает «иммунную систему», что, вместе с другими мерами Defense in Depth, обеспечивает надежную защиту сервиса и обрабатываемых данных.

• Статический и динамический анализ. Системы статического анализа кода регулярно сканируют репозитории в процессе разработки. Проверяется качество кода, покрытие кода тестами. Команды также используют инструменты динамического анализа для sanity- и fuzzy-тестирования.

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

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

Управление обновлениямиУправление обновлениями

Команда Yandex Cloud разработала политику управления обновлениями, которая регламентирует максимальный срок установки для каждого вида ПО. Установить обновление, выпущенное производителем ПО, необходимо в рамках этого срока.

Управление уязвимостямиУправление уязвимостями

Yandex Cloud регулярно проводит проверку уязвимостей предпроизводственных серверных систем с выходом в интернет и сетевых устройств перед их перемещением в промышленный контур. Все уязвимости устраняются до перемещения систем.

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

Внутренний и внешний аудиты, тесты на проникновениеВнутренний и внешний аудиты, тесты на проникновение

Для проверки работоспособности действующих процессов обеспечения ИБ и их развития компания проводит периодические внутренние и внешние аудиты и тесты на проникновение.

• Система управления информационной безопасностью проходит регулярный внутренний аудит с учетом рекомендаций ISO 19011.
• В рамках внутреннего аудита проверяются управление активами, физическая безопасность, управление изменениями, управление инцидентами ИБ, мониторинг и другие процессы и группы контролей ИБ.
• При проведении внутреннего аудита аудитор может проводить интервью, заполнять чек-листы, проводить проверки документированной информации с участием проверяемого, наблюдать за деятельностью, формировать репрезентативную выборку.
• Все несоответствия, выявленные в ходе внутреннего аудита, анализируются, чтобы установить причину несоответствий и внести изменения в план действий.
• Как требует законодательство в области защиты персональных данных (ПДн) и стандарты ISO, в компании есть план внешних аудитов на соответствие требованиям ISO 27001, ISO 27017, ISO 27018, а также план контрольных мероприятий для проверки соответствия процессов и контролей ИБ приказу ФСТЭК №21.
• Команда безопасности Yandex Cloud использует практики Red Teaming. Уязвимости, найденные благодаря регулярным тестам на проникновение, исправляются командами разработки или, если невозможно быстро выпустить обновление, закрываются подходящими средствами защиты до выхода исправления.

Реагирование на инцидентыРеагирование на инциденты

В компании существует политика управления инцидентами. Процесс управления инцидентами ИБ осуществляется Центром операционной безопасности (Security Operations Center, SOC) в составе службы информационной безопасности. При необходимости сотрудники профильных подразделений оказывают правовую, административную и экспертную поддержку. Основная задача SOC — проведение процедур для повышения безопасности:

• Сбор событий ИБ из средств мониторинга, сообщений пользователей и других источников.
• Выявление инцидентов ИБ с использованием автоматизированных средств, а также знаний и опыта сотрудников SOC.
• Реагирование на инциденты ИБ по типовому плану реагирования. Если такого плана нет, к разрешению инцидента привлекаются специалисты.
• Анализ инцидентов ИБ сразу после устранения последствий.
• Корректирующие действия по результатам анализа.

Уведомление клиентовУведомление клиентов

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

За подготовку письма отвечает инцидент-менеджер, назначенный в момент регистрации инцидента. В письме указывается характер инцидента, описываются возможные последствия и принятые (или предполагаемые) меры по устранению инцидента и его последствий. Инцидент-менеджер согласует письмо с ответственными лицами и передает его в службу поддержки.

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

Управление персоналом Yandex CloudУправление персоналом Yandex Cloud

Компания проводит мероприятия для сотрудников Yandex Cloud, чтобы минимизировать риски в области ИБ, связанные с действиями сотрудников.

• Компания проверяет всех кандидатов на трудоустройство.
• Сотрудники знакомятся с требованиями внутренних политик и регламентов, включая «Политику информационной безопасности Yandex Cloud» и «Положение об обработке персональных данных Yandex Cloud».
• Сотрудники дата-центров, администраторы и разработчики на регулярной основе проходят дополнительные курсы, связанные с безопасной разработкой и регламентами администрирования и эксплуатации облачных сервисов. Обучение проходит очно и онлайн.
• После обучения сотрудники выполняют тестирование, подтверждающее уровень знаний.
• Результаты проверки практических навыков и теоретических знаний анализируются, по ним вырабатывается коррекция системы обеспечения ИБ компании.
• Сотрудники, не прошедшие обучение в установленный срок, не допускаются к работе.
• Права доступа пересматриваются каждые полгода.
• При увольнении или смене должности права доступа к информационным ресурсам автоматически отзываются.
• Пароли проверяются на соответствие парольной политике. Регулярно оценивается стойкость паролей и их отсутствие в популярных словарях.

Непрерывность бизнеса и отказоустойчивостьНепрерывность бизнеса и отказоустойчивость

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

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

Для проверки эффективности планов регулярно проводятся тестирования. Результаты тестирования анализируются, вырабатываются меры по устранению недостатков, и принимается решение о пересмотре существующих планов.

Безопасность инфраструктуры облачной платформыБезопасность инфраструктуры облачной платформы

Разделение и изоляция ресурсовРазделение и изоляция ресурсов

Изоляция административных и пользовательских ресурсов в Yandex Cloud происходит следующим образом:

• Физическая изоляция с помощью групп хостов. Критичные с точки зрения безопасности сервисы запускаются в виртуальных машинах на отдельной группе физических хостов, на которой не запускаются пользовательские виртуальные машины.
• Логическая изоляция на уровне гипервизора и отдельных ядер. Иногда административная нагрузка может запускаться на хостах, на которых располагаются виртуальные машины пользователей. В таких случаях изоляция осуществляется на уровне гипервизора и физических ядер.
• Логическая изоляция с помощью сервиса Identity and Access Management (IAM). Все административные операции проводятся через IAM. Для их выполнения нужны специальные права, недоступные пользователям Yandex Cloud.
• Изоляция на уровне сети. Все административные виртуальные машины запускаются в физически или логически изолированных сетях. Корпоративная сеть провайдера отделена от сети облачной платформы. Доступ контролируется автоматически с помощью динамических и хостовых межсетевых экранов и списков управления доступа на маршрутизаторах.
• В мультитенантных системах изоляция реализуется на уровне приложения, а также при помощи проверки прав доступа к облаку и каталогу у пользователя, осуществляющего операцию над ресурсами.

Безопасность машин облачной платформыБезопасность машин облачной платформы

Безопасность физических машин и сервисных виртуальных машин обеспечивается на нескольких уровнях.

• На уровне сети используются несколько типов межсетевых экранов:

  • фильтры пакетов на границах внутренних подсетей;
  • простой фильтр пакетов на уровне Top-of-Rack коммутатора;
  • аппаратный межсетевой экран на границе инфраструктуры Яндекса и инфраструктуры Yandex Cloud;
  • программный межсетевой экран, установленный на всех физических хостах и виртуальных машинах.

• Используются дополнительные средства защиты:

  • AppArmor и Seccomp — формируют среду изоляции (песочницу) для приложений. Все виртуальные машины на уровне хостовой операционной системы работают под AppArmor.
  • Osquery 4 — доработанная версия Osquery, которая реализует функционал Host-based Intrusion Detection System, собирает телеметрию с хоста, включая логи AppArmor и Seccomp, обогащает их и отправляет в систему Security Information and Event Management (SIEM).
  • Система мониторинга и оповещения о подозрительном поведении.

• Конфигурации операционных систем описаны кодом и хранятся в репозитории. Все изменения конфигураций проходят обязательную проверку в тестовых средах перед переносом в продуктивную среду.

• Контроль доступа администраторов и разработчиков к продуктивной среде обеспечивается с помощью бастионного хоста, который записывает сессию пользователя. Информация из записанных сессий обрабатывается и попадает в SIEM-систему. Сотрудники службы информационной безопасности Yandex Cloud регулярно ее анализируют.

• Доступ к кластеру по SSH происходит с использованием аппаратных ключей, на которых хранятся аутентификационные данные сотрудников. Это снижает риски, связанные с кражей учетных данных сотрудников с доступом в продуктивную среду.

• Все установленные в продуктивном окружении пакеты регулярно проверяются на наличие уязвимостей и обновляются до последних версий.

Защита от атак на цепочку поставок (supply chain attacks)Защита от атак на цепочку поставок (supply chain attacks)

В Яндексе есть отдел Research and Development (RnD). Он занимается проектированием и организацией производства серверного оборудования, которое используется в компании. Все серверное оборудование проходит тестирование перед вводом в эксплуатацию. Пакеты с кодом, которые внедряются в продуктивную среду, содержат криптографическую подпись. Пакетный менеджер проверяет ее перед установкой. Все пакеты сторонних производителей ПО с открытым исходным кодом переподписываются перед добавлением в репозиторий пакетов компании.

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

Конфигурации всех компонентов продуктивной среды собираются отдельно при помощи Osquery. Сотрудники службы информационной безопасности анализируют их с помощью SIEM-системы.

Защита учетных данных сотрудниковЗащита учетных данных сотрудников

Процесс аутентификации на корпоративных ресурсах, не связанных с объектами облачной инфраструктуры, выстроен на основе лучших мировых практик:

• Все события аутентификации собираются и анализируются на предмет возможной кражи учетных данных.
• В Yandex Cloud внедрены меры противодействия фишингу.
• В компании действует парольная политика.
• Для внешнего доступа к ресурсам требуется VPN-соединение или двухфакторная аутентификация.
• Стойкость паролей регулярно проверяется.

Процесс аутентификации на ресурсах, связанных с облачной инфраструктурой, строже:

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

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

Защита данныхЗащита данных

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

• Шифрование на уровне Storage

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

• Шифрование на уровне баз данных Yandex Managed Service for YDB

  В YDB дополнительно реализовано шифрование на уровне баз данных. Данные шифруются непосредственно перед отправкой в Storage. Шифрование на уровне баз данных происходит в системах, построенных на базе YDB (например, Yandex Message Queue), и других сервисах платформы, которые используют YDB для хранения данных.

• Шифрование резервных копий данных в Managed Services for Databases (MDB)

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

• Шифрование данных при передаче

  Для шифрования данных при передаче используется протокол TLS. Ключи для работы протокола TLS хранятся на хостах, на которых он используется.

В сценариях, указанных выше, используются следующие криптографические алгоритмы:

• симметричные: AES, ChaCha;
• ассиметричные: RSA, Ed25519.

Минимальная длина ключа, используемая в симметричных алгоритмах, — 128 бит, в асимметричных — 2048 бит.

Удаление данныхУдаление данных

• Удаление ресурса при получении запроса через API сервиса. Если сервис получает запрос на удаление ресурса через API, ресурс немедленно помечается как удаляемый.

• При автоматической блокировке облака. По истечении 60 дней (при блокировке облака из-за нарушения условий использования — 7 дней) Yandex Cloud может пометить ресурсы как удаляемые.

• При удалении облака. Все каталоги и ресурсы немедленно помечаются как удаляемые.

• При разрыве контракта. Все облака и ресурсы немедленно помечаются как удаляемые.

• Удаление логов запросов к ресурсам. Записи о запросах к ресурсам пользователя через API хранятся в течение года для анализа инцидентов информационной безопасности и противодействия мошенничеству. По истечении года записи безвозвратно удаляются.

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

Раскрытие данных третьей сторонеРаскрытие данных третьей стороне

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

Защита информации о пользователеЗащита информации о пользователе

Информация о пользователях доступна сотрудникам Yandex Cloud на основе принципа минимальной необходимости, то есть эту информацию получают только те подразделения, которым она необходима для выполнения своих обязанностей. В системах обработки и хранения данной информации используется аутентификация, авторизация и учет действий над записями.

Информация о пользователях включает в себя:

• логи действий пользователей (операции);
• логи доступа для API и консоли;
• техническую информацию о состоянии сервисов пользователя;
• финансовую информацию и информацию о потреблении.

Права на доступ к информации, перечисленной выше, по умолчанию ограничены и регулярно пересматриваются сотрудниками службы ИБ. Системы, в которых хранится и обрабатывается данная информация, создаются с использованием процесса безопасной разработки (Security Development Lifecycle, SDL) и регулярно проходят внутренний тест на проникновение. Информация о пользователях по возможности шифруется при хранении и передаче.

МониторингМониторинг

Для сбора и обработки событий безопасности в Yandex Cloud используется SIEM-система. События доставляются в SIEM-систему из различных источников, в основном по протоколам HTTPS и syslog.

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

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

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