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

Newsletter Abonnieren

Abonnieren Sie jetzt IT-SICHERHEIT News und erhalten Sie alle 14 Tage aktuelle News, Fachbeiträge, exklusive Einladungen zu kostenlosen Webinaren und hilfreiche Downloads.

Andere interessante News

NIS2 auf Schild im EU-Design

VATM fordert Nachbesserungen beim NIS2-Gesetz

In der Bundestagsanhörung zum NIS2-Umsetzungsgesetz warnt der Telekommunikationsverband VATM vor einem überbordenden Bürokratieapparat. Statt paralleler Strukturen in Bund und Länd...

Mehrere Cloud-Strukturen nebeneinander

Warum Multi-Vendor-Strategien die Zukunft sind

Der europäische Data Act zwingt Cloud-Anbieter, den Wechsel zwischen Plattformen zu erleichtern. Für Unternehmen und Managed Service Provider ist das eine historische Chance: Wer s...

Cybersecurity im Bildungswesen/in der Schule

KI im Klassenzimmer: 41 Prozent der Schulen melden bereits Cybervorfälle

Eine neue Studie zeigt: Der Einsatz von künstlicher Intelligenz in Schulen wächst rasant – doch die Cybersicherheit hält nicht Schritt. Bereits 41 Prozent der befragten Bildungsein...