Сегодня многие организации внедрили облачные технологии, такие как Microsoft Azure или Amazon Web Services (AWS), чтобы упростить управление своей ИТ-инфраструктурой и передать ее на аутсорсинг.
Но, как и любая другая облачная технология, Microsoft Azure — сложная тема. Для его безопасной настройки требуются значительные усилия, знание нескольких технологических областей, а также понимание экосистемы Azure.
Облачная среда Azure изначально поставляется с предварительно настроенными базовыми функциями, минимальной защитой и благоприятными настройками безопасности, чтобы просто работать «из коробки».
Не прилагая дополнительных усилий для его защиты, организации могут легко стать уязвимыми и подверженными кибератакам, направленным против их облачных инфраструктур.
В следующем разделе содержится список 20 основных уязвимостей и неправильных конфигураций, которые обычно обнаруживаются во время аудитов безопасности с учетными данными и проверок конфигурации облачных сред Microsoft Azure.
Сертифицированный означает, что аудиторы имели доступ к административной консоли Microsoft Azure (Azure Portal), предоставленный клиентами.
Обратите внимание, что список организован случайным образом, поэтому он больше похож на контрольный список, чем на упорядоченный ранжированный список.
По умолчанию для учетных записей хранения Azure разрешен доступ из любого места, включая Интернет. Такие настройки, естественно, представляют риск потенциального несанкционированного доступа к данным, утечки данных, эксфильтрации и т. д.
Всегда целесообразно применять принцип наименьших привилегий и ограничивать доступ к каждой учетной записи хранения только с выбранных IP-адресов, сетевых диапазонов или подсетей виртуальной сети (виртуальная сеть Azure).
Дополнительную информацию по этой теме можно найти здесь.
Эти настройки позволяют обеспечить безопасную (зашифрованную) передачу данных в хранилища. Это означает, что любые запросы по незащищенным протоколам, таким как HTTP или SMB без шифрования, будут отклонены.
Настройки по умолчанию — принимать любой протокол, что неизбежно открывает облачные хранилища для подслушивающих атак. Злоумышленник с хорошим положением потенциально может подслушать общение и получить доступ к конфиденциальной или частной информации, проходящей мимо.
Излишне говорить, что безопасная передача данных должна быть включена для всех учетных записей хранения.
Дополнительные сведения о безопасной передаче данных в Azure можно найти здесь.
Многофакторная проверка подлинности (MFA) должна быть обязательной для любого пользователя с правами администратора или записи для любых ресурсов Azure. Сюда входят такие роли, как:
Защита этих учетных записей с высоким уровнем привилегий с помощью MFA чрезвычайно важна, поскольку они имеют высокий риск стать целью злоумышленников.
При включенной MFA злоумышленнику придется скомпрометировать как минимум 2 разных механизма аутентификации, принадлежащих пользователю, что значительно снижает риск.
Обратите внимание, что Microsoft Azure поддерживает целый ряд решений и опций MFA, некоторые из них бесплатны, некоторые — по подписке в соответствии с премиальными планами, например:
В любом случае, как минимум, для всех пользователей с правами администратора должен применяться какой-либо вид MFA.
Все пользователи должны предоставить второй метод аутентификации, прежде чем они смогут присоединиться к устройству в Active Directory.
Это делается для того, чтобы в каталог не были добавлены мошеннические устройства с использованием учетных данных скомпрометированной учетной записи пользователя.
Риск заключается в том, что злоумышленник может подключить к организации неуправляемое, несовместимое и потенциально вредоносное устройство, которое затем может получить доступ к приложениям и другим ресурсам организации.
Дополнительную информацию об управлении устройствами можно найти здесь.
Улучшенный ценовой уровень «Стандартный» в Центре безопасности Azure имеет следующие дополнительные функции безопасности по сравнению с уровнем «Бесплатный» (базовый):
Это, безусловно, может помочь в защите от некоторых кибератак, и, несмотря на увеличение затрат, это то, что следует включить в каждой производственной среде.
Более подробную информацию о ценах на Центр безопасности и обо всех функциях безопасности можно найти здесь.
Расширенная стандартная защита от DDoS (распределенный отказ в обслуживании) обеспечивает следующие дополнительные средства защиты по сравнению с базовой защитой от DDoS:
Опять же, это то, что, безусловно, может помочь в защите от сетевых DDoS-атак. Стандартный DDoS должен быть включен во всех важных виртуальных сетях в каждой производственной среде.
Единственным недостатком является то, что это премиальная функция и, следовательно, с дополнительными затратами. Сведения о ценах на защиту Azure от атак DDoS можно найти здесь.
Излишне говорить, что шифрование дисков должно быть стандартом в каждой производственной среде, на рабочих станциях, серверах и в облаке.
В облачном мире это иногда называют «шифрованием в состоянии покоя», и Azure поддерживает шифрование диска для виртуальных машин Windows и Linux:
Как указано в документации, шифрование диска не должно влиять на производительность и не требует дополнительных затрат, поэтому нет оправдания тому, что шифрование не включено для всех дисков, включая:
Запуск производственной среды в облаке Azure без настройки уведомлений по электронной почте в Центре безопасности Azure — это серьезная ошибка.
Центр безопасности Azure всегда должен быть настроен с адресом электронной почты и/или номером телефона, чтобы получать уведомления об инцидентах, например. когда конкретный ресурс скомпрометирован.
Это то, что следует настраивать в каждой среде и всегда отслеживать с очень высоким приоритетом.
Мониторинг и оповещения Azure позволяют создавать настраиваемые оповещения с учетом конкретных потребностей служб, развернутых в облаке Azure.
Если это правильно настроено с соответствующими условиями оповещения, оно может предоставить ранние признаки проблем в среде, а не полагаться на встроенные функции безопасности Azure.
Поэтому в обзорах архитектуры Azure всегда ожидается наличие четко определенного списка настраиваемых предупреждений, относящихся к среде.
Вот примерный список того, что мы можем оповещать с помощью оповещений мониторинга Azure:
Дополнительные сведения о мониторинге и оповещении Azure можно найти здесь.
Распространенная неправильная конфигурация при определении правил брандмауэра в NSG (группах сетевой безопасности) заключается в использовании протокола «ЛЮБОЙ», источника «ЛЮБОЙ» или пункта назначения «ЛЮБОЙ».
Такая практика может привести к риску пропуска большего трафика, чем предполагалось. Для злоумышленников эти маленькие, казалось бы, безобидные детали часто играют важную роль, позволяя им проникнуть в помещение. Не давайте им этих возможностей.
Лучше всего всегда придерживаться принципа наименьших привилегий. Определите правила брандмауэра таким образом, чтобы разрешить только определенный протокол с четко определенными адресами источника и назначения.
Обратите внимание, что настоятельно рекомендуется включить брандмауэр уровня 7 в Azure, который поддерживает приложения. Брандмауэр уровня 7 обеспечивает расширенные функции безопасности во всей сети Azure, включая приложения.
Настройка общедоступного IP-адреса в Azure в качестве стандартного номера SKU (складской единицы) имеет следующие преимущества по сравнению с базовым номером SKU.
В случае Basic SKU основной проблемой безопасности является общая открытость. Если система не защищена брандмауэром, система, которой назначен общедоступный IP-адрес с базовым номером SKU, по умолчанию будет полностью открыта для внешнего мира.
Излишне говорить, что это крайне нежелательно в любой производственной среде. В производственной среде все общедоступные IP-адреса должны быть настроены как стандартные SKU с хорошо понятным сетевым потоком.
Обратите внимание, что эти настройки нельзя изменить после того, как IP-адрес настроен каким-либо образом. Поэтому для исправления этого может потребоваться планирование времени простоя и миграции.
Дополнительные сведения о базовом и стандартном SKU см. на этой странице.
На самом деле это не уязвимость системы безопасности сама по себе, но это серьезная неправильная конфигурация для любой общедоступной системы.
Если IP-адрес динамический, это означает, что он может измениться в любой момент времени, например. после перезагрузки или продления аренды DHCP. И когда это происходит с общедоступной системой, это может сломать все, что угодно в будущем. Например:
Это может вызвать ненужные проблемы с доступностью (например, DoS). Поэтому всегда настоятельно рекомендуется использовать статический IP-адрес для любой общедоступной службы.
Хранилище BLOB-объектов Azure — это мощный и удобный способ обмена данными в облаке. Он поддерживает следующие 3 варианта контроля доступа (уровня):
Настройка уровня доступа в качестве одного из двух последних вариантов (анонимный доступ на чтение), естественно, представляет угрозу безопасности несанкционированного доступа к данным, утечки данных, эксфильтрации и т. д.
В производственной среде все хранилища BLOB-объектов должны быть закрытыми, что запрещает любой анонимный доступ.
Дополнительные сведения об элементах управления доступом для контейнеров и больших двоичных объектов можно найти здесь.
Гостевые пользователи в Azure Active Directory (AD) — это учетные записи, которые обычно создаются для внешних пользователей, таких как поставщики, подрядчики, партнеры, клиенты и другие временные роли.
Они просто аутсайдеры, и поэтому разумно свести их число к минимуму.
Проблема в том, что некоторые организации со временем накапливают гостевых пользователей и забывают отозвать их доступ после того, как они больше не нужны, что очень рискованно.
Гостевые пользователи часто предоставляют средства для проникновения в среду, и это может привести к повышению привилегий и другим проблемам в облачной среде Azure.
Поэтому количество гостевых учетных записей следует всегда контролировать. На самом деле, CIS Benchmark даже рекомендует вообще не использовать гостевых пользователей.
Вот как мы можем найти всех гостевых пользователей с помощью Azure CLI:
az ad user list --query "[?additionalProperties.userType=='Guest']"
Наличие гостевых пользователей в Azure Active Directory — это одно, а предоставление им непомерных привилегий — другое.
По умолчанию гости имеют очень ограниченные привилегии по сравнению с полноправными пользователями-членами (см. различия здесь), но в Azure AD гости также могут иметь те же привилегии, что и пользователи-члены.
Это настраивается с помощью параметров внешней совместной работы, таких как показанные выше. Конфигурация, показанная выше, предоставит гостевым пользователям разрешения на:
С точки зрения безопасности это, конечно, крайне небезопасно, и его следует изменить как можно скорее, если только для этого нет очень-очень веских оснований.
Но опять же, рекомендуется вообще не иметь гостевых пользователей.
Административный портал Azure AD содержит большой объем конфиденциальной информации, и по умолчанию любой пользователь Azure AD может получить к ней доступ.
Это означает, что можно войти на https://portal.azure.com/ в качестве стандартного пользователя (участника) и просмотреть все настройки, сведения о других пользователях, членство в группах, приложения и т. д.
Это, конечно, серьезный риск для безопасности, и поэтому его следует ограничить.
Azure Identity Protection добавляет дополнительный уровень защиты для учетных записей пользователей в Active Directory, чтобы снизить риски входа, такие как:
Это определенно то, что помогает сделать среду Azure AD более безопасной, и поэтому настоятельно рекомендуется включить эту функцию.
Единственным недостатком является то, что это премиальная функция, которая требует дополнительных затрат (подробности о ценах см. здесь).
Дополнительные сведения о Azure Identity Protection можно найти здесь.
Наблюдатель за сетями Azure предоставляет важные инструменты диагностики и визуализации для понимания и устранения сетевых проблем в сети Azure.
Он также обеспечивает анализ сетевого потока для брандмауэра Azure NSG (группы сетевой безопасности), включая захват пакетов в конкретную виртуальную машину и из нее, а также многие другие диагностические функции.
По умолчанию это отключено, но рекомендуется включить его для всех регионов.
Вот как мы также можем проверить состояние Наблюдателя за сетями с помощью Azure CLI:
az network watcher list
Дополнительные сведения о Наблюдателе за сетями Azure см. в официальной документации здесь.
С точки зрения безопасности прием только безопасных (зашифрованных) HTTPS-соединений сегодня должен стать стандартом для всех веб-приложений — как внутренних, так и внешних (общедоступных).
Это добавляет столь необходимый уровень безопасности, конфиденциальности и приватности.
Если указанные выше параметры включены, каждый входящий незащищенный (незашифрованный) HTTP-запрос к данной веб-службе Azure будет перенаправлен на ее HTTPS-порт.
Это должно быть настроено для всех веб-служб Azure.
Та же стратегия должна применяться, когда речь идет о базах данных в Azure, например:
На всех серверах должна быть включена опция «Принудительно использовать SSL-соединение».
Теперь вы можете задаться вопросом, какой TLS следует выбрать?
И NIST (Национальный институт стандартов и технологий), и PCI (Индустрия платежных карт) не считают версии TLS 1.0 и 1.1 надежной криптографией.
Поэтому всегда следует выбирать как минимум версию TLS 1.2.
CIS Benchmark рекомендует включить следующие политики мониторинга в Центре безопасности Azure:
Все эти политики должны быть включены (установлены в «AuditIfNotExists») в каждой производственной среде. Эти политики обеспечивают необходимый мониторинг безопасности облачных компонентов Azure.
Включение этих политик также должно сопровождаться включенной «Автоматической инициализацией агента мониторинга»:
Это гарантирует, что агент мониторинга Azure будет подготовлен на всех существующих виртуальных машинах, развернутых в среде, а также на любых новых виртуальных машинах, созданных в будущем.
Оценка состояния безопасности облачных сред Microsoft Azure — непростая задача. Это очень сложная тема, требующая глубоких знаний во многих областях, выходящих далеко за рамки самого облака Azure.
Вся экосистема постоянно меняется — всегда развивается, внедряет новые функции, адаптируется к новым требованиям и так далее.
Я надеюсь, что эта статья предоставила хотя бы некоторые полезные сведения о мире аудита облачных вычислений Azure и предоставила вам некоторую практическую информацию, чтобы вы могли помочь своим клиентам сделать их облачную инфраструктуру более безопасной.
Чтобы взломать сеть Wi-Fi с помощью Kali Linux, вам нужна беспроводная карта, поддерживающая режим мониторинга…
Работа с консолью считается более эффективной, чем работа с графическим интерфейсом по нескольким причинам.Во-первых, ввод…
Конечно, вы также можете приобрести подписку на соответствующую услугу, но наличие SSH-доступа к компьютеру с…
С тех пор как ChatGPT вышел на арену, возросла потребность в поддержке чата на базе…
Если вы когда-нибудь окажетесь в ситуации, когда вам нужно взглянуть на спектр беспроводной связи, будь…
Elastic Security стремится превзойти противников в инновациях и обеспечить защиту от новейших технологий злоумышленников. В…