Связаться с намиПодключиться

Слои изоляции

В моделях провайдера IaaS и PaaS обычно представлены следующие слои изоляции:

Изоляция серверов Yandex Cloud

Несмотря на то, что облако использует те же дата-центры (ДЦ) что и другие сервисы Яндекса, серверы Yandex Cloud находятся в отдельных изолированных зонах внутри ДЦ. Здесь действуют особые правила физического доступа, а физическая сеть платформы изолирована по периметру межсетевым экраном.

Логическая изоляция на уровне гипервизора

Этот уровень реализует классическую изоляцию с помощью гипервизора. Архитектура гипервизора и средства управления виртуальной средой обеспечивают изоляцию одной виртуальной машины (ВМ) от другой. В Yandex Cloud используется аппаратная виртуализация, реализованная при помощи набора команд Intel VT-x. Взаимодействие таких ВМ можно организовать только с помощью организации доступа L3 между ними, при этом не важно на одном или разных физических хостах они размещены.

В Yandex Cloud есть возможность создавать ВМ только с четным числом ядер для ослабления действия атак по сторонним каналам процессора. ВМ со 100% ядрами планировщик создает так, что она эксклюзивно занимает нужные ядра процессора и не позволяет проводить атаки типа Spectre или Meltdown. Помимо прочего, можно использовать функциональность «выделенных хостов», то есть аппаратных хостов, на которых будут запускаться ВМ только одного клиента (гарантия того, что у клиента не будет соседей).

Провайдер также может реализовать дополнительные меры по контролю изоляции ВМ и отслеживать поведение процессов, связанных с запущенными ВМ. Если процесс, ассоциированный с ВМ, обращается к не свойственным для него ресурсам операционной системы или вызовам ядра, стоит присмотреться к нему более внимательно — такое поведение может указывать на попытку злоумышленников нарушить изоляцию ВМ и попасть на уровень хостовой ОС или на соседнюю ВМ.

Логическая изоляция на уровне управляемых сервисов

Изоляция на этом уровне зависит от специфики и архитектуры управляемого сервиса. Если решение, предоставляемое в виде управляемого сервиса, реализует мультитенантную среду, то есть надежную и безопасную работу различных пользователей облака (в том числе принадлежащих разным организациям) с единой инсталляцией решения, то изоляция в основном обеспечивается на уровне логики решения. Так реализовано объектное хранилище (Object Storage) в Yandex Cloud.

Если же решение не обеспечивает изоляцию пользователей на должном уровне либо обеспечение такого уровня значительно затруднено, то изоляция обеспечивается уровнем выше — средствами управления облачной платформы. Например, кластеры некоторых БД в Yandex Cloud создаются всегда строго для конкретного клиента (в сущности являются решением single-tenant). Таким образом исключается возможность работы с созданным кластером соседей по облаку. Для соседа автоматика облака запустит отдельные экземпляры ВМ, внутри которых будет установлено решение, предоставляемое в рамках управляемого сервиса (например, СУБД MySQL в случае Managed Database for MySQL в Yandex Cloud). При этом внутри базы клиент может создавать пользователей и обеспечивать логическую изоляцию между своими приложениями — потребителями базы данных.

Изоляция управляющей сети провайдера от виртуальных сетей облачных пользователей

Управляющая сеть условно делится на базовую (underlay) и наложенную (overlay). Underlay — это сегмент физической сети, реализующий связность между всеми физическими компонентами облачной платформы. Overlay — это набор виртуальных сетей, которые могут использоваться как провайдером (в служебных целях для работы сервисов платформы), так и конечными пользователями. Underlay в Yandex Cloud делится на два сегмента (VLAN): технологический, который используется для работы overlay, и служебный для передачи данных между аппаратными хостами (например, в случае живой миграции ВМ).

Трафик в underlay и в служебные сегменты overlay строго контролируется ACL на Tor и граничных маршрутизаторах (border routers), аппаратными файрволлами на периметре физической сети, программными файрволами на хостах и security groups (встроенных межсетевых экранах на уровне виртуальной сети).

Изоляция трафика разных виртуальных сетей на уровне физической сети

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

Логическая изоляция на уровне учетных записей и прав доступа

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

Разделение сущностей сontrol plane и data plane

Архитектура всех сервисов облака условно разделяется на компоненты, реализующие функции управления ресурсами сервиса (control plane), и компоненты, реализующие работу с ресурсами того или иного сервиса. Например, в случае сервиса MDB (управляемые БД) слой, отвечающий за управление кластерами баз данных, реализован набором служебных ВМ, которые, в свою очередь, реализуют API управления ресурсами сервиса (например, запуск/остановка БД) и выполняют поданные пользователем (или его автоматикой) задачи. А data plane — это ВМ с самой БД, собранные в кластер для обеспечения нужного уровня отказоустойчивости. При этом изоляция на уровне control plane встроена в архитектуру сервиса и реализуется с помощью учетных записей и их прав доступа к ресурсам. Изоляция на уровне data plane зависит от особенностей конечного решения, предоставляемого пользователю (см. пункт 2). При этом компоненты сontrol plane не видят данные пользователей, они только лишь управляют компонентами, реализующими слой data plane, в котором уже идет работа с данными пользователя.

Изоляция сервисных компонент инфраструктуры провайдера от пользовательских ресурсов

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

  • компоненты, реализующие внутренние сервисы, не доступные конечным пользователям;
  • компоненты, реализующие доступный пользователям сontrol plane сервисов;
  • компоненты, обеспечивающие работу data plane слоя (например, ВМ, на которой размещена БД, предоставляемая клиенту в рамках управляемого сервиса).

В зависимости от ситуации такие сервисные компоненты изолируются как на уровне физических хостов (размещаются на хостах, где нет пользовательской нагрузки. Пример — основные машины сервиса KMS), так и на уровне виртуальных сетей.

Организация изоляции на примере архитектуры некоторых сервисов

Сервисы управляемых БД позволяют работать с нужной СУБД без необходимости ее инсталляции и обслуживания. Сервис обеспечивает развертывание нужной пользователю СУБД в режиме отказоустойчивого кластера. Далее пользователь работает с развернутой СУБД напрямую. Сервис поддерживает различные СУБД.

Общая архитектура сервиса

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

Работа с данными происходит стандартно: в зависимости от типа БД пользователь подключается к ней напрямую (например, на MySQL к порту 3306) и выполняет SQL-запросы.

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

Таким образом, изоляция на уровне управляющих компонент реализуется на уровне исходного кода сервиса управляемой БД и базируется на сервисе IAM (сервис идентификации и аутентификации) — именно он авторизует запросы на управление и не позволяет пользователям управлять чужими ресурсами. А изоляция на уровне кластеров организована посредством их разделения на уровне ВМ — все экземпляры кластера работают в ВМ, которые доступны в виртуальной сети того пользователя, который их создал. То есть пользователь другой организации сможет работать с чужой БД, только если владельцы кластера явно разрешат доступ такому пользователю к БД, включая предоставление соответствующего сетевого доступа.