Wenn du diese bewährten Verfahren befolgst, kannst du ein sicheres Benutzererlebnis schaffen.
Autorisierung, Authentifizierung und Zugriffssteuerung
Es wird empfohlen, eine GitHub App anstatt einer OAuth-App zu erstellen. GitHub Apps sind die offiziell empfohlene Möglichkeit zur Integration in GitHub, weil sie viel detailliertere Berechtigungen für den Zugriff auf Daten bieten.. Weitere Informationen findest du unter Unterschiede zwischen GitHub-Apps und OAuth-Apps.
- Apps sollten das Prinzip der geringsten Berechtigung anwenden und nur die OAuth-Bereiche und GitHub App-Berechtigungen anfordern, die die App benötigt, um ihre beabsichtigte Funktion auszuführen. Weitere Informationen findest du unter Prinzip der geringsten Rechte in Wikipedia.
- Apps sollten den Kunden eine Möglichkeit bieten, ihr Konto zu löschen, ohne dass sie eine E-Mail schreiben oder einen Support-Mitarbeiter kontaktieren müssen.
- Apps sollten keine Token zwischen verschiedenen Implementierungen der App freigeben. Zum Beispiel sollte eine Desktop-App ein anderes Token haben als eine webbasierte App. Mit individuellen Token kann jede App den Zugriff auf die GitHub-Ressourcen separat anfordern.
- Entwirf deine App mit unterschiedlichen Benutzerrollen, je nachdem, welche Funktionen der jeweilige Benutzertyp benötigt. Ein Standardbenutzer sollte z.B. keinen Zugriff auf die Verwaltungsfunktionen haben, und Abrechnungsmanager brauchen vielleicht keinen Push-Zugriff auf den Repository-Code.
- Apps sollten keine Dienstkonten wie E-Mail- oder Datenbankdienste freigeben, um deinen SaaS-Dienst zu verwalten.
- Alle Dienste, die in deiner App verwendet werden, sollten eindeutige Anmelde- und Kennwortanmeldeinformationen aufweisen.
- Der Zugriff auf die Produktionshosting-Infrastruktur mit Administratorrechten sollte nur Ingenieuren und Mitarbeitern mit administrativen Aufgaben gewährt werden.
- Ein personal access token sollte von Apps nicht zur Authentifizierung verwendet werden. Die Authentifizierung sollte als OAuth-App oder GitHub-App erfolgen:
- OAuth-Apps sollten sich mit einem OAuth-Token authentifizieren.
- GitHub Apps sollten sich mithilfe eines JSON-Webtokens (JWT), OAuth-Token oder Installationszugriffstoken authentifizieren.
Schutz von Daten
- Apps sollten Daten, die über das öffentliche Internet übertragen werden, mit HTTPS und einem gültigen TLS-Zertifikat oder SSH für Git verschlüsseln.
- Apps sollten Client-ID und Geheimschlüssel sicher speichern. Es wird empfohlen, sie als Umgebungsvariablen zu speichern.
- Apps sollten alle Benutzerdaten von GitHub innerhalb von 30 Tagen nach Erhalt einer Anfrage des Benutzers oder innerhalb von 30 Tagen nach Beendigung der Rechtsbeziehung des Benutzers mit GitHub löschen.
- Apps sollten nicht verlangen, dass der Benutzer sein GitHub-Passwort angibt.
- Apps sollten Token, Client-IDs und Clientschlüssel verschlüsseln.
Protokollierung und Überwachung
Apps sollten über Protokollierungs- und Überwachungsfunktionen verfügen. App-Protokolle sollten mindestens 30 Tage lang aufbewahrt und für mindestens ein Jahr archiviert werden. Ein Sicherheitsprotokoll sollte enthalten:
- Authentisierungs- und Autorisierungsereignisse
- Änderungen der Dienstkonfiguration
- Lesen und Schreiben von Objekten
- Alle Benutzer- und Gruppenberechtigungsänderungen
- Erhöhung der Rolle zum Administrator
- Konsistente Zeitstempelung für jedes Ereignis
- Quellbenutzer, IP-Adressen und/oder Hostnamen für alle protokollierten Aktionen
Workflow zur Reaktion auf Vorfälle
Um den Benutzern eine sichere Umgebung zu bieten, solltest du einen klaren Plan zur Reaktion auf Vorfälle haben, bevor du deine App veröffentlichst. Es empfiehlt sich, ein eigenes Sicherheitsteam in deinem Unternehmen einzurichten, anstatt einen Drittanbieter zu beauftragen. Du solltest die Möglichkeit haben, GitHub Enterprise Cloud innerhalb von 24 Stunden nach einem bestätigten Vorfall zu benachrichtigen.
Ein Beispiel für einen Workflow zur Reaktion auf einen Vorfall findest du auf der SANS Institute-Website unter „Datenverletzungsantwortrichtlinie“. Ein kurzes Dokument mit klaren Schritten für den Fall eines Vorfalls ist wertvoller als eine lange Richtlinienvorlage.
Verwaltung von Sicherheitsrisiken und Patching-Workflow
Du solltest regelmäßige Sicherheitsüberprüfungen der Produktionsinfrastruktur durchführen. Du solltest die Ergebnisse der Sicherheitsüberprüfungen bewerten und einen Zeitraum festlegen, innerhalb dessen du die Sicherheitsrisiken beheben willst.
Wenn du noch nicht bereit bist, ein komplettes Programm zum Sicherheitsrisikomanagement einzurichten, ist es sinnvoll, mit der Erstellung eines Patching-Prozesses zu beginnen. Anleitungen zum Erstellen einer Patchverwaltungsrichtlinie findest du in diesem TechRepublic-Artikel „Einrichten einer Patchverwaltungsrichtlinie.“