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:
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:
Hier greifen die bereits behandelten Prozesse ineinander:
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:
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“:
Rolle „Teamleitung Vertrieb“:
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:
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:
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:
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.