Wenn Automatisierung zu Ihrem größten unvorhergesehenen Risiko wird
Automatisierung wird zum größten unerkannten Risiko, wenn Skripte und Orchestrierung viele Kundenumgebungen gleichzeitig verändern können, ohne die gleichen Governance-Regelungen wie Ihre übrige kritische Infrastruktur zu durchlaufen. Gemäß ISO 27001 bedeutet dies, Skripte und Automatisierung als integralen Bestandteil Ihrer Sicherheitskontrollebene zu behandeln und nicht als informelle, nebenbei eingesetzte Entwicklungswerkzeuge.
Unkontrollierte Automatisierung in Ihrem Managed Service Provider (MSP) kann sich unbemerkt zum mächtigsten und am wenigsten kontrollierten Teil Ihrer Sicherheitsinfrastruktur entwickeln. Wenn ein einzelner Prozess in Ihrer RMM-, CI/CD- oder Orchestrierungsschicht Änderungen in alle Mandanten übertragen kann, fordert ISO 27001, dass Sie klare Zuständigkeiten, Verantwortlichkeiten, Änderungskontrolle und Überwachung genauso anwenden wie bei Firewalls, Identitätsplattformen und Backup-Systemen. Diese Auslegung entspricht der Norm ISO/IEC 27001:2022, die definierte Zuständigkeiten, Verantwortlichkeiten, kontrollierte Änderungen und Überwachung für Informationsverarbeitungseinrichtungen betont, die relevante Informationen verarbeiten.
Diese Informationen sind allgemeiner Natur und stellen keine Rechts-, Regulierungs- oder Zertifizierungsberatung dar; Sie sollten sich für Ihre spezifische Situation stets kompetenten professionellen Rat einholen.
Die Werkzeuge, die Ihnen Zeit sparen, können auch Ihre Fehler vervielfachen, wenn Sie sie nicht richtig einsetzen.
Wie sich die MSP-Automatisierung in der Praxis verhält
Die Automatisierung in Managed Service Providern (MSPs) entwickelt sich oft von wenigen nützlichen Skripten zu einem weitverzweigten, privilegierten Kontrollsystem, das Kunden, Plattformen und Umgebungen umfasst. Niemand versteht es vollständig, bis in mehreren Kundenumgebungen gleichzeitig ein Fehler auftritt. Um die Automatisierung gemäß ISO 27001 abzusichern, benötigen Sie zunächst ein klares Bild davon, wo die Automatisierung aktuell eingesetzt wird, wie weit verbreitet sie ist, welche Systeme und Daten sie beeinflussen kann und wie Sie dieses Ökosystem analysieren und abbilden können. So können Sie das damit verbundene Risiko bewerten und es Kunden und Auditoren erläutern.
Bei den meisten Managed Service Providern (MSPs) sieht man dasselbe Muster: Was mit ein paar praktischen PowerShell-Code-Snippets und geplanten Aufgaben begann, hat sich zu einem komplexen Geflecht entwickelt:
- RMM-Aufträge, die Tausende von Endpunkten innerhalb von Minuten ändern können.
- Gemeinsame Runbooks für Patching, Onboarding und Incident Response
- Pipeline-gesteuerte Bereitstellung von Richtlinien, Agenten und Konfigurationen
- API-basierte Integrationen, die mehrere Cloud-Dienste und Mandanten miteinander verbinden
All dies läuft üblicherweise mit erhöhten Rechten und umgeht oft die für normale Benutzer eingerichteten Kontrollmechanismen. Ein einziges falsch konfiguriertes Skript kann Folgendes bewirken:
- die falsche Richtlinie für jeden Kunden anstatt für einen anwenden
- Sicherheitssoftware entfernen, anstatt sie zu installieren.
- Berechtigungen für eine gemeinsam genutzte Ressource mandantenübergreifend zurücksetzen
- Daten oder Snapshots in der falschen Umgebung löschen
Aus Sicht der ISO 27001 bedeutet dies, dass die Automatisierung die Vertraulichkeit, Integrität und Verfügbarkeit der Informationen, die unter Ihr ISMS fallen, eindeutig beeinflusst. Sie lediglich als technische Infrastruktur anstatt als sicherheitsrelevante Komponente zu betrachten, ist nicht mehr tragbar, wenn Sie ein glaubwürdiges Zertifikat und ausfallsichere Dienste wünschen.
KontaktWie Sie die MSP-Automatisierung in Ihren ISO 27001-Geltungsbereich integrieren können
Sie integrieren die Automatisierung von Managed Service Providern (MSPs) in Ihren ISO 27001-Geltungsbereich, indem Sie sich auf Automatisierungen konzentrieren, die Systeme, Daten oder Dienste innerhalb des Geltungsbereichs verändern können, und diese Tools anschließend als mit Risiken und Kontrollen verknüpfte Assets dokumentieren. So können Sie Auditoren und Kunden nachweisen, dass Sie bewusste, risikobasierte Entscheidungen darüber getroffen haben, wo Scripting und Orchestrierung in Ihrem ISMS angesiedelt sind.
Fast alle Organisationen, die an der ISMS.online-Umfrage 2025 teilnahmen, nannten das Erreichen oder Aufrechterhalten von Sicherheitszertifizierungen wie ISO 27001 oder SOC 2 als eine ihrer obersten Prioritäten.
Die korrekte Definition des Geltungsbereichs Ihres ISMS ist bereits eine der größten Herausforderungen der ISO 27001, und die Automatisierung macht sie noch komplexer, da sie Systeme, Standorte und Kunden betrifft. Entscheidend ist, bewusst festzulegen, welche Skript- und Automatisierungsaktivitäten in den Geltungsbereich fallen, diese klar zu dokumentieren und ihre Steuerung transparent darzustellen, anstatt sie als unsichtbare Hintergrundprozesse zu belassen.
Entscheiden Sie, welche Automatisierungen tatsächlich in das ISMS gehören.
Sie entscheiden, welche Automatisierungen in das ISMS gehören, indem Sie prüfen, ob ein Skript, ein Runbook oder ein Job direkte Auswirkungen auf relevante Informationen, Systeme oder Dienste haben kann. Wenn Produktionsumgebungen, personenbezogene Daten oder die Verfügbarkeit von Kerndiensten verändert werden können, sollte es als relevantes Asset behandelt und denselben Kontrollen wie Ihre anderen kritischen Komponenten unterworfen werden.
Ein praktischer Test für jedes Skript, Runbook oder jeden automatisierten Job ist:
- Betrifft es Informationen, die bereits im Geltungsbereich des ISMS liegen?
- Kann dies die Vertraulichkeit, Integrität oder Verfügbarkeit der betroffenen Dienste oder Systeme wesentlich beeinträchtigen?
Lautet die Antwort auf eine der beiden Fragen „Ja“, sollten Sie die entsprechende Automatisierung als im Geltungsbereich liegend betrachten. Dies umfasst häufig Folgendes:
- RMM-Plattformen und ihre Skriptbibliotheken, die zur Verwaltung von Kundengeräten verwendet werden
- In Ihre PSA oder Ihren Service Desk integrierte Automatisierung, die Tickets aktualisiert oder Aktionen in anderen Tools auslöst
- Infrastruktur als Code, Konfigurationsmanagement und CI/CD-Jobs, die die Produktionsinfrastruktur bereitstellen oder ändern
- Benutzerdefinierte Bots oder API-Integrationen, die Kundendaten zwischen Systemen übertragen
Bei der automatisierten Verarbeitung personenbezogener Daten müssen Sie auch Datenschutz- und regulatorische Anforderungen berücksichtigen. Beispielsweise ist zu prüfen, ob Datenschutz-Folgenabschätzungen oder ähnliche Prüfungen diese Arbeitsabläufe in Ihrem Zuständigkeitsbereich umfassen sollten. Interne Testskripte, die niemals auf Produktions- oder reale Daten zugreifen, fallen möglicherweise tatsächlich nicht unter diese Anforderungen. Dennoch sollten Sie prüfen, ob sie indirekt Auswirkungen auf Live-Umgebungen haben können, etwa durch die Veröffentlichung von Inhalten, die später in der Produktion wiederverwendet werden.
Die Automatisierung soll sich klar in Umfang, Anlagen und System of Automation widerspiegeln.
Sie bilden die Automatisierung in Umfang, Assets und Ihrer Anwendbarkeitserklärung klar ab, indem Sie relevante Plattformen und Skriptbibliotheken benennen, diese als Informations-Assets modellieren und mit spezifischen Risiken und Kontrollen gemäß Anhang A verknüpfen. Dadurch wird Ihre Automatisierungsgeschichte für Prüfer leicht nachvollziehbar und Kunden erhalten die Gewissheit, dass Sie die tatsächliche Kontrollebene Ihres Managed Service Providers (MSP) verstehen.
Sobald Sie festgelegt haben, was in den Geltungsbereich gehört, müssen Sie dies in Ihrer ISMS-Dokumentation sichtbar machen. Mindestens:
- Geltungsbereich: – explizit RMM-Plattformen, Automatisierungs-Frameworks und Skriptbibliotheken erwähnen, die zur Bereitstellung der im Leistungsumfang enthaltenen Dienste verwendet werden.
- Anlagenregister oder CMDB: – Erstellen von Asset-Typen für „Automatisierungsskripte und Runbooks“ und „Automatisierungsplattformen“ mit Eigentümern, Standorten und Beziehungen zum Kundendienst.
- Risikoabschätzung: – einschließlich Risiken, die spezifisch für die Automatisierung sind, wie z. B. Massenfehlkonfigurationen, Missbrauch von Anmeldeinformationen, Auswirkungen auf andere Mandanten und mangelnde Rückverfolgbarkeit.
- Erklärung zur Anwendbarkeit: – Begründen Sie die relevanten Kontrollen für die Automatisierung, insbesondere in den Bereichen Zugriffskontrolle, Betrieb, sichere Entwicklung, Protokollierung und Lieferantenmanagement.
Wenn Sie mehrere Servicebereiche oder Marken unterstützen, geben Sie genau an, welche dazugehören. Für kundenspezifische Automatisierung gilt folgende Regel: Wenn Ihr Team die Automatisierung im Rahmen des Service entwickelt, betreibt oder wartet, behandeln Sie sie als Ihr Eigentum. Die geteilten Verantwortlichkeiten sollten in Verträgen und Datenschutzvereinbarungen dokumentiert werden.
Dieser Schritt macht Ihnen das Leben nicht schwerer; er bringt Ihr ISMS lediglich in Einklang mit der Realität, dass der Großteil Ihrer kritischen Sicherheits- und Compliance-Arbeit heute über Skripte und Plattformen und nicht mehr durch rein manuelle Administration erfolgt.
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.
Anhang A enthält die wichtigsten Steuerelemente für Skripte, Runbooks und RMM-Aufträge.
Die in Anhang A aufgeführten Kontrollen, die für Skripte, Runbooks und RMM-Jobs am wichtigsten sind, regeln, wer leistungsstarke Automatisierungen ändern darf, wie Änderungen vorgenommen werden und wie Aktionen protokolliert werden. Wenn Sie Zugriffskontrolle, Betrieb, Entwicklung, Protokollierung und Lieferantenüberwachung priorisieren, erzielen Sie die meisten Vorteile der ISO 27001, ohne jede Kontrolle gleichermaßen auf jedes Skript anwenden zu müssen.
Anhang A der ISO 27001:2022 enthält 93 Kontrollen, von denen jedoch nur ein Teil direkt Einfluss auf die Absicherung von Skripten und Automatisierungen hat. Unabhängige Analysen der Aktualisierung von 2022, wie beispielsweise die BSI-Übersicht zur ISO/IEC 27001:2022, heben hervor, dass die 93 Kontrollen risikobasiert und kontextbezogen und nicht einheitlich angewendet werden sollen. Indem Sie sich auf Zugriffskontrolle, Änderungsmanagement, sichere Entwicklung, Protokollierung und Lieferantenmanagement konzentrieren, können Sie ein zielgerichtetes Kontrollset erstellen, das zu Ihrem Managed Service Provider (MSP) passt und die Anforderungen der ISO 27001-Auditoren erfüllt, anstatt zu versuchen, mit einheitlichen Regeln alle Bereiche abzudecken.
Kernsteuerungsthemen für die Automatisierung
Zu den zentralen Steuerungsthemen für die Automatisierung gehören Identitäts- und Zugriffsmanagement, Servicekonten, Änderungsmanagement, sichere Entwicklung, Protokollierung und Lieferantenüberwachung. Einige wenige Themen aus Anhang A bieten Ihnen den größten Einfluss auf die MSP-Automatisierung. Wenn Sie diese Themen realen Tools und Workflows zuordnen – beispielsweise durch Zugriffskontrolle, um festzulegen, wer Skripte bearbeiten darf, Änderungsmanagement, um Aktualisierungen zu steuern, sichere Entwicklung, um offensichtliche Fehler zu vermeiden, Protokollierung, um Aktionen nachzuweisen, und Lieferantenmanagement, um Drittanbieterplattformen zu überwachen –, werden sie zu einem praktischen Leitfaden für die Steuerung von Skripten und RMM-Aufträgen anstatt zu einer abstrakten Regelliste.
Rund 41 % der Organisationen gaben in der ISMS.online-Umfrage 2025 an, dass das Management von Drittparteirisiken und die Überwachung der Lieferantenkonformität eine der größten Herausforderungen im Bereich der Informationssicherheit darstellen.
Die relevanten Steuerelemente lassen sich in einige wenige praktische Kategorien einteilen:
- Zugriffskontrolle und Identität: – festlegen, wer Automatisierungen erstellen, bearbeiten, genehmigen und ausführen darf.
- Dienstkonten und Schlüssel: – definieren, wie nicht-menschliche Identitäten ausgestellt, gespeichert und überprüft werden.
- Änderungsmanagement und operative Abläufe: – regeln, wie Skripte und Jobs angefordert, getestet, genehmigt und zurückgesetzt werden.
- Sichere Entwicklung: – Stellen Sie sicher, dass die Automatisierung so konzipiert, programmiert und überprüft wird, dass Fehler vorhersehbar und eingedämmt sind.
- Protokollierung und Überwachung: – Erfassung und Überprüfung automatisierter Aktionen, insbesondere privilegierter oder mandantenübergreifender Aktivitäten.
- Lieferanten- und Mietermanagement: – Bewertung und Überwachung von RMM-Anbietern, Cloud-Diensten und gemeinsam genutzten Automatisierungsinhalten.
Anstatt diese Themen abstrakt zu behandeln, ordnen Sie jedes einzelne konkreten Szenarien in Ihrer Umgebung zu. Diese Zuordnung bildet später die Grundlage Ihrer Handlungsanweisungen und Ihrer Kontrollberichte gegenüber Auditoren und Kunden.
Beispielhafte Zuordnung: Steuerungen zu Automatisierungspraktiken
Sie gestalten Anhang A praxisnah, indem Sie die Kontrollthemen direkt mit Automatisierungspraktiken und den bereits vorhandenen Nachweisen verknüpfen. So verweist jedes Thema auf konkrete Beispiele in Ihrem RMM, Ihren Skript-Repositories und Service-Workflows, anstatt nur in Richtliniendokumenten zu existieren.
Eine einfache Tabelle hilft Ihnen, die Themen aus Anhang A mit Ihrer heutigen MSP-Praxis zu verknüpfen:
| Steuerungsthema | Beispiel für eine Automatisierungspraxis | Typische Beweise |
|---|---|---|
| Zugriff | RBAC für RMM-Skriptbibliothek und Git-Repositories | Rollenmatrix, Zugriffsüberprüfungen, Screenshots |
| Änderungsmanagement | Änderungstickets für Aktualisierungen des Produktionsskripts | Tickets mit Genehmigungen und Testnotizen |
| Sichere Entwicklung | Peer-Review für risikoreiche PowerShell-Skripte | Überprüfen Sie die Datensätze im Repository oder im Ticketsystem. |
| Protokollierung | Zentrale Protokollierung der Ergebnisse der Skriptausführung | Protokollauszüge, Alarmregeln, SIEM-Berichte |
| Lieferantenmanagement | Sicherheitsbewertung von RMM- und Automatisierungsanbietern | Lieferantenrisikobewertungen und Verträge |
Sie müssen nicht für jedes Skript alle Kontrollmechanismen im gleichen Umfang implementieren. Risikobasierte Anwendung ist sowohl zulässig als auch erwünscht. Ein einfaches, einmaliges Abfrageskript, das von einem erfahrenen Entwickler in einer kontrollierten Umgebung verwendet wird, benötigt möglicherweise nur eine grundlegende Überprüfung und Protokollierung, während ein mandantenübergreifender Patch-Vorgang ein strengeres Design, Genehmigungen und Monitoring erfordert.
Indem Sie Ihre Kontrollmechanismen bewusst auswählen und die Zuordnung dokumentieren, erleichtern Sie es den Prüfern, Ihre Logik nachzuvollziehen, und den Ingenieuren, zu verstehen, warum bestimmte Schutzmaßnahmen getroffen wurden.
Skripte und Runbooks als erstklassige Informationsressourcen behandeln
Skripte und Runbooks als erstklassige Informationsressourcen zu behandeln bedeutet, ihnen klare Zuständigkeiten, Klassifizierungen und einen definierten Lebenszyklus zuzuweisen und sie nicht als persönliche Dateien auf Laptops zu belassen. Wenn die Automatisierung in Ihrem ISMS korrekt modelliert ist, können Sie grundlegende Fragen zu den vorhandenen Ressourcen, den Verantwortlichen und den damit verbundenen Risiken beantworten. Dies schafft Sicherheit sowohl für Auditoren als auch für Führungskräfte ohne technischen Hintergrund.
Eine ISMS-Plattform wie ISMS.online vereinfacht diese Modellierung durch standardisierte Anlagentypen, Beziehungen und Nachweisverknüpfungen, während Ihre Ingenieure weiterhin mit gewohnten RMM- und Versionskontrollsystemen arbeiten können. Diese Kombination ermöglicht es Ihnen, die Produktivität aufrechtzuerhalten und gleichzeitig die von ISO 27001 geforderte Transparenz und Verantwortlichkeit zu erreichen.
Erstellen Sie ein Automatisierungsanlagenmodell, das die Realität widerspiegelt
Sie erstellen ein realitätsnahes Automatisierungs-Asset-Modell, indem Sie wichtige Skripte und Runbooks katalogisieren, deren Speicherort, die betroffenen Systeme und die jeweiligen Eigentümer erfassen. So erhalten alle Beteiligten in den Bereichen Sicherheit und Servicebereitstellung eine gemeinsame, verlässliche Übersicht über die eingesetzte Automatisierung, deren Standort und das damit verbundene Risiko. Anstatt sich auf Erfahrungswissen zu verlassen, erfassen Sie alle wesentlichen Details in Ihrem ISMS. Dadurch erhalten Ingenieure, Manager und Auditoren ein einheitliches Bild der Automatisierungsreichweite, ohne jedes einzelne Hilfsskript verfolgen zu müssen.
Ein pragmatisches Automatisierungs-Asset-Modell beantwortet für jedes wichtige Skript oder Runbook einige einfache Fragen:
- Was ist es?: – ein Patch-Skript, ein Onboarding-Runbook, ein Backup-Orchestrierungsjob, eine Compliance-Prüfung und so weiter.
- Wo lebt es? – RMM-Bibliothek, Git-Repository, Konfigurationsmanagementsystem, Workflow-Tool.
- Wem gehört es? – eine benannte Rolle oder ein Team, das für die Korrektheit und Pflege verantwortlich ist.
- Was berührt es? – Mandanten, Umgebungen, Datenklassen und Systeme im Geltungsbereich.
- Wie kritisch ist es? – Auswirkungen auf Vertraulichkeit, Integrität und Verfügbarkeit, falls es versagt oder missbraucht wird.
Sie müssen nicht jedes einzelne Hilfsskript separat modellieren. Viele Managed Service Provider (MSPs) gruppieren die Automatisierung in Kategorien wie „Standard-Patching-Jobs“, „Backup-Jobs“ und „Onboarding-Workflows“ und weisen auf dieser Ebene Verantwortliche zu. Nur die risikoreichsten oder am stärksten individualisierten Skripte werden als separate Assets erfasst.
Der entscheidende Punkt ist, dass Sie auf die Frage „Wer ist für diese Automatisierung verantwortlich und wie riskant ist sie?“ schnell und konsequent antworten können.
Automatisierung klassifizieren, um sinnvolle Steuerungen zu ermöglichen
Sie klassifizieren Automatisierungsprozesse, um sinnvolle Kontrollen zu ermöglichen, indem Sie Skripte entsprechend ihrer Berechtigungen und ihres Wirkungsbereichs kennzeichnen und jede Klasse mit klaren Erwartungen verknüpfen. Dies vermeidet eine einheitliche Vorgehensweise und hilft Entwicklern zu verstehen, warum manche Änderungen formaler erfolgen müssen, ohne jede noch so kleine Änderung im Prozessablauf zu ersticken.
Als Ausgangspunkt könnten Sie drei einfache Bezeichnungen verwenden:
- Standard: – begrenzter Geltungsbereich, geringe Berechtigungen, einfache Rückgängigmachung; zum Beispiel Erzwingen einer Bildschirmschonerrichtlinie.
- Privilegiert: – verwendet Administratorrechte oder Dienstkonten, ist aber auf einen Mandanten oder eine Umgebung beschränkt.
- Mandantenübergreifend / kritisch: – kann mehrere Kunden, Kernplattformen oder große Datensätze betreffen.
Anschließend werden die Kontrollerwartungen auf jede Klasse abgestimmt. Zum Beispiel:
- Standard-Skripte müssen gegebenenfalls kurz überprüft und grundlegend protokolliert werden.
- Privilegierte Skripte erfordern Änderungstickets, Peer-Review und explizite Rollback-Pläne.
- Mandantenübergreifende oder kritische Skripte erfordern strengere Designprüfungen, die Genehmigung durch eine Führungskraft sowie ein dediziertes Monitoring und Alarmierungssystem.
Die Zentralisierung von Skripten in verwalteten Repositories mit Versionsverlauf und Backup rundet das Gesamtbild ab. Dadurch wird das Risiko privater Skriptablagen auf Laptops beseitigt, die Einarbeitung und Übergabe vereinfacht und Sie erhalten eine verlässliche Informationsquelle für Auditoren, wenn diese nach der Kontrolle der Automatisierung fragen.
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.
Gestaltung der Zugangskontrolle und Funktionstrennung für die Automatisierung
Bei der Gestaltung von Zugriffskontrolle und Aufgabentrennung für die Automatisierung geht es darum sicherzustellen, dass niemand unbemerkt und ohne Aufsicht wichtige Skripte und Prozesse ändern kann, während der Prozess gleichzeitig an die Teamgröße angepasst bleibt. ISO 27001 legt Wert auf die Aufgabentrennung an wichtigen Punkten, nicht auf ein umfangreiches Organigramm.
Da Automatisierung häufig mit weitreichenden Berechtigungen und großer Reichweite arbeitet, können Zugriffskontrolle und Funktionstrennung den entscheidenden Unterschied zwischen einem begrenzten Fehler und einem mandantenübergreifenden Vorfall ausmachen. Die Herausforderung für viele Managed Service Provider (MSPs) besteht darin, ein robustes System zu entwickeln, das sowohl Prüfer als auch Kunden überzeugt, ohne dabei einen Workflow zu schaffen, den die Techniker in der Praxis nicht umsetzen können.
Trennen Sie die Kategorien „Wer kann“ auf eine Weise, mit der Ihr Team leben kann.
Sie trennen die Zuständigkeiten so, dass Ihr Team damit gut zurechtkommt, indem Sie Lebenszyklusrollen für Autoren, Prüfer, Operatoren und Plattformadministratoren definieren und anschließend an den risikoreichsten Stellen Kontrollen durchführen, selbst wenn mehrere Rollen gleichzeitig besetzt sind. Idealerweise lägen das Schreiben, Genehmigen und Ausführen der Produktionsautomatisierung immer in getrennten Händen. In der Realität kombinieren kleine und mittelständische Managed Service Provider (MSPs) jedoch häufig Rollen, und ISO 27001 erlaubt dies, solange die Risiken verstanden, kompensierende Kontrollen angewendet und sichergestellt wird, dass Änderungen mit hoher Auswirkung weiterhin einer unabhängigen Prüfung unterzogen werden und der Produktionszugriff auf genehmigten Code beschränkt ist. Dieser risikobasierte Ansatz entspricht ISO 27001 und den Leitlinien zur Funktionstrennung für kleinere IT-Organisationen, die anerkennen, dass die Kombination von Rollen akzeptabel sein kann, wenn die daraus resultierenden Risiken identifiziert und minimiert werden, insbesondere bei Änderungen mit hoher Auswirkung (z. B. in den praktischen Leitlinien zur Funktionstrennung).
Ein praktisches Vorgehen besteht darin, Rollen anhand von Lebenszyklusphasen statt anhand von Berufsbezeichnungen zu gestalten:
- Autor: – kann Skripte in der Entwicklungs- oder Testumgebung erstellen und bearbeiten, kann sie aber nicht direkt in die Produktionsumgebung übertragen.
- Prüfer/Genehmiger: – prüft Absicht, Umfang und Sicherheit, insbesondere bei privilegierten oder mandantenübergreifenden Skripten.
- Betreiber: – können genehmigte Skripte in der Produktion planen oder ausführen, aber deren Inhalt nicht ändern.
- Plattform- und Geheimnisadministrator: – verwaltet die RMM-Konfiguration, Repositories und Credential Vaults.
In kleinen Teams kann eine Person zwei dieser Rollen innehaben, dennoch lässt sich an wichtigen Punkten eine klare Trennung durchsetzen. Beispielsweise sollte – zumindest bei risikoreichen Automatisierungen – festgelegt werden, dass Produktionsänderungen von einer anderen Person freigegeben werden als von derjenigen, die sie geschrieben hat. Wo dies nicht möglich ist, helfen kompensierende Maßnahmen wie eine erweiterte Protokollierung, regelmäßige Stichproben des Managements und strengere Beschränkungen der Berechtigungen eines einzelnen Kontos, das Risiko in Grenzen zu halten.
Wenn Sie ein Serviceleiter sind, bietet Ihnen diese Struktur eine einfache Möglichkeit, die Ingenieure über die Erwartungen zu informieren; wenn Sie operativ tätig sind, verwandelt sie abstrakte Anforderungen an die „Aufgabentrennung“ in konkrete Kontrollen, die Sie in Ihre Tools einbauen können.
Servicekonten und -schlüssel sollten als hochwertige Identitäten behandelt werden.
Sie behandeln Servicekonten und -schlüssel als wertvolle Identitäten, indem Sie diese inventarisieren, ihre Rechte streng einschränken, Geheimnisse sicher speichern und ihre Nutzung regelmäßig überprüfen. Da Automatisierungen häufig unter nicht-menschlichen Konten mit weitreichenden Berechtigungen laufen, ist es unerlässlich, diese Identitäten mit der gleichen Sorgfalt zu verwalten wie Ihre mächtigsten Benutzerkonten.
Skripte und Automatisierungsplattformen basieren typischerweise auf nicht-menschlichen Identitäten: Dienstkonten, API-Schlüssel, Token und Zertifikate. Diese sind oft leistungsfähiger und weniger gut kontrollierbar als menschliche Konten, was sie für Angreifer attraktiv macht und sowohl für Sicherheits- als auch für Datenschutzteams ein Problem darstellt.
Es ist unerlässlich, diese mit Ihren bestehenden Richtlinien für privilegierte Zugriffe in Einklang zu bringen:
- Führen Sie ein Verzeichnis aller nicht-menschlichen Identitäten, die in der Automatisierung verwendet werden, und der Systeme, auf die sie zugreifen können.
- Prinzip der minimalen Berechtigungen anwenden: Jede Identität sollte auf die minimal zugänglichen Mandanten, Ressourcen und Aktionen beschränkt werden.
- Geheimnisse sollten in einem verwalteten Tresor gespeichert werden, niemals fest in Skripten codiert oder im Klartext abgelegt.
- Die Zugangsdaten sollten regelmäßig und immer dann gewechselt werden, wenn Mitarbeiter das Unternehmen verlassen oder sich ihre Aufgaben ändern.
- Die Verwendung dieser Identitäten sollte protokolliert und überprüft werden, insbesondere im Hinblick auf ungewöhnliche Zeiten, Orte oder Ziele.
Viele moderne Plattformen unterstützen die bedarfsgerechte Rechteerweiterung oder kontextbezogene Richtlinien, bei denen eine Identität nur für eine bestimmte Aufgabe und ein bestimmtes Zeitfenster weitreichende Rechte erhält. Wo möglich, reduzieren diese Muster den Schaden, den ein kompromittiertes Konto oder Skript anrichten kann, zusätzlich.
Durch eine durchdachte Gestaltung der Zugangskontrolle und der Aufgabentrennung erfüllen Sie die Anforderungen der ISO 27001 und schützen Ihre Ingenieure gleichzeitig davor, zu unkontrollierten Machtzentren zu werden.
Ein praktischer, sicherer Entwicklungslebenszyklus für MSP-Skripte und Runbooks
Ein praktischer, sicherer Entwicklungszyklus für MSP-Skripte und Runbooks ist eine kurze, wiederholbare Abfolge, die Entwickler in ihren bestehenden Tools befolgen können und die automatisch ISO-27001-konforme Nachweise generiert. Ziel ist kein aufwendiger Prozess, sondern ein vorhersehbarer Weg von der Idee zur Produktion, der Risikobewertung, Überprüfung, Tests und Überwachung umfasst.
Viele Managed Service Provider (MSPs) verbinden mit „Entwicklung“ große Softwareprojekte und nicht die alltägliche Automatisierung, die den reibungslosen Betrieb der Kunden sicherstellt. ISO 27001 legt jedoch weniger Wert auf die Größe der Codebasis, sondern vielmehr darauf, ob sicherheitsrelevante Änderungen kontrolliert eingeführt werden. Dies entspricht den Bestimmungen der ISO/IEC 27001:2022, die kontrollierte Änderungen an Informationssystemen und sichere Entwicklungspraktiken in den Mittelpunkt stellen, unabhängig von der Größe der Codebasis (wie in der Norm ISO/IEC 27001:2022 festgelegt). Sie benötigen einen sicheren Entwicklungszyklus, der auch kleinere Aufgaben wie Skripte bewältigen kann, ohne Ihre Teams unnötig zu verlangsamen.
Gestalten Sie den SDLC so einfach, dass ihn die Ingenieure auch tatsächlich nutzen.
Sie gestalten den Softwareentwicklungszyklus (SDLC) so einfach, dass Ihre Entwickler ihn auch tatsächlich nutzen, indem Sie wenige, klare Schritte in Ihre bestehenden Tools wie PSA-, Git- und RMM-Plattformen integrieren. So erfolgen Risikoerfassung, -prüfung, -tests und -freigabe als Teil des normalen Arbeitsablaufs, und Sie behalten die Kontrolle, ohne zusätzlichen Verwaltungsaufwand. Der einzige SDLC, der Sie wirklich schützt, ist der, den Ihre Entwickler konsequent anwenden. Das bedeutet eine kurze, einprägsame Abfolge von Schritten, die in Ihre Ticket-, Versionskontroll- und RMM-Tools integriert ist. So generieren Ihre Entwickler ISO-konforme Nachweise als Nebenprodukt ihrer Arbeit und nicht als zusätzlichen Papierkram.
Ein praktikabler Softwareentwicklungszyklus für die Automatisierung passt auf eine Seite. Ein Muster, das Sicherheit und Geschwindigkeit in Einklang bringt, ist folgendes:
Schritt 1 – Idee und Risiko erfassen
Dokumentieren Sie, was das Skript tun soll, welche Kunden davon betroffen sind und was schiefgehen könnte, wenn es nicht ordnungsgemäß funktioniert, einschließlich der Auswirkungen auf Sicherheit und Datenschutz.
Schritt 2 – Entwurf und Entwicklung
Schreiben Sie das Skript in einer kontrollierten Umgebung unter Einhaltung vereinbarter Codierungsstandards, klarer Bereichsregeln und Muster für Fehlerbehandlung und Protokollierung.
Schritt 3 – Peer-Review
Bitten Sie einen anderen Ingenieur, die Absicht, den Umfang, die Handhabung von Anmeldeinformationen und die Fehlermodi zu überprüfen und Kommentare in Ihrem Ticket oder Repository zu protokollieren.
Schritt 4 – Testen in sicheren Umgebungen
Führen Sie das Skript in einem Labor- oder Staging-Tenant mit repräsentativen Systemen und Daten aus, um sowohl die erwartete Ausgabe als auch das Fehlerverhalten zu erfassen.
Schritt 5 – Freigabe zur Produktion
Für die Produktionsbereitstellung ist eine ausdrückliche Genehmigung durch eine dafür zuständige Person einzuholen, insbesondere bei privilegierten oder mandantenübergreifenden Automatisierungen.
Schritt 6 – Kontrollierte Bereitstellung
Überführen Sie das Skript mithilfe eines wiederholbaren, protokollierten Mechanismus in die Produktion, anstatt es ad hoc per Copy-and-Paste oder durch lokale Änderungen zu bearbeiten.
Schritt 7 – Beobachten und lernen
Die Ausführungsergebnisse überwachen, Anomalien untersuchen und Erkenntnisse aus Vorfällen, Fehlern oder Beinaheunfällen in die Konstruktion und die Normen einfließen lassen.
Der Umfang jedes einzelnen Schrittes kann dem Risiko angepasst werden. Ein einfaches Berichtsskript kann einer schnellen Peer-Review und einem Funktionstest unterzogen werden, während ein mandantenübergreifendes Sanierungsskript gründlichere Tests und eine breitere Freigabe erfordert.
Integrieren Sie diese Schritte nach Möglichkeit in die bereits von Ihrem Team verwendeten Tools. Beispielsweise kann ein PSA-Ticket Idee, Risiko und Genehmigung erfassen; das Git-Repository speichert Code und Review-Kommentare; die RMM-Plattform protokolliert Deployments und Ausführungsverlauf. So generieren Sie ISO-konforme Nachweise, ohne dass Ihre Entwickler in einem separaten System doppelt arbeiten müssen.
Integrieren Sie Sicherheit in Ihre Vorgehensweise beim Schreiben und Testen von Automatisierungslösungen.
Sie bauen Sicherheit in die Art und Weise ein, wie Sie Automatisierung schreiben und testen, indem Sie kleine, wiederholbare Gewohnheiten annehmen, wie z. B. das Vermeiden von fest codierten Geheimnissen, das vorsichtige Festlegen des Gültigkeitsbereichs, das Validieren von Eingaben und das klare Protokollieren, und indem Sie diese Gewohnheiten bei jeder Änderung wiederholen, anstatt sie für "große" Projekte aufzubewahren, sodass Sie die Wahrscheinlichkeit drastisch reduzieren, dass ein einfaches Versehen in einem Skript zu einem Multi-Tenant-Vorfall wird.
Sicheres Codieren von Skripten erfordert keine komplexen Frameworks, aber ein paar disziplinierte Gewohnheiten machen einen großen Unterschied:
- Geheimnisse sollten niemals fest im Code verankert werden; Zugangsdaten sollten zur Laufzeit aus einem Tresor oder einer gesicherten Konfiguration abgerufen werden.
- Den Umfang sorgfältig festlegen; standardmäßig sollte man sich auf eine explizite, kleine Anzahl von Systemen oder Mandanten konzentrieren, nicht auf „alle Geräte“.
- Überprüfen Sie Eingaben und Annahmen, bevor Sie Änderungen vornehmen; reagieren Sie schnell, wenn etwas nicht stimmt.
- Sicher scheitern; Skripte so entwerfen, dass sie im Fehlerfall die Systeme in einem sicheren Zustand hinterlassen und klar protokollieren.
- Protokollieren Sie aussagekräftig; halten Sie fest, was das Skript getan hat, wo und für wen, sodass Sie später Zusammenhänge herstellen können.
Die Tests sollten diese Denkweise widerspiegeln: Es sollte nicht nur geprüft werden, ob das Skript seine vorgesehene Funktion erfüllt, sondern auch, was bei fehlerhaften Eingaben, Systemausfällen oder falsch konfigurierten Berechtigungen passiert. Für kritische Automatisierungen empfiehlt sich eine standardisierte Testcheckliste, damit verschiedene Entwickler dieselben Risiken einheitlich bewerten können.
Notfalländerungen erfordern besondere Behandlung. Sie können einen beschleunigten Prozess ermöglichen, bei dem ein erfahrener Techniker ein neues oder modifiziertes Skript ausführt, um den Service schnell wiederherzustellen. Sie sollten jedoch eine Nachbearbeitung vorschreiben: die durchgeführten Maßnahmen dokumentieren, das Skript in den regulären Softwareentwicklungszyklus (SDLC) integrieren und prüfen, ob dauerhafte Verbesserungen erforderlich sind. So bleiben Sie reaktionsschnell, ohne dass „temporäre“ Lösungen zu dauerhaften, undokumentierten Risiken werden.
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.
Zusicherung gegenüber Kunden, Lieferanten und Wirtschaftsprüfern hinsichtlich des Automatisierungsrisikos
Sie überzeugen Kunden, Lieferanten und Auditoren von den Risiken der Automatisierung, indem Sie Ihre internen Kontrollen in klaren, verständlichen Beschreibungen darstellen und diese durch wiederholbare Nachweise untermauern. Wenn Sie darlegen können, wie Skripte definiert werden, wer sie ändern darf, wie sie protokolliert werden und wie Vorfälle behandelt werden, gewinnen die Beteiligten Vertrauen in Ihre Automatisierung – sie ist kontrolliert und nicht improvisiert.
Die ISMS.online-Umfrage 2025 zeigt, dass Kunden zunehmend erwarten, dass ihre Lieferanten sich an formale Rahmenwerke wie ISO 27001, ISO 27701, DSGVO, Cyber Essentials und SOC 2 sowie an neue KI-Standards anpassen.
Sobald Sie den Automatisierungsumfang festgelegt, Kontrollmechanismen ausgewählt, Skripte als Assets behandelt und einen grundlegenden Softwareentwicklungszyklus (SDLC) implementiert haben, sind Sie auf dem besten Weg, die Realität zu kontrollieren. Der letzte Schritt besteht darin, diese Zusammenhänge den relevanten Personen überzeugend zu vermitteln: Ihren Kunden, Lieferanten, Wirtschaftsprüfern und in vielen Fällen Ihren Datenschutz- und Rechtsabteilungen, die verstehen möchten, wie sich die Automatisierung auf ihr Risiko auswirkt.
Klarheit darüber, wie Sie Automatisierung einsetzen, trägt oft mehr zum Vertrauensaufbau bei als jede einzelne Kontrollmaßnahme.
Bieten Sie Ihren Kunden eine klare und ehrliche Geschichte über die Automatisierung.
Sie bieten Ihren Kunden eine klare und ehrliche Darstellung der Automatisierung, indem Sie erklären, was in ihrer Umgebung läuft, wie diese von anderen Mandanten getrennt ist und welche Sicherheitsvorkehrungen Fehler oder Kompromittierungen verhindern. So beruhigen klare Antworten auf diese Fragen Unternehmensleiter, CISOs und Datenschutzbeauftragte und erleichtern es ihnen, den von Ihrem MSP benötigten Zugriffsgrad zu rechtfertigen.
Die Mehrheit der Organisationen, die an der ISMS.online-Umfrage „State of Information Security 2025“ teilnahmen, gab an, im vergangenen Jahr von mindestens einem Sicherheitsvorfall eines Drittanbieters oder Lieferanten betroffen gewesen zu sein.
Unternehmenskunden und regulierte Kunden erkennen zunehmend, dass ihr Risiko davon abhängt, wie ihr Managed Service Provider (MSP) Fernzugriff und Automatisierung handhabt. Umfragen zum Umgang mit Cybersicherheit als Geschäftsrisiko zeigen, dass Vorstände und Führungskräfte Cybersicherheit und die Sicherheit von Drittanbietern mittlerweile als zentrales Geschäftsrisiko betrachten. Dies betrifft natürlich auch, wie MSPs Fernzugriff und Automatisierung handhaben (beispielsweise die Studie des Ponemon Institute). Management der Cybersicherheit als Geschäftsrisiko auf ponemon.org). Vertrauen entsteht, wenn man in einfacher Sprache erklären kann:
- welche Arten von Skripten und Automatisierungen Sie in ihrer Umgebung ausführen
- wie diese entworfen, genehmigt und überwacht werden
- wie man verhindert, dass die Änderungen eines Kunden einem anderen schaden
Einfache Diagramme und kurze Beschreibungen sind besser geeignet als umfangreiche Strategiepapiere. Beispielsweise können Sie Folgendes darstellen:
- Ihre RMM-Plattform als zentrales Werkzeug
- separate Mandantengruppen oder Ordner für jeden Kunden
- Rollen, die einschränken, wer globale versus mandantenspezifische Jobs ausführen darf
- Protokollierungsflüsse werden in Ihre Überwachungs- oder SIEM-Tools eingespielt.
Anschließend können Sie hervorheben, wie Ihre ISO-27001-Kontrollen dieses Design unterstützen: Zugriffsprüfungen, Genehmigungen von Änderungen, Reaktion auf Sicherheitsvorfälle, Lieferantenmanagement und, wo personenbezogene Daten verarbeitet werden, Datenschutz-Governance und Folgenabschätzungen. Indem Sie diese Vorgehensweise mit Ihren Verträgen und Datenschutzvereinbarungen abstimmen, stellen Sie sicher, dass keine Diskrepanz zwischen Ihren Zusagen und der tatsächlichen Umsetzung durch Ihre Automatisierung besteht.
Die Fragen von Prüfern und Aufsichtsbehörden sollen leicht zu beantworten sein.
Sie erleichtern die Beantwortung von Fragen von Prüfern und Aufsichtsbehörden, indem Sie standardisierte Nachweispakete erstellen, die Automatisierungsressourcen, Rollen, Änderungsprotokolle und Logs Ihrer Hauptplattformen aufzeigen. So können Sie anhand eines durchgängigen Beispiels einer Skriptänderung und deren Ausführung demonstrieren, dass Sie die Kontrolle haben, ohne bei jedem Besuch improvisieren zu müssen. Prüfer und Aufsichtsbehörden erhalten den Beweis, dass Sie Ihre Automatisierungsrisiken verstehen und beherrschen. ISO 27001-Checklisten und ähnliche Leitfäden betonen durchgängig die Bedeutung strukturierter Nachweise für die Identifizierung, Bewertung und Behandlung von Informationssicherheitsrisiken. Der Nachweis dieser Nachweise auch für Automatisierungsrisiken vereinfacht die Bewertungen erheblich (z. B. mithilfe von Leitfäden wie der ISO 27001-Compliance-Checkliste).
Dies wird erleichtert, indem wiederverwendbare „Nachweispakete“ für risikoreiche Automatisierungsbereiche zusammengestellt werden: ein kleines Paket aus Dokumenten und Exporten, das gemeinsam Richtlinien, Prozesse und Vorgehensweisen aufzeigt. Für Ihre Haupt-RMM-Plattform könnten Sie beispielsweise Folgendes einbeziehen:
- relevante Auszüge aus Richtlinien und Verfahren
- Eine Ansicht des Anlagenverzeichnisses der Plattform und ihrer Skriptbibliothek
- ein kürzlich veröffentlichter Zugriffsprüfungsbericht
- Beispiel eines Änderungstickets und einer Codeüberprüfung für ein Skript
- ein Protokollauszug, der die Skriptausführungen und Ergebnisse anzeigt
Eine strukturierte ISMS-Plattform wie ISMS.online hilft Ihnen, all diese Informationen mit spezifischen Kontrollen, Audits und Risiken zu verknüpfen, sodass Sie nicht jedes Mal nach Belegen suchen müssen, wenn eine Frage gestellt wird. Durch die Auswertung von Auditergebnissen, Kundenfragebögen und speziell als „automatisierungsbezogen“ gekennzeichneten Vorfällen können Sie zudem Muster erkennen und Verbesserungen direkt in Ihr ISMS einfließen lassen.
Buchen Sie noch heute eine Demo mit ISMS.online
ISMS.online bietet Ihnen eine zentrale, praxisorientierte Umgebung, um Ihre Automatisierungsressourcen, Risiken, Kontrollen und Nachweise zu verknüpfen. So verwandeln Sie Skripte von einem potenziellen Risiko in eine kontrollierte Stärke gemäß ISO 27001 und setzen Ihre guten Absichten in ein funktionierendes System um. Sie können Automatisierungsressourcen, Risiken, Kontrollen und Nachweise zentral modellieren, während Ihre Ingenieure weiterhin die gewohnten RMM-, Git- und PSA-Tools nutzen. Statt mit Tabellenkalkulationen, freigegebenen Laufwerken und Ad-hoc-Dokumenten zu jonglieren, sehen Sie, wie Skripte, Plattformen und Prozesse in Ihr ISO 27001-konformes ISMS integriert sind und machen die Automatisierung Ihres Managed Service Providers (MSP) zu einer sichtbaren Stärke statt zu einem versteckten Risiko.
Rund zwei Drittel der Organisationen, die an der ISMS.online-Umfrage „State of Information Security 2025“ teilnahmen, gaben an, dass die Geschwindigkeit und das Ausmaß der regulatorischen Änderungen die Einhaltung der Vorschriften zunehmend erschweren.
Sehen Sie, wie die Frameworks in diesem Leitfaden in einem Live-ISMS aussehen.
Den wahren Wert eines automatisierungsfähigen ISMS erkennt man, wenn die eigenen Tools und Services darin abgebildet werden und nicht nur theoretisch beschrieben sind. Die größte Klarheit gewinnt man, wenn man die eigene Umgebung in einem funktionierenden ISMS und nicht in abstrakten Diagrammen sieht. Eine kurze, zielgerichtete Demonstration kann die Konzepte dieses Artikels in konkrete Bildschirme, Workflows und Nachweisansichten übersetzen, sodass man beurteilen kann, wie gut sie zu den aktuellen Tools, Mitarbeitern und Kunden passen.
Wenn Sie Ihre eigene Umgebung in diesen Beispielen wiedererkennen, ist eine kurze Demonstration oft der schnellste Weg, um zu sehen, wie es besser aussehen könnte. In einer typischen Sitzung können Sie:
- Erläutern Sie, wie Automatisierungsanlagen und -plattformen im Anlagenregister dargestellt werden.
- erfahren Sie, wie Risiken wie massenhafte Fehlkonfigurationen oder der Missbrauch von Zugangsdaten erfasst und behandelt werden.
- Beachten Sie die Zuordnungen in Anhang A, die explizit auf Skripte, RMM-Aufträge und Runbooks verweisen.
- Untersuchen Sie, wie Nachweise wie Änderungsaufzeichnungen, Genehmigungen und Protokolle mit Kontrollen verknüpft werden können.
Da ISMS.online sowohl für technische als auch für nicht-technische Anwender konzipiert ist, können Ihr Geschäftsführer, Ihr Serviceleiter und Ihr Sicherheitsbeauftragter eine gemeinsame Sicht auf das Automatisierungsrisiko teilen, ohne sich durch unstrukturierte Skripte oder Konsolenbildschirme wühlen zu müssen.
Beginnen Sie klein und skalieren Sie dann in Ihrem eigenen Tempo.
Sie können klein anfangen, indem Sie einen wirkungsvollen Automatisierungsbereich in Ihr ISMS integrieren und dann, sobald Sie mehr Erfahrung gesammelt haben, auf weitere Tools, Teams und Kunden ausweiten. Ein erster, bescheidener Erfolg, wie beispielsweise die Optimierung der Governance einer RMM-Plattform, erleichtert oft anstehende Audits und gibt Ihren anspruchsvollsten Kunden Sicherheit.
Viele Managed Service Provider (MSPs) beginnen mit einem einzigen, klar definierten Anwendungsfall, wie zum Beispiel:
- Eine RMM-Plattform und ihre risikoreichsten Skripte in das ISMS einbringen
- Dokumentation des Softwareentwicklungszyklus und des Zugriffsmodells für die Automatisierung in einer Service-Linie
- Erstellung des ersten auf Automatisierung ausgerichteten Nachweispakets für ein bevorstehendes Audit
Von dort aus können Sie dieselben Vorgehensweisen auf andere Tools, Teams und Kunden übertragen, sobald Zeit und Ressourcen dies zulassen. Ein Gespräch mit einem Spezialisten von ISMS.online hilft Ihnen dabei, einen realistischen 90-Tage-Plan zu entwerfen, um Skripte und Automatisierung einzuführen, Verantwortlichkeiten zuzuweisen und Nachweismechanismen zu etablieren, die der Prüfung durch Kunden und Auditoren standhalten.
Wenn Sie als Führungskraft im Managed Service Provider (MSP), Sicherheitsverantwortlicher oder leitender Ingenieur Automatisierung als sichtbare Stärke und nicht als unangenehmes Risiko nutzen möchten, ist die Buchung einer Demo bei ISMS.online der nächste logische Schritt. Sie erhalten damit und Ihrem Führungsteam eine konkrete Grundlage, um zu entscheiden, wie Sie MSP-Scripting und -Automatisierung gemäß ISO 27001 in der Praxis umsetzen – nicht nur auf dem Papier.
KontaktHäufig gestellte Fragen (FAQ)
Wie sollte ein Managed Service Provider (MSP) entscheiden, welche Skripte und Automatisierungen in den Geltungsbereich des ISO 27001 ISMS gehören?
Beziehen Sie alle Skripte, Runbooks, RMM-Jobs oder Automatisierungspipelines in den Geltungsbereich ein, die Dienste, Systeme oder Daten innerhalb des Geltungsbereichs verändern können, unabhängig vom technischen Ausführungsort. Der praktische Test ist einfach: Wenn die Automatisierung die Vertraulichkeit, Integrität oder Verfügbarkeit von Diensten beeinträchtigen kann, die unter Ihr ISO 27001-Zertifikat fallen, gehört sie in das ISMS.
Wie können wir dieses Prinzip in eine wiederholbare Methode zur Abgrenzung des Untersuchungsbereichs umsetzen?
Arbeiten Sie von oben nach unten, ausgehend von Diensten und Kunden, nicht von unten nach oben, ausgehend von Ordnern und Dateien:
- Beginnen Sie mit den Dienstleistungen, Kunden und Standorten, die Sie als Geltungsbereich deklariert haben.
- Listen Sie für jedes dieser Elemente Plattformen und Automatisierungen auf, die Folgendes ermöglichen:
- Konfiguration in der Produktionsumgebung ändern oder bereitstellen.
- Kundendaten oder sensible interne Daten lesen, schreiben, löschen oder verschieben.
- Kritische Dienste starten, stoppen oder wesentlich beeinträchtigen.
Sie werden fast immer Folgendes miteinbeziehen:
- RMM-Plattformen und deren Automatisierungsmodule, die auf den betroffenen Geräten oder Mandanten eingesetzt werden.
- Gemeinsam genutzte Skript-Repositories und interne Bibliotheken, die regelmäßig Produktionsprozesse speisen.
- Orchestrierungspipelines (einschließlich CI/CD), die Systeme im Geltungsbereich bereitstellen, patchen, außer Betrieb nehmen oder härten.
- Geplante Jobs in Cloud-Plattformen, die Backups, Identität, Konfiguration oder Überwachung für relevante Assets verwalten.
Sie können in der Regel mit klarer Begründung ausschließen:
- Labore, die physisch und logisch voneinander getrennt sind, einschließlich separater Identitäten und ohne Möglichkeit des Kopierens und Einfügens in die Produktion.
- Einmalige Testskripte in isolierten Ressourcengruppen, die nicht auf aktive Mandanten übertragen werden können.
- Schulung von Mandanten ohne Kundendaten, ohne gemeinsam genutzte Servicekonten und ohne Produktionsanbindung.
Wenn Ihre Entwickler regelmäßig Logik aus einer internen Bibliothek in Prozesse kopieren, die Live-Systeme betreffen, sollte diese Bibliothek als relevant betrachtet werden. Erfassen Sie diese Automatisierungen in Ihrem Anlagenverzeichnis mit einem Verantwortlichen, verknüpften Diensten/Kunden und einer grundlegenden Risikobewertung. Die Verwaltung dieser Prozesse in einem Informationssicherheitsmanagementsystem wie ISMS.online erleichtert es Auditoren erheblich, eine lückenlose Kette von der Geltungsbereichsdefinition über den Dienst und die Plattform bis hin zur Automatisierung nachzuweisen, ohne in letzter Minute Tabellenkalkulationen zusammensuchen zu müssen.
Welche Kontrollbereiche des Anhangs A der ISO 27001:2022 sind für die MSP-Automatisierung am wichtigsten?
Für Managed Service Provider (MSPs) sind die in Anhang A aufgeführten Kontrollen besonders relevant, da sie regeln, wer Automatisierungen ändern darf, wie sicher diese Änderungen erfolgen und wie Aktionen protokolliert und überprüft werden. Ein separater Abschnitt „Automatisierung“ ist nicht erforderlich; vielmehr muss aufgezeigt werden, wie die Automatisierung in Ihre bestehenden Kontrollstrukturen integriert ist.
Worauf sollten wir uns bei Skripten, Runbooks und RMM-Jobs zuerst konzentrieren?
In der Praxis leisten fünf Themen den größten Beitrag:
1. Zugriffskontrolle für Automatisierungsidentitäten
Relevante Kontrollen gemäß Anhang A umfassen A.5.15, A.5.16, A.5.18 (Zugriff, Identität, Rechte) und A.8.2, A.8.5 (Privilegierter Zugriff, sichere Authentifizierung). Wenden Sie diese wie folgt an:
- Festlegung, wer für jede Plattform die Automatisierung erstellen, genehmigen und ausführen darf.
- Servicekonten, API-Schlüssel und Token werden als privilegierte Zugangsdaten mit Eigentümern, Berechtigungen, Überprüfungen und Ablaufdatum behandelt.
- Vermeidung anonymer „God-Mode“-Konten in RMM-Tools und Orchestrierungs-Engines.
2. Veränderungs- und Betriebsmanagement
Die Anhänge A.8.9 (Konfigurationsmanagement), A.8.19 (Softwareinstallation) und A.8.32 (Änderungsmanagement) sollten eindeutig auch für die Automatisierung gelten. Zeigen Sie Folgendes:
- Änderungen an Skripten und Jobs werden angefordert, einer Risikobewertung unterzogen und sind über Tickets nachvollziehbar.
- Code und Umfang werden entsprechend ihren Auswirkungen geprüft und getestet.
- Genehmigungen und Rollbacks werden in Service-Management- oder Git-Workflows erfasst.
3. Sichere Entwicklung für „kleinen“ Code
Die in A.8.24–A.8.29 (Kryptografie, Softwareentwicklungszyklus, Architektur, sichere Programmierung, Tests, ausgelagerte Entwicklung) festgelegten Kontrollen gelten nicht nur für große Anwendungen. Für Skripte und Pipelines bedeuten sie Folgendes:
- Verwendung von Versionskontrolle und Kennzeichnung von Produktionsversionen.
- Einhaltung einfacher Standards für Parameter, Fehlerbehandlung und Protokollierung.
- Die Entwicklungs-/Testumgebung sollte von der Produktionsumgebung getrennt bleiben, selbst wenn es sich nur um separate Mandanten und Gruppen handelt.
- Wo möglich, grundlegende statische Prüfungen oder Linter anwenden.
4. Protokollierung, Überwachung und Lernen
Die Anhänge A.8.15 (Protokollierung), A.8.16 (Überwachung) und A.5.27–A.5.28 (Lernen aus Vorfällen, Beweissicherung) bilden die Grundlage Ihrer Automatisierungsarchitektur. Sie sollten Folgendes nachweisen können:
- Protokolle, die Auskunft darüber geben, wer was, wo, wann und mit welcher Wirkung ausgeführt hat.
- Warnmeldungen bei Ausfällen oder ungewöhnlichen Abläufen von kritischen Jobs.
- Beispiele, in denen Automatisierungsprotokolle bei der Überprüfung von Vorfällen verwendet wurden und zu Änderungen führten.
5. Lieferanten- und Mehrmietermanagement
Da die MSP-Automatisierung stark von Drittanbieterplattformen abhängt, sind die Kontrollen A.5.19–A.5.23 (Lieferantenbeziehungen, Cloud-Dienste, Lieferkette) von zentraler Bedeutung:
- Prüfen Sie, wie Ihre RMM-, PSA- und Cloud-Anbieter die Mandantenisolierung, Protokollierung und starke Authentifizierung durchsetzen.
- Halten Sie fest, wie Sie über Vorfälle und Sicherheitslücken informiert werden.
- Verknüpfen Sie diese Lieferantenbewertungen mit den gleichen Kontrollen gemäß Anhang A, die Sie intern anwenden.
Eine praktische Möglichkeit, dies zu verknüpfen, ist eine Matrix, die die Themen von Anhang A Ihren tatsächlichen Werkzeugen und den erwarteten Verhaltensweisen zuordnet. Wenn Sie diese Matrix zusammen mit der Anwendbarkeitserklärung und dem Risikoregister in Ihrem ISMS pflegen, können Prüfer schnell von den übergeordneten Klauseln zur Realität Ihrer Skripte, Jobs und Pipelines gelangen.
Wie kann ein kleiner Managed Service Provider (MSP) Zugriffsrechte und Funktionstrennung im Bereich der Automatisierung regeln?
Ein kleiner Managed Service Provider (MSP) kann Zugriffsrechte und Aufgabentrennung steuern, indem er für jede Automatisierungsplattform wenige, klar definierte Befugnisse festlegt und sichtbare Kontrollmechanismen dort einbaut, wo diese Befugnisse konzentriert sind. ISO 27001 erwartet keine Trennung im Unternehmensmaßstab in einem Fünf-Personen-Team, aber sie verlangt, dass Sie nachweisen, dass Automatisierung keine unkontrollierte Supermacht darstellt.
Welches einfache Rollenmodell eignet sich, wenn nur wenige Ingenieure die Automatisierung betreuen?
Definieren Sie für jede Automatisierungskomponente (RMM, Skript-Repository, Orchestrierungs-Engine, Geheimnisspeicher) drei Berechtigungen:
-
Macht verändern – Automatisierung erstellen und anpassen
Beschränken Sie dies auf namentlich genannte Autoren und verwenden Sie authentifizierte Commits, damit Änderungen nachvollziehbar sind. Vermeiden Sie direkte Eingriffe an Endpunkten, die keine Historie hinterlassen. -
Genehmigungsmacht – Automatisierung in der Produktion ermöglichen
Trennen Sie die Autoren nach Möglichkeit und nutzen Sie Peer-Review in Git oder Tickets, um eine explizite Freigabe zu erhalten, insbesondere bei mandantenübergreifenden oder besonders wichtigen Aufgaben. -
Ausführungsleistung – Automatisierungen in Live-Umgebungen ausführen oder planen
Beschränken Sie umfassende oder mandantenübergreifende Ausführungen auf eine kleine Bedienergruppe und vermeiden Sie generische Administratorkonten. Falls Servicekonten erforderlich sind, dokumentieren Sie genau, welche Aufgaben sie unterstützen.
Wenn eine Person mehr als eine Macht ausüben muss, gleichen Sie dies mit Detektivkontrollen aus:
- Peer-Review oberhalb einer bestimmten Risikoschwelle.
- Stichprobenartige Überprüfungen des Managements hinsichtlich risikobehafteter Automatisierung.
- Vierteljährliche Zugriffsüberprüfungen von RMM-Tools, Repositories und Vaults, deren Ergebnisse im ISMS hinterlegt werden.
Behandeln Sie die nicht-menschlichen Identitäten, die der Automatisierung zugrunde liegen – Servicekonten, API-Schlüssel, Token – als eigenständige privilegierte Benutzer. Weisen Sie ihnen Verantwortliche zu, beschränken Sie ihren Zugriffsumfang, speichern Sie sie in einem Tresor und wechseln Sie sie regelmäßig sowie bei Ausscheiden von Mitarbeitern. Wenn Sie Ihr ISMS offenlegen und nachweisen können, dass dieses Muster konsequent angewendet wird, sind die Prüfer in der Regel davon überzeugt, dass die Einschränkungen kleiner Teams angemessen gehandhabt werden.
Wie sieht ein praktikabler, sicherer Entwicklungszyklus für MSP-Skripte konkret aus?
Ein praktikabler, sicherer Entwicklungszyklus für MSP-Skripte ist ein kompakter, wiederholbarer Pfad von den Geschäftsanforderungen bis zur Produktion, der sich an den bestehenden Arbeitsweisen Ihrer Entwickler orientiert. Ziel ist es, ausreichend Struktur und Nachweise für ISO 27001 zu schaffen, ohne dabei so viel Aufwand zu betreiben, dass die Vorgaben umgangen werden.
Welche Phasen sollte jedes Drehbuch in Produktionsqualität durchlaufen?
Die meisten Anbieter können ein einfaches Acht-Schritte-Muster unterstützen:
-
Bedarf und Umfang erfassen
Erstellen Sie ein Ticket, in dem Sie erläutern, warum das Skript benötigt wird, welche Dienste oder Kunden betroffen sind und wie ein erfolgreiches Ergebnis aussieht. -
Denken Sie an Risiko und Scheitern.
Weisen Sie auf mögliche Probleme wie zu breite Zielgruppenansprache, Datenleckage, Auswirkungen auf die Leistung oder regulatorische Konsequenzen hin und beschreiben Sie, wie Sie diese reduzieren wollen. -
Entwicklung in einem versionskontrollierten Repository
Verwenden Sie Git oder ein gleichwertiges Tool mit einem grundlegenden Standard für Struktur, Parameter, Protokollierung und Fehlerbehandlung und lagern Sie Geheimnisse in einen Tresor oder sichere Variablen aus. -
Holen Sie sich eine Peer-Review
Ein zweiter Ingenieur prüft Logik, Umfang und Sicherheitsvorkehrungen und erfasst Kommentare und Genehmigungen im Pull Request oder Ticket. -
Sicher testen
Führen Sie das Skript in einem Labor-Tenant, einer Testgruppe oder einer nicht kritischen Umgebung aus, die der Produktionsumgebung ähnelt, und protokollieren Sie kurz, was Sie getestet haben und was dabei herauskam. -
Für die Produktion freigeben
Ein namentlich genannter Genehmiger unterzeichnet das Projekt unter Angabe der erwarteten Auswirkungsstufe (niedrig, mittel oder hoch) und etwaiger Bedingungen wie Laufzeitfenster oder Pilotziele. -
Bereitstellung über protokollierte Mechanismen
Führen Sie die Aufgabe über Ihre RMM-Plattform, Orchestrierungspipeline oder ein ähnliches Tool aus, damit Job-ID, Initiator, Ziele und Ergebnis erfasst werden. -
Überwachen Sie die ersten Läufe und lernen Sie
Achten Sie bei den ersten Durchläufen genauer darauf, erfassen Sie Probleme und wenden Sie die gewonnenen Erkenntnisse auf zukünftige Automatisierungsmuster an.
Bei Projekten mit hohem Einfluss oder mandantenübergreifenden Projekten sollten die Risikobewertung, die Tests und die Genehmigungsschritte vertieft werden; bei weniger kritisch geführten Wartungsskripten sollten diese so schlank wie möglich gehalten werden, wobei die Überprüfung und Protokollierung erhalten bleiben. Wenn Sie einem Auditor ein konkretes Beispiel vom Ticket über den Code bis hin zu den Protokollen präsentieren können, wird Ihr Softwareentwicklungszyklus greifbar statt theoretisch.
Wie sollte ein Managed Service Provider (MSP) die Protokollierung und Überwachung für die Automatisierung gemäß ISO 27001 strukturieren?
Sie sollten Protokollierung und Überwachung so strukturieren, dass Sie wichtige automatisierte Aktionen rekonstruieren und nachweisen können, dass die relevanten Signale regelmäßig ausgewertet werden. ISO 27001 legt mehr Wert auf Rückverfolgbarkeit und Lernprozesse als auf ein bestimmtes Protokollierungsprodukt.
Welche Fragen sollten wir mithilfe unserer Automatisierungsprotokolle stets beantworten können?
Bei jeder wesentlichen automatisierten Änderung sollten Sie folgende Fragen beantworten können:
- Was wurde ausgeführt? (Skriptname, Job-ID, Version, falls möglich).
- Wo wurde es ausgeführt? (Mandant, Gerätegruppe, Abonnement, Umgebung).
- Unter welcher Identität? (Dienstkonto, Name: Admin, Operator).
- Wer hat es genehmigt? (Ticket, Überprüfung, Änderungsprotokoll).
- Was war das Ergebnis? (Erfolg/Misserfolg, Umfang und Schlüsselfehler).
Sie können diese Fragen unterstützen, indem Sie:
- Aktivieren Sie die detaillierte Protokollierung in Ihren RMM- und Orchestrierungsplattformen, einschließlich Parametern, Zielen und Ergebnissen.
- Verknüpfen Sie Bereitstellungsläufe mit Codeversionen in Ihrem Repository.
- Sicherstellen, dass Tickets Kontextinformationen, Risikohinweise und Genehmigungen enthalten.
- Hochriskante Automatisierungsereignisse werden gegebenenfalls in einem zentralen Protokoll oder SIEM zusammengefasst.
Legen Sie anhand von Kundenverträgen, gesetzlichen Vorgaben und Ihrem eigenen Untersuchungsbedarf fest, wie lange die verschiedenen Protokolle aufbewahrt werden müssen. Für Skripte und Prozesse, die viele Mandanten oder große Datensätze betreffen können, sollten Sie zusätzliche Maßnahmen in Betracht ziehen.
- Warnmeldungen bei Ausführungen außerhalb der Geschäftszeiten oder unerwartet hohen Zielzahlen.
- Einfache Dashboards, die aktuelle, besonders wichtige Stellenangebote anzeigen.
- Regelmäßige Überprüfungen, die sich speziell mit risikobehafteten Automatisierungsaktivitäten befassen.
Bereiten Sie sich auf ein ISO 27001-Audit vor, indem Sie einige aussagekräftige Beispiele auswählen und die entsprechenden Nachweise zusammenfassen: Ticket, Code, Genehmigungen, Ausführungsprotokolle und alle Folgemaßnahmen. Die detaillierte Darstellung dieser Beispiele macht Ihren Protokollierungs- und Überwachungsansatz konkret und glaubwürdig.
Welche Art von Nachweisen eignet sich am besten, um die Automatisierungskontrolle in einem ISO 27001-Audit zu belegen?
Die überzeugendsten Nachweise zeigen den gesamten Prozess anhand einiger repräsentativer Automatisierungsfälle, anstatt umfangreiche Theoriesammlungen zu präsentieren. Prüfer möchten sehen, dass sich Ihre Richtlinien und die Zuordnungen gemäß Anhang A in der Praxis widerspiegeln, wie Sie Skripte und Jobs erstellen, genehmigen und ausführen.
Was sollte in einem Nachweispaket für Automatisierungsprozesse enthalten sein?
Für jede wichtige Automatisierungsplattform oder Codebibliothek sollten Sie Folgendes zusammenstellen:
- Umfang und Nachweis der Vermögenswerte:
- Einträge im Anlagenregister für die Plattform und wichtige Skriptbibliotheken mit Eigentümern und verknüpften Diensten oder Kunden.
- Auszüge aus der Geltungsbereichsbeschreibung, die diese Komponenten innerhalb Ihrer ISO 27001-Grenze verorten.
- Verknüpfung von Risiko und Kontrolle:
- Risikodatensätze, die auf Missbrauch, Ausfall oder Schwächen von Zulieferern hinweisen, in Verbindung mit Maßnahmen gemäß Anhang A wie Zugriffskontrolle, Änderungsmanagement, Softwareentwicklungszyklus (SDLC) und Protokollierung.
- Auszüge aus Richtlinien und Verfahren, die beschreiben, wie die Automatisierung geregelt wird.
- Beispiele für Zugriff und Änderung:
- Aktuelle Zugriffsprüfungsergebnisse für Ihr RMM, Ihre Repositories, Ihre Orchestrierungsplattformen und Ihren Geheimnisspeicher.
- Ein oder zwei Änderungsdatensätze mit zugehörigen Git-Diffs und Review-Kommentaren für Skripte, die in die Produktion übergegangen sind.
- Ausführungs- und Überwachungsprotokolle:
- Auszüge aus Protokolldateien zu kürzlich durchgeführten sinnvollen Jobs, hervorgehoben, um zu zeigen, wer sie initiiert hat, was sie zum Ziel hatten und wie mit Fehlern umgegangen wurde.
- Alle Vorfälle oder Nachuntersuchungsberichte, bei denen die Automatisierung eine Rolle spielte und zu Verbesserungen führte.
- Lieferantenüberwachung:
- Zusammenfassungen aus Lieferantenbewertungen, die Mandantenisolierung, Authentifizierung, Protokollierung und Vorfallskommunikation für Ihre RMM- und Cloud-Plattformen abdecken.
Wenn Sie diese Elemente in einer ISMS-Plattform wie ISMS.online pflegen – also Anlagen, Risiken, Kontrollen, Aufzeichnungen und Lieferanteninformationen verknüpfen – können Sie Prüfer klar von den Verweisen in Anhang A bis hin zu konkreten Automatisierungsartefakten führen. Dadurch verschiebt sich die Diskussion von der Frage „Haben Sie eine Richtlinie für Skripte?“ hin zu „Zeigen Sie uns, wie die Automatisierung in Ihr Managementsystem integriert ist“. Genau hier heben sich erfahrene Managed Service Provider (MSPs) hervor.
Damit sich das Ganze nicht wie eine einmalige, hektische Angelegenheit anfühlt, sondern wie eine wiederholbare Stärke, ist die Zentralisierung Ihres ISMS, einschließlich aller Automatisierungsressourcen und -datensätze, ein wichtiger Schritt. So können Sie beruhigt Fragen zu Skripten, RMM-Jobs und Pipelines stellen, da Sie auf eine zentrale Datenquelle verweisen können, anstatt auf ein Flickwerk aus Ordnern und Ad-hoc-Exporte.
