Безопасность данных в журналах 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.

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

Тип данных	Поля
Предупреждение	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
State	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 соответствует следующим требованиям:

• ISO/IEC 27001;
• ISO/IEC 27018:2014
• ISO 22301
• Стандарт безопасности данных индустрии платежных карт (PCI DSS), разработанный Советом по стандартам безопасности индустрии платежных карт;
• элементы управления организацией служб (SOC) 1 типа 1 и SOC 2 типа 1;
• требования HIPAA и HITECH для компаний, заключивших Соглашение с бизнес-партнерами HIPAA.
• Общие условия проектирования для Windows
• Защищенные информационные системы корпорации Майкрософт
• Azure Monitor в качестве службы Azure использует компоненты, которые отвечают нормативным требованиям Azure. Дополнительные сведения см. на странице центра соответствия требованиям Майкрософт.

Примечание.

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

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

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

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

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

• идентификатор организации;
• Учетная запись Майкрософт — Outlook, Office Live, MSN.

Рабочая область 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 или агента сервера управления защищены хранилищем учетных данных операционной системы. Если служба не может обрабатывать данные через два часа, агенты будут очереди данных. Если очередь переполняется, агент начинает удалять данные по типам, начиная с данных производительности. Предел очереди агента — это раздел реестра. При необходимости его можно изменить. Собранные данные сжимаются и отправляются в службу, обходя базы данных группы управления Operations Manager, поэтому они не добавляют в них нагрузку. После отправки собранных данных он удаляется из кэша.

Как описано выше, данные с сервера управления или подключенных напрямую агентов отправляются по протоколу TLS в центры обработки данных Microsoft Azure. Для дополнительной защиты данных можно также использовать ExpressRoute. ExpressRoute — это способ напрямую подключаться к Azure из существующей глобальной сети, например MPLS VPN, предоставленной поставщиком сетевой службы. Дополнительные сведения см. в разделе "ExpressRoute" и "Использует ли трафик агента" для подключения Azure 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 шифруются с помощью ключей, управляемых Майкрософт. Ключи шифрования, управляемые клиентом, можно использовать для защиты данных и сохраненных запросов в рабочих областях. Управляемые клиентом ключи в Azure Monitor обеспечивают большую гибкость управления доступом к журналам.

После настройки новые данные, передаваемые в связанные рабочие области, шифруются с помощью ключа, хранящегося в Azure Key Vault, или управляемого azure Key Vault HSM.

Частное хранилище

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

Сетевое взаимодействие с Приватным каналом

Приватный канал Azure сети позволяют безопасно связывать службы платформы Azure как услуга (PaaS), включая Azure Monitor, к виртуальной сети с помощью частных конечных точек.

Защищенное хранилище для Microsoft Azure

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

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

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

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

Часто задаваемые вопросы

В этом разделы приводятся ответы на часто задаваемые вопросы.

Использует ли трафик агента подключение Azure ExpressRoute?

Трафик в Azure Monitor направляется по пиринговому каналу ExpressRoute. Различные типы трафика ExpressRoute описаны в документации по ExpressRoute.