Nullify
Sicher. Transparent. Nullifiziert.
Nullify ist eine Open-Source-Plattform für modulares Datenaufbewahrungs-, Lösch- und Lifecycle-Governance-Management. Sie bietet ein zentrales Framework zur Ermittlung von Daten, zur Bewertung von Aufbewahrungsrichtlinien, zur Ausführung kontrollierter Lifecycle-Aktionen und zur Pflege überprüfbarer Audit-Aufzeichnungen über verteilte Datenumgebungen hinweg.
Nullify ist um eine spezifikationsorientierte Architektur herum konzipiert. Kernmodule bieten die grundlegenden Fähigkeiten, die für die Daten-Lifecycle-Governance erforderlich sind, während optionale Plugin-Module Nullify um zusätzliche Konnektoren, Compliance-Frameworks, Intelligenz, Integrationen, Speichersysteme und Bereitstellungsfunktionen erweitern.
Spezifikation
Nullify definiert eine Open-Source-Architektur für zentralisiertes Daten-Lifecycle-Management.
Die Spezifikation basiert auf mehreren Prinzipien:
- Zentrale Richtlinienkoordination
- Unterstützung verteilter Datenquellen
- Richtliniengesteuerte Aufbewahrung und Löschung
- Explizite Autorisierung und Genehmigung
- Dry-Run- und Validierungs-Workflows
- Unveränderliche und überprüfbare Auditierung
- Datenherkunft und Provenienz
- Modulare Konnektoren und Integrationen
- Menschliche Aufsicht für destruktive Operationen
- Sichere Standard-Ausführung (Secure-by-Default)
- Herstellerneutrale Architektur
- Lokale, Cloud-, Hybrid- und föderierte Bereitstellung
- Erweiterbare Plugin-Architektur
- Transparente Richtlinienbewertung
- Reproduzierbare Lifecycle-Entscheidungen
Nullify verlangt nicht, dass Organisationen ihre Daten in ein proprietäres zentrales Repository migrieren. Stattdessen koordiniert das System Lifecycle-Richtlinien und -Aktionen über bestehende Datenumgebungen hinweg.
Architektur
Nullify ist in zwei primäre Architekturebenen unterteilt:
- Kernmodule
- Optionale Plugin-Module
Kernmodule enthalten die grundlegenden Funktionen, die für den Betrieb von Nullify erforderlich sind. Optionale Plugins bieten spezialisierte Funktionen, ohne die Basisplattform von einer bestimmten Datenbank, einem bestimmten Cloud-Anbieter, Compliance-Framework, KI-System, einer Benachrichtigungsplattform oder einer Infrastrukturumgebung abhängig zu machen.
Kernarchitektur
Der primäre Lifecycle-Ablauf ist:
Ermittlung → Klassifizierung → Richtlinienbewertung → Genehmigung → Planung → Ausführung → Verifizierung → Audit
Jede Stufe wird durch ein unabhängig wartbares Kernmodul repräsentiert.
Kernmodule
1. Datenermittlungsmodul
Das Datenermittlungsmodul identifiziert und inventarisiert die von Nullify verwalteten Datenressourcen.
Zu den Funktionen gehören:
- Registrierung von Datenquellen
- Ressourcenermittlung
- Inventare von Datensätzen und Objekten
- Metadaten-Erfassung
- Metadaten zur Datenverantwortung
- Zeitstempel für Erstellung und Änderung
- Zugriffsmetadaten
- Speicherort-Verfolgung
- Ressourcenstatus-Verfolgung
- Überwachung der Datenquellen-Gesundheit
- Planung der Ermittlung
Das Modul stellt das Inventar bereit, das für nachgelagerte Lifecycle-Richtlinien erforderlich ist, ohne dass die zugrunde liegenden Daten in Nullify kopiert werden müssen.
2. Datenklassifizierungsmodul
Das Datenklassifizierungsmodul weist ermittelten Ressourcen strukturierte Metadaten zu.
Zu den Funktionen gehören:
- Zuordnung von Datenkategorien
- Klassifizierung der Sensitivität
- PII-Klassifizierung
- Klassifizierung von Finanzdaten
- Klassifizierung von Gesundheitsdaten
- Interne und öffentliche Klassifizierung
- Benutzerdefinierte Klassifizierungen
- Klassifizierungs-Konfidenz
- Klassifizierungsverlauf
- Manuelle Klassifizierung
- Klassifizierungs-Überschreibungen
Klassifizierungsergebnisse fließen als Eingaben in den Richtlinienbewertungsprozess ein.
3. Policy-Engine-Modul
Die Policy-Engine ist die zentrale Entscheidungskomponente von Nullify.
Zu den Funktionen gehören:
- Aufbewahrungsrichtlinien
- Löschrichtlinien
- Archivierungsrichtlinien
- Anonymisierungsrichtlinien
- Regeln für rechtliche Aufbewahrungspflichten (Legal Holds)
- Ausnahmeregeln
- Richtlinienprioritäten
- Richtlinienvererbung
- Richtlinienversionierung
- Richtlinienaktivierung und -ablauf
- Richtliniensimulation
- Erkennung von Richtlinienkonflikten
- Richtlinienvalidierung
- Richtlinien-Rollback
Richtlinien sollten deklarativ und maschinenlesbar sein.
Nullify sollte mehrere Richtlinienformate unterstützen und dabei ein normalisiertes internes Richtlinienmodell beibehalten.
4. Lifecycle-Entscheidungsmodul
Das Lifecycle-Entscheidungsmodul wandelt Richtlinienbewertungen in explizite Lifecycle-Entscheidungen um.
Unterstützte Entscheidungen umfassen:
- Aufbewahren
- Prüfen
- Archivieren
- Anonymisieren
- Löschen
- Rechtliche Aufbewahrung (Legal Hold)
- Ausnahme
- Aufschieben
Jede Entscheidung sollte ausreichend Metadaten enthalten, um Folgendes zu erläutern:
- Welche Entscheidung getroffen wurde
- Welche Ressource betroffen war
- Welche Richtlinie die Entscheidung erzeugt hat
- Welche Richtlinienversion verwendet wurde
- Wann die Entscheidung erstellt wurde
- Wann die Entscheidung ausgeführt werden soll
- Ob eine Genehmigung erforderlich ist
5. Genehmigungs- und Human-Oversight-Modul
Nullify sollte nicht davon ausgehen, dass jeder destruktive Vorgang vollständig automatisiert werden kann.
Das Genehmigungsmodul bietet kontrollierte menschliche Aufsicht.
Zu den Funktionen gehören:
- Genehmigungswarteschlangen
- Mehrpersonen-Genehmigung
- Rollenbasierte Genehmigung
- Delegation von Genehmigungen
- Ablauf von Genehmigungen
- Ablehnungs-Workflows
- Eskalations-Workflows
- Notfall-Sperren
- Manuelle Überschreibungen
- Genehmigungsverlauf
Organisationen können konfigurieren, welche Aktionen eine menschliche Genehmigung erfordern und welche automatisch ausgeführt werden dürfen.
6. Planungsmodul
Das Planungsmodul verwaltet, wann Lifecycle-Aktionen stattfinden.
Zu den Funktionen gehören:
- Geplante Löschung
- Geplante Archivierung
- Geplante Anonymisierung
- Stapelverarbeitung
- Prioritätswarteschlangen
- Wartungsfenster
- Ressourcenbewusste Planung
- Wiederholungsplanung
- Abhängigkeitsbewusste Ausführung
- Arbeitslastverteilung
- Ausführungsdrosselung
Die Planung sollte die Entscheidung, eine Aktion durchzuführen, von der tatsächlichen Ausführung dieser Aktion trennen.
7. Aktionsausführungsmodul
Das Aktionsausführungsmodul führt genehmigte Lifecycle-Operationen an registrierten Datenquellen durch.
Unterstützte Lifecycle-Aktionen umfassen:
- Löschen
- Archivieren
- Anonymisieren
- Schwärzen
- Unter Quarantäne stellen
- Verschieben
- Ablaufen lassen
- Zugriff entziehen
Zu den Funktionen gehören:
- Dry-Run-Ausführung
- Validierung vor der Ausführung
- Ausführungsbestätigung
- Transaktionsbewusste Operationen, sofern unterstützt
- Wiederholungshandling
- Fehlererkennung
- Verfolgung von Teilfehlern
- Ausführungsstatus
- Ausführungsbelege
- Idempotente Ausführung
- Sichere Ausführungssteuerungen
Destruktive Aktionen sollten gemäß der konfigurierten Richtlinie eine explizite Autorisierung erfordern.
8. Verifizierungsmodul
Das Verifizierungsmodul bestätigt, ob Lifecycle-Aktionen erfolgreich abgeschlossen wurden.
Zu den Funktionen gehören:
- Löschverifizierung
- Archivierungsverifizierung
- Anonymisierungsverifizierung
- Quellbestätigung
- Replikat-Verifizierung
- Wiederholungs-Verifizierung
- Erkennung fehlgeschlagener Aktionen
- Erkennung von Restdaten
- Verifizierungsberichte
Die Verifizierung sollte unterscheiden zwischen:
- Angefordert
- Autorisiert
- Geplant
- Ausgeführt
- Verifiziert
- Fehlgeschlagen
- Teilweise abgeschlossen
9. Audit- und Evidence-Modul
Das Audit- und Evidence-Modul zeichnet den vollständigen Lebenszyklus jeder wichtigen Systemaktion auf.
Zu den Funktionen gehören:
- Unveränderliche Audit-Ereignisse
- Kryptografische Ereignisintegrität
- Aufzeichnungen von Richtlinienentscheidungen
- Genehmigungsaufzeichnungen
- Ausführungsaufzeichnungen
- Verifizierungsaufzeichnungen
- Aufzeichnungen der Benutzeraktivitäten
- Konfigurationsverlauf
- Richtlinienverlauf
- Audit-Export
- Evidence-Pakete
- Aufzeichnungen zur Beweiskette (Chain of Custody)
Audit-Aufzeichnungen sollten es ermöglichen, zu rekonstruieren, warum eine Lifecycle-Entscheidung getroffen wurde und was danach geschah.
10. Datenherkunftsmodul (Data Lineage)
Das Datenherkunftsmodul (Data Lineage) verfolgt Beziehungen zwischen Datenressourcen.
Zu den Funktionen gehören:
- Herkunft von der Quelle
- Herkunft zum Ziel
- Transformationsherkunft
- Kopierbeziehungen
- Replikationsbeziehungen
- Beziehungen abgeleiteter Daten
- Eltern-Kind-Beziehungen
- Verlauf der Datenbewegungen
- Lifecycle-Weitergabe
Die Herkunftsverfolgung ermöglicht es Nullify, verwandte Ressourcen zu identifizieren, die ebenfalls aufbewahrt, archiviert, anonymisiert oder gelöscht werden müssen.
11. Zugriffskontrollmodul
Das Zugriffskontrollmodul schützt administrative und Lifecycle-Operationen.
Zu den Funktionen gehören:
- Rollenbasierte Zugriffskontrolle (RBAC)
- Attributbasierte Zugriffskontrolle (ABAC)
- Berechtigungsverwaltung
- Berechtigungen auf Ressourcenebene
- Berechtigungen auf Aktionsebene
- Genehmigungsberechtigungen
- Administrative Trennung
- Sitzungsverwaltung
- Authentifizierungsintegration
- Autorisierungs-Auditierung
Destruktive Operationen sollten das Prinzip der geringsten Rechte (Least-Privilege) anwenden.
12. Benachrichtigungsmodul
Das Benachrichtigungsmodul stellt System- und Lifecycle-Benachrichtigungen bereit.
Zu den Funktionen gehören:
- Warnungen bei Richtlinienverstößen
- Warnungen bei fehlgeschlagener Ausführung
- Genehmigungsbenachrichtigungen
- Benachrichtigungen über geplante Aktionen
- Fehler bei der Verifizierung
- Fehler von Datenquellen
- Compliance-Warnungen
- Administrative Benachrichtigungen
Das Kernmodul sollte eine Benachrichtigungsschnittstelle bereitstellen, während die Zustellmechanismen austauschbar bleiben.
13. API-Modul
Das API-Modul bietet programmatischen Zugriff auf Nullify.
Zu den Funktionen gehören:
- REST-API
- GraphQL-API
- Authentifizierung
- Autorisierung
- Ressourcenverwaltung
- Richtlinienverwaltung
- Lifecycle-Verwaltung
- Audit-Abfragen
- Berichterstattung
- Plugin-Verwaltung
- Administrative Operationen
APIs sollten stabile, versionierte Schnittstellen bereitstellen.
14. Dashboard-Modul
Das Dashboard stellt die primäre Verwaltungsoberfläche bereit.
Zu den Funktionen gehören:
- Dateninventar
- Aufbewahrungsstatus
- Ausstehende Aktionen
- Richtlinienstatus
- Genehmigungswarteschlangen
- Ausführungsstatus
- Verifizierungsstatus
- Audit-Verlauf
- Richtlinienkonflikte
- Compliance-Kennzahlen
- Systemzustand
- Plugin-Status
Das Dashboard sollte Transparenz bieten, ohne dass Benutzer direkt mit zugrunde liegenden Datenbanken oder Ausführungssystemen interagieren müssen.
15. Berichtsmodul
Das Berichtsmodul wandelt Lifecycle-Daten in operative und Compliance-Berichte um.
Zu den Funktionen gehören:
- Aufbewahrungsberichte
- Löschberichte
- Richtlinienberichte
- Audit-Berichte
- Ausnahmeberichte
- Berichte zu rechtlichen Aufbewahrungspflichten
- Ausführungsberichte
- Verifizierungsberichte
- Berichte zum Dateninventar
- Compliance-Evidence-Pakete
Unterstützte Exportformate sollten umfassen:
- JSON
- CSV
- PDF
- Strukturierte maschinenlesbare Evidence-Formate
16. Multi-Tenant-Modul
Das Multi-Tenant-Modul ermöglicht es Nullify, über mehrere organisatorische Umgebungen hinweg zu arbeiten.
Zu den Funktionen gehören:
- Isolierung von Organisationen
- Mandantenspezifische Richtlinien
- Mandantenspezifische Administratoren
- Mandantenspezifische Audit-Aufzeichnungen
- Mandantenspezifische Konnektoren
- Mandantenspezifische Aufbewahrungsregeln
- Mandantenspezifische Berichterstattung
- Konfiguration auf Mandantenebene
Mandantengrenzen sollten auf den Ebenen der Autorisierung und des Datenzugriffs durchgesetzt werden.
17. Föderationsmodul
Das Föderationsmodul koordiniert mehrere Nullify-Installationen.
Zu den Funktionen gehören:
- Multi-Cluster-Koordination
- Föderierte Richtlinien
- Verteilte Ausführung
- Regionale Lifecycle-Durchsetzung
- Umgebungsübergreifende Audit-Koordination
- Zentrale Sichtbarkeit
- Lokale Ausführung
- Föderierte Verifizierung
Föderation sollte es Organisationen ermöglichen, die lokale Kontrolle über ihre Daten zu behalten und gleichzeitig die Lifecycle-Governance zentral zu koordinieren.
Optionale Plugin-Module
Plugins erweitern Nullify, ohne die Abhängigkeitsanforderungen der Kernplattform zu erhöhen.
Plugins sollten dokumentierte Schnittstellen und APIs verwenden und unabhängig installierbar, aktualisierbar, aktivierbar und deaktivierbar sein.
Datenquellen-Plugins
Optionale Konnektoren können umfassen:
- PostgreSQL
- MySQL
- MariaDB
- Microsoft SQL Server
- Oracle Database
- MongoDB
- Redis
- Elasticsearch
- OpenSearch
- Snowflake
- BigQuery
- Databricks
- Apache Cassandra
- S3-kompatibler Speicher
- Google Cloud Storage
- Azure Blob Storage
- Netzwerkdateisysteme
- Objektspeichersysteme
- Benutzerdefinierte REST-APIs
Cloud-Provider-Plugins
Optionale Integrationen können umfassen:
- AWS
- Microsoft Azure
- Google Cloud
- Cloudflare
- DigitalOcean
- Andere S3-kompatible Infrastruktur
Cloud-Plugins sollten optional bleiben, damit Nullify herstellerneutral bleibt.
Compliance-Plugins
Optionale Compliance-Richtlinienpakete können umfassen:
- GDPR
- CCPA
- CPRA
- HIPAA
- GLBA
- FERPA
- PCI DSS
- SOX
- Regionale Datenschutzanforderungen
- Organisationsspezifische Compliance-Frameworks
Compliance-Plugins sollten Richtlinienvorlagen und Zuordnungen bereitstellen, anstatt regulatorische Anforderungen fest in die Kern-Engine einzucodieren.
KI- und Intelligenz-Plugins
KI-Funktionalität sollte optional bleiben.
Mögliche Plugins umfassen:
- Klassifizierung sensibler Daten
- PII-Erkennung
- Dokumentklassifizierung
- Entitätserkennung
- Aufbewahrungsempfehlungen
- Analyse von Richtlinienkonflikten
- Richtlinienoptimierung
- Anomalieerkennung
- Analyse fehlgeschlagener Löschungen
- Compliance-Unterstützung
- Erstellung von Richtlinien in natürlicher Sprache
KI-generierte Empfehlungen sollten weiterhin Richtlinienkontrollen und menschlicher Aufsicht unterliegen.
Workflow-Plugins
Optionale Workflow-Integrationen können umfassen:
- Apache Airflow
- Dagster
- Temporal
- Kubernetes Jobs
- GitLab CI/CD
- Andere Workflow-Orchestrierungsplattformen
Event-Bus-Plugins
Optionale Ereignis-Integrationen können umfassen:
- Apache Kafka
- RabbitMQ
- NATS
- Redis Streams
- MQTT
- Cloud-Ereignissysteme
Identitäts-Plugins
Optionale Authentifizierungs- und Identitätsintegrationen können umfassen:
- LDAP
- Active Directory
- OAuth
- OpenID Connect
- SAML
- Unternehmens-Identitätsanbieter
Benachrichtigungs-Plugins
Optionale Benachrichtigungsintegrationen können umfassen:
- E-Mail
- Slack
- Microsoft Teams
- Webhooks
- PagerDuty
- Andere Benachrichtigungsdienste
Speicher-Plugins
Nullify kann optionale Speicher-Backends für Audit-Aufzeichnungen, Evidence, Metadaten und Systemzustand unterstützen.
Mögliche Plugins umfassen:
- PostgreSQL
- SQLite
- MariaDB
- S3-kompatibler Objektspeicher
- MinIO
- Verteilte Datenbanken
- Unternehmensspeichersysteme
Bereitstellungs-Plugins
Optionale Bereitstellungsmodule können Folgendes bereitstellen:
- Docker
- Docker Compose
- Kubernetes
- Helm
- Terraform
- Ansible
- Cloud-Bereitstellungsvorlagen
Sicherheitsarchitektur
Sicherheit ist eine Kernanforderung und kein optionales Plugin.
Nullify sollte Folgendes bereitstellen:
- Verschlüsselung während der Übertragung
- Verschlüsselung im Ruhezustand (at rest)
- Autorisierung nach dem Prinzip der geringsten Rechte
- Sicherer Umgang mit Anmeldedaten
- Integration der Geheimnisverwaltung
- Authentifizierung
- Autorisierung
- Audit-Protokollierung
- Kryptografische Audit-Integrität
- Rate-Limiting
- API-Sicherheit
- Administrative Trennung
- Sichere Plugin-Isolation
- Konfigurationsvalidierung
- Sichere Standardeinstellungen
Nullify sollte niemals verlangen, dass Klartext-Anmeldedaten in der Anwendungskonfiguration gespeichert werden.
Architektur für sicheres Löschen
Da Löschung potenziell destruktiv ist, trennt Nullify Lifecycle-Entscheidungen von der Ausführung.
Der empfohlene Lifecycle ist:
- Ressource ermitteln
- Ressource klassifizieren
- Anwendbare Richtlinien bewerten
- Lifecycle-Entscheidung erzeugen
- Ausnahmen und rechtliche Aufbewahrungspflichten prüfen
- Genehmigung anfordern, wenn erforderlich
- Aktion planen
- Aktion ausführen
- Ergebnis verifizieren
- Evidence aufzeichnen
- Lifecycle-Status aktualisieren
- Ergebnis berichten
Der Dry-Run-Modus sollte es Organisationen ermöglichen, das erwartete Ergebnis zu bewerten, bevor destruktive Aktionen ausgeführt werden.
Rechtliche Aufbewahrungspflichten und Ausnahmen
Nullify muss Lifecycle-Ausnahmen unterstützen, die automatische Löschungen verhindern.
Beispiele umfassen:
- Rechtliche Aufbewahrungspflichten (Legal Holds)
- Ermittlungen
- Laufende Streitigkeiten
- Behördliche Aufbewahrungsanforderungen
- Sicherheitsuntersuchungen
- Organisatorische Ausnahmen
- Vorübergehende Verlängerungen der Aufbewahrungsfrist
Eine rechtliche Aufbewahrungspflicht oder eine genehmigte Ausnahme sollte gemäß der konfigurierten Richtlinienhierarchie Vorrang vor gewöhnlichen Löschrichtlinien haben.
Erkennung von Richtlinienkonflikten
Nullify sollte Situationen identifizieren, in denen Richtlinien widersprüchliche Lifecycle-Entscheidungen erzeugen.
Beispiele umfassen:
- Löschen vs. Aufbewahren
- Löschen vs. rechtliche Aufbewahrungspflicht
- Archivieren vs. Löschen
- Widersprüchliche Aufbewahrungsfristen
- Widersprüchliche Organisationsrichtlinien
- Widersprüchliche Richtlinien nach Rechtsräumen
Das System sollte den Konflikt erläutern und identifizieren, welche Richtlinien dazu beigetragen haben.
Transparenz
Jede wichtige Lifecycle-Entscheidung sollte erklärbar sein.
Nullify sollte einen Entscheidungsdatensatz bereitstellen, der Folgendes enthält:
- Ressource
- Datenklassifizierung
- Anwendbare Richtlinien
- Richtlinienversionen
- Richtlinienbewertung
- Ausnahmen
- Genehmigungsanforderungen
- Endgültige Entscheidung
- Ausführungsstatus
- Verifizierungsstatus
- Relevante Audit-Ereignisse
Dies erzeugt eine prüfbare Kette von der Richtliniendefinition bis zum Lifecycle-Ergebnis.
Technologiearchitektur
Nullify ist darauf ausgelegt, auf Spezifikationsebene technologie-neutral zu bleiben.
Eine Referenzimplementierung kann Folgendes verwenden:
- Python
- FastAPI
- React
- PostgreSQL
- Open Policy Agent
- Apache Airflow
- Dagster
- Docker
- Kubernetes
- MinIO
- Apache Kafka
- RabbitMQ
- NATS
Diese Technologien sind Implementierungsentscheidungen und keine verbindlichen Anforderungen der Nullify-Spezifikation.
Modulares Design
Nullify folgt einer modularen Architektur, damit Organisationen nur die Funktionen bereitstellen können, die sie benötigen.
Die Kernplattform sollte Folgendes bereitstellen:
- Ermittlung
- Klassifizierung
- Richtlinienbewertung
- Lifecycle-Entscheidungen
- Genehmigung
- Planung
- Ausführung
- Verifizierung
- Auditierung
- Herkunftsverfolgung
- Zugriffskontrolle
- Benachrichtigungen
- APIs
- Dashboard
- Berichterstattung
- Multi-Tenancy
- Föderation
Optionale Funktionen sollten über Plugins bereitgestellt werden.
Diese Architektur verhindert, dass die Kernplattform eng an bestimmte Anbieter, Cloud-Provider, Datenbanken, KI-Systeme, Compliance-Frameworks oder Infrastrukturplattformen gekoppelt wird.
Plugin-Anforderungen
Plugins sollten:
- Dokumentierte Schnittstellen verwenden
- Unabhängige Konfiguration pflegen
- Abhängigkeiten deklarieren
- Health-Checks bereitstellen
- Aktivierungs- und Deaktivierungsvorgänge unterstützen
- Klare Fehlerberichte bereitstellen
- Die Autorisierung von Nullify respektieren
- Passende Audit-Ereignisse ausgeben
- Die Umgehung der Kern-Richtlinienbewertung vermeiden
- Kompatibilität mit unterstützten API-Versionen wahren
- Dokumentation enthalten
- Tests enthalten
Plugins dürfen Lifecycle-Richtlinien oder Autorisierungskontrollen nicht umgehen.
Observability
Nullify sollte operative Telemetrie bereitstellen für:
- Datenermittlung
- Richtlinienbewertung
- Warteschlangentiefe
- Geplante Aktionen
- Ausführungsleistung
- Ausführungsfehler
- Verifizierungsfehler
- API-Leistung
- Plugin-Health
- Datenquellen-Health
- System-Health
Optionale Observability-Plugins können mit externen Monitoring- und Logging-Plattformen integriert werden.
Zuverlässigkeit
Nullify sollte Folgendes unterstützen:
- Wiederholungen
- Idempotente Aktionen
- Fehlerbehebung
- Persistenz von Warteschlangen
- Ausführungs-Checkpoints
- Health-Checks
- Dienst-Wiederherstellung
- Sicherung und Wiederherstellung
- Notfallwiederherstellung (Disaster Recovery)
- Behandlung von Teilfehlern
Eine fehlgeschlagene Löschung sollte niemals stillschweigend als erfolgreich gemeldet werden.
Bereitstellungsmodelle
Nullify sollte Folgendes unterstützen:
- Lokale Entwicklung
- Bereitstellung auf einem einzelnen Server
- Docker-Bereitstellung
- Kubernetes-Bereitstellung
- On-Premises-Bereitstellung
- Cloud-Bereitstellung
- Hybride Bereitstellung
- Multi-Region-Bereitstellung
- Föderierte Bereitstellung
Organisationen sollten in der Lage sein, Nullify zu betreiben, ohne von einem proprietären gehosteten Dienst abhängig zu sein.
Feature-Roadmap
Kern
Sicherheit
Governance
Zuverlässigkeit
Optionale Plugins- [ ] SQL-Connectoren
Open-Source-Entwicklung
Nullify soll als ein gemeinschaftsgetragenes Open-Source-Projekt entwickelt werden.
Mitwirkende können sich beteiligen durch:
- Entwicklung von Kernmodulen
- Erstellung von Plugins
- Entwicklung von Connectoren
- Schreiben von Richtlinienpaketen
- Verbesserung der Dokumentation
- Erstellung von Tests
- Melden von Fehlern
- Verbesserung der Sicherheit
- Entwicklung von Integrationen
- Vorschlagen von Spezifikationsverbesserungen
Die modulare Architektur ermöglicht es Mitwirkenden, Nullify zu erweitern, ohne die grundlegende Lifecycle-Engine zu verändern, sofern eine Funktion als Plugin umgesetzt werden kann.
Designziele
Nullify ist darauf ausgelegt, Folgendes bereitzustellen:
- Transparenz statt undurchsichtiger Lifecycle-Automatisierung
- Richtlinienbasierte Steuerung statt manueller Prozesse
- Modulare Architektur statt monolithischer Abhängigkeiten
- Anbieterneutralität statt Plattform-Lock-in
- Überprüfbare Nachweise statt unüberprüfbarer Behauptungen
- Menschliche Aufsicht statt unkontrollierter Automatisierung
- Open-Source-Erweiterbarkeit statt proprietärer Integrationen
- Zentralisierte Steuerung mit verteilter Ausführung
- Sicheres Löschen statt unkontrollierter Zerstörung
Spezifikations-Branding-Lizenz (SBL)
Standard
- Vollständig AGPL-3.0+-konformes System
- Copyleft für Netzwerkbereitstellungen durchgesetzt
- Erforderliche Namensnennung:
Optional
- Spezifikations-Branding-Lizenz (SBL)
📄 Lizenz- und Hinweisanforderungen
Nullify wird unter der GNU Affero General Public License v3.0 oder später (AGPL-3.0+) veröffentlicht.
Durch einen Beitrag zu diesem Projekt erklärst du dich damit einverstanden, dass deine Beiträge ebenfalls unter dieser Lizenz veröffentlicht werden.
Bitte beachte Folgendes:
- Alle Beiträge müssen den Bedingungen der AGPL-3.0+ entsprechen.
- Gemäß Abschnitt 7 der Lizenz müssen alle Weiterverbreitungen, Forks und abgeleiteten Werke die Namensnennung bewahren:
Roxanne Ardary und roxanneardary.com.
- Nullify-Spezifikationen sind mit Namensnennung kostenlos nutzbar. Eine Spezifikations-Branding-Lizenz kann auf Anfrage vereinbart werden.
- Die Datei notice.md des Projekts erfasst die Anforderungen an die Namensnennung und die Anerkennung von Mitwirkenden.
Jede Aktualisierung, die neue Mitwirkende hinzufügt oder die Namensnennung ändert, sollte auch notice.md aktualisieren.
- Wenn du einen Pull-Request einreichst, stelle sicher, dass alle neuen Dateien die Namensnennungskopfzeilen enthalten, sofern zutreffend.
- Netzwerkbereitgestellte Versionen dieser Software müssen ebenfalls vollständig AGPL-3.0+-konform bleiben, einschließlich der Offenlegung von Quellcodeänderungen, sofern dies unter der Lizenz zutrifft.
Vollständige rechtliche Einzelheiten findest du in der AGPL-3.0+-Lizenz und in der Datei notice.md des Projekts.
Open Arsenal Hub
https://gitlab.com/Roxanne_Ardary/open-arsenal-specs
roxanne_ardary/nullify
