Was hat sich geändert

Jede Inhaltsänderung wird versioniert. Wählen Sie eine Version, um sie mit der vorherigen zu vergleichen.

Version 8 → 9

Aktualisierung

Vier neue Lektionen schließen die Lücken zur MCIP-Prüfung: Änderungssteuerung in den Produkten, Design-Einschränkungen für die Discovery, Absicherungen für die ersten Änderungen in der Produktion sowie Abnahmenachweise mit Betriebsaufgaben. Jeder Wissenscheck hat zwei neue Fragen. Die neuen Lektionen erhielten Diagramme.

4 Lektionen aktualisiert

Inhaltliche Aktualisierung. Eingeschriebene Lernende wurden benachrichtigt.

Änderungssteuerung: Was die Produkte beim Speichern tun

Ein Änderungsplan ist nur so gut wie sein Bild davon, was das Produkt tut, wenn jemand auf `Save` klickt. Einige Produktverhalten entscheiden darüber, ob ein sorgfältiger Plan in der Praxis hält. Diese Lektion sammelt die wichtigsten für die Projektumsetzung, jeweils mit der Arbeitsregel, die daraus folgt. ### Go oder No-Go ist eine Prüfung, kein Gefühl Schreiben Sie vor jeder Welle messbare Abschlusskriterien auf: Registrierungsquote, Fehlerquote bei der Anmeldung, Helpdesk-Tickets je hundert Benutzer. Vereinbaren Sie die Schwellenwerte, bevor die Welle beginnt, und testen Sie das Rollback vor der Sitzung. Der Lenkungskreis vergleicht dann Zahlen mit Schwellenwerten, statt Eindrücke auszutauschen. Eine Fehlentscheidung bleibt günstig, weil der Rückweg bereits erprobt ist. ### Monosync: Die Änderungshistorie ist ein Protokoll, kein Rückgängig Jedes Speichern einer Integration ist ein Commit mit Kommentar und Ticketnummer. `Show Commits` listet auf, wer was geändert hat, und zeigt den Unterschied. Eine Wiederherstellen-Funktion gibt es nicht. | Produktverhalten | Arbeitsregel | | --- | --- | | Zwei Personen bearbeiten dieselbe Integration. Das zweite Speichern zeigt `Integration Is Changed` und ersetzt nach `Overwrite` die Arbeit der ersten Person | Ein Bearbeiter je Integration zur gleichen Zeit, eine Ticketnummer an jedem Commit, Review mit `Show Commits` | | Eine frühere Version lässt sich nicht per Klick wiederherstellen | Der Änderungsplan hält die früheren Werte fest, damit sie von Hand wieder eingetragen werden können | | Werte, die bereits in ein Zielsystem geschrieben wurden, bleiben dort | Das Rollback nennt, wer die Zieldaten repariert und wie | ### Zeitpläne und Wartungsfenster Zeitpläne sind Cron-Ausdrücke in **UTC**. Ein neuer oder geänderter Zeitplan an einer aktiven Integration läuft in der Regel einmal direkt nach dem Speichern, weil sein nächster Laufzeitpunkt bereits in der Vergangenheit liegt. Wer am Freitag einen Zeitplan für ein Fenster am Samstag "vorbereitet", startet also am Freitag einen Lauf. Speichern Sie Zeitplanänderungen innerhalb des Fensters. Eine Integration führt nie zwei Jobs gleichzeitig aus. Wenn ein Zielsystem für Wartung heruntergefahren wird, pausiert `Start Maintenance` die Integrationen. Drei Details gehören ins Runbook: - Es wartet nicht auf laufende Jobs. Öffnen Sie `Integration Jobs` und bestätigen Sie, dass nichts läuft, bevor das Ziel heruntergefahren wird, oder wählen Sie `Start Maintenance with stopping tasks.`, um die Jobs abzubrechen. - `Run Once` funktioniert auch an einer pausierten Integration. Weisen Sie die Operatoren an, es im Fenster nicht zu verwenden. - Nach dem Fenster laufen die Zeitpläne ab dem Stoppzeitpunkt weiter. Im Fenster verpasste Läufe werden nicht nachgeholt. ### Monosign: drei Änderungen ohne Pilotmöglichkeit **Upgrades.** Lesen Sie in den Release Notes den genauen Pfad nach. Das Upgrade von v2026.07 auf v2026.09 erfordert einen vollständigen Stopp aller App-Knoten und identische Migrator-Versionen, weil eine gemischte Flotte Arbeit doppelt ausführt und Cache-Invalidierungen verpasst. Ein rollierendes Upgrade Knoten für Knoten gibt es auf diesem Pfad nicht. Vereinbaren Sie daher früh ein Wartungsfenster mit Ausfallzeit. **Angepasste Texte.** Ein bearbeitetes Inhaltselement, etwa der Text einer E-Mail-Vorlage, oder eine bearbeitete Übersetzung übersteht ein Upgrade nur, solange die ausgelieferte Version dieses Elements unverändert bleibt. Erhöht ein Release die Version, ersetzt der ausgelieferte Standard die Bearbeitung in jedem Tenant. Die Release Note enthält für solche Elemente eine Warnung. Bewahren Sie eine Kopie jeder Anpassung auf und planen Sie Zeit ein, um sie erneut einzuspielen. **API Security.** Der Schalter gehört zur Anwendung und erfasst alle Schlüssel dieser Anwendung zugleich. Ein Pilot mit einem einzelnen Schlüssel ist nicht möglich. Listen Sie die Endpunkte auf, die jeder Schlüssel aufruft, vergeben Sie diese Berechtigungen auf der Registerkarte `Permissions` des Schlüssels und schalten Sie den Schalter dann in einem Änderungsfenster ein. "Mit dem Master-Schlüssel funktioniert es" ist kein Nachweis: Eine Master-Anwendung besteht Prüfungen, für die ein gewöhnlicher Schlüssel eine Berechtigung braucht. ::diagram del-change-control ### Praxisbeispiel Ein Partner ändert am Samstag um 22:00 Uhr ein Mapping und verschiebt den Zeitplan einer produktiven Integration. Ein Plan, der das Produkt berücksichtigt, sieht so aus: 1. Ein namentlich benannter Bearbeiter. Niemand sonst öffnet die Integration an diesem Abend. 2. Die früheren Mapping-Werte und der frühere Cron-Ausdruck werden in das Ticket kopiert. 3. Der Zeitplan wird um 22:05 Uhr innerhalb des Fensters gespeichert, ein sofortiger Lauf wird erwartet. 4. Go-Kriterium: keine fehlgeschlagenen Objekte in diesem ersten Lauf. Andernfalls werden die früheren Werte von Hand wieder eingetragen. 5. Ein benannter Verantwortlicher im Zielsystem repariert Werte, die bereits geschrieben wurden.

Design-Einschränkungen, die die Discovery finden muss

Sizing beantwortet die Frage "wie groß". Einige Erkenntnisse aus der Discovery beantworten eine andere: "funktioniert es überhaupt". Im Workshop kostet die Frage nichts, nach dem Go-Live kostet die Antwort viel. Nehmen Sie diese fünf Punkte in Ihre Discovery-Vorlage auf. ### 1. Erreichen die Monosign-Server den Lizenzdienst? Monosign kontaktiert regelmäßig den Lizenzdienst von Monofor, standardmäßig unter `services.monofor.com`. Bei eingeschalteter Online-Prüfung wird die Anmeldung verweigert, sobald der letzte erfolgreiche Kontakt mehr als 7 Tage zurückliegt. Ein Kundennetz ohne ausgehende Route braucht deshalb eine Lizenz, die mit deaktivierter Online-Prüfung ausgestellt wurde. Ablauf und Host-Validierung gelten auch für eine solche Lizenz. Eine Lizenz lässt sich nicht in der Oberfläche importieren. Klären Sie das also mit Ihrem Monofor-Ansprechpartner, bevor das Design unterschrieben wird, nicht am Installationstag. ### 2. Wie groß ist das Verzeichnis? Eine Active-Directory- oder LDAP-Quelle liest je Lauf höchstens `Limit` Objekte (Standard 500000) in Seiten der Größe `Page Size` (Standard 1000). Ein größeres Verzeichnis wird **teilweise und ohne Fehlermeldung** synchronisiert. Fragen Sie für jedes Verzeichnis nach der Objektanzahl. Liegt sie nahe am Standard oder darüber, halten Sie im Design fest, dass `Limit` erhöht wird und dass die erste Synchronisierung mit der Zählung des Verzeichnisses verglichen wird. ### 3. Was liegt zwischen den Benutzern und Monopam? Monopam kennt keine lokalen Passwörter. Benutzer melden sich beim Identitätsanbieter an, normalerweise Monosign, und Monopam hält das Ergebnis in einem Cookie, das die Gruppen und Berechtigungen des Benutzers enthält. Dadurch wird die Antwort der Anmeldung groß. Jeder Reverse Proxy und jeder Load Balancer auf dem Weg muss große Antwort-Header akzeptieren. Ein einziger Hop mit Standardpuffern genügt, um die Anmeldung für Benutzer mit vielen Gruppen zu unterbrechen, typischerweise mit `502 Bad Gateway`. Listen Sie jeden Hop und seinen Verantwortlichen auf. ### 4. Wie läuft Monosync unter Last? Monosync wird als ein Container-Image ausgeliefert. Zwei Umgebungsvariablen bestimmen die Rolle eines Knotens: | Rolle des Knotens | Einstellung | | --- | --- | | Nur Oberfläche | `MONOSYNC_DISABLE_SERVICE=true` | | Nur Serviceknoten (Ausführung der Integrationen) | `MONOSYNC_DISABLE_UI=true` | | Beide Rollen | Keine der beiden Variablen gesetzt | Alle Knoten teilen sich **eine** Datenbank und **ein** authentifiziertes Redis, das den Job-Status und die Master-Wahl hält. Wenn viele Integrationen parallel laufen müssen, während Operatoren in der Oberfläche arbeiten, trennen Sie die Rollen und fügen Sie Serviceknoten hinzu. Geben Sie den Knoten keine getrennten Redis-Instanzen, denn dann koordinieren sie sich nicht mehr. ### 5. Wo liegen die Sitzungsaufzeichnungen? Ein Monopam Gateway zeichnet eine Sitzung nur auf, wenn seine beiden Capture-Pfade konfiguriert sind. Ohne sie öffnet es Sitzungen trotzdem, aber ohne Aufzeichnung. Die Pfade gehören zum Gateway-Host: zu seiner Konfigurationsdatei oder, bei einem Container, zu den Umgebungsvariablen `MONOPAM_GW_CAPTURE_TEMP_PATH` und `MONOPAM_GW_CAPTURE_VIDEO_PATH`. Ist für den Tenant kein CDN konfiguriert, bleiben die Aufzeichnungen auf dem Gateway. Ein Gateway im Container braucht deshalb persistente Volumes auf beiden Pfaden, bemessen nach den erwarteten Aufzeichnungen. Sonst verschwinden die Aufzeichnungen mit dem Container. ::diagram del-design-constraints ### Szenario Eine Bank verlangt die Aufzeichnung jeder privilegierten Sitzung, betreibt ihre Gateways als Container und sperrt ausgehenden Internetzugriff. Daraus folgen drei Designzeilen, bevor das Sizing beginnt: | Erkenntnis | Designzeile | | --- | --- | | Keine Route zum Lizenzdienst | Eine Lizenz mit deaktivierter Online-Prüfung, angefordert beim Monofor-Ansprechpartner | | Gateways im Container, Aufzeichnung ist Pflicht | Persistente Volumes auf beiden Capture-Pfaden jedes Gateways | | Zwei Proxys vor Monopam | Große Puffer für Antwort-Header auf beiden, mit benanntem Verantwortlichen | Keine dieser Zeilen ändert die Anzahl der Server. Jede einzelne würde das Projekt in der ersten Produktionswoche anhalten.

Absicherungen für die ersten Änderungen in der Produktion

Die riskantesten Stunden eines Projekts sind die ersten Änderungen an einem produktiven Tenant: die erste erzwungene Richtlinie, die erste Verzeichnissynchronisierung, das erste Zertifikat und der erste Schlüsselwechsel. Für jede gibt es eine einfache Absicherung. Nehmen Sie alle vier in den Inbetriebnahmeplan auf. ### Ein Weg zurück, bevor MFA erzwungen wird Eine falsch konfigurierte Authentifizierungsrichtlinie kann alle aussperren, auch die Administratoren. Bevor eine Richtlinie für alle Benutzer gilt, stellen Sie sicher, dass ein Notfall-Administratorkonto existiert, das die Richtlinie nicht aussperren kann, und weisen Sie es nach: Melden Sie sich am selben Tag damit an, aus dem Netz, das Sie bei einem Vorfall nutzen würden. Allgemein bewährte Praxis für ein solches Konto: - Es ist ein benanntes Konto, im Runbook dokumentiert und gehört dem Kunden. - Seine Zugangsdaten werden versiegelt aufbewahrt, zum Beispiel in einem Vault, der jede Entnahme protokolliert. - Jede Nutzung wird im Nachgang überprüft. Alle Administratoren von MFA auszunehmen ist nicht dasselbe. Es schwächt die mächtigsten Konten jeden Tag, um einen schlechten Tag abzudecken. ### Erste Synchronisierung eines großen Verzeichnisses: eng beginnen Ein Mapping-Fehler verbreitet sich auf jeden Benutzer, den die Synchronisierung berührt. Halten Sie den ersten Lauf deshalb klein: 1. Richten Sie `User Base DN` auf eine Pilot-OU und klicken Sie auf `Test`. 2. Starten Sie die Synchronisierung und prüfen Sie einige Benutzer von Hand: Attribute, Gruppenmitgliedschaften, Status. 3. Korrigieren Sie Mappings und Filter, solange nur die Pilotgruppe betroffen ist. 4. Erweitern Sie die Base DN auf den vollen Umfang und vergleichen Sie die synchronisierte Anzahl mit der Zählung des Verzeichnisses. Schließen Sie keine Automatisierung an, die Konten deaktiviert oder entfernt, bevor Schritt 4 bestanden ist. ### Das Zertifikat mit `monofor cert install` ersetzen | Verhalten | Bedeutung für Ihren Plan | | --- | --- | | Der Befehl prüft, ob Zertifikat und Schlüssel ein gültiges Paar bilden, bevor er etwas ändert | Ein falsches Dateipaar wird abgelehnt, das laufende System bleibt unberührt | | Er stellt das vorherige Zertifikat und die Konfiguration wieder her, wenn ein späterer Schritt fehlschlägt | Ein fehlgeschlagener Versuch erfordert keine Neuinstallation | | ~~Ein abgelaufenes Zertifikat benötigt~~ `--allow-expired` installiert ein bereits abgelaufenes Zertifikat | Verwenden Sie die Option nur bewusst, zum Beispiel in einer Testumgebung | | `monofor status` warnt 30 Tage vor Ablauf | Tragen Sie Ablaufdatum und Verantwortlichen für die Erneuerung in die Übergabe ein | ### Monopam Vault-Schlüssel: Die Reihenfolge zählt Der Schlüsselring des Vault wird beim Start eines Prozesses aus der Umgebung gelesen. Ein laufender Prozess bemerkt eine geänderte Variable nicht. Die sichere Reihenfolge lautet: 1. Setzen Sie denselben `MONOPAM_VAULT_KEY` samt Version auf **jedem** Prozess, der Geheimnisse liest: Web, Gateway mit seinen Proxys, Automator und RemoteSession. 2. Starten Sie alle neu. 3. Führen Sie erst dann den Job zur Neuverschlüsselung aus. Läuft der Job, während das Gateway noch den alten Schlüsselring hält, schreibt Web Zeilen neu, die das Gateway nicht entschlüsseln kann, und jede Verbindung über das Gateway schlägt fehl. Für einen verlorenen Schlüssel gibt es außerdem keine Wiederherstellung. Halten Sie daher fest, wo er aufbewahrt wird und wer verantwortlich ist, niemals den Schlüssel selbst. ::diagram del-commissioning-day ### Szenario Ein Plan für den Inbetriebnahmetag, der auf diesen Absicherungen aufbaut: | Zeit | Schritt | Nachweis | | --- | --- | --- | | 09:00 | Anmeldung mit dem Notfall-Administratorkonto getestet | Benannter Tester, Ergebnis notiert | | 09:30 | AD-Quelle auf die Pilot-OU begrenzt und synchronisiert | 40 Benutzer von Hand geprüft | | 11:00 | Kundenzertifikat installiert | `monofor status` zeigt die Zeile Certificate ohne Warnung | | 13:00 | Vault-Schlüssel auf fünf Prozessen gesetzt, alle neu gestartet, Job ausgeführt | Eine RDP- und eine SSH-Sitzung über das Gateway geöffnet | Jede Zeile trägt einen Namen und eine Uhrzeit. Dieselbe Liste ist Ihr erster Abnahmenachweis.

Abnahmenachweise und was der Betrieb beobachten muss

Die Abnahme ist der Moment, in dem der Kunde bestätigt, dass der vereinbarte Umfang funktioniert. Die Übergabe ist der Moment, in dem die Operatoren des Kunden dafür verantwortlich werden, dass es so bleibt. Beides hängt davon ab, die Aufzeichnungen des Produkts richtig zu lesen. ### Ein UAT, der etwas beweist Eine Vorführung zeigt Aktivität. Ein Test beweist Abdeckung. Für die Abnahme müssen drei Dinge zutreffen: - Jeder Testfall lässt sich auf eine Anforderung im vereinbarten Umfang zurückführen, und jede Anforderung hat mindestens einen Testfall. - Die Mitarbeiter des Kunden führen die Testfälle aus oder führen sie gemeinsam mit Ihnen aus. Tests allein durch den Partner beweisen nur, dass der Partner zufrieden ist. - Jedes Ergebnis wird mit Datum, Tester, Ergebnis und Nachweis protokolliert, etwa einer Berichtszeile oder einem Screenshot. | Anforderung | Testfall | Nachweis | | --- | --- | --- | | Eine Gruppenzuweisung in Monosign fügt den Benutzer der AD-Gruppe hinzu | Einen Pilotbenutzer zuweisen und auf das Zurückschreiben warten | Die Zeile in Reports → `Provisions` und ihr Verlauf unter `View Logs` | ::diagram del-uat-evidence ### Den Provisionierungsbericht zu Ende lesen Reports → `Provisions` listet das Zurückschreiben von Verzeichnisgruppen und Ressourcen-Provisionierungen auf, jeweils mit dem **letzten** Versuch. Eine Zeile im Status `Provisioned` kann mehrfach fehlgeschlagen sein, bevor sie erfolgreich war. Das Zeilenmenü `View Logs` öffnet jeden Versuch mit Datum, Status und Meldung. Nutzen Sie es, wenn ein Kunde fragt, ob eine Provisionierung unterwegs Fehler hatte. Kennen Sie auch die Grenze: Der Status von SCIM-Pushes ist nicht Teil dieses Berichts. ### Was still fehlschlägt `Dead Letters` unter Management → System → Services sammelt Benachrichtigungen, Provisionierungsjobs und Webhooks, die nicht zugestellt wurden. **Dafür wird kein Alarm ausgelöst.** Jemand muss die Seite öffnen. Das Runbook benennt deshalb einen Verantwortlichen und einen Prüfrhythmus und gibt Kriterien für die beiden Aktionen: | Aktion | Wirkung | Verwenden, wenn | | --- | --- | --- | | `Requeue` | Setzt das Element in den Bereit-Zustand zurück. Es kann erneut fehlschlagen und in die Liste zurückkehren | Die Ursache ist behoben, zum Beispiel ist der Mailserver wieder erreichbar | | `Discard` | Entfernt die Zeile aus der Liste und sendet nichts. Die Zeile und ihr Fehler bleiben in der Datenbank | Das Senden des Elements lohnt sich nicht mehr | ### Das Lizenzbanner Bei eingeschalteter Online-Prüfung zeigt Management ein Banner, sobald der Lizenzserver seit 3 Stunden nicht erreichbar ist. Die Anmeldung wird verweigert, wenn der letzte erfolgreiche Kontakt mehr als 7 Tage zurückliegt. Bringen Sie den Operatoren bei, das Banner als dringend zu behandeln. Die 7 Tage sind die Zeit, die sie haben, um den ausgehenden Zugriff wiederherzustellen, kein Grund zu warten. ### Aufbewahrung ist eine unterschriebene Entscheidung | Produkt | Verhalten | Festzuhaltende Entscheidung | | --- | --- | --- | | Monosign | Das Aktivieren der Regel `Audit` in `Data Retention` löscht ältere Audit-Zeilen dauerhaft, ohne Archiv vor dem Löschen | Die Anzahl der Tage und der Ort, an dem ältere Einträge liegen, falls Compliance sie länger braucht | | Monosync | Auch die Log-Bereinigung hat kein Archiv, und inkrementelle Läufe stützen sich auf den Eintrag des letzten erfolgreichen Laufs | Tageswerte oberhalb der längsten Lücke, die Sie zwischen erfolgreichen Läufen erwarten | Lassen Sie den Compliance-Verantwortlichen des Kunden beide Zeilen im Übergabepaket unterschreiben. Ein Aufbewahrungswert, den niemand gewählt hat, ist die Art von Feststellung, die ein Jahr später in einem Audit auftaucht. ### Übergabe-Checkliste zu diesen Punkten - UAT-Protokoll mit Anforderung, Testfall, Tester, Ergebnis und Nachweis für jede Zeile - Verantwortlicher und Prüfrhythmus für `Dead Letters` im Runbook eingetragen - Lizenzbanner erklärt, mit dem Ansprechpartner, der den ausgehenden Zugriff wiederherstellt - Aufbewahrungswerte vom Compliance-Verantwortlichen unterschrieben