# Publizieren ohne Öffentlichkeit URL: https://www.mikebild.dev/de/blog/publizieren-ohne-oeffentlichkeit/ Eine gesperrte Detailseite genügt nicht, wenn derselbe Inhalt weiterhin über Suche, Navigation, Medien oder maschinenlesbare Veröffentlichungsdateien auffindbar ist. ContentKit zieht daraus eine architektonische Konsequenz: Der Zugriffsschutz gehört zum veröffentlichten Stand. Die Zugriffspolitik mit ihren Gruppenreferenzen und genauen oder präfixbasierten Pfadregeln wird beim Release ausgewertet; Leser erhalten entsprechend ihrer Gruppenmitgliedschaften den erlaubten Ausschnitt aus Seiten, Medien, Navigation, Suche und maschinenlesbaren Veröffentlichungsdateien. *Teil 9 der Serie „ContentKit – Publishing für Maschinen“.* Statische Releases und kontrollierter Leserzugriff schließen sich in ContentKit nicht aus. Stand 18. August 2026 beschreibt dieser Text das Modell von ContentKit 4.26.1; die öffentliche API und einzelne Implementierungsdetails können sich in späteren Versionen ändern. ## Zwei getrennte Berechtigungsbereiche Die Zugriffspolitik beschreibt, welche veröffentlichten Inhalte persönliche Leser und Gruppen sehen dürfen. Rechte zum Bearbeiten von Inhalten, Aktivieren eines Releases oder Verwalten der Veröffentlichung betreffen dagegen den Veröffentlichungsprozess. Eine Leserfreigabe darf keinen Release aktivieren; ein Veröffentlichungsrecht ersetzt keinen Leserzugriff. ```mermaid flowchart LR P["Veröffentlichungsprozess"] --> R["Release mit
Zugriffspolitik"] F["Genaue und präfixbasierte
Pfadregeln"] --> A["Zugriffspolitik"] A --> R U["Persönlicher Leser"] --> G["Gruppenmitgliedschaft"] G --> Z["Auswertung des
Leserzugriffs"] R --> Z Z --> O["Erlaubte Seiten, Medien,
Suche und Navigation"] Z --> M["Erlaubte maschinenlesbare
Ausgaben"] ``` Eine falsch vergebene Leserfreigabe erlaubt damit weiterhin keine Änderung am aktiven Release. Die Zugriffspolitik bestimmt den veröffentlichten Ausschnitt für Leser und Gruppen. Änderungen am Inhalt oder am aktiven Veröffentlichungsstand bleiben eine davon getrennte Aufgabe des Veröffentlichungsprozesses. ## Gruppen und persönliche Leser Gruppen wie `customers`, `partners` oder `team` bündeln Leser mit demselben fachlichen Zugriff. Persönliche Leser werden diesen Gruppen zugeordnet. Damit bleibt die Entscheidung nachvollziehbar, welche Identität welchen geschützten Bereich lesen darf, ohne Management-Rechte zum Bearbeiten und Veröffentlichen mit dem Leserzugriff zu vermischen. Gemeinsame Sammelkonten sind dafür ungeeignet. Sie machen aus mehreren Personen eine einzige Leseridentität und erschweren den geregelten Entzug des Zugriffs. Wo persönliche Konten vorgesehen sind, sollte der organisatorische Prozess deshalb auch persönliche Identitäten verwenden. ## Schutz direkt am Dokument Wenn die Zugriffsangabe zum Dokument gehört, benennt die Seite die erlaubte Gruppe im Frontmatter: ```yaml --- kind: page layout: docs title: Customer runbook locale: en slug: customer-runbook translationKey: atlas-customer-runbook-v2 docKey: customer-runbook docsVersion: v2 parent: getting-started navTitle: Customer runbook navOrder: 30 access: [customers] summary: Verified operational procedures for signed-in customers. --- ``` Die Zugriffsangabe ist damit Teil des Inhalts, aus dem der nächste Veröffentlichungsstand entsteht. Eine Änderung an der erlaubten Gruppe betrifft nicht isoliert die sichtbare HTML-Seite. Sie muss zusammen mit den davon abhängigen Ausgaben geprüft und als konsistenter Release aktiviert werden. ## Regeln für ganze Pfadbereiche Für eine größere Dokumentationsstruktur stehen genaue und präfixbasierte Pfadregeln zur Verfügung. Eine genaue Regel schützt einen bestimmten Pfad. Eine Präfixregel erfasst einen zusammenhängenden Pfadbereich, etwa `/de/docs/v2/internal/`. Solche Regeln werden beim Release ausgewertet. Eine geänderte Regel wirkt daher gemeinsam mit dem dazugehörigen Stand von Navigation, Suche und maschinenlesbaren Ausgaben. Eine sofort wirksame Regel könnte dagegen nicht zum noch aktiven Such- und Navigationsstand passen. Dann wäre eine Seite bereits gesperrt, während ihr Titel im vorherigen öffentlichen Index weiter auftaucht. Die releasegebundene Auswertung verhindert diesen geteilten Zustand: Inhalt und Sichtbarkeit werden gemeinsam aktiviert. ## Nicht auffindbar gehört zum Schutz Eine geschützte Seite darf nicht nur beim direkten Aufruf gesperrt sein. Schon Titel, Zusammenfassung oder Suchausschnitte können vertrauliche Informationen offenlegen. ContentKit wendet die Leserfreigabe deshalb auch auf Navigation, Suche, Medien und maschinenlesbare Veröffentlichungsdateien an. Öffentliche Ausgaben dürfen keine Einträge enthalten, die ausschließlich für geschützte Leser bestimmt sind. Angemeldete Leser erhalten dagegen die Navigation und Suchergebnisse, die zu ihren Gruppen und den für sie geltenden Pfadregeln passen. So kann ein Dokument im geschützten Kundenbereich auffindbar bleiben, ohne über öffentliche Ausgaben sichtbar zu werden. `noindex` löst dieses Problem nicht. Ein solcher Hinweis bittet Suchmaschinen, eine abrufbare Ressource nicht zu indexieren. Er entscheidet aber nicht, welcher Leser die Ressource abrufen darf. Die Zugriffspolitik muss vor allen Ausgaberouten greifen, nicht erst als Hinweis innerhalb einer bereits ausgelieferten Seite. ## Medien benötigen dieselbe Berechtigungsgrenze Geschützte Dokumente enthalten häufig Bilder oder PDFs. Wenn die Seite geschützt ist, das referenzierte Medium aber öffentlich abrufbar bleibt, endet der Schutz an der ersten Verknüpfung. Medien müssen deshalb dieselbe Berechtigungsgrenze einhalten wie die Dokumente, zu denen sie gehören. Vor der Aktivierung eines Releases sollten nicht nur Seitenpfade geprüft werden. Referenzierte Medien gehören ebenfalls in die Zugriffsmatrix. Wird eine Datei öffentlich benötigt, ist sie öffentlich sichtbar. Muss sie geschützt bleiben, darf die öffentliche Seite nicht dieselbe Datei referenzieren. ## Rollback stellt den Zugriffszustand des Ziel-Releases wieder her Zugriffsregeln sowie der dazugehörige Such- und Navigationsstand gehören zum Release. Aktivierung und zeigerbasierter Rollback wechseln diesen veröffentlichten Stand gemeinsam. Der Zugriffsschutz steckt damit nicht allein in der sichtbaren Seite. Wird ein fehlerhafter Release zurückgesetzt, gilt wieder die Zugriffspolitik des Ziel-Releases. Daraus folgt noch keine vollständige Auditfunktion mit unveränderlicher Historie, Identitätszuordnung und Aufbewahrungsregeln. Belegt ist die engere architektonische Eigenschaft: Der Rollback stellt neben dem Inhalt auch den dazugehörigen Zugriffszustand wieder her. ## Praxisbeispiel: öffentliche Dokumentation und Kundenbetrieb Ein Anbieter veröffentlicht Installation und API-Referenz für alle. Kunden erhalten zusätzlich Runbooks für Backup, Eskalation und Rücksetzung. Das interne Betriebsteam besitzt weitergehende Anleitungen für Infrastruktur und Schlüsselrotation. Öffentliche Seiten benötigen keine Zugriffsangabe. Kundenseiten tragen `access: [customers]`, der Unterbaum `/de/docs/v2/internal/` wird über eine Präfixregel auf `team` begrenzt. Ein Mitarbeiter, der beide Bereiche benötigt, muss Mitglied beider Gruppen sein. Vor der Aktivierung sollte der Kandidat gegen die erwarteten Sichtbarkeiten geprüft werden: `allowed` bedeutet eine erfolgreiche Ausgabe des angeforderten Inhalts. `authentication required` verlangt zunächst eine Anmeldung. `denied` verweigert den Inhalt trotz angemeldeter, aber unzureichender Gruppe. ```text anonymous -> public installation: allowed anonymous -> customer runbook: authentication required customer -> customer runbook: allowed customer -> internal rotation guide: denied team only -> customer runbook: denied team only -> internal rotation guide: allowed team and customers -> customer runbook: allowed team and customers -> internal rotation guide: allowed public machine-readable output -> no protected entries public navigation and search -> no protected entries anonymous -> protected medium: authentication required customer -> protected medium: allowed ``` Erst wenn diese Matrix stimmt, wird der Release aktiviert. Für die Leser bleiben ein gemeinsamer Dokumentationsauftritt und die entsprechend ihrer Gruppen gefilterte Navigation. ## Zugriff regelmäßig als Matrix prüfen Mit wachsendem Bestand werden einzelne Seitenangaben und Präfixregeln schwerer zu überblicken. Vor jedem Release kann eine Matrix aus Lesergruppen und repräsentativen Pfaden geprüft werden. Entscheidend sind erlaubte und verbotene Fälle gleichermaßen. Eine Prüfung, die nur erfolgreiche Zugriffe betrachtet, erkennt keine zu weit geöffnete Route. ```yaml access_matrix: anonymous: public_installation: allowed customer_runbook: authentication_required internal_rotation: authentication_required customers: public_installation: allowed customer_runbook: allowed internal_rotation: denied team: public_installation: allowed customer_runbook: denied internal_rotation: allowed team_and_customers: public_installation: allowed customer_runbook: allowed internal_rotation: allowed ``` Zusätzlich müssen öffentliche Navigation, Suche und maschinenlesbare Veröffentlichungsdateien auf geschützte Einträge geprüft werden. Eine gesperrte Detailseite genügt nicht, wenn ihr Titel weiterhin in einer öffentlichen Ausgabe erscheint. Für geschützte Bereiche gehört außerdem ein Medientest dazu: Öffentliche Leser, Leser mit falscher Gruppe und Leser mit erlaubter Gruppe müssen jeweils das erwartete Ergebnis erhalten. ## Aufnahme und Austritt eines Kunden Für Kunden- oder Vertragsbereiche sollte eine benannte Person die Zuordnung prüfen, bevor die Automatisierung einen Leser oder seine Gruppen ändert. Eine E-Mail allein sollte keine Änderung auslösen. Beim Austritt sollte die Freigabe außerdem den zu entziehenden Leserzugriff und die betroffenen Gruppen benennen. ## Grenzen des eingebauten Modells ContentKit bietet persönliche Leser, Gruppen sowie genaue und präfixbasierte Pfadregeln. Dieses Modell genügt, wenn sich die benötigten Leserechte damit ausdrücken lassen und Seiten, Medien, Navigation, Suche sowie maschinenlesbare Veröffentlichungsdateien die relevanten Ausgaberouten bilden. Die Entscheidung fällt anders aus, sobald zusätzliche Anforderungen gelten. Dazu gehören etwa verpflichtendes Single Sign-on, Ende-zu-Ende-Verschlüsselung, kundeneigene Schlüssel, Dokumentenrechteverwaltung, besondere Mandantenisolation oder regulatorisch definierte Nachweise. Der hier beschriebene Leser- und Gruppenschutz belegt solche Eigenschaften nicht. Sie benötigen eine zusätzliche Architektur oder ein anderes Ablagemodell. Kundenhandbücher, Partnerbereiche und geschützte Betriebsanleitungen können über ContentKit veröffentlicht werden, wenn das beschriebene Leser-, Gruppen- und Pfadmodell ausreicht und keine dieser zusätzlichen Schutzanforderungen besteht. Schlüsselmaterial, personenbezogene Rohdaten oder Vertragsarchive sollten dagegen nicht allein wegen einer vorgeschalteten Anmeldung in dieses Veröffentlichungsmodell übernommen werden. Ihre Ablage hängt von den konkreten Verschlüsselungs-, Schlüsselverwaltungs-, Isolations- und Nachweispflichten ab. ## Fazit Bei Releases mit geändertem Zugriffszustand sollten öffentliche und geschützte Pfade, Gruppenmitgliedschaften, referenzierte Medien, Navigation, Suche und maschinenlesbare Veröffentlichungsdateien gemeinsam geprüft werden. Ein Rollback wechselt anschließend nicht nur den Inhalt, sondern auch den Zugriffszustand des Ziel-Releases. Reichen persönliche Leser, Gruppen und Pfadregeln für alle relevanten Ausgaberouten aus, kann ContentKit den Zugriff releasegebunden behandeln. Werden darüber hinaus Verschlüsselung, kundeneigene Schlüssel, Mandantenisolation oder regulatorische Nachweise verlangt, genügt dieses Modell allein nicht. ## Weiterführende Quellen - [ContentKit Reader Access Control](https://github.com/MikeBild/contentkit/blob/94a738ef791ffd5fec12e71eaf6ef64fa556c090/docs/ACCESS_CONTROL.md) - [ContentKit-Architektur](https://github.com/MikeBild/contentkit/blob/94a738ef791ffd5fec12e71eaf6ef64fa556c090/docs/ARCHITECTURE.md) - [ContentKit README](https://github.com/MikeBild/contentkit/blob/94a738ef791ffd5fec12e71eaf6ef64fa556c090/README.md)