Inhaltsverzeichnis
Das Wichtigste vorab
Was muss bei Entra ID für GxP-Anwendungen nachgewiesen werden?
Für Microsoft Entra ID ist der konkrete Beitrag zu Identität und Zugriff Ihrer GMP-relevanten Anwendungen abzugrenzen. Prüfen Sie genehmigte Rollen, Zuweisung und Entzug, wirksame Zugriffsrichtlinien sowie relevante Protokolle. Entscheidend ist das Zusammenspiel mit der Zielanwendung: Eine blockierte Neuanmeldung beendet nicht zwangsläufig jede bestehende Sitzung. Microsoft-Nachweise unterstützen die Bewertung, ersetzen aber keine Prüfung Ihrer Konfiguration und tatsächlichen Zugangswege.
- Identität, Anmeldung und fachliche Berechtigung sind unterschiedliche Nachweisfragen.
- Report-only zeigt mögliche Richtlinienwirkungen; es erzwingt die Kontrollen nicht.
- Benutzerkonten, technische Identitäten und Notfallzugänge benötigen passende eigene Kontrollen.
- Entra-Protokolle ersetzen weder den fachlichen Audit Trail noch ein begründetes Aufbewahrungskonzept.
1. Tenant, Lizenzen und verbundene Anwendungen abgrenzen
Microsoft Entra ID ist ein cloudbasierter Dienst für Identitäts- und Zugriffsverwaltung. Die Entra-Produktfamilie umfasst weitere Angebote, beispielsweise Domain Services, Governance und Workload ID. Diese sind nicht automatisch vollständig in jedem Tenant enthalten. Auch lokales Active Directory und Entra ID sind keine identischen Systeme. Dokumentieren Sie daher, wo Identitäten entstehen und welche Komponenten am Zugriff beteiligt sind.
Ein belastbarer Konfigurationsstand enthält Tenant, Lizenzumfang, Unternehmensanwendungen, Protokolle, Connectoren, Zuweisungen und relevante Richtlinien. Bei einem Cloud-Dienst genügt eine einzelne Versionsnummer nicht als Beschreibung aller wirksamen Einstellungen. Halten Sie den bewerteten Stand mit Datum und geeigneten Konfigurationsnachweisen fest; Vorschaufunktionen und zusätzliche Dienste werden gesondert eingeordnet.
Der regulatorische Rahmen dieses Artikels ist die Herstellung von Humanarzneimitteln. Annex 11 unterscheidet Infrastrukturqualifizierung von Anwendungsvalidierung. Für Entra geht es damit um geeignete Dienst- und Zugriffskontrollen sowie ihren nachgewiesenen Beitrag zum vorgesehenen Gebrauch der verbundenen Anwendungen. Daraus folgt weder eine pauschale GAMP-Kategorie noch eine Zertifizierung der gesamten Cloud. Andere Regelbereiche sind zusätzlich abzugrenzen.
2. Von der genehmigten Aufgabe bis zur erlaubten Aktion denken
Eine erfolgreiche Anmeldung beantwortet zunächst, ob der vorgesehene Anmeldeweg funktioniert. Sie zeigt noch nicht, ob der Mitarbeiter in der Anwendung nur die fachlich erlaubten Aktionen ausführen kann. Beschreiben Sie deshalb für jede relevante Rolle mindestens einen erlaubten und einen verbotenen Vorgang. Prüfen Sie die Zuweisung außerdem an einem Benutzer ohne diese Rolle.
Die folgende Matrix ist eine eigene Arbeitshilfe für die Abstimmung zwischen QA, IT und dem Verantwortlichen der Fachanwendung. Nutzen Sie stabile Zuordnungen und dokumentieren Sie, wer Änderungen genehmigt. Ein verständlicher Gruppenname ist hilfreich, ersetzt aber keine Prüfung seiner Mitglieder, Weitergabe und tatsächlichen Wirkung.
| Ebene | Nachweisfrage | Beispiel für die Prüfung |
|---|---|---|
| Fachliche Genehmigung | Welche Aufgabe ist dieser Person zugewiesen? | Genehmigung passt zu Standort, Prozess und Vertretung |
| Entra-Zuweisung | Wird die richtige Identität der Anwendung zugeordnet? | Direkte Mitgliedschaft, Ausschluss und falsche Identität prüfen |
| Provisioning oder Rollenmapping | Kommt die vorgesehene Rolle im Ziel an? | Zielkonto und konkrete Rechte nach Änderung vergleichen |
| Conditional Access | Greift die vorgesehene Anmeldebedingung tatsächlich? | Zulässigen und unzulässigen Zugang bei aktivierter Regel testen |
| Anwendungssitzung | Welche Aktionen bleiben nach einem Entzug möglich? | Bestehende Sitzung und Neuanmeldung getrennt versuchen |
| Nachweisführung | Kann die Entscheidung später rekonstruiert werden? | Genehmigung, Änderung, Zielwirkung und relevante Logs verbinden |
3. Zuweisung und Provisioning nicht mit derselben Handlung verwechseln
Automatische Bereitstellung kann Benutzer in geeigneten Zielanwendungen anlegen, verändern und deaktivieren. Die Microsoft-Dokumentation beschreibt dafür unter anderem SCIM sowie anwendungsspezifische Connectoren. Das tatsächliche Verhalten hängt jedoch von Scope, Zuordnungsattributen, erlaubten Aktionen und der Zielanwendung ab. Eine vorhandene Single-Sign-on-Verbindung belegt nicht, dass auch Berechtigungsänderungen automatisch übertragen werden.
Prüfen Sie beim Eintritt, Wechsel und Austritt dieselbe Person über die gesamte Kette. Ein Rollenwechsel soll die neue Aufgabe ermöglichen und alte Rechte entsprechend Ihrer Vorgabe entfernen. Bei Namensänderungen oder erneut eingestellten Mitarbeitern ist zu klären, welches Zielkonto zugeordnet wird. Als eigener Negativfall eignet sich eine absichtlich widersprüchliche Zuordnung, die sicher erkannt werden muss.
Beachten Sie die dokumentierte Grenze verschachtelter Gruppen in der beschriebenen gruppenbasierten Anwendungsbereitstellung: Die unmittelbare Mitgliedschaft ist maßgeblich, nicht beliebige Untergruppen. Prüfen Sie außerdem deaktivierte Connector-Aktionen. Ein erfolgreicher Verbindungscheck sagt noch nichts darüber, ob eine Deaktivierung fachlich wirksam umgesetzt wird. Für Anwendungen ohne passende Automatik braucht der Prozess einen nachvollziehbaren manuellen Abschluss.
4. Conditional Access zuerst auswerten, dann wirksam prüfen
Conditional Access verbindet Bedingungen mit Zugriffsentscheidungen. Laut Microsoft erfordert die Grundfunktion P1; risikobasierte Richtlinien benötigen passende P2-/Identity-Protection-Funktionen. Prüfen Sie zusätzliche Lizenz- und Dienstabhängigkeiten für Ihren tatsächlichen Entwurf. Eine vorhandene Lizenz beweist weder die richtige Zielgruppe noch eine aktivierte Richtlinie.
Report-only wertet Richtlinien aus, erzwingt ihre Zugriffs- und Sitzungskontrollen aber nicht. Ein dort angezeigter Misserfolg kann deshalb gerade nicht als beobachtete Zugriffssperre gelten. Auch ist der Modus nicht unter allen Bedingungen ohne Nutzerauswirkung: Microsoft beschreibt beispielsweise mögliche Gerätezertifikatsabfragen. Planen Sie die Erprobung daher kontrolliert und mit passenden Testidentitäten.
Für einen belastbaren Übergang dokumentieren Sie den geprüften Richtlinienstand, betroffene Ressourcen, Ein- und Ausschlüsse sowie das Zusammenspiel mit weiteren Regeln. Danach wird im vorgesehenen aktiven Zustand geprüft, ob erlaubter Zugriff funktioniert und unzulässiger tatsächlich scheitert. Ein einzelnes grünes Ergebnis einer Regel sagt noch nicht, dass die gesamte Anmeldung erlaubt wird. Ebenso wenig belegt es fachliche Schreib- oder Freigaberechte in der Anwendung.
5. Technische Identitäten und Notfallzugänge separat behandeln
Ein Schnittstellendienst arbeitet nicht zwangsläufig mit dem Benutzerkonto seines Entwicklers. Microsoft beschreibt für bestimmte Service Principals eigene Conditional-Access-Regeln und Lizenzvoraussetzungen. Eine Benutzerregel für eine Gruppe schützt einen enthaltenen Service Principal nicht automatisch. Der dokumentierte Workload-Scope hat zudem Grenzen, etwa für Managed Identities und bestimmte Mehrmandantenanwendungen.
Erstellen Sie deshalb ein Verzeichnis der tatsächlich verwendeten technischen Zugänge mit Zweck, Ressourcenrechten, verantwortlichem Eigentümer und Änderungspfad. Beim Austritt eines Mitarbeiters kann eine fachlich weiterhin benötigte Verbindung bestehen bleiben. Entscheidend ist, dass Eigentum, Geheimnisse und Berechtigungen kontrolliert sind und kein persönlicher Restzugang versteckt bleibt. Legen Sie für jeden Zugangsweg einen passenden Entzugstest fest.
Notfalladministration löst ein anderes Problem: Der Betrieb muss bei Ausfall normaler Anmeldewege handlungsfähig bleiben. Microsoft beschreibt geschützte, überwachte Notfallkonten und regelmäßige praktische Prüfung. Für Ihren Prozess gehören die berechtigten Nutzer, der Anlass, erreichbare Zugangsmittel und die anschließende Bewertung zusammen. Daraus entsteht kein Freibrief, fachliche Daten ohne Genehmigung zu ändern oder ein Notfallkonto im Alltag zu verwenden.
6. Illustrativer Entzugstest: Neue Anmeldung gesperrt, alte Sitzung aktiv
Dieser selbst konstruierte Fall ist kein Test eines echten Tenants oder Produkts. Benutzer U-17 besitzt in QMS-A drei Rechte: lesen, bearbeiten und genehmigen. In Labor-B besitzt er lesen, erfassen und bestätigen. Beide Anwendungen haben vor 09:00 Uhr eine aktive Sitzung. Eine technische Verbindung T-4 arbeitet mit eigener Identität und wird getrennt verantwortet.
Als ausschließlich beispielhafte Anforderung setzt das Unternehmen fest: Spätestens zehn Minuten nach dem um 09:00 Uhr genehmigten Entzug darf U-17 keine dieser sechs Aktionen mehr ausführen. Das ist keine Microsoft-Zusage und keine allgemeine GMP-Frist. Alle Uhren sind im Beispiel abgeglichen. Die Tests verändern nur dafür bestimmte Testdaten.
In diesem konstruierten Befund ist QMS-A beim Versuch um 09:03 Uhr gesperrt. Labor-B erlaubt die Aktionen noch um 09:10 Uhr; erst nach zusätzlicher anwendungsseitiger Maßnahme scheitern sie um 09:11 Uhr. Damit ist die Beispielanforderung verletzt. Der erste erfolgreiche Sperrtest allein verrät nicht sekundengenau, wann die Sperre wirksam wurde.
| Zeit und Prüfung | Konstruierter Befund | Bewertung im definierten Soll | Benötigter Beleg |
|---|---|---|---|
| 08:59 – Ausgangslage | QMS-A: 3; Labor-B: 3 persönliche Aktionen möglich | 6 von 6 Ausgangsaktionen bestätigt | Rollen, Testbenutzer und kontrollierte Sitzungen |
| 09:00 – Entzug auslösen | Entra-Konto gesperrt; weitere Entzugsschritte gestartet | Auslöser, noch kein Gesamtergebnis | Genehmigung und tatsächlich ausgeführte Maßnahmen |
| 09:01 – Neuanmeldung | Neue Anmeldung scheitert | Dieser Zugangsweg gesperrt; alte Sitzungen noch offen | Anmeldeversuch und korrelierbarer Protokolleintrag |
| 09:03 – Bestehende Sitzung QMS-A | Alle 3 Aktionen scheitern | 0 von 3 hier; erste bestätigte Sperre nach 3 Minuten | Appversuche mit Zeit und passenden Nachweisen |
| 09:10 – Bestehende Sitzung Labor-B | Alle 3 Aktionen weiterhin möglich | Beispielgrenze 10 Minuten nicht erfüllt | Offener Befund, mögliche Folgen und Eindämmung |
| 09:11 – Nachtest nach Appmaßnahme | Auch in Labor-B scheitern alle 3 Aktionen | 0 von 6 möglich; erste bestätigte Gesamtsperre nach 11 Minuten | Maßnahme, Nachtest und begründete Abschlussentscheidung |
| Separater Test T-4 | Verbindung bleibt für genehmigten Prozess nutzbar | Kein Beleg persönlicher Rechte; Eigentum separat prüfen | Technische Identität, Zweck und zuständiger Eigentümer |
7. Protokolle nach Aussage und Aufbewahrung unterscheiden
Ein Anmeldeprotokoll beantwortet andere Fragen als die Änderung einer fachlichen Freigabe. Ermitteln Sie, welche Ereignisse Entra, der Provisioning-Dienst und die Zielanwendung liefern. Für die Untersuchung eines Rollenentzugs können Genehmigung, Identitätsänderung und fehlgeschlagener Appzugriff gemeinsam wichtig sein. Ein einzelner Screenshot der Benutzerübersicht zeigt diese Kette nicht.
Die Microsoft-Tabelle nennt für Audit- und Anmeldeprotokolle standardmäßig sieben Tage in Free und 30 Tage in P1/P2. Das sind produktbezogene Aufbewahrungswerte, keine GMP-Fristen. Entra-Protokolle sind zudem vom Microsoft-365-Unified-Audit-Log zu unterscheiden. Eine Lizenzanhebung stellt bereits abgelaufene Daten nicht nachträglich wieder her, sofern sie nicht anderweitig gesichert wurden.
Leiten Sie Ihren Bedarf von den relevanten Nachweisfragen ab und richten Sie die erforderliche längere Speicherung rechtzeitig ein. Prüfen Sie anschließend mit einem bekannten Ereignis den Eingang, die Zuordnung und den späteren Abruf am vorgesehenen Speicherort. Berücksichtigen Sie Datenschutz und Zugriffsrechte. Weder eine aktivierte Exportoption noch eine große Speichermenge belegt allein Vollständigkeit und Verwendbarkeit der benötigten Nachweise.
8. Dienstnachweise mit der eigenen Konfiguration verbinden
Beginnen Sie mit einer Systembeschreibung, die Identitätsquelle, Anmeldewege, Zielanwendungen und Verantwortlichkeiten sichtbar macht. Verbinden Sie daran genehmigte Rollen, Konfigurationsstände und risikobezogene Prüffälle. Die Infrastrukturkontrollen des Dienstes und die fachlichen Tests einer Anwendung müssen dabei zusammenpassen; sie müssen nicht in künstlich getrennten Akten liegen.
Bewerten Sie nutzbare Microsoft- und Implementierungspartnerunterlagen hinsichtlich Gegenstand, Zeitraum, Dienst und tatsächlicher Abdeckung. Ein Bericht über allgemeine Sicherheitskontrollen beantwortet nicht automatisch Ihre Frage nach einem bestimmten Connector-Mapping. Umgekehrt müssen geeignete Nachweise nicht ohne Grund neu erstellt werden. Halten Sie fest, welche Aussagen Sie übernehmen und welche kundenbezogenen Punkte offen bleiben.
Für den Abschluss zählt, ob die vorgesehenen Kontrollen ausreichend nachgewiesen und Abweichungen verantwortet behandelt sind. Ein negativer Testbefund wird nicht durch Umbenennen der Rolle beseitigt. Beschreiben Sie Ursache, mögliche Folgen, Maßnahme und erforderlichen Nachtest. Historische Zuordnungen sollten für die Bewertung früherer Handlungen erhalten bleiben, auch wenn der aktuelle Zugriff entzogen wurde.
9. Änderungen und KMU-Mitwirkung praktisch organisieren
QA muss nicht jede Identitätsfunktion administrieren. Sie muss mit dem Prozessverantwortlichen klären, welche Aufgaben geschützt werden und welches Restrisiko eine Verzögerung oder Fehlzuordnung hat. IT beschreibt die technischen Wege; der Anwendungsverantwortliche bestätigt Rollen und Sitzungsverhalten. Personalprozesse liefern verlässliche Auslöser für Eintritt, Wechsel und Austritt. Ohne diese Zusammenarbeit bleibt die technische Sperre leicht ohne fachlichen Abschluss.
Der Aufwand hängt von der Zahl und Unterschiedlichkeit der Zugangswege ab: Cloud und lokale Identitäten, lokale Appkonten, Gastzugänge, Connectoren, technische Konten und Ausnahmen. Ein kleines Unternehmen kann wenige Systeme, aber mehrere kritische Sonderwege haben. Priorisieren Sie nach Wirkung auf den Prozess, statt nur die Benutzerzahl als Maß zu verwenden.
Bei geänderten Gruppenregeln, Authentifizierungsverfahren oder Appversionen bewerten Sie die Auswirkungen auf bestehende Nachweise. Ein unveränderter Connector kann betroffen sein, wenn sich sein Zielverhalten ändert. Planen Sie passende Regression und Betriebsbeobachtung, einschließlich kontrollierter Rücknahme. Die wiederkehrende Bewertung nutzt Vorfälle, offene Ausnahmen und veränderte Dienstfunktionen; eine allgemeine jährliche Testpflicht wird hier nicht behauptet.
10. Checkliste für wirksamen und belegbaren Zugriff
Die folgende Checkliste verbindet Entscheidungen und technische Wirkung. Nutzen Sie sie vor Einführung oder einer wesentlichen Änderung; dokumentieren Sie für jeden relevanten Punkt die konkrete Antwort und den dazugehörigen Nachweis. Nicht zutreffende Punkte werden begründet abgegrenzt.
- Tenant, Identitätsquelle, Lizenzen, Anwendungen und tatsächliche Anmeldewege sind beschrieben.
- Genehmigte Aufgaben sind auf überprüfbare Anwendungsrechte und verantwortliche Eigentümer abgebildet.
- Eintritt, Rollenwechsel und Austritt berücksichtigen Zielkonten, Matching und zulässige Connector-Aktionen.
- Conditional Access wurde mit Ein-/Ausschlüssen im tatsächlich erzwungenen Zustand geprüft.
- Bestehende Sitzungen, direkte Appzugänge und neue Anmeldungen wurden getrennt betrachtet.
- Technische Identitäten und Notfallzugänge haben passende Kontrollen und nachvollziehbare Verantwortlichkeiten.
- Relevante Protokolle werden in der benötigten Dauer verfügbar gehalten und praktisch wiedergefunden.
- Änderungen, Ausnahmen, Vorfälle und Nachtests fließen in die Bewertung des laufenden Betriebs ein.
Häufige Fragen zu Microsoft Entra ID
Muss Entra ID selbst validiert oder qualifiziert werden?
Beschreiben Sie zuerst seine Rolle in Ihrer Systemlandschaft. Infrastruktur- und Dienstkontrollen sind mit dem validierten Gebrauch der GMP-Anwendungen zu verbinden. Entscheidend sind passende Anforderungen und Nachweise, nicht das pauschale Etikett für ein ganzes Cloudangebot. Prüfen Sie insbesondere Konfiguration und Integration dort, wo Identität oder Zugriff eine relevante Prozessentscheidung beeinflussen. Eine universelle Produktkategorie lässt sich daraus nicht ableiten.
Belegt Single Sign-on auch die richtige Rolle in der Anwendung?
Nein. Eine Anmeldung und eine fachliche Berechtigung sind unterschiedliche Funktionen. Die Rolle kann aus übertragenen Attributen stammen oder in der Anwendung selbst verwaltet werden. Prüfen Sie für eine genehmigte Testperson erlaubte und verbotene Aktionen sowie einen Gegenfall ohne Zuweisung. Dokumentieren Sie, welche Stelle die Rolle tatsächlich vergibt und wie Änderungen bis zur wirksamen Aktion gelangen.
Warum kann ein gesperrter Benutzer noch in einer Anwendung arbeiten?
Die Anwendung kann eine eigene Sitzung verwalten. Microsoft erläutert, dass Entra ein von der Anwendung ausgegebenes Sitzungstoken nicht direkt widerrufen kann. Die tatsächliche Wirkung hängt daher auch von Appverhalten und Entzugsverfahren ab. Testen Sie eine schon geöffnete Sitzung getrennt von der Neuanmeldung und legen Sie passende zusätzliche Maßnahmen fest. Eine allgemeine sofortige Sperrwirkung sollten Sie nicht unterstellen.
Quellen: [4]
Ist ein Report-only-Ergebnis bereits ein bestandener Sperrtest?
Es ist ein Auswertungsbeleg zur möglichen Richtlinienwirkung. Weil Report-only die betreffenden Kontrollen nicht erzwingt, belegt es keine tatsächlich verhinderte Aktion. Verwenden Sie es zur Vorbereitung und prüfen Sie anschließend kontrolliert den vorgesehenen aktiven Zustand. Berücksichtigen Sie dabei andere gleichzeitig wirksame Regeln, Ausnahmen und Ressourcen. Auch mögliche Nutzerauswirkungen der Erprobung müssen vorab betrachtet werden.
Quellen: [3]
Brauchen wir für jede Zielanwendung automatische Bereitstellung?
Nicht zwangsläufig. Entscheidend ist ein verlässlicher, nachgewiesener Ablauf für Anlage, Änderung und Entzug. Automatik hängt von der Unterstützung der Anwendung und Ihrer Konfiguration ab. Bei einem manuellen Verfahren brauchen Sie klare Verantwortung, Auslöser und Abschlussnachweis. Prüfen Sie auch dann die tatsächliche Wirkung im Ziel. Eine automatische Übertragung ohne richtiges Mapping ist nicht verlässlicher als ein geeigneter kontrollierter manueller Prozess.
Gilt unsere MFA-Regel auch für die technische Laborschnittstelle?
Das können Sie aus einer Benutzerrichtlinie nicht ableiten. Ermitteln Sie zuerst, ob die Verbindung ein Benutzerkonto, einen Service Principal oder eine andere technische Identität nutzt. Microsoft dokumentiert für Workload-Identitäten eigene Voraussetzungen und Abdeckungsgrenzen. Bewerten Sie den konkreten Zugangsweg, seine Rechte und Schutzmaßnahmen. Eine interaktive MFA-Anforderung ist kein sinnvoller pauschaler Nachweis für jeden automatisierten Dienst.
Quellen: [7]
Wie werden Notfallkonten im GMP-Umfeld behandelt?
Planen Sie ihren technischen Zweck und den kontrollierten Gebrauch. Der Notfallzugang soll bei Ausfall normaler Administrationswege erreichbar sein, zugleich aber geschützt, überwacht und nachvollziehbar verwendet werden. Prüfen Sie den vorgesehenen Fall praktisch und bewerten Sie die anschließenden Handlungen. Eine technische Ausnahme von einer Anmelderegel erteilt keine fachliche Genehmigung für beliebige Datenänderungen in einem Qualitätssystem.
Sind 30 Tage Entra-Protokolle für GMP ausreichend?
Die Produktaufbewahrung ist keine fachliche Festlegung Ihres Nachweisbedarfs. Bestimmen Sie, welche Ereignisse Sie für den relevanten Prozess wie lange benötigen und welche Belege gegebenenfalls anderswo liegen. Falls die Standarddauer nicht reicht, muss eine geeignete Speicherung rechtzeitig greifen. Prüfen Sie ihren tatsächlichen Inhalt und Abruf. Ein späteres Lizenzupgrade kann bereits verfallene, nicht anderweitig gesicherte Einträge nicht zurückbringen.
Welche Unterlagen braucht ein KMU vor dem ersten Test?
Hilfreich sind eine aktuelle Anwendungsliste, die genehmigten Rollen, reale Anmeldewege und Verantwortlichkeiten für Identitäten und Zielsysteme. Ergänzen Sie bekannte Ausnahmen, technische Konten und den aktuellen Richtlinienstand. Legen Sie danach Sollentscheidungen und geeignete Testidentitäten fest. Der häufig entscheidende Vorbereitungsbeitrag ist die Klärung, wer welche fachliche Aktion wirklich ausführen darf und wie der Entzug bestätigt wird.
Quellen: [10]
Müssen bei jeder Cloudänderung alle Zugriffstests wiederholt werden?
Der erforderliche Umfang folgt aus der Auswirkungsbewertung. Eine Änderung kann geänderte und bisher unveränderte Funktionen betreffen, etwa wenn ein Appupdate das Sitzungsverhalten beeinflusst. Nutzen Sie weiterhin tragfähige Nachweise und ergänzen Sie gezielt die betroffenen Prüfungen. Halten Sie den betrachteten Stand, offene Unsicherheiten und die Entscheidung fest. Weder ein automatischer Vollretest noch grundsätzlicher Testverzicht ist daraus abzuleiten.
Quellen & fachlicher Stand
Quellenstand: 6. Oktober 2026. Produktangaben beziehen sich auf die benannten Microsoft-Learn-Unterlagen und deren Voraussetzungen. Die tatsächliche Tenant-Konfiguration und Zielanwendung sind gesondert zu prüfen. Regulatorischer Bezug: der erläuterte Humanarzneimittel-GMP-Einsatz. Zahlen und Zeitfall sind eigene illustrative Annahmen.
- What is Microsoft Entra?
- What is Conditional Access?
- Analyze Conditional Access Policy Impact
- Revoke user access in Microsoft Entra ID
- How Application Provisioning works in Microsoft Entra ID
- Microsoft Entra data retention
- Conditional Access for workload identities
- Manage emergency access accounts in Microsoft Entra ID
- EudraLex Volume4 – Humanarzneimittel-GMP
- EU-GMP Annex11: Computerised Systems
- EU-GMP Chapter4: Documentation
Zuletzt fachlich geprüft am 06.10.2026.
Daniel Herrmann Consulting
Zugriffskontrollen mit dem GxP-Prozess verbinden
Wir helfen Ihnen, Entra-Konfiguration, fachliche Rollen und tatsächliche Anwendungswirkung gemeinsam zu bewerten und passende Nachweise für Ihren Betrieb aufzubauen.
- IT-GxP-Audit →
Lücken zwischen Identitätsverwaltung, Anwendungsrechten und vorhandenen Nachweisen erkennen.
- IT-GxP-Consulting →
Zugriffsanforderungen, aussagekräftige Prüffälle und kontrollierte Betriebsverfahren erarbeiten.