Konzeption und Einführung eines SSH-Key Access Managements für die Zugriffskontrolle bei Linux-Servern
←
→
Transkription von Seiteninhalten
Wenn Ihr Browser die Seite nicht korrekt rendert, bitte, lesen Sie den Inhalt der Seite unten
Konzeption und Einführung eines SSH-Key
Access Managements für die Zugriffskontrolle
bei Linux-Servern
Lukas Fürderer
BACHELORARBEIT
zur Erlangung des akademischen Grades Bachelor of Science (B.Sc.)
Studiengang Angewandte Informatik
Fakultät Elektrotechnik, Medizintechnik und Informatik
Hochschule für Technik, Wirtschaft und Medien Offenburg
25.04.2021
Durchgeführt bei der Firma Leitwerk AG
Betreuer
Prof. Dr. rer. nat. Stephan Trahasch, Hochschule Offenburg
Dipl.-Ing. (FH) Klaus J. Müller, Leitwerk AGFürderer, Lukas: Konzeption und Einführung eines SSH-Key Access Managements für die Zugriffskontrolle bei Linux-Servern / Lukas Fürderer. – BACHELORARBEIT, Offenburg: Hochschule für Technik, Wirtschaft und Medien Offen- burg, 2021. 52 Seiten. Fürderer, Lukas: Design and introduction of an SSH-key access management tool for controlling linux server access / Lukas Fürderer. – BACHELOR THESIS, Offenburg: Offenburg University, 2021. 52 pages.
Vorwort Die Idee zu dieser Arbeit entstand während einer Hospitation bei der Leitwerk AG im August 2020. Ich durfte mir einen Tag lang den Betrieb anschauen und konnte dabei einen Einblick in das Unternehmen sowie die anstehenden Projekte erhalten. Die geplante Schlüsselverwaltung für SSH-Keys entsprach dabei sehr genau mei- nen Interessen. Einerseits, da ich bereits mehrere Jahre Linux nutze und SSH bereits sehr häufig benutzt hatte, andererseits aber auch da ich Sicherheitsthemen und ins- besondere das Design von Software hinsichtlich Sicherheit sehr interessant finde. Als Linux-Nutzer bin ich unter anderem begeistert von freier Software und es freut mich sehr, dass ich im Zuge meiner Arbeit einen Beitrag zur Weiterentwicklung einer solchen freien Software leisten durfte, auch wenn dies zu Beginn der Arbeit noch nicht absehbar war. Die Einarbeit in den bestehenden Code klappte erstaunlich schnell und ich nehme für mich mit, dass ein Beitrag zur Verbesserung bestehender Software einfacher sein kann als erwartet. Als eine weitere Erfahrung durfte ich feststellen, dass eine Software trotz anfäng- licher sorgfältiger Planung in den meisten Fällen nicht vollständig fertig werden kann. Es gibt immer Ansatzpunkte zur weiteren Verbesserung und nicht alle Wün- sche können berücksichtigt werden, wenn die Zeit für weitere Projekte benötigt wird. Ich möchte mich nun bei all denjenigen bedanken, die mir während meiner Arbeit zur Seite standen. Zuerst gebührt mein Dank Klaus Müller für die regelmäßige Unterstützung, beson- ders während der Planung der Anforderungen im Sinne der Interessen aller Linux- Kollegen. Ebenfalls vielen Dank an Prof. Stephan Trahasch für die hilfreichen Ratschläge zur inhaltlichen Gestaltung meiner Arbeit. Abschließend wünsche ich Ihnen viel Spaß beim Lesen meiner Arbeit. Lukas Fürderer Oberkirch, 25.04.2021
Eidesstattliche Erklärung Hiermit versichere ich eidesstattlich, dass die vorliegende Bachelor-Thesis von mir selbstständig und ohne unerlaubte fremde Hilfe angefertigt worden ist, insbesonde- re, dass ich alle Stellen, die wörtlich oder annähernd wörtlich oder dem Gedanken nach aus Veröffentlichungen, unveröffentlichten Unterlagen und Gesprächen ent- nommen worden sind, als solche an den entsprechenden Stellen innerhalb der Arbeit durch Zitate kenntlich gemacht habe, wobei in den Zitaten jeweils der Umfang der entnommenen Originalzitate kenntlich gemacht wurde. Ich bin mir bewusst, dass eine falsche Versicherung rechtliche Folgen haben wird. Ich bin damit einverstanden, dass meine Arbeit veröffentlicht wird, d. h. dass die Arbeit elektronisch gespeichert, in andere Formate konvertiert, auf den Servern der Hochschule Offenburg öffentlich zugänglich gemacht und über das Internet verbrei- tet werden darf. Offenburg, 25.04.2021 Lukas Fürderer
Zusammenfassung Konzeption und Einführung eines SSH-Key Access Managements für die Zugriffskontrolle bei Linux-Servern Die freie Software OpenSSH erlaubt den sicheren Fernzugriff auf entfernte Rech- ner über das Netzwerk oder Internet und kommt auf vielen Linux-Rechnern zum Einsatz. OpenSSH ermöglicht verschiedene Wege der Authentifizierung, unter an- derem mit Hilfe von asymmetrischen Schlüsseln. Im Standardfall existiert hierbei für jedes Nutzerkonto auf dem Zielrechner eine Datei mit den public-Keys der zu- griffsberechtigten Nutzer, welche manuell gepflegt wird. Diese Art der Zugriffskon- trolle wird jedoch schnell unübersichtlich, sobald viele Mitarbeiter auf viele Server zugreifen dürfen. Um den Überblick über zugriffsberechtigte Nutzer zu behalten, ist es deshalb notwendig, zur Verwaltung eine zusätzliche Software einzusetzen. Im Rahmen dieser Arbeit soll eine solche Verwaltungssoftware konzipiert werden. Nach einer Analyse bestehender Systeme werden die Gründe für die Wahl eines der Tools dargestellt sowie die anschließende Weiterentwicklung der gewählten Soft- ware dokumentiert.
Abstract Design and introduction of an SSH-key access management tool for controlling linux server access The free software OpenSSH allows users to securely remote-access computers over the network or internet and is used on many linux systems. Different methods of authentication can be used in OpenSSH, one of them is using asymmetric crypto- graphic keys. When using this method, usually there is one public-key-file for each user account on a target server. It contains public keys of users who are allowed to access this account and is managed manually. But this kind of access control quick- ly becomes confusing, if many co-workers are allowed to access many servers. So to keep track of authorized users, an additional software for access management is needed. In this thesis, such a management software will be designed. After ana- lyzing existing tools, the reasons for choosing one of the tools are shown and the process of further developing the chosen software is documented.
Inhaltsverzeichnis
1 Einleitung 1
2 Anforderungen 2
2.1 Hinzufügen von Schlüsseln . . . . . . . . . . . . . . . . . . . . . . 2
2.2 Deaktivierung von Schlüsseln . . . . . . . . . . . . . . . . . . . . 3
2.2.1 Möglichkeit zur Reaktivierung . . . . . . . . . . . . . . . . 3
2.3 Gruppierung von Zielmaschinen zur Berechtigung . . . . . . . . . . 3
2.4 Umgang mit unbekannten Schlüsseln . . . . . . . . . . . . . . . . . 4
2.4.1 Behandlung beim Erscheinen . . . . . . . . . . . . . . . . 4
2.4.2 Hinweis . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4
2.4.3 Möglichkeit zur Deaktivierung . . . . . . . . . . . . . . . . 4
2.4.4 Möglichkeit zur Erlaubnis . . . . . . . . . . . . . . . . . . 5
2.5 Auswirkung auf die Benutzung . . . . . . . . . . . . . . . . . . . . 5
2.6 Umgang mit privaten Schlüsseln . . . . . . . . . . . . . . . . . . . 6
2.7 Verwaltungsoberfläche . . . . . . . . . . . . . . . . . . . . . . . . 6
2.7.1 Webbasierte Oberfläche . . . . . . . . . . . . . . . . . . . 6
2.8 Automatische Wirksamkeit geänderter Rechte . . . . . . . . . . . . 6
2.9 Einschränkung der Rollout-Schnittstelle . . . . . . . . . . . . . . . 7
2.10 Nutzernamen auf Zielmaschinen . . . . . . . . . . . . . . . . . . . 7
2.11 Plattformunabhängigkeit bezüglich Zielmaschinen . . . . . . . . . 8
2.12 Schlüsseloptionen . . . . . . . . . . . . . . . . . . . . . . . . . . . 8
2.13 Beteiligung des Tools am Loginvorgang . . . . . . . . . . . . . . . 8
2.14 Definition des Schlüsselkommentars . . . . . . . . . . . . . . . . . 9
2.15 Export der vorhandenen Schlüssel . . . . . . . . . . . . . . . . . . 9
2.16 AD Anbindung . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9
2.16.1 Login mit AD-Zugang . . . . . . . . . . . . . . . . . . . . 9
2.16.2 Import von Gruppen aus dem AD . . . . . . . . . . . . . . 10
2.17 Erfassung des Alters von Schlüsseln . . . . . . . . . . . . . . . . . 10
2.18 Kompatibilität mit Client-Maschinen . . . . . . . . . . . . . . . . . 10
3 Verfügbare Software 12
3.1 Key Manager Plus . . . . . . . . . . . . . . . . . . . . . . . . . . . 12
3.2 Universal SSH Key Manager . . . . . . . . . . . . . . . . . . . . . 14
3.3 PrivX . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17
vInhaltsverzeichnis
3.4 Keyper . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20
3.5 Userify . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23
3.6 Vault . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25
3.7 Thycotic Secret Server . . . . . . . . . . . . . . . . . . . . . . . . 29
3.8 CyberArk Privileged Access Security . . . . . . . . . . . . . . . . 31
3.9 SSH Key Authority . . . . . . . . . . . . . . . . . . . . . . . . . . 32
3.10 Bastillion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 35
4 Vergleich 38
5 Implementierung zusätzlicher Funktionen 40
5.1 Anbindung von LDAP-Gruppen . . . . . . . . . . . . . . . . . . . 40
5.2 Erstellen und Löschen von Schlüsseln . . . . . . . . . . . . . . . . 41
5.3 Definierter Schlüsselkommentar . . . . . . . . . . . . . . . . . . . 42
5.4 Umgang mit vorhandenen Schlüsseln . . . . . . . . . . . . . . . . . 43
5.5 Monitoring . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 46
5.6 Mehrfachaktionen . . . . . . . . . . . . . . . . . . . . . . . . . . . 46
5.7 Jumphosts . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 47
5.8 Übersicht aller Berechtigungen . . . . . . . . . . . . . . . . . . . . 49
6 Ausblick 52
Abkürzungsverzeichnis
Literatur i
vi1. Einleitung
Das SSH1 -Protokoll erlaubt verschiedene Wege der Nutzer-Authentifizierung, ins-
besondere per Passwort sowie per SSH-Schlüssel, auf englisch SSH-Key genannt.
Die Authentifizierung per Key gilt als sicherer, da hierbei kein Passwort über das
Netzwerk übertragen wird. [La16, p. 129]
Bei einem Scan einer großen Zahl von SSH-Servern im Jahre 2018 wurde ermittelt
und kritisiert, dass mindestens 65% der öffentlich im Internet erreichbaren SSH-
Server die Passwort-Authentifizierung aktiviert haben. [AHB20]
Die Leitwerk AG setzte vor Beginn dieser Arbeit bereits SSH-Schlüssel für die
Authentifizierung auf Linux-Maschinen des Kunden ein. Es fehlte hierbei jedoch
ein Werkzeug, um die öffentlichen Schlüssel für die Erteilung von Zugriffsrechten
effizient zu verteilen sowie den Überblick über bestehende Zugriffsberechtigungen
zu behalten. Die Einführung eines solchen Werkzeugs ist Thema dieser Arbeit.
1
Secure Shell
12. Anforderungen
Damit die Verteilung von SSH-Schlüsseln einfacher und übersichtlicher wird und
keine zusätzlichen Hürden entstehen, muss die verwendete Software bestimmten
Anforderungen entsprechen. Um den Vergleich zwischen verschiedenen Lösungen
zu ermöglichen, wurde eine Liste von Kriterien erstellt.
Jedem der Kriterien wird ein Nutzwert zugeordnet, dabei handelt es sich um eine
positive Ganzzahl welche dazu dient, die Priorität verschiedener Kriterien in Re-
lation setzen zu können. In einer anschließenden Nutzwertanalyse können für ver-
schiedene Lösungen die Nutzwerte der jeweils erfüllten Kriterien zusammenaddiert
werden um einen Gesamt-Nutzwert für die Lösung zu erhalten. Dies erlaubt einen
Vergleich der vorhandenen Lösungen und die Entscheidung für eine Lösung.
Die konkret festgelegten Nutzwerte entsprechen der subjektiven Wahrnehmung der
Wichtigkeit verschiedener Kriterien und wurden in Kooperation mit den späteren
Nutzern des Tools definiert.
2.1 Hinzufügen von Schlüsseln
Bei der erstmaligen Einrichtung eines SSH-Clients für die Key-Authentifizierung
erzeugt ein Nutzer selbständig ein SSH-Schlüsselpaar. Bei der Nutzung mehrerer
Geräte wird üblicherweise auf jedem Gerät ein eigenes Schlüsselpaar erstellt. Je
nach Sicherheitsanforderungen müssen diese Schlüssel zudem regelmäßig ausge-
wechselt, das heißt neu erzeugt werden.
Das Key Access Management System soll dem Nutzer ermöglichen, seine eige-
nen Schlüssel selbständig einzutragen. Die Erfüllung dieses Kriteriums wird in der
Nutzwertanalyse mit 100 Punkten bewertet.
22 Anforderungen
2.2 Deaktivierung von Schlüsseln
Wenn ein Nutzer einen Linux-Rechner bzw. einen Linux-Account auf einem zen-
tralen Rechner nicht mehr benutzt, sollte er dem darauf liegenden SSH-Schlüssel
die Zugriffsberechtigung entziehen. Gleiches gilt für einen alten SSH-Schlüssel,
nachdem dieser durch einen neueren Schlüssel getauscht wurde.
Durch das Entziehen der Berechtigung wird ein möglicher Missbrauch verhindert,
falls der Schlüssel in der Vergangenheit bereits gestohlen wurde oder später noch
von dem betreffenden Gerät gestohlen wird.
Das Key Access Management System sollte dem Nutzer deshalb ermöglichen, die
eigenen Schlüssel selbständig zu deaktivieren und somit Berechtigungen zu entzie-
hen. Die Möglichkeit zur Deaktivierung eigener Schlüssel erhält in der Nutzwert-
analyse einen Wert von 100 Punkten.
2.2.1 Möglichkeit zur Reaktivierung
Durch die Funktion zum Deaktivieren bestimmter SSH-Schlüssel besteht für Nut-
zer die Gefahr, auch unbeabsichtigt Schlüssel zu deaktivieren. Ein Schlüsseltausch
ist in dieser Situation möglicherweise nicht gewünscht oder wäre umständlich, bei-
spielsweise weil das betroffene Gerät zu dem Zeitpunkt nicht zugreifbar ist. Das
Key Access Management System sollte deshalb erlauben, den deaktivierten Schlüs-
sel wieder erneut zu aktivieren. Die Möglichkeit einer solchen Reaktivierung ist in
der Nutzwertanalyse 5 Punkte wert.
2.3 Gruppierung von Zielmaschinen zur Berechtigung
In Unternehmen ist damit zu rechnen, dass viele Linux-Maschinen ähnliche Aufga-
ben haben und aus diesem Grund auch von der selben Personengruppe administriert
werden. Falls sich diese Personengruppe ändert, wäre es mühsam die Berechtigun-
gen für alle betroffenen Maschinen individuell neu zu setzen. Die Maschinen sollten
sich deshalb im Key Access Management System zu Gruppen zusammenfügen las-
sen, um die Berechtigungen zentral an einer Stelle definieren zu können. Sofern die
Möglichkeit besteht, Server hierzu in Gruppen zusammenzufassen, werden in der
Nutzwertanalyse 80 Punkte vergeben.
32 Anforderungen
2.4 Umgang mit unbekannten Schlüsseln
Das Key Access Management System wird bei der Interaktion mit Zielservern auf
SSH-Schlüssel treffen, deren Besitzer nicht bekannt ist, da die Schlüssel noch nicht
ins System eingetragen wurden. Dies betrifft zum einen den vorhandenen Bestand
an Schlüsseln, zum anderen aber auch neue Schlüssel die ein Linux-Administrator
auf Zielsystemen einträgt. Die folgenden Kriterien beziehen sich auf den Umgang
mit diesen unbekannten Schlüsseln.
2.4.1 Behandlung beim Erscheinen
Die unbekannten Schlüssel dürfen zunächst einmal nicht vom System gelöscht oder
anderweitig unbrauchbar gemacht werden. Hintergrund ist, dass auch außenstehen-
de Nutzer welche keinen Zugang zu dem Key Access Management System haben,
auf bestimmte Zielsysteme zugreifen dürfen. Dieser Zugriff darf nicht verloren ge-
hen. Im Falle der Leitwerk AG besitzen einige Kunden selbst Zugang zu den eige-
nen Linux-Servern, welcher nicht ohne Rücksprache deaktiviert werden darf. Die-
ses Kriterium wird als besonders wichtig eingestuft und in der Nutzwertanalyse mit
300 Punkten bewertet.
2.4.2 Hinweis
Das Key Access Management System hat den Anspruch, Zugangsberechtigungen
übersichtlich und nachvollziehbar zu machen. Es dürfen deshalb keine unbekann-
ten Schlüssel unbemerkt auf Zielsystemen vorhanden sein. Aus diesem Grund wird
von dem Key Access Management System ein Hinweis verlangt, welcher auf unbe-
kannte Schlüssel aufmerksam macht um deren Rechtmäßigkeit anschließend manu-
ell zu bewerten. Kann das Key Access Management System einen solchen Hinweis
liefern, erhält sie zusätzliche 100 Punkte in der Nutzwertanalyse.
2.4.3 Möglichkeit zur Deaktivierung
Die im Bestand vorhandenen SSH-Schlüssel sind zum Teil nicht mehr in Benut-
zung und sollten deshalb von Zielsystemen gelöscht werden. Gründe dafür gibt es
42 Anforderungen
verschiedene, beispielsweise könnte es sich um ehemalige Mitarbeiter des Unter-
nehmens handeln, oder um SSH-Schlüssel von nicht mehr vorhandenen Geräten.
Das Key Access Management System sollte es ermöglichen, derartige Schlüssel zu
deaktivieren, sodass diese in der Folge automatisch von allen Zielsystemen entfernt
werden. In der Nutzwertanalyse sind 100 Punkte vorgesehen, wenn diese Deakti-
vierung ermöglicht wird.
2.4.4 Möglichkeit zur Erlaubnis
Einige der auf Zielsystemen vorhandenen SSH-Schlüssel werden noch für den Zu-
griff benötigt, jedoch von Personen die selbst keinen Zugang zu dem Key Access
Management System haben. Im Zusammenhang mit dem oben genannten Hinweis
auf solche Schlüssel soll es deshalb auch die Möglichkeit geben, einzelne Schlüs-
sel als erlaubt zu definieren, sodass der Hinweis verschwindet und auch kein neuer
Hinweis für diesen Schlüssel angezeigt wird, sollte er auf weiteren Maschinen ge-
funden werden. Das Ziel ist, dass die Liste von Hinweisen hierüber aufgeräumt
werden kann und anschließend nur noch neu gefundene Schlüssel darin auftauchen.
Kann das SSH Key Management System diese Art von Erlaubnis einzelner Schlüs-
sel bieten, erhält es 50 Punkte in der Nutzwertanalyse.
2.5 Auswirkung auf die Benutzung
Linux-Administratoren sind es gewohnt, beim Zugriff auf Zielsysteme das Kom-
mando ‘ssh‘ zu benutzen und zur Authentifizierung lediglich den private-Key mit
der entsprechenden Passphrase zu entsperren. Das SSH Key Management System
soll an diesem Vorgang nichts ändern, insbesondere keine zusätzlichen Arbeits-
schritte für die Verbindung erfordern. Wenn der SSH Loginvorgang für den Nutzer
genau wie ohne das Key Access Management System abläuft, erhält das System
weitere 100 Punkte in der Nutzwertanalyse.
52 Anforderungen
2.6 Umgang mit privaten Schlüsseln
Für eine maximale Sicherheit darf ein SSH private-Key zu keinem Zeitpunkt an ei-
nem anderen Ort liegen als auf dem Linux-System auf dem er benutzt wird. Mit ei-
nem gestohlenen private-Key könnte sich ein Angreifer auf Zielsystemen einloggen
und die Verbindung würde im Log erscheinen als wäre sie vom bestohlenen Nutzer
initiiert worden. Von dem Key Access Management System wird deshalb verlangt,
dass es nur public-Keys verwaltet und nicht im Besitz der zugehörigen private-Keys
ist. Diese Sicherheitsanforderung wird in der Nutzwertanalyse mit 100 Punkte be-
wertet.
2.7 Verwaltungsoberfläche
Ein Key Access Management System kann nur dann den Ablauf der Schlüssel-
verteilung vereinfachen, wenn es selbst einfach zu benutzen ist. Eine komfortable
Oberfläche zur Verwaltung, welche von jedem Nutzer intuitiv bedient werden kann,
ist deshalb wünschenswert. Diese Anforderung ist in der Nutzwertanalyse 50 Punk-
te wert.
2.7.1 Webbasierte Oberfläche
Eine Verwaltungsoberfläche im Webbrowser hat den Vorteil, dass auf den Arbeits-
stationen der Nutzer keine zusätzliche Software erforderlich ist, denn ein Web-
browser gehört bereits zur Standardausstattung. Aus diesem Grund erhalten Key
Access Management Systeme mit webbasierter Verwaltung zusätzliche 5 Punkte in
der Nutzwertanalyse.
2.8 Automatische Wirksamkeit geänderter Rechte
Das Key Access Management System bietet verschiedene Use-Cases, bei denen
sich konkrete Zugriffsberechtigungen für bestimmte SSH-Schlüssel zu bestimmten
Zielsystemen ändern. Diese geänderten Berechtigungen sollen automatisch wirk-
sam werden. Für die Nutzwertanalyse werden zwei Fälle unterschieden und separat
bewertet. Wenn ein Schlüssel neu für einen Zugriff berechtigt wird und diese Be-
62 Anforderungen
rechtigung automatisch wirksam wird, ist dies 60 Punkte wert. Wenn einem Schlüs-
sel umgekehrt ein Zugriffsrecht genommen wird und das Key Access Management
automatisch die Zugriffsmöglichkeit für diesen Schlüssel deaktivieren kann, ist das
weitere 70 Punkte wert. Insgesamt können somit 130 Punkte durch diese Anforde-
rung erzielt werden, falls in beiden Fällen die Anforderung erfüllt ist. Der zweite
Fall hat eine höhere Bewertung, da das Entfernen von Rechten im Gegensatz zur
Neuberechtigung sicherheitsrelevant ist.
2.9 Einschränkung der Rollout-Schnittstelle
Das Key Access Management System ist konzeptionell bedingt in einer großen
Machtposition, da es die Möglichkeit hat, neue Zugangsschlüssel auf eine große
Anzahl von Linux-Systemen zu verteilen. In Einzelfällen, beispielsweise wenn ein
fremdes Unternehmen die Betriebsverantwortung für ein Linux System besitzt, ist
diese Machtposition möglicherweise nicht erwünscht. Für derartige Fälle sollte es
durch eine spezielle Konfiguration auf dem Zielsystem möglich sein, das Key Ac-
cess Management System zumindest soweit einzuschränken, dass es Schlüssel nur
für ausgewählte Nutzer des Zielsystems verwalten kann. Wird eine solche Ein-
schränkung technisch ermöglicht, erhält das System weitere 30 Punkte in der Nutz-
wertanalyse.
2.10 Nutzernamen auf Zielmaschinen
Auf Zielmaschinen existiert in manchen Fällen nur ein einzelnes Nutzerkonto für
root, oftmals gibt es aber auch noch weitere Nutzerkonten. Von dem Key Access
Management System wird erwartet, dass bei der Vergabe von Zugriffsberechtigun-
gen flexibel definierbar ist, unter welchem Nutzernamen sich ein Nutzer auf Ziel-
maschinen einloggen darf. Bei der Nutzwertanalyse werden 25 Punkte vergeben,
falls der Name des Zielnutzers einstellbar ist.
72 Anforderungen
2.11 Plattformunabhängigkeit bezüglich Zielmaschinen
SSH-Schlüssel müssen für verschiedenartige Zielmaschinen verwaltet werden. Es
existieren verschiedene Linux-Distributionen, je nach Anforderungen wurden ver-
schiedene Pakete installiert und die Konfigurationen unterscheiden sich. Das Key
Access Management System darf deshalb keine speziellen Anforderungen an die
Plattform der Zielmaschinen haben und auch keine eigene Software mitliefern, die
für die Kompatibilität bestimmte Anforderungen an die Plattform haben könnte.
Wird auf den Zielsystemen ausschließlich Standardsoftware wie OpenSSH ver-
langt, ist dies in der Nutzwertanalyse 45 Punkte wert.
2.12 Schlüsseloptionen
OpenSSH bietet die Möglichkeit, public-Keys auf Zielsystemen mit Zusatzoptio-
nen zu versehen. Durch diese Optionen kann beispielsweise eingeschränkt werden,
von welchen IP-Adressen der Schlüssel zur Authentifizierung benutzt werden darf
oder der Zugriff kann auf die Ausführung eines einzelnen Kommandos beschränkt
werden. Es ist wünschenswert, dass auch im Key Access Management System die-
se Optionen bei Berechtigungen festgelegt werden können, sodass ein Zugriffsrecht
nicht in jedem Fall Vollzugriff bedeuten muss. Wird die Angabe von Optionen un-
terstützt, erhält das System hierfür 60 Punkte in der Nutzwertanalyse.
2.13 Beteiligung des Tools am Loginvorgang
Für die Wartung von Linux-Systemen ist es wichtig, einen zuverlässigen Weg für
den SSH-Login zu besitzen. Ein single-point-of-failure könnte im Falle einer Stö-
rung die Fehlerbehebung unnötig verzögern und dadurch hohe Kosten verursachen.
Es ist deshalb wichtig, dass der SSH-Login, sobald die Zugriffsrechte einmal verge-
ben sind, auch ohne das Key Access Management System möglich ist. Wenn bereits
berechtigte Nutzer auch bei einem Ausfall des Systems noch weiter arbeiten kön-
nen, ist dies in der Nutzwertanalyse 70 Punkte wert.
82 Anforderungen
2.14 Definition des Schlüsselkommentars
Die public-Keys von OpenSSH werden prinzipiell mit einem Kommentarfeld gene-
riert, welches standardmäßig den Nutzernamen und Hostnamen des generierenden
Linux-Accounts enthält. Dieses Kommentarfeld ist aber frei änderbar, nicht an den
kryptografischen Schlüssel gebunden und somit von geringem Wert. Ein SSH Key
Access Management System könnte den Kommentar bei ausgerollten Schlüsseln
durch einen fest definierten Wert ersetzen. Wenn dies geschieht, sodass bei einem
Schlüssel auf dem Zielsystem immer der Inhaber erkennbar ist, wird dies in der
Nutzwertanalyse mit 40 Punkten bewertet.
2.15 Export der vorhandenen Schlüssel
Für eine möglichst hohe Flexibilität im Umgang mit SSH-Schlüsseln sollten sich die
von Nutzern gepflegten Schlüssel in einem maschinenlesbaren Format exportieren
lassen. Dies ermöglicht die Kommunikation mit anderen Systemen, beispielsweise
um Schlüssel auf spezielle Geräte auszurollen, welche nicht mit der erforderlichen
Linux-Standardsoftware ausgestattet sind. Außerdem können über die Schnittstelle
Analysen zum vorhandenen Bestand an Schlüsseln erstellt werden. Wenn ein Export
der public-Keys von Nutzern möglich ist, erhält das System hierfür 50 Punkte in der
Nutzwertanalyse.
2.16 AD Anbindung
Unternehmen besitzen meist ein AD1 System, in dem Mitarbeiter und verschiedene
Berechtigungsgruppen bereits vorhanden sind. Eine Anbindung an dieses AD bietet
deshalb Vorteile, welche im Folgenden beschrieben sind.
2.16.1 Login mit AD-Zugang
Ein Login am Key Access Management System mit den im AD hinterlegten Zu-
gangsdaten bietet den Vorteil, dass sich Nutzer mit den bekannten Daten einloggen
können und keine separaten Zugangsdaten benötigen. Dies wäre zwar auch dann
1
Active Directory
92 Anforderungen
der Fall, wenn Benutzer manuell bei jedem Dienst das selbe Passwort vergeben, mit
der AD-Integration wird aber auch eine Passwortänderung vereinfacht, da der Nut-
zer das Passwort dann nur einmal an zentraler Stelle ändern muss. Die Möglichkeit
des Logins von Nutzern mit AD-Zugangsdaten wird in der Nutzwertanalyse mit 50
Punkten bewertet.
2.16.2 Import von Gruppen aus dem AD
Die im AD vorhandenen Gruppen bilden meist Abteilungen und andere organisa-
torische Strukturen ab und können mit hoher Wahrscheinlichkeit im Key Access
Management System für die Vergabe von Berechtigungen sinnvoll wiederverwen-
det werden. Wenn das System erlaubt, Gruppen mit deren Mitgliedern aus dem AD
zu importieren und auch stets zu synchronisieren, werden hierfür in der Nutzwert-
analyse 20 Punkte vergeben.
2.17 Erfassung des Alters von Schlüsseln
Abhängig von Richtlinien zum Umgang mit SSH-Schlüsseln wird unter Umständen
verlangt, alle Schlüssel in regelmäßigen Abständen auszutauschen. Für die Über-
wachung einer solchen Richtlinie muss das Key Access Management System er-
fassen, wie lange ein Schlüssel bereits existiert. Es ist nicht möglich das genaue
Erstellungsdatum zu ermitteln, da dieses in einem SSH-Key nicht gespeichert wird.
Das Eintragungsdatum kann aber als Näherung für das Erstellungsdatum angese-
hen werden. Ein Key Access Management System, welches das Eintragungsdatum
jedes Schlüssels erfasst, erhält hierfür 20 Punkte in der Nutzwertanalyse.
2.18 Kompatibilität mit Client-Maschinen
Abhängig vom der konkreten technischem Umsetzung eines Key Access Mana-
gement Systems könnte eine spezielle Software für SSH-Clients benötigt werden.
Dies würde jedoch den Aufwand für die Inbetriebnahme erhöhen, da einerseits die
Kompatibilität mit verschiedenen Systemumgebungen sichergestellt werden muss
und andererseits die Installation auf allen nutzenden Systemen erforderlich wäre.
102 Anforderungen
Ein System, bei dem Standard OpenSSH Clients ohne zusätzliche Software für die
Verbindung genutzt werden können, erhält deshalb 10 weitere Punkte in der Nutz-
wertanalyse.
113. Verfügbare Software
In diesem Kapitel werden verschiedene, bereits existierende Systeme zur Verwal-
tung von SSH-Schlüsseln vorgestellt. Nach einer kurzen Beschreibung der wesent-
lichen Merkmale eines Produkts wird der Erfüllungsgrad der zuvor festgelegten
Kriterien ermittelt und die Berechnung des Gesamt-Nutzwerts durchgeführt. Diese
Nutzwertanalyse ist tabellarisch dargestellt.
Die Informationen zur Erfüllung oder nicht-Erfüllung einzelner Kriterien basieren
auf zwei verschiedenen Quellen. Einige Merkmale ergeben sich aus Angaben des
Software-Herstellers, beispielsweise aus den Informationen der Produkt-Webseite
oder aus der Kommunikation während der Produktberatung. Andere Eigenschaften
wurden in einer Testumgebung nach der Installation des zu bewertenden Produkts
ermittelt, indem die verschiedenen gewünschten Funktionen getestet wurden.
3.1 Key Manager Plus
Die Software Key Manager Plus ist ein Produkt des Unternehmens Zoho Corpora-
tion Pvt. Ltd. [Ma16]
Die Software erlaubt dem Nutzer beispielsweise, direkt aus dem Webbrowser heraus
per SSH auf Linux-Server zuzugreifen. Hierzu müsste allerdings der private-Key
durch das Tool generiert werden, was nicht erwünscht ist.
Kriterium Bewertung Begründung
Hinzufügen von 0 Nur Nutzer mit erhöhten Berechtigungen
Schlüsseln können Schlüssel hinzufügen.
Deaktivierung von 0 Nur Nutzer mit erhöhten Berechtigungen
Schlüsseln können Schlüssel löschen.
123 Verfügbare Software
Kriterium Bewertung Begründung
Möglichkeit zur 5 Ein gelöschter Schlüssel kann erneut im-
Reaktivierung portiert werden.
Gruppierung von 0 Zwar lassen sich Berechtigungen für
Zielmaschinen zur mehrere Maschinen setzen, es können je-
Berechtigung doch keine Gruppen von Maschinen defi-
niert werden.
Behandlung 300 Vorhandene Schlüssel auf Zielsystemen
unbekannter Schlüssel bleiben unberührt.
bei Erscheinen
Hinweis bei 0 Es wird kein Hinweis erzeugt, wenn sich
unbekannten fremde Schlüssel auf einem Zielsystem
Schlüsseln befinden.
Deaktivierbarkeit 0 Es existiert keine Option, Schlüssel als
unbekannter Schlüssel verboten zu kennzeichnen.
Möglichkeit zur 0 Bewertung entfällt, da kein Hinweis für
Erlaubnis unbekannter fremde Schlüssel erzeugt wird.
Schlüssel
Auswirkung auf die 100 Es wird eine klassische Key-
Benutzung Authentifizierung ohne Umwege
eingesetzt.
Umgang mit privaten 100 Obwohl die Software auch Schlüssel er-
Schlüsseln zeugen kann, ist eine Betriebsart ohne
die Speicherung von private-Keys im Tool
möglich.
Verwaltungsoberfläche 50 Eine intuitive grafische Verwaltungsober-
fläche ist vorhanden.
Webbasierte 5 Die Verwaltung geschieht im Webbrow-
Oberfläche ser.
Automatische 130 Sowohl neu vergebene als auch zurück-
Wirksamkeit genommene Berechtigungen werden im
geänderter Rechte Hintergrund automatisch wirksam.
Einschränkung der 30 Das Tool ist auch in der Lage einzelne
Rollout-Schnittstelle Nutzerkonten zu verwalten, ohne Root-
rechte zu besitzen.
133 Verfügbare Software
Kriterium Bewertung Begründung
Nutzernamen auf 25 Bei der Berechtigungsvergabe kann der
Zielmaschinen Nutzername festgelegt werden.
Plattformunabhängigkeit 45 Es gibt keine speziellen Anforderungen
bezüglich an die Umgebung der Zielmaschine, eine
Zielmaschinen Standardinstallation reicht aus.
Schlüsseloptionen 0 Es ist nicht möglich, Berechtigungen mit
Optionen zu versehen. Der Zugriff ist im-
mer uneingeschränkt.
Beteiligung des Tools 70 Die public-Keys werden auf die Zielsys-
am Loginvorgang teme verteilt, sodass der Login ohne das
Tool möglich ist.
Definition des 0 Der Schlüsselkommentar kann beim Im-
Schlüsselkommentars port in der Weboberfläche frei gewählt
werden.
Export der 0 Zwar lassen sich einzelne Keys exportie-
vorhandenen Schlüssel ren, jedoch nicht die gesamte Liste. Die
Funktion ist somit nicht praktikabel nutz-
bar.
Login mit AD-Zugang 50 Eine AD Anbindung für den Login kann
in den Einstellungen aktiviert werden.
Import von Gruppen 20 Bei einer AD Anbindung können auch
aus dem AD Nutzergruppen übernommen werden.
Erfassung des Alters 20 Der Eintrage-Zeitpunkt jedes Schlüssels
von Schlüsseln ist in der Weboberfläche einsehbar.
Kompatibilität mit 10 Der Clientrechner benötigt lediglich
Client-Maschinen einen klassischen OpenSSH-Client.
In der Summe erreicht Key Manager Plus 960 Punkte in der Nutzwertanalyse.
3.2 Universal SSH Key Manager
Der Universal SSH Key Manager wird vom Unternehmen SSH Communications
Security angeboten. [SS14]
143 Verfügbare Software
Es ist eines von wenigen Tools, welches auch Schlüssel auf Zielsystemen überwa-
chen kann.
Kriterium Bewertung Begründung
Hinzufügen von 0 Das Hinzufügen von Schlüsseln und die
Schlüsseln Zugriffsvergabe ist nur Nutzern mit er-
höhten Rechten möglich.
Deaktivierung von 100 Ein Nutzer kann selbständig Zugriffs-
Schlüsseln rechte von seinen eigenen Schlüsseln neh-
men.
Möglichkeit zur 5 Für einen Schlüssel können von berech-
Reaktivierung tigten Personen wieder Zugriffsrechte er-
teilt werden.
Gruppierung von 0 Berechtigungen werden einzeln verge-
Zielmaschinen zur ben. Eine Gruppierung von Servern ist
Berechtigung nicht möglich.
Behandlung 300 Ein unbekannter Schlüssel wird zunächst
unbekannter Schlüssel unangetastet gelassen und bleibt aktiv.
bei Erscheinen
Hinweis bei 100 Wird ein neuer public-Key auf einem
unbekannten Zielsystem hinterlegt, ist dies auf der
Schlüsseln Weboberfläche sichtbar.
Deaktivierbarkeit 0 Die auf Zielsystemen gefundenen Schlüs-
unbekannter Schlüssel sel können zwar per Weboberfläche de-
aktiviert werden, diese Entscheidung gilt
aber nicht automatisch für den selben
Schlüssel auf andere Maschinen.
Möglichkeit zur 0 Die Hinweise zu unbekannten Schlüs-
Erlaubnis unbekannter sel verschwinden nur dann, wenn für die
Schlüssel Zugänge Berechtigungen gesetzt werden.
Die Anforderung, bestimmte Schlüssel
pauschal als zulässig zu markieren, ist da-
mit nicht erfüllt.
Auswirkung auf die 100 Nach der einmaligen Rechtevergabe sind
Benutzung keine besonderen Schritte für einen Zu-
griff nötig.
153 Verfügbare Software
Kriterium Bewertung Begründung
Umgang mit privaten 100 Die Software verwaltet ausschließlich öf-
Schlüsseln fentliche Schlüssel.
Verwaltungsoberfläche 50 Es existiert eine komfortable grafische
Oberfläche für die Verwaltung.
Webbasierte 5 Berechtigungen werden über eine Webo-
Oberfläche berfläche verwaltet.
Automatische 130 Die Software kann bei Änderung von Be-
Wirksamkeit rechtigungen automatisch neue Schlüssel
geänderter Rechte verteilen und auch entfernen.
Einschränkung der 0 Das Tool erfordert nicht zwingend einen
Rollout-Schnittstelle Login als Root, muss aber alternativ zu-
mindest über sudo Rootrechte erlangen,
um korrekt arbeiten zu können. Es ist
nicht möglich, einzelne Nutzerkonten oh-
ne Rootrechte zu verwalten.
Nutzernamen auf 25 Der Nutzername ist bei Berechtigungen
Zielmaschinen einstellbar.
Plattformunabhängigkeit 45 Es ist keine spezielle Software auf Ziel-
bezüglich systemen erforderlich.
Zielmaschinen
Schlüsseloptionen 30 Es lässt sich nur die command-Option
von SSH nutzen, andere Optionen werden
nicht unterstützt. Deshalb werden 30 von
60 Punkten vergeben.
Beteiligung des Tools 70 Nach der Verteilung von Schlüsseln kön-
am Loginvorgang nen sich Nutzer unabhängig vom Univer-
sal SSH Key Manager auf Zielsystemen
einloggen.
Definition des 40 Als Schlüsselkommentar wird automa-
Schlüsselkommentars tisch der Besitzer des Schlüssels einge-
tragen, unabhängig vom ursprünglichen
Kommentar.
163 Verfügbare Software
Kriterium Bewertung Begründung
Export der 0 Es ist nicht möglich, eine Liste aller im
vorhandenen Schlüssel System vorhandenen Schlüssel zu expor-
tieren.
Login mit AD-Zugang 0 Im Test wurde eine Anbindung an ein
AD konfiguriert, der Login mit AD-
Zugangsdaten funktionierte jedoch nicht.
Import von Gruppen 0 Wie beim Login wurde die Anbindung
aus dem AD testweise konfiguriert, es ließen sich aber
keine Gruppen aus AD abrufen.
Erfassung des Alters 20 Der Zeitpunkt des Imports wird von allen
von Schlüsseln Schlüsseln erfasst und die Software bietet
auch Optionen, Nutzer zum regelmäßigen
Schlüsseltausch zu verpflichten.
Kompatibilität mit 10 Die Software verteilt lediglich public-
Client-Maschinen Keys auf Zielmaschinen, auf dem Client
ist somit keine spezielle Software not-
wendig.
In der Summe erreicht der Universal SSH Key Manager einen Nutzwert von 1130
Punkten.
3.3 PrivX
Die Software PrivX ist wie Universal SSH Key Manager ebenfalls ein Produkt von
SSH Communications Security. [SS18] In einem Beratungsgespräch mit dem Her-
steller zeigte sich Universal SSH Key Manager vielversprechender als PrivX, sodass
letztere Software nicht getestet wurde. Es sind somit lediglich die vom Hersteller
gegebenen Informationen bekannt.
Beim Einsatz von PrivX verändert sich die Art der Benutzung von SSH. Die Soft-
ware dient als Zwischenstation für Verbindungen vom Client zur Zielmaschine.
Zur Authentifizierung des Clients gegenüber PrivX wird auf Passwörter anstatt auf
Schlüssel gesetzt. Diese Eigenschaften führten zu einer frühen Entscheidung gegen
PrivX, weshalb die Kriterien der Software nicht vollumfänglich evaluiert wurden.
173 Verfügbare Software
Dennoch ist aus der folgenden Tabelle zu entnehmen, über welche der Kriterien eine
Aussage getroffen werden kann. Die Informationen beziehen sich auf Aussagen des
Herstellers.
Kriterium Bewertung Begründung
Hinzufügen von ? nicht getestet
Schlüsseln
Deaktivierung von ? nicht getestet
Schlüsseln
Möglichkeit zur ? nicht getestet
Reaktivierung
Gruppierung von 80 Gruppen zur Berechtigung können erstellt
Zielmaschinen zur werden.
Berechtigung
Behandlung 300 Unbekannte Schlüssel werden von PrivX
unbekannter Schlüssel nicht entfernt.
bei Erscheinen
Hinweis bei 0 Es werden keine Hinweise angezeigt,
unbekannten wenn sich unbekannte Schlüssel auf ei-
Schlüsseln nem System befinden.
Deaktivierbarkeit 0 PrivX setzt auf SSH-Zertifikate, deshalb
unbekannter Schlüssel werden Schlüssel auf Zielsystemen gene-
rell nicht angetastet.
Möglichkeit zur 0 Es werden keine Hinweise bei unbekann-
Erlaubnis unbekannter ten Schlüsseln erstellt, deshalb ist dieses
Schlüssel Kriterium nicht relevant.
Auswirkung auf die 0 Der Benutzer muss per SSH aktiv zur
Benutzung PrivX-Instanz verbinden und das ge-
wünschte Zielsystem in den Nutzernamen
kodieren. Außerdem geschieht die SSH-
Authentifizierung über AD-Zugangsdaten
anstatt über Schlüssel. Somit unterschei-
det sich die Benutzung grundlegend von
einer üblichen Verwendung von SSH.
183 Verfügbare Software
Kriterium Bewertung Begründung
Umgang mit privaten 0 PrivX besitzt alle privaten Schlüssel der
Schlüsseln Nutzer, um in deren Namen Verbindun-
gen zu Zielsystemen aufzubauen.
Verwaltungsoberfläche 50 Eine grafische Oberfläche zur Verwaltung
existiert.
Webbasierte 5 Die Verwaltung geschieht webbasiert, im
Oberfläche Browser.
Automatische 130 Bei jeder Verbindung werden die Berech-
Wirksamkeit tigungen geprüft, deshalb sind Änderun-
geänderter Rechte gen immer sofort wirksam.
Einschränkung der 30 Für eine Verwaltung von Zielmaschinen
Rollout-Schnittstelle ohne Root-Rechte existiert eine separa-
te Authentifizierungsmethode, unabhän-
gig von den standardmäßig eingesetzten
Zertifikaten.
Nutzernamen auf 25 Nutzernamen können bei der Berechti-
Zielmaschinen gungsvergabe festgelegt werden.
Plattformunabhängigkeit 45 Es wird keine spezielle Software auf Ziel-
bezüglich maschinen benötigt.
Zielmaschinen
Schlüsseloptionen 0 Die Angabe von Schlüsseloptionen wird
nicht unterstützt.
Beteiligung des Tools 0 Ein Login ist immer von PrivX abhängig,
am Loginvorgang da die Verbindung über das System gelei-
tet wird.
Definition des 0 Es wird standardmäßig zertifikatsbasierte
Schlüsselkommentars Authentifizierung genutzt, deshalb exis-
tieren keine Schlüsselkommentare.
Export der ? nicht getestet
vorhandenen Schlüssel
Login mit AD-Zugang 50 Ein AD kann für den Login genutzt wer-
den.
Import von Gruppen 20 Gruppen können aus einem verbundenen
aus dem AD AD eingelesen werden.
193 Verfügbare Software
Kriterium Bewertung Begründung
Erfassung des Alters 0 Wie lange ein Schlüssel schon benutzt
von Schlüsseln wird, ist in PrivX nicht sichtbar.
Kompatibilität mit 10 Für die Verbindung per SSH reicht ein
Client-Maschinen OpenSSH Client, lediglich die Art der
Benutzung unterscheidet sich von einer
Verbindung ohne PrivX.
Die Summe der bis hierher erfüllten Kriterien ergibt einen Nutzwert von 745 Punk-
ten, jedoch ist dieser Wert aufgrund der unvollständigen Evaluation nicht mit den
anderen Nutzwerten gleichzusetzen.
3.4 Keyper
Die Schlüsselverwaltung Keyper ist ein Produkt der DBSentry Corporation. [Gu20]
Im Gegensatz zu anderen Systemen rollt diese Software Schlüssel nicht aktiv auf
Zielsysteme aus sondern lässt diese bei jedem SSH-Login eine jeweils aktuelle Lis-
te der Schlüssel abrufen. Technisch umgesetzt ist dies über die Einstellung Autho-
rizedKeysCommand in der Konfiguration des OpenSSH Servers, worüber die Liste
gültiger Schlüssel vom Keyper-Server geladen wird.
Kriterium Bewertung Begründung
Hinzufügen von 100 Jeder Nutzer kann eigene Schlüssel ein-
Schlüsseln tragen.
Deaktivierung von 100 Jeder Nutzer kann auch eigene Schlüssel
Schlüsseln wieder deaktivieren, jedoch nicht final lö-
schen.
Möglichkeit zur 0 Eine Reaktivierung von bereits deak-
Reaktivierung tivierten Schlüsseln ist nicht möglich.
Auch ein erneuter Import wird abgelehnt,
da die Software den Schlüssel wiederer-
kennt.
203 Verfügbare Software
Kriterium Bewertung Begründung
Gruppierung von 80 Prinzipiell können Gruppen aus Hosts er-
Zielmaschinen zur stellt werden. Manuell erstellte Gruppen
Berechtigung scheinen sich anders zu verhalten als au-
tomatisch erstellte was nicht ganz intuitiv
ist, dies wurde jedoch nicht im Detail un-
tersucht.
Behandlung 300 Schlüssel die sich in authorized_keys be-
unbekannter Schlüssel finden, werden von Keyper nicht angetas-
bei Erscheinen tet, da die Software ausschließlich auf das
AuthorizedKeysCommand setzt.
Hinweis bei 0 Es wird kein Hinweis erzeugt, falls neue
unbekannten Schlüssel in authorized_keys auftauchen.
Schlüsseln Die Datei wird schlicht nicht berücksich-
tigt.
Deaktivierbarkeit 0 Es existiert kein Mechanismus, um be-
unbekannter Schlüssel stimmte Schlüssel in authorized_keys ge-
zielt zu löschen.
Möglichkeit zur 0 Nicht relevant, da keine Hinweise für un-
Erlaubnis unbekannter bekannte Schlüssel erzeugt werden.
Schlüssel
Auswirkung auf die 100 Der Nutzer erkennt beim Login kei-
Benutzung nen Unterschied zur klassischen Key-
Authentifizierung. Die relevanten Schritte
passieren im Hintergrund.
Umgang mit privaten 100 Keyper speichert und verarbeitet nur die
Schlüsseln public-Keys der Nutzer.
Verwaltungsoberfläche 50 Eine komfortable Oberfläche zur Verwal-
tung der Schlüssel und Berechtigungen ist
vorhanden.
Webbasierte 5 Die Verwaltungsoberfläche ist webba-
Oberfläche siert.
213 Verfügbare Software
Kriterium Bewertung Begründung
Automatische 130 Da die Liste gültiger Schlüssel bei jedem
Wirksamkeit SSH-Login von der zentralen Verwaltung
geänderter Rechte angefragt wird, sind neue und entfernte
Rechte immer sofort wirksam.
Einschränkung der 0 Das festgelegte AuthorizedKeysCom-
Rollout-Schnittstelle mand gilt immer für alle Nutzer eines
Systems. Eine Einschränkung wäre
nur durch ein speziell konstruiertes
Kommando möglich, beispielsweise ein
Wrapper-Skript, dieses ist jedoch nicht
im Funktionsumfang enthalten.
Nutzernamen auf 0 Keyper erlaubt Nutzern immer nur, sich
Zielmaschinen mit dem eigenen Nutzernamen auf Zielen
einzuloggen. Der Name ist nicht per Be-
rechtigung definierbar.
Plattformunabhängigkeit 0 Für die Abfrage der Schlüssel ist Zu-
bezüglich satzsoftware auf Zielmaschinen nötig, de-
Zielmaschinen ren Kompatibilität sichergestellt werden
muss.
Schlüsseloptionen 0 Die Vergabe von Schlüsseloptionen ist
nicht vorgesehen.
Beteiligung des Tools 0 Keyper muss bei jedem Login die gülti-
am Loginvorgang gen Schlüssel bereitstellen und ist deshalb
ein single-point-of-failure.
Definition des 0 Der Schlüsselkommentar ist nicht rele-
Schlüsselkommentars vant, da die Schlüssel nicht, wie sonst üb-
lich, auf dem Zielsystem gespeichert sind.
Export der 0 Eine Funktion zum Schlüsselexport fehlt
vorhandenen Schlüssel in Keyper.
Login mit AD-Zugang 0 Keyper benutzt eine einfache Passwortau-
thentifizierung, die es selbst verwaltet.
Import von Gruppen 0 Es kann kein AD angebunden werden,
aus dem AD deshalb sind auch die darin enthaltenen
Gruppen nicht nutzbar.
223 Verfügbare Software
Kriterium Bewertung Begründung
Erfassung des Alters 0 Der Zeitpunkt des Eintragens eines
von Schlüsseln Schlüssels ist nicht zu sehen, lediglich
dessen Ablaufdatum. Jedoch muss jeder
Schlüssel nach einer festgelegten Zeit ab-
laufen. Die maximale Gültigkeit sind 500
Wochen, das entspricht knapp 10 Jahren.
Kompatibilität mit 10 Auf dem Client wird nur OpenSSH be-
Client-Maschinen nötigt, da sich am Prozess der Key-
Authentifizierung nichts ändert.
Der Nutzwert von Keyper beträgt in der Summe 975 Punkte.
3.5 Userify
Userify ist eine Dienstleistung des Unternehmens Userify Corporation. [Us13] Stan-
dardmäßig wird die Software zentral durch das Unternehmen bereitgestellt, auf
Wunsch ist aber auch das Hosting in der eigenen Infrastruktur möglich.
Kriterium Bewertung Begründung
Hinzufügen von 100 Ein Nutzer kann seine eigenen Schlüssel
Schlüsseln in das System eintragen.
Deaktivierung von 100 Jeder Nutzer kann seine eigenen Schlüs-
Schlüsseln sel auch wieder löschen.
Möglichkeit zur 5 Ein zuvor gelöschter Schlüssel kann er-
Reaktivierung neut eingetragen werden.
Gruppierung von 80 Grundsätzlich können Server gruppiert
Zielmaschinen zur werden, jedoch dürfen diese Gruppen
Berechtigung nicht überlappen. Das bedeutet, ein Ser-
ver kann nicht in zwei Gruppen gleichzei-
tig enthalten sein.
Behandlung 0 Userify löscht rücksichtslos unbekannte
unbekannter Schlüssel Schlüssel in authorized_keys, welche dort
bei Erscheinen z.B. manuell eingetragen wurden.
233 Verfügbare Software
Kriterium Bewertung Begründung
Hinweis bei 0 Es ist kein Hinweis zu sehen, wenn ein
unbekannten fremder Schlüssel von Userify gefunden
Schlüsseln und gelöscht wurde.
Deaktivierbarkeit 100 Effektiv werden alle unbekannten Schlüs-
unbekannter Schlüssel sel von Zielsystemen gelöscht. Damit ist
rein formal die Anforderung erfüllt.
Möglichkeit zur 0 Es lassen sich keine Ausnahmen für be-
Erlaubnis unbekannter stimmte Schlüssel festlegen. Nur berech-
Schlüssel tigte Schlüssel bleiben in authorized_keys
stehen.
Auswirkung auf die 100 Userify verwaltet die Schlüssel in authori-
Benutzung zed_keys, sodass sich für den Login keine
Besonderheiten ergeben.
Umgang mit privaten 100 Es werden keine privaten Schlüssel durch
Schlüsseln Userify verarbeitet.
Verwaltungsoberfläche 50 Schlüssel und Berechtigungen können
über eine intuitive Oberfläche verwaltet
werden.
Webbasierte 5 Die Verwaltungsoberfläche ist webba-
Oberfläche siert, entweder zentral oder von eigenen
Servern bereitgestellt.
Automatische 130 Jede Änderung von Berechtigungen wird
Wirksamkeit sofort per SSH auf die Zielmaschinen
geänderter Rechte übernommen.
Einschränkung der 0 Die zentrale Userify-Instanz benötigt auf
Rollout-Schnittstelle allen verwalteten Servern Rootrechte.
Nutzernamen auf 0 Jeder Nutzer muss sich zunächst mit sei-
Zielmaschinen nem eigenen Namen auf dem Zielsys-
tem einloggen. Wenn bei der Berech-
tigung der Root-Zugang erlaubt wurde,
wird durch Userify das sudo-Programm
entsprechend konfiguriert.
243 Verfügbare Software
Kriterium Bewertung Begründung
Plattformunabhängigkeit 0 Auf Zielsystemen muss spezielle, von
bezüglich Userify bereitgestellte Software ausge-
Zielmaschinen führt werden.
Schlüsseloptionen 0 Es ist keine Möglichkeit vorgesehen, Be-
rechtigungen mit Schlüsseloptionen zu
versehen.
Beteiligung des Tools 70 Nach dem Ausrollen eines Schlüssels
am Loginvorgang wird Userify für den Login-Vorgang nicht
mehr benötigt.
Definition des 0 Als Schlüsselkommentar wird der ur-
Schlüsselkommentars sprüngliche, frei wählbare Kommentar
benutzt.
Export der 0 Es existiert keine Funktion für den Export
vorhandenen Schlüssel der public-Keys.
Login mit AD-Zugang 50 Eine Anbindung an ein AD wird im En-
terprise Modell angeboten.
Import von Gruppen ? Das Enterprise Modell wurde nicht getes-
aus dem AD tet, deshalb ist nicht bekannt ob sich auch
Gruppen importieren lassen.
Erfassung des Alters 0 In der Oberfläche ist nicht sichtbar, wie
von Schlüsseln lange ein Schlüssel bereits existiert.
Kompatibilität mit 10 Da Userify Schlüssel nach authori-
Client-Maschinen zed_keys ausrollt, wird lediglich ein
OpenSSH Client benötigt.
In der Nutzwertanalyse schneidet Userify mit einer Summe von 900 Punkten ab.
3.6 Vault
Die Software Vault ist ein Produkt des Unternehmens HashiCorp. [Ha16] Das Tool
setzt auf SSH-Zertifikate, für die OpenSSH bereits grundlegende Werkzeuge bietet.
Anstatt public-Keys direkt auf Zielsystemen zu verteilen, werden durch eine Zer-
tifizierungsstelle, in diesem Fall die Vault-Instanz, SSH-Zertifikate ausgestellt, die
253 Verfügbare Software
den Zugriff für einen bestimmten Schlüssel auf ein bestimmtes System gewähren.
Der Client muss dieses Zertifikat während des Login-Vorgangs benutzen, der Server
vertraut der Zertifizierungsstelle und überprüft das vom Client gesendete Zertifikat.
Bei der Ausstellung eines Zertifikats muss immer eine Gültigkeitsdauer angegeben
werden. Besonders für Vault ist die Dauer der Gültigkeit von Bedeutung, da das
System nicht von der Revocation List Gebrauch macht, das bedeutet eine vergebene
Berechtigung wird nur durch Überschreiten des Ablaufdatums unwirksam.
Bei der Nutzwertanalyse werden deshalb zwei mögliche Betriebsweisen von Vault
unterschieden.
Eine Möglichkeit ist die Nutzung kurzlebiger Zertifikate. Dabei fordert der Client
beim SSH-Login automatisch ein Zertifikat von Vault an, welches maximal wenige
Minuten gültig ist und benutzt dieses direkt für die Authentifizierung. Die hierfür
benötigte Software auf Clientseite wird jedoch nicht mitgeliefert und müsste separat
entwickelt werden.
Eine andere Möglichkeit ist die Nutzung langlebiger Zertifikate. Hierbei werden
Zertifikate manuell für eine Dauer von Monaten oder Jahren ausgestellt und auf dem
Clientrechner abgelegt. Für den entsprechenden Zeitraum muss dieses Zertifikat
somit nicht mehr angetastet werden.
Bei den Kriterien mit zwei Bewertungen in der nun folgenden Tabelle bezieht sich
der erste Wert auf die Variante mit kurzlebigen Zertifikaten, der zweite Wert auf
die Variante mit langlebigen Zertifikaten. Ist nur ein Wert angegeben, gilt dieser für
beide Betriebsvarianten.
Kriterium Bewertung Begründung
Hinzufügen von 100 Ein Nutzer kann sich bei bestehender Be-
Schlüsseln rechtigung jederzeit selbständig Schlüssel
zertifizieren lassen.
Deaktivierung von 100 / 0 Bei kurzlebigen Zertifikaten werden aus-
Schlüsseln gestellte Zugriffsrechte automatisch in-
nerhalb kurzer Zeit ungültig, bei langle-
bigen Zertifikaten ist eine Deaktivierung
nicht möglich.
Möglichkeit zur 5 Ein Schlüssel kann auch immer erneut
Reaktivierung zertifiziert werden.
263 Verfügbare Software
Kriterium Bewertung Begründung
Gruppierung von 80 Vault bietet eine Gruppen- und Rechte-
Zielmaschinen zur verwaltung für die Ausstellung von Zer-
Berechtigung tifikaten.
Behandlung 300 Schlüssel, die sich in authorized_keys be-
unbekannter Schlüssel finden, werden von Vault nicht berück-
bei Erscheinen sichtigt.
Hinweis bei 0 Da Vault ausschließlich Zertifikate aus-
unbekannten stellt, erkennt es keine Schlüssel die sich
Schlüsseln in authorized_keys befinden.
Deaktivierbarkeit 0 Es existiert keine Funktion, um unbe-
unbekannter Schlüssel kannte Schlüssel von Zielsystemen zu
entfernen.
Möglichkeit zur 0 Nicht relevant, da keine Hinweise für un-
Erlaubnis unbekannter bekannte Schlüssel erzeugt werden.
Schlüssel
Auswirkung auf die 100 Bei entsprechender Automatisierung er-
Benutzung kennt der Nutzer selbst bei kurzlebigen
Zertifikaten keinen Unterschied.
Umgang mit privaten 100 Vault benötigt keine private-Keys der
Schlüsseln Nutzer und arbeitet ausschließlich mit
public-Keys.
Verwaltungsoberfläche 50 Es existiert eine komfortable Oberfläche
zur Verwaltung der Berechtigungen und
zum Ausstellen der Zertifikate.
Webbasierte 5 Die Verwaltungsoberfläche ist webba-
Oberfläche siert.
Automatische 130 / 0 Nur bei kurzlebigen Zertifikaten sind
Wirksamkeit Änderungen der Berechtigung automa-
geänderter Rechte tisch wirksam. Bei langlebigen Zertifika-
ten muss der Nutzer zuerst Zertifikate er-
stellen und herunterladen bzw. beim Ent-
fernen von Berechtigungen bleiben beste-
hende Zertifikate noch gültig.
273 Verfügbare Software
Kriterium Bewertung Begründung
Einschränkung der 0 Als vertraute Zertifizierungsstelle kann
Rollout-Schnittstelle Vault Zertifikate für beliebige Nutzerkon-
ten auf Zielsystemen ausstellen.
Nutzernamen auf 25 Durch Berechtigungen lässt sich festle-
Zielmaschinen gen, für welchen Login-Namen ein Nut-
zer Zertifikate ausstellen darf.
Plattformunabhängigkeit 45 OpenSSH bringt zertifikatsbasierte Au-
bezüglich thentifizierung bereits mit, sodass keine
Zielmaschinen spezielle Software auf Servern nötig ist.
Schlüsseloptionen 60 Berechtigungen lassen sich so definie-
ren, dass Nutzer nur Zertifikate mit be-
stimmten, vorgegebenen Optionen aus-
stellen dürfen.
Beteiligung des Tools 0 / 70 Bei kurzlebigen Zertifikaten ist ohne
am Loginvorgang Vault ein Login nicht mehr möglich, bei
langlebigen Zertifikaten können zumin-
dest bereits ausgestellte Zertifikate wei-
terhin genutzt werden.
Definition des 0 Es existiert keine Datei auf Zielsystemen,
Schlüsselkommentars welche public-Keys enthält, deshalb ist
dieses Kriterium nicht relevant.
Export der 0 Eine Export-Funktion für alle in der Ver-
vorhandenen Schlüssel gangenheit zertifizierten Schlüssel exis-
tiert in Vault nicht.
Login mit AD-Zugang 0 Vault bietet keine Möglichkeit zur Anbin-
dung eines AD.
Import von Gruppen 0 Da es keine AD Anbindung gibt, können
aus dem AD auch keine Gruppen von dort importiert
werden.
Erfassung des Alters 0 Es gibt in Vault keine Auflistung zertifi-
von Schlüsseln zierter Schlüssel, somit ist auch nirgend-
wo ein Alter sichtbar.
28Sie können auch lesen
