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

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

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

Для защиты облачных сред гораздо лучше использовать концепцию ZTNA (Zero Trust Network Access). Мы не будем глубоко погружаться в маркетинговые особенности данной методологии нулевого доверия, а вместо этого посмотрим, что можно использовать на практике.

Не доверяем никому

ZTNA (концепция нулевого доверия) предполагает принятие решений о предоставлении доступа непосредственно в момент подключения. Другими словами, у нас конечно есть списки доступа, учетные записи и другие стандартные атрибуты, указывающие на то, кто и куда должен иметь доступ. Но когда пользователь подключается мы смотрим на контекст. То есть, мы смотрим на то, из какого региона осуществляется подключение (геолокация), были ли подключения из этого региона, из подсети этого провайдера. Также мы смотрим, какая ОС и какой клиент используется для подключения. В простейшем случае мы смотрим на значение USER_AGENT передаваемое при запросе по HTTP.

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

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

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

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

Облака это всегда железо

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

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

Безопасность приложений или когда много Open Source

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

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

После известных событий в мире Open Source стали появляться приложения с закладками. Так, если вы обращаетесь к репозиторию не с российского IP адреса, то вам загружается нормальный, безопасный код. А вот при обращении с российских или белорусских адресов можно получить код с закладками.

Так, на просторах Интернета можно найти список opensource проектов с закладками и политизированной рекламой https://vk.com/wall7076856_4847. Этот список содержит несколько разделов, в которых описываются различные вредоносные воздействия, выполняемые различным софтом по политическим мотивам.

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

Зависимость от зависимостей

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

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

Управляемость

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

Заключение

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

А напоследок я хочу пригласить вас на бесплатный вебинар, где поговорим про концепции защиты инфраструктуры Zero trust network Acceess (ZTNA), Secure Access Service Edge (SASE), Defence-in-depth (DiD)

• Зарегистрироваться на бесплатный вебинар