Сбор журналов аудита Microsoft 365
Журналы аудита выполняют важную роль в обслуживании, устранении неполадок и защите клиентов и внутренней инфраструктуры Microsoft 365. В связи с масштабом работы Microsoft 365 сбор и обработка журналов аудита должны быть стратегически управляемыми, чтобы обеспечить эффективный и эффективный мониторинг.
В этой статье представлен обзор методов ведения журнала аудита Microsoft 365, включая типы событий, которые записываются, какие сведения содержатся в каждом журнале, как применяются политики ведения журнала и как данные журнала защищены на всех этапах жизненного цикла.
Определение событий подлежащих аудиту
Команда безопасности Microsoft 365 отвечает за определение базовых журналов, которые должны собираться в Microsoft 365. Они поддерживают официальный список типов событий, которые должна записывать каждая система, а также данные, которые должно содержать каждое зарегистрированное событие.
Microsoft 365 собирает данные журнала из различных источников, включая:
- Журналы событий
- Журналы AppLocker
- Данные о производительности
- Данные System Center
- Записи сведений о вызовах
- Качество данных о взаимодействии
- Журналы веб-сервера IIS
- Журналы SQL Server
- Данные системного журнала
- Журналы аудита безопасности
Каждый из журналов в этом списке должен по крайней мере содержать следующие сведения для определения типа события, источника, расположения, результата, времени и связанной сущности:
- Source User ID
- Идентификатор целевого пользователя — в соответствии с типом события
- Отметка времени события (Дата и время)
- Сведения о событиях
- Тип
- Результат (успех или сбой)
- Подробные сведения — определяется для каждого типа события.
- Имя исходного & целевого узла — в соответствии с типом события
- Исходные & целевые сетевые адреса и протоколы — в соответствии с типом события
Список проверяемых событий и связанных данных определяется текущими оценками рисков, стандартами безопасности Microsoft 365, бизнес-требованиями и требованиями к соответствию. Команда Безопасности Microsoft 365 проверяет и обновляет список событий, подлежащих аудиту, чтобы учесть новые угрозы, изменения системы, уроки, полученные из прошлых инцидентов, и изменение требований к обеспечению соответствия.
Команды обслуживания могут определить дополнительные требования к ведению журнала для своей службы в дополнение к списку проверяемых событий, определенных командой безопасности Microsoft 365. События для конкретных приложений проверяются и обновляются во время проверок служб и на этапах планирования вех функций. Команда безопасности Microsoft 365 также помогает этим отдельным группам обслуживания управлять функциями аудита в соответствии с их конкретными потребностями. Проверяемые события уровня обслуживания проверяются и обновляются при внесении значительных изменений в систему.
В связи с масштабом корпорации Майкрософт объем захваченных данных должен быть сбалансирован с возможностью их хранения и обработки. Сбор информации о каждом возможном событии и его содержимом будет нецелесообразным как с точки зрения ресурса, так и с аналитической точки зрения. Благодаря выборке типов собираемых данных журналов корпорация Майкрософт может эффективно и эффективно поддерживать работоспособность и безопасность своих информационных систем.
Централизованное управление
Microsoft 365 централизованно применяет требования к ведению журнала с помощью политик, заданных группой безопасности Microsoft 365. Каждая система Microsoft 365 должна содержать настраиваемый агент ведения журнала Загрузчик данных Office (ODL), который устанавливается в рамках базового плана системы. ODL применяет централизованные политики ведения журнала и настраивается для сбора и отправки событий, определенных системой безопасности Microsoft 365, в централизованные службы для обработки и хранения.
ODL настроен для автоматического скрабирования всех сведений о конечных пользователях и отправки событий пакетными пакетами каждые пять минут. Все поля, содержащие данные клиента, такие как сведения о клиенте и сведения, идентифицируемые пользователем, удаляются и заменяются хэш-значением. Постоянные или необратимые изменения в содержимом записей аудита и упорядочение времени, помимо очистки, описанной ранее, запрещены.
Данные журналов передаются в собственное решение для мониторинга безопасности для анализа почти в реальном времени (NRT), проверки журналов на наличие потенциальных событий безопасности и показателей производительности. Журналы также отправляются во внутреннюю службу вычислений больших данных (Azure Data Lake) для долгосрочного хранения. Все передачи данных журнала выполняются через подключение TLS, проверенное FIPS 140-2, чтобы обеспечить конфиденциальность данных во время передачи.
Большинство данных журнала аудита, хранящихся в Azure Data Lake, хранятся по крайней мере один год для поддержки расследований инцидентов безопасности и соответствия нормативным требованиям к хранению. Группы обслуживания могут выбрать альтернативные сроки хранения в 90 дней или более для определенных типов данных журнала для удовлетворения потребностей своих приложений. Политики хранения журналов и резервного копирования Microsoft 365 обеспечивают доступ к данным журнала для расследования инцидентов, отчетности о соответствии требованиям законодательства и любым требованиям бизнеса.
Управление доступом.
Корпорация Майкрософт выполняет обширный мониторинг и аудит всех делегирований, привилегий и операций, выполняемых в Microsoft 365. Доступ к данным Microsoft 365, хранящимся в Azure Data Lake, ограничен авторизованным персоналом, а все запросы на управление доступом и утверждения записываются для анализа событий безопасности. Корпорация Майкрософт проверяет уровни доступа практически в режиме реального времени, чтобы убедиться, что доступ к ее системам могут получить только пользователи, которые имеют авторизованные бизнес-обоснования и соответствуют требованиям. Все разрешенные доступы отслеживаются для уникального пользователя.
Корпорация Майкрософт ограничивает управление журналами аудита ограниченным подмножеством членов группы безопасности, отвечающих за функциональные возможности аудита. Внутренняя философия управления доступом Майкрософт вращается вокруг принципов JIT (JIT) и JIT(JEA). Таким образом, команда безопасности не имеет постоянного административного доступа к Azure Data Lake, и все изменения записываются и проверяются.