Warum stellen MSP-Zugangsdaten mittlerweile den primären Angriffsweg dar?
MSP-Zugangsdaten stellen mittlerweile ein Hauptangriffsziel dar, da ein einziges privilegiertes Konto Zugriff auf zahlreiche Kundenumgebungen gleichzeitig ermöglicht. Jeder Techniker-Login, jedes Token und jeder API-Schlüssel erhöht das Risiko für Ihr gesamtes Portfolio, nicht nur für einen einzelnen Kunden. Angreifer betrachten Ihren MSP als Drehscheibe. Gelingt es ihnen, die richtigen Identitäten zu erlangen, können sie schnell zwischen verschiedenen Mandanten wechseln und Ihre operative Reichweite in großem Umfang zu ihrem Vorteil nutzen. Leitlinien zum Identitäts- und Zugriffsmanagement nationaler Cybersicherheitsbehörden, wie beispielsweise die „10 Schritte“ des NCSC zum Identitäts- und Zugriffsmanagement, unterstreichen ebenfalls, dass die Kompromittierung privilegierter Identitäten einer der häufigsten Wege in Organisationen ist. Dies macht diese Identitäten in einem Multi-Tenant-MSP-Modell besonders kritisch.
Diese Informationen sind allgemeiner Natur und stellen keine Rechts- oder Compliance-Beratung dar; Sie sollten sich für Ihre spezifische Situation stets professionellen Rat einholen.
Die meisten Organisationen, die an der ISMS.online-Umfrage 2025 teilnahmen, gaben an, im vergangenen Jahr von mindestens einem Sicherheitsvorfall bei einem Drittanbieter oder Lieferanten betroffen gewesen zu sein.
Der MSP-weite Explosionsradius einer einzelnen Akkreditierung
Ein einziges kompromittiertes Technikerkonto oder Zugangsdatenprofil kann einem Angreifer nahezu denselben Zugriff ermöglichen wie Ihrem Team. In einer mandantenfähigen MSP-Umgebung bedeutet dies Zugriff auf Remote-Management-Konsolen, Cloud-Portale, Backup-Systeme und Dashboards von Anbietern, die alle auf dieselbe Identität vertrauen. Ein einziger Fehler kann daher simultane Vorfälle bei vielen Kunden auslösen, anstatt nur einen einzelnen isolierten Sicherheitsvorfall zu verursachen. Analysen schwerwiegender Sicherheitslücken in Lieferketten und bei Serviceanbietern zeigen immer wieder, wie sich die Kompromittierung eines einzelnen Servicekontos, Integrationsschlüssels oder Zugangsdatenprofils eines MSP-Tools rasch auf viele nachgelagerte Organisationen auswirken kann.
Sobald ein Angreifer diese Identität erlangt hat, kann er sich lateral zwischen Mandanten bewegen, Schadsoftware so einsetzen, als wäre er Teil Ihres Teams, und Protokolle oder Backups manipulieren, um seine Spuren zu verwischen. Die Folge sind nicht nur Ausfallzeiten für einen einzelnen Kunden, sondern können langfristige Kundenverluste, Vertragsstrafen und schwerwiegende Reputationsschäden nach sich ziehen, die Ihre Wachstumspläne gefährden.
Warum traditionelle Anmeldeverfahren in Multi-Tenant-Umgebungen scheitern
Herkömmliche Vorgehensweisen wie das Teilen von Administratorpasswörtern, das Speichern von Zugangsdaten im Browser oder in unstrukturierten Notizen waren in einem Netzwerk einer einzelnen Organisation kaum tolerierbar; in einem Managed Service Provider (MSP) sind sie inakzeptabel. Ihre Techniker bewegen sich schnell zwischen Mandanten, Tools und Supportaufgaben, und bequeme, auf Abkürzungen basierende Lösungen sind unvermeidlich, wenn es keine zentrale, sichere Arbeitsweise gibt. In einer Multi-Tenant-Umgebung legen diese Abkürzungen viele Umgebungen gleichzeitig offen.
Wenn Sie immer noch auf gemeinsam genutzte globale Administratorkonten oder im Browser gespeicherte Passwörter setzen, wissen Sie bereits, wie unangenehm Audits und Kundenanfragen sein können. Solche Vorgehensweisen untergraben zudem die Verantwortlichkeit. Wenn mehrere Entwickler ein Konto gemeinsam nutzen, ist nicht nachvollziehbar, wer welche Aktionen durchgeführt hat. Daher fällt es Ihnen schwer, Kundenanfragen oder Prüfungsfragen souverän zu beantworten. Aufsichtsbehörden und Unternehmenskunden erwarten heute, dass privilegierte Zugriffe individuell, zeitlich begrenzt und überwacht werden. Schwache Praktiken im Umgang mit Authentifizierungsinformationen werden als direktes Geschäftsrisiko betrachtet. Branchenkommentare beschreiben Identität zunehmend als das neue Schlachtfeld der IT-Sicherheit. Versicherer und große Unternehmen konzentrieren sich darauf, ob privilegierte Zugriffe an namentlich genannte Benutzer gebunden, zeitlich begrenzt und nachvollziehbar sind.
Die ISO 27001:2022-Kontrolle A.5.17 wurde eingeführt, um den erweiterten Risiken im Zusammenhang mit Authentifizierungsinformationen zu begegnen und Organisationen – einschließlich Managed Service Providern (MSPs) – zu einem Umstieg von informellen Verfahren zur Geheimnisverwaltung hin zu kontrollierten und auditierbaren Verfahren zu bewegen. Sie erwartet, dass Sie von informellen Gewohnheiten zu einem kontrollierten Prozess übergehen, in dem die Zuweisung, Verwendung, Überwachung und der Widerruf von Authentifizierungsinformationen bewusst, dokumentiert und in allen von Ihnen genutzten Umgebungen überprüfbar erfolgen.
KontaktWas genau erwartet ISO 27001 A.5.17 von einem Managed Service Provider (MSP)?
ISO 27001:2022 A.5.17 verlangt, dass Authentifizierungsinformationen als verwaltetes Gut mit einem klar definierten Lebenszyklus behandelt werden. Für Managed Service Provider (MSPs) bedeutet dies, dass jedes Passwort, Token, jeder Schlüssel, jede PIN und jeder Wiederherstellungsfaktor, der für interne Systeme oder Kundenumgebungen verwaltet wird, gemäß nachvollziehbaren und nachweisbaren Regeln erstellt, gespeichert, verwendet, geändert und widerrufen werden muss. Verantwortliche für die Systeme, Sicherheitsbeauftragte und Betriebsleiter müssen die praktische Anwendung dieser Regeln nachweisen können. Die Formulierung von A.5.17 in ISO/IEC 27001:2022 verdeutlicht, dass Authentifizierungsinformationen als Teil des Informationssicherheitsmanagementsystems (ISMS) verwaltet werden sollten, mit definierten Aktivitäten für Erstellung, Verwendung, Änderung und Widerruf anstelle von Ad-hoc-Entscheidungen.
Komplizierte Kontrollsprache in einfaches Englisch übersetzen
Der Kern von A.5.17 besteht darin, dass jedes Geheimnis, das die Identität beweist, bewusst verwaltet wird und nicht persönlichen Vorlieben oder Stammeswissen überlassen bleibt. Im Klartext: Die Kontrolle erwartet von Ihnen, dass Sie mindestens Folgendes definieren:
- Wer kann eine Akkreditierung beantragen?
- Wer genehmigt diesen Antrag?
- Wie aussagekräftig die Referenz sein muss.
- Wie es dem Benutzer oder dem System übermittelt wird.
- Wo es aufbewahrt und geschützt wird.
- Wann es überprüft oder geändert werden muss.
- Wie Missbrauch oder Kompromittierung erkannt wird.
- Wie und wann es widerrufen wird.
Diese Entscheidungen sollten in Ihrer gesamten internen Umgebung und im Kundenbetrieb einheitlich getroffen werden. Ihr eigener Service Desk, Ihre Plattformen für Remote Monitoring und Management (RMM) und Professional Services Automation (PSA), Dokumentationssysteme, Backup-Konsolen, Versionskontrollsysteme und Identitätsanbieter fallen eindeutig in den Geltungsbereich. Ebenso wie Cloud-Tenants Ihrer Kunden, lokale Domänen, Firewalls, SaaS-Konsolen und Portale von Drittanbietern, auf denen Ihre Mitarbeiter Anmeldeinformationen für die tägliche Arbeit verwenden oder speichern.
Laut der ISMS.online-Umfrage 2025 erwarten viele Kunden mittlerweile von ihren Lieferanten, dass sie sich an formale Rahmenwerke wie ISO 27001, ISO 27701, DSGVO, Cyber Essentials und SOC 2 anpassen.
Sie können nicht einfach sagen: „Das sind die Zugangsdaten des Kunden“, wenn Ihre Mitarbeiter regelmäßig damit arbeiten. Wenn ein Geheimnis von Ihrem Team erstellt, gespeichert, verwendet oder unterstützt wird, fällt dies unter Ihren Prozess A.5.17 und muss durch Ihre Richtlinien, Verfahren und Nachweise abgedeckt sein, selbst wenn das System technisch gesehen dem Kunden gehört.
Den Umfang der „Authentifizierungsinformationen“ festlegen, damit Sie nichts verpassen
A.5.17 erwartet von Ihnen, dass Sie den Begriff „Authentifizierungsinformationen“ in Ihrem Kontext präzise definieren und sich nicht nur auf offensichtliche Passwörter konzentrieren. Die zugehörigen Richtlinien in ISO/IEC 27002:2022 für die Kontrollmaßnahme A.5.17 erweitern den Begriff explizit auf Token, Schlüssel und andere Geheimnisse, die zum Identitätsnachweis verwendet werden, nicht nur auf Passwörter. In der Praxis bedeutet dies, dass Sie neben den Benutzeranmeldeinformationen auch weniger sichtbare Geheimnisse berücksichtigen sollten, damit diese in Ihrem Kontrolldesign nicht vergessen werden. Wenn Sie anfangen, diese aufzulisten, kann die Anzahl der verschiedenen Geheimnistypen in einer mandantenfähigen Managed Service Provider-Umgebung (MSP) überraschend sein.
Sie müssen üblicherweise folgende Posten berücksichtigen:
- API-Schlüssel, Client-Geheimnisse und Tokens, die bei Automatisierungen und Integrationen verwendet werden.
- SSH-Schlüssel, Zertifikate und VPN-Pre-Shared-Keys, die von Ingenieuren und Tools verwendet werden.
- Wiederherstellungscodes und Hardware-Token-Seeds für die Multi-Faktor-Authentifizierung.
- Biometrische Vorlagen auf Geräten oder Systemen, die Sie konfigurieren oder verwalten.
Eine strukturierte Bestandsaufnahme identifiziert, wo diese Elemente vorhanden sind, welche Systeme sie schützen und welche Teams sie nutzen. Darauf aufbauend entscheiden Sie, welche Richtlinien und Verfahren aktualisiert werden müssen, welche Tools in Ihr Informationssicherheitsmanagementsystem (ISMS) integriert werden müssen und wo neue Kontrollen erforderlich sind. Ziel ist es, dass Sie auf die Frage eines Auditors, Kunden oder Versicherers „Wie verwalten Sie Authentifizierungsinformationen?“ einen klaren, durchgängigen Lebenszyklus aufzeigen können, anstatt eine Sammlung unzusammenhängender Praktiken.
Um diesen Wandel zu verstärken, ist es hilfreich, überkommene Gewohnheiten den mit A.5.17 abgestimmten Praktiken gegenüberzustellen:
| Gebiet | Alte Gewohnheit | A.5.17-konforme Praxis |
|---|---|---|
| Erstellung von Anmeldeinformationen | Ad-hoc-Kontoerstellung | Genehmigt, protokolliert und mit einem Risiko-/Kontrollsystem verknüpft. |
| Lagerung | Browser, Notizen oder freigegebene Tabellenkalkulationen | Zentraler Tresor mit rollenbasierter Zugriffskontrolle |
| Rotation und Widerruf | Erst nach Vorfällen | Geplante Überprüfungen plus ereignisgesteuerte Widerrufung |
| Beweisbar | Screenshots in E-Mail-Ketten | Kontrollierte Datensätze, die mit ISMS-Kontrollen verknüpft sind |
Wenn die Unterschiede so übersichtlich dargestellt werden, können die Teams leichter nachvollziehen, warum die Kontrolle wichtig ist und wo sich die tägliche Arbeit ändern muss.
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.
Wo genau geben Managed Service Provider (MSPs) heutzutage Authentifizierungsinformationen preis und missbrauchen sie?
Managed Service Provider (MSPs) geben Authentifizierungsinformationen häufiger preis und missbrauchen sie, als Führungskräfte erwarten, da Zugangsdaten in vielen Tools, Workflows und Verknüpfungen enthalten sind. Bei genauerer Betrachtung der täglichen Arbeit von Technikern findet man häufig Zugangsdaten, die über Browser, Chatprotokolle, Tickets, persönliche Passwortmanager, Dokumentationssysteme und Skripte verstreut sind. A.5.17 fordert Sie auf, diese Realitäten anzuerkennen und festzulegen, wie damit umgegangen werden soll.
Versteckte Verbreitung von Anmeldeinformationen über verschiedene Tools und Teams hinweg
Die erste Überraschung in den meisten Managed Service Providern (MSPs) ist, wie viele geheime Informationen existieren, die niemand aktiv verwaltet. Neben den benannten Benutzerkonten findet man typischerweise Folgendes:
- Gemeinsame Administrator-Logins für RMM-, PSA-, Backup- und Dokumentationstools.
- Servicekonten in Kundendomänen für Überwachung, Datensicherung oder Integrationen.
- Langlebige API-Schlüssel für Cloud-Dienste, Webhooks oder Anbieter-APIs.
- Verschlüsselungsschlüssel und Zertifikate werden informell auf den Geräten der Ingenieure gespeichert.
Viele dieser geheimen Zugangsdaten haben keinen eindeutigen Verantwortlichen, keinen dokumentierten Zweck und kein Ablaufdatum. Sie wurden möglicherweise im Rahmen einer Migration, eines Projekts oder eines Notfalls erstellt und anschließend nicht mehr verwendet, weil sie „einfach funktionieren“. Branchenstudien zu Zugangsdatennutzungsgewohnheiten zeigen ähnliche Muster: Zahlreiche wichtige Konten weisen in vielen Organisationen keine klare Verantwortlichkeit, Dokumentation oder ein definiertes Ablaufdatum auf, wie beispielsweise die Studie „Security Credential Habits“ verdeutlicht. Da diese Zugangsdaten unbemerkt im Hintergrund aktiv sind, werden sie selten in routinemäßige Zugriffsüberprüfungen oder Risikobewertungen einbezogen, obwohl sie attraktive Ziele darstellen: Sie sind wirkungsvoll, vorhersehbar und werden oft unzureichend überwacht.
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.
A.5.17 liefert Ihnen einen Grund – und eine Verpflichtung –, diese verborgenen Assets in ein kontrolliertes Inventar aufzunehmen. Die Implementierungskommentare zu A.5.17 betonen, dass Organisationen alle Formen von Authentifizierungsinformationen identifizieren und verwalten sollten, was zwangsläufig zur Führung eines Inventars solcher Geheimnisse als Teil des Kontrollumfangs führt. Dieses Inventar ist die Grundlage für jeden ernsthaften Versuch, die Angriffsfläche zu verringern und Kunden, Auditoren und Versicherern, die verstehen möchten, wie Sie privilegierte Zugriffe verwalten, die Kontrolle nachzuweisen.
Alltägliche Gewohnheiten, die selbst starke Technologien untergraben
Selbst wenn moderne Tools eingeführt werden, können alltägliche Gewohnheiten der Nutzer deren Sicherheit schnell untergraben. Entwickler exportieren beispielsweise Passwörter aus einem Passwort-Tresor in eine Tabellenkalkulation, um offline arbeiten zu können, fügen Administratorpasswörter aus Bequemlichkeit in Tickets oder Chats ein oder verwenden persönliche Zugangsdaten für neue Konten. Die Multi-Faktor-Authentifizierung mag zwar auf wichtigen Systemen erzwungen sein, wird aber stillschweigend deaktiviert oder umgangen, wenn sie die Arbeit verlangsamt.
Wenn Ihre vertraulichen Daten noch immer über verschiedene Browser, Chats und persönliche Tools verstreut sind, wissen Sie bereits, wie schwierig es ist, Risiken einzuschätzen. Dieses Verhalten ist unter Zeitdruck zwar verständlich, steht aber im direkten Widerspruch zu den Anforderungen von A.5.17 hinsichtlich kontrollierter Zuweisung und Verwaltung. Es erschwert zudem die Beantwortung grundlegender Fragen nach einem Vorfall, wie etwa „Welche vertraulichen Daten könnten durch diesen kompromittierten Laptop offengelegt worden sein?“ oder „Welche Kundenkonten waren durch dieses Konto gefährdet?“. Ohne diese Antworten verlieren Ihre Reaktion auf Vorfälle und Ihre Kundenkommunikation schnell an Glaubwürdigkeit.
Kleine Designänderungen tragen dazu bei, den Bedarf an unsicheren Notlösungen zu verringern, zum Beispiel können Sie:
- Deaktivieren Sie die Speicherung von Browserpasswörtern für Administratorkonten.
- Exporte aus Ihrem zentralen Datenspeicher können durch Richtlinien und technische Kontrollen blockiert werden.
- Für alle privilegierten Rollen, nicht nur für die wichtigsten Systeme, sollte eine Multi-Faktor-Authentifizierung erforderlich sein.
Diese Maßnahmen beseitigen zwar nicht alle menschlichen Risiken, aber sie verringern den Spielraum, in dem informelle Umgehungen unbemerkt Ihre Kontrollumgebung untergraben und schwer nachvollziehbare Offenlegungspflichten für Anmeldeinformationen schaffen können.
Wie sollte man eine A.5.17-konforme Multi-Tenant-Authentifizierungsstrategie entwerfen?
Eine A.5.17-konforme Authentifizierungsstrategie für Managed Service Provider (MSPs) klassifiziert Anmeldeinformationen nach ihrer Auswirkung und legt Mindestschutzmaßnahmen pro Ebene fest. Sobald Sie Ihre Anmeldeinformationslandschaft überblicken, können Sie von individuellen Vorgehensweisen zu einem definierten Modell übergehen, in dem für verschiedene Arten von Geheimnissen klare Behandlungsregeln gelten. Ziel ist es, dass die Kompromittierung einer Anmeldeinformation nicht automatisch alle von Ihnen betreuten Kunden gefährdet.
Definition von Berechtigungsstufen und Mindestschutzmaßnahmen
Ein praktischer Ansatz besteht darin, Authentifizierungsinformationen anhand ihrer Auswirkungen in verschiedene Stufen einzuteilen und jeder Stufe klare Mindestkontrollen zuzuordnen. So lassen sich sinnvolle Regeln mandantenübergreifend skalieren, anstatt jedes Konto einzeln zu verhandeln. Die Mitarbeiter erkennen zudem schnell, welche Geheimnisse strengere Sicherheitsvorkehrungen erfordern und warum bestimmte Schritte unerlässlich sind.
Sie könnten beispielsweise folgende Stufen definieren:
- Tier 1 – Break glass- und Plattformbetreiber: Notfallkonten, Super-Administratoren von Identitätsanbietern, zentrale RMM- und PSA-Besitzer.
- Tier 2 – Mandanten- und Systemadministratoren: Kunden-Tenant-Administratoren, Domänenadministratoren, Firewall-Administratoren, SaaS-Rollen mit hohen Berechtigungen.
- Tier 3 – Ingenieur- und Supportfunktionen: Benannte Mitarbeiterkonten mit erhöhten, aber eingeschränkten Berechtigungen in Tools und Tenants.
- Tier 4 – Service- und Automatisierungsidentitäten: Servicekonten, Skripte, Zeitplaner und API-Integrationen.
- Stufe 5 – Standardbenutzerkonten und Geheimnisse mit geringem Risiko:
Für jede Stufe definieren Sie Mindestkontrollen wie Multi-Faktor-Authentifizierung, Speicheranforderungen, Rotationsfrequenz, Überwachungserwartungen und Genehmigungsprozesse. Dadurch werden vage Vorgaben in konkrete Regeln umgewandelt, wie beispielsweise: „Geheimnisse der Stufen 1 und 2 befinden sich ausschließlich im Tresor, der Zugriff erfolgt über einen privilegierten Workflow und die Rotation erfolgt automatisch alle 90 Tage oder nach jedem Vorfall.“
Der Vorteil dieses Modells liegt in seiner Skalierbarkeit. Beim Hinzufügen von Mandanten, Tools oder Regionen werden neue Anmeldeinformationen der entsprechenden Stufe zugeordnet und dieselben grundlegenden Schutzmaßnahmen angewendet, anstatt jedes Mal neue Regeln zu erstellen. Mit der Zeit verinnerlichen die Mitarbeiter die Stufenlogik und verstehen, warum für manche Geheimnisse strengere Anforderungen an den Umgang gelten.
Ambitionen, bestehende Einschränkungen und Geschäftsziele in Einklang bringen
Es ist verlockend, ein perfektes Modell zu entwerfen, in dem es keine privilegierten Konten ohne sofortige Rechteerweiterung gibt und alle Geheimnisse täglich ausgetauscht werden. In der Realität müssen Sie jedoch Ihre Ambitionen mit den Beschränkungen bestehender Systeme, Kundenbudgets und Ihren eigenen Kapazitäten in Einklang bringen. Manche Systeme unterstützen moderne Modelle noch nicht, und manche Kunden werden nur in einem bestimmten Tempo mit den Neuerungen Schritt halten.
Sie könnten entscheiden, dass für Cloud-Tenant-Administratorrollen mithilfe integrierter Funktionen zur Verwaltung privilegierter Identitäten keine dauerhaften Berechtigungen erteilt werden können, bestimmte lokale Systeme jedoch vorerst auf herkömmliche Konten angewiesen sein sollen. Sie dokumentieren dies, legen kompensierende Maßnahmen wie verstärkte Überwachung oder strengere physische Sicherheitsvorkehrungen fest und planen regelmäßige Überprüfungen ein, um unbefristete Ausnahmen zu vermeiden.
Es ist außerdem wichtig, die Geschäftsziele im Blick zu behalten. Ihre Strategie sollte ein schnelles Kunden-Onboarding, eine reibungslose Integration von Akquisitionen und die Einhaltung branchenspezifischer Anforderungen, beispielsweise im Finanz- oder Gesundheitswesen, unterstützen. So angewendet, wird A.5.17 weniger zu einer bloßen Pflichterfüllung, sondern vielmehr zu einem Instrument, um das Risiko zu minimieren, dass ein einzelner Satz von Anmeldeinformationen Ihr gesamtes Serviceportfolio gefährdet.
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.
Welche Architekturen funktionieren tatsächlich für Vaults, PAM, KMS und JIT in einem MSP-Stack?
Managed Service Provider (MSPs) profitieren von einer einfachen Referenzarchitektur, die Identitätsmanagement, Geheimnissicherung, Zugriffsmanagement und Schlüsselverwaltung in einem einheitlichen Design vereint. Ziel ist es, den Zugriff von Mitarbeitern auf Rohdaten zu reduzieren und gleichzeitig reale Arbeitsabläufe zu unterstützen. Durch das Zusammenspiel dieser Bausteine erhalten Sie die von A.5.17 geforderte Transparenz und Kontrolle, ohne Ihre Entwickler zu überlasten.
Eine praxisorientierte Referenzarchitektur nutzt einen zentralen Identitätsanbieter, einen gemeinsamen Datenspeicher, eine Schicht für privilegiertes Zugriffsmanagement und ein strukturiertes Schlüsselmanagement, die sich gegenseitig verstärken. Mitarbeiter authentifizieren sich einmal, erhalten die korrekte Zugriffsebene und müssen nur selten direkt mit ungeschützten Geheimnissen hantieren. Dies reduziert die Angriffsfläche und erleichtert den Nachweis gegenüber Kunden und Auditoren, dass Sie Authentifizierungsinformationen konsistent verwalten.
Ein typisches Muster für einen MSP sieht folgendermaßen aus:
- Identitätsanbieter im Zentrum: Alle Mitarbeiter authentifizieren sich über eine zentrale Identitätsplattform, die eine starke Multi-Faktor-Authentifizierung und bedingten Zugriff erzwingt.
- Geheimer Tresor für von Menschen verwendete Zugangsdaten: Administratoren vermeiden Browser oder Notizen und verwenden einen zentralen Tresor, um bei Bedarf privilegierte Passwörter abzurufen.
- PAM-Workflows für Hochrisikooperationen: Techniker fordern genehmigte, zeitlich begrenzte Rechteerweiterungen an, anstatt gemeinsam genutzte Administrator-Logins für die Mandantenverwaltung zu verwenden.
- Schlüsselverwaltung für kryptografisches Material: Die Verschlüsselungsschlüssel und Zertifikate werden in einem speziellen System verwaltet, das die Rotation durchsetzt und die Nutzung protokolliert.
In diesem Design sind Tresor, PAM- und Schlüsselverwaltungssystem in Ihren Identitätsanbieter integriert, sodass der Zugriff darauf zentral gesteuert wird. Mitarbeiteridentitäten werden Rollen zugeordnet, und diese Rollen legen fest, welche Geheimnisse sie unter welchen Umständen verwenden dürfen. Dies unterstützt direkt den Fokus von A.5.17 auf kontrollierte Zuweisung, sichere Verwendung, Überwachung und Widerruf von Authentifizierungsinformationen.
Gestaltung von Mietertrennung, Resilienz und realen Arbeitsabläufen
Ein MSP-spezifisches Design muss auch die Trennung von Mandanten und die Ausfallsicherheit berücksichtigen, damit die Dienste sicher betrieben werden können. Sie müssen Fragen wie die folgenden beantworten können:
- Wie kann sichergestellt werden, dass ein Techniker mit Zugriff auf viele Mandanten beim Einsatz privilegierter Tools nicht ohne Weiteres Grenzen überschreiten kann?
- Werden Sie einen zentralen Tresor für alle Kunden verwenden oder separate logische oder physische Tresore für verschiedene Segmente oder Hochrisikokunden?
- Was passiert, wenn der Datentresor, der Identitätsanbieter oder der PAM-Dienst während eines Vorfalls oder eines größeren Ausfalls nicht verfügbar ist?
Die Antworten hängen von Ihrer Unternehmensgröße und Risikobereitschaft ab, sollten aber explizit formuliert und nicht vorausgesetzt werden. Viele Managed Service Provider (MSPs) setzen auf bewährte Verfahren wie mandantenspezifische Rollen in RMM- und Cloud-Plattformen, mandantenspezifische Protokollierung (wo möglich) und eine klare Aufgabentrennung zwischen den Ingenieuren, die Zugriffe konzipieren, und denen, die diese genehmigen oder überprüfen.
Auch der Arbeitsalltag erfordert Aufmerksamkeit. Fernwartung, Skripterstellung, Fehlerbehebung außerhalb der Geschäftszeiten und Projektarbeit führen zu Druck, Abkürzungen zu nehmen, wenn die Architektur zu starr ist. Die frühzeitige Einbindung der operativen Führungskräfte in die Architekturdiskussion hilft dabei, sichere und praktikable Muster für die Techniker zu entwickeln.
Eine Plattform wie ISMS.online kann Ihnen dabei helfen, diese Architektur zusammen mit den dazugehörigen Richtlinien, Risiken und Kontrollen zu dokumentieren und zu verfolgen, sodass Sie das Design weiterentwickeln können, ohne aus den Augen zu verlieren, warum es so aussieht, wie es aussieht, oder wie es A.5.17 unterstützt.
Wie führt man in der Praxis Lebenszyklusoperationen für MSP-Secrets durch?
Lebenszyklusprozesse setzen Ihre Strategie und Architektur im täglichen Betrieb um, indem sie definieren, wie Geheimnisse angefordert, erstellt, verwendet, rotiert und widerrufen werden. A.5.17 setzt voraus, dass Geheimnisse nicht nur sicher erstellt, sondern auch diszipliniert geändert, außer Betrieb genommen und überprüft werden. Für Managed Service Provider (MSPs) muss dieser Lebenszyklus Personalwechsel, Kunden-Onboarding und -Offboarding, Tool-Änderungen und die Reaktion auf Sicherheitsvorfälle über mehrere Mandanten hinweg abdecken. Die Leitlinien zu A.5.17 in ISO/IEC 27002:2022 bekräftigen dies durch die Beschreibung von Lebenszyklusaktivitäten wie Registrierung, Verwaltung, Widerruf und Austausch von Authentifizierungselementen.
Definition von Standard-Workflows für Erstellung, Rotation und Widerruf
Ein robustes Lebenszyklusmodell deckt den gesamten Lebenszyklus jedes Berechtigungsnachweises oder Schlüssels ab, von der Beantragung bis zur Außerkraftsetzung. Es wandelt Ad-hoc-Reaktionen in eine wiederholbare Abfolge von Schritten um, sodass verschiedene Berechtigungsnachweistypen einheitliche Prozesse mit entsprechenden Genehmigungen, Prüfungen und Nachweisen in jeder Phase durchlaufen. Diese Einheitlichkeit macht das Lebenszyklusmanagement transparent und nachvollziehbar.
Man kann den Lebenszyklus in fünf einfachen Schritten darstellen.
Schritt 1 – Zielgerichtet und mit Zustimmung erstellen
Die Erstellung von Geheimnissen erfolgt über einen festgelegten Prozess, wird mit einem geschäftlichen Grund begründet und bei hohem Risiko genehmigt. Geheimnisse werden mithilfe sicherer Standardeinstellungen wie starker Zufälligkeit und eindeutigen Werten generiert, nicht durch wiederverwendete Muster.
Schritt 2 – Sicher lagern und verteilen
Neue Geheimnisse werden direkt im entsprechenden Tresor oder System gespeichert und über verschlüsselte Kanäle an Mitarbeiter oder Systeme übermittelt. Sie werden niemals, auch nicht vorübergehend, an unkontrollierte Orte wie E-Mails, Chats oder persönliche Notizen kopiert.
Schritt 3 – Verwendung mit minimalen Berechtigungen und Protokollierung
Die Nutzung wird durch Tools gesteuert, die das Prinzip der minimalen Berechtigungen durchsetzen, gegebenenfalls Multi-Faktor-Authentifizierungen anwenden und protokollieren, wer welche Anmeldeinformationen zu welchem Zweck und wann verwendet hat. Mitarbeiter verwenden nach Möglichkeit personalisierte Konten anstelle gemeinsam genutzter Logins.
Schritt 4 – Regelmäßig überprüfen und rotieren
Geheimnisse werden nach einem festgelegten Zeitplan überprüft, um den Bedarf zu bestätigen, Berechtigungen anzupassen und Werte zu aktualisieren. Zusätzliche Aktualisierungen werden durch Ereignisse wie Rollenwechsel, Verdacht auf Kompromittierung, Herstellerwarnungen oder wesentliche Architektur-Updates ausgelöst.
Schritt 5 – Widerrufen und sauber vernichten
Wenn ein Geheimnis nicht mehr benötigt wird, wird es umgehend widerrufen und aus Tresoren, Systemen und Dokumentationen entfernt. Zwischengespeicherte Kopien werden gelöscht, damit die Zugangsdaten nicht versehentlich in Skripten, Notizen oder alten Playbooks wiederverwendet werden können.
Einige dieser Schritte lassen sich automatisieren, andere erfordern menschliche Disziplin. Wichtig für A.5.17 ist, dass jede Zertifizierungskategorie einen klar definierten Lebenszyklus aufweist und dass Sie Prüfern und Kunden nachweisen können, wie Sie diesen einhalten und wie Sie mit Ausnahmen umgehen.
Umgang mit Ausnahmen, Notfallzugang und menschliche Faktoren
Kein Lebenszyklus ist vollständig ohne klare Regeln für Ausnahmen und Notfälle. Es wird Systeme geben, die moderne Authentifizierungsverfahren nicht unterstützen, und es wird Situationen geben, in denen normale Zugriffswege ausfallen und Notfalloptionen benötigt werden. A.5.17 verbietet dies nicht; es erwartet jedoch, dass Sie dies transparent und durchdacht steuern.
Bei Ausnahmen können Sie einen Risikoverantwortlichen benennen, die Gründe für die Ausnahme dokumentieren, kompensierende Maßnahmen wie zusätzliche Überwachung oder strengere physische Sicherheitsvorkehrungen definieren und ein Ablaufdatum für die erneute Bewertung festlegen. Dadurch wird eine potenziell dauerhafte Schwachstelle zu einem beherrschbaren, zeitlich begrenzten Risiko, das Sie offen mit Kunden und Wirtschaftsprüfern besprechen können.
Für den Notfallzugriff können Sie festlegen, wie spezielle Konten erstellt werden, wo die Zugangsdaten gespeichert werden, wer sie nutzen darf, wie die Nutzung protokolliert wird und wie die Zugangsdaten nach Gebrauch ausgetauscht oder widerrufen werden. So gewährleisten Sie sowohl die Verfügbarkeit in Krisensituationen als auch die Nachvollziehbarkeit im Anschluss.
Sie müssen auch menschliche Gegebenheiten berücksichtigen: unerwartete Mitarbeiterabgänge, Vertragsabschlüsse, Fusionen und Übernahmen, die die Zuständigkeiten für Systeme oder Mandanten verändern. Die Integration von Prozessen für Eintritt, Versetzung und Austritt in HR-, CRM- und Identitätsmanagementsystemen verringert das Risiko, dass privilegierte Konten verwaist zurückbleiben, erheblich. Wenn diese Lebenszyklusprozesse als Workflows in Ihrem ISMS abgebildet sind – mit klaren Verantwortlichen und Nachweisen –, lässt sich Auditoren und Kunden viel leichter zeigen, dass A.5.17 mehr als nur eine Richtlinie ist.
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.
Wie gestalten Sie die Prozesse, wie dokumentieren Sie Ihre Abläufe und wie stellen Sie sicher, dass Sie für A.5.17 auditbereit sind?
Governance ist der Punkt, an dem Kontrollsprache, Architektur, Arbeitsabläufe und alltägliche Verhaltensweisen zu einem für Außenstehende verständlichen Gesamtbild verschmelzen. Wenn Auditoren oder Unternehmenskunden Sie bewerten, wollen sie nicht nur sehen, dass Sie über gute Tools verfügen, sondern auch, dass Sie Authentifizierungsinformationen schlüssig verwalten und dies nachweisen können. Governance hilft Ihnen zu zeigen, dass Ihre Kontrollen real und nicht nur ein Wunschtraum sind.
Governance macht Ihre bestehenden Arbeitsweisen sichtbar, zielgerichtet und leichter verbesserungsfähig.
Eine Beweisführung entwickeln, die auch für Außenstehende Sinn ergibt
Die Nachweise gemäß A.5.17 lassen sich üblicherweise in verschiedene Kategorien einteilen, die gemeinsam beschreiben, wie Sie Authentifizierungsinformationen in Ihrem Managed Service Provider (MSP) verwalten. Diese Kategorisierung hilft Ihnen, für Prüfer und Kunden aussagekräftige Nachweise zu sammeln und nicht nur eine Ansammlung unzusammenhängender Dokumente. Best-Practice-Empfehlungen für die Implementierung von A.5.17 und den Betrieb eines umfassenden Informationssicherheitsmanagementsystems (ISMS) strukturieren die Nachweise häufig auf diese Weise, sodass Richtlinien, Konfigurationen, Protokolle und Schulungsunterlagen gemeinsam veranschaulichen, wie Authentifizierungsinformationen in der Praxis gehandhabt werden.
Typische Beweismittel umfassen:
- Richtlinien und Standards: die festlegen, wie Authentifizierungsinformationen angefordert, genehmigt, erstellt, gespeichert, verwendet, rotiert und widerrufen werden.
- Prozeduren und Betriebshandbücher: die erläutern, wie Sie mit Szenarien wie dem Onboarding, der Erstellung von Mandantenadministratoren oder dem Verdacht auf eine Kompromittierung von Anmeldeinformationen umgehen.
- Konfigurationsdatensätze: Von Tresoren über Systeme für privilegierten Zugriff und Identitätsplattformen bis hin zu Schlüsselverwaltungstools, die zeigen, wie Design und Richtlinien übereinstimmen.
- Protokolle und Berichte: die veranschaulichen, wie Geheimnisse tatsächlich verwendet werden, einschließlich privilegierter Sitzungsprotokolle, Zugriffsüberprüfungen und Rotationsereignisse.
- Schulungs- und Sensibilisierungsaufzeichnungen: die belegen, dass die Mitarbeiter unterwiesen wurden und die wichtigsten Verantwortlichkeiten für den Umgang mit Authentifizierungsinformationen anerkannt haben.
Die überzeugendsten Nachweise verknüpfen diese Punkte zu konkreten, relevanten Beispielen. Beispielsweise könnten Sie einen Standard für die Verwaltung von API-Schlüsseln vorlegen, der mit einem Eintrag im Risikoregister für Drittanbieterintegrationen verknüpft ist, sowie ein Handbuch zur Schlüsselerneuerung und die zugehörigen Protokolle mit den letzten Aktualisierungen. Diese Art der Nachvollziehbarkeit gibt Prüfern und Kunden die Gewissheit, dass Ihre Vorgehensweise planvoll und überwacht ist und nicht improvisiert.
Man kann sich das wie eine klare Geschichte vorstellen: „Hier ist unsere Regel, so setzen wir sie um, so überprüfen wir sie und hier ist der Beweis, dass sie tatsächlich eingehalten wird.“ Wenn diese Geschichte über alle Mandanten und Tools hinweg einheitlich erzählt wird, wirkt Ihre Governance-Strategie glaubwürdig und nicht nur oberflächlich.
Integration von A.5.17 in Ihren Governance-Rhythmus
Governance funktioniert am besten, wenn sie Teil Ihres regulären Arbeitsablaufs ist und nicht erst kurz vor einer externen Prüfung in letzter Minute erledigt wird. Sie können A.5.17 in diesen Arbeitsablauf integrieren, indem Sie:
- Regelmäßige Überprüfungen von Zugangsdaten und Schlüsseln mit hohem Risiko, bei denen die Eigentümer die Notwendigkeit bestätigen, Berechtigungen anpassen und überprüfen, ob Aufbewahrung und Rotation den Anforderungen entsprechen.
- Überprüfung von Protokollen und Warnmeldungen im Zusammenhang mit privilegiertem Zugriff und geheimer Nutzung sowie Behandlung von Anomalien als Auslöser sowohl für die Reaktion auf Vorfälle als auch für die Prozessoptimierung.
- Die Erkenntnisse aus Vorfällen, Beinaheunfällen und Penetrationstests werden in aktualisierte Richtlinien, Standards und Architekturen eingearbeitet.
- Die Einbeziehung des Status A.5.17 in Management Reviews und Aktualisierungen des Risikoausschusses entspricht der Erwartung der ISO 27001, dass das Top-Management regelmäßig den Status der Kontrollen und des Restrisikos im gesamten ISMS prüft.
Rund zwei Drittel der Befragten in der ISMS.online-Umfrage 2025 gaben an, dass die Geschwindigkeit und das Ausmaß der regulatorischen Änderungen die Aufrechterhaltung der Compliance erschweren.
Wenn Sie Ihre Nachweise immer noch einige Wochen vor jedem Audit in freigegebenen Ordnern und E-Mails vorbereiten, wissen Sie, wie stressig das sein kann. Eine ISMS-Plattform wie ISMS.online kann dies vereinfachen, indem sie als zentrale Anlaufstelle dient, wo Sie A.5.17-Kontrollen definieren, mit Risiken verknüpfen, Verantwortliche zuweisen, Nachweise erfassen und Prüfungen planen. Anstatt sich auf Ad-hoc-Dokumente und Tabellenkalkulationen zu verlassen, erhalten Sie ein dynamisches System, das die tatsächliche Verwaltung von Authentifizierungsinformationen widerspiegelt und Verbesserungspotenziale aufzeigt.
Wenn Governance auf diese Weise transparent ist, ermöglicht A.5.17 bessere Entscheidungen. Sie müssen nicht länger raten, welche Geheimnisse am wichtigsten sind, oder darauf hoffen, dass sich gute Gewohnheiten bewähren; Sie nutzen Fakten, um Ihren Managed Service Provider (MSP) zu weniger Überraschungen und stabileren Kundenbeziehungen zu führen.
Buchen Sie noch heute eine Demo mit ISMS.online
ISMS.online unterstützt Sie bei der Umsetzung von A.5.17, indem es Ihre Richtlinien, Risiken, Architekturen und Nachweise in einem strukturierten System verknüpft. So können Sie Prüfern und Kunden zeigen, dass Sie Authentifizierungsinformationen als kritischen Vermögenswert behandeln. Für MSP-Leiter und Sicherheitsteams bedeutet dies, dass Ihre Zugangsdaten und Geheimnisse – auch bei wachsendem Kundenstamm – Vertrauen schaffen, anstatt Sorgen zu bereiten.
Sehen Sie sich Ihr A.5.17-Geschoss von Anfang bis Ende an
Wenn Sie ISMS.online erkunden, sehen Sie, wie es Sie dabei unterstützt, technische Kontrollen in eine klare, nachvollziehbare Dokumentation zu verwandeln. Anstatt vor jedem Audit Screenshots und Tabellenkalkulationen mühsam zusammenzutragen, arbeiten Sie in einer Umgebung, die Risiken, Kontrollen, Maßnahmen und Nachweise direkt miteinander verknüpft. Dadurch wird es einfacher, Stakeholder zu informieren und anspruchsvollen Kunden zu beweisen, dass Sie diszipliniert arbeiten.
In der ISMS.online-Umfrage 2025 nannten fast alle Organisationen das Erreichen oder Aufrechterhalten von Sicherheitszertifizierungen wie ISO 27001 oder SOC 2 als eine ihrer obersten Prioritäten.
Mit ISMS.online können Sie:
- Die Richtlinien und Standards gemäß A.5.17 sollten in einer klaren Sprache formuliert werden, die auch Nicht-Fachleute verstehen und befolgen können.
- Geheimnisse und Risiken privilegierter Zugriffe in internen Systemen und Kundenumgebungen werden in einer einzigen Ansicht dargestellt.
- Verknüpfen Sie spezifische Kontrollaktivitäten – wie etwa die Rotation von Berechtigungsnachweisen oder Zugriffsüberprüfungen – mit Einträgen im Risikoregister und Prüfungsanforderungen.
- Speichern und greifen Sie auf Belege wie Konfigurations-Screenshots, Exportdateien und Besprechungsnotizen zu, ohne E-Mails und Dateifreigaben durchsuchen zu müssen.
Diese durchgängige Sichtweise macht aus der Kontrollvorgabe A.5.17 eine nachvollziehbare Erklärung, die Sie gegenüber Kunden oder Auditoren bei schwierigen Fragen begründen können. Sie bietet Ihnen eine zentrale, übersichtliche Plattform, um nachzuverfolgen, wie Ihr Managed Service Provider (MSP) Authentifizierungsinformationen mandanten- und toolübergreifend zuweist, verwendet und widerruft.
Planen Sie Ihre nächsten neunzig Tage mit Zuversicht
Ein kurzer, zielgerichteter Implementierungsplan ist oft wertvoller als eine langfristige Vision. Gemeinsam mit Ihrem Team und einem Spezialisten von ISMS.online können Sie die nächsten drei Monate auf einige konkrete Maßnahmen ausrichten, die A.5.17 praktisch stärken, ohne Ihre Mitarbeiter zu überlasten oder den Kundenservice zu beeinträchtigen. Viele ausgelastete MSP-Teams haben die Erfahrung gemacht, dass ein fokussierter 90-Tage-Plan deutlich besser zu bewältigen ist als der Versuch, alles auf einmal anzugehen.
Schritt 1 – Erstellen Sie ein realistisches Qualifikationsprofil
Identifizieren Sie Ihre Anmeldeinformationen mit dem höchsten Risiko, Servicekonten, API-Schlüssel und Schlüsselspeicher und protokollieren Sie, wo diese gespeichert sind, welche Systeme sie schützen und wem sie gehören.
Schritt 2 – Festlegung von Basisrichtlinien und -standards
Definieren Sie praxisnahe Richtlinien und Standards für Authentifizierungsinformationen, die die Größe, die Tools und die bestehenden Prozesse Ihres Managed Service Providers widerspiegeln, und weisen Sie jedem Dokument eindeutige Verantwortliche zu.
Schritt 3 – Wesentliche Lebenszyklus-Workflows einrichten
Implementieren Sie einen minimalen Satz von Arbeitsabläufen für die Erstellung, Rotation, Überprüfung und den Widerruf privilegierter Konten und Schlüssel, einschließlich klarer Auslöser und Verantwortlichkeiten für jeden Schritt.
Schritt 4 – Ein erstes Beweismaterialpaket zusammenstellen
Sammeln Sie erste Belege für aussagekräftige Fortschritte im Hinblick auf A.5.17, damit Sie Stakeholder, Versicherer und Wirtschaftsprüfer mit Zuversicht informieren und weitere Verbesserungen planen können.
Von dort aus können Sie iterativ vorgehen und die Komplexität erhöhen, sobald Ihre Mitarbeiter, Prozesse und Architekturen ausgereift sind, ohne dabei die bereits geschaffenen Grundlagen aus den Augen zu verlieren. Kleine, kontinuierliche Schritte stärken die Position deutlich mehr als gelegentliche große Initiativen vor Audits, und ein 90-Tage-Plan erscheint für die meisten MSP-Teams als realistischer Zeithorizont.
Wenn Sie möchten, dass Ihre Zugangsdaten und Geschäftsgeheimnisse Ihr Wachstum fördern, anstatt es stillschweigend zu untergraben, ist ISMS.online als Plattform für Ihr ISMS der richtige nächste Schritt. Sie erhalten ein Framework, Inhalte und Workflows, die auf realen ISO 27001-Erfahrungen basieren. So müssen Sie nicht bei null anfangen oder verstreute Dokumente zusammenfügen. Das erleichtert die Implementierung von A.5.17 erheblich und trägt dazu bei, Ihre Kunden zu schützen, Ihre Techniker zu unterstützen und Ihr Unternehmen zu stärken.
KontaktHäufig gestellte Fragen (FAQ)
Wie genau verändert ISO 27001:2022 A.5.17 die Authentifizierung für einen Managed Service Provider (MSP)?
ISO 27001:2022 A.5.17 wandelt jedes Passwort, jeden Token und jeden Schlüssel, mit dem Ihr Managed Service Provider (MSP) arbeitet, in ein kontrolliertes Gut mit klaren Regeln, Eigentumsverhältnissen und Nachweisen um – und nicht nur in etwas, das man sich merkt oder irgendwo speichert. Sie müssen definieren, wie Authentifizierungsinformationen erstellt, geschützt, verwendet, ausgetauscht und widerrufen werden, und dies konsistent in Ihrer eigenen Infrastruktur und bei jedem von Ihnen verwalteten Kunden nachweisen.
Welchen Anwendungsbereich hat A.5.17 in einer MSP-Umgebung?
Für einen typischen Managed Service Provider (MSP) geht A.5.17 weit über Mitarbeiter-Logins oder einen einzelnen Passwort-Manager hinaus. Es verändert die Art und Weise, wie Sie die Authentifizierung handhaben, in folgenden Bereichen:
- RMM- und PSA-Plattformen: das Hunderte von Endpunkten und Kundenmandanten erreichen kann.
- Dokumentations- und Wissenssysteme: wo Anleitungen und Passwörter oft miteinander vermischt werden.
- Backup-, Überwachungs- und DR-Konsolen: die im Stillen einen breiten und dauerhaften Zugang besitzen.
- Cloud-Mandanten und Identitätsanbieter: wo wenige Rollen alles verändern können.
- Anbieterportale und Lizenzsysteme: Wird zur Verwaltung von Berechtigungen für verschiedene Kunden verwendet.
Statt sich auf überliefertes Wissen oder verstreute Notizen zu verlassen, wird von Ihnen Folgendes erwartet:
- Behalten Sie eine verlässliche Sichtweise auf wer kann was erreichen über interne und Kundensysteme hinweg.
- Wenden Sie einfache, wiederholbare Regeln an für ausstellen, schützen, rotieren und widerrufen jede Art von Nachweis.
- Stellen Sie sicher, dass sich die Änderungen für Joiner, Mober und Leaver bewähren. tatsächlich den Zugriff entfernen und gegebenenfalls Rotationen auslösen.
- Halten Sie genügend strukturierte Nachweise bereit, um Ihre Vorgehensweise gegenüber Wirtschaftsprüfern und Unternehmenskäufern ruhig erläutern zu können.
Wenn Sie diese Regeln, Verantwortlichkeiten und Arbeitsabläufe in einem strukturierten Informationssicherheitsmanagementsystem (ISMS) wie ISMS.online erfassen, gelangen Sie von der Annahme „Wir denken, wir haben alles unter Kontrolle“ zur Fähigkeit, genau zu zeigen, wie Authentifizierungsinformationen in einer mandantenfähigen, toolintensiven MSP-Welt verwaltet werden.
Der eigentliche Wandel besteht nicht in strengeren Passwörtern, sondern darin, jedes Geheimnis als ein Gut mit einem nachvollziehbaren und beweisbaren Lebenszyklus zu behandeln.
Wie kann ein Managed Service Provider (MSP) die Auswirkungen minimieren, wenn ein wichtiges Zugangsdokument unweigerlich gestohlen wird?
Sie minimieren die Auswirkungen, indem Sie davon ausgehen, dass mindestens ein wichtiger Zugangspunkt kompromittiert wird, und Ihre Umgebung so gestalten, dass dieser Zugangspunkt so wenig wie möglich, für die kürzestmögliche realistische Dauer und mit klaren Spuren bei der Nutzung entsperrt wird. A.5.17 empfiehlt, einen kleineren, besser sichtbaren „Auswirkungsradius“ anzustreben, anstatt alles darauf zu setzen, niemals einen Schlüssel zu verlieren.
Wie sieht ein kleinerer Explosionsradius im alltäglichen Einsatz von MSPs aus?
In den meisten MSPs sieht ein praktischer Mustersatz folgendermaßen aus:
- Nur benannte Administratoridentitäten: Ersetzen Sie gemeinsam genutzte „Global Admin“-Konten durch die Verknüpfung erhöhter Rollen mit einzelnen Benutzern in Ihrem Identitätsanbieter mittels starker Multi-Faktor-Authentifizierung.
- Rollenbasierter Zugriff auf alle Kernwerkzeuge: RMM, PSA, Cloud-Plattformen und Dokumentationssysteme sollten nach dem Prinzip der minimalen Berechtigungen für Rolle, Kundengruppe und Region ausgerichtet werden, nicht nach dem Prinzip „Jeder kann alles überall tun“.
- Just-in-time-Erhöhung: Gewährung voller Administratorrechte nur für eine bestimmte Aufgabe und einen bestimmten Zeitraum, danach automatische Reduzierung der Berechtigungen auf niedrigere Werte.
- Kontrollierte Verwaltungszugangspunkte: Erzwinge die Ausführung privilegierter Arbeitsvorgänge über gehärtete Pfade (z. B. Privileged Access Management, Bastion-Hosts oder streng kontrollierte Jump-Boxen), anstatt über beliebige Laptops in beliebigen Netzwerken.
- Zentralisierte Protokollierung und Alarmierung: Senden Sie privilegierte Aktivitätsprotokolle an einen zentralen Ort, damit ungewöhnliche Aktionen auffallen und mit realen Personen, Tickets und Zeiträumen in Verbindung gebracht werden können.
Auf diese Weise konzipiert, bleibt ein gestohlenes Technikerpasswort zwar weiterhin ein ernstes Problem, stellt aber nicht mehr einen Generalschlüssel für „alle Kunden gleichzeitig“ dar. Wenn Sie diese Designentscheidungen in Ihrem ISMS dokumentieren und mit A.5.17 verknüpfen, können Sie Prüfern, Versicherern und anspruchsvollen Kunden nachweisen, dass Sie die potenziellen Auswirkungen bewusst minimiert haben, anstatt darauf zu hoffen, dass ein Sicherheitsvorfall nie eintritt.
Was gehört in ein Handbuch für gehärtete Zugangsdaten und Geheimnisse eines Managed Service Providers?
Ein ausgereiftes Handbuch erklärt, wie Sie Zugangsdaten in Stufen einteilen, welche Mindestsicherheitsvorkehrungen jede Stufe erfüllen muss und wie Sie diese Sicherheitsvorkehrungen im Laufe der Zeit implementieren und verbessern. Es ersetzt die Aussage „Jeder weiß, dass Vorsicht geboten ist“ durch „Wir wenden dieses Modell täglich an, und diese Aufzeichnungen belegen es“.
Welche Elemente sind für einen Multi-Tenant-MSP am wichtigsten?
Für die meisten Managed-Service-Provider umfasst ein hilfreicher Leitfaden Folgendes:
- Klare Berechtigungsstufen: zum Beispiel Break-Glass-Konten, plattformweite Administratoren in RMM und Cloud, Mandantenadministratoren, Ingenieurskonten, Servicekonten und Automatisierungsgeheimnisse.
- Grundlegende Sicherheitsvorkehrungen pro Stufe: Erwartungen an die Multi-Faktor-Authentifizierung, Speicherort der Geheimnisse (Tresor vs. Plattform), maximale Lebensdauer, Rotationsfrequenz, Protokollierungstiefe und Überprüfungshäufigkeit.
- Standard-Werkzeugkombinationen: Wie Sie Ihren Identitätsanbieter, Ihren Passwort- oder Geheimnisspeicher, Ihre Fernzugriffsarchitektur und Ihre Protokollierungstools so einsetzen, dass die Regeln durchgesetzt werden, ohne die Entwickler massiv zu verlangsamen.
- Ausnahmebehandlung und Legacy-Verarbeitung: wie Sie ältere Plattformen, Nischenanbieter oder übernommene Umgebungen dokumentieren und einbinden, die Ihren idealen Standard noch nicht erfüllen können.
- Ein einfacher Fahrplan für Veränderungen: welche Sicherheitsvorkehrungen Sie in diesem Quartal, in diesem Jahr und vor größeren Vertragsverlängerungen oder Plattformänderungen verschärfen werden.
Wenn Sie dieses Handbuch in ISMS.online als Richtlinien, Standards, verknüpfte Assets, Risiken und Kontrollen abbilden, beschränkt es sich nicht mehr nur auf das Notizbuch eines einzelnen leitenden Ingenieurs. Es wird zu einem Werkzeug, das Sie neuen Mitarbeitern vermitteln, mit der Führungsebene besprechen und Auditoren oder Risikomanagement-Teams als Ihren klaren und verlässlichen Ansatz für Zugangsdaten und Geschäftsgeheimnisse präsentieren können.
Wie sollte ein Managed Service Provider (MSP) Servicekonten, API-Schlüssel und Automatisierungsgeheimnisse unterschiedlich handhaben?
Dienstkonten und Automatisierungsschlüssel müssen als leistungsstarke Identitäten mit Besitzern, Berechtigungen und Ablaufdatum behandelt werden, nicht als unauffällige Konfigurationsdetails, die erst dann Beachtung finden, wenn ein Fehler auftritt. Sie bieten oft weitreichende und langfristige Zugriffsrechte ohne zugeordnete Person, was sie für Angreifer attraktiv macht und leicht übersehen werden kann, wenn sie nicht gezielt verwaltet werden.
Was beinhaltet eine gute Governance nicht-menschlicher Identitäten für eine MSP?
Effektive Regierungsführung beruht in der Regel auf einigen wenigen Gewohnheiten:
- Führen eines Live-Bestands: von Servicekonten, API-Schlüsseln und Automatisierungsgeheimnissen für RMM, Backup, Monitoring, Cloud-Plattformen, Anbieterportale und interne Tools.
- Zuweisung eines verantwortlichen Eigentümers und eines Zwecks: für jede nicht-menschliche Identität, mit dokumentierten minimalen Berechtigungen und einer klaren Aufzeichnung darüber, wo sie verwendet wird.
- Zentralisierung der Geheimhaltung: in einem kontrollierten Tresor oder auf einer Plattform, anstatt Werte über Skripte, Tickets, freigegebene Ordner, Wikis oder lokale Konfigurationsdateien zu verstreuen.
- Definition und Durchsetzung von Rotationsauslösern: planmäßige Rotationen sowie Änderungen nach Personalabgängen, Zwischenfällen mit Lieferanten, Plattformverletzungen oder größeren Konfigurationsänderungen.
- Einbeziehung nicht-menschlicher Identitäten in Rezensionen und Vorfällen: Bei routinemäßigen Zugriffsüberprüfungen, der Priorisierung von Vorfällen und der Nachanalyse von Vorfällen sollte immer die Frage gestellt werden: „Welche Automatisierungen und Integrationen könnten hier betroffen oder missbraucht sein?“
Wenn Sie nicht-menschliche Identitäten über Ihr ISMS mit einheitlichen Richtlinien, Risiken, Kontrollen und Nachweisen verwalten, können Sie zeigen, dass A.5.17 die unauffällige Automatisierungsebene Ihrer IT-Infrastruktur genauso umfassend abdeckt wie menschliche Administratoren. Dies beruhigt größere Kunden, die sich vor allem Sorgen um Integrationen und Skripte machen, die bei unsachgemäßer Handhabung weitreichenden, unbemerkten Zugriff gewähren könnten.
Wie kann ein MSP nachweisen, dass A.5.17 in der Realität funktioniert und nicht nur auf dem Papier?
Sie zeigen, dass A.5.17 real ist, indem Sie Ihre Richtlinien, die Gestaltung Ihrer Umgebung und die tatsächlichen Abläufe im Tagesgeschäft miteinander verknüpfen. Auditoren und Unternehmenskunden suchen nach einer nachvollziehbaren Geschichte: „Das ist unsere Richtlinie, das sind die Kontrollen und Tools, die wir einsetzen, so testen wir sie, und diese Beispiele zeigen die jüngsten Aktivitäten.“
Welche Arten von Nachweisen überzeugen üblicherweise Wirtschaftsprüfer und Unternehmenskäufer?
Als Nachweise, die typischerweise gut für A.5.17 geeignet sind, gelten unter anderem:
- Richtlinien und detaillierte Standards: die beschreiben, wie Sie Zugangsdaten und Geheimnisse in internen Systemen und Kundensystemen ausgeben, schützen, rotieren und widerrufen, in einer Sprache, die Ingenieure verstehen können.
- Konfigurationsexporte oder Screenshots: von Identitätsanbietern, Datenspeichern, Tools für privilegierten Zugriff und Schlüsselverwaltungsdiensten, die die Einhaltung dieser Standards in realen Umgebungen demonstrieren.
- Aktivitätsprotokolle und Berichte: Darstellung privilegierter Aktionen, geheimer Rotationen, Zugriffsüberprüfungen und Vorfallsbearbeitung im Zeitverlauf, nicht nur für eine einzelne Woche.
- Schulungs- und Bestätigungsnachweise: für Mitarbeiter, die mit sensiblen Authentifizierungsinformationen arbeiten, insbesondere solche mit Zugriff auf mehrere Mandanten.
- Ergebnisse interner Audits und Managementbewertungen: wo Sie Ihre eigene Herangehensweise hinterfragt, Erkenntnisse festgehalten und konkrete Verbesserungen dokumentiert haben.
Wenn Sie all dies in ISMS.online als Kontrollen mit zugeordneten Risiken, Verantwortlichen, Maßnahmen und zugehörigen Nachweisen verknüpfen, vermeiden Sie die zeitraubende Suche nach alten Tickets und Screenshots. Stattdessen verfügen Sie über eine stets aktuelle, transparente Dokumentation (A.5.17-Standard), die Sie Vorständen, Versicherern und Kundenrisikoteams jederzeit vorlegen können, wenn diese nach Ihrem Zugriffsmanagement für Ihre eigenen und die Systeme Ihrer Kunden fragen.
Wenn Sie nicht nur Richtlinien, sondern auch Veränderungen aufzeigen können, hören die Menschen auf, sich Sorgen zu machen, dass Ihre Sicherheit eher in Präsentationsfolien als in Systemen verankert ist.
Wie kann ISMS.online einem Managed Service Provider (MSP) bei der Implementierung von A.5.17 helfen, ohne die Techniker zu überfordern?
ISMS.online unterstützt Sie bei der Konzeption, dem Betrieb und der Dokumentation Ihres A.5.17-Ansatzes in einer strukturierten Umgebung, anstatt Richtlinien über verschiedene Ordner und Nachweise über E-Mail-Verläufe und Chatprotokolle zu verteilen. So können Sie sich zunächst auf die wichtigsten Zugangsdaten und Geheimnisse konzentrieren, Fortschritte schnell nachweisen und die Abdeckung anschließend in einem Tempo erweitern, das Ihr Team realistisch bewältigen kann.
Welche sinnvollen, unkomplizierten Schritte eignen sich für die nächsten neunzig Tage?
Viele Managed Service Provider (MSPs) erzielen innerhalb kurzer Zeit sichtbare Fortschritte durch:
- Aufbau eines fokussierten Bestands: ihrer leistungsstärksten Administratorkonten, Servicekonten und API-Schlüssel auf Kernplattformen wie RMM, PSA, Cloud Identity, Backup und Remote Access.
- Einigung auf ehrliche Grundsatzrichtlinien und -standards: für Authentifizierungsinformationen, die die aktuelle Funktionsweise widerspiegeln, und deren Speicherung in ISMS.online mit benannten Verantwortlichen, Überprüfungsdaten und verknüpften Steuerelementen.
- Erfassung einiger zentraler Arbeitsabläufe: -zum Beispiel die Bereitstellung von Administratorkonten, Änderungen von Berechtigungen, der Entzug von Berechtigungen und die Nutzung im Notfall innerhalb von ISMS.online und die Verknüpfung dieser mit den damit verbundenen Risiken und Nachweisen.
- Zusammenstellung eines ersten Beweismaterialpakets: Das zeigt, dass im Hinblick auf A.5.17 tatsächlich Fortschritte erzielt wurden, darunter mindestens eine Zugriffsüberprüfung, ein Rotationsereignis und eine interne Kontrolle, um die Führungsebene zu informieren und schwierigere Kundenfragen zu beantworten.
Von dort aus können Sie die Abdeckung auf weitere Mandanten und Tools ausweiten, Ihre Architektur mit zunehmender Reife optimieren und regelmäßige Überprüfungen integrieren, ohne jede Verbesserung in ein Großprojekt zu verwandeln. Wenn Sie Zugangsdaten und Zugangsrechte nutzen möchten, um Wachstum zu fördern, anstatt Ihre Reichweite stillschweigend zu vergrößern, ist die Verwendung eines ISMS wie ISMS.online ein vielversprechender Ansatz, um Ihren ersten 90-Tage-Plan transparent, kontrollierbar und realisierbar zu gestalten.
