IT-Management Oktober 2021

Weitere Magazine

Empfehlungen

Info

28 | IT INFRASTRUKTUR Der Aufbau unserer Lab Umgebung ist dabei wie folgt: GitLab Container GitLab Runner Sonarqube Container Für unser Demo-Lab verwenden wir exemplarisch ein Sourcecode Management Tool sowie einen Sourcecode Scanner. Wir wählen in diesem Fall die Tools Git- Lab und SonarQube. GitLab ist in der Community Edition kostenfrei verfügbar und bringt von Haus aus nützliche Funktionalitäten wie zum Beispiel Continuous Integration (CI) ein. Auf diese Weise kann eine YAML-Datei im eigenen Projektordner abgelegt werden. SonarQube ist in der Community Edition ebenfalls ein frei verwendbares Tool und bietet eine große Diversität unterstützter Programmiersprachen. Out of Scope: - Application Hardening - Network Configuration (TLS) Out of Scope: - OS Hardening - Network Security System 6GB RAM 2 CPU Cores Ubuntu 18.04 LTS Docker Bild 2: Architekturdiagramm Docker CE Ubuntu 18.04 LTS Out of Scope: - Image Scanning - Image Hardening - Docker Configuration - Defense in Depth Der Scope Dieses Lab legt den Fokus sehr stark auf die automatisierte Überprüfung der Sicherheit von Sourcecode. Zur Vereinfachung werden folgende Themen nicht berücksichtigt (siehe auch Architektur-Diagramm): Gitlab Runner Starts SonarQube Scanner Push Results ➤ OS Hardening ➤ Network Hardening Feature Branch Merge Request Master Branch Merge No Security Vulnerabilities found? Yes SonarQube Server ➤ Container Security Push Code ➤ Application Security Report Back Das Deployment Für das Deployment der Artefakte des Labs wird Ansible verwendet. Hierzu wird ein Ansible Playbook erstellt, welches folgende Funktionen erfüllt: ➤ Updaten des Systems ➤ Entfernen der vorinstallierten Docker Version ➤ Installieren der Docker Community Edition ➤ Anlegen eines Docker Users ➤ Kopieren von Bash-Scripten auf das Zielsystem Developer Bild 3: Flussdiagramm ➤ Ändern der Berechtigung der Bash- Scripte Die Bash-Scripte erfüllen verschiedene Aufgaben im Zusammenspiel mit den Docker-Containern. Ein Script kopiert die aktuellsten Images, welche für das Lab benötigt werden, von Docker Hub: Dies sind zum einen GitLab, des Weiteren GitLab Runner sowie SonarQube Server. Ein vorheriges manuelles Herunterladen des SonarQube Scanners ist nicht erforderlich, da dies durch die CI-Funktionalität von GitLab automatisch durchgeführt wird. www.it-daily.net
IT INFRASTRUKTUR | 29 Die übrigen Scripte werden benötigt, um die Container auszuführen und einen persistenten Speicher innerhalb der Container zuzuweisen, sowie für die Dienste entsprechende Ports zu setzen und jeden Container eindeutig zu benennen. Zusätzlich wird ein weiteres Script ausgeliefert, welches den GitLab-Runner konfiguriert. Dazu muss zunächst innerhalb von GitLab ein Runner-Token erstellt werden, welches anschließend dem Script weitergegeben und somit der Runner Git- Lab zugewiesen wird. Die Besonderheit einer containerisierten GitLab Instanz ist die Portzuweisung. Am Anfang des Projektes traten häufiger Probleme mit git-Befehlen auf der Konsole auf, sofern GitLab nicht der Standard SSH Port 22 zugewiesen wurde. Daher entschließen wir uns, dem Host System einen alternativen SSH Port zuzuweisen und GitLab auf dem Standard SSH Port zu nutzen. Projekte, Projekte, Projekte Um ein Repository scannen zu können, muss zunächst ein SonarQube Projekt angelegt und ein Project Key vergeben werden. Anschließend wird ein Token generiert. Dies geschieht durch Vergabe eines Token Namens, zu dem SonarQube einen alphanumerischen String erzeugt. Als nächstes muss im Projektordner die Konfigurationsdatei sonar-project.properties angelegt werden. Diese enthält insbesondere die Parameter Project.Key und Project.Name. Ohne diese generiert SonarQube eine Fehlermeldung. Weiterhin muss zwingend die Quelle (das heißt der Pfad zum Sourcecode) spezifiziert werden. Zusätzlich können noch weitere Eigenschaften wie Kodierung und Programmiersprache konfiguriert werden, was jedoch in unserem Fall nicht erforderlich ist. Das Anlegen der Konfigurationsdatei sonar-project.properties ist ebenfalls nicht zwingend notwendig: Alternativ können die Werte Project.Key und Project.Name auch in GitLab selbst hinterlegt und anschließend in der .gitlab-ci.yml zugewiesen werden. Die .gitlab-ci.yml Das Herzstück der Automatisierung dieses kleinen Labs bildet die in YAML geschriebene Datei .gitlab-ci.yml. Für diesen Anwendungsfall ist die Komplexität minimal gehalten, alle Anweisungen werden vom GitLab-Runner ausgeführt. In diesem simplen Fall sucht der Git- Lab-Runner das Sonar-Scanner-Image auf Dockerhub, sofern es nicht bereits lokal vorliegt. Hier kommt das alphanumerische Token zum Einsatz, welcher an den Scanner übergeben wird. Zusätzlich muss die Host-Adresse von SonarQube angegeben werden, um nach dem Scan die Ergebnisse auf den Server zu pushen. Nachdem dies ausgeführt wurde, beendet sich der Container mit dem Sonar-Scanner wieder automatisch und wird erst dann erneut gestartet, wenn ein neuer Merge-Request auf den Master aufgeführt wird. Ausblick Wie oben erwähnt sind einige Security-Best-Practices, wie die Härtung von Betriebssystem und Netzwerk, hier nicht berücksichtigt. Auch dieser Ausblick fokussiert daher eher den horizontalen Ausbau rechts und links der im Architekturdiagramm skizzierten Lösung. Beginnen wir mit der Betrachtung des „Links“: Dem Sourcecode Management Tool vorgelagert sitzt im Normalfall der Editor oder die IDE des Entwicklers. Hier können verschiedene Plugins genutzt werden, um zum Beispiel implementierte Kryptographie zu identifizieren und festzustellen, ob die Schlüssellänge richtig gewählt ist. Somit können Sicherheitsmängel sofort behoben werden. Danach erfolgt ein Commit und gegebenenfalls der Merge-Request und ein automatischer SonarQube-Scan. Dem Lab nachgelagert (gedanklich rechts von unserer Lösung) sind andere Sicherheitsfeatures eingereiht, etwa ein eigenes Image Repository und ein Image Vulnerability Scanner. Somit kann sichergestellt werden, dass die Security-Abteilung diese Images vorab überprüfen kann, bevor Entwickler diese nutzen. Auch hier ist Kommunikation zwischen den Abteilungen sehr wichtig. Zu guter Letzt sollen weitere nicht-funktionale Tests noch Erwähnung finden: Ebenso wie funktionale- und End-to-End Tests können auch einige Security Tests automatisiert durch Scanner und andere Tools durchgeführt werden. Diese sind nicht nur hilfreich für die Entwickler, sondern auch für die Operatoren, da auch Konfigurationen mit in diese Tests einbezogen werden. Fazit Die Qualität von Sourcecode in Hinblick auf Security-Aspekte zu erhöhen, muss weder aufwändig noch kostenintensiv sein. So lässt sich die Integration eines Basissets von (Open Source) Security-Tools in die Entwicklungspipeline bereits mit einfachen Mitteln realisieren und liefert dabei einen klaren Mehrwert. Wie so oft führen viele Wege zum Ziel und jede Reise beginnt mit dem ersten Schritt. Jan Sudmeyer, Kevin Kloft www.it-daily.net
Seite 1 und 2: OKTOBER 2021 INKLUSIVE 48 SEITEN IT
Seite 3 und 4: EDITORIAL | 3 Immer gut informiert!
Seite 5 und 6: IT MANAGEMENT | 5 26 10 COVERSTORY
Seite 7 und 8: TRENDS | 7 AKTUELLE STUDIE DIGITALI
Seite 9 und 10: TRENDS | 9 RECHENZENTREN STATUS QUO
Seite 11 und 12: COVERSTORY - IT MANAGEMENT | 11 Ulr
Seite 13 und 14: MICROSOFT 365 & AZURE GERÄUSCHLOS
Seite 15 und 16: CHECKLISTE: IT MANAGEMENT | 15 gen
Seite 17 und 18: IT MANAGEMENT | 17 verlässigkeit i
Seite 19 und 20: von Workloads anstoßen, ihre IT-Um
Seite 21 und 22: IT MANAGEMENT | 21 wurde, waren seh
Seite 23 und 24: IT MANAGEMENT | 23 upgraden? Tatsä
Seite 25 und 26: IT MANAGEMENT | 25 (kurz: BaSys 4.0
Seite 27: IT INFRASTRUKTUR | 27 Auch wenn sic
Seite 31 und 32: eBUSINESS | 31 werden. Der Entwickl
Seite 33 und 34: eBUSINESS | 33 Die sechs Erfolgsfak
Seite 35 und 36: NEW WORKING WORLD Digitalevent | 11

IT-Management Oktober 2021

Erfolgreiche ePaper selbst erstellen

Template löschen?

Als Template speichern?