Rechte und Mandanten

Wer darf auf welchem Server wie weit gehen, was hält ein Mandant zurück, und wie prüft man hinterher, was geschehen ist. Eine Regel trägt das meiste, und sie passt in einen Satz.

Zwei Rollen, und Rechte einzeln

Ein Mitglied hat, was die Buchstaben auf jedem Server geben, und liest daneben das Wissen und das Audit-Protokoll. Ein Administrator hat alles, einschließlich Benutzer, Einstellungen und jeden Server; der Deckel eines Servers begrenzt trotzdem, was Heinzel dort tut. Unter Benutzer laden Sie Leute per Mailadresse ein; sie bekommen einen Anmeldelink und nehmen die Einladung nach der Anmeldung an.

„Rechte“ bei einer Person zeigt jedes Recht als Satz mit drei Antworten: wie es steht, ja, nein. So wird aus jemandem, der nach seinen Buchstaben auf Servern arbeitet, jemand, der trotzdem nur schaut („alles, aber nichts ausführen“), oder ein Mitglied bekommt ein einzelnes benanntes Recht, etwa die zweite Freigabe, wo die Matrix zwei Personen verlangt. „Nein“ gewinnt gegen „Ja“. Rechte zum Ansehen sind frei; jedes Recht zum Handeln belegt einen Platz der Lizenz.

Die Rechteseite einer Person: Rechte als Sätze mit den drei Antworten wie es steht, ja und nein — Ein Recht, drei Antworten. Die Seite sagt vor dem Speichern in einem Satz, was dabei herauskommt.

Drei Buchstaben

Buchstaben	Öffnet
`---`	Nichts. Auf einem Server: gesperrt für alle; wer ihn sah, sieht ihn weiter, wie `ls` eine Datei zeigt, die niemand öffnen darf.
`r--`	Sieht: den Server in Listen und in der Suche, seine Notizen, das Journal, Befunde und die Sessions dort, zum Lesen.
`rw-`	Arbeitet: eigene Sessions, Freigaben, den Server betreuen, Zeitpläne dort. Heinzel liest allein und ändert nichts ohne Freigabe.
`rwx`	Heinzel ändert allein: was die Matrix des Mandanten auf dieser Stufe sofort laufen lässt, voreingestellt alles außer Identitäten und Gesperrtem, ohne dass jemand einen Befehl vorher liest.

Die Regel

Was eine Person auf einem Server darf, ist der höchste Zugriff ihrer Teams auf die Gruppen, in denen der Server ist, und nie mehr als ein Deckel. Vier Wörter tragen sie:

Ein Team ist eine Menge von Personen (Gruppen, Teams). Jede Person ist auch ein Team für sich, das Heinzel anlegt.
Eine Servergruppe ist eine Menge von Servern (Gruppen, Servergruppen). Jeder Server ist auch eine Gruppe für sich. Ein Server ist in einer Gruppe, weil ihn jemand hineingelegt hat, nicht über Tags.
Ein Zugriff ist eine Zeile: ein Team, eine Servergruppe, Buchstaben. Die Grundregel ist die Zeile „alle auf allen Servern“, mit der ein neuer Mandant beginnt: rw-.
Ein Deckel ist das Höchste, was irgendjemand darf, Administratoren eingeschlossen: auf einem Server, einer Servergruppe, einem Zugang, und der der Installation für den Mandanten. Der niedrigste gilt.

Ein Beispiel

Die Beispiel GmbH hat zwei Teams und drei Servergruppen:

Team	Servergruppe	Zugriff
Alle	Jeder Server	`r--` (die Grundregel, gesenkt)
Bereitschaft	Web	`rw-`
Bereitschaft	Backup	`rw-`
Datenbank	Datenbanken	`rwx`

Dazu zwei Deckel: db02 trägt rw-, weil ein Kunde ihn mitbetreut, und der Zugang root auf allen Webservern trägt r--. Daraus folgt:

Jonas aus der Bereitschaft arbeitet auf web05 als deploy mit Freigabe vor jeder Änderung. Als root liest er dort nur. Auf db01 sieht er zu, und auf einer Session dort kann er nichts freigeben.
Mira aus dem Datenbank-Team lässt Heinzel auf db01 allein ändern. Auf db02 wartet trotzdem jede Änderung auf sie: der Deckel.
Ein neuer Server db03 gehört keiner Gruppe, bis ihn jemand hineinlegt. Bis dahin sehen ihn alle nur, und wer ihn angelegt hat, arbeitet darauf.

Die Seite Wer darf was (Verwaltung, Gruppen) rechnet das für jede Person vor, Server für Server, mit dem Weg: über welches Team auf welche Gruppe, und welcher Deckel gehalten hat.

Die Seite Wer darf was: die Grundregel alle auf allen Servern als vier Knöpfe, darunter die Rechte einer gewählten Person mit der Erklärung, und die Liste aller Zugriffe mit der Seite, auf der jeder geändert wird — Die Grundregel, eine Person mit der Erklärung ihrer Rechte, und jeder Zugriff, den es gibt.

Wartungsfenster

Eine Servergruppe kann ein Wartungsfenster tragen: Wochentage, von und bis, in der Zeitzone des Mandanten. Außerhalb des Fensters wartet auf den Servern der Gruppe jede Änderung wie auf rw- (auf eine Person, auf zwei, wo die Matrix es dort verlangt), auch auf rwx, und ein geplanter Lauf überspringt, was er geändert hätte. Wer außerhalb freigibt, setzt sich darüber hinweg, und das Audit-Protokoll zeigt das.

Was der Mandant zurückhält

Neben der Stufe hat ein Mandant fünf Werkzeuge. Keines hebt die Sperrliste auf oder öffnet einen Nur-Lese-Server.

Einstellungen, Richtlinie: die Freigaberegeln mit der Stufe, mit der eine neue Session beginnt, und dem Gegenzeichnen, darunter die Matrix mit einer Zeile je Klasse und einer Spalte je Stufe, dann die vier Fähigkeiten Identität, Secrets und Zertifikate, Partitionieren und OS-Austausch — Die Richtlinie: Womit eine Session beginnt, was jede Klasse auf jeder Stufe tut, und was Heinzel Pro über das offene Regelwerk hinaus darf.

Die Matrix (Einstellungen, Richtlinie): eine Zeile je Risikoklasse (schreibend, Paket, Dienst, Firewall, Identität, Neustart, unumkehrbar), eine Spalte je Stufe, in jeder Zelle „läuft sofort“, „wartet auf eine Person“, „wartet auf zwei Personen“ oder „läuft nie“. Voreingestellt wartet auf rw- alles außer Lesen auf eine Person, Unumkehrbares und Identitäten auf zwei; auf rwx läuft alles sofort, Identitäten warten auf zwei. Drei Zellen bewegt niemand: Lesen läuft, Gesperrtes läuft nie, eine Identität (ein Konto, ein Schlüssel, eine sudo-Zeile) wartet mindestens auf eine Person. Das Formular eines Servers stellt eine Zelle für diesen Server strenger, nie milder.
Not-Aus (Einstellungen, Richtlinie, und ein Banner auf jeder Seite): Keine Session startet, kein Befehl läuft, kein Zeitplan feuert, und was läuft, wird abgebrochen. Er braucht einen Grund; ein Administrator hebt ihn auf. Die Installation hat einen für alle Mandanten.
Sperrliste (Einstellungen, Befehle): Befehle, die hier nie laufen, auf allen Servern oder auf einem, in Worten („diese Worte in dieser Reihenfolge“) oder als regulärer Ausdruck. Geprüft beim Vorschlag und noch einmal vor dem Ausführen. Statt zu sperren kann eine Regel einen Befehl höher einstufen („zählt als“: rm unter /srv/db als unumkehrbar); die Matrix entscheidet dann wie für diese Klasse. Nach unten stuft keine Regel.
Dauerfreigaben (Einstellungen, Befehle): exakte Befehlszeilen, die immer in Ordnung sind. Ein Vorschlag, der ihr Zeichen für Zeichen gleicht, läuft ohne Person und wird so protokolliert. Unumkehrbare Befehle sind nie abgedeckt.
Erhöhte Stufe auf Zeit: ein Administrator gibt einem Server für höchstens vier Stunden rwx, für eine Migration, die durchlaufen soll.

Beispiel	Eintrag	Wirkung
Sperrliste, in Worten	`rm -rf /var/lib/postgresql` auf jedem Server	Jeder Befehl, der diese Worte in dieser Reihenfolge enthält, wird abgelehnt, mit dem Grund, den Sie angeben.
Sperrliste, regulärer Ausdruck	`^.\bshutdown\b.$` auf `db01`	Kein Herunterfahren der primären Datenbank, auf keiner Stufe.
Dauerfreigabe	`systemctl restart php8.2-fpm` auf der Gruppe Web	Läuft ohne Freigabe, auch auf `rw-`. `systemctl restart php8.2-fpm.service` ist eine andere Zeile und fragt.

Einen Befehl gegen die Richtlinie prüfen (Einstellungen, Befehle) sagt, was all das für einen Befehl auf einem Server entscheiden würde, ohne ihn auszuführen. Fügen Sie einen Befehl ein, wählen Sie den Server, drücken Sie Prüfen: Einstufung, und was auf jeder Stufe passieren würde.

Einstellungen, Befehle: die Sperrliste des Mandanten mit Feldern für Befehl, Lesart, Zählt als, Server und Grund, die Dauerfreigaben, und das Formular Einen Befehl gegen die Richtlinie prüfen — Sperrliste, Dauerfreigaben und die Probe.

Fähigkeiten

Das offene Regelwerk Heinzel liest Partitionstabellen, Bootloader, Benutzerkonten und Secrets und ändert nichts davon. Heinzel Pro tut es, wo der Mandant die Fähigkeit auf der Richtlinien-Seite einschaltet: Identität (Konten, Schlüssel, sudo-Rechte; an) und Secrets und Zertifikate (an) von Anfang an, Partitionieren und OS-Austausch aus. Ein Identitätsbefehl wartet auf jeder Stufe mindestens auf eine Person und läuft nie unbeaufsichtigt; was Partitionieren und OS-Austausch tun, ist unumkehrbar und folgt dieser Zeile der Matrix. Das Serverformular schaltet eine Fähigkeit für einen Server wieder aus, damit ein Datenbank-Host nie partitioniert wird.

Die Richtlinie als Datei

Unter Einstellungen, Richtlinie als Datei steht alles davon als JSON mit einem SHA-256 über den Inhalt: zum Vergleichen zweier Mandanten, zum Ablegen im Repository, zum Vorlegen beim Prüfer. Eine eingefügte Datei wird mit dem Eingestellten verglichen; Anwenden macht die Richtlinie gleich der Datei und hält den Hash fest.

Kontrolle im Nachhinein

Audit-Protokoll (Navigation): jede Anmeldung, jeder Befehl, jede Entscheidung, jede Einstellung, mit Akteur und Zeit. Nur anhängbar, SHA-256-verkettet; „Kette prüfen“ erkennt Lücken, CSV exportiert. Nichts davon lässt sich nachträglich ändern.
Gegenzeichnen (Sessions, Durchsicht): Eine beendete Session, in der ein ändernder Befehl ohne Freigabe lief, wartet auf die Unterschrift von jemandem, der nicht beteiligt war. Aus in einem neuen Mandanten; einschalten unter Einstellungen, Richtlinie, wenn ein Audit vier Augen bei jeder Änderung verlangt.
Zugriffsüberprüfung (Benutzer): wer fragt und freigibt, wer volle Autonomie hat, wer seit neunzig Tagen nicht angemeldet war, wer keinen zweiten Faktor hat. Ein Administrator bestätigt sie; die Seite mahnt nach einem Quartal.
Kontrollen (Verwaltung): die Schutzmaßnahmen des Produkts, zugeordnet zu ISO/IEC 27001 Anhang A, SOC 2 und BSI IT-Grundschutz, mit dem Stand im Mandanten und dem Verweis auf den Nachweis. Eine Zuordnung für das Gespräch mit einem Prüfer, kein Zertifikat.

Das Audit-Protokoll: Filter nach Aktion, Akteur, Suche und Zeitraum, darunter die Einträge mit Uhrzeit, Aktion und Akteur, die Knöpfe Kette prüfen und CSV — Das Protokoll nach einer Nacht. Jeder Eintrag klappt auf; Ziel-Links springen zur Session oder zum Server.

Mandanten

Ein Mandant ist ein Kunde, eine Abteilung oder eine Umgebung: eigene Server, Schlüssel, Sessions, Zeitpläne, ein eigenes Audit-Protokoll, ein eigener Modellanbieter, eigene Richtlinien. Nichts davon ist aus einem anderen Mandanten sichtbar, weder für Menschen noch für den Agenten. Eine Installation beginnt mit einem Mandanten und braucht keinen zweiten; mit nur einem erwähnt die Oberfläche Mandanten nirgends.

Konten gehören zur Installation, Rollen zu einem Mandanten. Ein Mensch hat ein Konto und in jedem Mandanten, dem er angehört, eine Rolle. Wer mehrere hat, wechselt oben in der Navigation.
Ein Mandant je Tab. Die Adresse nennt ihn (/acme/servers), also arbeiten mehrere Tabs nebeneinander in mehreren Mandanten, und ein halb ausgefülltes Formular landet nie im falschen.
Administratoren der Installation legen Mandanten an, schließen und löschen sie, pflegen Tarife und ändern, was mandantenübergreifend gilt: Anmelderegeln, Single Sign-on, Lizenz, Regelwerk, Mailversand. Sie betreten einen Mandanten nur, wenn sie dort Mitglied sind, mit der Rolle, die sie dort haben.
Ein neuer Mandant nennt die Mailadresse seiner ersten Admin-Person; sie wird eingeladen und legt danach ihre Leute, Server und ihren Modellanbieter selbst an. Wer den Mandanten angelegt hat, bleibt draußen.
Tarife sind Vorlagen für die Grenzen eines Mandanten: Plätze, Server, und wie weit Heinzel allein gehen darf (die Obergrenze). Plätze zählen pro Konto für die ganze Installation: Wer in drei Mandanten arbeitet, belegt einen.
Ein geschlossener Mandant behält seine Daten, lässt niemanden hinein und ruht. Löschen geht nur bei einem geschlossenen und verlangt, dass man seine Adresse eintippt; danach ist alles darin weg, auch sein Audit-Protokoll.

Installation, Mandanten: der Not-Aus für alle Mandanten, der Mandant Beispiel GmbH mit Administratoren, Benutzern, Plätzen, Servern, seiner Obergrenze und seinem Zustand, und die Liste der Administratoren der Installation — Die Seite Mandanten, mit einem Mandanten. Die Obergrenze „allein höchstens: rwx“ wird hier gesetzt.

Anmeldung und Single Sign-on

Unter Installation, Einstellungen, Anmeldung: Passwortanmeldung an oder aus, 2FA-Pflicht, Abmelden nach Untätigkeit, und Single Sign-on mit jedem OpenID-Connect-Aussteller (Entra ID, Keycloak, Google Workspace, Authentik). Die Redirect-URI, die Sie dort eintragen, ist https://heinzel.example.com/auth/oidc/callback. Neue SSO-Benutzer erhalten die Standardrolle; eine Domain-Liste begrenzt, wer sich anmelden darf. Mit mehreren Mandanten tritt ein neues SSO-Konto keinem bei und wartet auf einen Administrator.