Monopam-Architektur und Installation
Was hat sich geändert
Jede Inhaltsänderung wird versioniert. Wählen Sie eine Version, um sie mit der vorherigen zu vergleichen.
Version 1 → 2
Aktualisierung4 Lektionen aktualisiertDauer
Inhaltliche Aktualisierung. Eingeschriebene Lernende wurden benachrichtigt.
Dauer von 11 auf 15 Minuten geändert.
Monopam speichert keine lokalen Passwörter. Ein Benutzer wird zum Identitätsanbieter des Mandanten geschickt, normalerweise Monosign, und kehrt mit einem signierten Ergebnis zurück, das Monopam in einem Auth-Cookie ablegt. Diese eine Entwurfsentscheidung beantwortet mehrere Planungsfragen zugleich.
| Frage | Antwort | Warum |
| --- | --- | --- |
| Wo erzwingen wir MFA? | Beim Identitätsanbieter | Monopam hat keine eigene MFA. Anmeldedaten und MFA sind Sache des Anbieters, daher gelten Monosign-Zugriffsrichtlinien auch für privilegierte Benutzer |
| Woher kommen Gruppen und Berechtigungen? | Vom Anbieter, im Auth-Cookie | Monopam liest sie bei jeder Anfrage aus dem Cookie |
| Warum wirkt eine Rollenänderung noch nicht? | Der Benutzer muss sich neu anmelden | Das Cookie trägt noch die alten Gruppen |
::diagram pam-signin-path
### Die Proxy-Falle
Weil Gruppen und Berechtigungen im Cookie reisen, ist die Antwort, die die Anmeldung abschließt, groß und wächst mit jeder Gruppe eines Benutzers. Ein Reverse-Proxy mit kleinen Puffern für Antwort-Header lehnt diese Antwort ab.
Ein typischer Fall: Ein Unternehmen stellt nginx vor Monopam. Die meisten melden sich problemlos an. Das Plattformteam, Mitglied in Dutzenden Gruppen, erhält auf dem Rückweg von Monosign `502 Bad Gateway`, und im nginx-Log steht `upstream sent too big header`. An den Konten ist nichts falsch. Die Lösung ist, die Puffer für Antwort-Header (bei nginx `proxy_buffer_size` und `proxy_buffers`) auf **jedem** Proxy-Hop vor Monopam zu vergrößern. Ein vergessener Hop genügt, um die Anmeldung zu brechen, und zwar nur für Benutzer mit vielen Gruppen, weshalb es wie ein Berechtigungsproblem aussieht.
> TipTipp: Scheitert die Anmeldung nur bei stark privilegierten Benutzern, prüfen Sie zuerst die Proxys und erst dann die Richtlinien.
### Lizenznutzung läuft über Monosign
Monopam ruft niemals selbst Monofor-Dienste auf. Alle 15 Minuten zählt es die lizenzierten Module jedes Mandanten und sendet nur die Zahlen, keine Namen und keine Inhalte, an das Monosign des Mandanten. Monosign fügt sie seinem eigenen Lizenz-Heartbeat hinzu. Der Monosign-REST-API-Schlüssel, den Monopam verwendet, braucht die Berechtigung `System.API.System.Usage`. Eine von einer älteren Version aktualisierte Installation läuft ohne sie weiter, meldet aber nichts: Im Monopam-Log steht `License usage could not be reported to Monosign`, und das Lizenzportal zeigt keine Monopam-Nutzung, bis die Berechtigung erteilt ist.
### Was zuerst zu prüfen ist
| Symptom | Zuerst prüfen |
| --- | --- |
| `502 Bad Gateway` auf dem Rückweg von Monosign, nur bei Benutzern mit vielen Gruppen | Die Antwort-Header-Puffer an jedem Proxy-Hop |
| Eine neue Rolle oder Gruppe greift nicht | Ob sich der Benutzer seit der Änderung neu angemeldet hat |
| Das Lizenzportal zeigt keine Monopam-Nutzung | Die Berechtigung `System.API.System.Usage` am Monosign-REST-API-Schlüssel und die Logzeile `License usage could not be reported to Monosign` |
Der Monopam-Webserver öffnet keine Sitzungen zu Zielen. Das tut ein **Gateway**: Es steht dort, wo es die Ziele erreicht, und trägt die Sitzung zurück zu Monopam. Liegen Produktionsserver in einem isolierten Segment, öffnen Sie also weder Ports noch ein VPN in das Segment. Sie stellen ein Gateway bereit, das es erreicht, und lassen die Sitzungen darüber laufen. Die Segmentierung bleibt intakt, und jede Sitzung bleibt vermittelt und aufgezeichnet.
::diagram pam-gateway-path
### Sites: standortbewusstes Routing
Eine **Site** ist ein Standort wie ein Werk, eine Niederlassung oder ein Rechenzentrum. Gateways und Ressourcen werden ihr zugewiesen (`Site` am Gateway, `Advanced` > `Site` an der Ressource). Sites sind optional: Eine Installation ohne Sites verhält sich wie zuvor. Der Standard ist `Unassigned`.
Monopam wählt das Gateway einer Verbindung in fester Reihenfolge:
| Rang | Regel | Ergebnis |
| --- | --- | --- |
| 1 | An der Ressource oder in der Richtlinie ist ausdrücklich ein Gateway gewählt | Diese Auswahl gewinnt immer |
| 2 | Die Ressource gehört zu einer Site mit Gateways | Nur die Gateways der Site werden genutzt |
| 3 | Keines von beiden | Jedes aktive Gateway |
::diagram pam-gateway-order
Zwei Störungen folgen direkt aus dieser Tabelle.
**"Gateway not found" nach dem Aufräumen.** Ein Team legt die Site "Werk Bursa" an, weist das Gateway des Werks zu und verschiebt vierzig Ressourcen in die Site. Bis dahin konnten diese Ressourcen jedes aktive Gateway nutzen. Jetzt dürfen sie nur die Gateways der Site nutzen. Ist dieses Gateway inaktiv oder nicht vom benötigten Verbindungstyp, scheitert jede Verbindung mit `Gateway not found`. Das Badge `Gateways` in der Liste `Sites` zeigt die Zahl aktiver Gateways und wird bei null bernsteinfarben. Sites entscheiden nie, wer sich verbinden darf, sondern nur, welches Gateway genutzt wird.
**Eine Ressource, die ihre Site ignoriert.** Ein Server gehört zur Site Istanbul, deren Gateways gesund sind, doch seine Sitzungen laufen über Ankara. Regel 1 erklärt es: Ein vor langer Zeit an der Ressource oder ihrer Richtlinie gewähltes Gateway gewinnt weiterhin. Entfernen Sie die ausdrückliche Auswahl, dann greift die Site.
### Ein Detail für Datenbankressourcen
Benutzer des Datenbank-Proxys verbinden ihren Client mit dem Proxy-Port des Gateways, den das Verbindungsfenster anzeigt. Das Feld `Port` der Datenbankressource ist etwas anderes: der eigene Port der Datenbank (5432 bei PostgreSQL), über den der Proxy das Backend erreicht. Wer dort den Proxy-Port einträgt, lässt den Proxy sich selbst anrufen, und Verbindungen scheitern.
> Tipp: Scheitert eine Verbindung mit `Gateway not found`, gehen Sie die Reihenfolge von oben durch. Ist an der Ressource oder in ihrer Richtlinie ausdrücklich ein Gateway gewählt? Gehört die Ressource zu einer Site? Zeigt das Badge `Gateways` dieser Site ein aktives Gateway, und hat es den benötigten Verbindungstyp?
Eine Monopam-Installation bedeutet **eine Datenbank, ein Redis und einen Vault-Schlüssel**. Sie kann trotzdem auf mehreren App-Servern laufen. Ein Dienstleister betreibt etwa einen Hauptserver für die meisten Kunden und ergänzt einen eigenen Server für einen großen Kunden. Der Mandant einer Anfrage wird allein aus dem Hostnamen der Anfrage abgeleitet, und eine angemeldete Sitzung ist an den Mandanten gebunden, für den sie ausgestellt wurde.
Jeder App-Server hat zwei unabhängige Listen in seiner Umgebung:
| Einstellung | Entscheidet | Wenn sie falsch ist |
| --- | --- | --- |
| `MONOPAM_SERVED_TENANTS` | Für welche Mandanten dieser Server Webanfragen beantwortet | Ein Host, der zu einem Mandanten außerhalb der Liste gehört, erhält eine Seite, dass der Mandant von diesem Server nicht bedient wird |
| `MONOPAM_JOB_TENANTS` | Für welche Mandanten dieser Server Hintergrundjobs ausführt: Rotation, Alarme, Synchronisierungen, Agenten-Updates | Ein Mandant auf zwei Servern führt seine Jobs doppelt aus. Bei einem Mandanten auf keinem Server warten die Jobs in der Warteschlange |
| `MONOPAM_VAULT_KEY` | Den Schlüssel, der Vault-Daten entschlüsselt | Ein Server mit anderem Schlüssel kann nicht entschlüsseln, Verbindungen scheitern |
::diagram pam-multi-server
Die ersten beiden sind bewusst getrennt. Einen Mandanten zu bedienen heißt nicht, dessen Jobs auszuführen, und umgekehrt.
### Beispiel
Der Dienstleister ergänzt Server B für den Mandanten "acme" und zeigt mit acmes DNS darauf.
1. Benutzer sehen "Tenant 'acme' is not served by this server." Datenbank und Redis sind gesund. Server B führt acme schlicht nicht in `MONOPAM_SERVED_TENANTS`. Tragen Sie ihn ein.
2. Eine Woche später rotieren acmes Passwörter doppelt, und die Alarm-E-Mails kommen zweifach. Server A führt acme noch in `MONOPAM_JOB_TENANTS`, Server B jetzt ebenfalls. Die Jobs eines Mandanten gehören auf **genau einen** Server. Entfernen Sie acme bei einem von beiden.
3. Beide Server und jedes Gateway müssen denselben `MONOPAM_VAULT_KEY` tragen und dasselbe Redis erreichen. Unterschiedlich je Server sind nur die beiden Mandantenlisten.
### Was eine eigene Datenbank nicht leistet
Ein Mandant kann eine eigene Datenbank erhalten. Kunden lesen das mitunter als Sicherheitsgrenze zwischen ihren Daten und den anderen App-Servern der Installation. Das ist sie nicht: Vault-Schlüssel und Steuerungsebene werden von der gesamten Installation geteilt. Sagen Sie das klar. Wer eine solche Trennung braucht, braucht eine eigene Installation.
### Was zuerst zu prüfen ist
| Symptom | Zuerst prüfen |
| --- | --- |
| Die Seite meldet, der Mandant werde von diesem Server nicht bedient | `MONOPAM_SERVED_TENANTS` auf dem Server, auf den der Hostname zeigt |
| Rotationen oder Alarm-E-Mails geschehen doppelt | `MONOPAM_JOB_TENANTS` auf jedem Server: Der Mandant steht auf zweien |
| Die Jobs eines Mandanten warten in der Warteschlange | `MONOPAM_JOB_TENANTS`: Der Mandant steht auf keinem Server |
| Verbindungen scheitern nur über einen Server oder ein Gateway | `MONOPAM_VAULT_KEY` weicht dort von den übrigen ab |
Der Monofor-Agent läuft auf einem Windows-, Linux- oder macOS-Host und bedient lokale Vorgänge wie Kontenerkennung und Skriptläufe. Vier Momente seines Lebens verlangen das Urteil eines Administrators.
::diagram pam-agent-lifecycle
### 1. Registrierung
`Import Resource with Agent` erzeugt ein einzeiliges Installationsskript mit eingebettetem **Setup-Schlüssel**. Der Schlüssel gilt 24 Stunden und kann viele Maschinen registrieren. Wer das Skript besitzt und Monopam erreicht, kann bis zum Ablauf eine Maschine in Ihren Mandanten aufnehmen. Behandeln Sie das Skript daher wie eine Anmeldeinformation: Geben Sie es der Person, die installiert, legen Sie es nicht ins Wiki und erzeugen Sie beim nächsten Mal ein neues.
### 2. Konnektivität
| Weg | Richtung | Wann |
| --- | --- | --- |
| Agent Channel | Der Agent wählt sich bei Monopam ein und hält die Verbindung offen. Monopam schickt Anfragen darüber | Immer bevorzugt. Funktioniert hinter NAT und ohne eingehende Firewallregel |
| Eingehender Listener | Ein Gateway ruft den Agenten auf | Ausweichweg, nur wenn ein Gateway den Host erreicht |
Die Spalte `Connection` auf der Seite `Agents` zeigt den momentanen Stand als `Channel` oder `Inbound`.
### 3. Vertrauen
Jede Anfrage von Monopam an einen Agenten ist signiert. Der Agent hat bei der Registrierung Monopams öffentlichen Schlüssel fixiert und prüft jede Signatur, einen Zeitstempel und eine einmalig gültige Zahl. Ein gestohlener Agenten-API-Schlüssel allein kann einen Agenten also nicht steuern. Zwei betriebliche Folgen:
- **Uhren.** Die Uhren von Agent und Server dürfen höchstens 300 Sekunden auseinanderliegen. Antwortet ein frisch registrierter Agent auf alles mit 401, obwohl die Registrierung gelang, prüfen Sie zuerst die Zeitsynchronisation auf beiden Seiten.
- **Wiederherstellungen.** Monopams privater Signaturschlüssel ist durch den Data-Protection-Schlüssel der Anwendung geschützt. Stellen Sie Monopam ohne diesen Schlüssel auf einem neuen Host wieder her, ist der Signaturschlüssel nicht lesbar, ein neuer wird erzeugt, und jeder Agent lehnt ihn ab, bis er neu registriert ist. Nehmen Sie den Data-Protection-Schlüssel in Ihren Sicherungsplan auf.
### 4. Updates
`Update agent` in einer Zeile oder `Update all agents` teilt Agenten mit, welche Version zu installieren ist. Der Agent lädt das Paket, prüft dessen Prüfsumme, ersetzt seine eigene Binärdatei und startet neu. Konfiguration und Registrierung bleiben unberührt, und nichts aktualisiert sich von selbst.
Planen Sie zwei Dinge ein. Ein Flotten-Update läuft mit fünf Agenten je Mandant alle 30 Sekunden, hundert Hosts brauchen also etwa zehn Minuten. Und jeder Agent startet für einige Sekunden neu, sodass ein Vorgang, der in diesem Moment über ihn läuft, scheitert und wiederholt werden muss. Ein Agent mit `"AllowUpdate": false` in seiner `config.json` verweigert und meldet das im Job-Ergebnis: Ändern Sie die Einstellung auf dem Host oder aktualisieren Sie mit dem Installationsprogramm.
### Was zuerst zu prüfen ist
| Symptom | Zuerst prüfen |
| --- | --- |
| Ein frisch registrierter Agent antwortet auf alles mit 401 | Zeitsynchronisation auf beiden Seiten: Die Uhren müssen innerhalb von 300 Sekunden liegen |
| Nach einer Wiederherstellung auf neuem Host lehnt jeder Agent Monopam ab | Der Data-Protection-Schlüssel wurde nicht wiederhergestellt, daher entstand ein neuer Signaturschlüssel. Die Agenten müssen neu registriert werden |
| Ein Agent verweigert `Update agent` | `"AllowUpdate": false` in seiner `config.json`. Das Job-Ergebnis sagt es |
| Ein Vorgang scheiterte während des Flotten-Updates | Der Agent startete in diesem Moment neu. Führen Sie den Vorgang erneut aus |