Безопасность данных журналов Azure Monitor

  • Статья

В этой статье объясняется, как Azure Monitor собирает, обрабатывает и защищает данные журнала, а также описывает функции безопасности, которые можно использовать для обеспечения дополнительной защиты среды Azure Monitor. Сведения в этой статье относятся к журналам Azure Monitor и дополняют информацию в Центре управления безопасностью Azure.

Служба журналов Azure Monitor безопасно управляет облачными данными с использованием следующих методов:

  • Разделение данных
  • Хранение данных
  • Физическая безопасность
  • Управление инцидентами
  • Соответствие нормативным требованиям
  • Соответствие сертификатам и стандартам безопасности

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

Безопасная отправка данных с помощью TLS 1.2

Чтобы обеспечить безопасность передаваемых в Azure Monitor данных, настоятельно рекомендуем настроить для агента использование протокола TLS как минимум версии 1.2. Более старые версии протоколов TLS/SSL оказались уязвимы. Хотя они все еще используются для обеспечения обратной совместимости, применять их не рекомендуется, так как представители отрасли стремятся как можно скорее отказаться от их поддержки.

Совет по стандартам безопасности PCI установил крайний срок (30 июня 2018 года) для отказа от старых версий протоколов TLS или SSL и перехода на более безопасные протоколы. Как только Azure прекратит поддержку предыдущих версий, агенты, не поддерживающие протокол TLS версии минимум 1.2, не смогут отправлять данные в журналы Azure Monitor.

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

Поиск руководств в соответствии с платформой

Платформа или язык Поддержка Дополнительные сведения
Linux Как правило, дистрибутивы Linux для поддержки протокола TLS 1.2 используют OpenSSL. Убедитесь, что ваша версия OpenSSL поддерживается, проверив журнал изменений OpenSSL.
Windows 8.0–10 Поддерживается и включена по умолчанию. Убедитесь, что вы все еще используете параметры по умолчанию.
Windows Server 2012–2016 Поддерживается и включена по умолчанию. Убедитесь, что вы все еще используете параметры по умолчанию
Windows 7 с пакетом обновления 1 и Windows Server 2008 R2 с пакетом обновления 1 Поддерживается, но не включена по умолчанию. Информацию о том, как ее включить, см. на странице Transport Layer Security (TLS) registry settings (Параметры реестра TLS).

Разделение данных

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

Хранение данных

Индексированные данные поиска по журналу хранятся и удерживаются согласно ценовому плану. Дополнительные сведения см. на странице цен на Log Analytics.

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

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

Решение Типы данных
Capacity and Performance Данные производительности и метаданные.
Управление обновлениями Метаданные и данные о состоянии.
Управление журналами; Пользовательские журналы событий, журналы событий Windows и журналы IIS.
Отслеживание изменений Инвентаризация программного обеспечения, метаданные управляющей программы Linux и службы Windows, метаданные файлов Windows и Linux
Оценка SQL и Active Directory. Данные WMI, данные реестра, данные производительности и результаты динамического управления SQL Server.

В следующей таблице показаны примеры типов данных:

Data type Поля
Оповещение Alert Name, Alert Description, BaseManagedEntityId, Problem ID, IsMonitorAlert, RuleId, ResolutionState, Priority, Severity, Category, Owner, ResolvedBy, TimeRaised, TimeAdded, LastModified, LastModifiedBy, LastModifiedExceptRepeatCount, TimeResolved, TimeResolutionStateLastModified, TimeResolutionStateLastModifiedInDB, RepeatCount
Конфигурация CustomerID, AgentID, EntityID, ManagedTypeID, ManagedTypePropertyID, CurrentValue, ChangeDate
Событие EventId, EventOriginalID, BaseManagedEntityInternalId, RuleId, PublisherId, PublisherName, FullNumber, Number, Category, ChannelLevel, LoggingComputer, EventData, EventParameters, TimeGenerated, TimeAdded
Примечание. Log Analytics собирает данные событий с настраиваемыми полями при их записи в журнал событий Windows.
Метаданные BaseManagedEntityId, ObjectStatus, OrganizationalUnit, ActiveDirectoryObjectSid, PhysicalProcessors, NetworkName, IPAddress, ForestDNSName, NetbiosComputerName, VirtualMachineName, LastInventoryDate, HostServerNameIsVirtualMachine, IP Address, NetbiosDomainName, LogicalProcessors, DNSName, DisplayName, DomainDnsName, ActiveDirectorySite, PrincipalName, OffsetInMinuteFromGreenwichTime
Производительность ObjectName, CounterName, PerfmonInstanceName, PerformanceDataId, PerformanceSourceInternalID, SampleValue, TimeSampled, TimeAdded
Состояние StateChangeEventId, StateId, NewHealthState, OldHealthState, Context, TimeGenerated, TimeAdded, StateId2, BaseManagedEntityId, MonitorId, HealthState, LastModified, LastGreenAlertGenerated, DatabaseTimeModified

Физическая безопасность

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

Управление инцидентами

В Azure Monitor предусмотрен процесс управления инцидентами, которого придерживаются все службы Майкрософт. Он включает в себя следующие основные этапы:

  • Использование модели разделения ответственности: частично ответственность за безопасность лежит на корпорации Майкрософт, а частично — на клиенте.
  • Управление инцидентами безопасности Azure:
    • Начало расследования при обнаружении инцидента
    • Дежурный специалист группы реагирования на инциденты оценивает влияние и серьезность инцидента. Исходя из полученных данных, инцидент передается или не передается группе реагирования на инциденты для последующей оценки.
    • Ответственные специалисты диагностируют инцидент, чтобы провести техническое или экспертное расследование, определить стратегии сдерживания, устранения и решения. Если группа безопасности полагает, что к данным клиента был получен незаконный или несанкционированный доступ, в это же время будут предприняты действия для уведомления клиента об инциденте.
    • Стабилизация и восстановление после инцидента. Группа реагирования на инциденты создает план восстановления, чтобы устранить проблему. Действия по сдерживанию проблемы, в частности помещение затронутых систем под карантин, могут быть предприняты немедленно и выполняться параллельно с диагностикой. Действия по устранению проблем могут также выполняться по окончании периода риска.
    • Закрытие инцидента и последующий анализ. Группа реагирования на инциденты составляет отчет с подробными сведениями об инциденте для его последующего анализа. Цель этого — избежать повторения происшествия, изменив политики, процедуры и процессы.
  • Уведомление клиентов об инцидентах безопасности:
    • Определяется ряд клиентов, которых затронул инцидент. Им предоставляется максимально подробная информация о случившемся.
    • На этом этапе для клиентов создается уведомление, содержащее достаточно подробные сведения для того, чтобы они могли изучить проблему со своей стороны и выполнить свои обязательства перед конечными пользователями, не задерживая процесс уведомления.
    • При необходимости инцидент подтверждается или объявляется.
    • Клиентов уведомляют об инциденте в соответствии с юридическими или договорными обязательствами без какой-либо необоснованной задержки. Клиенты получают уведомления об инцидентах безопасности через своих администраторов любым способом, выбранным корпорацией Майкрософт, включая электронную почту.
  • Готовность и обучение команды:
    • Персонал корпорации Майкрософт проходит обязательное обучение в сфере обеспечения безопасности и обнаружения инцидентов, что помогает им выявлять потенциальные проблемы безопасности и сообщать о них.
    • Операторы, работающие в службе Microsoft Azure, проходят дополнительное обучение, так как они имеют доступ к системам, содержащим данные клиента.
    • Группа Майкрософт по реагированию на инциденты получает обучение в соответствии с выполняемыми ролями.

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

Дополнительные сведения о том, как корпорация Майкрософт реагирует на угрозы безопасности, см. в статье Microsoft Azure Security Response in the Cloud (Реагирование на нарушения безопасности в облаке Microsoft Azure).

Соответствие нормативным требованиям

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

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

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

Совету директоров корпорации Майкрософт сообщают обо всех программах информационной безопасности в годовом отчете.

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

Сертификации и аттестации

Azure Log Analytics соответствует следующим требованиям:

Примечание

В некоторых сертификациях и аттестациях служба Azure Monitor указывается под прежним названием Operational Insights.

Безопасность потока данных для облачных вычислений

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

Схема сбора данных и обеспечения безопасности в Azure Monitor

1. Регистрация в Azure Monitor и сбор данных

Чтобы организация могла отправлять данные в журналы Azure Monitor, настройте агент Windows или Linux на виртуальных машинах Azure или на физических компьютерах в среде или другом поставщике облачных служб. При использовании Operations Manager из группы управления можно настроить агент Operations Manager. Пользователям (вам, другим индивидуальным пользователям или группе людей) необходимо создать одну или несколько рабочих областей Log Analytics и зарегистрировать агентов с помощью одной из следующих учетных записей:

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

Группа управления Operations Manager устанавливает подключение к службе Azure Monitor. Затем вы настраиваете системы, управляемые агентами в группе управления, которым разрешено собирать и отправлять данные в службу. В зависимости от активированных решений данные из них отправляются в службу Azure Monitor непосредственно с сервера управления Operations Manager или непосредственно из агента (в зависимости от объема данных, собранных в управляемой агентом системе). Все системы, не отслеживаемые Operations Manager, безопасно подключаются к службе Azure Monitor напрямую.

Все данные, передаваемые между подключенными системами и службой Azure Monitor, шифруются. Для шифрования используется протокол TLS (HTTPS). Благодаря соблюдению жизненного цикла разработки защищенных приложений (Майкрософт) служба Log Analytics соответствует последним усовершенствованиям протоколов шифрования.

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

2. Отправка данных от агентов

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

В Operations Manager группа управления, зарегистрированная в рабочей области Log Analytics, устанавливает безопасное подключение HTTPS с сервером управления Operations Manager.

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

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

Кэшированные данные Windows или агента сервера управления защищены хранилищем учетных данных операционной системы. Если в течение 2 часов служба не может обработать данные, агенты помещают их в очередь. Если очередь переполняется, агент начинает удалять данные по типам, начиная с данных производительности. Предел очереди агента — это раздел реестра. При необходимости его можно изменить. Собранные данные сжимаются и отправляются в службу, минуя группу управления Operations Manager базы данных, то есть к ним не применяется никакой дополнительной нагрузки. После отправки собранных данных они удаляются из кэша.

Как описано выше, данные с сервера управления или подключенных напрямую агентов отправляются по протоколу TLS в центры обработки данных Microsoft Azure. Для дополнительной защиты данных можно также использовать ExpressRoute. ExpressRoute — это способ напрямую подключаться к Azure из существующей глобальной сети, например MPLS VPN, предоставленной поставщиком сетевой службы. Дополнительные сведения см. в статье об ExpressRoute.

3. Служба Azure Monitor получает и обрабатывает данные

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

Период хранения собранных данных в базе данных зависит от выбранного тарифного плана. На бесплатном уровне собранные данные доступны в течение семи дней. На платном уровне собранные данные по умолчанию доступны в течение 31 дня, но этот период можно продлить до 730 дней. Данные хранятся в зашифрованном виде в хранилище Azure для обеспечения конфиденциальности данных, а данные реплицируются в локальном регионе с помощью локально избыточного хранилища (LRS) или хранилища, избыточного между зонами (ZRS) в поддерживаемых регионах. Данные за последние две недели также хранятся в кэше на базе SSD. Этот кэш шифруется.

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

4. Использование Azure Monitor для доступа к данным

Чтобы получить доступ в рабочую область Log Analytics, войдите на портал Azure с помощью учетной записи организации или учетной записи Майкрософт, настроенной ранее. Весь трафик между порталом и службой Azure Monitor отправляется через защищенный канал HTTPS. При использовании портала идентификатор сеанса создается в клиенте пользователя (веб-браузер), а данные хранятся в локальном кэше до завершения сеанса. После завершения сеанса кэш удаляется. Файлы cookie со стороны клиента, не содержащие сведений, по которым можно установить личность, не удаляются автоматически. Файлы cookie сеанса помечены как HTTPOnly и защищены. По истечении предопределенного периода простоя сеанс работы с порталом Azure прерывается.

Дополнительные компоненты безопасности

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

  • Ключи, управляемые клиентом (безопасность). Вы можете использовать ключи, управляемые клиентом, для шифрования данных, отправляемых в рабочие области log Analytics. Для этого нужно использовать Azure Key Vault.
  • Частное или управляемое клиентом хранилище. Управляйте персональной зашифрованной учетной записью хранения и настройте Azure Monitor для ее использования в качестве хранилища данных мониторинга
  • Сети Приватного канала. Приватный канал Azure позволяет безопасно связывать службы Azure PaaS (в том числе Azure Monitor) с виртуальной сетью с помощью частных конечных точек.
  • Защищенное хранилище Azure. Предоставляет клиентам интерфейс для просмотра и утверждения или отклонения запросов на доступ к данным клиента. Этот интерфейс позволяет специалисту Майкрософт получить доступ к данным клиента в рамках процессов поддержки.

Защита от незаконного изменения и неизменяемость

Azure Monitor — это платформа данных только для добавления, но включает в себя подготовку к удалению данных для обеспечения соответствия требованиям. Вы можете установить блокировку в рабочей области Log Analytics , чтобы заблокировать все действия, которые могут удалять данные: очистку, удаление таблиц и изменение хранения данных на уровне таблицы или рабочей области. Однако эту блокировку по-прежнему можно снять.

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

Дальнейшие действия