Anzeige
rhh

Im Interview: Ulf Feger, IBM/Tivoli

Ulf Feger, Security Consultant bei IBM/Tivoli

Virtualisierung macht dem Administrator das Leben leichter: Er braucht lediglich die Virtualisierungs-Software auf einen Rechner spielen, muss nur schnell eine neue VM einrichten und starten. Doch wenn viele Leute viele Server anlegen dürfen und wenn diese zudem nicht sauber konfiguriert und aktualisiert werden, ergeben sich vielfältige Angriffsflächen.
Wir sprachen dazu mit Ulf Feger, Security Consultant bei IBM/Tivoli.

 Öffnet die Server-Virtualisierung dem Wildwuchs in der IT Tür und Tor?

Anzeige
 Ulf Feger 
Ulf Feger
Feger: In vielen Firmen wird mal hier und dort eine Virtuelle Maschine – VM – aufgesetzt. Hin und wieder vergessen es die Verantwortlichen, sie wieder stillzulegen. Unter Umständen übernehmen diese die Abteilungen Entwicklung und Test/Abnahme später mit einem zustimmenden Nicken in die Produktionsumgebung. An Security-Aspekte denkt man erst hinterher – wenn überhaupt.

 Gibt es denn viele Unternehmen, die ihre Sicherheits-Policies so erweitert haben, dass sie auch ihre virtuellen Umgebungen mit einbeziehen?

Feger: Hier trifft man bei Unternehmen auf vielfältige Variationen. Sie beginnen mit einem »Huch – wir haben ja Security Policies« – bis hin zur Einstellung: »Ja es gibt Sicherheitsrichtlinien – aber sind die auch für uns gültig?« Wenn dies der Fall ist, stellt sich zuerst die Frage, wie sind die umzusetzen. Und ist das geklärt, dann bleibt immer noch offen: »Wem sagen wir es denn, dass wir sie umgesetzt haben und wer kontrolliert dies«. Sprich es geht darum, wer für die Überwachung der Sicherheitsrichtlinien zuständig ist. Also kommen wir zu der Vorgehensweise Analyse, Design, Implementierung, Kontrolle und Maintenance/Anpassung der Richtlinien inklusive dem erforderlichen Berichtswesen – mit der Betonung auf »erforderlich«. Dies bedeutet eine mit dem Revisor abgestimmte und zielgerichtete Datensammlung, -haltung und Auswertung.

 Zu was raten sie beim virtuellen Serverkauf?

Feger: Sinnvoll ist, dass bei jeder Bestellung eines Servers oder eben bei einer Instanziierung einer neuen VM gleich der Sicherheitsverantwortliche involviert wird oder dessen Richtlinien beachtet werden. Dieser sollte dann nachprüfen und nachweisen können, in welchen Bereichen diese Maschine/Instanz zum Einsatz kommt: Ist es nur ein Entwicklungs- beziehungsweise Testsystem oder geht das Gerät sofort in den produktiven Einsatz. Leider handhaben dies viele Firmen mitunter sehr lax.

 Gibt es in Bezug auf die Virtualisierungs-Technik Unterschiede?

Feger: Ja, es gilt zu berücksichtigen, auf welcher Ebene die Virtualisierung ansetzt. Direkt auf der Hardware ist es etwas anderes als auf der Betriebssystemebene, wie etwa bei AIX. Hier lassen sich zum Beispiel beliebige Partitionen aufsetzen. Sicherlich als Extrem eines Virtualisierungsansatzes kann man das Cloud Computing betrachten. Hier lösen wir uns von der eigentlichen Plattform (HW, OS).

 Warum der Terminus Extrem?

Feger: Speziell bei der Kombination von Cloud Computing, Security und Identity Management kommen wir in eine ganz andere Größenordnung der Aufgabenstellung. Ohne Policies und ihre strikte Umsetzung geht gar nichts mehr – das wird ansonsten absolut geschäftsgefährdend.

 Ist Cloud Computing schon im Markt angekommen?

Feger: Nur »große« Anwender kombinieren das Cloud Computing mit Security und dem Identitätsmanagement. Wir versuchen es in den Markt zu tragen, sowohl das Cloud Computing als auch die entsprechenden Sicherheitslösungen. Unternehmen sollten sich aber zuerst klar werden, was sie mit Cloud Computing erreichen möchten: Wollen sie einfach nur Rechenressourcen im Sinne purer Rechenleistung oder möchten sie Dienste nutzen, die in der Cloud angeboten werden oder gar eigene anbieten. Beides kann ihnen eine entsprechende private, eine öffentliche oder eine hybride Cloud bieten. Aber alle Ansätze verlangen eine Lösung der Sicherheitsherausforderungen.

 Was hat das zur Folge?

Feger: In allen Fällen brauche ich Identitätsdaten, also personenbezogen Daten, um die Ressourcen abrechnen (Accounting) und um sie zuweisen zu können. Dazu gehören die Punkte Authentifizierung und Authorisierung, Zugriffsidentifizierung, Zugriffskontrolle und Zugriffsmanagements. Somit findet sich in diesem Kontext sehr schnell das komplette Thema Identity Management wieder.

 Macht das auch bei mittelständischen Anwendern Sinn?

Feger: Ja – doch dabei wird wohl nicht so sehr das Thema der Rechenkapazität im Vordergrund stehen, sondern vielmehr das der verteilten Dienste.

 Können Sie dazu ein Beispiel geben?

Feger: Viele Anbieter binden Google Maps in ihre Websites und Applikationen mit ein. Sollte Google später einmal Geld für diesen Service verlangen, sind wieder Authentifizierung und Authorisierung gefragt, dann ist man wieder von Identitäten »abhängig«. Generell wird der Faktor Kosten der Treiber sein – frei nach dem Motto: Wer darf meine Dienste nutzen und was muss er dafür bezahlen… und somit wären wir wieder bei den drei (englischen) A’s – Authentication, Authorization und Accounting.

 Ist das Thema Identitätsmanagement stark technikgetrieben?

Feger: Generell sollte sich ein Unternehmen klar werden, was es mit Identitätsmanagement erreichen möchte und/oder gar muß. Das dreht sich heutzutage vor allem um die Punkte Authentifizierung und Authorisierung und dem benötigten Berichtswesen. Hieran hängen sehr viele Prozesse, und genau dieser Bestandteil wird sehr häufig unterschätzt. Bei einem Projekt in diesem Umfeld sind 20 bis 30 Prozent Technologie, der größere „Rest“ ist der Prozessaufwand, also auch hier Anforderungsanalyse, Design, Implementierung inklusive Test und Rollout. Dies nicht nur für den Technologiepart, sondern auch für die umgesetzen Prozesse, Prozessaktivitäten, Prozesschritte erforderlich.

 Was meinen Sie damit?

Feger: Es sind Fragen zu klären, wie zum Beispiel: Woher bekomme ich die benötigten Identitätsinformationen? Welche Bestätigungen für bestimmte Aktivitäten sind in Workflows notwendig? Wie sehen die Abläufe generell aus, wo existieren Spezialfälle? Wie weise ich Berechtigungen zu, wie entziehe ich sie wieder? Wie sieht der Identitätslebenszyklus aus und wie realisiere ich ihn? Danach geht es zu virtuellen Maschinen beziehungsweise zu virtuellen IT-Infrastrukturen: Was möchte ich mit meinen Identitäten dort machen und erreichen?

 Was schlagen Sie konkret vor, um einen Wildwuchs bei VMs einzudämmen?

Feger: Der Prozess muss definiert sein, der die Beantragung und Einrichtung einer virtuellen Instanz beschreibt. Dazu gehören sicherlich bekannterweise alle HW-Komponenten, die nötig sind, wie Arbeitsspeicherausbau, CPU, und so weiter.

 Ist das schon alles?

Feger: Nein, es sind sicherlich auch die Administratoren zu berücksichtigen, die diese virtuelle Instanzen verwalten müssen. Hier drängt sich der Gedanke auf: Wenn ich die Systembetreuer über ein Identitätsmanagement-System verwalten– also ein User Management für Admins – und dort die Berechtigungen pflegen kann, die sie bezüglich der Verwaltung der VMs haben, kann ich hierzu einen Bericht für das Management und die Revision erstellen lassen – nach dem Motto: »Gib mir alle Systemverwalter und zeige mir ihre Berechtigungen bezüglich der virtuellen Umgebungen.« Somit erweitere ich die Anforderungen an den zuvor genannten Prozess über die HW hinaus auf die erforderliche Berechtigungsebene.

 Wäre es da nicht besser, einen Prozess zu definieren, der Fragen klärt wie: Wer darf eine VM aufsetzen, wann muss er sich darum kümmern, ob die VM noch weiter laufen soll und wann muss er kontrolliert wieder abstellen?

Feger: Die Verknüpfung dieser beiden Ansätze macht für mich am meisten Sinn: Erst ist ein Prozess einzuführen und anschließend das Reporting und das Management dieser Benutzer über das User Management des Identitätsmanagement-System zu etablieren. Wichtig hierbei ist: a) Es muss ein sinnvoller und lebbarer Ablauf sein, der sichtbare Vorteile für alle Beteiligten aufzeigt, zum Beispiel durch Zeitersparnis, Kostenersparnis, Arbeitsentlastung der Administaroren bei Routineaufgaben und Revisoren durch ein sauberes Berichtswesen und somit eine Effizienzsteigerung und b) Wieviel kann ich hiervon generell durch meine Abläufe automatisieren.

 Sehen Sie prinzipielle Unterschiede zwischen Admins im virtuellen Bereich und denen von physischen Systemen?

Feger: Ja, dies ist abhängig von der virtuellen Instanz und speziell was sie »beheimatet«: Im Bereich Test und Entwicklung ist ein eher laxer Umgang machbar. Wobei ich hier auch im Bereich Test das Thema Sicherheitstests sehe und somit den Anforderungen der Produktivumgebung bei sicherheits- und geschäftskritischen Komponenten entsprechend intensiv beachten und betrachten muss. Betrachte ich jedoch eine Produktivumgebung, so entscheidet der Aspekt »geschäftskritisch«. Dann ist es unbedeutend, ob es sich um eine virtuelle oder physische Umgebung handelt – letztendlich entscheidet die Business Affinität.

 Sind deswegen die üblichen Vorkehrungen für physische Umgebungen bei geschäftskritischen Applikationen auch im virtuellen Bereich zutreffend?

Feger: Ja – es kommen sogar noch weitere Faktoren hinzu, wenn ich zum Beispiel bei einem virtuellen System nicht mehr spezifizieren kann, wo es sich »befindet«. Es besteht ja die Möglichkeit, dass eine VM automatisch in ein anderes Rechenzentrum verschoben wird, das es zudem in einem anderen Land oder gar auf einem anderen Kontinent liegt. Daraus ergeben sich aufgrund der lokalen Gesetzgebung noch weitere Anforderungen und Restriktionen. Wir sprechen dann von einem Cross-Border-Problem oder Herausfoderung. Gerade bei Identitätsinformationen gelangen wir so recht schnell in den sensitiven Bereich Privacy. Wer benötigt genau welche Informationen wo und wozu? Was geschieht mit diesen Imformationen und wie sieht der Lebenszyklus dieser (Identitäts-) Informationen aus?

 Viele Experten halten den Einsatz der Verschlüsselung als einen wichtigen Aspekt virtueller Infrastrukturen. Wie sehen Sie dieses Thema?

Feger: Hochkritisch. Es sind zwei Aspekte zu betrachten. Dies ist einerseits der verschlüsselte Datentransport, etwa via Kanalverschlüsselung, Nachrichtenverschlüsselung, als auch die verschlüsselte Ablage der Daten. Viele Unternehmen machen sich darüber allerdings leider nur unzureichende Gedanken und beschränken dies häufig auf das Thema Passwörter. Wir behandeln hier jedoch Identitätsdaten und diese können beispielsweise im SAN liegen – aber wo ist das SAN? Bei Virtualisierung in großen Speichersystemen weiß man nicht mehr auf welchem Speichergerät die Informationen residieren. Insbesondere bei einer räumlichen Verteilung trifft dies schnell zu. Hier helfen entsprechnde Sicherheitskonzepte, die die Datenablage, die Verschlüsselung und auch den Zugriff und die Auswertung der vorliegenden Daten beinhalten. Grosse Datenmengen wecken immer schnell den »Idee des Vorteils« der Datenkorrelation und Auswertung.

 Generell kommt eine zusätzliche Belastung durch Sicherheitsmechanismen auf die Systeme. Reduziert das die Konsolidierungsrate bei der Virtualisierung von Servern?

Feger: Die nötige Rechenleistung für die Sicherheitsvorkehrungen wird oft vergessen. Ein Identitätsmanagement-System und das Access-Management benötigen CPU-Zyklen. Dazu kommt noch das Auditing – das kann ein regelrechter Performance-Killer sein, je nachdem wie sensibel es eingestellt ist, wie häufig und wie intensiv grosse Datenmengen durchsucht und ausgewertet werden müssen. Aber auch hier trifft die Aussage zu: Erfordert das Business eine entsprechende Security, dann muss man das mit einrechnen. Insofern ist ein möglichst reales Sizing einer Lösung nötig.

 Gibt es dazu auch konkretere Werte?

Feger: Nein, denn dies ist system- und applikationsabhängig und somit sind wir auch recht schnell bei der kundespezifischen Systembetrachtung und wie »er« dieses nutzt. Zudem stellt sich die Frage, besteht eine aus Endanwendnersicht existierende Applikation wirklich aus einer nennen wir es Applikationsinstanz oder ist es in Wirklichkeit eine sogenannte Composite Applikation, also ein funktional aufgesplittetes System, welches AAA-Funktionen inklusive Identitätsmanagement an vielerlei Stellen und Orten benötigt. Somit wäre es falsch, ein System mit durchschnittlich 5 Prozent Auslastung in 20 Scheiben zu schneiden, um 100 Prozent Auslastung zu erreichen. Hier kommt die eigene Erfahrung und die Zusammenarbeit mit dem Kunden zum Tragen, um sowohl eine sinnvolle Auslastung der virtuellen Infrastruktur als auch eine sinnvolle Sicherheitsarchitektur, die geschäftskritschen Komponenten schützt und gleichzeitig den erforderlichen Mehrwert liefert, umsetzt.
Basisprozesse Identitätsmanagement
  • Eintritt
    • Übernahme aus HR
      • Datenimport
      • automatisches Provisionieren der Standardbenutzerkonten
    • Eingabe über GUI
      • automatisches Provisionieren der Standard-Accounts
  • Änderungen
    • Änderungen der Stammdaten
      • Übernahme der Daten aus HR oder Pflege über GUI
      • Weitergabe der geänderten Daten an Zielsysteme
    • Beantragung neuer Berechtigungen
      • Zuordnung neuer Rollen
      • Genehmigung der beantragten Rollen
      • Umsetzung der Berechtigungen auf Zielsysteme
    • Passwortwechsel
      • Passwortwechsel identisch für alle Accounts über Selfservice-GUI
    • Organisationseinheitenwechsel
      • Neue OE-Informationen werden über HR oder GUI übernommen
      • Weitergabe der neuen OE an Zielsysteme
      • Information an bisherigen und neuen Vorgesetzten
    • sofortige Sperre
      • Trigger aus HR oder über GUI
      • Person und Accounts werden gesperrt
      • Information an HR senden
  • Austritt
    • temporärer Austritt
      • Kennzeichen/Flag in Personenattribut wird über HR oder GUI gesetzt und wieder gelöscht
      • Person und Konten/Accounts werden gesperrt und wieder freigegeben
    • endgültiger Austritt
      • Austrittskennzeichen über HR oder GUI gesetzt
      • Person und alle Accounts werden gesperrt
      • nach 90 Tagen werden Person und Konten/Accounts endgültig gelöscht
  • Weiteres
    • Re-Zertifizierung der Benutzerkonten
      • Eskalationsverhalten
    • regelmäßiger Abgleich mit Zielsystemen
      • Übernahme von Daten aus Zielsystemen
      • Abgleich mit Rollen und Policies
      • Korrektur von Regelverletzungen
    • Generierung eines Standardreports
      • Konten/Accounts pro System
    • Eskalationsabläufe und Benachrichtigungen in Entitlement-Workflows
  • Voraussetzungen
    • Basisrollendefinition existiert
    • statische Organisationsstruktur existiert
    • Vorgesetzteninformation existiert
    • Eindeutiges Personenkennzeichen (z.B. Personalnummer) existiert
    • ausreichende Personeninformationen existieren
    • ein führendes Quellsystem für Personendaten
    • Personendaten in Quellsystem vor Arbeitsantritt
    • Eindeutige Userid ohne Änderung bei Personenattributänderung
    • regelmäßige (täglich) automatische Übernahme der HR Personalstammdaten

Anzeige