GOpenCNR-Enterprise-Vereinbarung zur Auftragsverarbeitung

Diese Vereinbarung

Diese Vereinbarung gilt zwischen dem Kunden als Verantwortlichem und Gelhaus Solutions, Einzelunternehmen von Enno Gelhaus, Eichenwald 3, 49624 Löningen, Deutschland, als Auftragsverarbeiter nach Art. 28 DSGVO. Sie ist Teil jedes Bestellformulars, das unter den GOpenCNR-Enterprise-Bedingungen unterzeichnet wird, und wird mit ihm geschlossen; das Bestellformular nennt die Fassung, unter der es unterzeichnet wurde. Kontakt für alles daraus: contact@gplatform.org.

Sie ist der GOpenCNR-Teil der allgemeinen Vereinbarung zur Auftragsverarbeitung und in sich vollständig: Sie enthält jeden Punkt, den Art. 28 Abs. 3 DSGVO für die Enterprise-Dienste von GOpenCNR verlangt. Wo beide in einem Punkt zu GOpenCNR voneinander abweichen, geht diese Vereinbarung vor.

Was sie umfasst und was nicht

Sie umfasst die personenbezogenen Daten, die wir im Auftrag des Kunden in drei Diensten verarbeiten:

• verwaltete Edge-Router, die Tier 0 für den Kunden verwaltet;
• dedizierte Hubs, die Tier 0 für den Kunden auf seinen eigenen Servern betreibt;
• die Verwaltung der Unterpools des Kunden: wer welche Rolle daran hat, die Ansprechpartner, die der Kunde dafür einträgt, und die Teile seines Adressplans, die die Registry nicht veröffentlicht.

Sie umfasst nicht, was wir als Verantwortliche verarbeiten: Konten, Sitzungen und Organisationsdaten in GOpenCSR; die öffentlichen Registry-Daten, die RPKI und das Transparenzlog; Missbrauchsfälle einschließlich der Stichproben von Verkehrsflüssen in einem Fall; Anfragen von Behörden; und den kostenlosen Kern von GOpenCNR. Diese beschreiben der GOpenCSR-Datenschutzhinweis und der GOpenCNR-Datenschutzhinweis. Ebenso wenig umfasst sie, was ein Mitglied in eigener Verantwortung verarbeitet.

Gegenstand und Dauer

Gegenstand ist der Betrieb der Enterprise-Dienste, die die Bestellformulare des Kunden nennen. Diese Vereinbarung gilt, solange einer davon läuft, und danach, bis die Daten wie unten beschrieben zurückgegeben oder gelöscht sind.

Art und Zweck der Verarbeitung

• Verwaltete Edge-Router: Speichern der Konfiguration, die der Kunde wünscht, ihre Umsetzung in signierte Bundles und ihre Anwendung auf den Router; Empfang der Zustandsberichte, der Telemetrie und der Verkehrszähler des Routers; Einspielen von Updates; Finden und Beheben von Störungen.
• Dedizierte Hubs: Abschluss der äußeren Tunnel der Router des Kunden, Betrieb ihrer BGP-Sitzungen, Weiterleitung und Zählung ihres Verkehrs.
• Verwaltung von Unterpools: Führen der Rollen, Ansprechpartner und des Adressplans, die der Kunde für seine Unterpools einträgt, und Handeln danach.

Zweck ist die Erbringung dieser Dienste für den Kunden und nichts anderes. Wir werten die Daten zu keinem anderen Zweck aus, bilden keine Profile daraus und nutzen sie nicht für Werbung.

Kategorien betroffener Personen

• Die Beschäftigten des Kunden und die weiteren Menschen, die er in seine Organisation aufnimmt.
• Die Menschen, die der Kunde als Ansprechpartner für seine Unterpools und deren Unterinhaber nennt.
• Menschen, die die Geräte und Netze hinter einem verwalteten Edge-Router nutzen.
• Menschen, deren Verkehr einen verwalteten Edge-Router oder einen dedizierten Hub passiert.

Kategorien personenbezogener Daten

• Konfiguration eines verwalteten Edge-Routers: der Adressplan, Einstellungen für DHCP und Router Advertisements, Firewall-Zonen und -Regeln, Portweiterleitungen und NAT, Routen und BGP-Sitzungen, VLANs, WLAN-Namen und -Schlüssel, lokale DNS-Namen sowie Geräte mit ihren Namen und öffentlichen Schlüsseln. Geräte- und Hostnamen können eine Person erkennbar machen.
• Berichte und Zähler: die Zustandsberichte und die Telemetrie verwalteter Edge-Router und die Zähler je Mitglied auf einem dedizierten Hub: Bytes, Pakete und verworfene Pakete nach Grund, abgewiesene Routen, nach Flapping angehaltene Sitzungen und die genutzte Bandbreite im Verhältnis zur Fair-Use-Grenze. Zähler sagen, wie viel, nie, wer mit wem gesprochen hat, und nie, was gesagt wurde.
• Endpunktadressen: die öffentlichen Adressen, über die sich die Router des Kunden verbinden. Sie werden verschlüsselt gespeichert, nur Tier 0 und den Peers gezeigt, die der Kunde angenommen hat, und nie veröffentlicht.
• Verkehr bei der Übertragung: Ein dedizierter Hub sieht die äußeren Adressen zweier Router sowie Größe und Zeitpunkt jedes Pakets und leitet den inneren Verkehr zwischen Agenten verschlüsselt weiter. Er behält davon nichts außer den Zählern.
• Daten der Unterpool-Verwaltung: Rollen am Unterpool und an seinen Unterzuteilungen, Ansprechpartner dafür und die nicht veröffentlichten Teile des Adressplans.

Den Inhalt von Verkehr lesen wir nie. Die Dienste sind nicht für besondere Kategorien personenbezogener Daten gebaut, und der Kunde trägt solche weder in Konfigurationen noch in Namen oder Ansprechpartner ein.

Verarbeitungsvorgänge

Speichern, Erzeugen und Signieren von Konfiguration, ihre Übermittlung an Router, Empfang von Berichten, Weiterleiten von Paketen, Zählen, Zugriffskontrolle, Sichern und Löschen.

Weisungen

• Wir verarbeiten die Daten nur auf dokumentierte Weisung des Kunden, auch bei einer Übermittlung in ein Drittland. Seine Weisungen sind diese Vereinbarung, das Bestellformular, die Einstellungen, die er im Portal wählt, und das, worum die im Bestellformular für Weisungen genannten Ansprechpartner schriftlich bitten.
• Erscheint uns eine Weisung als Verstoß gegen die DSGVO oder eine andere Datenschutzvorschrift, sagen wir das und können sie aussetzen, bis der Kunde sie bestätigt oder zurücknimmt.
• Eine Weisung, die gegen die GOpenCNR-Nutzungsbedingungen, die Richtlinie zur zulässigen Nutzung, die Vereinbarung zur Netzteilnahme oder eine Regel zum Schutz anderer Mitglieder verstieße, etwa den Schutz vor gefälschten Absendern abzuschalten oder ein geschlossenes Präfix über seine Zielgruppe (Audience) hinaus zu öffnen, wird nicht ausgeführt. Wir sagen, welche Regel entgegensteht.
• Verlangt das Recht der Union oder eines Mitgliedstaats eine Verarbeitung über die Weisungen hinaus, etwa nach einer Anordnung, die nach der Richtlinie zu Behördenanfragen bearbeitet wird, teilen wir das dem Kunden vorher mit, sofern das Recht es nicht verbietet.

Vertraulichkeit

• Alle, die wir zur Verarbeitung der Daten befugen, sind vertraglich oder gesetzlich zur Vertraulichkeit verpflichtet, auch über das Ende ihrer Tätigkeit hinaus.
• Der Inhalt von Verkehr und seine näheren Umstände sind zudem durch das Fernmeldegeheimnis geschützt (§ 3 TDDDG), das uns und alle bindet, die für uns arbeiten. GOpenCNR und das Fernmeldegeheimnis legt dar, was das für Zähler, Stichproben von Verkehrsflüssen und gehostete Router bedeutet.
• Zugang zu Produktivsystemen haben nur die, die ihn für den Betrieb brauchen, jede Änderung durch Tier 0 braucht einen Passkey, und jeder Zugriff, der etwas ändert, wird protokolliert.

Sicherheit

Wir treffen die Maßnahmen, die Art. 32 DSGVO verlangt. In Kürze:

• Schlüssel liegen in HashiCorp Vault auf eigener Hardware in Deutschland, und Signaturen entstehen dort. Schlüssel von Routern und Geräten werden auf ihrem Host erzeugt und verlassen ihn nie.
• Jede Änderung wird signiert, mit einem Passkey oder einem darunter registrierten Automatisierungsschlüssel, und Freigaben durch Tier 0 erfolgen im Vier-Augen-Prinzip.
• Verkehr ist verschlüsselt: WireGuard zwischen Routern und Hubs und Ende-zu-Ende zwischen Agenten. Endpunktadressen sind im Ruhezustand verschlüsselt.
• Hubs leiten verschlüsselten Verkehr weiter und führen Zähler, und Verkehrsflüsse werden nur in einem offenen Fall stichprobenartig erfasst.
• Router wenden nur signierte Bundles an, und eine Änderung, die einen Router abschneiden könnte, rollt sich selbst zurück.
• Audit-Einträge werden nur angefügt, und Sicherungen sind verschlüsselt, liegen 90 Tage auf eigener Hardware in Deutschland und werden in Übungen wiederhergestellt.
• Personenbezogene Daten werden nur in der EU verarbeitet, auf Servern in Deutschland.

Die vollständige Liste ist der Anhang „Technische und organisatorische Maßnahmen“ am Ende dieser Vereinbarung. Wir können eine Maßnahme durch eine mindestens ebenso schützende ersetzen und senken das Schutzniveau insgesamt nie.

Unterauftragsverarbeiter

Der Kunde erteilt uns die allgemeine Genehmigung, Unterauftragsverarbeiter einzusetzen. Eingesetzt sind:

• IONOS SE, Elgendorfer Straße 57, 56410 Montabaur, Deutschland, vermietet uns die Server in Deutschland, auf denen die Steuerungsebene von GOpenCNR, die Hubs von Tier 0 und unser eigener Mailserver (Stalwart) laufen.
• Sentry (Functional Software, Inc.), in dessen EU-Datenregion, erhält Fehlerberichte. Es ist so konfiguriert, dass es keine Nutzerkennung, kein Cookie, keinen Header, keinen Anfrageinhalt, keine Query-Parameter und keine Werte lokaler Variablen erhält: Ein Fehlerbericht enthält die Ausnahme, ihren Stacktrace, die betroffene Route und die Anfragekennung. Die Daten werden in der EU gespeichert, und Fehlerereignisse werden 90 Tage aufbewahrt. Das Unternehmen hat seinen Sitz in den Vereinigten Staaten, ein Zugriff von dort ist daher nicht auszuschließen; es gelten die EU-Standardvertragsklauseln im Auftragsverarbeitungsvertrag von Sentry.

Unsere Signaturschlüssel und verschlüsselten Sicherungen liegen auf eigener Hardware in Deutschland, erreichbar über WireGuard; das ist kein Unterauftragsverarbeiter. E-Mails versendet unser eigener Mailserver.

Zertifizierte Hub- und Transit-Betreiber sind nicht beteiligt. Dedizierte Hubs betreibt ausschließlich Tier 0 auf seinen eigenen Servern, und verwaltete Edge-Router berichten unmittelbar an unsere eigenen Systeme; nichts, was wir nach dieser Vereinbarung verarbeiten, geht daher an einen Hub- oder Transit-Betreiber. Nutzen die Router des Kunden auch das gemeinsame Netz, gehört dieser Verkehr zum kostenlosen Kern von GOpenCNR, den wir als Verantwortliche verarbeiten. Dort sind zertifizierte Hub-Betreiber und geprüfte Transit-Betreiber unsere Auftragsverarbeiter, nach Klauseln gemäß Art. 28 DSGVO in ihren Vereinbarungen und, wo sie außerhalb der EU und des EWR und außerhalb von Ländern mit Angemessenheitsbeschluss sitzen, gebunden an die EU-Standardvertragsklauseln (Modul 2, Verantwortlicher an Auftragsverarbeiter), wie es der GOpenCNR-Datenschutzhinweis beschreibt.

Jeder Unterauftragsverarbeiter ist durch einen Vertrag an dieselben Datenschutzpflichten gebunden wie diese Vereinbarung, und wir haften dem Kunden für jeden von ihnen (Art. 28 Abs. 4 DSGVO).

Änderungen. Bevor wir einen Unterauftragsverarbeiter hinzunehmen oder ersetzen, informieren wir die Ansprechpartner des Kunden, und die Mitteilung nennt die Frist, in der der Kunde widersprechen kann. Widerspricht der Kunde aus berechtigten Gründen des Datenschutzes und können wir keine Alternative anbieten, kann er die betroffene Bestellung beenden, und im Voraus gezahlte Entgelte für die Zeit danach werden erstattet.

Unterstützung des Kunden

• Anliegen betroffener Personen (Art. 12 bis 23 DSGVO). Wir helfen dem Kunden, die Daten in unseren Systemen zu finden, zu berichtigen, zu exportieren oder zu löschen, und verweisen ihn auf die Funktion, die das tut, wo es eine gibt. Wendet sich eine betroffene Person wegen Daten, für die der Kunde verantwortlich ist, an uns, verweisen wir sie an den Kunden und informieren ihn.
• Art. 32 bis 36 DSGVO. Wir unterstützen bei der Sicherheit der Verarbeitung, bei Meldung und Benachrichtigung von Verletzungen, bei Folgenabschätzungen und bei der Konsultation der Aufsichtsbehörde, indem wir bereitstellen, was wir über die Funktionsweise der Dienste wissen.
• Gewöhnliche Unterstützung ist inbegriffen. Ist eine Anfrage unverhältnismäßig, können wir den Aufwand berechnen und sagen das, bevor wir beginnen.

Verletzungen des Schutzes personenbezogener Daten

• Wir melden dem Kunden eine Verletzung des Schutzes personenbezogener Daten unverzüglich, nachdem sie uns bekannt geworden ist, und jedenfalls so rechtzeitig, dass er seine eigene Frist von 72 Stunden nach Art. 33 DSGVO einhalten kann.
• Die Meldung beschreibt, was geschehen ist, die Kategorien und die ungefähre Zahl der betroffenen Personen und Datensätze, die wahrscheinlichen Folgen, die ergriffenen oder vorgeschlagenen Maßnahmen und eine Kontaktstelle. Haben wir nicht alles auf einmal, senden wir, was wir haben, und ergänzen.
• Wir melden nichts an die Aufsichtsbehörde des Kunden oder an betroffene Personen in seinem Namen, es sei denn, er bittet uns schriftlich darum.
• Unsere eigenen Pflichten als Netzbetreiber bestehen daneben und ersetzen nichts, was wir dem Kunden schulden: Sicherheitsvorfälle nach § 168 TKG der Bundesnetzagentur und dem BSI innerhalb von 24 Stunden, 72 Stunden und einem Monat zu melden und Verletzungen des Schutzes personenbezogener Daten in der Telekommunikation nach § 169 TKG der Bundesnetzagentur und der Bundesbeauftragten für den Datenschutz und die Informationsfreiheit (BfDI) zu melden.

Löschung und Rückgabe

• Endet eine Bestellung, wählt der Kunde, ob wir seine Daten zurückgeben oder löschen. Sagt er nichts anderes, bleiben die Daten nach dem Ende der Bestellung 30 Tage für den Export verfügbar und werden dann gelöscht. Auf Wunsch löschen wir sie früher.
• Ein verwalteter Edge-Router behält die Konfiguration, die auf ihm liegt; sie gehört dem Kunden. Unsere Kopien werden wie oben gelöscht.
• Während der Laufzeit werden Zustandsberichte und Telemetrie 12 Monate aufbewahrt. Feine Verkehrszähler werden 90 Tage aufbewahrt; danach bleiben nur Tagessummen je Mitglied, bis 12 Monate.
• Sicherungen werden jede Nacht auf eigener Hardware in Deutschland erstellt und 90 Tage aufbewahrt. Sie werden nicht bearbeitet, und Daten aus einer Sicherung werden nur zur Wiederherstellung des Dienstes eingespielt, nie, um Gelöschtes zurückzuholen.
• Wir behalten nur, was wir nach dem Recht der Union oder eines Mitgliedstaats aufbewahren müssen, und sagen dem Kunden, was und warum, falls das je zutrifft.

Kontrollen

• Wir stellen bereit, was der Kunde braucht, um die Einhaltung dieser Vereinbarung nachzuweisen: den Anhang unten, die Liste der Unterauftragsverarbeiter und Antworten darauf, wie die Dienste mit Daten umgehen.
• Jede Änderung an den Registry-Objekten des Kunden steht mit einer signierten Quittung im Transparenzlog, und jede Änderung an einem verwalteten Edge-Router erzeugt einen Audit-Eintrag, den der Kunde einsehen kann, wenn er danach fragt.
• Reicht das nicht, kann eine Inspektion vereinbart werden, mit angemessener Vorankündigung, zu Geschäftszeiten, ohne Störung des Betriebs und durch jemanden, der zur Vertraulichkeit verpflichtet ist und nicht mit uns im Wettbewerb steht. Geht eine Inspektion über das hinaus, was Art. 28 Abs. 3 lit. h DSGVO verlangt, können wir die Zeit berechnen.

Übermittlung in Drittländer

• Personenbezogene Daten werden nur in der EU verarbeitet, auf Servern in Deutschland. Die einzige Ausnahme ist Sentry wie oben beschrieben, auf Grundlage der EU-Standardvertragsklauseln.
• Eine andere Übermittlung gibt es nicht, es sei denn, der Kunde weist sie schriftlich an und Kapitel V DSGVO erlaubt sie.

Haftung

Gegenüber betroffenen Personen haftet jede Seite nach Art. 82 DSGVO. Untereinander trägt jede einen Schaden im Verhältnis ihres Anteils an der Verantwortung für seine Ursache (Art. 82 Abs. 5 DSGVO). Im Übrigen richtet sich die Haftung nach den allgemeinen Nutzungsbedingungen, wie sie sie für Unternehmer festlegen. Nichts in dieser Vereinbarung beschränkt die Haftung nach Art. 82 DSGVO.

Änderungen

Eine wesentliche Änderung dieser Vereinbarung wird dem Kunden mindestens sechs Wochen vor ihrem Inkrafttreten per E-Mail angekündigt, und bei seiner nächsten Anmeldung wird der Kunde gebeten, der neuen Fassung zuzustimmen; sie wird ihm dabei vollständig gezeigt und ist im Dokumentenarchiv verlinkt, ohne Liste der Änderungen. Eine neue Fassung gilt für eine Bestellung erst, wenn der Kunde ihr zustimmt. Bis dahin bleibt jede Bestellung bei der Fassung, die ihr Bestellformular nennt. Stimmt der Kunde nicht zu, können wir die Bestellung zu ihrem nächsten ordentlichen Ende nach ihrem Bestellformular beenden, und erst dann. Für das Hinzunehmen oder Ersetzen eines Unterauftragsverarbeiters gilt „Unterauftragsverarbeiter“ oben, nicht dieser Abschnitt. Jede Fassung bleibt im Dokumentenarchiv.

Anhang: Technische und organisatorische Maßnahmen

Dies sind die Maßnahmen nach Art. 32 DSGVO für die Dienste, die diese Vereinbarung umfasst.

Identität und Zugang

• Menschen melden sich auf csr.gplatform.org mit einem Passkey oder einem Passwort an. Passwörter werden als argon2id-Hashes gespeichert und haben mindestens 15 Zeichen; fünf Fehlversuche in Folge sperren das Konto für 15 Minuten.
• Sitzungstoken werden nur als Hashes gespeichert. Eine Sitzung endet nach 7 Tagen ohne Nutzung oder spätestens nach 30 Tagen; für die Root-Rollen von Tier 0 nach 30 Minuten ohne Nutzung oder spätestens nach 12 Stunden. Eine Bestätigung mit einem Passkey gilt 5 Minuten.
• Jede Änderung durch Tier 0 braucht einen Passkey. Freigaben durch Tier 0 erfolgen im Vier-Augen-Prinzip in der Datenbank, eine Anfrage verfällt 72 Stunden nach ihrer Stellung, und eine Freigabe, die allein erteilt wird, solange Tier 0 aus einer Person besteht, wird als allein entschieden gekennzeichnet.
• Rollen (Owner, Admin, Tech, Abuse, Read-only) werden beim Inhaber vergeben und im Zuteilungsbaum nach unten vererbt. Eine Rollenvergabe wird nie gelöscht; eine widerrufene Vergabe bleibt in der Historie.
• API-Schlüssel laufen immer ab (spätestens nach 400 Tagen, standardmäßig nach 90 Tagen), tragen nie Rechte von Tier 0, können keine Freigabe entscheiden und keine Schlüssel verwalten, werden einmal angezeigt, können auf benannte Adressen beschränkt werden und sind auf 600 Anfragen pro Minute begrenzt; fehlgeschlagene Schlüsselversuche sind auf 30 je Adresse in 15 Minuten begrenzt.
• Der Support arbeitet mit Ansichten, die nur lesen. Niemand meldet sich als Nutzer eines Kunden an.

Integrität von Änderungen

• Jede Änderung an der Registry wird vom Inhaber signiert, mit einer Passkey-Bestätigung über den Hash der Änderung oder einem unter einem Passkey registrierten Ed25519-Automatisierungsschlüssel, und ihre Quittung ist ihr Eintrag im Transparenzlog mit einem Einschlussnachweis. Ein Monitor prüft jede protokollierte Änderung gegen die Schlüssel des Inhabers und warnt den Inhaber vor allem, was er nicht signiert hat.
• Bundles für Router und Hubs werden in Vault Transit signiert und tragen eine Seriennummer; eine niedrigere Seriennummer wird abgewiesen, und der Signaturschlüssel ist im Agent-Release fest hinterlegt.
• Jede Anfrage eines Agenten ist eine EdDSA-Signatur, gebunden an den Hash des Anfrageinhalts und nach 60 Sekunden ungültig. Die Registrierung nutzt ein Einmal-Token, das 24 Stunden gültig ist, und der Schlüssel des Agenten wird auf dem Router erzeugt.
• Eine Änderung, die einen Router abschneiden könnte, wird mit Bestätigungspflicht angewendet und zurückgerollt, wenn der Router nicht innerhalb von 5 Minuten meldet, dass er gesund ist. Änderungen an Hubs erreichen zuerst einen Kanarien-Hub und werden bei einer Verschlechterung zurückgerollt.
• Release-Abbilder werden lokal neu gebaut, ihre Prüfsummen mit dem Build verglichen und über Vault signiert. Agenten und Hubs führen nur signierte Abbilder aus.

Schlüssel

• Schlüssel liegen in HashiCorp Vault auf eigener Hardware in Deutschland, erreichbar nur über WireGuard. Sie verlassen Vault nie, mit zwei schriftlich festgehaltenen Ausnahmen: RPKI-Einmalschlüssel, die im Arbeitsspeicher entstehen und nach einer Signatur vernichtet werden; und die WireGuard-Schlüssel der Hubs und gehosteten Router von Tier 0, die in Vault liegen und beim Start über eine direkte Verbindung geholt werden, die nie über GOpenCNR läuft.
• Der Schlüssel des RPKI-Vertrauensankers ist so abgeschirmt, dass nur eine Zeremonie-Identität ihn nutzen kann, in geskripteten Zeremonien im Vier-Augen-Prinzip mit Protokoll im Transparenzlog.
• Die Schlüssel der Router und Geräte von Mitgliedern, auch die eines verwalteten Edge-Routers, werden auf ihrem Host erzeugt und verlassen ihn nie; registriert werden nur ihre öffentlichen Hälften.

Das Netz

• Zwei WireGuard-Schichten: vom Router zum Hub und darin Ende-zu-Ende von Agent zu Agent. Hubs leiten den inneren Verkehr verschlüsselt weiter und führen Zähler, keine Verkehrsaufzeichnungen.
• Verkehrsflüsse werden nur in einem offenen Fall stichprobenartig erfasst, höchstens 7 Tage lang, 1 von 1.000 Paketen, mit Quelle, Ziel, Port und Größe, nie mit Inhalt; die Stichproben werden gelöscht, wenn der Fall abgeschlossen ist.
• Jeder Tunnel nimmt nur Absender aus dem registrierten Adressraum des Mitglieds an, und Hubs leiten nur Pakete weiter, deren Quelle und Ziel beide in GOpenCNR-Bereichen oder einer benannten Zusammenschaltung liegen.
• Importfilter werden aus der Registry erzeugt und validieren RPKI und ASPA. Ein Hub, der keine frischen Daten laden kann, behält seine letzten guten Filter und öffnet sich nie.
• Geschlossene Routen laufen nur über die Hubs von Tier 0 und zertifizierte Hubs, nur Mitglieder der Zielgruppe halten die inneren Schlüssel der anderen, und ein Leck wird sofort unterbrochen.
• Die Firewall des Agenten weist Verkehr aus GOpenCNR ab, solange ihn kein angemeldeter Dienst öffnet.
• Endpunktadressen sind im Ruhezustand verschlüsselt und werden nie veröffentlicht. Im Transparenzlog erscheinen sie nur als Hashes, jeder mit einem eigenen zufälligen Salt von 32 Byte, der verschlüsselt beim Eintrag liegt und dem Inhaber und angenommenen Peers mit der Quittung übergeben wird, damit sie den Eintrag prüfen können und niemand eine Adresse aus dem Log erraten kann.

Datensparsamkeit

• Die rohe IP-Adresse in einem Audit-Eintrag wird nach 90 Tagen gelöscht; ein Hash mit Schlüssel (HMAC-SHA256 unter einem Geheimnis in Vault) bleibt beim Eintrag.
• Anfrageprotokolle werden nach 14 Tagen gelöscht. Zeitfenster der Ratenbegrenzung sind nur nach dem Adress-Hash geschlüsselt und werden nach 24 Stunden gelöscht, Idempotenz-Einträge ebenfalls nach 24 Stunden.
• Zustandsberichte und Telemetrie werden 12 Monate aufbewahrt; feine Verkehrszähler 90 Tage, danach nur Tagessummen je Mitglied bis 12 Monate.
• Anwendungsprotokolle durchlaufen eine Schwärzungsliste. Fehlerberichte an Sentry enthalten, wie oben konfiguriert, keine personenbezogenen Daten und werden 90 Tage aufbewahrt.
• Das Transparenzlog enthält Kennungen und Hashes, nie Namen, E-Mail-Adressen oder IP-Adressen.

Verfügbarkeit und Wiederherstellung

• Die Datenbanken, das RPKI-Repository und die Host-Konfiguration der Hubs werden jede Nacht verschlüsselt auf einen Proxmox Backup Server auf eigener Hardware in Deutschland gesichert und 90 Tage aufbewahrt, und ihre Wiederherstellung wird geübt.
• Router laufen mit ihrem letzten signierten Bundle weiter, wenn die Steuerungsebene ausfällt, und kein kritischer Pfad der drei Dienste hängt im Kreis von einem anderen ab.
• Schriftliche Abläufe decken einen Hub-Ausfall, die Kompromittierung eines Schlüssels, ein Leck geschlossener Routen, einen Vault-Ausfall und die Meldung von Vorfällen ab.

Organisation

• Alle, die die Daten verarbeiten, sind zur Vertraulichkeit und auf das Fernmeldegeheimnis verpflichtet.
• Für den Agenten, den Hub, die RPKI-CA, das Signieren von Änderungen und geschlossene Präfixe gibt es jeweils ein Bedrohungsmodell, und jede Routing- oder Filterfunktion wird durch ein Laborszenario belegt.
• Schwachstellen werden nach der GOpenCNR-Sicherheits- und Offenlegungsrichtlinie gemeldet und behandelt.
• Wir führen ein Sicherheitskonzept nach § 166 Abs. 2 TKG, melden Sicherheitsvorfälle nach § 168 TKG der Bundesnetzagentur und dem BSI innerhalb von 24 Stunden, 72 Stunden und einem Monat und melden Verletzungen des Schutzes personenbezogener Daten in der Telekommunikation nach § 169 TKG der Bundesnetzagentur und der BfDI. Gelhaus Solutions ist beim BSI als besonders wichtige Einrichtung registriert.