20 основных уязвимостей и неправильных конфигураций Microsoft Azure

Сегодня многие организации внедрили облачные технологии, такие как Microsoft Azure или Amazon Web Services (AWS), чтобы упростить управление своей ИТ-инфраструктурой и передать ее на аутсорсинг.

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

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

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

Топ-20 уязвимостей Microsoft Azure

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

Сертифицированный означает, что аудиторы имели доступ к административной консоли Microsoft Azure (Azure Portal), предоставленный клиентами.

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

1. Учетные записи хранения, доступные из Интернета

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

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

Дополнительную информацию по этой теме можно найти здесь.

2. Разрешены учетные записи хранения с небезопасным переносом

Эти настройки позволяют обеспечить безопасную (зашифрованную) передачу данных в хранилища. Это означает, что любые запросы по незащищенным протоколам, таким как HTTP или SMB без шифрования, будут отклонены.

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

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

Дополнительные сведения о безопасной передаче данных в Azure можно найти здесь.

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

Многофакторная проверка подлинности (MFA) должна быть обязательной для любого пользователя с правами администратора или записи для любых ресурсов Azure. Сюда входят такие роли, как:

• • • • Администраторы
      • Соадминистраторы службы
      • Владельцы подписки
      • Авторы

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

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

Обратите внимание, что Microsoft Azure поддерживает целый ряд решений и опций MFA, некоторые из них бесплатны, некоторые — по подписке в соответствии с премиальными планами, например:

• • • • Многофакторная идентификация Azure
      • Политики условного доступа

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

4. Отсутствие многофакторной аутентификации для присоединения устройств

Все пользователи должны предоставить второй метод аутентификации, прежде чем они смогут присоединиться к устройству в Active Directory.

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

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

Дополнительную информацию об управлении устройствами можно найти здесь.

5. Центр безопасности Azure с базовым ценовым уровнем

Улучшенный ценовой уровень «Стандартный» в Центре безопасности Azure имеет следующие дополнительные функции безопасности по сравнению с уровнем «Бесплатный» (базовый):

• • • • Каналы обнаружения угроз и аналитики угроз
      • Обнаружение аномалий, анализ поведения и предупреждения системы безопасности
      • Машинное обучение с потенциалом для выявления новых атак и эксплойтов нулевого дня
      • Сканирование уязвимостей и управление уязвимостями всей инфраструктуры
      • Расширенный контроль доступа и приложений для блокировки вредоносных программ и других сетевых атак

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

Более подробную информацию о ценах на Центр безопасности и обо всех функциях безопасности можно найти здесь.

6. Виртуальные сети Azure с базовой защитой от атак DDoS

Расширенная стандартная защита от DDoS (распределенный отказ в обслуживании) обеспечивает следующие дополнительные средства защиты по сравнению с базовой защитой от DDoS:

• • • • Телеметрия в реальном времени и мониторинг трафика
      • Оповещения и уведомления о текущих атаках
      • Адаптивная настройка и профилирование трафика
      • Детальный анализ атаки

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

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

7. Незашифрованные ОС и диски данных

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

В облачном мире это иногда называют «шифрованием в состоянии покоя», и Azure поддерживает шифрование диска для виртуальных машин Windows и Linux:

• • • • В Windows используется BitLocker.
      • В Linux используется DM-Crypt.

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

• • • • диск ОС
      • Диски данных
      • Неподключенные диски

8. В Центре безопасности отсутствуют уведомления по электронной почте.

Запуск производственной среды в облаке Azure без настройки уведомлений по электронной почте в Центре безопасности Azure — это серьезная ошибка.

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

Это то, что следует настраивать в каждой среде и всегда отслеживать с очень высоким приоритетом.

9. Оповещения журналов отсутствуют в Azure Monitor

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

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

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

Вот примерный список того, что мы можем оповещать с помощью оповещений мониторинга Azure:

• • • • Значения показателей
      • Журнал поисковых запросов
      • События журнала активности
      • Работоспособность базовой платформы Azure
      • Тесты на доступность сайта

Дополнительные сведения о мониторинге и оповещении Azure можно найти здесь.

10. Входящие правила Azure NSG настроены на ЛЮБОЙ

Распространенная неправильная конфигурация при определении правил брандмауэра в NSG (группах сетевой безопасности) заключается в использовании протокола «ЛЮБОЙ», источника «ЛЮБОЙ» или пункта назначения «ЛЮБОЙ».

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

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

Обратите внимание, что настоятельно рекомендуется включить брандмауэр уровня 7 в Azure, который поддерживает приложения. Брандмауэр уровня 7 обеспечивает расширенные функции безопасности во всей сети Azure, включая приложения.

11. Общедоступные IP-адреса, настроенные как базовые SKU.

Настройка общедоступного IP-адреса в Azure в качестве стандартного номера SKU (складской единицы) имеет следующие преимущества по сравнению с базовым номером SKU.

• • • • Действительно статический IP-адрес
      • Безопасен по умолчанию, закрыт для входящего трафика
      • Обеспечивает резервирование зон и зонирование (региональное, географическое и т. д.)
      • Обеспечивает масштабируемость в будущем

В случае Basic SKU основной проблемой безопасности является общая открытость. Если система не защищена брандмауэром, система, которой назначен общедоступный IP-адрес с базовым номером SKU, по умолчанию будет полностью открыта для внешнего мира.

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

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

Дополнительные сведения о базовом и стандартном SKU см. на этой странице.

12. Динамические IP-адреса для общедоступных сервисов

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

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

• • • • DNS-записи
      • Мониторинг и регистрация предупреждений
      • Системная интеграция и совместимость

Это может вызвать ненужные проблемы с доступностью (например, DoS). Поэтому всегда настоятельно рекомендуется использовать статический IP-адрес для любой общедоступной службы.

13. Хранилище BLOB-объектов с анонимным уровнем доступа для чтения

Хранилище BLOB-объектов Azure — это мощный и удобный способ обмена данными в облаке. Он поддерживает следующие 3 варианта контроля доступа (уровня):

1. Частный (без анонимного доступа)
2. Blob (анонимный доступ для чтения только для больших двоичных объектов)
3. Контейнер (анонимный доступ на чтение для контейнеров и BLOB-объектов)

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

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

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

14. Большое количество гостевых пользователей в Azure AD.

Гостевые пользователи в Azure Active Directory (AD) — это учетные записи, которые обычно создаются для внешних пользователей, таких как поставщики, подрядчики, партнеры, клиенты и другие временные роли.

Они просто аутсайдеры, и поэтому разумно свести их число к минимуму.

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

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

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

Вот как мы можем найти всех гостевых пользователей с помощью Azure CLI:

az ad user list --query "[?additionalProperties.userType=='Guest']"

15. Небезопасные настройки гостевого пользователя в Azure AD

Наличие гостевых пользователей в Azure Active Directory — это одно, а предоставление им непомерных привилегий — другое.

По умолчанию гости имеют очень ограниченные привилегии по сравнению с полноправными пользователями-членами (см. различия здесь), но в Azure AD гости также могут иметь те же привилегии, что и пользователи-члены.

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

• • • • Перечислить всех остальных пользователей и группы (включая участников)
      • Чтение свойств всех зарегистрированных и корпоративных приложений
      • Приглашайте других пользователей извне в организацию

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

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

16. Неограниченный доступ к порталу администрирования Azure AD.

Административный портал Azure AD содержит большой объем конфиденциальной информации, и по умолчанию любой пользователь Azure AD может получить к ней доступ.

Это означает, что можно войти на https://portal.azure.com/ в качестве стандартного пользователя (участника) и просмотреть все настройки, сведения о других пользователях, членство в группах, приложения и т. д.

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

17. Функция защиты идентификации Azure отключена.

Azure Identity Protection добавляет дополнительный уровень защиты для учетных записей пользователей в Active Directory, чтобы снизить риски входа, такие как:

• • • • Нетипичное путешествие пользователя
      • IP-адрес источника, связанного с вредоносным ПО
      • Утечка учетных данных пользователя
      • Попытки распыления пароля
      • Анонимный исходный IP-адрес (например, Tor)

Это определенно то, что помогает сделать среду Azure AD более безопасной, и поэтому настоятельно рекомендуется включить эту функцию.

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

Дополнительные сведения о Azure Identity Protection можно найти здесь.

18. Наблюдатель за сетями Azure отключен.

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

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

По умолчанию это отключено, но рекомендуется включить его для всех регионов.

Вот как мы также можем проверить состояние Наблюдателя за сетями с помощью Azure CLI:

az network watcher list

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

19. Только HTTPS-трафик не применяется для всех веб-приложений.

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

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

Если указанные выше параметры включены, каждый входящий незащищенный (незашифрованный) HTTP-запрос к данной веб-службе Azure будет перенаправлен на ее HTTPS-порт.

Это должно быть настроено для всех веб-служб Azure.

Та же стратегия должна применяться, когда речь идет о базах данных в Azure, например:

• • • • сервер MySQL
      • PostreSQL сервер

На всех серверах должна быть включена опция «Принудительно использовать SSL-соединение».

Теперь вы можете задаться вопросом, какой TLS следует выбрать?

И NIST (Национальный институт стандартов и технологий), и PCI (Индустрия платежных карт) не считают версии TLS 1.0 и 1.1 надежной криптографией.

Поэтому всегда следует выбирать как минимум версию TLS 1.2.

20. Политика мониторинга в Центре безопасности Azure

CIS Benchmark рекомендует включить следующие политики мониторинга в Центре безопасности Azure:

• • • • Вычисления и приложения:
        • Обновления системы
        • Уязвимости ОС
        • Защита конечных точек
        • Шифрование диска
        • Оценка уязвимости
        • Адаптивное управление приложениями
      • Сеть:
        • Группы безопасности сети (NSG)
        • Брандмауэр веб-приложений (WAF)
        • Брандмауэр следующего поколения (NGFW)
      • Данные:
        • Шифрование хранилища
        • Аудит SQL
        • SQL-шифрование

Все эти политики должны быть включены (установлены в «AuditIfNotExists») в каждой производственной среде. Эти политики обеспечивают необходимый мониторинг безопасности облачных компонентов Azure.

Включение этих политик также должно сопровождаться включенной «Автоматической инициализацией агента мониторинга»:

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

Вывод

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

Вся экосистема постоянно меняется — всегда развивается, внедряет новые функции, адаптируется к новым требованиям и так далее.

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