Управление личными данными в журналах Azure Monitor и Аналитика приложений

  • Статья

Хранилище данных Log Analytics может содержать персональные данные. Данные Application Insights хранятся в разделе Log Analytics. В этой статье описано, где Log Analytics и Application Insights хранят персональные данные и как управлять этими данными.

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

Примечание.

См. сведения о просмотре и удалении персональных данных в руководстве по созданию запросов субъектов данных Azure в соответствии с GDPR. Дополнительные сведения о GDPR см. в разделе, посвященном GDPR, в Центре управления безопасностью Майкрософт и на портале Service Trust Portal.

Стратегия обработки персональных данных

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

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

Где искать персональные данные в Log Analytics

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

Примечание.

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

Данные журнала

  • IP-адреса. Log Analytics собирает разные сведения об IP-адресах в нескольких таблицах. Например, следующий запрос показывает все таблицы, в которых адреса IPv4 были собраны за последние 24 часа.

    search * 
| where * matches regex @'\b((25[0-5]|2[0-4][0-9]|[01]?[0-9][0-9]?)(\.|$)){4}\b' //RegEx originally provided on https://stackoverflow.com/questions/5284147/validating-ipv4-addresses-with-regexp
| summarize count() by $table

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

    search "<username or user ID>"

    Не забывайте искать не только понятные имена пользователей, но и идентификаторы GUID, которые связаны с конкретными пользователями.

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

  • Пользовательские данные. Log Analytics позволяет собирать пользовательские данные с помощью пользовательских журналов, пользовательских полей, API сборщика данных HTTP и как часть системных журналов событий. Проверьте все пользовательские данные на предмет наличия персональных данных.

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

Данные приложения

  • IP-адреса. Хотя Application Insights маскирует все поля IP-адреса по умолчанию, используя 0.0.0.0, довольно часто это значение переопределяется фактическим IP-адресом пользователя для сохранения информации о сеансе. Используйте приведенный ниже запрос, чтобы найти любую таблицу, содержащую значения в столбце IP-адреса, отличные от 0.0.0.0, за последние 24 часа.

    search client_IP != "0.0.0.0"
| where timestamp > ago(1d)
| summarize numNonObfuscatedIPs_24h = count() by $table

  • Идентификаторы пользователей. По умолчанию Application Insights использует случайно сгенерированные идентификаторы для отслеживания пользователей и сеансов в таких полях, как session_Id, user_Id, user_AuthenticatedId, user_AccountId и customDimensions. Однако обычно эти поля переопределяются идентификатором, который более релевантн для приложения, например имена пользователей или идентификаторы GUID Microsoft Entra. Эти идентификаторы часто считаются персональными данными. Мы рекомендуем маскировать или анонимизировать эти идентификаторы.

  • Пользовательские данные. Application Insights позволяет добавлять набор пользовательских измерений к любому типу данных. Используйте следующий запрос, чтобы определить специальные параметры, собранные за последние 24 часа.

    search * 
| where isnotempty(customDimensions)
| where timestamp > ago(1d)
| project $table, timestamp, name, customDimensions

  • Данные в памяти и в процессе передачи. Application Insights отслеживает исключения, запросы, вызовы зависимостей и трассировки. Персональные данные часто находятся на уровне кода и HTTP-вызова. Просмотрите таблицы исключений, запросов, зависимостей и трассировок, чтобы определить такие данные. Везде, где возможно, используйте инициализаторы телеметрии для маскировки таких данных.

  • Записи Snapshot Debugger. Функция Snapshot Debugger в Application Insights позволяет получать моментальные снимки для отладки при возникновении любого исключения в рабочем экземпляре приложения. Моментальные снимки предоставляют полную трассировку стека, указывающую на исключения и значения локальных переменных на каждом шаге в стеке. К сожалению, эта функция не позволяет выборочно удалять точки моментального снимка или осуществлять программный доступ к данным в моментальном снимке. Поэтому, если скорость сохранения моментальных снимков по умолчанию не соответствует вашим требованиям, мы рекомендуем отключить эту функцию.

Экспорт и удаление персональных данных

Мы настоятельно рекомендуем вам изменить структуру политики сбора данных, чтобы остановить сбор персональных данных, замаскировать или обезличить персональные данные или иным образом изменить такие данные, пока они больше не будут считаться персональными. При обработке персональных данных вы понесете расходы на определение и автоматизацию стратегии, создание интерфейса, через который ваши клиенты взаимодействуют со своими данными, и текущее обслуживание. Это также требует значительных вычислительных ресурсов для Log Analytics и Application Insights, а большой объем одновременных вызовов Query или Purge API может негативно сказаться на всех других взаимодействиях с функциями Log Analytics. Но если вам нужно собирать персональные данные, следуйте рекомендациям, приведенным в этом разделе.

Внимание

Хотя большинство операций по очистке выполняются намного быстрее, в официальном соглашении об уровне обслуживания для завершения операций очистки указано 30 дней из-за значительного влияния на платформу данных. Это соглашение об уровне обслуживания соответствует требованиям GDPR. Это автоматизированный процесс, поэтому ускорить операцию нельзя.

Просмотр и экспорт

Используйте API запросов Log Analytics или API запросов Application Insights для просмотра и экспорта запросов данных.

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

Удаление

Предупреждение

Удаление данных в Log Analytics носит разрушительный характер и необратимо! Выполняйте эту операцию чрезвычайно осторожно.

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

Очистка — это операция с высокими привилегиями. Предоставьте роль Data Purger в Azure Resource Manager осторожно из-за потенциальной потери данных.

Для управления системными ресурсами мы ограничиваем запросы на очистку до 50 запросов в час. Выполняйте запросы на очистку пакетом путем отправки одной команды, предикат которой включает все идентификаторы пользователей, требующих очистки. Используйте оператор in, чтобы указать несколько удостоверений. Выполните запрос перед выполнением запроса на очистку, чтобы проверить ожидаемые результаты.

Внимание

Использование API очистки Log Analytics или Application Аналитика не влияет на затраты на хранение. Чтобы снизить затраты на хранение, необходимо уменьшить срок хранения данных.

Данные журнала

  • API POST очистки рабочей области принимает объект, определяющий параметры данных для удаления, и возвращает ссылочный GUID.

  • API POST получения состояния очистки возвращает заголовок x-ms-status-location, который включает URL-адрес, который вы можете вызвать, чтобы определить состояние операции очистки. Например:

    x-ms-status-location: https://management.azure.com/subscriptions/[SubscriptionId]/resourceGroups/[ResourceGroupName]/providers/Microsoft.OperationalInsights/workspaces/[WorkspaceName]/operations/purge-[PurgeOperationId]?api-version=2015-03-20

Данные приложения

  • API POST очистки компонентов принимает объект, определяющий параметры данных для удаления, и возвращает ссылочный GUID.

  • API GET получения состояния очистки компонентов возвращает заголовок x-ms-status-location, который включает URL-адрес, который вы можете вызвать, чтобы определить состояние операции очистки. Например:

    x-ms-status-location: https://management.azure.com/subscriptions/[SubscriptionId]/resourceGroups/[ResourceGroupName]/providers/microsoft.insights/components/[ComponentName]/operations/purge-[PurgeOperationId]?api-version=2015-05-01

Следующие шаги