Thema 4.2 — Identitäts- und Zugriffsmanagement

In Gesundheit und Pflege ist die Kontrolle darüber, wer mit der Akte einer Patientin was sehen und tun darf, keine IT-Haushaltsaufgabe, sondern ein Faktor an vorderster Front für klinische Sicherheit, Vertraulichkeit und öffentliches Vertrauen.

Warum das in Gesundheit und Pflege wichtig ist#

Jede klinische Entscheidung ruht auf der Annahme, dass die Akte vor einer Klinikerin die richtige Akte ist, der richtigen Patientin gehört und von der richtigen Person erreicht wurde. Identitäts- und Zugriffsmanagement (Identity and Access Management, IAM) ist die Maschinerie, die diese drei Annahmen wahr macht. Wenn es funktioniert, sieht ein Rettungssanitäter eine Allergie rechtzeitig, erreicht ein Schutzvermerk nur jene, die ihn brauchen, und eine Prüfspur kann die Frage beantworten „wer hat diese Akte angesehen und warum?“. Wenn es versagt, werden Patientinnen und Patienten durch unter dem falschen Namen geöffnete Akten geschädigt, schnüffelt Personal bei Verwandten oder Prominenten, und das Vertrauen in das gesamte digitale Vorhaben erodiert.

Gesundheit und Pflege heben den Einsatz auf drei Weisen über den gewöhnlichen Unternehmensfall. Erstens gehören die Daten zu den sensibelsten, die ein Mensch je erzeugen wird – psychische Gesundheit, sexuelle Gesundheit, Substanzkonsum, Geschlechtsidentität, Schutzbedenken –, sodass eine Verletzung der Vertraulichkeit keine Unannehmlichkeit, sondern ein bleibender Schaden ist. Zweitens ist die Belegschaft mobil, rotierend und organisationsübergreifend: Junge Ärztinnen und Ärzte rotieren alle paar Monate, Zeitarbeits- und Vertretungskräfte kommen für eine einzige Schicht, und integrierte Versorgung bedeutet, dass eine Gemeindekrankenschwester legitim eine Krankenhausakte brauchen kann. Drittens verzeiht die Sorgfaltspflicht keine Reibung: Eine Zugriffskontrolle, die um 3 Uhr morgens in der Reanimation zu langsam ist, ist selbst eine Sicherheitsgefahr. IAM ist in diesem Sektor daher ein ständiges Aushandeln zwischen dem Abriegeln von Daten und dem schnellen Hineinlassen der richtigen Person.

Dieses Thema behandelt die Tiefe der Zugriffskontrolle, die unter den breiteren Pflichten aus Thema 1.7 — Informationsgovernance, Datenschutz und Cybersicherheit liegt. Wo jenes Thema den rechtlichen und organisatorischen Rahmen setzt – die UK General Data Protection Regulation, das Data Security and Protection Toolkit, die Vertraulichkeitspflicht –, handelt dieses von der konkreten Mechanik, Identität zu beweisen und den geringsten zur Arbeit nötigen Zugriff zu gewähren.

Kernkonzepte#

Identitäts- und Zugriffsmanagement ist die Disziplin und die Menge an Technologien, die sicherstellen, dass die richtigen Personen zur richtigen Zeit den richtigen Zugriff auf die richtigen Ressourcen haben und dass sich dies hinterher beweisen lässt. Es ruht auf einer Unterscheidung, die leicht zu verwischen und gefährlich zu verlieren ist: dem Unterschied zwischen Authentifizierung und Autorisierung.

Authentifizierung beantwortet „sind Sie, wer Sie zu sein behaupten?“. Sie wird durch Faktoren bewiesen: etwas, das man weiß (ein Passwort oder eine PIN), etwas, das man hat (eine Smartcard, ein Telefon, ein Hardware-Token), und etwas, das man ist (ein Fingerabdruck oder ein Gesicht). Autorisierung beantwortet eine andere Frage – „jetzt, da wir wissen, wer Sie sind, was dürfen Sie sehen und tun?“. Ein Oberarzt und eine Empfangskraft können sich beide einwandfrei authentifizieren, sind aber für sehr unterschiedliche Teile einer Akte autorisiert. Beides zu verwechseln führt zu Systemen, die Identität stark prüfen und dann jeden alles sehen lassen.

Autorisierung wird in Gesundheit und Pflege meist als rollenbasierte Zugriffskontrolle (Role-Based Access Control, RBAC) organisiert, bei der Berechtigungen an Rollen hängen – „Pflegekraft der Notaufnahme“, „Hausärztin“, „medizinische Sekretärin“ – und Menschen Berechtigungen erben, indem sie eine Rolle innehaben, statt dass Rechte einzeln vergeben werden. RBAC wird vom Prinzip der geringsten Rechte (Least Privilege) bestimmt: Jede Person und jedes Systemkonto sollte den minimalen zur Arbeit nötigen Zugriff halten und nicht mehr. Geringste Rechte begrenzen sowohl versehentliche Fehler als auch den Wirkungsradius eines kompromittierten Kontos.

Moderne Authentifizierung stärkt den Schritt „beweisen Sie, wer Sie sind“ durch Multi-Faktor-Authentifizierung (MFA), die zwei oder mehr Faktoren kombiniert, sodass ein gestohlenes Passwort allein nicht genügt. Sie verringert Reibung durch Single Sign-on (SSO), bei dem eine authentifizierte Sitzung Zugriff auf viele Anwendungen ohne wiederholte Anmeldungen gewährt – ein echter Sicherheitsnutzen, wenn eine Klinikerin in einer Stunde zwischen einem Dutzend Systemen wechseln muss. SSO über Organisationsgrenzen beruht auf föderierter Identität: Eine Organisation bürgt für einen Nutzenden, damit eine andere ihm vertrauen kann, ohne seine Zugangsdaten zu halten.

Die Infrastruktur von Föderation und moderner Authentifizierung ist auf offenen Standards gebaut. OAuth ist ein Standard für delegierte Autorisierung – eine Anwendung in Ihrem Namen handeln zu lassen, ohne Ihr Passwort herauszugeben. OpenID Connect legt Authentifizierung auf OAuth, sodass eine Anwendung erfahren kann, wer der Nutzende ist, und die ältere, XML-basierte Security Assertion Markup Language (SAML) leistet Ähnliches für Unternehmens-SSO. Der Lebenszyklus einer Identität – das Gewähren, Ändern und Entziehen von Zugriff, wenn Menschen eintreten, wechseln und gehen – wird durch Provisionierungs-Prozesse behandelt, gemeinhin Joiners/Movers/Leavers oder JML genannt.

Die strategische Entwicklungsrichtung ist die Zero-Trust-Architektur: die Annahme, dass kein Nutzender und kein Gerät schon deshalb vertrauenswürdig ist, weil es im Netzwerk sitzt. Jede Anfrage wird authentifiziert, autorisiert und gegen den Kontext geprüft – Gerätezustand, Ort, Sensibilität der Daten –, statt sich auf einen gehärteten Perimeter zu verlassen. In einem Sektor, in dem Personal aus Kliniken, Wohnungen, Rettungswagen und Partnerstandorten arbeitet, hat sich der Perimeter faktisch aufgelöst, und Zero Trust benennt die ehrliche Antwort darauf.

Bewährte Praktiken#

1. Behandeln Sie Authentifizierung und Autorisierung als getrennte Designentscheidungen. Entscheiden Sie zuerst, wie stark Sie für ein gegebenes System Identität beweisen müssen, und getrennt davon, wie fein Sie kontrollieren müssen, was jede Rolle dann tun kann. Eine starke Anmeldung an einem System, das allen vollen Zugriff gibt, ist ein falscher Trost, und feinkörnige Berechtigungen hinter einem schwachen Passwort sind ebenso hohl. Dokumentieren Sie beide Entscheidungen für jedes klinische System ausdrücklich und überprüfen Sie sie, wenn sich Datensensibilität oder Nutzerpopulation ändern.

2. Lassen Sie die rollenbasierte Zugriffskontrolle reale klinische Rollen spiegeln und halten Sie sie dann sauber. Gestalten Sie Rollen danach, wie Versorgung tatsächlich erbracht wird – nicht nach dem Organigramm oder den Launen der Standardkonfiguration eines Lieferanten – und bilden Sie jede Rolle auf die minimalen Akten und Funktionen ab, die sie braucht. Mit der Zeit verfällt RBAC zu einer „Rollenexplosion“, bei der sich Hunderte überlappender Rollen ansammeln und niemand sagen kann, was eine davon gewährt. Planen Sie periodische Rollenrationalisierung und widerstehen Sie der Versuchung, jede Zugriffsanfrage durch das Prägen einer neuen Maßanfertigungsrolle zu lösen.

3. Wenden Sie geringste Rechte auf Menschen und Maschinenkonten gleichermaßen an. Geringste Rechte werden routinemäßig auf Klinikpersonal angewandt und dann für die Servicekonten, Integrations-Engines und Berichtswerkzeuge vergessen, die oft den weitesten Zugriff von allen halten. Eine automatisierte Schnittstelle, die Daten für ein Dashboard zieht, braucht selten Schreibzugriff oder identifizierbaren Freitext, bekommt ihn aber häufig. Inventarisieren Sie nichtmenschliche Identitäten, schränken Sie sie ein und rotieren Sie ihre Zugangsdaten planmäßig.

4. Verlangen Sie Multi-Faktor-Authentifizierung für Fern- und privilegierten Zugriff und wählen Sie Faktoren, die zum Umfeld passen. Passwörter allein sind für alles, was Patientendaten von außerhalb eines vertrauenswürdigen Geräts erreicht, nicht mehr vertretbar, und MFA ist inzwischen eine Grunderwartung über NHS-Systeme. Wählen Sie Faktoren, die das klinische Umfeld überstehen: phishing-resistente Hardware-Token oder Plattform-Authenticatoren für privilegierten und Fernzugriff, und seien Sie vorsichtig mit SMS-Codes auf Stationen, wo der Empfang schlecht ist und Telefone geteilt werden. Wägen Sie den Sicherheitsgewinn gegen die Realität ab, dass eine Klinikerin mitten in einer Reanimation nicht nach einem zweiten Faktor tasten kann.

5. Nutzen Sie Single Sign-on, um Reibung zu beseitigen, die das Personal zu unsicheren Umgehungen drängt. Wenn Personal sich an zehn Systemen einzeln anmelden muss, schreibt es Passwörter auf Haftnotizen, teilt Smartcards und lässt Sitzungen offen – jedes ein Sicherheits- und Vertraulichkeitsrisiko. Gut umgesetztes SSO, idealerweise kombiniert mit „Tap in, Tap out“-Näherungsausweisen an gemeinsamen klinischen Arbeitsplätzen, verbessert sowohl Sicherheit als auch gibt Klinikpersonal Zeit zurück. Behandeln Sie SSO als Patientensicherheitsintervention, nicht bloß als Bequemlichkeit, und messen Sie die Anmeldezeit, die Sie entfernen.

6. Modernisieren Sie die NHS-Identität über die Smartcard hinaus, ohne zu zerbrechen, was funktioniert. Der NHS Care Identity Service (früher der Care Identity Service und davor das auf Smartcards gebaute Registration-Authority-Regime) authentifiziert NHS-Personal und treibt den Zugriff auf nationale Systeme wie die Spine. Die nationale Richtung geht nun zu moderner, standardbasierter Authentifizierung – CIS2 mit MFA und OpenID Connect –, die die Abhängigkeit von physischen Smartcards und Kartenlesern verringert, die ausfallen, geteilt werden oder Versorgung blockieren. Planen Sie Ihre Migration bewusst: Behalten Sie die Absicherungs- und Registrierungsstrenge des Smartcard-Modells bei und übernehmen Sie die Flexibilität moderner Token.

7. Führen Sie Joiners/Movers/Leavers als kontrollierten, prüfbaren Prozess – besonders Leavers. Der häufigste ernste IAM-Fehler in Gesundheit und Pflege ist das Konto, das den Bedarf der Person überdauert: die rotierte junge Ärztin, die ausgeschiedene Zeitarbeits-Pflegekraft, der Auftragnehmer, dessen Zugriff nie entzogen wurde. Automatisieren Sie die Provisionierung aus einer maßgeblichen Quelle (meist der elektronischen Personalakte), sodass Beginn, Änderung und Ende einer Rolle die passende Zugriffsänderung binnen eines definierten, kurzen Fensters auslösen. Behandeln Sie den Entzug am selben Tag bei Ausscheidenden und bei Personal unter Untersuchung als harte Anforderung, nicht als Aspiration.

8. Rezertifizieren Sie Zugriff regelmäßig und machen Sie Führungskräfte dafür rechenschaftspflichtig. Zugriff, der am ersten Tag angemessen war, driftet, während Menschen Teams wechseln und Rechte ansammeln, die sie nicht mehr brauchen – „Privilege Creep“. Führen Sie periodische Zugriffsüberprüfungen (Rezertifizierung) durch, bei denen die verantwortliche Führungskraft oder der Systemverantwortliche aktiv bestätigt, dass jede Person jedes Recht noch braucht, wobei Schweigen zum Entzug statt zur Beibehaltung führt. Machen Sie die Überprüfung sinnvoll, indem Sie sie in verständlicher klinischer Rollensprache statt in rohen Berechtigungscodes darstellen, die keine Führungskraft deuten kann.

9. Steuern Sie privilegierten Zugriff als eigene Kategorie. Administratoren, Datenbankverantwortliche und Infrastrukturingenieure können jede Akte lesen oder ändern und genau die Kontrollen abschalten, die sie schützen; ihr Zugriff braucht daher stärkere Behandlung als der gewöhnlicher Nutzender. Setzen Sie Privileged Access Management um: Trennen Sie Admin-Identitäten von Alltagskonten, gewähren Sie erhöhte Rechte Just-in-Time und zeitlich begrenzt statt dauerhaft und zeichnen Sie privilegierte Sitzungen für unabhängige Überprüfung auf. Lassen Sie nie einen Lieferanten oder ein „Break-Glass“-Konto zu einem dauerhaften, unüberwachten Generalschlüssel werden.

10. Machen Sie jede Zugriffsentscheidung prüfbar und lesen Sie die Prüfspur tatsächlich. Zugriffskontrolle, die man hinterher nicht überprüfen kann, ist nur eine halbe Kontrolle; die Fähigkeit, „wer hat auf diese Akte zugegriffen, wann und auf welcher Grundlage?“ zu beantworten, stützt sowohl Vertraulichkeitsuntersuchungen als auch Patientensicherheit. Konfigurieren Sie umfassendes, manipulationssicheres Audit-Logging und – entscheidend – statten Sie proaktives Audit aus, einschließlich Alarmen bei Selbstabfragen, Abfragen von Kolleginnen oder VIPs und ungewöhnlichen Zugriffsvolumina. Eine Prüfspur, die niemand untersucht, schreckt niemanden ab.

11. Gestalten Sie Break-Glass-Zugriff so, dass Notfälle bedient und Missbrauch gefangen wird. Klinikpersonal braucht manchmal legitim eine Akte, die es nicht routinemäßig sehen darf – eine bewusstlose Patientin, ein organisationsübergreifender Notfall. Bieten Sie einen expliziten „Break-Glass“-Weg, der Notfallzugriff mit verlangtem Grund, sofortiger Markierung und verpflichtender nachträglicher Überprüfung gewährt, statt Personal zu zwingen, zwischen den Regeln und der Patientin zu wählen. Ziel ist, die sichere Notfallhandlung leicht und die ungerechtfertigte sichtbar zu machen.

12. Übernehmen Sie Zero Trust als Richtung und sequenzieren Sie es pragmatisch. Wechseln Sie von „vertrauenswürdiges Netzwerk, innen offen“ zur Prüfung jeder Anfrage gegen Identität, Gerätezustand und Kontext, sodass ein kompromittierter Laptop im Unternehmens-LAN nicht mehr automatisch vertraut wird. Das ist eine mehrjährige Reise über starke Identität, Gerätekonformität, bedingten Zugriff und Mikrosegmentierung – kein Produkt, das man kauft. Sequenzieren Sie es hinter die Grundlagen (MFA, geringste Rechte, saubere JML) und stimmen Sie es auf die Landschaftsarbeit in Thema 4.0 — Technische Architektur, Cloud und Altsysteme ab.

Fragen zur Diskussion im Team#

1. Wo tauschen wir bewusst Zugriffsreibung gegen klinische Sicherheit, und wer hat die Balance entschieden? Jede zusätzliche Anmeldung, jeder zweite Faktor und jeder Autorisierungsschritt schützt die Vertraulichkeit, kostet aber Sekunden, die in einem Notfall selbst ein Sicherheitsrisiko sind. Diese Frage zwingt das Team, die konkreten Stellen zu benennen, an denen Sicherheitskontrollen Versorgung verzögern könnten – die Reanimations-Anmeldung, der gemeinsame Stationsarbeitsplatz, das System außerhalb der Dienstzeiten – und zu fragen, ob die aktuelle Balance von Menschen gewählt wurde, die sowohl die klinischen als auch die Sicherheitsfolgen verstehen, oder per Voreinstellung eines Lieferanten entstand. Debattieren Sie die Spannung ehrlich: Eine zu enge Kontrolle treibt Haftnotiz-Passwörter und geteilte Smartcards, die schlimmer sind als das Risiko, das sie adressieren, während eine zu lockere Schnüffelei und Pannen einlädt. Achten Sie auf konkrete Signale einer schlechten Balance – Personal, das Zugangsdaten teilt, offen gelassene Sitzungen, routinemäßig genutztes Break-Glass. Eine gute Antwort benennt, wer jeden Zielkonflikt verantwortet, zeigt, dass Klinikpersonal im Raum war, als er gesetzt wurde, und verweist auf gemessene Anmeldezeiten und Umgehungsraten statt auf Annahmen. Sie verpflichtet sich auch, die Balance zu überprüfen, wenn sich Rollen, Systeme und Bedrohungen ändern.

2. Wie sicher sind wir, dass ein Ausscheidender oder Wechselnder jedes Mal den richtigen Zugriff im richtigen Zeitrahmen verliert? Das Konto, das seinen Bedarf überdauert, ist der klassische IAM-Fehler, und in einer rotierenden, organisationsübergreifenden Gesundheitsbelegschaft ist das Risiko akut. Diese Frage prüft, ob Joiners/Movers/Leavers ein verlässlicher, automatisierter, aus einer maßgeblichen Quelle getriebener Prozess ist oder eine Menge manueller E-Mails, die still scheitern, wenn jemand beschäftigt ist. Besprechen Sie die harten Fälle: die junge Ärztin, die zwischen Trusts rotiert, die Zeitarbeits-Pflegekraft für eine Schicht, der Auftragnehmer, das bis zur Untersuchung suspendierte Personalmitglied. Überlegen Sie, was „der richtige Zeitrahmen“ für jeden bedeutet – Entzug am selben Tag ist bei einer Suspendierung nicht verhandelbar, kann bei einem routinemäßigen internen Wechsel aber weicher sein. Eine gute Antwort kann auf Evidenz statt Absicht verweisen: die Ergebnisse des letzten Leaver-Audits, die Zahl gefundener und geschlossener ruhender Konten, die Zeit zwischen dem Ausscheiden einer Person und dem Ende ihres Zugriffs. Sie ist ehrlich zu den Lücken und benennt, wer für das Schließen rechenschaftspflichtig ist.

3. Wenn bei einer Akte etwas schiefgeht, können wir tatsächlich rekonstruieren, wer was getan hat – und würden wir Missbrauch ohne einen auslösenden Vorfall bemerken? Audit ist die Kontrolle, die Vertraulichkeit und Sicherheit im Nachhinein durchsetzbar macht, funktioniert aber nur, wenn die Logs vollständig, geschützt und wirklich überprüft sind. Diese Frage trennt zwei Dinge, die ein Team oft vermengt: die Fähigkeit, reaktiv zu untersuchen, wenn eine Beschwerde eintrifft, und die Fähigkeit, Missbrauch proaktiv zu erkennen, bevor sich jemand beschwert. Ergründen Sie, was Ihre Logs tatsächlich erfassen, ob sie verändert werden können, wie lange sie aufbewahrt werden und – die schwerere Frage – wer sie ansieht, wenn es keinen Vorfall gibt. Bedenken Sie die realistischen Bedrohungen: ein Personalmitglied, das ein Familienmitglied, eine Kollegin oder eine Person des öffentlichen Lebens nachschlägt; ein kompromittiertes Konto, das Akten im großen Maßstab exfiltriert. Eine gute Antwort zeigt, dass Audit als aktive Funktion mit Alarmierung ausgestattet ist, nicht als schlafendes Archiv, und kann ein reales Beispiel für Missbrauch nennen, den die Organisation erkannte und bearbeitete. Sie verbindet Audit auch mit Fairness und stellt sicher, dass Überprüfungen nicht überproportional bestimmte Personalgruppen ins Visier nehmen.

4. Wenn Klinikpersonal legitim eine Akte braucht, die es nicht routinemäßig sehen darf, macht unser Break-Glass-Weg die sichere Handlung leicht und die ungerechtfertigte sichtbar? Gesundheit und Pflege unterscheiden sich von gewöhnlicher Unternehmens-IT gerade dadurch, dass die Regeln manchmal der Patientin vor Ihnen weichen müssen – ein bewusstloser Neuzugang, ein organisationsübergreifender Notfall, ein Kliniker außerhalb der Dienstzeiten, der eine ungewohnte Fallzahl abdeckt. Diese Frage fragt, ob der Notfallzugriff als expliziter, begründeter, markierter Weg gestaltet ist oder Personal still gezwungen wird, zwischen der Zugriffsrichtlinie und dem Wohl der Patientin zu wählen. Prüfen Sie die Fehlerbilder an beiden Enden: ein Break-Glass-Weg, so umständlich, dass Klinikpersonal ihn meidet und stattdessen Zugangsdaten teilt, oder einer, so reibungslos und ungeprüft, dass er zum Routineweg hinein wird und RBAC völlig aushöhlt. Besprechen Sie, wer Break-Glass-Ereignisse überprüft, wie schnell und welcher Anteil sich als ungerechtfertigt erweist – eine Rate nahe null kann bedeuten, dass die Kontrolle ungenutzt statt sauber ist. Eine gute Antwort kann die genauen Schritte beschreiben, die eine Klinikerin unternimmt, die Grunderfassung, die sofortige Markierung an die Heimatorganisation der Akte und die nachträgliche Überprüfung, die die Schleife schließt, und zeigen, dass Notfälle wirklich bedient und Missbrauch wirklich gefangen wird. Sie ist ehrlich, ob Break-Glass-Volumina in eine Richtung laufen, die eine tiefere Autorisierungslücke nahelegt.

5. Steuern wir privilegierten und nichtmenschlichen Zugriff so eng wie den des Klinikpersonals – oder sitzt dort die eigentliche Exposition? Die Kontrollen, die Patientendaten schützen, werden selbst von jemandem administriert, und Administratoren, Datenbankverantwortliche, Integrations-Engines und Berichtskonten können oft jede Akte lesen oder ändern und genau die Schutzvorkehrungen abschalten, die alle anderen einschränken. Diese Frage zerrt den Zugriff ans Licht, den die Disziplin der geringsten Rechte am ehesten überspringt: dauerhafte Admin-Konten, Fernsupport-Zugänge von Lieferanten, Servicekonten mit Gottmodus-Rechten und die automatisierte Schnittstelle, die still identifizierbaren Freitext zieht, den sie nie brauchte. Besprechen Sie, ob Admin-Identitäten von Alltagskonten getrennt sind, ob Erhöhung Just-in-Time und zeitlich begrenzt oder dauerhaft ist und ob privilegierte Sitzungen aufgezeichnet und unabhängig überprüft werden. Bedenken Sie speziell die nichtmenschliche Landschaft – wer jedes Servicekonto verantwortet, wann seine Zugangsdaten zuletzt rotiert wurden und ob jemand sie heute aufzählen könnte. Eine gute Antwort behandelt privilegierten Zugriff als eigene Kategorie mit benannten Verantwortlichen, Evidenz für Just-in-Time-Erhöhung und einem echten Inventar von Maschinenidentitäten, statt der Annahme, dass die auf Klinikpersonal angewandten Grundlagen auch das Backoffice abdecken. Sie ist offen zu Lieferanten und zu jedem Konto, das zu einem dauerhaften, unüberwachten Generalschlüssel geworden ist.

6. Wie viel unserer Identität hängt von Parteien außerhalb unserer Kontrolle ab, und gehen wir mit dieser Abhängigkeit bewusst um? Moderne Identität in Gesundheit und Pflege ist von Natur aus föderiert – eine gemeinsame Akte vertraut Aussagen jeder Partnerorganisation, nationale Services wie der NHS Care Identity Service und CIS2 bürgen für Personal, und NHS login bürgt für Bürgerinnen und Bürger –, was bedeutet, dass die Stärke Ihrer Zugriffskontrolle nur so gut ist wie die Identitätsanbieter, auf die Sie sich verlassen, und die Standards, die Sie verbinden. Diese Frage bittet das Team zu kartieren, wo Vertrauen delegiert ist: welche Organisationen welche Nutzenden authentifizieren, was geschieht, wenn der Joiners/Movers/Leavers-Prozess eines Partners versagt, und wie ein föderierter Login entzogen wird, wenn ein Mitarbeitender eines anderen Arbeitgebers geht. Wägen Sie die laufende Migration von Smartcards zu standardbasierter Authentifizierung (CIS2 mit MFA und OpenID Connect) ab und die Spannung zwischen der Übernahme nationaler Richtung und dem Funktionieren lokaler Arbeitsabläufe um 3 Uhr morgens. Bedenken Sie auch den Resilienzaspekt: Wenn ein nationaler Identitätsdienst nicht verfügbar ist, kann Klinikpersonal die nötigen Akten dennoch sicher erreichen, oder wird Föderation zum Single Point of Failure? Eine gute Antwort zeigt, dass das Team genau weiß, auf wessen Absicherung es sich verlässt, vereinbart hat, wie organisationsübergreifender Entzug und Vorfälle behandelt werden, und seinen Wechsel zur modernen NHS-Authentifizierung bewusst sequenziert, statt davon getragen zu werden. Sie ist realistisch zu den Teilen der Landschaft, die noch nicht föderieren können, und wie sie in der Zwischenzeit überbrückt werden.

In der Praxis: ein Beispiel aus Gesundheit und Pflege#

Das Meadowvale Integrated Care System führt eine gemeinsame Patientenakte ein, damit Personal aus Krankenhaus, Gemeinde, psychischer Gesundheit, Hausarztpraxis und Erwachsenen-Sozialfürsorge eine einheitliche Sicht auf jeden Menschen sehen kann. Früh in der Discovery erkennt das Programm, dass sein wirkliches Risiko nicht der Bau der Akte ist, sondern die Kontrolle des Zugriffs darauf: Eine einzige Sicht über fünf Organisationen vervielfacht sowohl den Sicherheitsnutzen, dass die richtige Klinikerin die richtige Information sieht, als auch den Schaden, dass die falsche Person etwas Sensibles sieht.

Das Team macht Zugriffskontrolle zu einem erstklassigen Designstrang. Es vereinbart ein in klinischer Sprache ausgedrücktes Rollenmodell – „Gemeindepflegekraft“, „zugelassene psychosoziale Fachkraft“, „Pflegeheimleiterin“ – und bildet jede Rolle auf die geringste Datenmenge ab, die sie braucht, wobei Akten zu psychischer und sexueller Gesundheit engerem, separat autorisiertem Zugriff unterliegen. Die Authentifizierung ist föderiert: Jede Partnerorganisation authentifiziert ihr eigenes Personal über den NHS Care Identity Service oder ihren lokalen Identitätsanbieter mit OpenID Connect, und die gemeinsame Akte vertraut diesen Aussagen, statt eigene Zugangsdaten auszugeben; es gibt also kein neues Passwort zu verwalten, und Joiners/Movers/Leavers bleibt bei der beschäftigenden Organisation, wo die maßgebliche Personalakte lebt.

Weil ein Rettungssanitäter oder ein Kliniker außerhalb der Dienstzeiten manchmal eine Akte braucht, die er nicht routinemäßig sehen darf, baut das Team einen expliziten Break-Glass-Weg: Notfallzugriff wird bei Eingabe eines Grundes gewährt, sofort an die Heimatorganisation der Akte markiert und binnen 48 Stunden überprüft. Sie stellen eine kleine gemeinsame Funktion für Informationsgovernance und Audit auf, die Break-Glass-Ereignisse prüft, Alarme für Selbstabfragen und Abfragen markierter Personen betreibt und vierteljährlich an den ICS-Vorstand berichtet.

Sechs Monate nach dem Go-live markiert ein Alarm eine Versorgungskoordinatorin, die wiederholt die Akte einer Person öffnet, die nicht an ihrer Fallzahl beteiligt ist. Die Audit-Funktion untersucht, stellt fest, dass der Zugriff persönlich statt beruflich war, und die beschäftigende Organisation ergreift disziplinarische Maßnahmen. Es trat kein Patientensicherheitsvorfall auf, der Verstoß wurde proaktiv gefangen, und – weil die Kontrollen nachweislich funktionierten – hielt das öffentliche Vertrauen in die gemeinsame Akte. Der Vorstand vermerkt, dass dieselbe Audit-Fähigkeit nun auch als Evidenz für seine Einreichung beim Data Security and Protection Toolkit dient (siehe Thema 1.7 — Informationsgovernance, Datenschutz und Cybersicherheit).

Sektorperspektiven#

Startup#

Ein kleines Unternehmen der digitalen Gesundheit, das etwa eine Fernüberwachungs-App baut, hat den Vorteil, keine Altlasten zu haben: Es kann moderne Authentifizierung, MFA und standardbasierte Föderation von Tag eins an übernehmen und sich für Bürgerinnen und Bürger mit NHS login und für Klinikpersonal mit CIS2 integrieren, statt ein eigenes Identitätssystem zu erfinden. Die Gefahr ist, dass Tempo die Disziplin überholt – fest kodierte Admin-Zugangsdaten, ein geteiltes „Gründer“-Superuser-Konto, Servicekonten mit Gottmodus-Zugriff und kein Leaver-Prozess, weil „jeder jeden kennt“. Geringste Rechte und Audit fühlen sich bei zehn Personen wie Overhead an, werden aber bei hundert zu unrettbarer technischer Schuld. Der pragmatische Zug ist, Identität als verwalteten Service zu kaufen, MFA und RBAC ab dem ersten Commit durchzusetzen und DTAC-Anforderungen (Digital Technology Assessment Criteria) als Mindestlatte für jeden NHS-Einsatz zu behandeln.

Kleines Unternehmen#

Ein etablierter kleiner Anbieter – eine Hausarztpraxis, eine Gemeindeapotheke, ein Pflegeheim, ein ambulanter Pflegedienst, eine Einzelstandort-Klinik oder ein kleiner Health-Tech-Lieferant jenseits der Phase ohne Umsatz – trägt dieselben Pflichten zu Vertraulichkeit und Zugriffskontrolle wie ein großer Trust, hat aber echte Patientinnen und Patienten in den Büchern, eine Handvoll Personal und wenig oder keine eigene IT-Kapazität, sie zu erfüllen. Das praktische Risiko ist hier nicht exotisch: Es ist der geteilte Login am Empfang, das an einen Monitor geklebte Passwort des klinischen Systems, die Vertretungskraft, die die Smartcard einer Kollegin bekommt, weil die Registrierung einer neuen zu lange dauert, und der Ausscheidende, dessen Konto nie deaktiviert wird, weil niemand diese Aufgabe verantwortet. Der pragmatische Weg ist, sich auf die in den gekauften Systemen bereits eingebauten Identitätsfunktionen zu stützen – MFA und Konten je Person durchzusetzen, das Audit-Logging des Lieferanten einzuschalten und NHS CIS2 und NHS login statt hausgemachter Zugangsdaten zu nutzen – und eine einfache Joiners/Movers/Leavers-Routine aufzuschreiben, die eine verantwortliche Person benennt, auch wenn diese Person die Praxismanagerin ist, die es von Hand tut. Geringste Rechte und Entzug am selben Tag bei Ausscheidenden zählen bei zehn Mitarbeitenden ebenso wie bei zehntausend; der Unterschied ist, dass sie hier durch Prozess und Konfiguration statt durch ein eigenes Identitätsteam erreicht werden müssen.

Großunternehmen#

Ein großer NHS Trust oder ICS betreibt Dutzende klinischer Systeme sehr unterschiedlichen Alters, jedes mit eigenem Identitätsmodell; seine zentrale Herausforderung ist Integration und Lebenszyklus im großen Maßstab. Smartcards, SSO, „Tap in, Tap out“-Arbeitsabläufe und eine verlässliche JML-Pipeline aus der elektronischen Personalakte zählen hier mehr als jede einzelne clevere Kontrolle, weil die Fehlerbilder Volumenfehler sind: Tausende ruhende Konten, Rollenexplosion und Audit-Logs, für deren Überprüfung niemand Kapazität hat. Privileged Access Management ist angesichts der Zahl von Administratoren und Lieferanten, die die Landschaft berühren, kritisch. Fortschritt kommt aus einer Identitätsstrategie, die Rollen rationalisiert, über Systeme föderiert und eine ständige Audit-Funktion ausstattet – nicht aus Punktlösungen, die an jede Anwendung angeflanscht werden.

Regierung#

Eine nationale Stelle wie NHS England betreibt Identität als gemeinsame Infrastruktur für das ganze System: den NHS Care Identity Service und CIS2 für Personal, NHS login für Bürgerinnen und Bürger sowie die Standards und Assurance-Regime, die Hunderte Organisationen einander vertrauen lassen. Ihre Entscheidungen setzen die Entwicklungsrichtung – der Wechsel von Smartcards zu moderner Authentifizierung, die Übernahme von OpenID Connect, der Vorstoß zu Zero Trust – und ihre Rechenschaft gilt gegenüber Parlament und Öffentlichkeit für Sicherheit und gerechten Zugang. Die Spannung liegt zwischen zentraler Standardisierung und lokaler Flexibilität: Zu starr vorgeschrieben, brechen Sie lokale Arbeitsabläufe; zu locker vorgeschrieben, kollabiert Föderation in Uneinheitlichkeit. Die Regierungsperspektive dreht sich daher darum, interoperable Standards zu setzen (siehe Thema 4.3 — Interoperabilität und Datenstandards), vertrauenswürdige gemeinsame Services bereitzustellen und Compliance abzusichern, ohne jeden Trust zu mikromanagen.

Häufige Fehlermuster#

• Verwaiste und ruhende Konten. Ausscheidende, rotierte Mitarbeitende und alte Auftragnehmer behalten Live-Zugriff, weil JML auf manuelle Benachrichtigung setzt. Die Lösung ist automatisiertes Deprovisioning aus einer maßgeblichen Quelle plus regelmäßige Durchsuchung nach ruhenden Konten.
• Rollenexplosion und Privilege Creep. RBAC verfällt zu Hunderten überlappender Rollen, und Einzelne sammeln Rechte an, die sie nicht mehr nutzen. Dagegen helfen periodische Rezertifizierung und planmäßige Rollenrationalisierung.
• Zugangsdaten-Teilen und gemeinsame Arbeitsplätze. Langsame Anmeldungen und klobige Smartcards treiben Personal, Karten zu teilen und Sitzungen offen zu lassen. Beheben Sie die Ursache mit SSO, Näherungsausweisen und schnellem Wechsel, statt das Personal zu ermahnen, sich anständig zu verhalten.
• Dauerhafter privilegierter Zugriff. Administratoren und Lieferanten halten permanente Gottmodus-Konten, die die Kontrollen selbst abschalten können. Wechseln Sie zu Just-in-Time-, zeitlich begrenzter, aufgezeichneter Erhöhung.
• Audit als Dekoration. Logs werden gesammelt, aber nie überprüft, sodass Missbrauch nur reaktiv gefunden wird. Statten Sie proaktives Audit mit Alarmierung für Selbstabfragen und VIP-Abfragen aus.
• Break-Glass als Schlupfloch. Notfallzugriff existiert, ist aber unüberwacht und wird zum Routineweg des geringsten Widerstands. Verlangen Sie einen Grund, markieren Sie jede Nutzung und überprüfen Sie nachträglich.
• MFA-Theater. MFA ist aktiviert, aber auf schwachen, phishbaren Faktoren oder für die geschäftigsten privilegierten Nutzenden erlassen. Bevorzugen Sie phishing-resistente Faktoren dort, wo das Risiko am höchsten ist.

Reifegradmodell#

Checkliste#

• Authentifizierungsstärke und Autorisierungsumfang sind für jedes klinische System getrennt entschieden und dokumentiert.
• MFA ist für allen Fern- und privilegierten Zugriff durchgesetzt, mit für das klinische Umfeld passenden Faktoren.
• Single Sign-on und schneller Arbeitsplatzwechsel sind eingeführt, um Anmeldereibung und Teilen von Zugangsdaten zu beseitigen.
• Das Rollenmodell ist in klinischer Sprache ausgedrückt, auf geringste Rechte abgebildet und planmäßig rationalisiert.
• Joiners/Movers/Leavers sind aus einer maßgeblichen Personalquelle automatisiert, mit Entzug am selben Tag bei Ausscheiden und Suspendierung.
• Periodische Zugriffsrezertifizierung wird von rechenschaftspflichtigen Führungskräften durchgeführt, mit Entzug als Voreinstellung bei unbestätigtem Zugriff.
• Privilegierter Zugriff wird als eigene Kategorie gesteuert: getrennte Identitäten, Just-in-Time-Erhöhung, Sitzungsaufzeichnung.
• Nichtmenschliche und Integrationskonten sind inventarisiert, auf geringste Rechte eingeschränkt und in ihren Zugangsdaten rotiert.
• Umfassendes, manipulationssicheres Audit-Logging besteht, mit proaktiver Alarmierung bei Selbst-, Kollegen- und VIP-Abfragen.
• Break-Glass-Notfallzugriff ist mit verpflichtendem Grund, sofortiger Markierung und nachträglicher Überprüfung gestaltet.
• Die Migration von Smartcards zu moderner NHS-Authentifizierung (CIS2 / OpenID Connect) ist geplant und sequenziert.
• Eine Zero-Trust-Roadmap ist vereinbart und auf die technische Architekturstrategie abgestimmt.

Zentrale Quellen#

• NHS England — Leitlinien zu NHS Care Identity Service und Care Identity Service 2 (CIS2)
• NHS England — Data Security and Protection Toolkit
• National Cyber Security Centre (NCSC) — Zero Trust Architecture Design Principles
• National Cyber Security Centre (NCSC) — Leitlinien zu Multi-Faktor-Authentifizierung und Identitäts-/Zugriffsmanagement
• NIST — Special Publication 800-207, Zero Trust Architecture
• NIST — Special Publication 800-63, Digital Identity Guidelines
• NHS England / NHS login — Dokumentation des Identitätsverifizierungsdienstes für Bürgerinnen und Bürger
• DTAC — Digital Technology Assessment Criteria für Gesundheit und Sozialfürsorge
• Caldicott-Prinzipien und die Schweigepflicht nach Common Law (UK)

Referenzen#

1. Identity management (identity and access management) — Wikipedia — https://en.wikipedia.org/wiki/Identity_management
2. Authentication — Wikipedia — https://en.wikipedia.org/wiki/Authentication
3. Authorization — Wikipedia — https://en.wikipedia.org/wiki/Authorization
4. Role-based access control — Wikipedia — https://en.wikipedia.org/wiki/Role-based_access_control
5. Principle of least privilege — Wikipedia — https://en.wikipedia.org/wiki/Principle_of_least_privilege
6. Multi-factor authentication — Wikipedia — https://en.wikipedia.org/wiki/Multi-factor_authentication
7. Single sign-on — Wikipedia — https://en.wikipedia.org/wiki/Single_sign-on
8. Federated identity — Wikipedia — https://en.wikipedia.org/wiki/Federated_identity
9. OAuth — Wikipedia — https://en.wikipedia.org/wiki/OAuth
10. OpenID (and OpenID Connect) — Wikipedia — https://en.wikipedia.org/wiki/OpenID
11. Security Assertion Markup Language (SAML) — Wikipedia — https://en.wikipedia.org/wiki/Security_Assertion_Markup_Language
12. Provisioning (technology) — Wikipedia — https://en.wikipedia.org/wiki/Provisioning_(technology)
13. Zero trust architecture — Wikipedia — https://en.wikipedia.org/wiki/Zero_trust_architecture
14. NHS Care Identity Service 2 (CIS2) — NHS England — https://digital.nhs.uk/services/care-identity-service
15. Data Security and Protection Toolkit — NHS England — https://www.dsptoolkit.nhs.uk/
16. Zero Trust Architecture Design Principles — National Cyber Security Centre — https://www.ncsc.gov.uk/collection/zero-trust-architecture
17. Special Publication 800-207: Zero Trust Architecture — National Institute of Standards and Technology (NIST) — https://csrc.nist.gov/pubs/sp/800/207/final
18. Special Publication 800-63: Digital Identity Guidelines — National Institute of Standards and Technology (NIST) — https://pages.nist.gov/800-63-3/
19. Digital Technology Assessment Criteria (DTAC) — NHS England — https://www.nhs.uk/digital-technology-assessment-criteria-dtac/
20. NHS login — NHS England — https://www.nhs.uk/nhs-services/online-services/nhs-login/