Nullify
Безопасно. Прозрачно. Обнулено.
Nullify — это открытая модульная платформа для управления хранением, удалением и жизненным циклом данных. Она предоставляет централизованную основу для обнаружения данных, оценки политик хранения, выполнения контролируемых действий жизненного цикла и ведения проверяемых аудит-записей в распределённых средах данных.
Nullify разработана вокруг архитектуры, в которой спецификация имеет приоритет. Базовые модули обеспечивают фундаментальные возможности, необходимые для управления жизненным циклом данных, а дополнительные модули-плагины расширяют Nullify новыми коннекторами, фреймворками соответствия, интеллектуальными функциями, интеграциями, хранилищами и возможностями развёртывания.
Спецификация
Nullify определяет открытую архитектуру для централизованного управления жизненным циклом данных.
Спецификация построена на нескольких принципах:
- Централизованная координация политик
- Поддержка распределённых источников данных
- Управляемое политиками хранение и удаление
- Явная авторизация и согласование
- Пробные запуски и рабочие процессы проверки
- Неизменяемый и проверяемый аудит
- Происхождение и история данных
- Модульные коннекторы и интеграции
- Контроль со стороны человека для разрушительных операций
- Безопасность по умолчанию
- Вендоро-нейтральная архитектура
- Локальное, облачное, гибридное и федеративное развёртывание
- Расширяемая архитектура плагинов
- Прозрачная оценка политик
- Воспроизводимые решения жизненного цикла
Nullify не требует от организаций переносить свои данные в проприетарное централизованное хранилище. Вместо этого система координирует политики и действия жизненного цикла в существующих средах данных.
Архитектура
Nullify разделена на два основных архитектурных уровня:
- Базовые модули
- Опциональные модули-плагины
Базовые модули содержат фундаментальную функциональность, необходимую для работы Nullify. Опциональные плагины предоставляют специализированные функции, не делая базовую платформу зависимой от конкретной базы данных, облачного провайдера, фреймворка соответствия, ИИ-системы, платформы уведомлений или инфраструктурной среды.
Базовая архитектура
Основной поток жизненного цикла:
Обнаружение → Классификация → Оценка политик → Согласование → Планирование → Исполнение → Проверка → Аудит
Каждый этап представлен независимо поддерживаемым базовым модулем.
Базовые модули
1. Модуль обнаружения данных
Модуль обнаружения данных идентифицирует и инвентаризирует ресурсы данных, управляемые Nullify.
Возможности включают:
- Регистрация источников данных
- Обнаружение ресурсов
- Инвентаризация наборов данных и объектов
- Сбор метаданных
- Метаданные о владельцах данных
- Метки времени создания и изменения
- Метаданные доступа
- Отслеживание места хранения
- Отслеживание статуса ресурсов
- Мониторинг работоспособности источников данных
- Планирование обнаружения
Модуль предоставляет инвентаризацию, необходимую для нижестоящих политик жизненного цикла, без необходимости копировать сами данные в Nullify.
2. Модуль классификации данных
Модуль классификации данных присваивает структурированные метаданные обнаруженным ресурсам.
Возможности включают:
- Присвоение категорий данных
- Классификация по уровню чувствительности
- Классификация PII
- Классификация финансовых данных
- Классификация медицинских данных
- Классификация внутренних и публичных данных
- Пользовательские классификации
- Уверенность классификации
- История классификаций
- Ручная классификация
- Переопределение классификаций
Результаты классификации становятся входными данными для процесса оценки политик.
3. Модуль политик
Модуль политик — центральный компонент принятия решений в Nullify.
Возможности включают:
- Политики хранения
- Политики удаления
- Политики архивирования
- Политики анонимизации
- Правила юридического удержания
- Правила исключений
- Приоритеты политик
- Наследование политик
- Версионирование политик
- Активация и истечение срока действия политик
- Симуляция политик
- Обнаружение конфликтов политик
- Проверка политик
- Откат политик
Политики должны быть декларативными и машиночитаемыми.
Nullify должна поддерживать несколько форматов политик, сохраняя нормализованную внутреннюю модель политик.
4. Модуль решений жизненного цикла
Модуль решений жизненного цикла преобразует оценки политик в явные решения жизненного цикла.
Поддерживаемые решения включают:
- Хранить
- Пересмотреть
- Архивировать
- Анонимизировать
- Удалить
- Юридическое удержание
- Исключение
- Отложить
Каждое решение должно содержать достаточно метаданных, чтобы пояснить:
- Какое решение было принято
- Какой ресурс затронут
- Какая политика привела к решению
- Какая версия политики использовалась
- Когда решение было создано
- Когда решение должно быть исполнено
- Требуется ли согласование
5. Модуль согласования и контроля со стороны человека
Nullify не должна предполагать, что каждая разрушительная операция может быть полностью автоматизирована.
Модуль согласования обеспечивает контролируемый контроль со стороны человека.
Возможности включают:
- Очереди согласования
- Многоступенчатое согласование
- Согласование на основе ролей
- Делегирование согласования
- Истечение срока согласования
- Рабочие процессы отклонения
- Рабочие процессы эскалации
- Экстренные удержания
- Ручные переопределения
- История согласований
Организации могут настраивать, какие действия требуют согласования человеком, а какие могут выполняться автоматически.
6. Модуль планирования
Модуль планирования управляет тем, когда происходят действия жизненного цикла.
Возможности включают:
- Плановое удаление
- Плановое архивирование
- Плановая анонимизация
- Пакетная обработка
- Очереди приоритетов
- Окна технического обслуживания
- Планирование с учётом ресурсов
- Планирование повторных попыток
- Исполнение с учётом зависимостей
- Балансировка нагрузки
- Ограничение интенсивности исполнения
Планирование должно отделять решение о выполнении действия от фактического исполнения этого действия.
7. Модуль исполнения действий
Модуль исполнения действий выполняет одобренные операции жизненного цикла в зарегистрированных источниках данных.
Поддерживаемые действия жизненного цикла включают:
- Удаление
- Архивация
- Анонимизация
- Редактирование
- Карантин
- Перемещение
- Истечение срока
- Отзыв доступа
Возможности включают:
- Пробное исполнение
- Проверка перед исполнением
- Подтверждение исполнения
- Транзакционные операции, где поддерживаются
- Обработка повторных попыток
- Обнаружение сбоев
- Отслеживание частичных сбоев
- Статус исполнения
- Квитанции об исполнении
- Идемпотентное исполнение
- Безопасные средства контроля исполнения
Разрушительные действия должны требовать явной авторизации в соответствии с настроенной политикой.
8. Модуль проверки
Модуль проверки подтверждает, были ли действия жизненного цикла успешно завершены.
Возможности включают:
- Проверка удаления
- Проверка архивации
- Проверка анонимизации
- Подтверждение источника
- Проверка реплик
- Проверка повторных попыток
- Обнаружение неудачных действий
- Обнаружение остаточных данных
- Отчёты о проверке
Проверка должна различать состояния:
- Запрошено
- Авторизовано
- Запланировано
- Исполнено
- Проверено
- Не удалось
- Частично выполнено
9. Модуль аудита и доказательств
Модуль аудита и доказательств записывает полный жизненный цикл каждого важного действия системы.
Возможности включают:
- Неизменяемые события аудита
- Криптографическая целостность событий
- Записи решений политик
- Записи согласований
- Записи исполнения
- Записи проверок
- Записи действий пользователей
- История конфигураций
- История политик
- Экспорт аудита
- Пакеты доказательств
- Записи цепочки хранения
Записи аудита должны позволять реконструировать, почему произошло решение жизненного цикла и что произошло после него.
10. Модуль происхождения данных
Модуль происхождения данных отслеживает связи между ресурсами данных.
Возможности включают:
- Происхождение источника
- Происхождение назначения
- Происхождение трансформаций
- Связи копий
- Связи репликации
- Связи производных данных
- Связи родитель-потомок
- История перемещения данных
- Распространение жизненного цикла
Происхождение позволяет Nullify выявлять связанные ресурсы, для которых также может потребоваться хранение, архивация, анонимизация или удаление.
11. Модуль управления доступом
Модуль управления доступом защищает административные операции и операции жизненного цикла.
Возможности включают:
- Управление доступом на основе ролей
- Управление доступом на основе атрибутов
- Управление разрешениями
- Разрешения на уровне ресурсов
- Разрешения на уровне действий
- Разрешения на согласование
- Разделение административных функций
- Управление сессиями
- Интеграция аутентификации
- Аудит авторизации
Для разрушительных операций следует использовать авторизацию с минимальными привилегиями.
12. Модуль уведомлений
Модуль уведомлений обеспечивает системные уведомления и уведомления жизненного цикла.
Возможности включают:
- Оповещения о нарушениях политик
- Оповещения о сбоях исполнения
- Уведомления о согласованиях
- Уведомления о запланированных действиях
- Сбои проверки
- Сбои источников данных
- Оповещения о соответствии требованиям
- Административные уведомления
Базовый модуль должен предоставлять интерфейс уведомлений, а механизмы доставки остаются заменяемыми.
13. Модуль API
Модуль API обеспечивает программный доступ к Nullify.
Возможности включают:
- REST API
- GraphQL API
- Аутентификация
- Авторизация
- Управление ресурсами
- Управление политиками
- Управление жизненным циклом
- Запросы аудита
- Отчётность
- Управление плагинами
- Административные операции
API должны предоставлять стабильные версионированные интерфейсы.
14. Модуль панели управления
Панель управления предоставляет основной административный интерфейс.
Возможности включают:
- Инвентаризация данных
- Статус хранения
- Ожидающие действия
- Статус политик
- Очереди согласований
- Статус исполнения
- Статус проверки
- История аудита
- Конфликты политик
- Метрики соответствия
- Работоспособность системы
- Статус плагинов
Панель управления должна обеспечивать видимость без необходимости прямого взаимодействия пользователей с базовыми базами данных или системами исполнения.
15. Модуль отчётности
Модуль отчётности преобразует данные жизненного цикла в операционные отчёты и отчёты о соответствии.
Возможности включают:
- Отчёты о хранении
- Отчёты об удалении
- Отчёты о политиках
- Отчёты аудита
- Отчёты об исключениях
- Отчёты о юридическом удержании
- Отчёты об исполнении
- Отчёты о проверке
- Отчёты об инвентаризации данных
- Пакеты доказательств соответствия
Поддерживаемые форматы экспорта должны включать:
- JSON
- CSV
- PDF
- Структурированные машиночитаемые форматы доказательств
16. Модуль мультитенантности
Модуль мультитенантности позволяет Nullify работать в нескольких organisational средах.
Возможности включают:
- Изоляция организаций
- Политики, специфичные для тенанта
- Администраторы, специфичные для тенанта
- Аудит-записи, специфичные для тенанта
- Коннекторы, специфичные для тенанта
- Правила хранения, специфичные для тенанта
- Отчётность, специфичная для тенанта
- Конфигурация на уровне тенанта
Границы тенантов должны обеспечиваться на уровнях авторизации и доступа к данным.
17. Модуль федерации
Модуль федерации координирует несколько установок Nullify.
Возможности включают:
- Координация нескольких кластеров
- Федеративные политики
- Распределённое исполнение
- Региональное обеспечение жизненного цикла
- Координация аудита в разных средах
- Централизованная видимость
- Локальное исполнение
- Федеративная проверка
Федерация должна позволять организациям сохранять локальный контроль над своими данными, одновременно координируя управление жизненным циклом централизованно.
Опциональные модули-плагины
Плагины расширяют Nullify, не увеличивая требования к зависимостям базовой платформы.
Плагины должны использовать документированные интерфейсы и API, а также быть независимо устанавливаемыми, обновляемыми, включаемыми и отключаемыми.
Плагины источников данных
Опциональные коннекторы могут включать:
- PostgreSQL
- MySQL
- MariaDB
- Microsoft SQL Server
- Oracle Database
- MongoDB
- Redis
- Elasticsearch
- OpenSearch
- Snowflake
- BigQuery
- Databricks
- Apache Cassandra
- S3-совместимые хранилища
- Google Cloud Storage
- Azure Blob Storage
- Сетевые файловые системы
- Объектные хранилища
- Пользовательские REST API
Плагины облачных провайдеров
Опциональные интеграции могут включать:
- AWS
- Microsoft Azure
- Google Cloud
- Cloudflare
- DigitalOcean
- Другая S3-совместимая инфраструктура
Облачные плагины должны оставаться опциональными, чтобы Nullify оставалась вендоро-нейтральной.
Плагины соответствия
Опциональные пакеты политик соответствия могут включать:
- GDPR
- CCPA
- CPRA
- HIPAA
- GLBA
- FERPA
- PCI DSS
- SOX
- Региональные требования конфиденциальности
- Организационные фреймворки соответствия
Плагины соответствия должны предоставлять шаблоны политик и сопоставления, а не встраивать нормативные требования в ядро.
Плагины ИИ и интеллектуальной обработки
Функциональность ИИ должна оставаться опциональной.
Возможные плагины включают:
- Классификация чувствительных данных
- Обнаружение PII
- Классификация документов
- Распознавание сущностей
- Рекомендации по хранению
- Анализ конфликтов политик
- Оптимизация политик
- Обнаружение аномалий
- Анализ неудачных удалений
- Помощь в обеспечении соответствия
- Создание политик на естественном языке
Рекомендации, созданные ИИ, должны оставаться под контролем политик и надзором человека.
Плагины рабочих процессов
Опциональные интеграции рабочих процессов могут включать:
- Apache Airflow
- Dagster
- Temporal
- Kubernetes Jobs
- GitLab CI/CD
- Другие платформы оркестрации рабочих процессов
Плагины шины событий
Опциональные интеграции событий могут включать:
- Apache Kafka
- RabbitMQ
- NATS
- Redis Streams
- MQTT
- Облачные системы событий
Плагины идентификации
Опциональные интеграции аутентификации и идентификации могут включать:
- LDAP
- Active Directory
- OAuth
- OpenID Connect
- SAML
- Корпоративные поставщики идентификации
Плагины уведомлений
Опциональные интеграции уведомлений могут включать:
- Email
- Slack
- Microsoft Teams
- Webhooks
- PagerDuty
- Другие сервисы уведомлений
Плагины хранилищ
Nullify может поддерживать опциональные серверные хранилища для аудит-записей, доказательств, метаданных и состояния системы.
Возможные плагины включают:
- PostgreSQL
- SQLite
- MariaDB
- S3-совместимое объектное хранилище
- MinIO
- Распределённые базы данных
- Корпоративные системы хранения
Плагины развёртывания
Опциональные модули развёртывания могут предоставлять:
- Docker
- Docker Compose
- Kubernetes
- Helm
- Terraform
- Ansible
- Облачные шаблоны развёртывания
Архитектура безопасности
Безопасность — это базовое требование, а не опциональный плагин.
Nullify должна обеспечивать:
- Шифрование при передаче
- Шифрование при хранении
- Авторизацию с минимальными привилегиями
- Безопасную обработку учётных данных
- Интеграцию с менеджерами секретов
- Аутентификацию
- Авторизацию
- Ведение журналов аудита
- Криптографическую целостность аудита
- Ограничение частоты запросов
- Безопасность API
- Административное разделение
- Безопасную изоляцию плагинов
- Проверку конфигураций
- Безопасные настройки по умолчанию
Nullify никогда не должна требовать хранения учётных данных в открытом виде в конфигурации приложения.
Архитектура безопасного удаления
Поскольку удаление потенциально разрушительно, Nullify разделяет решения жизненного цикла и исполнение.
Рекомендуемый жизненный цикл:
- Обнаружить ресурс
- Классифицировать ресурс
- Оценить применимые политики
- Сформировать решение жизненного цикла
- Проверить исключения и юридические удержания
- Запросить согласование при необходимости
- Запланировать действие
- Выполнить действие
- Проверить результат
- Зафиксировать доказательства
- Обновить состояние жизненного цикла
- Сообщить о результате
Режим пробного запуска должен позволять организациям оценить ожидаемый результат перед выполнением разрушительных действий.
Юридические удержания и исключения
Nullify должна поддерживать исключения жизненного цикла, предотвращающие автоматическое удаление.
Примеры включают:
- Юридические удержания
- Расследования
- Активные споры
- Требования регуляторного сохранения
- Расследования безопасности
- Организационные исключения
- Временные продления хранения
Юридическое удержание или одобренное исключение должно иметь приоритет над обычными политиками удаления в соответствии с настроенной иерархией политик.
Обнаружение конфликтов политик
Nullify должна выявлять ситуации, в которых политики приводят к конфликтующим решениям жизненного цикла.
Примеры включают:
- Удаление против хранения
- Удаление против юридического удержания
- Архивация против удаления
- Конфликтующие периоды хранения
- Конфликтующие организационные политики
- Конфликтующие юрисдикционные политики
Система должна объяснять конфликт и указывать, какие политики к нему привели.
Прозрачность
Каждое важное решение жизненного цикла должно быть объяснимым.
Nullify должна предоставлять запись решения, содержащую:
- Ресурс
- Классификацию данных
- Применимые политики
- Версии политик
- Оценку политик
- Исключения
- Требования согласования
- Итоговое решение
- Статус исполнения
- Статус проверки
- Соответствующие события аудита
Это создаёт проверяемую цепочку от определения политики до результата жизненного цикла.
Технологическая архитектура
Nullify спроектирована так, чтобы оставаться технологически нейтральной на уровне спецификации.
Эталонная реализация может использовать:
- Python
- FastAPI
- React
- PostgreSQL
- Open Policy Agent
- Apache Airflow
- Dagster
- Docker
- Kubernetes
- MinIO
- Apache Kafka
- RabbitMQ
- NATS
Эти технологии являются вариантами реализации, а не обязательными требованиями спецификации Nullify.
Модульная конструкция
Nullify следует модульной архитектуре, чтобы организации могли развёртывать только те функции, которые им нужны.
Базовая платформа должна предоставлять:
- Обнаружение
- Классификацию
- Оценку политик
- Решения жизненного цикла
- Согласование
- Планирование
- Исполнение
- Проверку
- Аудит
- Происхождение данных
- Управление доступом
- Уведомления
- API
- Панель управления
- Отчётность
- Мультитенантность
- Федерацию
Опциональная функциональность должна поставляться через плагины.
Такая архитектура предотвращает жёсткую связь базовой платформы с конкретными вендорами, облачными провайдерами, базами данных, ИИ-системами, фреймворками соответствия или инфраструктурными платформами.
Требования к плагинам
Плагины должны:
- Использовать документированные интерфейсы
- Поддерживать независимую конфигурацию
- Объявлять зависимости
- Предоставлять проверки работоспособности
- Поддерживать операции включения и отключения
- Обеспечивать понятные сообщения об ошибках
- Уважать авторизацию Nullify
- Генерировать соответствующие события аудита
- Не обходить базовую оценку политик
- Поддерживать совместимость с поддерживаемыми версиями API
- Включать документацию
- Включать тесты
Плагины не должны обходить политики жизненного цикла или средства контроля авторизации.
Наблюдаемость
Nullify должна предоставлять операционную телеметрию для:
- Обнаружения данных
- Оценки политик
- Глубины очередей
- Запланированных действий
- Производительности исполнения
- Сбоев исполнения
- Сбоев проверки
- Производительности API
- Работоспособности плагинов
- Работоспособности источников данных
- Работоспособности системы
Опциональные плагины наблюдаемости могут интегрироваться с внешними платформами мониторинга и логирования.
Надёжность
Nullify должна поддерживать:
- Повторные попытки
- Идемпотентные действия
- Восстановление после сбоев
- Постоянство очередей
- Контрольные точки исполнения
- Проверки работоспособности
- Восстановление сервисов
- Резервное копирование и восстановление
- Аварийное восстановление
- Обработку частичных сбоев
Неудачное удаление никогда не должно молча отображаться как успешное.
Модели развёртывания
Nullify должна поддерживать:
- Локальную разработку
- Развёртывание на одном сервере
- Развёртывание в Docker
- Развёртывание в Kubernetes
- Локальное развёртывание
- Облачное развёртывание
- Гибридное развёртывание
- Мультирегиональное развёртывание
- Федеративное развёртывание
Организации должны иметь возможность эксплуатировать Nullify без зависимости от проприетарного облачного сервиса.
Дорожная карта функций
Базовые функции
Безопасность
Управление
Надёжность
Опциональные плагины- [ ] SQL-коннекторы
Разработка с открытым исходным кодом
Nullify задуман как проект с открытым исходным кодом, развиваемый сообществом.
Участники могут внести свой вклад:
- Разработка основных модулей
- Создание плагинов
- Создание коннекторов
- Написание пакетов политик
- Улучшение документации
- Создание тестов
- Сообщение об ошибках
- Повышение безопасности
- Разработка интеграций
- Предложение улучшений спецификации
Модульная архитектура позволяет участникам расширять Nullify без изменения базового механизма жизненного цикла, если функцию можно реализовать в виде плагина.
Цели проектирования
Nullify спроектирован для обеспечения:
- Прозрачности вместо непрозрачной автоматизации жизненного цикла
- Управления на основе политик вместо ручных процессов
- Модульной архитектуры вместо монолитных зависимостей
- Нейтральности к вендорам вместо привязки к платформе
- Проверяемых доказательств вместо непроверяемых утверждений
- Надзора человека вместо неконтролируемой автоматизации
- Расширяемости с открытым исходным кодом вместо проприетарных интеграций
- Централизованного управления с распределённым выполнением
- Безопасного удаления вместо неконтролируемого уничтожения
Specification Branding License (SBL)
Стандарт
- Полностью совместимая с AGPL-3.0+ система
- Копилефт обязателен для сетевых развёртываний
- Обязательная атрибуция:
Необязательно
- Specification Branding License (SBL)
📄 Лицензия и требования к уведомлениям
Nullify выпущен под лицензией GNU Affero General Public License v3.0 или более поздней (AGPL-3.0+).
Внося вклад в этот проект, вы соглашаетесь с тем, что ваши изменения также будут выпущены под этой лицензией.
Обратите внимание на следующее:
- Все вклады должны соответствовать условиям AGPL-3.0+.
- Согласно Разделу 7 лицензии, все распространения, форки и производные работы должны сохранять атрибуцию:
Roxanne Ardary и roxanneardary.com.
- Спецификации Nullify можно свободно использовать с указанием атрибуции. Лицензия на брендирование спецификаций может быть согласована по запросу.
- Файл notice.md проекта отслеживает требования к атрибуции и признание авторов.
Любое обновление, добавляющее новых участников или изменяющее атрибуцию, должно также обновлять notice.md.
- При отправке pull request убедитесь, что любые новые файлы сохраняют заголовки атрибуции, где это применимо.
- Сетевые версии этого программного обеспечения также должны полностью соответствовать AGPL-3.0+, включая раскрытие изменений исходного кода, когда это применимо по лицензии.
Полные юридические сведения см. в лицензии AGPL-3.0+ и файле notice.md проекта.
Open Arsenal Hub
https://gitlab.com/Roxanne_Ardary/open-arsenal-specs
roxanne_ardary/nullify
