Маскировка конфиденциальных данных

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

На этой странице показаны примеры конфигураций Collector для редактирования определенных конфиденциальных данных (например, номеров кредитных карт или адресов электронной почты), которые могут появляться в телеметрических данных и которые следует маскировать/редактировать перед тем, как они покинут вашу сеть.

Предустановка

• Один из следующих дистрибутивов Collector с процессорами преобразования и/или редактирования :
• • Collector Ключ-АСТРОМ
  • OpenTelemetry Contrib
  • Пользовательская версия Builder
• URL-адрес конечной точки API Ключ-АСТРОМ, на которую следует экспортировать данные.
• Токен API с соответствующей областью доступа (требуется только для SaaS и АктивногоШлюза)

Информацию о настройке Collector с использованием указанной ниже конфигурации см. в разделах Развертывание коллектора и Конфигурация коллектора.

Процессор редактирования в сравнении процессора преобразования

В следующих примерах используются эти два процессора Collector :

• процессор преобразования
• процессор редактирования

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

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

Демо конфигурация

Этот документ YAML представляет собой базовый скелет конфигурации Collector, содержащий базовые общие компоненты (то есть приемники, экспортеры и определение конвейера).

receivers:   otlp:     protocols:       grpc:         endpoint: 0.0.0.0:4317       http:         endpoint: 0.0.0.0:4318 processors:   PLACEHOLDER-FOR-PROCESSOR-CONFIGURATIONS exporters:   otlphttp:     endpoint: ${env:DT_ENDPOINT}     headers:       "Authorization": "Api-Token ${env:DT_API_TOKEN}" service:   pipelines:     traces:       receivers: [otlp]       processors: [PLACEHOLDER-FOR-PROCESSOR-REFERENCES]       exporters: [otlphttp]     metrics:       receivers: [otlp]       processors: [PLACEHOLDER-FOR-PROCESSOR-REFERENCES]       exporters: [otlphttp]     logs:       receivers: [otlp]       processors: [PLACEHOLDER-FOR-PROCESSOR-REFERENCES]       exporters: [otlphttp]

Обязательно замените значения заполнителей в документе соответствующими конфигурациями:

• PLACEHOLDER-FOR-PROCESSOR-CONFIGURATIONS: соответствующая конфигурация процессора
• PLACEHOLDER-FOR-PROCESSOR-REFERENCES: ссылки на соответствующие объекты процессора для отдельных типов сигналов

IP-адреса

Используя процессор преобразования, мы маскируем атрибут client.address с помощью оператора set.

transform:   error_mode: ignore   trace_statements:     - context: span       statements: &filter-statements         # this will not only mask end user client IP addresses,         # but also the address of a server acting as a client when establishing a connection to another server         - set(attributes["client.address"], "<masked-clientip-ot>")   metric_statements:     - context: datapoint       statements: *filter-statements   log_statements:     - context: log       statements: *filter-statements

Адреса электронной почты

Используя процессор преобразования, мы маскируем атрибут user.email с помощью оператора set.

transform:   error_mode: ignore   trace_statements:     - context: span       statements: &filter-statements         - set(attributes["user.email"], "<masked-email-ot>")   metric_statements:     - context: datapoint       statements: *filter-statements   log_statements:     - context: log       statements: *filter-statements

API-токены Ключ-АСТРОМ

Используя процессор редактирования, мы применяем регулярное выражение dt0[a-z]0[1-9]\.[A-Za-z0-9]{24}\.([A-Za-z0-9]{64}) для маскировки всех вхождений токенов API Ключ-АСТРОМ в наших телеметрических данных.

redaction:   allow_all_keys: true   blocked_values:     - dt0[a-z]0[1-9]\.[A-Za-z0-9]{24}\.([A-Za-z0-9]{64})   summary: info

Имена пользователей

Используя процессор преобразования, мы маскируем атрибуты user.id, user.name, и user.full_name с помощью оператора set.

transform:   error_mode: ignore   trace_statements:     - context: span       statements: &filter-statements         - set(attributes["user.id"], "<masked-userid-ot>")         - set(attributes["user.name"], "<masked-username-ot>")         - set(attributes["user.full_name"], "<masked-userfullname-ot>")   metric_statements:     - context: datapoint       statements: *filter-statements   log_statements:     - context: log       statements: *filter-statements

Номера кредитных карт

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

transform:   error_mode: ignore   trace_statements:     - context: span       statements: &filter-statements         - replace_all_patterns(attributes, "value", "^3\\s*[47](\\s*[0-9]){9}((\\s*[0-9]){4})$", "<masked-pcard$$2-ot>") where IsValidLuhn(attributes["value"])         - replace_all_patterns(attributes, "value", "^(5[1-5]([0-9]){2}|222[1-9]|22[3-9]\\d|2[3-6]\\d{2}|27[0-1]\\d|2720)(\\s*[0-9]){8}\\s*([0-9]{4})$", "<masked-pcard$$4-ot>") where IsValidLuhn(attributes["value"])         - replace_all_patterns(attributes, "value", "^4(\\s*[0-9]){8,14}\\s*(([0-9]\\s*){4})$", "<masked-pcard$$2-ot>") where IsValidLuhn(attributes["value"])   metric_statements:     - context: datapoint       statements: *filter-statements   log_statements:     - context: log       statements: *filter-statements

Номера IBAN

Используя процессор редактирования, мы используем регулярное выражение ^[A-Z]{2}[0-9]{2}(\\s*[A-Z0-9]){8,30}$ для маскировки всех вхождений IBAN в наших телеметрических данных.

redaction:   allow_all_keys: true   blocked_values:     - "^[A-Z]{2}[0-9]{2}(\\s*[A-Z0-9]){8,30}$"   summary: info

Компоненты

Для нашей конфигурации мы используем следующие компоненты.

Приемники

В разделе receivers мы указываем стандартный приемник otlp, как активный компонент приемника для нашего экземпляра Collector.

Процессоры

В разделе processors мы размещаем конфигурацию для соответствующих экземпляров процессора.

Экспортеры

В разделе exporters мы указываем экспортер otlphttp по умолчанию и настраиваем его с помощью URL-адреса нашего API Ключ-АСТРОМ и требуемого токена аутентификации.

Для этой цели мы устанавливаем следующие две переменные среды и ссылаемся на них в значениях конфигурации для endpoint и Authorization.

• DT_ENDPOINT содержит базовый URL-адрес конечной точки API Ключ-АСТРОМ (например, https://{your-environment-id}.live.astromkey.com/api/v2/otlp)
• DT_API_TOKEN содержит токен API

Сервисные контейнеры

В service в конечном итоге мы собираем все настроенные объекты в контейнеры для отдельных телеметрических сигналов (трассы и т. д.) и заставляем экземпляр Collector выполнять настроенные задачи.