Was hat sich geändert

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

Version 10 → 11

Aktualisierung

Neues Modul zu Zuweisungen, Genehmigungen und Governance: SCIM-Übertragung an Anwendungen, Gruppenmitgliedschaften und Rückschreiben ins Verzeichnis, Import des Organigramms, Genehmigungswarteschlangen, Delegierung und Verantwortliche, Zugriffspakete und Zertifizierungskampagnen. Diese Themen gehören zur MCSA-Prüfung und waren bisher nicht abgedeckt.

3 Lektionen aktualisiert

Inhaltliche Aktualisierung. Eingeschriebene Lernende wurden benachrichtigt.

SCIM-Übertragung an Anwendungen

Eine Anwendung, deren Hersteller die Standard-Endpunkte `/Users` und `/Groups` anbietet, spricht SCIM 2.0. Eine solche Anwendung braucht keinen Konnektor: Applications → Anwendung → Tab `Provisioning` → Tab `SCIM` überträgt die der Anwendung zugewiesenen Personen. Das Konto existiert also, sobald ein Benutzer zugewiesen ist, und verschwindet, wenn die Zuweisung endet. ### Richtung: Monosign ist der Client Monosign ruft den SCIM-Endpunkt der Anwendung auf. Es **stellt keinen eigenen SCIM-Endpunkt bereit**. Ein anderes Identitätssystem wie Microsoft Entra ID kann daher keine Benutzer per SCIM nach Monosign übertragen. Um Identitäten hereinzuholen, verwenden Sie eine Benutzerquelle: einen Verzeichniskonnektor oder einen Import. Auch der `SCIM Entitlement Provider` aus der vorigen Lektion ist ein Client. Er liest den SCIM-Endpunkt des anderen Systems. ### Einstellungen - `Enable Provisioning`: der Hauptschalter. Solange er aus ist, erfolgt kein Aufruf. - `API Url` und `API Key`: die SCIM-Basisadresse und ein Bearer-Token. - `Enable Auto-sync` mit `Timing`: eine geplante Übertragung, stündlich oder täglich, in UTC. `Force Sync` startet sofort eine. - Eine Übertragung läuft auch sofort, wenn ein Benutzer der Anwendung von Hand oder durch eine Regel zugewiesen oder aus ihr entfernt wird. ### Was eine Übertragung mit Benutzern macht Eine neue Zuweisung wird im Ziel gesucht und dann mit `POST /Users` angelegt oder mit `PUT /Users/{id}` aktualisiert. Eine Zuweisung, die **inaktiv wird, wird** mit `DELETE /Users/{id}` **gelöscht**. Monosign sendet nie `active = false`, und wenn die Zuweisung wieder aktiviert wird, legt das Ziel ein neues Konto mit einer **neuen SCIM-ID** an. Bewahrt die Anwendung die Historie eines Benutzers nur auf, solange das Konto existiert, dann klären Sie mit dem Anwendungsverantwortlichen, wie diese Historie exportiert wird, bevor sich die Zuweisung eines ausscheidenden Mitarbeiters ändert. ::diagram lc-scim-push-lifecycle Ein Benutzer, dessen Standardprofil keinen Vornamen enthält, wird ohne Meldung übersprungen. Prüfen Sie also das Profil, wenn im Ziel eine einzelne Person fehlt. ### Was eine Übertragung mit Gruppen macht Die zugeordneten `Groups` werden als SCIM-Gruppen übertragen. Danach **löscht die Übertragung jede Gruppe im Ziel, die nicht zu den zugeordneten Gruppen gehört**, auch Gruppen, die die Administratoren der Anwendung selbst angelegt haben. Eine Zielgruppe, deren `externalId` keine GUID ist, bricht den gesamten Gruppenschritt ab. Bevor Sie die Gruppenübertragung für eine Anwendung einschalten, die bereits Gruppen hat, listen Sie diese auf und entscheiden Sie, welche Monosign gehören sollen. ### Wenn etwas fehlschlägt SCIM-Übertragungen erscheinen nicht unter Reports → `Provisions`. Die einzige Spur ist das Service-Log: Suchen Sie nach einer Zeile wie `SCIM API returned error` mit Statuscode und Antworttext. Der nächste geplante Lauf versucht es erneut. ### Provision-Services und Benutzerdaten Manche Integrationen nutzen statt SCIM einen Provision-Service mit Regeln. Der `User Provisioning Service` prüft jeden Benutzer gegen diese Regeln. Einen Benutzer **ohne E-Mail-Adresse, einen inaktiven Benutzer oder einen Benutzer, dessen Status nicht `Enabled` ist, behandelt er so, als passe er zu keiner Regel**, und das führt zum Entzug der Bereitstellung. Füllen Sie nach einem Verzeichnisimport das E-Mail-Attribut, bevor solche Benutzer ausgewertet werden. > Tipp: Führen Sie die erste Übertragung gegen einen Testmandanten der Anwendung aus. Ein Löschen im Ziel lässt sich von Monosign aus nicht zurücknehmen. ::shot lc-provisions

Genehmigungen, Delegierung und Verantwortliche

Präventive Trigger und Zugriffsanfragen stellen Menschen in den Weg einer Zuweisung. Drei Dinge entscheiden, ob die richtige Person eine Anfrage rechtzeitig sieht. ### Wo eine wartende Zuweisung liegt Ein Trigger mit `Require approval` braucht einen `Approval workflow`, wenn Personen benachrichtigt werden sollen. Ist das Feld leer, landet die Anfrage in einer **manuellen Warteschlange**: Sie erscheint im Tab `Approvals` des Triggers, und niemand wird informiert. Zugriff wird erst nach `Approve` gewährt. Legen Sie entweder einen Workflow fest oder machen Sie die Durchsicht dieses Tabs zur festen Aufgabe einer Person. ### Wer einen Schritt bearbeiten kann Ein Workflow-Schritt kann Personen oder, mit `Group Approval`, Gruppen zugewiesen werden. Gruppenschritte werden bei jedem Lesen aus der **aktuellen Mitgliedschaft** aufgelöst. Wer der Gruppe hinzugefügt wird, kann sofort handeln. Wer aus ihr entfernt wird, verliert die Zeile sofort aus dem Tab `Active` seines `Approvals`-Eingangs, während Zeilen unter `History` bei demjenigen bleiben, der gehandelt hat. Jedes einzelne aktuelle Mitglied schließt den Schritt ab, und eine leere Gruppe lässt ihn warten. ### Delegierung Security → `Delegations` überträgt die Genehmigungen eines Benutzers für einen Zeitraum auf einen anderen: `Assign`, dann `User (from)`, `Delegated User (to)` sowie Start- und Enddatum. Die Zuweisungen des Vertreters werden **beim Anlegen eines Schritts** hinzugefügt. Eine später eingerichtete Delegierung hängt sich nicht an Schritte, die bereits warten. Geben Sie diese Schritte von Hand an einen anderen Genehmiger. Richten Sie Delegierungen vor einer geplanten Abwesenheit ein, nicht an deren erstem Tag. ::diagram lc-approval-routing ::shot lc-delegations ### Verantwortliche Viele Entscheidungen gehen an "den Verantwortlichen", also müssen Verantwortliche erfasst sein. Governance → `Owners` hält fest, wem eine Anwendung, ein Benutzer, eine Gruppe, eine Rolle, eine Berechtigung, eine Ressource oder ein KI-Agent gehört, als `Direct Manager` oder als `Governance Owner`. Gruppen, Rollen und Berechtigungen haben auf ihrer eigenen Seite zusätzlich einen Tab `Owners`. **Anwendungen nicht**: Weisen Sie einen Anwendungsverantwortlichen unter Governance → `Owners` oder über die Object-Owners-API (`v1.5/object-owners`) zu. Zertifizierungskampagnen wählen Prüfer aus diesen Zeilen, und Trigger benachrichtigen sie. Eine Kampagne liest nur den `Owner Type`, für den sie konfiguriert ist. Ein mit dem anderen Typ erfasster Verantwortlicher wird also nicht gewählt. > Tipp: Wenn eine Genehmigung verschwunden zu sein scheint, prüfen Sie drei Dinge in dieser Reihenfolge: die Mitgliedschaft der zugewiesenen Gruppe, ob ein anderes Mitglied bereits entschieden hat und ob der Flow abgebrochen wurde.

Zugriffspakete und Zertifizierungskampagnen

Lifecycle-Automatisierung gewährt, was Personen standardmäßig brauchen. Zugriffspakete decken ab, was sie anfragen, und Zertifizierungskampagnen bestätigen, dass ihr Zugriff noch richtig ist. ### Zugriffspakete Governance → `Access Packages` definiert Bündel, die Personen anfragen können: einen Titel, eine `Policy`, eine `Lifetime`, optional einen `Workflow` zur Genehmigung und Ressourcen aus einem Katalog. `Assigned Object(s)` listet auf, wer ein Paket besitzt. - **Das Entfernen einer Zuweisung** (v2026.10) entzieht die Berechtigungen, die ihre genehmigte Anfrage erzeugt hat. Zugriff, den der Benutzer aus einer anderen Quelle hat, etwa eine direkte Rollenzuweisung, bleibt. Ein abgelehnter Entzug wird protokolliert. - **Die Richtlinie ist gesperrt, solange sie verwendet wird.** Eine Richtliniendefinition, auf die ein Paket verweist, lässt sich weder deaktivieren noch entfernen. Lösen Sie sie zuerst von jedem Paket. Das Entfernen ist ein weiches Löschen, die Historie bleibt. ::shot lc-access-packages ### Zertifizierungskampagnen Governance → `Certifications` enthält Definitionen: was geprüft wird, wer prüft, wie oft und für wie viele Tage. Ein Dienst macht aus einer fälligen Definition eine Kampagne mit Elementen und Prüfern. - **Die Prüfer werden beim Start der Kampagne ermittelt**, aus dem `Reviewer Type`: benannte Benutzer, `User Manager`, eine Regel oder Verantwortliche. Ein späterer Wechsel des Vorgesetzten oder Verantwortlichen verschiebt die Elemente nicht. Ein Zertifizierungsmanager nutzt `Reassign` oder `Add Reviewer`. - **Es wird nichts eskaliert.** Die einzige Nachverfolgung sind Erinnerungsmails und manuelles Neuzuweisen. - **Das Enddatum entscheidet nicht.** Wenn die Definition Entscheidungen nicht vorab mit `Approve All` oder `Reject All` setzt, bleiben Elemente, die niemand geprüft hat, unentschieden, und die Kampagne wird lediglich als `Completed` markiert. Haken Sie während der Kampagne bei den Prüfern nach und melden Sie unentschiedene Elemente als offenen Befund. ::diagram lc-campaign-course ### Wie die Teile zusammenpassen | Bedarf | Werkzeug | | --- | --- | | Zugriff, den alle in einer Gruppe haben sollen | Automatisierungsregel | | Zugriff, den eine Person mit Genehmigung und Enddatum anfragt | Zugriffspaket | | Nachweis, dass Zugriff noch begründet ist | Zertifizierungskampagne | | Eine verantwortliche Person, die entscheidet | Governance → `Owners` | > Tipp: Prüfen Sie vor dem Start einer Kampagne, dass jedes Element einen Prüfer haben wird: Vorgesetzte in den Profilen eingetragen und Verantwortliche mit dem Typ erfasst, den die Kampagne liest.