roxanne_ardary/nullifyAutomatisiertes, richtliniengesteuertes System zur Datenaufbewahrung und -löschung mit unveränderlichen Prüfpfaden, RBAC/ABAC, Einhaltung mehrerer Rechtsordnungen und KI/ML-Klassifizierung für sensible Daten.
# 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: 1. Kernmodule 2. 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: 1. Ressource ermitteln 2. Ressource klassifizieren 3. Anwendbare Richtlinien bewerten 4. Lifecycle-Entscheidung erzeugen 5. Ausnahmen und rechtliche Aufbewahrungspflichten prüfen 6. Genehmigung anfordern, wenn erforderlich 7. Aktion planen 8. Aktion ausführen 9. Ergebnis verifizieren 10. Evidence aufzeichnen 11. Lifecycle-Status aktualisieren 12. 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 - [ ] Datenermittlung - [ ] Datenklassifizierung - [ ] Policy-Engine - [ ] Lifecycle-Entscheidungen - [ ] Genehmigungs-Workflows - [ ] Planung - [ ] Aktionsausführung - [ ] Dry-Run-Modus - [ ] Ausführungsverifizierung - [ ] Audit und Evidence - [ ] Datenherkunft (Data Lineage) - [ ] RBAC - [ ] ABAC - [ ] Benachrichtigungen - [ ] REST-API - [ ] GraphQL-API - [ ] Dashboard - [ ] Berichterstattung - [ ] Multi-Tenancy - [ ] Föderation ### Sicherheit - [ ] Verschlüsselung während der Übertragung - [ ] Verschlüsselung im Ruhezustand - [ ] Sicheres Anmeldedaten-Management - [ ] Integration der Geheimnisverwaltung - [ ] Kryptografische Audit-Integrität - [ ] Autorisierung nach dem Prinzip der geringsten Rechte - [ ] Administrative Trennung - [ ] Sichere Plugin-Architektur ### Governance - [ ] Richtlinienversionierung - [ ] Richtlinien-Rollback - [ ] Richtliniensimulation - [ ] Erkennung von Richtlinienkonflikten - [ ] Rechtliche Aufbewahrungspflichten - [ ] Lifecycle-Ausnahmen - [ ] Richtlinienvorrang - [ ] Aufbewahrungsempfehlungen - [ ] Compliance-Berichterstattung ### Zuverlässigkeit - [ ] Idempotente Ausführung - [ ] Wiederholungsmanagement - [ ] Fehlerbehebung - [ ] Ausführungs-Checkpoints - [ ] Health-Monitoring - [ ] Sicherung und Wiederherstellung - [ ] Notfallwiederherstellung ### Optionale Plugins- [ ] SQL-Connectoren - [ ] NoSQL-Connectoren - [ ] Objektspeicher-Connectoren - [ ] Cloud-Anbieter-Connectoren - [ ] Compliance-Richtlinienpakete - [ ] KI-Klassifizierung - [ ] KI-Compliance-Berater - [ ] Workflow-Integrationen - [ ] Event-Bus-Integrationen - [ ] Identitätsintegrationen - [ ] Benachrichtigungsintegrationen - [ ] Observability-Integrationen - [ ] Zusätzliche Speicher-Backends - [ ] Bereitstellungsintegrationen --- ## 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: - Roxanne Ardary - https://www.roxanneardary.com/ ### Optional - **Spezifikations-Branding-Lizenz (SBL)** - Kommerzielle Bereitstellung ohne Namensnennung - Preisgestaltung basierend auf Umfang, Nutzung und Bereitstellungsumfang - [https://roxanneardary.com/nullify/](https://roxanneardary.com/nullify/) --- ## 📄 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](https://www.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](https://gitlab.com/Roxanne_Ardary/open-arsenal-specs)
