Startseite > Datacenter & Verkabelung > 7 Regeln für ein erfolgreiches Single-Sign-on-Projekt

Authentisierung

7 Regeln für ein erfolgreiches Single-Sign-on-Projekt

10. September 2013, 14:18 Uhr | Erwin Schöndlinger, Geschäftsführer von Evidian Deutschland, einer Tochter der Bull-Gruppe

Fortsetzung des Artikels von Teil 4

Regel 4: Projekt auf bestehende Prozeduren und Policies aufsetzen

Prozeduren und Policies sollten nur dort, wo unumgänglich, geändert werden. Werden Prozeduren für den SSO modifiziert, beeinflusst dies auch die Vergabe von Zugriffsrechten für Applikationen. Deshalb sollten für den SSO, soweit wie möglich, die Prozeduren beibehalten werden, um zeit- und kostenaufwendigen Änderungen im Projektverlauf aus dem Weg zu gehen. Dies kann beispielsweise dadurch erreicht werden, indem die automatisierten Zugriffe vorerst über bestehende Nutzerkonten geführt werden. Dort, wo Prozeduren im Kontext mit dem SSO geändert werden müssen, sollten dafür die Fachabteilungen freie Hand bekommen. Sie kennen am besten ihre fachlichen und organisatorischen Anforderungen und müssen die zusätzlichen Aktivitäten in ihre Terminplanung einbringen können. Das gilt auch für die IT-Abteilung: Die künftigen SSO-Administratoren müssen frühzeitig in ihrem Aufgabenfeld – Organisationsabläufe, Verwaltung von Applikations- und Nutzerkonten, Zugriffsprozeduren, Auditierungs-, Auswertungs- und Dokumentationsprozesse – geschult werden.

Das SSO kann dennoch potenzielle Projektverzögerungen zur Folge haben. Manager sind oftmals nicht dazu bereit, ihre Zugriffsmethoden ad hoc auf das SSO umzustellen. Kernapplikationen des Unternehmens, beispielsweise SAP, müssen in der Regel vor ihrer Integration in das SSO ausgiebige Tests durchlaufen. Dabei müssen auch die zu befolgenden Regularien und Regeln bedacht werden, ebenso wie dafür notwendige Kontrollprozeduren. Deshalb sollte die Umstellung auf das SSO in überschaubaren Etappen erfolgen, beispielsweise Abteilung für Abteilung oder Standort für Standort, verzögernde Bereiche und/oder Kernapplikationen vorerst von der Realisierung ausgenommen werden.

Zum Stichwort „Policies“: Über das SSO wird transparent, wer welche Applikationen in welchem Umfang nutzt. Dieses Wissen versetzt das Projekteam in die Lage, verlässliche Security-Policies abzuleiten, zu entscheiden, welche davon beibehalten werden können und welche für das SSO modifiziert werden sollten.