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

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

Суть облака — в предоставлении программного обеспечения, платформ для разработки или целой инфраструктуры как услуги. Покупкой новых серверов, строительством и обслуживанием серверных помещений, заменой оборудования и базовой безопасностью занимается провайдер облачных услуг (Cloud Service Provider, или CSP). Клиент же получает возможность из удобного интерфейса настраивать уже подготовленные для него информационные системы или целую инфраструктуру. Это позволяет экономить огромное количество времени — ведь в таком подходе больше не нужно ждать поставки оборудования, его подготовки и настройки, а затем установки ПО и интеграции получившейся системы со всей остальной инфраструктурой. А так как многие сложные технические моменты облачный провайдер забирает на себя, существенно снижаются и требования к числу специалистов в штате. 

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

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

Какие бывают облака?

Развитие облачных технологий началось с предоставления в качестве услуги конкретного программного обеспечения. Самый простой пример — это почта. Вам не нужно поднимать свой собственный почтовый сервер, настраивать почтовый домен, заниматься вопросами безопасности (защитой от спама, например) и иметь какое-то хранилище для ваших электронных писем. Всем этим занимается провайдер, такой как Яндекс или Google. Вам же, как клиенту, предоставляется доступ к веб-сайту, который после прохождения авторизации позволит вам работать с почтой и календарем. Такой подход называется SaaS (Software as a Service). Этот подход забирает у клиента всю возможную «головную боль», которая может возникать при работе с ПО, но одновременно с этим забирает множество возможностей по настройке этого ПО «под себя». Вы не сможете поставить свой собственный анти-спам фильтр в облачную почту, настроить маршрутизацию почтовых сообщений или обязательную проверку подлинности отправителя. Вы работаете только с тем небольшим набором настроек, что предоставил вам провайдер. SaaS — это предоставление ПО в максимально user-friendly виде, но с минимальными возможностями. 

Следующим шагом в развитии стала идея PaaS (Platform as a Service). Появился спрос не только на конкретное ПО, но и на программные платформы, на которых оно устанавливается. Допустим, небольшому стартапу нужна инфраструктура для разработки собственного веб-приложения, но бюджет сильно ограничен. Создание и настройка своей собственной платформы для разработки (еще и безопасной!) для нескольких небольших команд всё равно выливается в необходимость закупки и настройки множества серверов и прикладного ПО: где-то должен стоять веб-сервер, где-то должна быть развернута отказоустойчивая база данных, где-то должны храниться файлы и репозитории кода. Для такого стартапа настоящим спасением станет PaaS. Облачный провайдер по запросу предоставит и веб-сервер, и базу данных, и всё необходимое для создания своего приложения. Причем устанавливать операционные системы и создавать виртуальные машины не потребуется — всё необходимое ПО будет разворачиваться в готовом к работе виде. И в этом подходе возможностей для настроек будет значительно больше. Конфигурацию веб-сервера можно будет переделать под свою, как и конфигурацию базы данных. А если веб-приложение станет популярным, и имеющаяся база данных и веб-сервер не будут справляться с нагрузкой, платформа позволяет гибко и просто увеличить их мощности или количество экземпляров. Однако возможности платформы сильно ограничены тем, под что она заточена. На платформе для веб-разработки не получится построить собственную нейросеть, если команде придет в голову такая идея, — необходимых сервисов у провайдера просто нет. Придется искать другую платформу для решения этой задачи.

Финальным на текущий момент шагом в развитии облачных технологий стала концепция IaaS (Infrastructure as a Service). В такой модели провайдер облачных услуг предоставляет целую инфраструктуру в аренду, открывая огромные возможности: можно создавать свои виртуальные машины из подготовленных образов парой кликов мышью; строить свою собственную сеть, как внутреннюю, так и связываясь с «внешним» миром; пользоваться десятками самых различных сервисов провайдера, которые на уровне облака уже интегрированы друг с другом (например, аренда сканера уязвимостей не требует никакой интеграции с машинами, которые нужно проверить, — он по умолчанию видит их все). Здесь для пользователя открывается наибольшее число возможностей, но и резко возрастает ответственность. Провайдер больше не может брать на себя все задачи по обеспечению безопасности ваших данных, так как эти данные вы можете размещать так, как вам заблагорассудится. Он всё еще занимается вопросами предоставления вам мощностей, а также их резервирования (чтобы вы не потеряли всю инфраструктуру от аварии в одной серверной), но вот безопасность развернутого вами ПО и ОС, а также сетей и доступа теперь полностью на вашей стороне. Далее в статье мы рассмотрим именно такие облака.

Делятся облака не только по своему функционалу, но и по местоположению. Большинство облаков (как и все приведенные выше примеры) называются публичными, то есть на стороне клиента никакого оборудования нет. Но у некоторых организаций может возникнуть такая ситуация: технологии и возможности облачной платформы крайне востребованы, а размещать данные на чьих-либо «чужих» ресурсах (тем более доступных из интернета) не разрешено. В этом случае возможно построение частного облака. Такой подход будет очень сильно напоминать стандартную платформу виртуализации — всё железо необходимо купить (или арендовать) клиенту самостоятельно, отказоустойчивость оборудования и данных настроить самостоятельно, все вопросы по безопасности, как и всегда, взять на себя. Но вместо обычного гипервизора у клиента будет многофункциональная гибкая облачная платформа, которая позволит ему решать ИТ-задачи быстрее и эффективнее. А производитель облачной платформы в этом случае будет оказывать техническую поддержку и консультации, совсем как при покупке обычного Enterprise ПО. Наконец, третья модель доступности облака — гибридная. Как следует из названия, она совмещает публичный и частный подход. Часть инфраструктуры остается в ЦОД клиента, часть — арендуется у провайдера, и между ними настраивается безопасный канал обмена данными.

Сервисы, специфичные для облаков

Как уже было отмечено ранее, облачная платформа — это не просто среда виртуализации, где можно создавать машины и связывать их сетью. Это развитие данной идеи в сторону создания сервисов, которые, будучи развернуты, сразу готовы к выполнению задач. В процессе разработки и анализа данных нужно постоянно создавать новые базы данных. Но база данных — это прикладное ПО. Значит, для создания новой БД нужно ставить операционную систему, потом устанавливать СУБД, создавать в ней БД, настраивать всё это для удаленного доступа и безопасной авторизации, интегрировать с другим ПО. Это совершенно базовая задача, которую приходится в обычной среде виртуализации повторять множество раз. В облаке такая необходимость отсутствует — нужная клиенту база данных будет развернута как сервис, а необходимость работы с ОС (и, как следствие, ее защиты), на которой она установлена, отпадает. И расширять такую базу данных значительно проще — теперь не придется думать о примонтированном к ОС диске. Таких сервисов у облачного провайдера десятки: веб-серверы, платформы для работы с большими данными, сервисы сбора и хранения логов, сервисы для работы с контейнерами и многое другое. Таким образом, подход SaaS «включен» в подход IaaS: получив целую инфраструктуру как сервис, внутри можно разворачивать самое различное ПО как сервис.

Гибкость работы и выделения ресурсов в облаке привела к появлению концепции Serverless. Этот термин подчеркивает не отсутствие серверов, а отсутствие необходимости (и возможности) управлять этими серверами.

Представим себе следующий сценарий: вам необходимо регулярно создавать резервные копии виртуальных дисков ваших машин и данных с них. В традиционном подходе вам бы потребовалось развернуть еще одну ВМ, на ней создать в планировщике задач скрипт для снятия резервных копий. Тогда такую ВМ нужно всегда держать запущенной (иначе задача не выполнится), ее необходимо защитить, и за нее необходимо всё время платить. 

С помощью облачных функций (также часто называемых лямбда-функциями) возможно написать код, который будет обращаться к API облачной платформы. Такая функция может создать резервную копию нужных дисков при ее вызове по расписанию, переместить их в хранилище резервных копий и завершиться. В этом случае платить нужно только за вызовы такой функции — никакого простоя ресурсов не возникает. Такой подход предоставляет огромное число возможностей по упрощению и автоматизации различных задач, а также позволяет самостоятельно интегрировать сервисы таким образом, каким это нужно для клиента. Но при этом среда выполнения этой функции уже не имеет значения: где и как она вызывается, клиенту не важно, ведь сама функция — это тоже сервис.

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

На этом развитие облачных сервисов не остановилось. Если можно связать несколько сервисов и автоматизировать изменение их параметров с помощью кода, то аналогично можно управлять всей инфраструктурой целиком. Если нужно создать 100 однотипных виртуальных машин и связать их единой сетью, можно не прокликивать каждый раз одинаковые операции в веб-интерфейсе, а написать код, который обратится к API платформы и сделает это всё за вас за несколько секунд. Так появился подход IaC (Infrastructure as Code). С помощью специального высокоуровневого языка Terraform, методы которого «понимает» облачная платформа, стало возможным управлять инфраструктурой как кодом проекта: вести историю версий через GitHub, применять процесс проверки кода перед релизом, иметь несколько «веток» вашей инфраструктуры и модернизировать ее значительно эффективнее. При таком подходе вся информация о инфраструктуре больше не разрознена по сотням страниц десятков технических документов и пояснительных записок, а находится в одном файле, где имеет стандартизированное и читабельное представление.

Рассмотрим пример. В конфигурационном файле мы описываем, какой ресурс (то есть облачный сервис) необходимо задействовать — сперва это сервис создания ВМ. Задаем имя для нашей ВМ и пишем, какие ресурсы процессора и ОЗУ ей необходимо выделить. Далее указываем диск, который необходимо примонтировать к ВМ как загрузочный. В данном примере у нас используется идентификатор уже подготовленного образа диска, предоставляемого облачным провайдером. После чего указываем, какой сетевой интерфейс из какой подсети необходимо добавить для машины. Для данной машины нам нужна новая подсеть — ее мы объявляем далее, обращаясь к ресурсам облачного сервиса Virtual Private Cloud, указывая, как будет называться данная сеть, в какой она должна быть зоне доступности и какой диапазон «серых» адресов она займет. После применения данной конфигурации нужная ВМ и сеть будут автоматически созданы, а сетевой интерфейс ВМ получит адрес из созданной подсети. Итоговый конфигурационный файл будет выглядеть следующим образом:

resource "yandex_compute_instance" "vm-1" {
  name = "terraform1"
  
  resources {
      cores  = 4
      memory = 4
  }
  
  boot_disk {
      initialize_params {
            image_id = "fd87va5cc00gaq2f5qfb"    
      }  
  }
  
  network_interface {
      subnet_id = yandex_vpc_subnet.subnet-1.id
      nat       = true  
  }
}

resource "yandex_vpc_network" "network-1" {
  name = "network1"
}

resource "yandex_vpc_subnet" "subnet-1" {
  name           = "subnet1"  
  zone           = "ru-central1-a"  
  network_id     = yandex_vpc_network.network-1.id  
  v4_cidr_blocks = ["192.168.10.0/24"]
}

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

Что у облака под капотом?

Технически как публичное, так и частное облако — это «надстройка» над средой виртуализации. Оно реализуется набором ПО, которое умеет обращаться к гипервизору, который, в свою очередь, уже управляет распределением физических ресурсов. Часто в качестве гипервизора используется KVM (Kernel Virtual Machine), то есть происходит виртуализация средствами Linux. Крупные провайдеры, такие как Amazon, Microsoft, Google, используют свои собственные гипервизоры — Nitro, Azure, и т. д.

Рассмотрим пример самого проверенного и популярного способа построения облака. На хост гипервизора устанавливается OpenStack — тот самый набор программного обеспечения с открытым исходным кодом, который и реализует всю логику и возможности облака. OpenStack состоит из множества «модулей», что открывает возможности облачным провайдерам самостоятельно дорабатывать или вообще заменять некоторые из модулей без нарушения совместимости. Контроллер вычислительных мощностей Nova отвечает за запуск, остановку и выделение ресурсов виртуальных машин. Виртуальную облачную сеть реализует модуль Neutron. Модули Swift и Cinder являются виртуальными системами хранения данных с высокой отказоустойчивостью. Keystone отвечает за авторизацию пользователей облака. Horizon реализует единый веб-интерфейс управления облаком, откуда пользователь может обратиться к любому из модулей. Разбор OpenStack выходит далеко за пределы данной статьи, и количество его модулей достаточно велико. Мы остановимся на его верхнеуровневой архитектуре.

Второй распространенный вариант построения облака не так популярен, так как не обладает такой гибкой модульной структурой и жестко привязан к одному производителю — VMware. Облако можно реализовать средствами VMware Cloud Director — это просто расширенная под задачи облака среда виртуализации VMWare vCenter, которую на собственных площадках используют клиенты по всему миру. Такой вариант облака может быть востребован для компаний, у которых уже вся инфраструктура реализована на VMware (в этом случае миграция в облако пройдет быстро и без проблем, а администраторам ничему не нужно будет учиться) или если им требуются решения VMware в своем облаке — например, VDI (сервис виртуальных рабочих мест). В этом случае в качестве гипервизора на схеме будет выступать VMware ESXi, а вместо OpenStack и его модулей будет VMware Cloud Director.

Важным аспектом устройства облака является его отказоустойчивость. Системы виртуализации всегда позволяют дублировать и резервировать свои объекты между несколькими серверами. Однако у крупного бизнеса ИТ-инфраструктура часто размещается в нескольких ЦОД для обеспечения отказоустойчивой работы даже в том случае, если ЦОД физически будет уничтожен (например, из-за пожара или стихийного бедствия). Аналогичный подход предлагают и облачные провайдеры, используя понятие зоны доступности. Каждая зона доступности — это набор физически изолированного оборудования, аналог ЦОД. Логической изоляции при этом нет — ваши виртуальные машины в разных зонах будут иметь сетевую связность. Но в случае аварии в ЦОД провайдера всё то, что вы дублировали в другой зоне доступности, остается с вами. Но такую катастрофоустойчивость вам необходимо предусмотреть самостоятельно — ваши виртуальные машины не резервируются в другой зоне доступности, и вам нужно добавлять резервные машины для критичных сервисов в несколько зон, а потом связывать их механизмами кластеризации. Чаще всего предлагаются три зоны доступности на выбор.

Сеть в облаке так же, как и в среде виртуализации, имеет несколько слоев. Уровень физического оборудования от вас скрыт — вы не управляете физическими коммутаторами и маршрутизаторами. Но вам это и не требуется — с помощью VPC (Virtual Private Cloud) (сетевой облачный сервис, не путать с частным облаком!) вы можете создавать свои «логические» сети, причем эти сети могут быть растянуты между всеми зонами доступности. Каждая VPC — это набор «серых» адресов и их подсетей, создав такую и присвоив каждой машине «серый» адрес, вы автоматически обеспечиваете для них сетевую доступность. Межсетевое экранирование также выстраивается логически с помощью групп безопасности: вы объединяете адреса машин в группы и для каждой группы указываете правила — по каким протоколам, портам и адресам данная группа может получать или отправлять сетевой трафик. Доступна также и аренда «белых» адресов, которые средствами платформы можно назначать определенным сетевым интерфейсам нужных вам машин. Или же настроить NAT для доступа к множеству ресурсов через один адрес с помощью соответствующего сервиса. VPN также может быть реализован средствами облачной платформы, а при необходимости можно установить прямое сетевое подключение площадки клиента и ЦОД облачного провайдера. Набор сетевых инструментов облака очень широк и предоставляет клиентам удобные возможности по настройке и защите своей сети, хотя ограничения, безусловно, могут возникнуть — так как клиент не управляет физическими маршрутизаторами и «привязан» к тому, как они настроены, иногда уже имеющиеся сетевые решения приходится корректировать для миграции в облако.

На примере ниже указано разделение машин по зонам доступности, подсетям и группам безопасности. Веб-сервер должен быть доступен из сети интернет, поэтому он размещается в публично доступной подсети. База данных, наоборот, не должна быть доступна извне — она размещается в закрытой подсети. Для отказоустойчивости экземпляры базы данных и веб-сервера дублируются в другой зоне доступности. Однако логика разграничения доступа у экземпляров в разных зонах одинаковая — они размещаются в одной группе безопасности.

Часто облако требуется не только для аренды вычислительных мощностей, но и для хранения данных. Облачное хранение данных для обычных пользователей уже давно вошло в привычку — фотографии и документы тысячами загружаются в iCloud, Яндекс.диск, Dropbox. У бизнеса своя потребность в хранении данных: это могут быть файлы баз данных, образы виртуальных машин и прикладного ПО, ML-модели, изображения для веб-ресурсов, проектные документы. Облачные провайдеры предоставляют такой сервис, чаще всего он называется Object Storage. Это файловое хранилище, к которому возможно очень гранулярно настроить доступ: кто к каким файлам имеет право обратиться. Возможно изменять и режим хранения объекта: если к нему постоянно идут обращения (что характерно для веба), его можно положить на физически более быстрый и доступный диск, но такая услуга будет дороже. А если это некий «архивный» файл, который смотрят раз в год, то за его хранение можно платить меньше денег, но его доступность будет сильно ниже. Всего в хранилище две сущности — это бакеты и объекты. Объект — это любой файл или директория. Бакет — это логическая сущность, напоминающая «корень диска»: они создаются для удобства разграничения хранимых данных и доступа к ним. Каждый бакет имеет свой URL для доступа подобно веб-сайту.

В отличие от хранения данных на виртуальной машине, диск которой ограничен, такое хранилище всегда растягивается под нужды клиента автоматически. Доступ к данным также предоставлять проще: некоторые объекты можно опубликовать в интернет или поделиться ссылкой на них, не опасаясь при этом проникновения на ВМ. Надежность хранения данных — это всегда крайне критично. Поэтому облачные провайдеры используют не просто СХД, а SAN — сети хранения данных. Такая сеть объединяет в кластер множество СХД и многократно дублирует записанные данные между разными зонами доступности. Также используются дисковые массивы, которые сами по себе реализуют дублирование записи на несколько жестких дисков, объединенных в массив. Аппаратные платформы, используемые для такого хранения, поддерживают горячую замену почти всех своих элементов без необходимости выключать их — вылетевший диск можно тут же заменить, вставив новый. Совокупность этих методов реализует надежность хранения данных вплоть до 99,99999%, что означает менее минуты простоя в течение года. Соответственно, количество объектов, которые могут быть утеряны, исчисляется единицами. Большим преимуществом этого сервиса также является богатый API. И если у разных облачных платформ и сервисов API различен, то для этого сервиса удалось выработать единый стандарт — во многих облаках используется API, называемый s3-совместимым, и набор его методов позволяет взаимодействовать с хранилищами разных облаков почти одинаково. API позволяет использовать облачное хранилище другим сервисам и ПО, автоматизировать работу с данными, причем поддерживает больше функций, чем доступно из веб-интерфейса.

Безопасность в облаке

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

Зоны ответственности, то есть набор мер защиты инфраструктуры, которые необходимо реализовать своими силами, зависят от выбранного типа облака. В модели SaaS возможности клиента по обеспечению ИБ сильно ограничены, так как у него нет доступа к платформе, на которой установлено прикладное ПО. Всё, что находится в зоне ответственности клиента — это разграничение доступа до ПО путем настройки аутентификации и управления созданными учетными записями. Если у сотрудника клиента украдут учетную запись и таким образом авторизуются в ПО, предоставляемом как сервис, облачный провайдер не несет за это никакой ответственности. Но если облачный провайдер не установил вовремя обновления безопасности или оставил какую-то «дыру», позволяющую обратиться к ПО не напрямую, а, например, через API — за причиненный ущерб он будет нести перед клиентом полную ответственность.

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

В модели IaaS вопрос ИБ стоит максимально остро. Как видно из рисунка, происходит большой скачок, и очень многие элементы переходят в зону ответственности клиента. В данной модели все виртуальные машины клиент создает сам, и сети для своей инфраструктуры тоже создает и защищает самостоятельно. Вопрос резервирования между зонами доступности также становится задачей инженеров клиента в случае, если речь идет о ПО, развернутом на ВМ (если речь идет о сервисах, таких как объектное хранилище или БД, то они являются SaaS сами по себе, и вопрос их резервирования провайдер снова берет на себя). Аналогично с логами аудита. Логи аудита прикладного ПО и их хранение находятся полностью в зоне ответственности клиента. А вот целостность логов самой платформы, в которых находится информация о том, кто какие облачные сервисы создавал — уже в зоне ответственности провайдера. Шифрование данных в этой модели также перекладывается на клиента — облачный провайдер предоставляет сервис хранения и создания ключей, с помощью которых можно шифровать диски с данными.

Помимо явно обозначенных уязвимых мест в процессе развертывания облачной инфраструктуры, возникает множество менее очевидных: на виртуальных машинах, доступных из сети, может стоять уязвимое ПО, или сама ОС может быть недостаточно защищена от типовых угроз. Сеть может быть недонастроена и допускать попадание нелигитимного трафика в подсети, которые должны быть изолированы. Наконец, разграничение доступа к объектам и сервисам облака должно быть максимально строгим и соответствовать принципу минимальных привилегий — ведь когда вся инфраструктура управляется из единого веб-интерфейса, цена ошибки предоставления лишнего доступа становится выше. Но облачная платформа предоставляет все необходимые инструменты для того, чтобы избежать рисков компрометации данных и недоступности продуктивных сервисов, а задача инженеров — грамотно воспользоваться ими.

Угрозы для облаков и средства защиты от них

К облакам применимы практически все распространенные типы угроз, актуальные для любой инфраструктуры. Но в силу специфики облака некоторые аспекты становятся особенно критичными. Первый из таких — управление доступом. В любом облаке за него отвечает модуль, называемый IAM (Identity and Access Management). При недостаточно детальной проработке ролей и полномочий, выдаваемых пользователям облака, возможны ситуации, когда у учетной записи появляются избыточные права доступа. Разработчик, работающий только над одним проектом, не должен видеть другие проекты. У него не должно быть прав на запись данных, которые ему не нужно изменять. И совершенно точно разработчик не должен иметь возможность настраивать параметры безопасности в облаке, потому что он в пользу удобства и простоты гарантированно их ослабит. Важно спроектировать максимально проработанную ролевую модель доступа, учитывающую особенности облака (разграничение по проектам / областям видимости / сервисам / конкретным ресурсам) и корректно применить ее. К этой же теме можно отнести настройки аутентификации в облаке — важно использовать двухфакторную аутентификацию для исключения ситуаций, когда компрометация одной лишь учетной записи уже дает злоумышленнику проход к веб-интерфейсу управления, откуда можно получить очень много информации. Наконец, нельзя забывать про управление учетными записями. Для них обязательна ротация стойких паролей и контроль актуальности — устаревшие и более не используемые УЗ должны быть отключены или удалены.

Следующая важная угроза называется Shadow IT. Облако заточено под постоянное наращивание самых различных ресурсов, и команды разработчиков или ИТ-инженеров могут очень быстро «плодить» виртуальные машины, бакеты, сервисы. При этом обеспечение безопасности в их рабочие задачи не входит — они будут создавать эти ресурсы для себя, не учитывая необходимости их защиты. Администратору ИБ важно следить за активностью в облаке и постоянно сканировать новые машины на предмет различных уязвимостей, а затем оперативно их устранять. Особенно критичным это становится для ресурсов, к которым привязывают «белые» адреса для доступа из интернета — они являются сладкой добычей злоумышленников, и их появление всегда должно быть учтено. Эта угроза — яркий пример того, как дыру в информационной безопасности инфраструктуры можно получить даже не от недонастройки системы ИБ, а в результате хода обычного рабочего процесса. Люди могут создавать уязвимости, сами того не понимая.

Не менее актуальна для облака и безопасность сети. Межсетевые экраны, как встроенные, так и установленные дополнительно, необходимо обязательно настроить для сетевого разграничения доступа между ВМ. В противном случае с одной машины, подвергшейся атаке, злоумышленник сможет подключиться и к другим ВМ в других сетях. Доступ до самих ВМ необходимо предоставлять исключительно через VPN с аутентификацией, исключая возможность подключиться напрямую на «белый» адрес виртуальной машины.

В модели PaaS и SaaS клиенту не требуется беспокоиться за обновления версий прикладного ПО. Однако в IaaS это такая же ответственность инженеров клиента, как и в традиционной инфраструктуре. Обновления позволяют оперативно защищаться от уязвимостей, которые выявляются регулярно в распространенном ПО, особенно Open Source. Внедрение процесса регулярного обновления (Patch Management) и сканера уязвимостей может помочь в решении данной задачи.

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

Все ресурсы облака, опубликованные в интернет, необходимо защитить по лучшим практикам защиты веба, чтобы защититься от специфичных атак: инъекций SQL-запросов, подделки межсайтовых запросов, DDoS-атак. С этим справляются межсетевые экраны уровня приложений (L7 модели OSI), которые называются WAF (Web Application Firewall). И, наконец, сам доступ в облако не должен осуществляться через недоверенную сеть, такую как публичный Wi-Fi, где данные в процессе передачи могут быть скомпрометированы. Также пользователей необходимо беречь от атак типа «человек посередине» и фишинга, которые могут позволить злоумышленнику перехватить аутентификационные данные.

Безопасность немыслима и без логирования — все данные аудита о действиях пользователей в облаке должны сохраняться и проверяться. Облачные сервисы, часто называемые Audit Trail (или Cloud Trace), обязательно должны быть настроены так, чтобы в случае инцидента они могли предоставить необходимую информацию для его расследования. Большим преимуществом здесь выступает единообразие облачной платформы — действия со всеми сервисами очень просто собирать, так как сервис логирования «знает» об их существовании и дополнительных интеграций, как и в случае со сканером безопасности, не потребуется. Действия с данными внутри сервисов необходимо настраивать уже на уровне этих сервисов — например, все действия с облачным хранилищем логируются средствами данного хранилища.

Если в облачной среде осуществляется работа с персональными данными или платежной информацией, такая инфраструктура по требованиям регуляторов обязана проходить Compliance — проверку на соответствие требованиям специальных стандартов безопасности. Современные облака предоставляют клиентам необходимый инструментарий и консультации по такой настройке, а сами они на уровне платформы уже имеют сертификаты соответствия, позволяющие размещать там такие данные. Например, отечественные облачные платформы аттестованы согласно требованиям закона 152-ФЗ «О персональных данных», и если клиент примет со своей стороны необходимые меры защиты, он может осуществлять деятельность по их обработке в облаке.

Специфичные средства защиты и не только

Средства защиты информации (СЗИ) в облаке бывают двух видов — встроенные и наложенные. Встроенными называются те, что предоставляются в облаке как сервис — например, VPN средствами облака будет встроенным. Наложенными называются те, что устанавливаются «как обычно» — то есть в виде прикладного ПО на ВМ. Если реализовать VPN средствами OpenVPN-сервера в облаке, такой VPN будет являться наложенным. Сравнение встроенных и наложенных средств — это предмет дискуссии, выходящий далеко за рамки данной статьи. Нельзя сказать, что всегда нужны исключительно сторонние СЗИ, хотя у последних есть ряд очевидных функциональных отличий. Но и преимущество самого облака — в предоставлении готовых сервисов. Значит, расход денег, сил и времени на установку полного набора СЗИ из собственной площадки будет нивелировать данное преимущество и снова вернет клиента к увеличению всех возможных затрат. Задача проектировщика облака — поиск такого разумного компромисса между встроенными и наложенными средствами защиты, чтобы их совместное применение давало оптимальный по всем параметрам результат.

Таким образом, наложенным СЗИ в облаке может стать вообще любое СЗИ, применяющееся и в классических On-premise инсталляциях (т. е. в собственных ЦОД). Но существуют решения, которые специфичны для облака, придуманы исключительно для них и вне контекста облака не имеют смысла.

Первым и самым популярным из таких, очень востребованным в подходе IaaS, является CSPM (Cloud Security Posture Management). Инструменты облака дают создать всё, что угодно, но само облако не имеет инструментов для визуализации и анализа всего созданного. По мере роста инфраструктуры число сетей, виртуальных машин, пользователей, различных политик доступа может разрастись до очень больших значений. И если у администратора возникнет вопрос: «А какие виртуальные машины нужно удалить, потому что их никто не использует?», то ответ на этот вопрос средствами облака он может искать часами и днями. А если необходимо проверить 10 000 правил межсетевого экрана на наличие конфликтных правил? Тут без разработки собственного скрипта вообще обойтись не получится, а такой скрипт необходимо еще протестировать и отладить. На помощь в таких задачах и приходит CSPM — средство анализа состояния и безопасности. Такое ПО разворачивается в облаке и, используя его API, выполняет множество проверок, результаты которых визуализирует для пользователя в формате удобных отчетов. Можно сразу увидеть весь список важных вещей: ВМ, у которых есть доступ в интернет/из интернета; ошибки в правилах встроенного МЭ или небезопасные правила; сервисные учетные записи, имеющие слишком много ключей доступа или полномочий; диски и бакеты, для которых не настроено шифрование, и многое другое. Такие решения также могут выступать внешними сканерами безопасности и проверять ВМ в облаке на наличие заплаток от самых распространенных уязвимостей. И наконец, решения этого класса могут помочь в оптимизации затрат на облако, показав все виртуальные машины, которые сильно недогружены (можно уменьшить их характеристики), диски, подключенные к выключенным ВМ (возможно, они более не нужны), и машины, которые давно никем не использовались. В этом классе есть и отечественные продукты — например CloudAdvisor, который сам предоставляется по модели SaaS и поддерживает нативные интеграции с различными облачными провайдерами.

Следующим востребованным решением, пока не имеющим отечественных аналогов, является CASB (Cloud Access Security Broker). Данный класс СЗИ предназначен для защиты от атак типа Shadow IT, для контроля передаваемых в облако данных и отслеживания доступа к нему, а также для консолидации информации об инфраструктуре и ее наглядному представлению: к каким облачным сервисам какие пользователи имеют доступ, и кто действительно ими пользуется и из какого местоположения. CASB также может стать еще одним инструментом разграничения доступа к данным в облаке, а также отслеживать аномалии в части обращений к различным сервисам. В части работы с данными CASB может выступать как аналог DLP-системы — согласно настроенным политикам находить на ресурсах облака критичную информацию и блокировать ее передачу. В качестве дополнительной защиты CASB может предоставлять возможность шифрования передаваемых в облако данных (средствами облачной платформы происходит только шифрование на стороне сервера). Изначально данные решения были созданы для контроля SaaS-облаков (например, для защиты облачной почты), но к настоящему моменту расширили свой функционал для полноценной работы с IaaS.

Максим Малышев

Старший инженер по информационной безопасности, "Инфосистемы Джет"