Yuriy Gavrilov: posts tagged Security

Анатомия невидимости: гид по рекламным идентификаторам (2025+)

Tue, 20 Jan 2026 22:16:15 +0300

В современном маркетинге данные — это новая нефть, а рекламный идентификатор (Advertising ID) — это трубопровод, по которому эта нефть течет. От смартфона в кармане до умного телевизора в гостиной: каждое устройство имеет свой цифровой паспорт.

В этой статье мы разберем не только скрытую механику «рекламной слежки», но и юридические риски для бизнеса в РФ, новые технологии обхода блокировок и то, как клиентский опыт (CX) меняется в эпоху тотальной приватности.

1. Зоопарк идентификаторов: Кто есть кто

Рынок рекламных ID фрагментирован. Каждый сегмент решает одну задачу — узнать пользователя, — но делает это разными способами.

📱 Мобильные устройства (MAID — Mobile Advertising IDs)

Это самые ценные идентификаторы, так как смартфон является наиболее персональным (“интимным”) устройством.

IDFA (Identifier for Advertisers): Стандарт Apple (iOS). После внедрения *App Tracking Transparency (ATT)* в iOS 14.5 доступ к нему закрыт по умолчанию.
> Важно: Лишь 20-30% пользователей в мире нажимают «Разрешить» (Allow Tracking). Это создало огромную «слепую зону» в аналитике.
GAID (Google Advertising ID) / AAID: Аналог для Android. Позволяет связывать активность пользователя между разными приложениями. Google также движется в сторону ограничения доступа через инициативу Privacy Sandbox on Android.

📺 Телевизоры и Set-Top Box (CTV IDs)

С ростом Smart TV и стримингов маркетологи теперь трекают пользователей «на диване».

Примеры: TIFA (Samsung), Roku ID, Amazon Fire TV ID.
Логика Household (Домохозяйство): В отличие от личных смартфонов, эти ID часто привязаны к семье.
- *Инсайт эксперта по данным:* Это создает проблему «шумных данных». Если вы рекламируете женские духи, а телевизор смотрит муж или ребенок, атрибуция будет ошибочной. Для очистки данных используются Cross-Device графы, связывающие TV ID с мобильными телефонами, находящимися в той же Wi-Fi сети.

🌐 Веб-идентификаторы

Third-Party Cookies: Старейший и умирающий стандарт. Текстовые файлы, оставляемые рекламными сетями (не владельцем сайта) в браузере.
Stable IDs / Hashed Emails: Новая валюта рынка. Это зашифрованные (хэшированные) адреса электронной почты или номера телефонов. Используются в таких решениях, как *Unified ID 2.0*.

🔍 Юридический комментарий: Персональные данные в РФ

Согласно 152-ФЗ «О персональных данных» normativ.kontur.ru и позиции Роскомнадзора, любые данные, которые позволяют (даже косвенно) идентифицировать личность, могут считаться персональными данными (ПДн).

Является ли IDFA/GAID персональными данными? Формально — нет, это псевдонимизированные данные. НО: Как только вы обогащаете этот ID номером телефона из вашей CRM или связываете его с профилем конкретного клиента, он становится ПДн.
Риски: Хранение баз с “просто ID” безопаснее, но как только происходит «склейка» (matching) с реальным человеком, вы обязаны иметь согласие на обработку (и часто — на передачу третьим лицам, т.е. рекламным сетям).
Штрафы: За нарушение правил обработки ПДн штрафы для юрлиц могут достигать 18 млн рублей (при повторном нарушении при локализации), а за утечки — вплоть до оборотных штрафов (обсуждаемые поправки). Подробнее о сборе данных adesk.ru.

2. Механика: Как они строятся и живут

Формула генерации

Большинство мобильных ID (GAID, IDFA) представляют собой UUID (Universally Unique Identifier) версии 4. Это 128-битное число.

$$ P(collision) \approx \frac{n^2}{2 \times 2^{128}} $$

Вероятность совпадения двух таких ID астрономически мала.

Пример: `123e4567-e89b-12d3-a456-426614174000`
Генерация: Алгоритм использует криптографически стойкий генератор случайных чисел (CSPRNG) + энтропию системы (время запуска, «шум» железа).

Жизненный цикл и безопасность

Главное отличие рекламного ID от аппаратного (IMEI) — возможность сброса (Resettability).

Действие пользователя: В настройках конфиденциальности нажимается «Сбросить рекламный ID».
Реакция ОС: Генерируется новый UUID.
Результат: Для рекламных сетей устройство становится «чистым листом». История интересов разрывается.

3. E-commerce: Сквозь экраны к покупке

В интернет-коммерции ID — это клей, собирающий разрозненные клики в путь покупателя (Customer Journey Map).

Сквозная аналитика (Cross-Device)

Как понять, что телефон `User_A` и ноутбук `Cookie_B` — это один человек?

Deterministic (Точный метод): «Золотой стандарт». Пользователь залогинился в магазине под своим Email на обоих устройствах. Связка 100% достоверна.
Probabilistic (Вероятностный метод): Система видит, что телефон и ноутбук ежедневно выходят в сеть с одного IP-адреса Wi-Fi в одно время, имеют похожие паттерны посещения сайтов. Алгоритмы с вероятностью 90%+ «склеивают» профили в один Household.

Механика таргетинга (RTB – Real Time Bidding)

Процесс показа рекламы занимает менее 100 миллисекунд:

Вы смотрите кроссовки в приложении (система фиксирует ваш `GAID`).
Вы открываете новостной сайт. Сайт отправляет ваш `GAID` на рекламную биржу.
DSP (платформа закупки) узнает ваш ID в базе сегментов: *«Это тот же, кто смотрел Nike 5 минут назад!»*.
Происходит мгновенный аукцион, ставка выигрывает, и вам показывается баннер.

4. Феномен Amazon Ads и Retail Media

Amazon (и его аналоги в РФ) стоит особняком. Это закрытая экосистема (Walled Garden), чья сила не в технологиях трекинга, а в транзакционных данных. Им не нужно *угадывать*, что вы хотите купить, они *знают*, что вы покупаете.

Идентификатор Amazon

В основе лежит не «летучий» UUID устройства, а Internal Customer ID, жестко привязанный к аккаунту.

Формула матчинга: Для обмена данными с внешним миром используется Hashed Email (HEM). Ваш email превращается в необратимую строку (обычно SHA-256).
Clean Rooms (AMC): Amazon Marketing Cloud позволяет крупным брендам загружать свои CRM-данные в защищенную среду, где они пересекаются с данными Amazon. Рекламодатель получает инсайты (например, “Клиенты, купившие кофемашину у нас на сайте, покупают капсулы на Amazon”), но не видит персональных данных конкретных людей.

5. Война за приватность и обходные пути

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

Главные сложности

Apple ATT: Обрушение эффективности рекламы Facebook на iOS. Стоимость привлечения клиента (CAC) выросла на 40-60%.
Смерть Cookies: Google Chrome (хоть и откладывает полное отключение) внедряет Privacy Sandbox, заменяя индивидуальные куки на FLoC/Topics API (группировку по интересам).
Блокировщики: AdBlock режет запросы к доменам трекеров. (на уровне DNS, например AdGuard)

Как рынок обходит блокировки? Технический Deep Dive

Server-Side Tracking (S2S / CAPI):
Вместо отправки данных пикселем из браузера (JS), данные о покупке отправляются напрямую с бэкенда магазина на сервер рекламной системы (например, через Facebook Conversions API).

Плюс:* Не блокируется AdBlock и браузерами. Точность данных выше.
Минус:* Сложная техническая реализация. Требует согласия пользователя на передачу данных.

Fingerprinting (Серый метод):
Сбор уникальных параметров устройства без использования cookie:

`Screen Resolution` + `User Agent` + `Battery Level` + `System Fonts` + `AudioContext`
Такой “цифровой отпечаток” уникален для 95% пользователей. Apple и Google активно борются с этим методом, считая его нарушением приватности.

Итог: Тренды 2025+ и рекомендации

Эра «дикого запада», когда можно было незаметно следить за каждым шагом, заканчивается. Мы переходим в эру агрегированных данных и доверительного маркетинга (Zero-Party Data).

Ключевые тренды:

First-Party Data — король: Компании, владеющие собственными данными и прямым контактом с клиентом (Email, App), выигрывают. Зависимость от Facebook становится токсичной.
Retail Media Networks: Бум рекламных сетей маркетплейсов. Они обладают данными о деньгах, а не о кликах.
AI вместо Cookies: Алгоритмы машинного обучения будут «достраивать» потерянные данные. Например, Google GA4 уже использует моделирование конверсий для пользователей, отказавшихся от трекинга.

✅ Рекомендация

Инвестируйте в CDP (Customer Data Platform): Собирайте все данные (CRM, сайт, приложение) в одном месте.
Внедряйте Server-Side трекинг: Это единственный способ сохранить точность аналитики в будущем.
Тестируйте новые каналы: Telegram Ads (работает без кук, на контексте каналов) или Retail Media.
Аудит согласий: Проверьте формы сбора данных на сайте. Галочка «Согласен на рекламную рассылку» должна быть отделена от «Согласен на обработку ПДн». Но мне, если честно, не нравится такой подход. Я бы сделал так – Типа Посмотри 10 рекламных роликов, и спи спокойно сегодня до 12, больше показывать сегодня не буду типа)))
Обезличивание: Используйте методы обезличивания (деперсонализации) при передаче данных партнерам, как того требуют новые правила consultant.ru.
Цели обработки: Четко прописывайте цели в политике конфиденциальности (например, не просто “маркетинг”, а “таргетирование рекламы в сетях Яндекса”) rppa.pro. Кстати, хороший справочник.

Обработка логов Trino из Kafka с помощью Vector для удаления полей

Fri, 21 Nov 2025 01:27:16 +0300

В современных архитектурах данных, построенных на Kafka, часто возникает задача обработки или фильтрации потока событий “на лету”. Один из распространенных кейсов — удаление чувствительной информации из логов перед их передачей в следующую систему (например, в SIEM или систему долгосрочного хранения).

Kafka: https://hub.docker.com/r/apache/kafka
Vector: https://vector.dev/docs

Рассмотрим реальный пример:

Кластер Trino (или Presto) пишет подробные логи о каждом выполненном запросе в топик Kafka.
Эти логи содержат как полезные метаданные (пользователь, время, объем данных), так и полную текстовую версию самого SQL-запроса в поле, например, `query`.
Задача: Переложить эти логи в другой топик Kafka, но уже без** поля `query`, чтобы система-подписчик не имела доступа к потенциально конфиденциальной информации в текстах запросов.

Для решения этой задачи мы воспользуемся Vector — легковесным и сверхбыстрым инструментом для обработки данных.

План действий

Создадим два топика в Kafka: `trino-logs-raw` (для сырых логов) и `trino-logs-cleaned` (для очищенных).
Настроим Vector для чтения из первого топика, удаления поля `query` и всех служебных метаданных.
Настроим Vector на запись результата во второй топик.
Запустим всю цепочку в Docker и протестируем.

Шаг 1: Подготовка Kafka

Предполагается, что у вас уже запущен Kafka-брокер в Docker. На основе нашего примера, у вас есть контейнер с именем `broker1`, который является частью Docker-сети `minimal_iceberg_net`.

Откройте терминал и подключитесь к контейнеру Kafka, чтобы создать топики:

Создадим сеть 

docker network create my_net 

Запускаем брокер broker:

docker run -d \
  --name broker3 \
  --network=my_net \
  -p 8893:9092 \
  -e KAFKA_NODE_ID=3 \
  -e KAFKA_PROCESS_ROLES='broker,controller' \
  -e KAFKA_CONTROLLER_QUORUM_VOTERS='3@broker3:9093' \
  -e KAFKA_LISTENERS='INTERNAL://0.0.0.0:29092,EXTERNAL://0.0.0.0:9092,CONTROLLER://broker3:9093' \
  -e KAFKA_ADVERTISED_LISTENERS='INTERNAL://broker3:29092,EXTERNAL://localhost:8893' \
  -e KAFKA_LISTENER_SECURITY_PROTOCOL_MAP='INTERNAL:PLAINTEXT,EXTERNAL:PLAINTEXT,CONTROLLER:PLAINTEXT' \
  -e KAFKA_INTER_BROKER_LISTENER_NAME='INTERNAL' \
  -e KAFKA_CONTROLLER_LISTENER_NAMES='CONTROLLER' \
  -e KAFKA_OFFSETS_TOPIC_REPLICATION_FACTOR=1 \
  -e KAFKA_TRANSACTION_STATE_LOG_REPLICATION_FACTOR=1 \
  -e KAFKA_TRANSACTION_STATE_LOG_MIN_ISR=1 \
  apache/kafka:latest


docker exec --workdir /opt/kafka/bin/ -it broker3 sh

Теперь, находясь внутри контейнера, выполните команды:

# Создаем "сырой" топик для входящих логов Trino
./kafka-topics.sh --create --topic trino-logs-raw --bootstrap-server localhost:29092 --partitions 1 --replication-factor 1

# Создаем "чистый" топик для обработанных логов
./kafka-topics.sh --create --topic trino-logs-cleaned --bootstrap-server localhost:29092 --partitions 1 --replication-factor 1

*Обратите внимание: я использую внутренний порт брокера `29092`, который узнали ранее.*

Выйдите из контейнера командой `exit`.

Шаг 2: Конфигурация Vector

На вашей локальной машине создайте структуру папок:

vector-trino-processor/
└── config/
    └── vector.toml

Поместите в файл `vector.toml` следующую конфигурацию. Это сердце нашего решения.

# vector-trino-processor/config/vector.toml

# ==================================
#          ИСТОЧНИК ДАННЫХ
# ==================================
# Читаем сырые логи из Kafka
[sources.trino_raw_logs]
  type = "kafka"
  # Подключаемся к брокеру по имени контейнера и внутреннему порту
  bootstrap_servers = "broker3:29092"
  # Указываем, какой топик слушать
  topics = ["trino-logs-raw"]
  group_id = "vector-trino-cleaner"
  # Vector автоматически распарсит входящие сообщения как JSON
  decoding.codec = "json"

# ==================================
#             ТРАНСФОРМАЦИЯ
# ==================================
# Удаляем поле `query` и служебные метаданные Vector
[transforms.clean_trino_log]
  type = "remap"
  # Получаем данные от нашего источника
  inputs = ["trino_raw_logs"]
  # Скрипт на языке Vector Remap Language (VRL)
  source = '''
  # 1. Удаляем чувствительное поле "query" из лога.
  del(.query)

  # 2. Удаляем все служебные поля, которые Vector добавляет
  #    при чтении из Kafka, чтобы на выходе был чистый JSON.
  del(.headers)
  del(.message_key)
  del(.offset)
  del(.partition)
  del(.source_type)
  del(.timestamp)
  del(.topic)
  '''

# ==================================
#           ПРИЕМНИК ДАННЫХ
# ==================================
# Пишем очищенные логи в новый топик Kafka
[sinks.trino_cleaned_logs]
  type = "kafka"
  # Принимаем на вход данные, прошедшие трансформацию
  inputs = ["clean_trino_log"]
  bootstrap_servers = "broker3:29092"
  # Указываем топик для записи
  topic = "trino-logs-cleaned"
  # Кодируем итоговое событие обратно в JSON
  encoding.codec = "json"

Шаг 3: Запуск и Тестирование

Нам понадобится три терминала.

В Терминале №1 — Запустим Vector

Перейдите в папку `vector-trino-processor` и выполните команду:

docker run \
  -d \
  --name vector-processor \
  -v "$(pwd)/config:/etc/vector/" \
  --network=my_net \
  --rm \
  timberio/vector:latest-alpine --config /etc/vector/vector.toml

Эта команда:

Запускает контейнер Vector в фоновом режиме (`-d`).
Дает ему имя `vector-processor`.
Монтирует ваш локальный конфиг (`-v`).
Подключает его к той же сети, что и Kafka (`--network`).
Явно указывает, какой файл конфигурации использовать (`--config`).

В Терминале №2 — Симулируем отправку лога Trino

Запустим интерактивный Kafka-продюсер.

docker exec --workdir /opt/kafka/bin -it broker3 ./kafka-console-producer.sh --topic trino-logs-raw --bootstrap-server localhost:29092

Теперь вставьте в этот терминал JSON, имитирующий лог от Trino, и нажмите Enter:

{"user":"yuriy","source":"trino-cli","queryId":"20231120_123456_00001_abcde","query":"SELECT * FROM sensitive_table a JOIN other_table b ON a.id = b.id WHERE a.credit_card = '1234-5678-9012-3456'","state":"FINISHED"}

В Терминале №3 — Проверяем результат

Запустим Kafka-консьюмер, который будет слушать очищенный топик `trino-logs-cleaned`.

docker exec --workdir /opt/kafka/bin -it broker3 ./kafka-console-consumer.sh --topic trino-logs-cleaned --bootstrap-server localhost:29092 --from-beginning

Вы практически мгновенно увидите результат работы Vector — тот же самый лог, но уже без поля `query`:

{"user":"yuriy","source":"trino-cli","queryId":"20231120_123456_00001_abcde","state":"FINISHED"}

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

И еще немного про безопасность в масштабе

Fri, 29 Aug 2025 00:02:28 +0300

Ranger vs. OPA: Битва архитектур... и почему OPAL меняет правила игры

● Ranger has a fixed development model
● To add new systems you need to write new modules,
compile and roll out Ranger
● OPA is all REST
● Basically everything is configuration
● We can build the 80% abstraction layer easily
● Anybody else -> they can build whatever extra they need -> in config!

В мире современных распределённых систем управление доступом (авторизация) — одна из самых сложных и критически важных задач. Компании постоянно ищут баланс между безопасностью, гибкостью и скоростью разработки. Начальные тезисы были абсолютно точны:

У Ranger фиксированная модель разработки. Чтобы добавить поддержку новых систем, нужно писать новые модули. [...] OPA полностью построен на REST. По сути, всё является конфигурацией. [...] Мы можем создать 80% абстракции, а остальные сами допишут всё, что нужно, через конфиг!

Это сравнение описывает переход от традиционной, монолитной архитектуры к современной, микросервисной. Однако история неполная без третьего ключевого элемента — OPAL, который решает фундаментальную проблему OPA при масштабировании.

Давайте рассмотрим все три компонента по порядку.

1. “Классический” подход: Apache Ranger

Apache Ranger — это зрелая и мощная система для централизованного управления политиками безопасности в экосистеме больших данных (Hadoop, Hive, Kafka и т.д.).

Как это работает: Ranger работает по принципу “сервер + плагины”. Центральный сервер хранит все политики доступа. В каждую защищаемую систему (например, в Hive) устанавливается специальный плагин, который периодически опрашивает сервер Ranger, скачивает актуальные политики и кэширует их для быстрой проверки доступа.

Сильные стороны:
- Централизация: Единый центр для аудита и управления доступом.
- Мощность: Глубокая интеграция с поддерживаемыми системами (например, безопасность на уровне колонок в Hive).

Слабые стороны (те самые “фиксированные модели разработки”):
- Негибкость: Поддержка новой системы, не входящей в стандартный набор, требует написания плагина на Java, компиляции и развертывания новой версии Ranger. Это медленно и требует узкой экспертизы.
- “Бутылочное горлышко”: Все изменения проходят через центральную команду, что замедляет продуктовые команды.
- Не для микросервисов: Этот подход плохо подходит для динамичного мира микросервисов, где новые сервисы появляются каждый день.

Аналогия: Ranger — это как служба безопасности крупного завода, которая работает только со стандартными станками этого завода. Если вы покупаете новый станок из-за границы, вам нужно написать для службы безопасности целую новую инструкцию и переобучить персонал.

2. “Гибкий” подход: Open Policy Agent (OPA)

OPA — это универсальный движок политик с открытым исходным кодом. Его философия прямо противоположна Ranger. OPA ничего не знает о тех, кого он защищает.

Как это работает:
1. Ваш сервис, получив запрос, формирует JSON-документ с контекстом (`{“user”: “alice”, “action”: “read”, “resource”: “document”}`).
2. Он отправляет этот JSON в OPA через простой REST API-вызов.
3. OPA применяет к этому JSON’у правила, написанные на языке Rego, и мгновенно возвращает решение: `allow` или `deny`.

Сильные стороны:
- Универсальность: OPA может управлять доступом к чему угодно — микросервисам, Kubernetes, конвейерам CI/CD, базам данных.
- Policy-as-Code: Политики на Rego — это код. Их можно хранить в Git, версионировать, тестировать и автоматически развертывать.
- Децентрализация: OPA обычно развертывается как “сайдкар”-контейнер рядом с каждым экземпляром сервиса, что обеспечивает низкую задержку и высокую отказоустойчивость.

Проблема, которую OPA создает:
Представьте, у вас 500 микросервисов, и рядом с каждым работает свой экземпляр OPA. Возникают вопросы:

Как доставить обновление политики во все 500 экземпляров OPA одновременно?
Откуда OPA возьмет данные для принятия решений (например, список ролей пользователя или владельцев документа)? Если каждый из 500 экземпляров OPA будет сам ходить в базу данных, это создаст колоссальную нагрузку.

Здесь на сцену выходит OPAL.

3. “Связующее звено”: OPAL (Open Policy Administration Layer)

OPAL — это не еще один движок политик. Это административный слой реального времени для OPA. Его единственная задача — поддерживать политики и данные в ваших OPA-агентах в актуальном состоянии.

Как это работает (OPA + OPAL):**
1. Политики (Rego-файлы) хранятся в Git-репозитории. Данные (роли, атрибуты) — в базах данных или API.
2. OPAL Server подписывается на изменения в этих источниках (например, через веб-хуки из Git или топики Kafka).
3. Когда происходит изменение (например, разработчик пушит новую политику в Git), OPAL Server получает уведомление.
4. Сервер немедленно публикует сообщение об обновлении в легковесный канал (pub/sub, обычно через WebSockets).
5. OPAL Clients, работающие рядом с каждым OPA, получают это сообщение.
6. Клиенты сами скачивают нужные обновления (новую политику из Git, свежие данные из БД) и загружают их в свой локальный OPA.

Что это дает:
- Обновления в реальном времени: Изменение политики в Git моментально распространяется по всей системе.
- Событийная архитектура: Нет необходимости постоянно опрашивать источники. Это очень эффективно.
- Полное разделение: OPA отвечает только за принятие решений. OPAL — за доставку “знаний” для этих решений.
- Масштабируемость: Эта архитектура легко управляет тысячами OPA-агентов, решая проблему синхронизации.
- Завершение истории GitOps: Вы управляете доступом ко всей вашей инфраструктуре через `git push`, что полностью соответствует исходному тезису: “всё является конфигурацией”. medium.com

Итоговое сравнение

Критерий	Apache Ranger	OPA (самостоятельно)	OPA + OPAL (Современный стек)
Архитектура	Монолитный сервер + плагины	Децентрализованный движок политик	Децентрализованный движок + слой управления реального времени
Процесс обновления	Код -> Компиляция -> Развертывание	Ручная загрузка политик через API	`git push` -> Автоматическое распространение
Гибкость	Низкая (только для поддерживаемых систем)	Очень высокая (универсальный)	Очень высокая + управляемость в масштабе
Управление данными	Встроено	Требует самостоятельного решения	Встроено в архитектуру (OPAL следит за данными)
Масштабируемость	Масштабируется, но обновления медленные	Плохо масштабируется с точки зрения управления	Отлично масштабируется
Подход	Классический, централизованный	`Policy-as-Code`, но неполный	`Policy-as-Code` + `GitOps`, событийно-ориентированный

Вывод

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

Ranger — это мощный, но неповоротливый инструмент из прошлого, идеальный для статичных, гомогенных сред.
OPA — это гениально простой и гибкий движок, сердце современной авторизации.
OPAL — это нервная система, которая соединяет это сердце с “мозгом” (Git, базы данных) и позволяет всему организму (вашим микросервисам) реагировать на изменения мгновенно.

Современный, масштабируемый и по-настоящему гибкий “слой абстракции”, о котором говорилось в начале, строится именно на связке OPA + OPAL. Это позволяет создавать платформу, ценность которой, как и было сказано, “заключается в способности объединять внешние инструменты, команды, данные и процессы”.

Еще было это: https://gavrilov.info/all/evolyuciya-upravleniya-dostupom-opa-opal-vs-fga-rbac-rebac/

Эволюция управления доступом: OPA\OPAL vs FGA, RBAC, ReBAC

Tue, 19 Aug 2025 23:44:00 +0300

В разработке программного обеспечения управление доступом пользователей — одна из критически важных задач. От того, кто и какие действия может выполнять в приложении, напрямую зависит его безопасность, функциональность и надежность. Исторически логика авторизации часто была разбросана по всему коду приложения, что приводило к появлению архитектурного антипаттерна, известного как «Большой ком грязи» (Big Ball of Mud).

Что такое «Большой ком грязи»? Это система, в которой отсутствует четкая архитектура. Логика авторизации, выраженная в бесконечных `if-else` конструкциях, смешивается с бизнес-логикой, обработкой данных и представлением. Такую систему практически невозможно поддерживать, аудировать и масштабировать. Любое изменение в правах доступа требует переписывания кода в разных местах, что увеличивает риск ошибок и уязвимостей.

Современный подход заключается в отделении логики авторизации от основного кода приложения с помощью специализированных инструментов — механизмов политик (Policy Engines). Эти системы позволяют централизованно определять, управлять и применять правила доступа. В предоставленном материале рассматриваются три ведущих механизма: OPA (Open Policy Agent), OpenFGA и AWS Cedar.

Основной подход: Политика как код vs. Политика как данные

Ключевое различие между механизмами политик заключается в их подходе к определению правил. Это разделение можно описать как «управляемые политикой» (policy-driven) и «управляемые данными» data-driven https://www.permit.io/blog/policy-engine-showdown-opa-vs-openfga-vs-cedar.

Управляемые политикой (Policy-Driven)
В этой модели основная логика авторизации описывается в виде кода на специальном декларативном языке. Данные, такие как атрибуты пользователя или ресурса, передаются в механизм во время запроса для принятия решения.

Cedar (AWS): Яркий пример такого подхода. Cedar делает акцент на читаемости и безопасности политик. Политики пишутся так, чтобы их было легко понять и верифицировать. Joy Scharmen из StrongDM отмечает: «Cedar очень ориентирован на политики. Данные проходят через систему как эфемерный ввод, не требуя предопределенной модели данных» https://www.permit.io/blog/policy-engine-showdown-opa-vs-openfga-vs-cedar. Это идеально для систем, где важна предсказуемость и простота аудита.

Управляемые данными (Data-Driven)
Здесь ядром системы являются данные, описывающие *отношения* между субъектами (пользователями) и объектами (ресурсами). Политика — это, по сути, модель, которая интерпретирует эти отношения.

OpenFGA (на основе Google Zanzibar): Этот механизм реализует модель управления доступом на основе отношений (ReBAC). Вы определяете модель (например, «владелец документа может его удалить»), а конкретные связи («пользователь `Alice` является владельцем `document:123`») хранятся как данные https://www.permit.io/blog/opa-cedar-openfga-why-are-policy-languages-trending. Этот подход чрезвычайно масштабируем для систем со сложными иерархиями и связями, как в Google Docs или социальных сетях.

Гибридный подход
Некоторые механизмы поддерживают оба подхода.

OPA (Open Policy Agent): OPA является универсальным механизмом общего назначения https://www.permit.io/blog/policy-engines. Он позволяет как загружать данные и политики в виде «пакетов» (bundles), так и получать их динамически во время выполнения. Это дает максимальную гибкость, но требует более тщательного проектирования архитектуры.

Архитектурные модели развертывания

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

Централизованная модель: Все сервисы обращаются к единому центральному сервису авторизации.
- Плюсы: Единый источник правды, консистентность решений.
- Минусы: Может стать узким местом (bottleneck) и единой точкой отказа.
Децентрализованная модель: Механизм политик разворачивается как «сайдкар» (sidecar) рядом с каждым экземпляром приложения.
- Плюсы: Минимальная задержка (latency), высокая отказоустойчивость.
- Минусы: Требует синхронизации политик и данных между всеми экземплярами.
Гибридная модель: «Управляй централизованно, авторизуй локально». Политики и данные управляются из центра, но доставляются на децентрализованные механизмы для локального принятия решений.

Для решения проблемы синхронизации в децентрализованных моделях существуют инструменты, такие как OPAL (Open Policy Administration Layer). OPAL работает поверх OPA, Cedar и OpenFGA, обнаруживая изменения в политиках и данных в реальном времени и доставляя обновления агентам https://docs.opal.ac.

Сравнение механизмов: плюсы и минусы

Механизм	Описание	Плюсы	Минусы
:---	:---	:---	:---
OPA (Open Policy Agent)	Универсальный механизм общего назначения, использующий язык Rego.	Гибкость: Поддерживает RBAC, ABAC, ReBAC. Может использоваться не только для авторизации. Экосистема: Зрелый проект CNCF с огромным сообществом и инструментарием. Адаптивность: Может работать в stateful и stateless режимах, быть централизованным или децентрализованным.	Сложность: Язык Rego имеет порог вхождения. Требует дисциплины: Гибкость может привести к усложнению, если не планировать архитектуру тщательно.
OpenFGA	Специализированный механизм, основанный на Google Zanzibar. Реализует ReBAC.	Масштабируемость: Идеален для систем с большим количеством пользователей и сложными отношениями между объектами. Производительность: Проверенная модель, оптимизированная для быстрых проверок разрешений. Четкая модель: Фокусируется на одной задаче и делает ее хорошо.	Узкая специализация: Менее интуитивен для простых сценариев RBAC или ABAC https://www.permit.io/blog/opa-cedar-openfga-why-are-policy-languages-trending Синхронизация данных: Основная сложность — поддерживать граф отношений в актуальном состоянии.
AWS Cedar	Механизм, ориентированный на безопасность, читаемость и формальную верификацию политик.	Простота и читаемость: Политики легко писать и аудировать. Безопасность: Встроенные средства верификации для проверки корректности политик. Низкий порог вхождения: Интуитивно понятен для команд, новых в этой области.	Ограниченная гибкость: В первую очередь предназначен для авторизации и менее гибок, чем OPA. Stateless-ориентированность: Модель, где все данные передаются с запросом, может не подходить для всех сценариев.

Итог: нет “победителя”, есть правильный инструмент

Как было подчеркнуто в дискуссии на KubeCon, «победителя нет». Выбор механизма политик полностью зависит от конкретного случая использования:

Если у вас сложная система с множеством взаимосвязанных разрешений (например, совместное редактирование документов, социальная сеть), OpenFGA — ваш выбор.
Если вам нужен универсальный инструмент для управления политиками в разных частях стека (Kubernetes, CI/CD, микросервисы) и ваша команда готова изучить новый язык, OPA предоставит максимальную гибкость.
Если ваша главная цель — простая, безопасная и легко проверяемая авторизация в приложении, и вы цените читаемость политик, Cedar будет отличным стартом.

Переход от «большого кома грязи» к внешним механизмам политик — это шаг к созданию более надежных, безопасных и поддерживаемых систем. Благодаря таким проектам, как OPA, OpenFGA, Cedar и инструментам вроде OPAL, разработчики получают мощные средства для построения современных систем управления доступом https://www.permit.io/blog/introduction-to-opal

OPA + OPAL == 💜

https://github.com/permitio/opal?tab=readme-ov-file

Спойлер ...

Платформа защиты данных: принципы и практика

Sun, 09 Jun 2024 23:46:23 +0300

Перевод: https://sanjmo.medium.com/drowning-in-data-a-data-security-platform-dsp-is-your-life-raft-92be7cdc9e66

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

Защита данных не является новым открытием, а давно признанной необходимостью. В прошлом эти меры внедрялись как второстепенные и изолированные, что затрудняло своевременный и безопасный доступ к корпоративным данным. Однако сейчас организации делают защиту данных приоритетом и внедряют её структурированным образом. Неудивительно, что Gartner сообщает о 70-процентном росте звонков, связанных с защитой данных, между 2021 и 2022 годами.

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

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

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

Компоненты платформы защиты данных (DSP)
Как тормоза у автомобиля, защита данных предназначена не для замедления, а для безопасного ускорения с доверием и уверенностью. Они созданы, чтобы предотвращать как намеренное, так и случайное использование инфраструктуры данных. Цель состоит в том, чтобы обеспечить доступ к нужным данным для нужных людей в нужное время, чтобы принимать бизнес-решения и получать конкурентное преимущество.

Надежная платформа защиты данных состоит из трёх основных элементов, приведённых ниже.

Элементы платформы защиты данных (DSP)
Обнаружение и наблюдение
Первая итерация больших данных, начатая Hadoop, превратила озера данных в болота данных из-за недостаточного понимания данных. В стремлении сделать данные доступными для анализа был пропущен критический этап их понимания, включая чувствительные данные.

Современная DSP должна иметь возможность подключаться к исходным системам и определять характер данных. Чувствительность данных скрыта в контексте самих данных. Когда чувствительные данные обнаружены, их необходимо пометить в соответствии с корпоративными правилами безопасности и применимыми нормативными требованиями. Эти данные могут включать личную идентификационную информацию (PII), личную медицинскую информацию (PHI), финансовые данные, интеллектуальную собственность или производственные секреты.

Ваша DSP должна уметь подключаться ко всем соответствующим источникам данных и выявлять чувствительные данные, используя несколько подходов:

Профилирование исходных данных: сканирование и профилирование данных часто использует выборку, но должно иметь возможность сканировать полный набор данных. Однако это может создать нагрузку на операционные системы. Этот вариант требует разрешений для доступа к исходным данным.
Профилирование ответов: чтобы преодолеть некоторые из вышеупомянутых барьеров, можно профилировать и классифицировать ответы. Например, можно выявлять электронные письма, номера социального страхования и другую личную информацию.
Пометка данных может быть ручной, однако чаще всего используется сложные алгоритмы машинного обучения. Этот процесс должен быть непрерывным, так как данные меняются в реальном времени. Таким образом, в вашей DSP необходимы возможности наблюдения.

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

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

Принуждение к соблюдению политики
Заключительный этап – это выполнение политик безопасности данных с минимальными накладными расходами и задержками. Для назначения прав доступа в зависимости от роли пользователя в проекте следует использовать контроль доступа на основе ролей (RBAC). Для предоставления доступа на основе комбинации атрибутов пользователя, атрибутов данных и атрибутов окружения следует использовать контроль доступа на основе атрибутов (ABAC), обеспечивая более детализированный контроль.

Некоторые важные факторы при исполнении политики включают:

Согласованность: политики безопасности должны применяться к данным независимо от того, где они хранятся – в облачных хранилищах данных, операционных системах, хранилищах объектов или озерах данных.
Низкую задержку и масштабируемость: накладные расходы на безопасность данных должны быть минимальными для запросов. Они также должны масштабироваться с ростом нагрузки.
Динамичность: предпочтительнее ABAC, так как он динамический и адаптируется с изменением окружения пользователя.
Адаптивность: продукт для защиты данных должен быть прозрачным для конечных пользователей. В идеале пользователь должен обращаться к конечной точке или использовать API, который автоматически применяет политики безопасности и не требует изменений в схеме или запросах.
Развертывание: современные продукты безопасности развёртываются либо как SaaS-инструменты, либо в частных облаках, управляемых с помощью Kubernetes.

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

Как хакеры ломают кошельки: шесть главных уязвимостей

Thu, 10 Aug 2023 21:10:23 +0300

Оригинал статьи тут: https://forklog.com/exclusive/kak-hakery-lomayut-koshelki-shest-glavnyh-uyazvimostej

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

Однако криптокошельки все же уязвимы к хакерским атакам — из-за багов в приложениях и ошибок пользователей. Рассказываем о шести способах взлома и объясняем, как обезопасить средства от кражи.

Weak Address — уязвимые ключи

Из-за бага в генераторе случайных чисел (ГСЧ) кошелек может создать приватный ключ лишь с несколькими случайными байтами. В идеале приложение работает так:

Генерирует случайное число заданной длины.
Преобразует его в короткий формат ключа соответствующего блокчейна.
Генерирует публичный адрес из ключа.
В этом случае число fffffffffffffffffffffffffffffffebaaedce6af48a03bbfd25e8cd0364110 преобразуется в ключ 5Km2kuu7vtFDPpxywn4u3NLpbr5jKpTB3jsuDU2KYEqeoQJAair, который управляет адресом 1CaZUpjd7VmsyWDFrk9WG9nTYMLcLLvvCw.

Но иногда ГСЧ допускает ошибку и генерирует строку с большим количеством нулей вроде 0000000000000000000000000000000000000000ffa3cafff0000000000000000 вместо действительно случайного числа. Хакеры называют такие кошельки Weak Addresses.

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

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

Random Vulnerability — извлечение приватных ключей из транзакций

Биткоины существуют в виде UTXO — неиспользованных выходов. При отправке средств кошелек собирает их на нужную сумму и подписывает транзакцию комбинацией приватного ключа и случайного числа — nonce.

Из-за бага ГСЧ приложение может подписать разные операции одинаковыми nonce. Если злоумышленники сопоставят и дешифруют подписи таких транзакций, то смогут извлечь приватные ключи.

Этот метод называется Random Vulnerability. С его помощью хакеры взломали более двух тысяч кошельков на сумму 484 BTC.

Согласно исследованию компании Kudelski Security, уязвимость также встречается в кошельках Ethereum и EVM-совместимых сетей.

Как защититься: вовремя обновлять приложения кошельков, в том числе Bitcoin Core и его аналоги для других блокчейнов.

Weak Brainwallet — генерация ключей из неслучайных данных

Brainwallet — способ создания приватного ключа на базе пользовательской фразы вместо случайного числа. Ее легко можно запомнить, а значит буквально «хранить в голове».

Зачастую пользователи генерируют ключи из единичных слов, очевидных комбинаций вроде 12341234, телефонных номеров или цитат из фильмов. Хакеры пользуются человеческой предсказуемостью: они создают ключи из популярных или утекших паролей, а затем выводят криптовалюты с соответствующих кошельков. Таким образом с 2009 года злоумышленники взломали более 19 000 биткоин-кошельков и украли как минимум 4000 BTC.

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

Рассылки ForkLog: держите руку на пульсе биткоин-индустрии!

Итоги недели

Итоги недели + главные новости по будням

Фишинг — пользователь сам отдает ключ

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

Например, в феврале 2023 года хакеры отправляли пользователям Trezor фейковые письма от лица компании, в которых сообщали о взломе программного обеспечения кошельков и просили передать сид-фразу для «проверки».

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

Как защититься: ни в коем случае не отправлять приватный ключ или сид-фразу кому бы то ни было.

Ключи в публичном доступе — мониторинг GitHub

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

Хакеры отслеживают обновления и загрузки репозиториев на GitHub, Pastebin и других популярных платформах для хранения текстовых заметок. Они проверяют строки, которые начинаются с «5» (биткоин-ключи в формате WIF), содержат слова из словаря сид-фраз или совпадают с длиной закрытого ключа.

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

Скам-сайты — генерация скомпрометированных ключей

С 2019 года хакеры используют генераторы онлайн-кошельков в качестве инструмента взлома. Такие сервисы могут выдавать одни и те же ключи разным пользователям или содержать уязвимости для их перехвата.

Так, в июле 2023 года пользователь r/jdmcnair заявил о краже $3000 в биткоине из бумажного кошелька, который он сгенерировал в онлайн-сервисе.

Как защититься: не пользоваться веб-сайтами — создавать адреса только в аппаратных устройствах или приложениях кошельков.

Как создать безопасный кошелек

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

Чтобы избежать взлома, следуйте инструкции по созданию безопасного биткоин-кошелька:

Не используйте сайты для генерации адресов — только аппаратные кошельки и приложения.
Не создавайте ключи из фраз и паролей, которые можете запомнить: они уязвимее комбинаций, созданных ГСЧ.
После генерации кошелька проверьте, действительно ли символы в нем случайны. Если более половины символов ключа — нули, он уязвим для брутфорса.
Кроме того, важно не использовать личные криптовалютные адреса для разработки Web3-приложений регулярно обновлять кошелек.

Помните: приватные ключи нельзя отправлять третьим лицам, что бы они ни говорили.