Bewährte Methoden zum Schützen von Konten

Über diesen Leitfaden

In diesem Leitfaden werden die Änderungen mit den größten Auswirkungen beschrieben, die du zum Erhöhen der Kontosicherheit vornehmen kannst. In den einzelnen Abschnitten wird jeweils eine Änderung beschrieben, die du zur Verbesserung der Sicherheit an deinen Prozessen vornehmen kannst. Die Änderungen mit den größten Auswirkungen sind zuerst aufgeführt.

Welches Risiko besteht?

Kontosicherheit ist grundlegend für die Sicherheit deiner Lieferkette. Wenn es Angreiferinnen gelingt, dein Konto auf GitHub Enterprise Server zu übernehmen, können sie böswillige Änderungen an deinem Code oder Buildprozess vornehmen. Dein oberstes Ziel muss daher sein, die Übernahme deines Kontos und der Konten anderer Benutzerinnen in deine GitHub Enterprise Server-Instanz zu erschweren.

Authentifizierung zentralisieren

Wenn du derdie Siteadministratorin für deine GitHub Enterprise Server-Instanz bist, kannst du den Anmeldevorgang für Benutzer vereinfachen, indem du eine Authentifizierungsmethode wählst, bei der eine Verbindung mit einem bestehenden Identitätsanbieter (IdP) wie CAS, SAML oder LDAP hergestellt wird. Das bedeutet, dass sich Benutzer*innen kein zusätzliches Kennwort für GitHub merken müssen.

Bei einigen Authentifizierungsmethoden wird auch die Übermittlung zusätzlicher Informationen an GitHub Enterprise Server, z. B. bei welchen Gruppen der Benutzer Mitglied ist, oder die Synchronisierung von kryptografischen Schlüsseln für den Benutzer unterstützt. Das ist eine gute Möglichkeit, die Verwaltung bei wachsenden Organisationen zu vereinfachen.

Weitere Informationen zu Authentifizierungsmethoden für GitHub Enterprise Server findest du unter Informationen zur Authentifizierung für dein Unternehmen.

Konfigurieren der zweistufigen Authentifizierung

Die beste Möglichkeit, die Sicherheit deines persönlichen Kontos oder deine GitHub Enterprise Server-Instanz zu verbessern, ist die Konfiguration der Zwei-Faktor-Authentifizierung. Kennwörter selbst können kompromittiert werden, wenn sie erraten werden können, auf einer kompromittierten Website wiederverwendet oder durch Social Engineering wie Phishing kompromittiert werden. Mit der zweistufigen Authentifizierung wird die Kompromittierung eines Kontos deutlich erschwert, selbst wenn der Angreifer über das entsprechende Kennwort verfügt.

Um sowohl die Sicherheit als auch den zuverlässigen Zugriff auf dein Konto zu gewährleisten, solltest du immer mindestens zwei Anmeldeinformationen mit Zwei-Faktor-Authentifizierung in deinem Konto registriert haben. Zusätzliche Anmeldeinformationen stellen sicher, dass du nicht aus deinem Konto gesperrt wirst, auch wenn du den Zugriff auf eine Anmeldeinformation verlierst.

Wenn du derdie Siteadministratorin für deine GitHub Enterprise Server-Instanz bist, kannst du möglicherweise die Zwei-Faktor-Authentifizierung für alle Benutzer deiner Instanz konfigurieren. Ob die zweistufige Authentifizierung für GitHub Enterprise Server verfügbar ist, hängt von der verwendeten Authentifizierungsmethode ab. Weitere Informationen findest du unter Zentralisieren der Benutzerauthentifizierung.

Wenn du Organisationsbesitzer bist, kannst du möglicherweise festlegen, dass alle Mitglieder der Organisation die zweistufige Authentifizierung aktivieren.

Weitere Informationen zum Aktivieren von 2FA in deinem eigenen Konto findest du unter Zwei-Faktor-Authentifizierung konfigurieren. Weitere Informationen zur Anforderung von 2FA in deiner Organisation findest du unter Erfordern der zweistufigen Authentifizierung in deiner Organisation.

Konfigurieren deines Unternehmenskontos

Unternehmensbesitzer können möglicherweise festlegen, dass alle Benutzerinnen der Instanz die zweistufige Authentifizierung verwenden. Ob Richtlinien für die zweistufige Authentifizierung für GitHub Enterprise Server verfügbar sind, hängt davon ab, wie sich Benutzerinnen für den Zugriff auf deine Instanz authentifizieren.

• Wenn du dich bei deine GitHub Enterprise Server-Instanz über einen externen Identitätsanbieter mithilfe von CAS oder SAML SSO anmeldest, kannst du die Zwei-Faktor-Authentifizierung für GitHub Enterprise Server nicht konfigurieren. Die zweistufige Authentifizierung für den Identitätsanbieter muss von einem Benutzer mit Administratorzugriff konfiguriert werden.

• Wenn du dich bei deine GitHub Enterprise Server-Instanz über ein externes LDAP-Verzeichnis anmeldest, kannst du für dein Unternehmen festlegen, dass die Zwei-Faktor-Authentifizierung für GitHub Enterprise Server verwendet werden muss. Wenn du die integrierte Authentifizierung für Benutzerinnen außerhalb deines Verzeichnisses zulässt, können einzelne Benutzerinnen die zweistufige Authentifizierung aktivieren. Es ist jedoch nicht möglich, festzulegen, dass für dein Unternehmen die zweistufige Authentifizierung verwendet werden muss.

Weitere Informationen findest du unter Erzwingen von Richtlinien für Sicherheitseinstellungen in deinem Unternehmen.

Konfigurieren eines persönlichen Kontos

GitHub Enterprise Server unterstützt mehrere Optionen für die zweistufige Authentifizierung, und obwohl jede davon besser ist als nichts, ist WebAuthn doch die sicherste Option. Für WebAuthn wird entweder ein Hardwaresicherheitsschlüssel oder ein Gerät benötigt, das über Windows Hello oder Mac TouchID entsprechende Unterstützung bietet. Phishing ist bei anderen Formen der zweistufigen Authentifizierung zwar schwierig, aber möglich (wenn du beispielsweise gebeten wirst, dein sechsstelliges Einmalkennwort vorzulesen). Bei WebAuthn ist Phishing dagegen nicht möglich, da im Protokoll eine Domänendefinition integriert ist, mit der verhindert wird, dass Anmeldeinformationen von einer Website, die eine Anmeldeseite imitiert, für GitHub Enterprise Server verwendet werden.

Beim Einrichten der zweistufigen Authentifizierung solltest du die Wiederherstellungscodes immer herunterladen und mehr als eine Stufe einrichten. Dadurch wird sichergestellt, dass der Zugriff auf dein Konto nicht von einem einzelnen Gerät abhängt. Weitere Informationen findest du unter Zwei-Faktor-Authentifizierung konfigurieren und unter Wiederherstellungsmethoden bei der Zwei-Faktor-Authentifizierung konfigurieren.

Konfigurieren eines Organisationskontos

Als Organisationsinhaberin kannst du erkennen, für welche Benutzerinnen die zweistufige Authentifizierung nicht aktiviert ist. Du kannst ihnen beim Einrichten der zweistufigen Authentifizierung behilflich sein und anschließend festlegen, dass für deine Organisation die zweistufige Authentifizierung verwendet werden muss. Informationen zu dieser Vorgehensweise findest du unter:

1. Überprüfen, ob die 2FA für die Benutzer*innen deiner Organisation aktiviert ist
2. Vorbereiten auf die Voraussetzung der zweistufigen Authentifizierung in deiner Organisation
3. Erfordern der zweistufigen Authentifizierung in deiner Organisation

Herstellen einer Verbindung mit GitHub Enterprise Server mithilfe von SSH-Schlüsseln

Außer der Anmeldung bei der Website gibt es auch andere Möglichkeiten, mit GitHub Enterprise Server zu interagieren. Viele autorisieren den Code, den sie an GitHub pushen, mit einem privaten SSH-Schlüssel. Weitere Informationen findest du unter Informationen zur SSH.

Ebenso wie bei deinem Kontokennwort können Angreifer*innen deine Identität annehmen und böswilligen Code an alle Repositorys pushen, für die du Schreibzugriff hast, falls sie an deinen privaten SSH-Schlüssel gelangen. Wenn du deinen privaten SSH-Schlüssel in einem Datenträgerlaufwerk speicherst, solltest du ihn mit einer Passphrase zu schützen. Weitere Informationen findest du unter SSH-Schlüssel-Passphrasen verwenden.

Eine weitere Option besteht darin, SSH-Schlüssel mit einem Hardwaresicherheitsschlüssel zu generieren. Dabei kann derselbe Schlüssel wie für die zweistufige Authentifizierung verwendet werden. Die Kompromittierung von Hardwaresicherheitsschlüsseln per Fernzugriff ist schwierig, da der private SSH-Schlüssel auf der Hardware verbleibt und über die Software nicht direkt zugänglich ist Weitere Informationen findest du unter Generieren eines neuen SSH-Schlüssels und Hinzufügen des Schlüssels zum ssh-agent.

Hardwaregestützte SSH-Schlüssel sind recht sicher, aber die Hardwareanforderung ist für einige Organisationen möglicherweise nicht geeignet. Ein alternativer Ansatz besteht darin, SSH-Schlüssel zu verwenden, die nur für einen kurzen Zeitraum gültig sind. Auch wenn der private Schlüssel kompromittiert wird, kann er nicht lange genutzt werden. Auf diesem Konzept beruht die Unterhaltung einer eigenen SSH-Zertifizierungsstelle. Bei diesem Ansatz kannst du weitgehend festlegen, wie sich Benutzer*innen authentifizieren, jedoch bist du dafür verantwortlich, selbst eine SSH-Zertifizierungsstelle zu unterhalten. Weitere Informationen findest du unter Informationen zu SSH-Zertifizierungsstellen.

Nächste Schritte

• Sichern einer End-to-End-Lieferkette

• Bewährte Methoden zum Sichern von Code in einer Lieferkette

• Bewährte Methoden zum Schützen deines Buildsystems