4 риска при использовании облачных сервисов

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

Облачные сервисы позволяют:

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

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

Риск № 1. Конфиденциальность данных

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

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

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

Необходимо отметить, что простота в создании и настройке некоторых сервисов приводит к возникновению угрозы несанкционированного доступа к опубликованным базам данных и иным сервисам для хранения информации (например, S3 или Object Storage). Наиболее частой ошибкой является публикация баз данных в интернете, что в большинстве случаев приводит к утечке хранимой информации.

Еще одна – публичный доступ к консоли управления арендованным облаком. это означает, что административный доступ может получить практически любой человек из любой точки мира. Следовательно, крайне важно уделить особое внимание обеспечению безопасности учетных записей.

Для минимизации данного риска рекомендуется применить следующие меры.

1. Шифровать конфиденциальные данные, хранимые в базе данных

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

2. Шифровать данные при передаче

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

3. Удалять системных пользователей и/или пакеты, созданные провайдером, с виртуальных серверов

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

4. Запретить на уровне сетевых сегментов публичный доступ к базам данных

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

5. Мониторить управленческие события на уровне облака

Для своевременного выявления нарушений требований по публикации баз данных или признаков компрометации учетных записей необходимо контролировать все, что происходит в облачной инфраструктуре. Как правило, провайдер предоставляет специализированные сервисы, позволяющие реализовать такой мониторинг (например, Cloudtrail или Audit Trails). Все события из этих сервисов можно экспортировать в SIEM и настроить там необходимые алерты.

6. Обязательно использовать многофакторную аутентификацию для доступа к облаку

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

7. Контролировать целостность контейнеров и используемого программного обеспечения

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

Риск № 2. Доступность сервиса

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

Чаще всего данный риск является следствием реализации таких угроз, как:

• ограничение доступа из-за санкционных ограничений;
• любой иной отказ в предоставлении услуги со стороны провайдера;
• технический сбой на оборудовании провайдера.
  

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

Для снижения вероятности возникновения этого риска необходимы следующие меры.

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

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

2. Запрет на использование рутового аккаунта для целей администрирования

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

3. Мониторинг сообщений от провайдера о техническом обслуживании или деградации оборудования

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

4. Отдельные OU для администраторов, безопасников, тестировщиков, разработчиков и основной инфраструктуры

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

Риск № 3. Избыточная стоимость

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

1. Лимитирование масштабируемых сервисов

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

2. Использование средств защиты от атак на прикладном уровне

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

3. Контроль загрузки виртуальных серверов

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

Риск № 4. Несанкционированное изменение ПО

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

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

Опубликовано в журнале "Системы безопасности" №5/2021