# Обробка конфіденційних даних

> Найкращі практики та рекомендації щодо обробки конфіденційних даних в OpenTelemetry

---

LLMS index: [llms.txt](/llms.txt)

---

При впровадженні OpenTelemetry дуже важливо памʼятати про обробку конфіденційних даних. Збір телеметричних даних завжди повʼязаний з ризиком ненавмисного захоплення конфіденційної або особистої інформації, яка може підпадати під дію різних нормативно-правових актів та вимог щодо дотримання конфіденційності.

## Ваша відповідальність {#your-responsibility}

OpenTelemetry збирає телеметричні дані, але не може самостійно визначити, які дані є конфіденційними у вашому конкретному контексті. Як впроваджувач, ви несете відповідальність за:

- Забезпечення дотримання відповідних законів і правил щодо захисту персональних даних.
- Захист конфіденційної інформації у ваших телеметричних даних.
- Отримання необхідних дозволів на збір даних.
- Впровадження належних практик обробки та зберігання даних.

Крім того, ви несете відповідальність за розуміння і перевірку телеметричних даних, що передаються будь-якими інструментальними бібліотеками, які ви використовуєте, оскільки ці бібліотеки також можуть збирати і розкривати конфіденційну інформацію.

## Рекомендації щодо конфіденційних даних {#sensitive-data-considerations}

Те, які дані є конфіденційними, залежить від ситуації. Приклади включають

- Персональні ідентифікаційні дані (PII)
- Облікові дані для автентифікації
- Токени сеансів
- Фінансова інформація
- Дані, повʼязані зі станом здоровʼя
- Дані про поведінку користувача

## Мінімізація даних {#data-minimization}

При зборі потенційно чутливих даних за допомогою телеметрії дотримуйтесь принципу [мінімізації даних](https://en.wikipedia.org/wiki/Data_minimization). Це означає:

- Збирайте лише ті дані, які слугують цілям спостереження.
- Уникайте збору особистої інформації, якщо це не є абсолютно необхідним.
- Подумайте, чи можуть агреговані або анонімні дані слугувати тій самій меті.
- Регулярно переглядайте зібрані атрибути, щоб переконатися, що вони залишаються необхідними.

## Захист конфіденційних даних {#protecting-sensitive-data}

Як зазначено у попередньому розділі, найкращий спосіб запобігти збиранню конфіденційних даних — не збирати дані, які можуть бути конфіденційними. Однак, можливо, ви захочете збирати такі дані за певних обставин, або, можливо, ви не маєте повного контролю над даними, які збираються, і вам потрібні способи вилучення даних під час постобробки. Наступні пропозиції можуть допомогти вам у цьому.

[Колектор OpenTelemetry](/docs/collector) надає декілька процесорів, які можуть допомогти в управлінні чутливими даними:

- Процесор [`attribute`](https://github.com/open-telemetry/opentelemetry-collector-contrib/tree/main/processor/attributesprocessor): Видаляє або змінює певні атрибути.
- Процесор [`filter`](https://github.com/open-telemetry/opentelemetry-collector-contrib/tree/main/processor/filterprocessor): Фільтрує цілі відрізки або метрики, що містять конфіденційні дані.
- Процесор [`redaction`](https://github.com/open-telemetry/opentelemetry-collector-contrib/tree/main/processor/redactionprocessor): Видаляє атрибути відрізків, журналів і точок даних метрик, які не відповідають списку дозволених атрибутів.
- Процесор [`transform`](https://github.com/open-telemetry/opentelemetry-collector-contrib/tree/main/processor/transformprocessor): Перетворює дані за допомогою регулярних виразів.

### Deleting and hashing user information {#deleting-and-hashing-user-information}

Наступна конфігурація для процесора `attribute` хешує `user.email` і видаляє `user.full_name` з конфіденційної інформації [`user`](/docs/specs/semconv/registry/attributes/user/#user-hash):

```yaml
processors:
  attributes/example:
    actions:
      - key: user.email
        action: hash
      - key: user.full_name
        action: delete
```

### Заміна `user.id` на `user.hash` {#replacing-userid-with-userhash}

Наступна конфігурація для процесора `transform` може бути використана для видалення `user.id` і заміни його на `user.hash`:

```yaml
transform:
  trace_statements:
    - context: span
      statements:
        - set(attributes["user.hash"], SHA256(attributes["user.id"]))
        - delete_key(attributes, "user.id")
```

> [!WARNING] Ризики та обмеження хешування для анонімізації
>
> Хешування ідентифікатора або імені користувача може не забезпечити необхідного рівня анонімності, оскільки на практиці хеші є оборотними, якщо вхідний простір невеликий і передбачуваний (наприклад, числові ідентифікатори користувачів).

### Усікання IP-адрес {#truncating-ip-addresses}

Як альтернативу хешуванню ви можете усікати дані або групувати їх за спільним префіксом або суфіксом. Це, наприклад, стосується

- дат, де ви зберігаєте тільки рік або рік і місяць, але опускаєте день.
- адреси електронної пошти, де ви видаляєте локальну частину і залишаєте тільки домен.
- IP-адреси, де ви відкидаєте останній октет IPv4 або останні 80 біт IPv6.

Наступна конфігурація для процесора `transform` відкидає останній октет атрибута `client.address`:

```yaml
transform:
  trace_statements:
    - context: span
      statements:
        - replace_pattern(attributes["client.address"], "\\.\\d+$", ".0")
```

### Видалення атрибутів за допомогою процесора redaction {#delete-attributes-with-redaction-processor}

Нарешті, приклад видалення певних атрибутів за допомогою процесора `redaction` можна знайти у розділі [«Видалення конфіденційних даних»](/docs/security/config-best-practices/#scrub-sensitive-data) на сторінці найкращих практик безпеки для конфігурацій Collector.