Startseite > Datacenter & Verkabelung > Drei Buchstaben - und viele offene Fragen

Kontrolle über SSH-Fernzugriffe

Drei Buchstaben - und viele offene Fragen

17. März 2017, 11:33 Uhr | Autor: Christian Kress / Redaktion: Axel Pomper

Fortsetzung des Artikels von Teil 2

Wäre es nicht schön, wenn ...

Nachdem wir erkannt haben, dass eine sichere und kontrollierte Fernwartungslösung mehr ist als ein funktionierender VPN-Zugang, kommen wir in die nächste Phase: Wir spielen ein bisschen „Wünsch Dir was!“ In dem Zusammenhang bekommen Service Provider von Kunden (sobald sie sich trauen) häufig folgende Anforderungen:

Keine Software-Installation: Linux ist nicht gleich Linux. Es kann im Detail sehr aufwändig sein, auf einer heterogenen Umgebung einen Agenten auszurollen. Häufig erwarten die internen Prozesse für jede größere Systemänderung ein Ticket (ITIL und SOX lassen grüßen).

Integration in das Microsoft Active Directory: Wenn wir unsere Kunden fragen, wo sie ihre Benutzer verwalten, bekommen wir häufig die gleiche Antwort: im Active Directory. Gleichzeitig zucken sie zusammen, wenn sie über die Konsequenzen einer LDAP/Kerberos-Anbindung nachdenken.

Wenig Betriebsaufwand: Jedes erfolgreiche Projekt bedarf im Nachhinein eines kontinuierlichen Pflegeaufwands über den Lifecycle des Produkts bzw. des Dienstes. Die wenigsten Administratoren warten wirklich auf zusätzliche Arbeit.

Die typischen Wünsche bzw. (aus unserer Sicht) Herausforderungen im Bereich verschlüsselte, sichere Fernwartung lassen sich also in folgenden Punkten zusammenfassen:

Eindeutige Personalisierung ist mit wenig Aufwand verbunden.
Der Zugang via Benutzername/Passwort bzw. SSH Keys muss klar geregelt sein.
Die Problematik, dass ein SSH Key nie abläuft, ist für Personen zu lösen.
Der Zugang zu den Linux- und Unix-Systemen soll zentral verwaltet werden.
Die Verwaltung soll einfach und nachvollziehbar sein und auch von den Verantwortlichen in den Fachabteilungen verstanden werden.
Neue Kollegen können umgehend Zugriff zu allen relevanten Systemen erhalten und können bei Bedarf wieder gesichert von allen Systemen entfernt werden.
Die Arbeiten auf den Systemen können bei Bedarf im Detail nachvollzogen werden, ohne die Administratoren durch sudo & Co. zu quälen.

Es wird Zeit für eine Lösung

Wie zuvor dargestellt, haben die Herausforderungen sowohl technische als auch organisatorische Anteile. Aus dem Grund raten wir unseren Kunden ab, ihr Glück in einer reinen technischen Lösung zu suchen.

Wir starten mit der Frage: Warum nutzt ein Administrator ein bestimmtes System? Die häufige Antwort: Weil es sein Job ist. Klingt wieder logisch: Ein Oracle DBA hat die Aufgabe, Oracle-Dienste zu verwalten. Die damit verbundene Konsequenz ist, dass der Mitarbeiter zu allen Systemen Zugang bekommen sollte, auf denen Oracle läuft. Dies wären die Systeme bzw. die Host-Gruppen. Wenn man alle Oracle DBAs kennt (das sollten Sie), dann könnte man diese in einer Gruppe im Microsoft Active Directory zusammenfassen. Der Zugang zum Oracle Account erfolgt nicht über Benutzername und Passwort, sondern über einen SSH Key. Was fehlt, ist eine Brücke vom Active Directory zu den tatsächlichen Systemen, z.B. anhand der IP-Adressen, da diese schlicht nicht im Active Directory bekannt sind. Diese Brücke existiert in Form eines Proxy- oder Gateway-Systems auf Protokoll-Ebene, vergleichbar einer Firewall. Gleichzeitig unterstützt dieses Proxy-System die Aufzeichnung der administrativen Sitzung. Sie kennen die Idee seit vielen Jahren aus dem Call-Center-Umfeld: „… aus Qualitätsgründen wird die eine oder andere Sitzung aufgezeichnet …“

Wenn diese Brücke existiert, dann verfügen wir über alle Zutaten, um den Zugang zu den Linux- und Unix-Systemen für Personen umfassend zu steuern. Bleiben wir bei Oracle und spielen wir ein paar typische Szenarien durch:

Ein neuer Oracle DBA soll die Fernwartung unterstützen
Die zusätzliche Person wird im Active Directory angelegt. Dabei ist es nicht relevant, ob es sich um einen internen oder externen Mitarbeiter handelt. Die Person wird in die Gruppe der Oracle DBAs aufgenommen. Fertig! Der Kollege kann sofort alle bestehenden Systeme der Oracle Host-Gruppe über seine persönliche Benutzernamen-Passwort-Kombination erreichen.

Ein zusätzliches Oracle-System wird eingerichtet
Das neue System wird mit der IP-Adresse oder dem DNS-Namen in die Gruppe der bestehenden Oracle-Systeme hinzugefügt. Fertig! Alle bisherigen Oracle DBAs haben sofort Zugang zu dem neuen Oracle Server.

Ein Mitarbeiter scheidet aus
Die Person wird im Active Directory deaktiviert. Fertig! Mit der Deaktivierung im Active Directory erreicht der Administrator kein einziges System mehr, da sein Zugang „nur“ über die erfolgreiche Authentifikation am Active Directory möglich war. Den für die tatsächliche Anmeldung notwendigen SSH Key hatte er nie, sondern er wurde ihm im Anmeldeprozess nach der Validierung durch das Active Directory transparent bereitgestellt.

Ein neuer Dienst wird eingerichtet

Dies ist der „aufwändigste“ Teil.

Es wird auf dem Active Directory eine Gruppe für die Administratoren erstellt.
Die im Active Directory existierenden Personen werden Mitglied der Gruppe.
Es wird auf dem Gateway eine Host-Gruppe für den Dienst erstellt.
Die Systeme, die den Dienst bereitstellen, werden mit ihrer IP-Adresse Mitglied in der Host-Gruppe.
Es wird ein SSH Key erzeugt und dem Dienst zugeordnet.
Es wird eine Regel erstellt, dass alle Mitglieder der Active Directory-Gruppe auf alle Systeme der Host-Gruppe Zugriff bekommen.

Fazit

Es lohnt sich, das Thema Fernwartung oder Zugangsmanagement im Allgemeinen ein wenig genauer zu betrachten und sich Klarheit über die eigene Ist-Situation und die persönlichen Erwartungen zu verschaffen. Oft können mit technisch pfiffigen, jedoch in der Anwendung sehr einfachen Methoden schnelle und kostengünstige Lösungen geschaffen werden. So wird es möglich, viele der im Active Directory existierenden Prozesse ohne zusätzlichen Aufwand in der Linux- und Unix-Umgebung einzusetzen und wieder die volle Zugangskontrolle zurückzugewinnen.

Christian Kress, Bundesfachverband der IT-Sachverständigen und -Gutachter (BISG)