Yuriy Gavrilov: posts tagged Security

Генерация синтетических данных с помощью SDV: от идеи до готовой таблицы в ClickHouse

Thu, 03 Sep 2026 00:49:26 +0300

Синтетические данные давно перестали быть просто «искусственной картинкой» — сегодня это полноценный инструмент для тестирования, разработки и даже обучения моделей машинного обучения. В этой статье я на примере реального кода покажу, как с помощью библиотеки SDV ( Synthetic Data Vault ) можно сгенерировать синтетическую копию существующей таблицы из ClickHouse, сохранив её статистические свойства и взаимосвязи.

Весь код, который мы разберём, написан на Python и использует актуальную версию SDV. Спойлер: итоговый скрипт занимает меньше 80 строк, а результат — полностью готовая синтетическая таблица в вашей базе данных.

Что такое SDV и зачем он нужен

Synthetic Data Vault (SDV) — это Python-библиотека с открытым исходным кодом, которая стала фактическим стандартом для генерации синтетических табличных данных. Она была создана в MIT, а сегодня развивается компанией DataCebo.

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

Ключевые возможности SDV:

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

SDV умеет работать с одиночными таблицами, связанными таблицами и даже последовательными данными.

Какие синтезаторы предлагает SDV

SDV предлагает несколько алгоритмов (синтезаторов) на выбор. В нашем примере мы используем `GaussianCopulaSynthesizer` — и вот почему.

Синтезатор	Принцип работы	Скорость	Когда использовать
GaussianCopulaSynthesizer	Классический статистический метод, моделирует данные через многомерное распределение	Очень быстрый	Рекомендуется для старта: быстрая работа, хорошее качество, прозрачность
CTGANSynthesizer	Генеративно-состязательная сеть (GAN)	Медленнее	Для данных со сложными зависимостями или большим количеством категориальных признаков
TVAESynthesizer	Вариационный автокодировщик	Средняя	Альтернатива GAN, требующая больше данных для обучения

`GaussianCopulaSynthesizer` отлично справляется со смешанными типами данных, которые встречаются в реальных таблицах: числа, строки, даты. При этом он обучается за секунды даже на десятках тысяч строк. Именно поэтому мы выбрали его для нашего примера.

Настройка окружения

Перед запуском кода нам потребуется установить несколько пакетов. В нашем проекте мы использовали `uv` — быстрый менеджер пакетов для Python.

uv pip install torch==2.2.2
uv pip install "numpy<2"
uv pip install "scipy<1.13"
uv pip install sdv
uv pip install clickhouse-connect

Важно: версии пакетов подобраны так, чтобы избежать конфликтов. На момент написания статьи `torch` версии 2.13.0 не имеет готовых сборок для macOS на Intel, поэтому мы используем `2.2.2`. Также важно зафиксировать `numpy<2` и `scipy<1.13` — более новые версии несовместимы с текущей версией `torch`.

Полный код генерации синтетических данных

Ниже представлен итоговый скрипт `sdv_py_v5.py`, который мы будем разбирать. Он подключается к ClickHouse, загружает реальные данные, обучает синтезатор, генерирует синтетическую копию и сохраняет результат обратно в базу.

import clickhouse_connect
import pandas as pd
import os
import warnings
from sdv.single_table import GaussianCopulaSynthesizer
from sdv.metadata import SingleTableMetadata

# Подавляем предупреждения (включая депрекацию)
warnings.filterwarnings("ignore")

# Правильный импорт для однотабличных отчётов
from sdmetrics.reports.single_table import QualityReport, DiagnosticReport

# ========== НАСТРОЙКИ ==========
CLICKHOUSE_HOST = 'localhost'
CLICKHOUSE_PORT = 18123
CLICKHOUSE_USER = 'default'
CLICKHOUSE_PASSWORD = 'changeme'
CLICKHOUSE_DATABASE = 'default'

SOURCE_TABLE = 'superstore'
SYNTHETIC_TABLE = f'{SOURCE_TABLE}_synt'
LIMIT_ROWS = 10000
NUM_SYNTHETIC_ROWS = None

# ========== ПОДКЛЮЧЕНИЕ ==========
client = clickhouse_connect.get_client(
    host=CLICKHOUSE_HOST,
    port=CLICKHOUSE_PORT,
    username=CLICKHOUSE_USER,
    password=CLICKHOUSE_PASSWORD,
    database=CLICKHOUSE_DATABASE
)

# ========== ЗАГРУЗКА ==========
query = f"SELECT * FROM {SOURCE_TABLE} LIMIT {LIMIT_ROWS}"
real_df = client.query_df(query)
print(f"Загружено {len(real_df)} строк")

# Преобразуем числовые колонки (запятая → точка)
numeric_cols = ['sales', 'discount', 'profit']
for col in numeric_cols:
    if col in real_df.columns and real_df[col].dtype == 'object':
        real_df[col] = real_df[col].str.replace(',', '.').astype(float)

# ========== МЕТАДАННЫЕ ==========
metadata = SingleTableMetadata()
metadata.detect_from_dataframe(real_df)

if os.path.exists('metadata.json'):
    os.remove('metadata.json')
metadata.save_to_json('metadata.json')
print("Метаданные сохранены в metadata.json")

# ========== ОБУЧЕНИЕ ==========
print("Начинаем обучение синтезатора...")
synthesizer = GaussianCopulaSynthesizer(metadata)
synthesizer.fit(real_df)
print("Обучение завершено")

# ========== ГЕНЕРАЦИЯ ==========
if NUM_SYNTHETIC_ROWS is None:
    NUM_SYNTHETIC_ROWS = len(real_df)
synthetic_df = synthesizer.sample(NUM_SYNTHETIC_ROWS)
print(f"Сгенерировано {len(synthetic_df)} строк")

# ========== ПРЕДПРОСМОТР ==========
print("\nОригинальные данные (первые 5 строк):")
print(real_df.head())
print("\nСинтетические данные (первые 5 строк):")
print(synthetic_df.head())

# ========== ОЦЕНКА КАЧЕСТВА ==========
print("\n--- Диагностика (проверка ошибок) ---")
diagnostic = DiagnosticReport()
diagnostic.generate(real_df, synthetic_df, metadata.to_dict())
print(diagnostic)

print("\n--- Оценка качества (статистическое сходство) ---")
quality = QualityReport()
quality.generate(real_df, synthetic_df, metadata.to_dict())
print(quality)

# ========== СОХРАНЕНИЕ В CLICKHOUSE ==========
client.command(f"CREATE TABLE IF NOT EXISTS {SYNTHETIC_TABLE} AS {SOURCE_TABLE}")
client.insert_df(SYNTHETIC_TABLE, synthetic_df)
print(f"\nСинтетические данные загружены в таблицу {SYNTHETIC_TABLE}")

# ========== СОХРАНЕНИЕ В CSV ==========
synthetic_df.to_csv('synthetic_table.csv', index=False)
print("Синтетические данные также сохранены в synthetic_table.csv")

Разбор кода по шагам

1. Подключение к ClickHouse и загрузка данных

client = clickhouse_connect.get_client(
    host=CLICKHOUSE_HOST,
    port=CLICKHOUSE_PORT,
    username=CLICKHOUSE_USER,
    password=CLICKHOUSE_PASSWORD,
    database=CLICKHOUSE_DATABASE
)

query = f"SELECT * FROM {SOURCE_TABLE} LIMIT {LIMIT_ROWS}"
real_df = client.query_df(query)

Мы подключаемся к ClickHouse через библиотеку `clickhouse-connect` и загружаем данные из таблицы-источника в Pandas DataFrame. Лимит в 10 000 строк — разумный компромисс между качеством обучения и скоростью. Для большинства задач этого объёма достаточно, чтобы синтезатор уловил основные закономерности.

2. Предобработка числовых данных

numeric_cols = ['sales', 'discount', 'profit']
for col in numeric_cols:
    if col in real_df.columns and real_df[col].dtype == 'object':
        real_df[col] = real_df[col].str.replace(',', '.').astype(float)

В нашем примере числовые колонки хранятся в ClickHouse как строки с запятой в качестве десятичного разделителя (европейский формат). Перед обучением мы преобразуем их в числа с плавающей точкой — иначе SDV не сможет корректно обработать эти данные.

3. Создание метаданных

metadata = SingleTableMetadata()
metadata.detect_from_dataframe(real_df)
metadata.save_to_json('metadata.json')

SDV автоматически определяет типы каждой колонки: числовые, категориальные, даты и т.д.. Метаданные сохраняются в JSON-файл — это полезно для воспроизводимости: в следующий раз вы сможете загрузить их, а не пересоздавать заново.

4. Обучение синтезатора

synthesizer = GaussianCopulaSynthesizer(metadata)
synthesizer.fit(real_df)

Синтезатор «изучает» ваши данные: анализирует распределения каждой колонки, корреляции между ними, паттерны пропусков. Этот процесс занимает секунды даже на 10 000 строк.

5. Генерация синтетических данных

synthetic_df = synthesizer.sample(NUM_SYNTHETIC_ROWS)

Метод `sample()` создаёт нужное количество новых записей. В нашем случае мы генерируем столько же строк, сколько было в оригинале. При желании можно увеличить или уменьшить это число — синтезатор умеет масштабировать данные.

6. Оценка качества

diagnostic = DiagnosticReport()
diagnostic.generate(real_df, synthetic_df, metadata.to_dict())

quality = QualityReport()
quality.generate(real_df, synthetic_df, metadata.to_dict())

Этот этап — одна из сильных сторон SDV. Мы проверяем два аспекта:

Диагностика (Data Validity + Data Structure) — проверяет, что синтетические данные корректны по типам и структуре. В нашем случае — 100%.
Quality Report — оценивает статистическое сходство с реальными данными по двум метрикам:
- Column Shapes Score (90.77%) — насколько хорошо совпадают распределения отдельных колонок.
- Column Pair Trends Score (37.71%) — насколько хорошо сохранились попарные зависимости между колонками.

Общий Score 64.24% — это нормальный результат для демонстрационного примера. Для улучшения качества можно переключиться на `CTGANSynthesizer` или увеличить объём обучающих данных.

7. Сохранение в ClickHouse

client.command(f"CREATE TABLE IF NOT EXISTS {SYNTHETIC_TABLE} AS {SOURCE_TABLE}")
client.insert_df(SYNTHETIC_TABLE, synthetic_df)

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

Интеграция с ClickHouse: почему это важно

ClickHouse — популярная колоночная СУБД для аналитики. Генерация синтетических данных прямо в экосистему ClickHouse открывает широкие возможности:

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

Альтернативный подход — использование встроенных средств ClickHouse, таких как движок `GenerateRandom`. Однако SDV даёт гораздо более качественные данные, потому что он не просто генерирует случайные значения, а воспроизводит реальные статистические паттерны.

Что дальше: улучшение качества синтеза

Если качество синтеза (особенно Column Pair Trends) вас не устраивает, вот несколько способов его улучшить:

Увеличьте объём обучающих данных — вместо 10 000 строк загрузите 50 000 или 100 000.
Попробуйте CTGANSynthesizer — нейросетевой синтезатор лучше справляется со сложными зависимостями.
Настройте метаданные вручную — если автоматическое определение типов сработало неидеально, вы можете отредактировать `metadata.json` и указать типы явно.
Используйте условную генерацию — SDV позволяет фиксировать значения отдельных колонок и генерировать остальные с учётом этих условий.

Заключение

Мы прошли полный путь: от установки библиотек до готовой синтетической таблицы в ClickHouse. SDV оказался мощным и при этом простым в использовании инструментом — весь процесс уместился в один скрипт на 80 строк.

Главные выводы:

SDV — это не просто генератор случайных данных, а интеллектуальный инструмент, который сохраняет статистическую структуру оригинала.
`GaussianCopulaSynthesizer` — отличная точка входа: быстрый, прозрачный, даёт хорошее качество.
Встроенная оценка качества позволяет объективно понять, насколько синтетика похожа на реальные данные.
Интеграция с ClickHouse через `clickhouse-connect` делает процесс полностью автоматизированным.

Синтетические данные открывают новые возможности для разработки, тестирования и анализа данных — без рисков, связанных с работой с реальными данными. А SDV даёт в руки инструмент, который превращает эту идею в реальность за считанные минуты.

ПЫСЫ:

Можно еще попробовать так: CTGANSynthesizer

from sdv.single_table import GaussianCopulaSynthesizer, CTGANSynthesizer

Но надо будет дольше ждать... и заменить тип в строке на

CTGANSynthesizer

uv run sdv_py_v55.py
Загружено 9994 строк
Метаданные сохранены в metadata.json
Начинаем обучение синтезатора...
PerformanceAlert: Using the CTGANSynthesizer on this data is not recommended. To model this data, CTGAN will generate a large number of columns.

Original Column Name   Est # of Columns (CTGAN)
Order Date             1236
Ship Date              1334
Ship Mode              4
Customer Name          793
segment                3
Country/Region         1
region                 4
category               3
Sub-Category           17
Product Name           1849
sales                  5825
quantity               11
discount               12
profit                 7287

We recommend preprocessing discrete columns that can have many values, using 'update_transformers'. Or you may drop columns that are not necessary to model. (Exit this script using ctrl-C)

Все .. комп полетел)) 5 мин... 7 мин... 15... чем то напоминает майнинг))) .... 20... 30... пойду пожалуй спать ... утром все еще майнит, видимо надо другие параметры указывать и разобраться лучше для чего эта опция. Первая же отработала очень быстро.

Управление доступом в дашбордах с Marimo и OPA: простое решение для сложных политик

Fri, 28 Aug 2026 00:14:17 +0300

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

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

Что такое Marimo и OPA?

Marimo (https://github.com/marimo-team/marimo) — это современный интерактивный блокнот для Python, который сочетает в себе удобство Jupyter с реактивностью и возможностью превращать блокнот в веб-приложение. В отличие от классических блокнотов, Marimo автоматически пересчитывает ячейки при изменении входных данных, что делает его идеальным для создания дашбордов и инструментов анализа.

OPA (Open Policy Agent: https://www.openpolicyagent.org) — это универсальный движок политик с открытым исходным кодом. Он позволяет описывать правила доступа на языке Rego (декларативном, похожем на JSON) и принимать решения на основе входных данных (input). OPA работает как отдельный сервис, принимающий запросы и возвращающий разрешено или запрещено действие. Такой подход отделяет политики от кода приложения, упрощая их изменение, аудит и повторное использование.

Простой пример: проверка доступа в Marimo

Представьте, что у нас есть дашборд, в котором разные пользователи могут видеть разные разделы. Вместо того чтобы хардкодить условия в Python, мы выносим логику в OPA.

Ниже приведён фрагмент кода на Marimo, который реализует минимальный интерфейс для проверки доступа:

Запускаем OPA

podman run -d --name opa-server -p 8181:8181 openpolicyagent/opa \                
  run --server --addr=0.0.0.0:8181 --log-level debug

Создаем политику Rego

nano policy.rego

package app.authz
default allow = false
allow if {
    input.user.role == "admin"
}

Отправляем политику в OPA:

curl -X PUT --data-binary @policy.rego http://localhost:8181/v1/policies/my_policy

Далее запускаем новый блокнот Marimo

mkdir marimo-opa
cd marimo-opa
uv init 
uv add marimo requests
uv run marimo edit app.py

а теперь само приложение Marimo

import marimo as mo
import requests

# Элементы управления
user_role = mo.ui.dropdown(["user", "admin"], value="user", label="Роль пользователя:")
resource = mo.ui.text(value="dashboard", label="Ресурс:")
submit = mo.ui.button(label="Проверить доступ")

mo.hstack([user_role, resource, submit])

После нажатия кнопки код отправляет запрос к OPA:

mo.stop(not submit.value, mo.md("*Нажмите кнопку для проверки прав*"))

opa_url = "http://localhost:8181/v1/data/app/authz/allow"
payload = {
    "input": {
        "user": {"role": user_role.value},
        "resource": resource.value
    }
}

try:
    response = requests.post(opa_url, json=payload).json()
    is_allowed = response.get("result", False)
    status = mo.md("**Доступ разрешен**") if is_allowed else mo.md("**Доступ запрещен**")
except Exception as e:
    status = mo.md(f"**Ошибка подключения к ОРА:** {e}")

status

Что здесь происходит?

Пользователь выбирает роль (user/admin) и вводит название ресурса.
При клике на кнопку формируется JSON с полем `input`, содержащим роль и ресурс.
Этот JSON отправляется в OPA по эндпоинту, который возвращает решение (`result` — true/false).
На основе результата выводится сообщение о разрешении или запрете.

Этот пример демонстрирует, как легко интегрировать OPA в интерфейс на Marimo. Все политики (например, `admin` может всё, а `user` — только определённые ресурсы) хранятся отдельно в OPA и могут быть изменены без переписывания кода приложения.

Расширяем сценарий: дашборд на Trino с двойным контролем доступа

Теперь представим более реальную задачу: мы строим дашборд для аналитики, который выполняет SQL-запросы к Trino — распределённому движку для работы с большими данными. В Trino доступ к таблицам, схемам и столбцам также можно регулировать через OPA. Таким образом, у нас возникает два уровня авторизации:

Уровень приложения (Marimo) — определяет, может ли пользователь вообще открыть определённый раздел дашборда или выполнить какое-то действие в интерфейсе.
Уровень данных (Trino) — контролирует, какие именно данные (таблицы, колонки, строки) пользователь может запрашивать через SQL.

Эти два уровня могут обслуживаться разными экземплярами OPA или одним, но с разными пакетами политик. Например, в Marimo мы проверяем политику `app/authz/allow`, а в Trino — `trino/authz/allow`. Это даёт гибкость: политики для интерфейса и для данных могут управляться разными командами или обновляться независимо.

В нашем приложении Marimo после успешной проверки прав на доступ к разделу мы можем формировать SQL-запрос и отправлять его в Trino. При этом Trino, в свою очередь, проверит, имеет ли пользователь право читать запрашиваемые таблицы, используя свой OPA-агент. Если хотя бы один из агентов вернёт отказ, пользователь не получит данные.

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

Управление политиками OPA: взгляд в будущее

Настройка и поддержка политик OPA, особенно когда речь идёт о десятках таблиц, ролей и атрибутов, может стать сложной задачей. Требуется не только писать правила на Rego, но и поддерживать актуальность данных о пользователях и ресурсах. Для упрощения этой работы существует проект Moat (Data Control Plane для Trino и OPA).

Moat предоставляет: https://github.com/moat-io/moat

SCIM2.0-сервер для интеграции с провайдерами идентичности (Okta, EntraId и др.);
ингестию атрибутов пользователей и групп из различных источников (SQL, LDAP);
ингестию метаданных о таблицах и представлениях из каталогов данных;
готовые политики Rego для типовых сценариев (RBAC, ABAC);
OPA-совместимый Bundle API с кешированием для быстрого обновления политик.

Moat сам не принимает решений в рантайме — он лишь поставляет OPA необходимую информацию (политики и данные). Это позволяет удобно управлять множеством кластеров Trino и эфемерных окружений, добавляя OPA-контейнер в каждый координатор и указывая ему на Moat как источник бандлов.

Однако подробное рассмотрение Moat выходит за рамки этой статьи. Мы обязательно вернёмся к нему в отдельном материале, где разберём его архитектуру, настройку и примеры использования.

Заключение

Связка Marimo и OPA даёт разработчикам дашбордов мощный и гибкий инструмент для управления доступом. Вы можете отделить политики от кода, упростить их изменение и аудит, а также комбинировать несколько OPA-агентов для разных уровней — приложения и данных. В сочетании с Trino и такими инструментами, как Moat, эта экосистема становится полноценным решением для корпоративных аналитических платформ.

Попробуйте предложенный пример в своём проекте — и вы убедитесь, как легко внедрить централизованное управление доступом, не усложняя код приложения. А о Moat мы расскажем в следующий раз!

Анатомия невидимости: гид по рекламным идентификаторам (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-приложений регулярно обновлять кошелек.

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