Руководство по хранению персональных данных в Log Analytics и Application Insights

Хранилище данных 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 — это масштабируемое хранилище, описывающее схему для ваших данных и позволяющее переопределить каждое поле пользовательскими значениями. Кроме того, может быть принята любая пользовательская схема. Таким образом, невозможно точно определить, где размещаются персональные данные в конкретном рабочем пространстве. Но есть несколько типичных расположений, с которых есть смысл начинать поиск:

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

  • 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 goes here]"
    
    Не забудьте взглянуть не только на понятные имена пользователей, но и на идентификаторы GUID, по которым можно напрямую отследить конкретного пользователя.
  • Идентификаторы устройств. Как и идентификаторы пользователей, идентификаторы устройств иногда считаются "частными". Используйте тот же подход, который указан выше, для идентификаторов пользователей, чтобы идентифицировать таблицы, там где это может потребоваться.
  • Пользовательские данные. Log Analytics позволяет собирать данные различным образом: пользовательские журналы и настраиваемые поля, API-интерфейс сборщика данных HTTP и пользовательские данные, собранные как часть журналов системных событий. Все они восприимчивы к содержанию частных данных и должны быть просмотрены, чтобы проверить, существуют ли такие данные.
  • Данные, взятые из решения. Так как механизм решения является открытым, мы рекомендуем просмотреть все таблицы, созданные решениями, чтобы обеспечить соответствие.

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

  • IP-адреса. По умолчанию Application Insights маскирует все значения в полях IP-адресов, заменяя их строкой 0.0.0.0, но для сохранения сведений о сеансах в них часто сохраняются реальные значения клиентских IP-адресов. Приведенный ниже запрос Analytics позволяет найти все таблицы, в которых содержатся поля 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 создает случайные идентификаторы для отслеживания пользователей и сеансов. Но эти поля в реальных приложениях часто переопределяются так, чтобы сохранять реальные идентификаторы, имеющие смысл для приложения. Например: имена пользователей, GUID AAD и т. д. Такие идентификаторы часто включаются в категорию персональных данных, а значит требуют соответствующей обработки. Мы рекомендуем всегда маскировать или анонимизировать эти идентификаторы. Чаще всего такие значения сохраняются в полях с такими именами, как session_Id, user_Id, user_AuthenticatedId, user_AccountId или даже customDimensions.
  • Пользовательские данные. 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, а большое количество одновременных запросов или вызовов API очистки может отрицательно повлиять на работу со всеми остальными функциями Log Analytics. Но при этом мы понимаем, что в некоторых сценариях невозможно избежать сбора персональных данных. В таких случаях следует обрабатывать эти данные так, как описано в этом разделе.

Примечание

В этой статье приведены пошаговые инструкции по удалению персональных данных с устройства или из службы. Эти сведения можно использовать для соблюдения обязательств согласно Общему регламенту по защите данных (GDPR). Общие сведения о GDPR см. в разделе, посвященном GDPR, в Центре управления безопасностью Майкрософт и на портале Service Trust Portal.

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

для запросов на просмотр и экспорт данных следует использовать api Log Analytics запросов или Application Insights api запросов . Вам необходимо самостоятельно создать логику преобразования данных в требуемый вид для предоставления пользователям. Функции Azure отлично подходят для размещения такой логики.

Важно!

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

DELETE

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

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

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

Примечание

После выполнения операции очистки доступ к данным невозможен, пока операция очистки находится в состоянииОжидание.

Операция очистки имеет настолько высокий уровень привилегий, что ни одно приложение или пользователь Azure (даже владелец ресурса) не смогут ее выполнять без явно предоставленной роли в Azure Resource Manager. Соответствующая роль именуется Data Purger (Очистка данных). Ее следует назначать осторожно в силу возможных потерь данных.

Важно!

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

Назначение роли в Azure Resource Manager открывает два новых пути API.

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

  • POST purge — принимает объект с параметрами удаляемых данных и возвращает идентификатор GUID.

  • GET purge status — вызов POST purge возвращает заголовок x-ms-status-location со значением URL-адреса, вызов которого позволяет определить состояние API очистки. Пример:

    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
    

Важно!

Предполагается, что большинство операций очистки будут выполняться намного быстрее, чем указано в Соглашении об уровне обслуживания. Но из-за сильного влияния таких операций на платформу данных Log Analytics в Соглашении об уровне обслуживания предусмотрен период в 30 дней для завершения операций очистки.

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

  • POST purge — принимает объект с параметрами удаляемых данных и возвращает идентификатор GUID.

  • GET purge status — вызов POST purge возвращает заголовок x-ms-status-location со значением URL-адреса, вызов которого позволяет определить состояние API очистки. Пример:

    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
    

Важно!

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

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

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