Warum Identitätsmanagement für Managed Service Provider (MSPs) existentiell wurde
Identitätsmanagement ist für Managed Service Provider (MSPs) existentiell geworden, da wenige Techniker- und Tool-Identitäten den Zugriff auf zahlreiche Kundenkonten gleichzeitig steuern und jedes schlecht verwaltete Konto zu einem potenziellen Sicherheitsvorfall für mehrere Kunden machen. Können Sie nicht nachweisen, dass jede Identität und Berechtigung bewusst vergeben, angemessen und leicht widerrufbar ist, werden Kunden, Auditoren und Ihre eigene Führungsebene dies als kritisches, systemisches Risiko und nicht als unbedeutendes operatives Detail einstufen.
Diese Informationen sind allgemeiner Natur und stellen keine Rechts- oder Regulierungsberatung dar.
Die Identität ist heute die Eingangstür für jeden Kunden.
Die Identität ist heute der Zugangspunkt zu jedem Mandanten, da nahezu jede Aktion Ihrer Entwickler oder Tools über ein Konto, eine Rolle oder ein Token läuft. Wenn diese Identitäten mehrere Mandanten umfassen, kann eine mangelhafte Konzeption oder unzureichende Governance dazu führen, dass jede einzelne Identität zu einem potenziellen Einfallstor für viele Kundenumgebungen gleichzeitig wird.
Für Managed Service Provider (MSPs) hat die Identitätsverwaltung den traditionellen Netzwerkperimeter praktisch ersetzt, da nahezu jede Aktion in einer Clientumgebung über ein Konto, eine Rolle oder ein Token läuft, das Mandantengrenzen überschreiten kann. Unabhängige Analysen von Cloud- und Provider-seitigen Risiken, wie beispielsweise europäische Leitlinien zur Netzwerk- und Informationssicherheit in Bezug auf Bedrohungen innerhalb der Cloud, verdeutlichen ebenfalls, wie Identität und Zugriffspfade zur praktischen Kontrollschnittstelle in Multi-Tenant-Umgebungen geworden sind.
In älteren, stärker auf Perimeter-Sicherheit ausgerichteten Modellen konnte man sich darauf verlassen, dass ein VPN, eine Firewall-Regel und ein kleiner Kreis vertrauenswürdiger Techniker für Sicherheit sorgten. Heutzutage ermöglichen Cloud-Plattformen, Remote-Arbeit und gemeinsam genutzte Managementebenen zwar den Betrieb in großem Umfang, bedeuten aber auch, dass jede zusätzliche Berechtigung, die Ihr Team in einem Mandanten besitzt, das Risiko für viele Mandanten erhöhen kann. Mit der Ergänzung von ISO 27001:2022 Annex A.5.16, die das Identitätsmanagement zu einer expliziten Kontrollmaßnahme erhebt, wird dieser Wandel noch deutlicher: Der zugehörige Standard ISO/IEC 27002:2022 führt A.5.16 als eigenständige Kontrollmaßnahme für das Identitätsmanagement ein und unterstreicht damit ausdrücklich die Notwendigkeit, Identitäten und ihre Lebenszyklen als erstklassige Sicherheitsobjekte und nicht als nebensächliche Implementierungsdetails zu behandeln.
Wenn das Corporate Design hinter dem Wachstum zurückbleibt, wachsen die Risiken im Verborgenen.
Auch Kunden haben diesen Wandel bemerkt. Sicherheitsbewusste Käufer stellen nun detaillierte Fragen dazu, welche Mitarbeiter von Managed Service Providern (MSPs) Zugriff auf ihre Systeme haben, wie diese Konten erstellt und gelöscht werden und wie verhindert wird, dass sich ein Sicherheitsvorfall bei einem Kunden auf andere ausbreitet. Identitätskontrollen sind nicht länger nur eine Frage der „guten Hygiene“, sondern werden zunehmend zur Grundvoraussetzung, um Kunden zu gewinnen und zu binden, denen ISO 27001 oder ähnliche Rahmenwerke wichtig sind.
Warum Kunden und Wirtschaftsprüfer sich zunehmend dafür interessieren
Kunden und Auditoren legen Wert auf Ihr Identitätsmanagement, da die Benutzerkonten Ihrer Ingenieure in deren Lieferkette eingebunden sind und die Vertraulichkeit, Integrität und Verfügbarkeit ihrer Systeme und Daten direkt beeinträchtigen können. Sind diese Identitäten unzureichend geschützt, kann jeder Vorfall in Ihrer Umgebung schnell auch deren Problem werden, unabhängig davon, wo die Kompromittierung ursprünglich stattfand.
Aus Kundensicht sind Sie Teil seiner erweiterten IT-Umgebung. Wenn ein Angreifer einen Ihrer Technikeraccounts kompromittiert und diesen nutzt, um seine Mandanten zu manipulieren, sind die Auswirkungen für ihn sehr real, selbst wenn der erste Zugriff über Ihre Systeme erfolgte. Daher behandeln viele Aufsichtsbehörden und Versicherer den Zugriff auf Managed Service Provider (MSPs) mittlerweile als ein wichtiges Risiko und nicht mehr als eine technische Nebensache. Beispielsweise definieren Leitlinien für Drittanbieter und Outsourcing im Finanzsektor, wie die Outsourcing-Leitlinien der Europäischen Bankenaufsichtsbehörde (EBA), den Zugriff und die Governance von Anbietern explizit als wesentliches operationelles Risiko, das die Aufmerksamkeit der Geschäftsleitung erfordert.
In der ISMS.online-Umfrage „State of Information Security 2025“ nannten rund 41 % der Unternehmen die Bewältigung von Drittparteirisiken und die Überwachung der Lieferantenkonformität als eine der größten Sicherheitsherausforderungen.
Auditteams sind diesem Weg gefolgt. Während sich frühere ISO-27001-Audits hauptsächlich auf interne Benutzerlisten und einige wenige Zugriffsprüfungen konzentrierten, fordert A.5.16 die Auditoren auf, präzisere Fragen zu stellen. Sie wollen wissen, ob jede MSP-Identität eindeutig ist, ob nachvollziehbar ist, wer den Zugriff auf die einzelnen Mandanten genehmigt hat, wie schnell Zugriffsrechte bei Ausscheiden von Mitarbeitern entzogen werden und ob Berechtigungen regelmäßig anhand der aktuellen Rollen überprüft werden. Akkreditierungs- und Zertifizierungsrichtlinien für ISO/IEC 27001, wie beispielsweise die Materialien der IAF zu ISO/IEC-27001-Audits, unterstreichen diesen Fokus auf Nachvollziehbarkeit, Eindeutigkeit und fundierte Nachweise im Zusammenhang mit identitätsbezogenen Kontrollen.
Aus diesem Grund ist Identität auch zu einem wichtigen Gesprächsthema bei Vertrieb und Vertragsverlängerungen geworden. Große Interessenten verlangen oft detaillierte Beschreibungen Ihres Identitätsmanagementmodells, bevor sie einen Vertrag unterzeichnen. Bestandskunden drängen möglicherweise auf die Zusicherung, dass Sie gemeinsam genutzte Administratorkonten abgeschafft oder veraltete Zugriffswege eingeschränkt haben. Wenn Sie diese Fragen souverän beantworten und strukturierte Nachweise vorlegen können, schafft Identität Vertrauen. Andernfalls wird sie zu einer immer wiederkehrenden Quelle von Reibungsverlusten und Verzögerungen.
Der kommerzielle Vorteil einer gelungenen Markenidentität
Die korrekte Verwaltung von Identitätsdaten reduziert nicht nur Risiken, sondern schafft auch wirtschaftliche Vorteile, indem sie das Vertrauen in Ihren Service stärkt, die Skalierbarkeit verbessert und die Kommunikation mit Entscheidungsträgern ohne technischen Hintergrund erleichtert. Wenn Identitätsdaten als dynamisches Kontrollinstrument und nicht als unübersichtliches Kontengeflecht betrachtet werden, können Sie sie als Teil Ihres Wertversprechens nutzen, anstatt zu hoffen, dass Kunden nicht danach fragen.
Die ISMS.online-Umfrage 2025 zeigt, dass Kunden zunehmend erwarten, dass Lieferanten sich an formale Rahmenwerke wie ISO 27001, ISO 27701, DSGVO, Cyber Essentials, SOC 2 und neue KI-Standards anpassen.
Man könnte all dies leicht als reinen Compliance-Aufwand betrachten, doch Managed Service Provider (MSPs), die A.5.16 als Designherausforderung und nicht nur als Audit-Anforderung verstehen, können deutlichere Vorteile erzielen. Ein klares, standardisiertes Identitätsmodell für alle Mandanten erleichtert die Einarbeitung neuer Techniker, reduziert den Zeitaufwand für die Behebung von Zugriffsproblemen und liefert dem Vertrieb eine glaubwürdige Begründung, warum man ihm kritische Systeme anvertrauen sollte – auch wenn die konkreten Vorteile je nach Organisation variieren.
Wenn Sie sagen können: „Hier ist unser Rollenkatalog, so weisen wir ihn Mandanten zu, so entfernen wir Zugriffsrechte bei Rollenwechseln und so überprüfen wir ihn“, dann argumentieren Sie nicht mehr nur über den Preis. Sie bieten Sicherheit. Eine Plattform wie ISMS.online kann Ihnen helfen, dieses Modell so darzustellen und zu belegen, dass Kunden und Auditoren es verstehen, ohne dass Sie sich zum Vollzeit-Standardspezialisten ausbilden lassen müssen. Identität wird zu einem Thema, über das Sie mit ruhiger Zuversicht sprechen können.
KontaktWas ISO 27001:2022 A.5.16 tatsächlich verlangt
ISO 27001:2022 A.5.16 verlangt den Nachweis, dass jede Identität im Geltungsbereich bewusst erstellt, mit entsprechenden Rechten versehen, regelmäßig überprüft und umgehend entfernt wird, sobald sie nicht mehr benötigt wird – und nicht aus Gewohnheit oder Bequemlichkeit entsteht. Für Managed Service Provider (MSPs) gilt diese Vorgehensweise konsequent für alle internen Systeme und alle relevanten Kundenkonten, auf die Ihre Mitarbeiter oder Tools zugreifen können, nicht nur für die Systeme, die Sie direkt betreiben. Der zugehörige Kontrolltext in ISO/IEC 27002:2022 A.5.16 verdeutlicht dies durch die Forderung nach Richtlinien und Prozessen, die die Identifizierung, Zuweisung und das Lebenszyklusmanagement von Identitäten regeln, die für den Zugriff auf Informationen und Dienste verwendet werden.
Im Kern verlangt A.5.16 den Nachweis, dass Identitäten und die zugehörigen Zugriffsrechte während ihres gesamten Lebenszyklus bewusst verwaltet werden. Für Managed Service Provider (MSPs) bedeutet dies, über die willkürliche Kontoerstellung oder die Bereitstellung von kurzfristigen Berechtigungen hinauszugehen und stattdessen klare Regeln für die Erstellung, Änderung, Überprüfung und Löschung von Identitäten in allen betreuten Umgebungen zu definieren. Sie müssen kein ISO-Spezialist sein; Sie benötigen lediglich eine wiederholbare Methode zur Identitätsverwaltung, die für Auditoren und Kunden verständlich ist.
In der ISMS.online-Umfrage 2025 gaben fast alle Organisationen an, dass das Erreichen oder Aufrechterhalten von Sicherheitszertifizierungen wie ISO 27001 oder SOC 2 für sie höchste Priorität hat.
Die Kernverpflichtungen in A.5.16
A.5.16 lässt sich in wenige konkrete Verpflichtungen übersetzen, die zwar einfach zu beschreiben, aber in ihrer konsistenten Umsetzung über mehrere Mandanten hinweg anspruchsvoll sind. Für Managed Service Provider (MSPs) müssen sich diese Verpflichtungen über interne Systeme hinaus auf alle Bereiche erstrecken, in denen Ihre Mitarbeiter und Tools in Kundenumgebungen agieren können, einschließlich Cloud-Konsolen und Managementplattformen.
Wenn man A.5.16 auf das Wesentliche reduziert, stechen vier Verpflichtungen hervor:
- Stellen Sie sicher, dass jede Identität, die auf relevante Informationen oder Systeme zugreifen kann, eindeutig ist und einer realen Person oder Funktion zugeordnet werden kann.
- Jede Identität muss vor der ersten Zugriffsgewährung durch einen festgelegten Prozess registriert, genehmigt und erstellt werden.
- Zugriffsrechte sollten auf der Grundlage dokumentierter Rollen oder geschäftlicher Erfordernisse und nicht auf der Grundlage von Gewohnheiten oder individuellen Vorlieben vergeben werden.
- Identitäten und Rechte werden in einem geplanten Zyklus überprüft und gegebenenfalls angepasst oder widerrufen, wenn sie nicht mehr angemessen sind.
Für Managed Service Provider (MSPs) beschränkt sich dies nicht auf den internen Microsoft 365-Tenant oder das Ticketsystem. Es umfasst die Konten und Rollen, die Ihre Mitarbeiter in den einzelnen Kundentenants verwenden, die Dienstkonten, auf die Ihre Tools angewiesen sind, und sogar generische oder gemeinsam genutzte Identitäten, die Sie möglicherweise aus historischen Gründen noch verwenden. A.5.16 verbietet nicht zwangsläufig nicht-personenbezogene Konten, erwartet aber, dass deren Nutzung, sofern vorhanden, minimiert, streng kontrolliert und vollständig nachvollziehbar ist. Praxisnahe Kommentare zu ISO 27002, wie beispielsweise Community-orientierte Leitlinien zu ISO/IEC 27002, heben hervor, dass Dienst- oder gemeinsam genutzte Konten akzeptabel sind, wenn sie klar begründet, geregelt und auditierbar sind.
Aus praktischer Sicht müssen Sie Fragen beantworten können wie: „Wer hat diesen Zugriff beantragt, wer hat ihn genehmigt, wann wurde er gewährt, was erlaubt er und wann wurde er zuletzt überprüft?“ Das ist eine höhere Anforderung als „Wir haben eine Benutzerliste“, aber es ist auch die Art von Anforderung, die Ihren Kunden hilft, nachts ruhig zu schlafen.
Wie A.5.16 mit anderen ISO 27001-Kontrollen zusammenhängt
Das Verständnis des Zusammenhangs zwischen A.5.16 und den angrenzenden Kontrollen erleichtert die Entwicklung eines kohärenten Systems, das die Anforderungen der Prüfer erfüllt, erheblich und vermeidet Doppelarbeit. Für Managed Service Provider (MSPs) sind die wichtigsten Verbindungen zu A.5.17, A.5.18 und A.8.2 relevant, die Authentifizierungsinformationen, Zugriffsrechte bzw. privilegierte Konten abdecken.
Identitätsmanagement ist kein isoliertes Thema. A.5.16 ist eng mit mehreren anderen Kontrollen der ISO 27001-Revision 2022 verknüpft, und Auditoren betrachten sie häufig gemeinsam. A.5.17 (Authentifizierungsinformationen) konzentriert sich auf den Schutz von Passwörtern, Token, Schlüsseln und anderen Authentifizierungsmitteln. A.5.18 (Zugriffsrechte) behandelt die Gewährung, Änderung und den Entzug von Zugriffsrechten. A.8.2 befasst sich speziell mit privilegierten Zugriffsrechten, wie z. B. Administrator- oder Root-Konten. Die Zuordnungsrichtlinien und Kontrollbeschreibungen der ISO 27002, einschließlich der in unabhängigen ISO 27002-Digests zusammengefassten, behandeln diese Bereiche als eigenständige, aber koordinierte Aspekte der Zugriffskontrolle.
Man kann diesen Cluster folgendermaßen betrachten: A.5.16 beantwortet die Frage „Wer ist im System vorhanden und welche Berechtigungen haben wir diesen Personen eingeräumt?“, A.5.17 die Frage „Wie stellen wir sicher, dass es sich bei der Anmeldung tatsächlich um diese Person handelt?“ und A.8.2 die Frage „Wie behandeln wir besonders privilegierte Konten mit besonderer Sorgfalt?“. Bei der Entwicklung eines mandantenfähigen Identitätsmodells legen Sie im Wesentlichen fest, wie diese drei Kontrollmechanismen in der Praxis für Ihre Entwickler und Tools funktionieren.
Das Verständnis dieser Zusammenhänge hilft Ihnen, Doppelungen und Lücken zu vermeiden. Wenn Sie beispielsweise bedarfsgerechten privilegierten Zugriff für Entwickler einführen, berühren Sie gleichzeitig den Identitätslebenszyklus (A.5.16), die Zugriffsgewährung (A.5.18), privilegierte Zugriffsrechte (A.8.2) und den Authentifizierungsschutz (A.5.17). Je klarer Sie darlegen können, wie Ihre Vorgehensweisen die einzelnen Anforderungen erfüllen, desto einfacher werden Audits und Kundengespräche.
Wer und was fällt in den Geltungsbereich des Identitätsmanagements?
A.5.16 gilt für jede Identität, die Einfluss auf relevante Informationen oder Dienste nehmen kann, unabhängig davon, ob das Konto technisch Ihrer Organisation oder einem Kunden gehört. Für Managed Service Provider (MSPs) muss der Geltungsbereich interne Mitarbeiter, Tools und Automatisierungen über alle relevanten Mandanten hinweg umfassen und nicht nur einen kleinen Teil der „internen Benutzer“.
Ein häufiger Fehler ist die Annahme, dass sich A.5.16 nur auf Mitarbeiterkonten in eigenen Systemen bezieht. Für einen Managed Service Provider (MSP) ist dieser Anwendungsbereich viel zu eng gefasst. Jede Identität, die von Ihrem Unternehmen verwendet wird und Informationen oder Dienste innerhalb Ihres Informationssicherheitsmanagementsystems beeinflussen kann, sollte berücksichtigt werden, unabhängig davon, ob das Konto technisch gesehen Ihnen oder einem Kunden gehört.
Dies umfasst benannte Ingenieurskonten in Kunden-Cloud-Umgebungen, delegierte Rollen für Ihre Unternehmensidentitäten, Servicekonten für Backup- oder Überwachungstools sowie Automatisierungsidentitäten für Skripte oder Integrationsplattformen. Auch gemeinsam genutzte oder generische Konten, die in älteren Umgebungen möglicherweise noch vorhanden sind, fallen darunter. Selbst wenn Sie deren Abschaffung planen, sollten Sie diese bis zu ihrer vollständigen Entfernung weiterhin als Teil des Geltungsbereichs betrachten.
Je genauer Sie diesen Umfang im Vorfeld definieren, desto geringer ist die Wahrscheinlichkeit, dass Sie später überrascht werden, wenn ein Wirtschaftsprüfer oder Kunde nach einer Kategorie von Konten fragt, die Sie nicht berücksichtigt hatten. Ein klar definierter Umfang erleichtert zudem die Entscheidung, wo Investitionen in Automatisierung sinnvoll sind und wo Sie sich getrost auf gut kontrollierte manuelle Prozesse verlassen können.
ISO 27001 leicht gemacht
Ein Vorsprung von 81 % vom ersten Tag an
Wir haben die harte Arbeit für Sie erledigt und Ihnen vom Moment Ihrer Anmeldung an einen Vorsprung von 81 % verschafft. Sie müssen nur noch die Lücken ausfüllen.
Neuausrichtung von A.5.16 für die Realität von Multi-Tenant-MSPs
Die Neuausrichtung von A.5.16 für die Realität von Multi-Tenant-MSPs bedeutet, dass mandantenübergreifende Risiken und Risiken in der gemeinsamen Lieferkette als eigenständige Designprobleme behandelt werden müssen. Ihre Interpretation der Kontrollmaßnahme muss berücksichtigen, dass eine Identität mehrere Kundenumgebungen umfassen kann und daher ein höheres systemisches Risiko birgt als in einem Single-Tenant-Unternehmen.
Sobald Sie den formalen Wortlaut von A.5.16 verstanden haben, gilt es, diesen im Kontext eines Anbieters, der in vielen Kundenumgebungen tätig ist, neu zu interpretieren. Die Risiken und Verantwortlichkeiten verändern sich, wenn eine Ihrer Identitäten Sie mit einem einzigen Klick in mehrere Mandanten bringen kann, und Ihr Identitätsmodell muss diesen Unterschied in Umfang und Auswirkungen widerspiegeln.
Das Risikoprofil von MSP-Mehrnutzern verstehen
Das Risikoprofil eines Managed Service Providers (MSP) wird durch die Möglichkeit bestimmt, dass die Identität eines einzelnen Technikers oder ein Tool-Konto missbraucht werden könnte, um gleichzeitig auf viele Kundensysteme zuzugreifen, anstatt nur ein Unternehmen nach dem anderen zu schädigen. Daher sind die potenziellen Auswirkungen und die gemeinsame Gefährdung zentrale Fragen, die Ihr Identitätsdesign beantworten muss, und dürfen nicht nur eine untergeordnete Rolle spielen.
Die meisten Organisationen, die an der ISMS.online-Umfrage 2025 teilnahmen, gaben an, im vergangenen Jahr bereits von mindestens einem Sicherheitsvorfall im Zusammenhang mit Drittanbietern oder Lieferanten betroffen gewesen zu sein.
In einem traditionellen Unternehmen mit einem einzigen Mandanten beschränkt sich der Einfluss eines kompromittierten Administratorkontos üblicherweise auf diese eine Organisation. Bei einem Managed Service Provider (MSP) kann die kompromittierte Identität eines Technikers in manchen Servicemodellen jedoch Zugriff auf Dutzende oder sogar noch mehr Kundenmandanten gewähren, insbesondere wenn in der Vergangenheit Komfort Vorrang vor strikter Trennung hatte. Analysen von Lieferkettenangriffen auf MSPs, wie beispielsweise veröffentlichte Fallstudien zu gezielten Angriffen auf MSPs, zeigen, wie der Missbrauch von Zugangsdaten des Anbieters sich gleichzeitig auf viele Kundenumgebungen auswirken kann.
Die Neuinterpretation von A.5.16 für die heutige Welt bedeutet, in Bezug auf die Auswirkungen und die gemeinsame Gefährdung zu denken. Sie müssen wissen, welche Identitäten Mandantengrenzen überschreiten können, welche Berechtigungen sie in den jeweiligen Umgebungen besitzen und wie Sie verhindern, dass ein Fehler an einer Stelle sich kaskadenartig ausbreitet. Dazu gehört auch die Überlegung, wie Ihre eigenen Cloud-Mandanten, Management-Tools und Ihre lokale Infrastruktur als Einfallstor zu Kunden genutzt werden könnten, falls ein Angreifer die Kontrolle erlangt.
Es erfordert außerdem eine Überprüfung informeller Vorgehensweisen. Gemeinsam genutzte „MSP-Administrator“-Konten, veraltete VPN-Profile, die clientübergreifend wiederverwendet werden, oder undokumentierte Ausnahmen für einzelne Techniker können das von A.5.16 geforderte klare Identitätsbild untergraben. Diese Probleme ohne Schuldzuweisungen aufzudecken, ist der erste Schritt hin zu einer robusteren Lösung.
Klärung der Eigentumsverhältnisse an Identitäten zwischen Managed Service Providern, Kunden und Lieferanten
Die Klärung der Zuständigkeiten für Identitäten über die Grenzen von Managed Service Providern (MSPs), Kunden und Lieferanten hinweg ist unerlässlich, da A.5.16 voraussetzt, dass Sie wissen, wer Zugriffe genehmigt, wer Konten verwaltet und wer im Falle des Missbrauchs dieser Identitäten verantwortlich ist. Ohne diese Klarheit tragen Sie ein höheres Risiko als Ihnen bewusst ist und haben Schwierigkeiten, grundlegende Sorgfaltspflichten zu erfüllen.
Die Multi-Tenant-Realität verwischt auch die Grenzen zwischen den Inhabern der einzelnen Identitäten. Einige Konten werden eindeutig von Ihnen kontrolliert, beispielsweise Ihre Corporate-Identity-Provider-Konten und die damit verbundenen Rollen in den Kunden-Tenants. Andere werden möglicherweise von Kunden erstellt und verwaltet, aber von Ihren Mitarbeitern genutzt. Wieder andere werden unter Umständen von Drittanbietern verwaltet, deren Tools Sie weiterverkaufen oder integrieren.
Eine praktikable Auslegung von A.5.16 für Managed Service Provider (MSPs) erfordert die Definition von Zuständigkeiten und Verantwortlichkeiten in allen Bereichen. Für jede Kategorie sollte klar sein, wer neue Zugriffe genehmigt, wer die Identität erstellt und konfiguriert, wer sie regelmäßig überprüft und wer bei Missbrauch haftet. Diese Antworten müssen mit Ihren Verträgen, den Kundenerwartungen und Ihren Risikobewertungen übereinstimmen.
Dies in einfacher Sprache aufzuschreiben – zusammen mit Diagrammen, die veranschaulichen, wo Identitäten gespeichert sind und wie sie sich durch Systeme bewegen – kann erstaunlich wirkungsvoll sein. Es schafft ein gemeinsames Verständnis im Team und ermöglicht Kunden und Auditoren, ein komplexes Thema zu verstehen, ohne sich in technischen Details zu verlieren.
Regulatorische und rechtliche Aspekte, die Sie nicht ignorieren können
Regulatorische und rechtliche Aspekte sind relevant, da Identitäten Regionen und Datensätze verbinden können, in denen unterschiedliche Datenschutz- und Zugriffsregeln gelten. Regulierungsbehörden erwarten zunehmend von Managed Service Providern (MSPs), dass sie nachweisen, dass grenzüberschreitende oder sensible Zugriffe gerechtfertigt, protokolliert und beschränkt sind. Ein Identitätsdesign, das diese Grenzen ignoriert, führt daher zu vermeidbaren Problemen.
Viele Managed Service Provider (MSPs) arbeiten mit Kunden in regulierten Branchen oder in mehreren Ländern zusammen, wo Identitätsmanagement mit Datenschutz, Datenresidenz und grenzüberschreitenden Zugriffsanforderungen verknüpft ist. Wenn Mitarbeiter in einem Land auf Systeme zugreifen können, die Daten aus einem anderen Land enthalten, können Aufsichtsbehörden von Ihnen verlangen, darzulegen, wie Sie diesen Zugriff kontrollieren und rechtfertigen, insbesondere wenn lokale Gesetze einschränken, wer welche Daten von wo einsehen darf. Europäische Datenschutzleitlinien für Verantwortliche und Auftragsverarbeiter, wie beispielsweise die des Europäischen Datenschutzbeauftragten, betonen die Bedeutung von Governance, Protokollierung und vertraglicher Klarheit für Auftragsverarbeiter, die grenzüberschreitende oder sensible Daten im Auftrag von Verantwortlichen verarbeiten.
Laut der ISMS.online-Umfrage 2025 geben rund zwei Drittel der Unternehmen an, dass die Geschwindigkeit und das Ausmaß der regulatorischen Änderungen die Einhaltung der Vorschriften zunehmend erschweren.
Bei der Neugestaltung der Identitätsrichtlinien gemäß A.5.16 ist es hilfreich, sich folgende Fragen zu stellen: Welche Techniker an welchen Standorten können unter welchen Bedingungen auf welche Datenklassen zugreifen, und wie wird dies dokumentiert? Dies ist insbesondere dann relevant, wenn Kundenverträge oder lokale Gesetze vorschreiben, dass bestimmte Daten aus bestimmten Regionen niemals abgerufen werden dürfen oder dass der Zugriff auf namentlich genannte Personen mit spezifischen Berechtigungen beschränkt ist.
Die Einbeziehung Ihrer Datenschutz-, Rechts- und Sicherheitsteams zur Überprüfung dieser Fragen unter dem Gesichtspunkt der Identität kann spätere unangenehme Überraschungen verhindern. Sie hilft Ihnen außerdem, die Entwicklung einer theoretisch soliden Identitätsarchitektur zu vermeiden, die sich im Nachhinein als nicht mit den regulatorischen Gegebenheiten vereinbar erweist, insbesondere bei grenzüberschreitenden Diensten.
Entwurf eines mandantenfähigen Identitätsmanagementmodells
Die Entwicklung eines mandantenfähigen Identitätsmanagementmodells erfordert die Auswahl einer Architektur, eines Toolsets und von Fehlerbehandlungsmustern, die eindeutige Identitäten mit minimalen Berechtigungen für alle Kundenmandanten gewährleisten, ohne die Entwickler zu überfordern. Das Modell sollte durchdacht, dokumentiert und praktikabel sein, um mit dem Wachstum und den Veränderungen Ihres Managed Service Providers Schritt halten zu können.
Nachdem das Risikobild und die Verantwortlichkeiten geklärt sind, können Sie mit der Entwicklung eines mandantenfähigen Identitätsmodells beginnen, das sowohl praktikabel als auch mit A.5.16 konform ist. Hier legen Sie fest, wie Identitäten aus Ihrem eigenen Verzeichnis in die Mandanten Ihrer Kunden fließen, welche Tools im Zentrum Ihrer Umgebung stehen und wie Sie mit Ausnahmesituationen umgehen, ohne das gesamte Design zu gefährden.
Auswahl einer mandantenfähigen Identitätsarchitektur
Ihre Identitätsarchitektur sollte klarstellen, wo Identitäten gespeichert sind, wie sie Rollen in Kundenumgebungen übernehmen und wie einfach Sie den Zugriff in all diesen Umgebungen bei Personalwechseln entziehen können. Die meisten Managed Service Provider (MSPs) entscheiden sich letztendlich für ein Hub-and-Spoke-Modell, ein mandantenbasiertes Kontomodell oder eine Hybridlösung, die Elemente beider Modelle kombiniert.
Im Wesentlichen stehen Managed Service Provider (MSPs) drei Modellvarianten zur Auswahl. Im Hub-and-Spoke-Modell fungiert der eigene Identitätsanbieter als zentrale Plattform, und die Techniker nutzen Identitäten aus diesem Verzeichnis, um Rollen in verschiedenen Kundensystemen zu übernehmen. Im mandantenbasierten Modell verfügt jeder Kunde über eigene Benutzerkonten für seine Mitarbeiter, teilweise mit lokalen Verzeichnissen. Hybridmodelle kombinieren zentrale Steuerung für bestimmte Aspekte mit mandantenbasierter Isolation für andere.
Ein einfacher Vergleich kann bei der Entscheidungsfindung helfen:
Vorgehensweise | Hauptvorteil | Hauptrisiko
—|—|—
Hub-and-Spoke-Architektur | Zentralisierte Richtlinien und einfaches Offboarding | Größerer Wirkungsbereich für mehrere Mandanten bei einem Hub-Angriff
Pro Mandant | Stärkere Trennung der Kunden | Schwieriger zu verwalten und konsistent zu halten im großen Maßstab.
Hybrid | Vereint zentrale Steuerung mit lokalen Beschränkungen | Erfordert mehr Aufwand bei Planung und Dokumentation
Kurz gesagt: Hub-and-Spoke optimiert die zentrale Steuerung, mandantenbasierte Architekturen maximieren die Isolation, und Hybridmodelle bieten einen Ausgleich zwischen beiden – allerdings mit höherem Planungs- und Dokumentationsaufwand. Professionelle IT-Audit-Richtlinien, wie sie beispielsweise von ISACA und ähnlichen Organisationen veröffentlicht werden, betonen, dass es Prüfern weniger um das gewählte Modell geht, sondern vielmehr darum, dass dieses klar erläutert, seine risikomindernde Wirkung aufgezeigt und seine konsequente Anwendung nachgewiesen werden kann.
Ihre Wahl sollte von Ihrer Unternehmensgröße, den Erwartungen Ihrer Kunden, den von Ihnen unterstützten Plattformen und Ihrer Bereitschaft zur Komplexität abhängen. Unabhängig von der gewählten Architektur erwartet A.5.16, dass diese bewusst gewählt und dokumentiert wird. Sie sollten darlegen können, warum Sie sich für diese Architektur entschieden haben, wie sie die eindeutige und nachvollziehbare Identität gewährleistet und wie Lebenszyklusereignisse ablaufen. Die Dokumentation muss nicht ausführlich, aber verständlich sein.
Die richtigen Werkzeuge in den Mittelpunkt stellen
Die Integration der richtigen Tools in Ihr Modell gewährleistet eine durchgängige und verlässliche Datenkette von Geschäftsereignissen – Eintritt, Versetzung, Austritt und Neukundengewinnung – bis hin zu Konto-, Rollen- und Nachweisänderungen. Andernfalls wird die Identität schnell zu einem undurchsichtigen Gemisch aus Gewohnheiten und Ausnahmen, das sich im Falle einer Prüfung nur schwer verteidigen lässt.
Sobald Sie eine konzeptionelle Architektur haben, müssen Sie entscheiden, welche Tools die zentrale Datenquelle für Identität und Zugriff darstellen. Für einige Managed Service Provider (MSPs) ist dies der Corporate Identity Provider. Für andere kann es eine Identity-Governance-Plattform, eine Lösung für das Privileged Access Management oder sogar ein Ticketsystem sein, das als maßgebliche Quelle dafür dient, wer was angefordert und genehmigt hat.
Entscheidend ist, dass eine klare Kette von Geschäftsereignissen – Eintritt, Rollenwechsel oder Ausscheiden eines Mitarbeiters; Onboarding neuer Kunden; Vertragsänderungen – zu Identitätsänderungen in Ihren verschiedenen Systemen und Mandanten besteht. Wenn neue Rollen in Ihrem HR-System oder Ihrer Professional-Services-Plattform erstellt werden, müssen Sie wissen, wie diese Daten in Ihre Identitätsplattform, die Kundenmandanten und Ihre Nachweisdokumentation fließen.
Hier kann eine Informationssicherheitsmanagement-Plattform wie ISMS.online helfen. Durch die Verknüpfung Ihrer Richtlinien, Rollenkataloge, Diagramme und Genehmigungsprotokolle mit spezifischen Kontrollen wie A.5.16 erhalten Sie eine zentrale Anlaufstelle, um zu überprüfen, ob das von Ihnen entworfene Modell tatsächlich eingehalten wird, und um diese Verknüpfung auf Anfrage von Auditoren oder Kunden nachzuweisen.
Konstruktion für Ausfallsicherheit und Kontinuität
Ausfallsicheres Design und die Gewährleistung der Kontinuität bedeuten, das Verhalten von Identitäten zu planen, wenn wichtige Tools, Mitarbeiter oder Infrastrukturen ausfallen, um Kunden auch unter Stress zu schützen. Dies erfordert kontrollierte Notfallpläne und Wiederherstellungsverfahren, die den Vorgaben von A.5.16 entsprechen und diese nicht umgehen.
Kein Identitätsmodell ist vollständig, wenn es nur unter optimalen Bedingungen funktioniert. Sie müssen auch Situationen einplanen, in denen Ihr Identitätsanbieter nicht verfügbar ist, eine Schlüsselverwaltungsplattform ausfällt oder ein Techniker mit wichtigen Kenntnissen plötzlich fehlt. Solche Szenarien sind zwar unangenehm, doch sie zu ignorieren führt oft zu provisorischen Lösungen, die Ihre Kontrollmechanismen untergraben.
Ein robustes Design umfasst klar definierte Notfallzugriffswege, die den Grundsatz der minimalen Berechtigung wahren. Dies kann bedeuten, dass es wenige Notfallkonten mit sehr hohen Sicherheitsvorkehrungen und strengen Verfahren gibt oder dass vorab genehmigte Offline-Prozesse für spezifische Szenarien eingerichtet werden. Entscheidend ist, dass deren Existenz und Nutzung dokumentiert, überwacht und überprüft werden, um einen stillen Missbrauch im Laufe der Zeit zu verhindern.
Wenn man diese potenziellen Fehlerquellen frühzeitig erkennt und in sein Informationssicherheitsmanagementsystem integriert, lässt sich Kunden und Auditoren deutlich leichter erklären, wie man in einer Krise vorgehen würde, ohne die sorgfältig konzipierten Identitätskontrollen einfach zu umgehen. Das gibt dem eigenen Team außerdem die Sicherheit, auch unter Druck handeln zu können, ohne riskante Abkürzungen nehmen zu müssen.
Befreien Sie sich von einem Berg an Tabellenkalkulationen
Integrieren, erweitern und skalieren Sie Ihre Compliance, ohne dass es zu Problemen kommt. IO gibt Ihnen die Widerstandsfähigkeit und das Vertrauen, um sicher zu wachsen.
RBAC, Least-Privilege-Prinzip und Trennungsmuster für Administratorkonten
Rollenbasierte Zugriffskontrolle, das Prinzip der minimalen Berechtigungen und die klare Trennung zwischen Standard-, privilegierten und Notfallkonten machen Ihre übergeordnete Identitätsarchitektur zu einem konkreten, alltäglichen Verhalten, das die Auswirkungen von Fehlern auf Mandantensysteme begrenzt. Durch diese Vorgehensweise wird A.5.16 für Managed Service Provider (MSPs) zu einem lebendigen Steuerungsinstrument und nicht nur zu einer Richtlinie, die in der Schublade liegt.
Sobald Ihr übergeordnetes Modell klar ist, können Sie die Muster für den täglichen Zugriff detailliert ausarbeiten. Rollenbasierte Zugriffskontrolle, das Prinzip der minimalen Berechtigungen und die sorgfältige Trennung zwischen Standard-, privilegierten und Notfallkonten sind die Werkzeuge, mit denen die Prinzipien von A.5.16 in ein praktisches Design umgesetzt werden, das Entwickler befolgen und Auditoren testen können.
Erstellung eines MSP-weiten Rollenkatalogs
Ein unternehmensweiter Rollenkatalog sollte Ihnen eine kleine, klar definierte Menge an Rollen bieten, die plattform- und mandantenübergreifend konsistent Berechtigungen zugeordnet sind. So erhalten Techniker Zugriff aufgrund ihrer Aufgaben und nicht aufgrund ihrer persönlichen Erfahrung oder informeller Ausnahmen. Außerdem erleichtert dies die Erläuterung Ihres Modells für Nicht-Fachleute.
Ein Rollenkatalog ist einfach eine Liste definierter Rollen mit jeweils klarem Zweck und zugehörigen Berechtigungen. Bei einem Managed Service Provider (MSP) könnten typische Rollen beispielsweise First-Level-Support, Senior Engineer, Sicherheitsanalyst, Projektingenieur und Account Manager sein. Jede Rolle sollte so beschrieben werden, dass sie sowohl für Geschäfts- als auch für IT-Mitarbeiter verständlich ist, und Beispiele für die dazugehörigen Aufgaben enthalten.
Der Vorteil eines Zugriffskatalogs liegt darin, dass er einen standardisierten Ausgangspunkt bietet. Anstatt den Zugriff mandanten- und personenspezifisch festzulegen, wird er einmalig auf Rollenebene bestimmt. Anschließend werden diese Rollen den plattformspezifischen Berechtigungen in jeder Umgebung zugeordnet. Dadurch lässt sich wesentlich leichter nachweisen, dass der Zugriff an Verantwortlichkeiten und nicht an persönliche Beziehungen oder zufällige Vorkommnisse gebunden ist.
Wenn Sie einen solchen Rollenkatalog erstellen, empfiehlt es sich, klein anzufangen. Identifizieren Sie die wenigen Rollen, die den Großteil Ihrer Mitarbeiter abdecken, definieren Sie diese präzise, ordnen Sie sie ein oder zwei Hauptplattformen zu und verfeinern Sie die Liste anschließend. Ausnahmen können Sie dann als dokumentierte Varianten behandeln, anstatt für jeden Sonderfall neue Rollen zu erfinden. Im Laufe der Zeit können Sie weitere Rollen hinzufügen oder bestehende anpassen, wenn Ihre Dienstleistungen wachsen.
Trennung von Standard-, privilegierten und Notfallzugängen
Die Trennung von Standard-, privilegierten und Notfallzugriffen ermöglicht es Ihnen, unterschiedliche Kontroll-, Überwachungs- und Prüfzyklen für alltägliche Aufgaben, administrative Tätigkeiten und echte Notfälle anzuwenden. Eine klare Trennung hilft Technikern außerdem zu verstehen, welche Identität sie in welcher Situation verwenden sollten und mit welchem Prüfgrad sie rechnen müssen.
Bei vielen Managed Service Providern (MSPs) wird dieselbe Technikeridentität sowohl für die tägliche Arbeit als auch für privilegierte Aktionen in Kundenumgebungen verwendet. Das mag zwar praktisch erscheinen, führt aber zu unklaren Verantwortlichkeiten und erschwert die Implementierung zusätzlicher Sicherheitsmaßnahmen für sensible Vorgänge. A.5.16 und die zugehörigen Kontrollen fordern Sie auf, klarere Grenzen zu ziehen, um Kundenumgebungen effektiver zu schützen.
Ein praktisches Muster, das viele Managed Service Provider (MSPs) anwenden, sieht folgendermaßen aus:
- Standardidentitäten für die tägliche Arbeit und unterstützende Aufgaben mit geringem Risiko.
- Privilegierte Identitäten oder Rollen für administrative Aufgaben, idealerweise mit bedarfsgerechter Erhöhung der Berechtigungen.
- Notfallkonten sind ausschließlich für Notfälle reserviert und unterliegen verstärkten Schutz- und Überwachungsmaßnahmen.
Standardidentitäten bearbeiten Routine-Tickets und Änderungen mit geringem Risiko und werden über normale Protokollierung überwacht. Privilegierte Identitäten werden nur bei Bedarf verwendet, erhalten vorübergehend erhöhte Berechtigungen und unterliegen einer genaueren Überprüfung. Notfallkonten werden streng kontrolliert, nur selten und unter definierten Bedingungen genutzt und nach jeder Verwendung überprüft, um sicherzustellen, dass Notfälle nicht zu Hintertüren werden.
Testen, ob Ihr Design tatsächlich einen Explosionsradius enthält
Die Wirksamkeit Ihrer rollenbasierten Zugriffs- und Trennungsmechanismen lässt sich erst dann sicher beurteilen, wenn Sie deren Verhalten unter realistischen Fehlerszenarien, wie beispielsweise kompromittierten Geräten oder durchgesickerten Zugangsdaten, getestet haben. Ohne diese Tests verlassen Sie sich möglicherweise auf ein Design, das zwar auf dem Papier solide erscheint, aber in der Praxis kaum Schutz bietet.
Rollen und Trennungsmuster mögen in Diagrammen hervorragend aussehen, funktionieren aber unter Belastung schlecht. Um ein trügerisches Sicherheitsgefühl zu vermeiden, sollten Sie regelmäßig testen, ob Ihr Design die Auswirkungen eines kompromittierten Kontos oder eines Missbrauchsszenarios tatsächlich wie erwartet begrenzt. Nutzen Sie hierfür sowohl technische als auch organisatorische Übungen.
Dies könnte beispielsweise Planspiele umfassen, in denen hypothetische Vorfälle durchgespielt werden: Das Gerät eines Technikers wird gestohlen; ein Angreifer erlangt Zugriff auf einen Passwort-Tresor; ein privilegiertes Token wird gestohlen. Es könnte auch technische Simulationen beinhalten, bei denen mithilfe von Tools oder manuellen Überprüfungen ermittelt wird, auf welche Mandanten und Systeme eine bestimmte Identität zugreifen kann und welche Aktionen sie dort ausführen kann.
Ziel ist es nicht, Ihr Design um seiner selbst willen zu „zerstören“, sondern Schwachstellen aufzudecken, bevor ein Angreifer sie ausnutzt. Wenn Sie daraufhin Rollen, Berechtigungen oder Verhaltensmuster anpassen, dokumentieren Sie diese Änderungen und deren Gründe. Mit der Zeit liefert dies einen aussagekräftigen Beweis dafür, dass Sie Identität als dynamisches Steuerungssystem behandeln und nicht als statische Konfiguration, die am Tag der Zertifizierung eingefroren ist.
Beitritts-, Umzugs- und Auszugsprozesse sowie bedarfsgerechter Zugang für alle Mieter
Bei den Prozessen für Mieterwechsel, -versetzungen und Just-in-Time-Prozessen trifft Ihr Identitätsmodell auf alltägliche Veränderungen. Daher müssen sie sicherstellen, dass die Konten über alle Mieter hinweg mit der Realität übereinstimmen, ohne dabei unerträgliche Reibungsverluste zu verursachen. A.5.16 wird häufig danach beurteilt, wie gut diese Abläufe in der Praxis funktionieren, und nicht nur danach, wie sie in Richtlinien oder Diagrammen beschrieben sind.
Ein gut durchdachtes Identitätsmodell versagt, wenn es nicht an die sich ändernden Anforderungen von Mitarbeitern – wie Eintritt, Positionswechsel und Ausscheiden – angepasst werden kann. Für Managed Service Provider (MSPs) ist der Prozess von Eintritt, Versetzung und Ausscheiden der Punkt, an dem die theoretische Konzeption auf die komplexe Realität trifft: Personalfluktuation, organisatorische Veränderungen, Neukunden und dringende Projekte, die Mitarbeiter kurzfristig in neue Teams versetzen.
Entwurf robuster Joiner-Mover-Leaver-Flows
Robuste Prozesse für Beitritt, Umzug und Austritt basieren auf verlässlichen Geschäftsereignissen und werden konsistent in Identitätsänderungen in allen relevanten Mandanten umgesetzt, anstatt dass sich die Techniker um Ad-hoc-Aktualisierungen kümmern müssen. Das bedeutet, die Abläufe für Beitritt, Umzug und Austritt zu definieren und diese Schritte so weit wie möglich zu automatisieren und wiederholbar zu gestalten.
Ein robuster JML-Prozess beginnt mit der Verankerung von Identitätsänderungen in zuverlässigen Ereignissen. Neueinsteiger sollten durch die Personalabteilung oder vertragliche Einarbeitung, Versetzungen durch genehmigte Rollen- oder Verantwortungsänderungen und Austritte durch formale Austrittsprozesse oder Vertragsbeendigungen ausgelöst werden. Jeder Ereignistyp sollte klaren Aktionen in Ihren Systemen und in jedem Kundenmandanten zugeordnet sein, mit dem ein Entwickler oder ein Tool interagiert.
Eine einfache Möglichkeit, dies greifbar zu machen, besteht darin, für jede Phase eine kurze, wiederholbare Abfolge zu definieren:
Tischler
- Erstellen Sie Identitäten im Unternehmensverzeichnis.
- Weisen Sie Standardrollen und grundlegende Zugriffsrechte zu.
- Gewähren Sie Mietern, sofern die Verträge dies zulassen, einen individuellen Zugang.
- Genehmigungen erfassen und Gültigkeitsdaten protokollieren.
Umzug
- Überprüfen Sie die aktuellen Rollen und Zugriffsrechte der Mieter.
- Fügen Sie die erforderlichen Rollen hinzu und entfernen Sie die nicht mehr benötigten.
- Aktualisieren Sie Gruppenmitgliedschaften und Werkzeugberechtigungen.
- Genehmigungen und Begründungen für Änderungen protokollieren.
Abgänger
- Entziehen Sie umgehend sämtliche Zugriffsrechte für Mieter und Tools.
- Konten im Unternehmensverzeichnis deaktivieren oder entfernen.
- Aus privilegierten Gruppen und Administratorrollen entfernen.
- Fertigstellung bestätigen und Nachweise für die Prüfung aufbewahren.
Die Herausforderung bei Mandantenfähigkeit besteht darin, dass diese Schritte oft in verschiedenen Umgebungen und Tools wiederholt werden müssen. Die Automatisierung vorhersehbarer Vorgänge, wie z. B. Aktualisierungen von Gruppenmitgliedschaften oder Workflow-Genehmigungen, und die Beschränkung menschlicher Eingriffe auf Ausnahmefälle tragen zur Konsistenz bei, ohne die Teams zu überlasten oder auf das individuelle Gedächtnis angewiesen zu sein. Die Literatur zur Identitätsverwaltung, beispielsweise Leitlinien zum Identitätslebenszyklus und zu Verwaltungsmustern, betont diese durchgängige Vorgehensweise – Registrierung, Änderung und Widerruf –, die weitgehend mit den Anforderungen von A.5.16 übereinstimmt.
Nutzung von bedarfsgerechter Höhenverstellung ohne Verlangsamung der Ingenieure
Um die Just-in-Time-Höhenverstellung (JIT) zu nutzen, ohne die Ingenieure zu verlangsamen, müssen Höhenverstellpfade entworfen werden, die das Risiko durch verkleinerte Zeitfenster minimieren und gleichzeitig eine schnelle Reaktion ermöglichen. Werden die Ingenieure in den Entwurfsprozess einbezogen, kann JIT als normaler Arbeitsablauf und nicht als Hindernis wahrgenommen werden, das es zu umgehen gilt.
Für Ingenieure, die permanente Administratorrechte gewohnt sind, kann der bedarfsgerechte Zugriff eine zusätzliche Belastung darstellen. Schlecht umgesetzt, verlangsamt er die Reaktionszeiten und fördert unkonventionelle Vorgehensweisen. Richtig eingesetzt, kann er das Risiko deutlich reduzieren und gleichzeitig einen reibungslosen Arbeitsablauf ermöglichen.
In der Praxis bedeutet JIT für Managed Service Provider (MSPs), dass Techniker die meiste Zeit mit Standardzugriff arbeiten und nur für bestimmte Aufgaben, die dies tatsächlich erfordern, eine temporäre Rechteerweiterung beantragen. Diese Anträge können automatisch durch Tickets, Änderungen oder Incident-Workflows ausgelöst werden und je nach Risiko der Maßnahme Genehmigungen beinhalten. Die Rechteerweiterung ist zeitlich begrenzt und wird protokolliert. Anschließend wird der Zugriff ohne manuelle Aufräumarbeiten wieder auf den Normalzustand zurückgesetzt.
Damit dies funktioniert, muss der Prozess gemeinsam mit den Entwicklern gestaltet werden, nicht nur für sie. Dazu gehört die Wahl sinnvoller Standardbearbeitungsdauern, das Vermeiden unnötiger Genehmigungen für Aufgaben mit geringem Risiko und ein schneller, vertrauter Anfrageprozess. Wenn der Prozess klar mit Ihrer Identity-Governance-Strategie verknüpft ist und die Kunden seinen Wert erkennen, lässt sich leichter kulturelle Akzeptanz schaffen und Umgehungslösungen vermeiden.
Automatisieren Sie, was möglich ist, und überprüfen Sie, was unbedingt überprüft werden muss.
Durch die Automatisierung möglicher Prozesse und die Überprüfung notwendiger Vorgänge können Sie häufige, risikoarme Identitätsänderungen in großem Umfang bewältigen und gleichzeitig menschliches Urteilsvermögen für risikoreichere oder ungewöhnliche Fälle reservieren. A.5.16 lässt sich leichter nachweisen, wenn routinemäßige Schritte bei Eintritt, Versetzung und Austritt sowie Just-in-Time-Maßnahmen konsistent, gut protokolliert und wiederholbar sind.
Nicht jeder Aspekt von JML und JIT kann oder sollte automatisiert werden. Häufige Änderungen mit geringem Risiko – wie das Hinzufügen einer Standardrolle für einen neuen Entwickler oder die Aktualisierung von Gruppenzugehörigkeiten – eignen sich gut für die Automatisierung, insbesondere in Multi-Tenant-Systemen, wo sich Fehler schnell ausbreiten können. Gleiches gilt für routinemäßige Deaktivierungsschritte, die zuverlässig von HR- oder Vertragssystemen ausgelöst werden können.
Ungewöhnliche Zugriffsanfragen, Ausnahmen zwischen Mandanten und die Nutzung von Notfallfunktionen sollten hingegen stets einer manuellen Prüfung unterzogen werden. Hier ist Urteilsvermögen gefragt, und es ist wichtig nachzuweisen, dass jemand das Risiko abgewogen und eine bewusste Entscheidung getroffen hat, anstatt lediglich eine formale Prüfung durchzuführen.
Der regelmäßige Abgleich zwischen den Annahmen Ihrer Identitätssysteme, den Daten Ihrer Personal- und Vertragsunterlagen und den tatsächlichen Gegebenheiten in jedem Kundenmandanten ist der letzte Schritt. Wenn Sie Diskrepanzen feststellen – beispielsweise inaktive Konten, verbliebene Berechtigungen oder nicht dokumentierte Identitäten –, betrachten Sie diese als Lernchance. Beheben Sie das jeweilige Problem und überlegen Sie anschließend, wie Sie Ihre Prozesse oder Automatisierungen anpassen können, um ähnliche Lücken künftig zu vermeiden. Dieser Abgleich ist ein starker Beleg dafür, dass Sie die Anforderungen des Lebenszyklus gemäß A.5.16 erfüllen und nicht nur die Dokumentationspflichten.
Wenn Sie bereits jetzt unter dem Druck stehen, die Zutritts-, Umzugs- und Austrittsprozesse sowie den Just-in-Time-Zugriff für viele Mandanten mithilfe von Tabellenkalkulationen und dem Gedächtnis aufeinander abzustimmen, lohnt es sich möglicherweise zu prüfen, wie eine strukturierte Informationssicherheitsmanagement-Plattform einen Teil dieser Last übernehmen und dazu beitragen könnte, A.5.16 in eine nachhaltigere, lebendige Steuerung anstatt in eine Reihe von Ad-hoc-Lösungen zu verwandeln.
Verwalten Sie Ihre gesamte Compliance an einem Ort
ISMS.online unterstützt über 100 Standards und Vorschriften und bietet Ihnen eine einzige Plattform für alle Ihre Compliance-Anforderungen.
Nachweis der Einhaltung von A.5.16: Dokumentation, Nachweise und Audits
Der Nachweis der A.5.16-Konformität bedeutet, jederzeit darlegen zu können, wie Sie die Verwaltung von Identitäten planen, wie diese sich in der Praxis verhalten und wie Sie aus Audits und Vorfällen lernen. Für Managed Service Provider (MSPs) muss dieser Nachweis sowohl Mandantenumgebungen als auch interne Systeme abdecken, um Kunden und Auditoren auch unter Druck Sicherheit zu geben.
Design und Betrieb machen nur zwei Drittel des Ganzen aus. A.5.16 setzt außerdem voraus, dass Sie auf Anfrage nachweisen können, wie Ihr Identitätsmanagement tatsächlich funktioniert. Das bedeutet, die richtigen Dokumente bereitzuhalten, diese stets an die Praxis anzupassen und alltägliche Aktivitäten in Nachweise umzuwandeln, die Sie Prüfern, Kunden und Aufsichtsbehörden ohne hektische Last-Minute-Aktivitäten vorlegen können.
Der Mindestdokumentensatz für A.5.16
Die Mindestdokumentation gemäß A.5.16 besteht aus wenigen, klaren und gut gepflegten Richtlinien und Verfahren, die Ihre Identitätsziele und Verantwortlichkeiten beschreiben. Diese Dokumente müssen die Realität des heutigen Multi-Tenant-Betriebs widerspiegeln und dürfen kein theoretisches Modell darstellen, das nur für Audits relevant ist.
Sie benötigen keine Hunderte von Seiten, aber ein kurzes Dokument, das Ihre Absicht klar zum Ausdruck bringt. Dies umfasst in der Regel mindestens eine Richtlinie zum Identitätsmanagement, einen Standard für Rollen und Zugriffsrechte, Verfahren für Eintritts-, Versetzungs- und Austrittsprozesse sowie Just-in-Time-Prozesse und einen Standard für Administrator- und Notfallkonten.
Diese Richtlinien sollten nicht nur beschreiben, was Sie tun, sondern auch, wer es tut und wie Sie die Durchführung sicherstellen. Sie sollten mit Ihrer Risikobewertung und anderen relevanten Richtlinien wie Zugriffskontrolle, Lieferantenmanagement und Geschäftskontinuität übereinstimmen. Für Managed Service Provider (MSPs) sollten sie zudem explizit Aspekte der Mandantenfähigkeit abdecken: delegierte Administratorrechte, mandantenübergreifende Rollen, Servicekonten in Kundenumgebungen und ältere gemeinsam genutzte Konten.
Die Erstellung dieser Dokumente in leicht verständlicher Sprache zahlt sich schnell aus. Sie werden zu nützlichen Nachschlagewerken für Ingenieure und Betriebspersonal und sind nicht nur Formalitäten für Auditoren. ISMS.online unterstützt Sie dabei, diese Dokumente mit Kontrollen wie A.5.16, Risikoaufzeichnungen und Verbesserungsmaßnahmen zu verknüpfen, sodass sie stets aktuell sind und nicht erst kurz vor dem nächsten Audit aktualisiert werden müssen.
Aufbau eines Beweisregisters, das unter Druck funktioniert
Der Aufbau eines unter Zeitdruck funktionierenden Nachweisregisters bedeutet, jede Anforderung gemäß A.5.16 spezifischen, wiederholbaren und schnell erstellbaren Artefakten zuzuordnen. Ziel ist es, die Wiederverwendung von Routinearbeiten als Prüfnachweise deutlich zu vereinfachen, anstatt jede Anfrage in hektische, reaktive Prozesse zu verwandeln.
Wenn die Audit-Saison beginnt oder ein wichtiger potenzieller Kunde Nachweise verlangt, ist die Woche vor dem Gespräch der denkbar ungünstigste Zeitpunkt, um Ihre Belege zusammenzutragen. Stattdessen empfiehlt es sich, ein einfaches Nachweisregister anzulegen, das jede Anforderung in A.5.16 spezifischen, wiederholbaren Artefakten zuordnet: Berichten, Konfigurationsauszügen, Ticketbeispielen, Zugriffsprüfungsprotokollen und Logs, die Sie zuverlässig erstellen können.
Beispielsweise könnten Sie die Anforderung eindeutiger Identitäten mit Exporten Ihres Identitätsanbieters verknüpfen, die Namenskonventionen und Kontotypen sowie Verfahren zur Erstellung neuer Konten aufzeigen. Sie könnten Anforderungen an den Lebenszyklus mit Änderungsdatensätzen verknüpfen, die dokumentieren, wie ein neuer Mitarbeiter in mehreren Mandanten aufgenommen und ein Mitarbeiter entfernt wurde, kombiniert mit einem Export des Identitätsanbieters für denselben Zeitraum. Sie könnten Erwartungen an regelmäßige Überprüfungen mit dokumentierten Zugriffsprüfungskampagnen und deren Ergebnissen verknüpfen.
Durch die strukturierte Führung dieses Registers verwandeln Sie Ihre tägliche Arbeit in Material, das sich schnell zu einem schlüssigen Nachweis zusammenstellen lässt. Wenn Sie gefragt werden: „Woher wissen Sie, dass Ihre Identitäten ordnungsgemäß verwaltet werden?“, müssen Sie nicht lange suchen, sondern können auf einen Satz vereinbarter, leicht zu erstellender Elemente zurückgreifen. Jeder Managed Service Provider (MSP) kann ein solches Register erstellen; eine dedizierte ISMS-Plattform ist lediglich eine Möglichkeit, die Datenstruktur zu verwalten und sichtbar zu halten.
Nutzung von Audits und Vorfällen zur Stärkung Ihrer Story
Die Nutzung von Audits und Vorfallsmeldungen zur Stärkung Ihrer A.5.16-Architektur bedeutet, diese als strukturierte Feedbackschleifen und nicht als einmalige Compliance-Maßnahmen zu behandeln. Jede festgestellte Störung oder jeder Beinahe-Fehler bietet die Chance, Ihr Corporate Design, Ihre Prozesse und Ihre Nachweise so zu verbessern, dass Sie dies später demonstrieren können.
Interne und externe Audits können sich zwar konfrontativ anfühlen, bieten aber auch die Möglichkeit, Ihr Identitätsmanagement zu überprüfen und zu verbessern. Planen Sie ein internes Audit und wählen Sie gezielt eine Mischung aus Mandanten, Identitätstypen und Rollen aus. Achten Sie auf Übereinstimmungen zwischen Ihrem Konzept und den Ergebnissen und erfassen Sie Stärken und Schwächen in einer Form, die Sie in Ihre Risikobewertungen und Richtlinien einfließen lassen können.
Wenn ein Vorfall die Identität betrifft – sei es ein tatsächlicher Verstoß, ein Beinahe-Vorfall oder einfach eine missverständliche Zugriffsanfrage –, sollten Sie sich im Nachhinein fragen, was er über Ihre Sicherheitsarchitektur und -prozesse aussagt. Hat Ihre Dokumentation die Untersuchung unterstützt oder behindert? Waren Protokolle verfügbar und nützlich? War den Beteiligten klar, welche Identitäten betroffen waren und welche nicht?
Die Erfassung der Ergebnisse dieser Überprüfungen und deren Rückführung in Ihr Informationssicherheitsmanagementsystem schließt den Kreislauf. Sie zeigt Prüfern und Kunden, dass Sie A.5.16 als dynamische Kontrollmaßnahme behandeln, und gibt Ihrer Führungsebene die Gewissheit, dass Identitätsmanagement nicht nur ein einmaliges Projekt, sondern eine kontinuierliche Praxis ist, die sich mit zunehmendem Lernprozess verbessert.
Buchen Sie noch heute eine Demo mit ISMS.online
ISMS.online unterstützt Sie dabei, eine komplexe Identitätslandschaft mit mehreren Mandanten in ein kohärentes, auditfähiges System zu überführen, das die Anforderungen der ISO 27001 A.5.16 erfüllt und Ihren Kunden die Gewissheit gibt, dass Sie den Zugriff auf Ihre Identitäten ernst nehmen. Indem Sie Ihre Richtlinien, Vorbilder, Prozesse für neue Mitarbeiter, Personalwechsel und bedarfsgerechte Änderungen sowie Nachweise in einem strukturierten Bereich zusammenführen, erkennen Sie deutlich leichter Ihre Stärken, Ihre Schwachstellen und die Auswirkungen von Änderungen in einem Bereich auf andere.
Welchen Vorteil Ihnen die Zentralisierung Ihrer Identitätsnachweise bringt
Die zentrale Speicherung identitätsbezogener Nachweise in einer einzigen, strukturierten Umgebung ermöglicht Ihnen einen kontinuierlich aktuellen Überblick darüber, wie die Anforderungen von A.5.16 in Ihrem gesamten Unternehmen und bei Ihren Kunden erfüllt werden. So vermeiden Sie, sich im Vorfeld von Audits oder Kundenbesprechungen auf die Suche nach einzelnen Dokumenten verlassen zu müssen. Erfahrungen aus der Praxis von Informationssicherheitsmanagementsystemen (ISMS) und Identitätsgovernance, die sich in unabhängigen Integrationsleitfäden wie Branchen-Whitepapers zur Verknüpfung von ISMS und Identitätskontrollen widerspiegeln, legen nahe, dass ein zentrales Kontroll- und Nachweismanagement die Transparenz des Kontrollstatus im Zeitverlauf deutlich verbessern kann.
Wenn die Identitätsverwaltung über Tabellenkalkulationen, Ticketkommentare und das individuelle Gedächtnis verstreut ist, wird jede Prüfung oder Due-Diligence-Anfrage zu einem Mini-Projekt. Durch die Zentralisierung Ihres Kontrolldesigns und der Nachweise schaffen Sie eine zentrale Plattform, auf der Ihr Team sehen kann, wie Identitäten verwaltet werden sollen, welche Kontrollen dies unterstützen und welche Datensätze dies belegen.
Das erleichtert die Beantwortung von Kundenfragen wie „Wer in Ihrem Unternehmen hat Zugriff auf unsere Mieter?“ erheblich und bietet mehr als nur vage Zusicherungen. Sie können auf definierte Rollen, dokumentierte Prozesse und tatsächliche Zugriffsprüfungsergebnisse verweisen. Zudem reduziert es Ihre Abhängigkeit von wenigen Personen, die „alles im Griff haben“, was insbesondere bei Unternehmenswachstum und Personalwechseln oder -ausscheiden von entscheidender Bedeutung ist.
Aus operativer Sicht reduziert die Zentralisierung Doppelarbeit und Verwirrung. Bei Änderungen Ihrer Richtlinien aktualisieren Sie diese einmalig und verknüpfen sie mit den relevanten Kontrollen, Aufgaben und Datensätzen. Nach Abschluss einer Überprüfung oder dem Beheben eines Prüfungsbefundes werden die entsprechenden Nachweise kontextbezogen hinterlegt. So entsteht mit der Zeit eine umfassende und übersichtliche Dokumentation darüber, wie Sie das Identitätsmanagement für Ihr eigenes Unternehmen und die von Ihnen betreuten Mieter optimiert haben.
Ein risikoarmer Einstieg in ISMS.online
Mit einem kleinen, fokussierten Ausschnitt aus A.5.16 in ISMS.online können Sie den Nutzen der Zentralisierung nachweisen, ohne gleich am ersten Tag eine umfassende Prozessänderung vornehmen zu müssen. Sie können mit einer Identitätsrichtlinie und einem einzigen Prozess für Eintritt, Versetzung und Austritt beginnen und diesen dann erweitern, sobald Ihr Team sich damit vertraut gemacht hat und die praktischen Vorteile erkennt.
Wenn Sie bereits unter der Belastung durch die Verwaltung von Mandantenidentitäten ohne ein strukturiertes Informationssicherheitsmanagementsystem leiden, mag die Vorstellung, eine weitere Plattform hinzuzufügen, abschreckend wirken. Tatsächlich ist der Aufwand jedoch viel geringer als erwartet. Viele Managed Service Provider (MSPs) beginnen damit, einen kleinen, fokussierten Teil von A.5.16 in ISMS.online zu integrieren und aus diesen Erfahrungen zu lernen, bevor sie weitere Kontrollen und Frameworks einführen.
Sie könnten beispielsweise mit Ihrer Identitätsrichtlinie, Ihrem Rollenkatalog und einem einzelnen Prozess für Eintritt, Versetzung und Austritt beginnen, diese mit A.5.16 und den zugehörigen Steuerelementen verknüpfen und einige aktuelle Nachweise hinzufügen. Anschließend können Sie, sobald Sie mehr Erfahrung gesammelt haben, mit der Planung von Überprüfungen, der Zuweisung von Verbesserungsaufgaben und der Abbildung weiterer Teile Ihres Identitätsmodells im System experimentieren.
Ein kurzes Gespräch mit dem ISMS.online-Team hilft Ihnen zu entscheiden, ob dieser Ansatz zu Ihrer Unternehmenskultur, Ihrem Umfang und Ihren bestehenden Tools passt. Sie erfahren, wie andere Managed Service Provider (MSPs) die Plattform zur Abbildung von Mandantenidentitätsmodellen genutzt haben, wie Auditoren typischerweise reagieren und wie ein realistischer Fahrplan aussieht. Entscheiden Sie sich für ISMS.online, wenn Sie Wert auf kontrolliertes, nachvollziehbares und erklärbares Mandantenidentitätsmanagement legen. Wenn Sie gegenüber Kunden, Auditoren und Aufsichtsbehörden glaubwürdige Zusicherungen gewährleisten möchten, ist der nächste Schritt leicht.
KontaktHäufig gestellte Fragen (FAQ)
Wie genau verändert ISO 27001:2022 A.5.16 die Art und Weise, wie ein Managed Service Provider (MSP) Identitäten in Kunden-Tenants handhaben muss?
ISO 27001:2022 A.5.16 führt Sie von der bloßen Kenntnis des Zugriffsrechts hin zur jederzeitigen, präzisen Nachvollziehbarkeit der Zugriffsrechte aller Kunden – aus welchem Grund und für welchen Zeitraum. Für Managed Service Provider umfasst dies sowohl die eigene Unternehmensinfrastruktur als auch alle delegierten oder eingebetteten Identitäten in Kundenumgebungen.
Was bedeutet „keine anonymen Hände“ in einem Multi-Tenant-MSP?
A.5.16 setzt voraus, dass Sie Identität als verwaltetes Gut und nicht als eine verstreute Menge von Anmeldedaten behandeln:
- Jede menschliche und nicht-menschliche Identität, die einen Mieter erreichen kann, ist aufgelistet, im Besitz und gerechtfertigt.
- Jede Identität ist an eine Rolle, Vertrag oder Dienstleistungnicht etwa ein vager „Admin“-Zugang.
- Änderungen im Zeitverlauf – Onboarding, Projektzugriff, Eskalation von Vorfällen, Offboarding – folgen definierte Schritte.
- Genehmigungen, Überprüfungen und Löschungen sind protokolliert und probenfähig Monate später.
Diese Disziplin muss mehrere Ebenen durchdringen:
- Partner-/delegierte Administratorrollen in Hyperscalern.
- Legacy-Direktadministratorkonten in älteren Mandanten.
- Servicekonten für RMM, Backup, Monitoring und Sicherheitstools.
- Notfallidentitäten für die Aufrechterhaltung des Betriebs oder die Bewältigung von Zwischenfällen.
Aus Käufer- oder Auditorensicht stellt ein vom Managed Service Provider (MSP) kontrollierter Administrationspfad heutzutage eine bedeutende Angriffsfläche dar. Wenn Sie einen bestimmten Techniker oder eine bestimmte Serviceidentität identifizieren, deren Standort, Rollen in den einzelnen Mandanten und die Integration von Genehmigungen und Prüfungen in Ihr Informationssicherheitsmanagementsystem (ISMS) aufzeigen können, wird A.5.16 nicht länger zu einer bloßen Klausel, sondern zu einem Grund für Vertrauen. ISMS.online unterstützt Sie beim Aufbau dieser transparenten Dokumentation, indem es Richtlinien, Diagramme, Risikodatensätze und Nachweise aus dem Lebenszyklus direkt mit den Kontrollen verknüpft, sodass Ihre Aussagen und Ihr Handeln stets übereinstimmen.
Wie kann ein Managed Service Provider (MSP) eine mandantenfähige Identitätsarchitektur entwerfen, die den Anforderungen von A.5.16 und der unternehmensweiten Due-Diligence-Prüfung standhält?
Eine mandantenfähige Identitätsarchitektur, die kritischen Prüfungen standhält, bietet Ihnen eine kleine Menge standardisierter Muster für den Zugriff und die Nutzung Ihrer Mitarbeiter und Tools in jedem Mandanten, inklusive klarer Problembegrenzung. A.5.16 schreibt keine bestimmte Technologie vor; es fragt lediglich, ob Ihr Muster bewusst gewählt, dokumentiert und wiederholbar ist.
Welche Entscheidungen zur Identitätsarchitektur sollten Sie einmalig festlegen?
Sie reduzieren Risiken und den Aufwand für Audits, indem Sie aufhören, die Grundlagen von Fall zu Fall zu diskutieren und stattdessen einige Punkte als Hausregeln festlegen:
- Wo Identitäten beheimatet sind:
Entscheiden Sie, ob die Entwicklerkonten zentral verwaltet werden (z. B. in Entra ID) und Rollen in Mandanten übernehmen, ob sie innerhalb jedes Mandanten nach strengen Regeln erstellt werden oder ob ein Hybridmodell verwendet wird. Dokumentieren Sie Ihre Wahl und halten Sie sich daran.
- Welches System ist die „Quelle der Wahrheit“ für Veränderungen?
Wählen Sie ein zentrales Master-System (HR, ITSM, IdP, Governance-Tool) für alle Ereignisse (Eintritt, Versetzung, Austritt) und stellen Sie sicher, dass alle weiteren Änderungen – einschließlich des Mandantenzugriffs – automatisch übernommen werden. A.5.16 ist erfüllt, wenn Sie ein eindeutiges Signal nachweisen können, das alle Zugriffsänderungen steuert.
- Zulässige Zugangswege zu Mietern:
Beschränken Sie sich auf eine kurze Liste: delegierte Administratorgruppen, Bastion-Zugriff, Just-in-Time-Berechtigungserhöhung, privilegierte Arbeitsstationen usw. Nicht unterstützte Einzellösungen bergen oft das Risiko von Überraschungen und Problemen bei Audits.
- Geplante Glasbruch- und Ausfallmodi:
Definieren Sie, was passiert, wenn Ihr Identitätsanbieter (IdP), Ihr PAM-System oder die Steuerungsebene eines Clients ausfällt. Zeitlich begrenzter, protokollierter Notfallzugriff, der an Tickets gebunden ist, lässt sich deutlich leichter rechtfertigen als ein auswendig gelerntes globales Administratorpasswort.
Eine einfache Visualisierung, die „MSP-Identitätsebene → Zugriffsmuster → Mandantenebenen“ darstellt, ist bei einer Due-Diligence-Prüfung oft hilfreicher als eine zehnseitige Richtlinie. Wenn dieses Diagramm, die zugehörigen Richtlinien und Risikobewertungen in ISMS.online zusammengeführt und mit A.5.16 verknüpft sind, erstellen Sie nicht nur ein Dokument für ein Audit, sondern pflegen ein dynamisches Design, in das sich neue Entwickler, neue Mandanten und neue Plattformen ohne Improvisation integrieren lassen.
Wie sieht eine strenge rollenbasierte Zugriffskontrolle und das Prinzip der minimalen Berechtigungen für MSP-Ingenieure bei einer Vielzahl von Kunden aus?
Für einen Managed Service Provider (MSP) bedeutet das Prinzip der glaubwürdigen minimalen Privilegien, dass die Rechte jedes Technikers in jedem Mieter gleichberechtigt sind. gegenwärtiger Ausdruck ihrer RolleEs geht nicht um eine detaillierte Auflistung aller Vorfälle und Gefälligkeiten, die sie je bearbeitet haben. A.5.16 lässt sich deutlich leichter beweisen, wenn die Rechte einem klaren Modell folgen und die Erhebung eindeutig die Ausnahme darstellt.
Wie kann man RBAC so strukturieren, dass es auch unter Druck verteidigt werden kann?
Anbieter, die Kundensicherheitsfragebögen ohne Panik beantworten, weisen in der Regel einige gemeinsame Merkmale auf:
- Ein straff geführter Stellenkatalog:
Statt Dutzenden von „fast identischen“ Rollen definieren sie ein fokussiertes Set – zum Beispiel Service Desk, Senior Engineer, Security Specialist, Project Engineer, Duty Manager – und ordnen jede Rolle den Rechten pro Plattform und pro Mandantenstufe zu (z. B. hohe Regulierung vs. Standard).
- Strikte Trennung von normaler und privilegierter Arbeit:
Ingenieure nutzen für alltägliche Aufgaben eine einzige Identität und erhöhen entweder deren Berechtigungen oder wechseln für risikoreiche Änderungen zu einem gehärteten Konto. Multifaktor-Authentifizierung und Protokollierung sind bei der Erhöhung der Berechtigungen unerlässlich.
- Mieterspezifische Abgrenzung:
Gruppen und Rollen spiegeln wider, was tatsächlich verkauft und mit jedem Kunden vereinbart wurde. Die Position eines leitenden Ingenieurs berechtigt nicht automatisch zu weitreichenden Rechten in jedem Mieter.
- Sichtbare, zeitlich begrenzte Ausnahmen:
Weitreichende, mieterübergreifende oder Notfallrollen existieren nur für klar definierte Szenarien wie die Reaktion auf Vorfälle, mit expliziten Verantwortlichen, Ablaufdaten und Nachweisen zur Überprüfung.
Ein einfacher, aber effektiver Test besteht darin, einen erfahrenen Ingenieur zu befragen: „Wenn diese Identität heute kompromittiert würde, welche Mandanten wären betroffen und wie schwerwiegend?“ Können Sie diese Frage nicht innerhalb weniger Minuten anhand Ihrer Systeme beantworten, ist Ihr RBAC-Modell anfälliger als angenommen. Die zentrale Speicherung von Rollendefinitionen, Zuordnungen und Zugriffsprüfungsnachweisen in ISMS.online ermöglicht es Ihnen, dieses Modell an einem Ort zu optimieren und Auditoren sowie Kunden zu zeigen, dass Ihr Risiko sinkt und nicht weiter steigt.
Wie kann ein Managed Service Provider (MSP) den zuverlässigen Zugriff für neue, wechselnde und ausscheidende Mitarbeiter sowie die bedarfsgerechte Verfügbarkeit gewährleisten, wenn die Mitarbeiter für Dutzende von Mietern tätig sind?
Wenn Personen eintreten, ihre Rolle wechseln oder ausscheiden, sollten sich die Zugriffsrechte aller betroffenen Mieter auf vorhersehbare Weise ändern – nicht durch willkürliche Änderungen, die sechs Monate später niemand mehr nachvollziehen kann. A.5.16 konzentriert sich weniger auf spezifische Tools, sondern vielmehr darauf, ob Identitätsänderungen definierten, wiederholbaren Abläufen folgen, die Spuren hinterlassen.
Managed Service Provider (MSPs), die keine Angst vor Stichproben bei Zugriffsänderungen haben, haben die Realität in der Regel auf einige wenige, verlässliche Gewohnheiten vereinfacht:
- Beginnen wir mit einer Veranstaltung mit nur einer Person:
Erfassen Sie Neueinstellungen, interne Versetzungen, Beförderungen, Vertragsänderungen und Austritte einmalig in der Personalabteilung oder Ihrem ITSM-Tool und lassen Sie diese Informationen dann alle nachfolgenden Identitätsänderungen steuern – Kontoerstellung, Gruppenzugehörigkeit, Mandantenzugriff und Deaktivierung.
- Standardisieren Sie wiederkehrende Zugriffsaktionen:
Die Einbindung von Ingenieuren in Mandantengruppen, die Änderung der Zuständigkeiten bestimmter Teams oder der Entzug des Zugriffs von Auftragnehmern auf gemeinsam genutzte Tools folgen einfachen Verfahren und basieren nicht auf dem Gedächtnis. Diese Verfahren legen fest, wer was in welchem Zeitraum genehmigt und welche Nachweise aufbewahrt werden.
- Automatisieren Sie die Routine, behalten Sie aber das menschliche Urteilsvermögen hinsichtlich des Risikos bei:
Bei wiederkehrenden Abläufen – wie dem Hinzufügen einer Standardrolle zu zehn Mandanten oder dem Entfernen einer Identität aus gemeinsam genutzten Tools – funktioniert die Automatisierung gut, solange Protokolle erstellt werden, auf die man verweisen kann. Außergewöhnliche Änderungen, wie beispielsweise ungewöhnlich weitreichende Rechte in einem regulierten Mandanten, erfordern weiterhin eine explizite Genehmigung und protokollierte Validierung.
- Behandeln Sie die JIT-Elevation als kontrolliertes Ereignis, nicht als Gefallen:
Wenn Ingenieure erweiterte Berechtigungen benötigen, beantragen sie diese für einen definierten Zeitraum, der mit einem Ticket verknüpft ist. Gewährung, Beginn und Ende der Rechteerweiterung sind allesamt Einträge, die Sie später vorzeigen können.
Ihre Teammitglieder akzeptieren diese Kontrollmaßnahmen oft eher, wenn sie erkennen, dass sie nicht nur für Auditoren relevant sind: Richtig umgesetzt, bedeuten sie weniger Nachhaken, weniger manuelle Schritte und weniger unangenehme Gespräche über vergessene Rechte. Die Verwendung von ISMS.online zur Zuordnung von JML- und JIT-Prozessen zu realen Tickets, HR-Ereignissen und der Kontrollmaßnahme A.5.16 erleichtert es Ihnen erheblich, sowohl Ihrer Führungsebene als auch Ihren Kunden zu verdeutlichen, dass das Identitätsrisikomanagement fester Bestandteil Ihres täglichen Geschäftsbetriebs ist und nicht nur eine jährliche Checkliste darstellt.
Welche Identitätsnachweise geben Kunden und Prüfern tatsächlich die Gewissheit, dass ein Managed Service Provider (MSP) die Anforderungen von A.5.16 mandantenübergreifend erfüllt?
Prüfer und Unternehmenskäufer erwarten selten Perfektion, aber sie erwarten, dass Ihre Geschäftsprozesse und Ihre Aufzeichnungen übereinstimmen. Der beste Identitätsnachweis bezieht sich in der Regel eher auf Folgendes: Kohärenz als Volumen.
Welche A.5.16-Artefakte fördern Vertrauen, anstatt die Menschen mit Details zu überfordern?
Für einen Multi-Tenant-MSP enthält ein überzeugender Nachweis oft folgende Elemente:
- Richtlinien- und Verfahrensdokumente: Verfasst in einfacher Sprache, wobei externe Mandanten, die wichtigsten unterstützten Plattformen und die Funktionsweise von Beitritts-, Umzugs- und Austrittsprozessen, Rollenzuweisung und erweiterten Zugriffsrechten explizit erwähnt werden.
- Ein aktueller Rollenkatalog und seine Zuordnungen: die zeigen, wie interne Rollen in spezifische Rechte in Systemen wie Microsoft 365 Delegated Admin, RMM, Backup, Sicherheitstools und On-Premise-Infrastruktur übersetzt werden.
- Eine kleine Anzahl realer JML-Beispiele: Hier können Sie Onboarding, Änderungen und Offboarding anzeigen, einschließlich hinzugefügter oder entfernter Mandantenzugriffe und erfasster Genehmigungen.
- Protokolle aus geplanten Zugriffsüberprüfungen: – beispielsweise vierteljährlich oder halbjährlich – eine Liste, welche MSP-Identitäten die einzelnen Mandanten erreichen können, was sich seit der letzten Überprüfung geändert hat und welche Korrekturmaßnahmen Sie ergriffen haben.
- Änderungs- und Vorfallprotokolle: Nachverfolgung von Zugriffsereignissen mit höherem Risiko von der Anfrage über die Genehmigung bis zur Implementierung, gegebenenfalls mit Test- oder Rollback-Vermerken.
- Nachweise für Lernprozesse im Laufe der Zeit: – Ergebnisse interner Audits, Penetrationstests oder Vorfälle, bei denen der Zugriff eine Rolle spielte, sowie die protokollierten und abgeschlossenen Folgemaßnahmen.
Die Zusammenstellung dieser Informationen aus persönlichen E-Mails, exportierten Tabellen und verstreuten Dateien bereitet den meisten Managed Service Providern (MSPs) Kopfzerbrechen. Ein strukturiertes Informationssicherheits-Managementsystem (ISMS) mit der Verknüpfung jedes Dokuments mit A.5.16 ermöglicht es Ihnen, komplexe Fragen souverän und konsistent zu beantworten. Mit ISMS.online kann Ihr Team die Dokumentation einmalig vorbereiten und die gleiche, kontrollierte Ansicht anschließend für ISO-Audits, wichtige Ausschreibungen und Fragebögen von Versicherern wiederverwenden, anstatt jedes Mal die Nachweise neu zusammenzustellen.
Wie kann ein Managed Service Provider (MSP) ISMS.online nutzen, um A.5.16 in eine wiederholbare Multi-Tenant-Identitätslösung anstatt in ein einmaliges Projekt zu verwandeln?
Die meisten Managed Service Provider (MSPs) wissen bereits, wie ein „gutes“ Identitätsmanagement aussieht; die Schwierigkeit besteht darin, es umzusetzen. zuverlässig ISMS.online bietet Ihnen eine zentrale Anlaufstelle, um die Funktionsweise von Identitätsmanagement zu beschreiben, diese Beschreibung mit realen Aktivitäten zu verknüpfen und die erzielten Verbesserungen aufzuzeigen – und das bei der Unterstützung zahlreicher Mandanten, verschiedener Plattformen und eines stark ausgelasteten Teams.
Wie lässt sich Mandantenfähigkeit so in ein ISMS integrieren, dass sie auch tatsächlich dauerhaft implementiert wird?
Teams, die A.5.16 souverän beherrschen und nicht ständig in Panik geraten, nutzen die Plattform in der Regel auf einige wenige konkrete Arten:
- Den Identitätsplan dokumentieren und sich zu eigen machen:
Bewahren Sie Ihre Identitätsarchitekturdiagramme, Ihren Rollenkatalog und Ihre Standard-Administrationsmuster in einem Arbeitsbereich auf, der mit A.5.16 und zugehörigen Steuerelementen wie Zugriffsbeschränkung, Protokollierung und Lieferantenzugriff verknüpft ist. Wenn Sie das Modell an eine neue Plattform, einen neuen Sektor oder eine neue Risikobereitschaft anpassen, wird die Änderung versioniert, geprüft und klar zugeordnet.
- Verfahren direkt mit der gelebten Praxis verknüpfen:
Verknüpfen Sie JML/JIT-Prozeduren und Zugriffsprüfungsschritte mit Tickets, Exporten, Protokollen und Berichten, um deren tatsächliche Ausführung zu dokumentieren. Diese Verbindung wandelt A.5.16 von einer bloßen Behauptung zu einer nachweisbaren Leistung, die jederzeit auf Anfrage erbracht werden kann.
- Erkenntnisse in sichtbare Verbesserungen umsetzen:
Wenn interne Audits, Vorfälle oder Kundenanfragen Schwachstellen in der Identitätsprüfung aufdecken, sollten diese als Maßnahmen mit Verantwortlichen und Datum protokolliert werden, anstatt sie als Hintergrundbedenken zu behandeln. Mit der Zeit entwickelt sich Ihre ISMS-Sicht auf A.5.16 zu einer Zeitleiste von Maßnahmen zur Verbesserung der Identitätsprüfung anstatt zu einer statischen Kontrollaussage.
- Beantworten Sie dieselben schwierigen Fragen stets konsequent:
Gehen Sie von derselben Kontrollperspektive aus, wenn ein ISO-Auditor Stichproben gemäß A.5.16 prüft, wenn das Sicherheitsteam eines Großkunden anfragt, welche Personen Zugriff auf seinen Mieter haben, oder wenn Ihr Versicherer Ihr Identitätsmodell verstehen möchte. Sie passen die Tiefe der offengelegten Informationen an, nicht die zugrunde liegenden Fakten.
Wenn Ihre aktuelle Identitätsverwaltung stark von wenigen Personen abhängt, die „einfach wissen, wie es funktioniert“, beginnen Sie klein, anstatt alles auf einmal abzubilden. Wählen Sie einen kritischen Prozess – beispielsweise die Gewährung, Überprüfung und den Entzug privilegierter Zugriffe für regulierte Mandanten – und modellieren Sie diesen in ISMS.online gemäß A.5.16 klar ab. Sobald Sie diesen Prozess in einem Meeting ohne Notizen oder mühsames Suchen nach Belegen erklären können, verfügen Sie über ein Muster, das Sie auf alle Ihre Identitäten und Mandanten anwenden können. Dadurch haben Sie eine deutlich stärkere Position, wenn Sie Ihren Managed Service nicht nur als funktionsfähig, sondern auch als nachweislich vertrauenswürdig präsentieren.
