Home » News » Managed Security » Kommentar: SSH-Schlüssel in GitLab

Kommentar: SSH-Schlüssel in GitLab

HTTPS zeigt sich wenig nutzerfreundlich, wenn es darum geht, Git-Befehle an GitLab zu senden. SSH-Schlüssel könnten in GitLab eine gute Alternative für HTTPS und simple Passwortverfahren sein.

2 Min. Lesezeit
Zu sehen ist ein Server-Rack voller ordentlich angeordneter blauer Kabel. Der Text „SSH“ und ein Vorhängeschloss-Symbol sind deutlich zu sehen und verdeutlichen den hohen Sicherheitsaspekt des Secure Shell-Protokolls.
© AdobeStock/Funtap

HTTPS zeigt sich wenig nutzerfreundlich, wenn es darum geht, Git-Befehle an GitLab zu senden. SSH-Schlüssel könnten in GitLab eine gute Alternative für HTTPS und simple Passwortverfahren sein.

Um Daten verschlüsselt und authentifiziert – und damit sicher – über ein Netzwerk auf den Server einer Webseite zu übertragen, kommt meist HTTPS zum Einsatz. Im Falle des Transfers von Git-Daten auf GitLab kommt dieses Kommunikationsprotokoll zur Anwendung. Das Problem: Hier müssen Anwender für jede einzelne Aktion – für jede Übertragung vom lokalen Git- auf das GitLab-Repository – zunächst eine Nutzername- und eine Passortwort-Anfrage beantworten. Jedes Mal aufs Neue, für jede noch so kleine Änderung im lokalen Repository. Ein zeitraubender – vor allem aber eigentlich unnötiger – Arbeitsaufwand.

„GitLab-Nutzern steht eine wesentlich anwenderfreundlichere Option für ihre Datentransfers zur Verfügung: SSH-Schlüssel. Sicherer als HTTPS ist diese Variante auch. Denn Nutzername-Passwort-Kombinationen stellen heutzutage für Cyberkriminelle kein wirkliches Hindernis mehr dar. Social Engineering, Phishing- und Spear Phishing-Attacken wurden von ihnen in den vergangenen Jahren stark perfektioniert. Relativ leicht gelingt es ihnen nun, Mitarbeiter einer Opferinstitution zu manipulieren und so zur Herausgabe von Zugangsdaten zu bewegen. Haben sie diese dann erst einmal in der Hand, können sie sich unbehelligt – und unerkannt – Zugriff auf die Webseiten ihrer Opfer – auch auf GitLab – verschaffen.

Einen Ausweg bietet hier der Einsatz von SSH-Schlüsselpaaren – soweit man diese richtig einzusetzen weiß. Zwei Schlüsselformate stehen für GitLab zur Auswahl: RSA-SSH- und ED25519-SSH-Schlüssel. Der Vorteil: Im Gegensatz zur Nutzername-Passwort-Kombination kann ein SSH-Schlüsselpaar nicht einfach über eine Manipulierung der Mitarbeiter erbeutet werden. Cyberkriminelle haben es hier deutlich schwerer. Sie müssen sich schon direkten Zugriff auf das Opfersystem und die dort lagernden privaten SSH-Schlüssel verschaffen – und dies unbemerkt von der IT-Sicherheit ihres Angriffsziels. Ein weiterer Vorzug: Über ein systematisches Schlüsselmanagement können SSH-Schlüssel zusätzlich vor unerlaubten Fremdzugriffen abgesichert werden.

Über das Schlüsselmanagement werden alle vorhandenen Schlüssel lokalisiert, identifiziert und gemanagt. Hier hakt es bei vielen Unternehmen häufig noch. Sie unterschätzen, dass SSH-Schlüssel kontinuierlich überwacht werden müssen. Doch kann nur so sichergestellt werden, dass der einmal generierte und lokal abgespeicherte private Schlüssel niemals kopiert, verschoben oder mit einer Sicherungskopie versehen wird. All dies würde nur zu einer unnötigen Erhöhung der Sicherheitsrisiken führen.

Außerdem müssen alte Schlüsselpaare regelmäßig durch neue ersetzt werden. Auf GitLab-Administratorenseite können hierzu Ablaufrichtlinien eingerichtet werden, die sicherstellen, dass SSH-Schlüssel nur für einen bestimmten Zeitraum Gültigkeit besitzen. Ist das Ablaufdatum überschritten, wird der Anwender gezwungen, sie durch neue Schlüssel zu ersetzen. Hierzu sind mittlerweile auch automatische Managementlösungen erhältlich, welche die regelmäßige Erstellung und Löschung von SSH-Schlüsselpaaren ganz im Alleingang bewältigen. So kann dann auch die Nutzerfreundlichkeit von SSH-Schlüsseln noch einmal deutlich angehoben werden. Ausgestattet mit einem effektiven Schlüsselmanagement sind SSH-Schlüssel in GitLab die derzeit nutzerfreundlichste und sicherste Variante, Daten verschlüsselt, authentifiziert – und damit gesichert – zu übertragen.“

Christine Schönig ist Regional Director Security Engineering CER, Office of the CTO, bei Check Point Software Technologies.
Foto: Check Point Software

Christine Schönig, Regional Director Security Engineering CER, Office of the CTO, bei Check Point Software Technologies

Andere interessante News

Bedrohungslage Ransomware

Virtuelle Tarnkappe: Ransomware unter dem Radar

Eine virtuelle Maschine als Einfallstor, Social Engineering am Telefon und legitime Fernwartungstools: Die Cybercrime-Gruppe 3AM hat ihre Methoden weiterentwickelt. In der neuen An...

Ein goldenes geschütztes Datenschutz-Symbol

Schlag gegen Lumma-Infostealer – ein Nadelstich mit Wirkung?

Mit einer konzertierten Aktion haben Ermittler von Europol, FBI und Microsoft der Malware-as-a-Service-Plattform Lumma Stealer einen empfindlichen Schlag versetzt. Zwar bleibt ein ...

Gefälschte Zoll-SMS

Zolltricks und Tariftäuschung – Wie Online-Betrüger das Handelschaos für sich nutzen

Zolltarife sind längst nicht mehr nur ein Thema für Finanzabteilungen und Logistikexperten. In den Vereinigten Staaten entdecken Cyberkriminelle derzeit ein neues Einfallstor: das ...