Secure Deployment

Wir haben gesehen, wie Patch Management Systeme aktuell hält und wie Configuration Management für einen definierten Konfigurationszustand sorgt. Doch bevor ein neuer Mitarbeiter produktiv arbeiten kann, müssen noch weitere Voraussetzungen erfüllt sein.

„Wenn ein neuer Kollege anfängt, reicht es dann, ihm ein fertig konfiguriertes Notebook hinzustellen?“

„Nein. Das Endgerät muss sicher eingerichtet sein – und der Mitarbeiter muss genau die Anwendungen und Berechtigungen erhalten, die er für seine Arbeit benötigt.“

Damit sind wir beim Thema „Sicheres Bereitstellen eines Endgerätes“ – gängigerweise als Secure Deployment bezeichnet. Unter Deployment versteht man die Bereitstellung von IT-Systemen, Anwendungen oder Änderungen für den produktiven Einsatz.

Secure Deployment sorgt dafür, dass diese Bereitstellung kontrolliert erfolgt und die notwendigen Sicherheitsanforderungen bereits vor dem produktiven Einsatz berücksichtigt werden. Bei einem neuen Arbeitsplatz lassen sich zwei Bereiche unterscheiden, wie die folgenden Flipcards zeigen:

Device Provisioning

Device Provisioning: Das Endgerät wird eingerichtet, aktualisiert und in die Sicherheits- und Management-Infrastruktur des Unternehmens eingebunden.

Identity & Access Provisioning

Identity & Access Provisioning: Für den Mitarbeiter werden die benötigten Konten, Anwendungen, Rollen und Berechtigungen bereitgestellt.

Beide Bereiche gehören zusammen. Ein sicher konfiguriertes Notebook allein ergibt noch keinen sicher bereitgestellten Arbeitsplatz.

Am Anfang steht eine vertrauenswürdige Ausgangsbasis, beispielsweise ein freigegebenes Betriebssystem-Image, ein automatisierter Provisioning-Prozess oder ein kontrolliertes Software-Repository. Anschließend wird das Endgerät eingerichtet.

Dazu können z.B. gehören:

  • Betriebssystem und benötigte Anwendungen,
  • Sicherheitsrichtlinien,
  • Endpoint-Schutz und Personal Firewall,
  • Laufwerksverschlüsselung,
  • Netzwerk- und VPN-Konfiguration,
  • Zertifikate,
  • Einbindung in das Endpoint Management.

Hier greifen die bereits behandelten Prozesse ineinander:

  • Das Configuration Management legt mit einer Baseline fest, wie ein bestimmter Gerätetyp konfiguriert sein soll. Der Deployment-Prozess sorgt dafür, dass diese Konfiguration auf dem neuen Endgerät tatsächlich umgesetzt wird.
  • Auch der Patchstand muss berücksichtigt werden. Selbst ein freigegebenes Installationsimage kann bereits veraltet sein. Vor der produktiven Nutzung sollte das Gerät deshalb die erforderlichen Sicherheitsupdates erhalten.

Ein Secure-Deployment-Prozess kann sich folgendermaßen darstellen. Klicke auf das Symbol oben rechts zum Maximieren für eine bessere Lesbarkeit:

Zu einem Arbeitsplatz gehört nicht nur das Endgerät. Ein Mitarbeiter benötigt beispielsweise Zugriff auf:

  • E-Mail und Kollaborationsplattformen
  • Unternehmensanwendungen
  • Dateiablagen
  • Datenbanken
  • Cloud-Ressourcen
  • etc.

Dabei gilt das Least-Privilege-Prinzip: Benutzer sollten nur die Berechtigungen erhalten, die sie für ihre Aufgaben tatsächlich benötigen. Eine Möglichkeit, dies strukturiert umzusetzen, ist Role-Based Access Control (RBAC).

Über RBAC haben wir bereits ausführlich gesprochen. Kurz zur Wiederholung für den Kontext: Bei RBAC werden Berechtigungen Rollen zugeordnet. Benutzer erhalten anschließend die für ihre Tätigkeit erforderlichen Rollen. Ein vereinfachtes Beispiel:

Rolle „Vertrieb“:

  • Zugriff auf das CRM-System
  • Zugriff auf die Vertriebsablage
  • Zugriff auf benötigte Kollaborationsbereiche

Rolle „Teamleitung Vertrieb“:

  • Berechtigungen der Vertriebsrolle
  • zusätzliche Reporting- und Freigabefunktionen

Damit müssen Berechtigungen nicht für jeden Mitarbeiter vollständig neu zusammengestellt werden.

Auch eine korrekt definierte Rolle sollte nicht beliebig vergeben werden. In größeren Unternehmen werden zusätzliche Zugriffe deshalb häufig über einen Request-and-Approval-Prozess beantragt. Beispielsweise benötigt eine neue Mitarbeiterin Zugriff auf eine bestimmte Unternehmensanwendung.

Der Prozess könnte folgendermaßen aussehen:

  1. Der Abteilungsleiter beantragt den erforderlichen Zugriff.
  2. Ein zuständiger Verantwortlicher prüft und genehmigt den Antrag.
  3. Die Genehmigung erfolgt nach bestimmten Kriterien.
  4. Die Rolle bzw. Berechtigung wird provisioniert
  5. Die Vergabe wird dokumentiert.

Dadurch wird nachvollziehbar, wer welchen Zugriff aus welchem Grund erhalten hat und wer ihn genehmigt hat.

Solche Prozesse können durch Software und Systeme aus den Bereichen Identity and Access Management (IAM), Identity Governance and Administration (IGA) oder IT Service Management (ITSM) unterstützt werden. Beispiele sind:

  • Microsoft Entra ID Governance: Zugriffe können beispielsweise über Access Packages gebündelt und mit Request- und Approval-Prozessen verbunden werden.
  • Okta Identity Governance: Access Requests können unter anderem für Anwendungen, Gruppen oder gebündelte Berechtigungen verwendet werden.
  • ServiceNow: Zugriffsanforderungen können über Service-Request- und Approval-Workflows abgebildet werden.

Damit kann ein Abteilungsleiter beispielsweise über ein Intranet-Portal die benötigte Rolle für einen Mitarbeiter beantragen. Nach der vorgesehenen Genehmigung kann die Bereitstellung automatisiert oder durch die zuständige IT erfolgen.

Viele Schritte des Secure Deployment lassen sich automatisieren. Betriebssysteme, Anwendungen und Konfigurationen können zentral bereitgestellt und auch Benutzerkonten oder genehmigte Berechtigungen automatisiert provisioniert werden.

Automatisierung reduziert manuelle Fehler und sorgt für reproduzierbare Abläufe. Sie birgt allerdings auch ein Risiko:

⚠️ Ein Fehler im automatisierten Prozess kann sehr schnell auf viele Geräte oder Benutzer übertragen werden.

Deployment-Prozesse sollten deshalb gut getestet und ständig kontrolliert werden. Bei größeren Änderungen bietet sich zudem ein gestaffelter Rollout an. Nutze die Flipcards für weitere Informationen:

1. Pilotgruppe

Pilotgruppe: Zunächst erhält eine sehr kleine, bewusst ausgewählte Gruppe die Änderung. Idealerweise umfasst sie technisch versierte Benutzer und verschiedene typische Gerätekonfigurationen. Ziel ist es, grundlegende Probleme frühzeitig zu erkennen, bevor viele Mitarbeiter betroffen sind.

2. Kleinere Benutzergruppe

Kleinere Benutzergruppe: War der Pilot erfolgreich, wird der Rollout auf eine größere, aber weiterhin begrenzte Gruppe ausgeweitet. Dadurch zeigt sich, ob die Änderung auch unter realistischeren Bedingungen zuverlässig funktioniert. Hier können beispielsweise Inkompatibilitäten mit bestimmten Anwendungen oder Gerätemodellen auffallen.

3. Größere Zielgruppe

Größere Zielgruppe: Erst wenn auch diese Phase erfolgreich verlaufen ist, wird die Änderung auf den überwiegenden Teil oder die gesamte vorgesehene Zielgruppe ausgerollt.

Treten Probleme auf, kann der Rollout gestoppt werden. Soweit technisch möglich und sicherheitlich vertretbar, kann auch eine Rückkehr zum vorherigen Zustand – ein Rollback – vorgesehen werden.

Nach oben scrollen