3 ключевые ошибки управления доступом в облаке: находим и устраняем

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

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

Давайте вспомним, что в мире IT есть четыре типа инфраструктуры: 

• on-premise — развернутая внутри предприятия, на собственной площадке;

• cloud based — в публичном облаке;

• private cloud — в частном облаке; 

• hybrid — инфраструктура, которая объединяет облачные и локальные ресурсы.

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

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

• Самообслуживание. Все операции в облаке специалисты компании могут проводить самостоятельно без помощи команды провайдера. 

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

В этой статье мы поговорим про защиту публичного облака. Его подключение предполагает совместное использование некоторым количеством пользователей общей сетевой инфраструктуры: серверов, системы хранения данных (СХД), сетевого оборудования. А еще такое облако имеет прямой доступ к интернету, что заставляет задуматься о его защите от утечек данных и кибератак. 

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

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

• Платформа. Здесь хранятся настройки, которые пользователь регулирует через веб-консоль управления провайдера.

• Хосты и контейнеры. На этом слое определяется доступ к настройкам операционной системы (ОС), которые выполняются внутри хоста, а также к настройкам контейнерной среды внутри ОС.

• Приложение. Слой приложения, на котором определяются настройки доступа к системе управления базами данных (СУБД), самому ПО и его API.

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

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

Советы для базовой защиты

Совет 1

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

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

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

Совет 2

Использовать двухфакторную аутентификацию (2FA). Какой выбрать второй фактор, зависит от требований. Но не забывайте, что устройство с TOTP (Time-based One-Time Password) может выйти из строя, а SMS не всегда приходит вовремя из-за проблем в сети оператора или повреждения SIM. Поэтому важно, чтобы восстановление доступа не стало вектором атаки.

Совет 3

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

Советы для максимальной защиты

Совет 1

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

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

Совет 2

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

Совет 3

Ограничивать удаленные подключения к платформе по белому списку IP. Таким образом вы гарантируете защиту интерфейса управления облаком в случае утечки ключей доступа Access Key (AK) и Secret Access Key (SK), что происходит не редко. 

А что в Cloud.ru?

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

А сервис Cloud Advisor помогает проверить корректность конфигурации сервиса IAM на платформах Cloud.ru Advanced и Облако VMware, предупредить о несоответствии настроек требованиям безопасности и получить инструкции по исправлению проблемы.  

Советы для базовой защиты

Совет 1

Использовать для доступа к ВМ только SSH-ключи, а не пароль: 

• Вероятность успешной брутфорс-атаки на SSH-ключи крайне мала из-за их длины: 2048 или 4096 бит. 

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

• Исключена фишинговая атака, когда вам предлагают ввести пароль на поддельном сервере. Закрытый ключ никогда не передается и не вводится вручную.

• Это просто, удобно и быстро, потому что не требует ввода длинного пароля.

Совет 2

Отключить доступ по паролю (команда PasswordAuthentication no) после настройки ключа. Это позволит уменьшить поверхность атаки.

Совет 3

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

Совет 4

Поменять дефолтные SSH-ключи и пароли, если используете готовые сборки библиотек установщиков или программных пакетов, например, Bitnami и TurnKey. В противном случае злоумышленник по SSH-отпечатку* сможет выявить использование вами неуникального SSH-ключа. 

*SSH-отпечаток — это MD5-сумма открытого ключа, которая отображается на экране после первой попытки подключения к серверу по SSH.

Советы для максимальной защиты

Совет 1

Использовать пароль (passphrase) для закрытого ключа SSH. Это защитит ключ в том случае, если злоумышленник получит доступ в систему, на которой хранится закрытый ключ.

Совет 2

Отключить баннер, который сообщает всем версию сервера SSH, номер протокола и версию ОС. Зная их злоумышленник может найти уязвимость этих версий ПО и проверить на прочность вашу защиту. Для снижения риска взлома также не забываем обновлять OpenSSH.

Совет 3

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

Совет 4

Использовать дополнительные сервисы:

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

• Защищенный jump-сервер или Privileged Access Management (PAM). Jump-сервер предоставляет возможность сетевого доступа к серверам только после аутентификации на защищенном сервере. А сервис PAM используется для ограничения непреднамеренных действий админов, записи SSH/RDP-сессий и быстрого расследования инцидентов. Особенно это важно на критических сегментах облачной инфраструктуры, к которым имеет доступ подрядчик с широкими правами. Мы же не знаем насколько защищена его инфраструктура и вполне возможно, вместо разработчика на аутсорсе к вам подключится хакер, желающий зашифровать ваши серверы и получить выкуп. Новости о взломах крупных компаний через цепочку поставок доказывают важность таких систем.

А что в Cloud.ru?

Для обеспечения защиты Cloud.ru использует сервис Advanced Host Security Service (HSS), который позволяет контролировать большое число параметров безопасности виртуальных машин и контейнеров, а также сканировать уязвимости и наличие зловредных программ в облаках и в локальных дата-центрах. А еще он блокирует атаки, закрывает доступ для зловредных файлов и рекомендует настройки для исправления уязвимостей. 

Также в Cloud.ru используется Cloud Advisor — платформа для защиты ресурсов и приложений в облаке. Он проверяет настройки SSH на всех виртуальных машинах в инфраструктуре на соответствие лучшим практикам CIS и рекомендациям ФСТЭК. Плюс позволяет получить финальный отчет без установки агентов за счет использования технологии безагентного сканирования DiskScan.

В качестве PAM-решения мы рекомендуем использовать сервис Cloud Bastion Host (CBH), который дает возможность гибко управлять SSH/RDP-подключениями, блокировать команды с высоким риском и выполняет видеозапись сессий.

Советы для базовой защиты

Совет 1

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

Совет 2

Использовать управление доступом на основе ролей (Role Based Access Control, RBAC) и запретить использование общих учетных записей. Это снизит вероятность ошибок и улучшит прозрачность управления. 

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

Совет 3

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

Совет 4

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

Советы для максимальной защиты

Совет 1

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

Совет 2

Регулярно аудировать пользователей, у которых есть ключи доступа (AK/SK) и отзывать более не используемые ключи доступа. Помните, что применение ключей доступа не требует 2FA, а потому более рискованно. 

А что в Cloud.ru?

Бесплатные сервисы на наших платформах, такие как Evolution Security Groups, позволяют ограничить доступ к серверу с приложением, предоставив его только известным IP-адресам и определенным портам. 

Другие бесплатные сервисы — Cloud Trace Service (CTS) и Аудит-логирование — фиксируют все действия в облачной консоли. С помощью их записей можно отслеживать изменения ресурсов, в том числе пользователей, а все файлы трассировки хранить в бакетах Object Storage Service.

Также Host Security Service (HSS) и Cloud Advisor на платформе Cloud.ru Advanced помогают выполнять и контролировать требования организации к аутентификации. Эти сервисы интегрирует несколько решений безопасности в одном пользовательском интерфейсе, упрощая управление защитой облака. Кроме сканирования уязвимостей, проверки небезопасной конфигурации, антивируса, инвентаризации и множества других возможностей в части контроля доступа, оба решения позволяют отслеживать соблюдение парольной политики и использование 2FA. При этом: 

• HSS работает на слое конфигурации сервера и контейнера, поэтому требует установку агента в операционной системе. Сервис располагает механизмами усиления аутентификации в ОС, сканирования файлов и образов, блокировки вредоносного ПО и попыток взлома сервера или среды контейнеров. 

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

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

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