Eine Alternative zum lokalen Betrieb eines Loadbalancers sind gemanagte Angebote in der Public Cloud. Diese decken bereits viele typische Anforderungen hinsichtlich Hochverfügbarkeit, Skalierbarkeit, aber auch Security ab. Solche Dienste bringen zwar häufig nicht den kompletten Funktionsumfang wie etwa F5 Big-IP oder Citrix Netscaler mit, bestechen aber durch ihre Einfachheit beim Aufsetzen und im Betrieb. In der Azure-Cloud bietet Microsoft als Layer-7-Loadbalancer das Azure Application Gateway an.
Loadbalancer sind ein zentraler Baustein für das Betreiben von Web-applikationen – sowohl für VM- als auch containerbasierte Anwendungen. Allerdings stellt deren klassische Ausprägung IT-Verantwortliche vor einige Herausforderungen, insbesondere was den Betrieb, aber auch das benötigte Know-how angeht. Soll die Anwendung beispielsweise Anforderungen hinsichtlich Hochverfügbarkeit und Skalierbarkeit erfüllen, müssen einige Voraussetzungen gegeben sein: Je nach Kritikalität sind mehrere Rechenzentren, aber auch Management- sowie Monitoringwerkzeuge erforderlich.
Für das Hosting von Webapplikationen kommt typischerweise ein Layer-7-Loadbalancer zum Einsatz, der auf HTTP-Ebene arbeitet. Diese Technologie unterliegt aber ebenso den eben geschilderten Herausforderungen. Doch in Azure will Microsoft dies mit dem Azure Application Gateway (AAG) vereinfachen – dazu gleich mehr. Um Verwechslungen auszuschließen, hier alle Lastverteiler in Azure:
– Azure Loadbalancer: ein Layer-4 Dienst, der auf TCP/UDP-Basis arbeitet.
Gesamten Artikel im IT-Administrator-Heftarchiv lesen
Wenn es um Sicherheit geht, ist es sehr sinnvoll, diese möglichst früh im Entwicklungsprozess einer Software zu verankern. DefectDojo ist ein Vulnerability-Management-Tool, das Entwicklerteams und Admins dabei hilft, Schwachstellen zu identifizieren, nachzuverfolgen und zu beheben. Unser Workshop stellt Grundlagen, Architektur und praktische Nutzung des freien Werkzeugs vor.
Schon seit Jahren ist DevOps bei den meisten Firmen in der Softwareentwicklung nicht mehr wegzudenken. Der Begriff steht für diverse Praktiken, Tools und eine Art Kulturphilosophie, die dabei helfen sollen, Prozesse zwischen der Entwicklungsabteilung und den IT-Teams zu automatisieren und zu verzahnen. Basierend auf den DevOps-Mechanismen hat sich in den letzten Jahren eine Weiterentwicklung herausgebildet: DevSecOps. Kurz gesagt handelt es sich dabei um DevOps plus Sicherheit. Etwas ausführlicher bedeutet dies, dass Sicherheit in jeder Phase des Software-Entwicklungsprozesses eine Rolle spielen sollte: vom ersten Design über Integration, Test und Bereitstellung bis hin zur Auslieferung.
Das Prinzip, dass die Bearbeitung von Aufgaben – in unserem Fall Security – möglichst zeitlich nach vorne in einer Prozesskette verlagert werden soll, heißt auch Shift-Left-Ansatz. Auf Container bezogen bedeutet dies, Sicherheitsaspekte schon beim Bau von Containern einzubeziehen. Das ergibt Sinn, denn Vorfälle in Produktivumgebungen lassen sich oft nur mit hohen Kosten beheben. Viel kostengünstiger ist es meist, wenn Fehler am Anfang des Entwicklungsprozesses gefunden werden. Im Umfeld von Shift-Left und DevSecOps haben sich in den letzten Jahren viele Tools auf dem Markt etabliert. Ein freies ist DefectDojo [1].
DefectDojo im Überblick
Ursprünglich wurde DefectDojo von Rackspace entwickelt, ist aber mittlerweile Open Source. An der Fortentwicklung der Software arbeitet die Community eifrig: Mittlerweile gibt es über 350 Contributers und das Produkt hat mehr als 2500 GitHub-Stars. Neue Features werden relativ häufig released – laut GitHub-Seite erfolgt etwa alle zwei Wochen eine Aktualisierung. Das Werkzeug integriert sich in eine große Reihe existierender Sicherheitstools – inklusive Security-Scanner, Issue-Tracker und Reporting-Werkzeuge – und zeigt deren Informationen in einer zentralen und leicht nachvollziehbaren Art und Weise an.
Gesamten Artikel im IT-Administrator-Heftarchiv lesen
Der Betrieb von cloudnativen Anwendungen in Containern oder mit Serverless-Technologien bringt spezielle und neue Anforderungen in Sachen Sicherheit mit sich. Zwar integrieren die großen Wolkenbereitsteller wie AWS oder Azure viel Security in ihre Plattformen, doch meist nur mit internen Diensten. Wie sich der Schutz von Workloads in Containern mit Aqua Security realisieren lässt, zeigt dieser Workshop.
Für viele Firmen ist das Betreiben von cloudnativen Applikationen mittlerweile Standard. Dabei beschreibt „cloudnative“ einen Ansatz der Softwareentwicklung, bei dem Applikationen von Anfang an für den Einsatz in der Cloud konzipiert werden. Derartige Anwendungen bestehen oft aus Microservices, die wiederum auf Basis von Containern oder Serverless-Technologien bereitgestellt sind. Neben der Eigenentwicklung von Applikationen kommt mittlerweile vermehrt auch Standardsoftware auf Basis solcher Technologien zur Auslieferung.
Neue Anforderungen an die Sicherheit
Solche Anwendungen benötigen einen neuen Ansatz in Sachen Security. Zwar bringen die großen Hyperscaler mittlerweile eine Reihe von Sicherheitsfunktionen mit, jedoch unterscheiden sich diese je nach Anbieter und sind zudem auf die eigene Plattform beschränkt. IT-Verantwortliche, die sich einen starken Rundumschutz wünschen, der sich zugleich über mehrere Cloudanbieter sowie lokale Systeme erstreckt, sind somit auf Drittanbietersoftware angewiesen.
Gesamten Artikel im IT-Administrator-Heftarchiv lesen
Virtual Private Clouds erlauben in der Google Cloud Platform das schnelle und einfache Anlegen selbst komplexer Netzwerkinfrastrukturen. Doch wie jeder IT-Verantwortliche bestätigen wird, bedeutet schnell nicht immer auch richtig – und das ist in der Cloud insbesondere in Sachen Security ein Problem. In diesem Vorabartikel aus dem neuen IT-Administrator Sonderheft „Cloud Security“ zeigen wir daher, welche Bordmittel für Sicherheit sorgen.
Mit Virtual Private Clouds (VPCs) haben Google und die anderen Hyperscaler das Netzwerkmanagement (in der Cloud) revolutioniert. Während es in der lokalen IT trotz Neuentwicklungen wie dem Software-defined Networking (SDN) immer noch einigermaßen umständlich ist, Netzwerke dynamisch anzulegen und zu verwalten, bieten die Cloudprovider eine API an, mit der sich Netzwerkkonstrukte wie VPCs im Handumdrehen erzeugen lassen.
Doch nicht selten liegt die Verwaltung von Cloudnetzwerken in der Hand von DevOps-Teams. Und nicht immer ist der Kenntnisstand dort so, dass alle Sicherheitsbelange gebührlich beachtet werden. Zudem ist das Feld der Netzwerksicherheit relativ groß und verlangt Know-how in Sachen Anlegen von VPCs und ihren Subnetzen, Routing, Firewalls und Flow-Log-Analyse oder Threat-Detection. Wir stellen daher im Folgenden diese zentralen Sicherheitstechniken in der Google Cloud Platform (GCP) dar.
Mehr Sicherheit mit Shared VPCs
Shared VPCs sind eine Weiterentwicklung der VPCs. Letztere können Admins auf einfache Art und Weise erstellen – mit allen denkbaren Fehlkonfigurationen. Der Ansatz von Shared VPCs ist, das Erstellen und Verwalten von VPCs an ein dediziertes Team zu delegieren. Dies entbindet Applikationsteams von der Bürde „Netzwerk-sicherheit“ und erlaubt ihnen, sich dediziert um ihre Anwendung zu kümmern.
Gesamten Artikel im IT-Administrator-Heftarchiv lesen
Das Arbeiten mit Containern gehört mittlerweile zu den Standardaufgaben von Administratoren. Neben dem reinen Betrieb der Container gilt es jedoch auch, sich um deren Sicherheit zu kümmern – eine Disziplin, die bei der relativ neuen Container-Technologie bisweilen vernachlässigt wird. Das Open-Source-Tool Trivy stellt Informationen zur Container- und Softwaresicherheit bereit.
Trivy [1] wird von der israelischen Firma Aqua Security als Open-Source-Tool bereitgestellt und scannt neben der Sicherheit von Container-Images auch Dateisysteme, Git Repositories und Kubernetes-Cluster und -Ressourcen. Zudem kann die Software OS-Packages und Software Dependencies (auch Software Bill of Material genannt), bekannte Sicherheitslücken (CVEs), Infrastructure-as-Code-Falschkonfigurationen sowie sensitive Information und Passwörter finden.
Installation
Die Installation von Trivy unterstützt alle gängigen Linux-Distributionen sowie macOS. Alternativ lässt sich Trivy als Container betreiben. Eine ausführliche Installationsanleitung finden Sie ebenfalls unter [1]. Bei der Installation unter Debian/ Ubuntu klappt das Aufsetzen des Scanners wie folgt:
sudo apt-get install wget apt-transport-https gnupg lsb-release
wget -qO -https://aquasecurity.github.io/trivy-repo/deb/public.key | sudo apt-key add –
echo deb https://aquasecurity.github.io/trivy-repo/deb $(lsb_release -sc) main | sudo tee -a /etc/apt/sources.list.d/trivy.list
sudo apt-get update
sudo apt-get install trivy
Einführung in Securityscans
Sobald die Installation abgeschlossen ist, können Sie mit dem Scannen beginnen. Wir zeigen dies am Beispiel des bekannten nginx-Images. Zuerst laden wir dabei das Image herunter…
Gesamten Artikel im IT-Administrator-Heftarchiv lesen
Jede Anwendung, auf die mehr als ein Nutzer zugreift, muss die entscheidende Frage beantworten: Darf dieser Benutzer die gewünschte Aktion wirklich ausführen? Was ein Anwender in einer Software darf, legt meist ein Rollenmodell fest. Doch insbesondere in der Cloud oder für Infrastructure-as-Code birgt dies zahlreiche Herausforderungen. Mit dem freien Open Policy Agent steuern Admins Nutzerrechte flexibler.
Infrastructure-as-Code (IaC) ist mittlerweile ein Erfolgsrezept für deklarativen, maschinenlesbaren Code und daher liegt es nahe, es auf das Thema Security und insbesondere auf das Verfassen von Policies zu übertragen. Mit diesem Ansatz versuchen Firmen in einer skalierbaren Art und Weise, Regeln innerhalb einer Organisation zu implementieren. Ein Vertreter dieser Gattung, der in jüngster Zeit immer mehr Aufmerksamkeit erhält, ist der Projekt Open Policy Agent (OPA) [1], hinter dem das Startup-Unternehmen Styra steht. OPA ist eine universell einsetzbare Policy-Engine, die eine einheitliche, kontextbewusste Durchsetzung von Richtlinien über den gesamten Stack hinweg ermöglicht.
Open Policy Agent im Überblick
OPA wird von der CNCF (Cloud Native Computing Foundation) gehostet – also von der Organisation, die für Kubernetes verantwortlich zeichnet. Konzipiert ist OPA für cloudnative Umgebungen und kombiniert die relativ einfach zu erlernende und lesbare Policy-Sprache „Rego“ mit einem Richtlinienmodel sowie einer API. Dies ermöglicht eine Art universelles Framework, um Regeln auf alle Arten von Stacks anzuwenden. Einer der großen Vorteile von OPA ist somit die Entkopplung von Security-Policies und Code und seiner Anwendung – unabhängig, wie oft sich der Code ändert.
Technisch ist OPA an Input gebunden. Sobald diese Daten vorliegen, entscheidet der OPA-Code darüber, wie mit dem entsprechenden Input umzugehen ist (beispielsweise das Erlauben oder Verbieten mit einer allow/deny-Policy). Ein weiterer Vorteil ist die Tatsache, dass OPA Input und Output sowohl im JSON- als auch im YAML-Format verarbeitet, sodass sich IT-Verantwortliche dabei nicht an eine vordefinierte API halten müssen. Insgesamt gestaltet sich das Verfassen von Regeln so relativ leicht – darüber hinaus unterstützt OPA REPL, also das Shell-basierte Ausführen von Code. Praktisch ist auch, dass Sie nicht alle Policies selbst verfassen müssen, denn im Internet finden sich für viele Anwendungsfälle bereits fertige Policy-Bundles, die ein brauchbares, vordefiniertes Regelwerk beinhalten. Zum Üben existiert sowohl ein frei zugänglicher Playground als auch eine freie Styra Academy.
Gesamten Artikel im IT-Administrator-Heftarchiv lesen
Beim Betrieb von Infrastruktur und Anwendungen ist Monitoring für einen Einblick in den Zustand der jeweiligen Komponenten unabkömmlich. Dies gilt nicht nur für lokale Umgebungen, sondern auch für die Public Cloud. Der folgende Artikel gibt eine Einführung in die Überwachung der Google Cloud Platform. Dabei gehen wir unter anderem auf das Monitoring von virtuellen Maschinen, das Einrichten von Warnungen, die Nutzung von Dashboards und das Setzen von Service Level Objectives ein.
Google ist mit seiner Google Cloud Platform (GCP) neben AWS und Microsoft Azure einer der drei großen Public-Cloud-Anbieter. In den letzten Jahren konnte Google gerade bei den Themen Maschinelles Lernen und Big Data ein beträchtliches Wachstum verzeichnen. Aber auch im klassischen IaaS-Bereich braucht sich GCP vor seinen Mitbewerbern nicht zu verstecken. Um eine Cloudinfrastruktur richtig betreiben zu können, spielt Monitoring eine zentrale Rolle. Bei Google hieß die Cloud Operations Suite, die die Themen Monitoring, Logging, Tracing, Debugging, Profiling und Auditing adressiert, bis vor zwei Jahren Stackdriver. Mittlerweile verwendet Google diesen Namen nicht mehr, sondern spricht einfach nur von der Operations Suite.
Um im laufenden Betrieb ein funktionierendes Monitoring zu gewährleisten, ist es notwendig, entsprechend Daten aus den Quellsystemen in Form von Signalen zu empfangen. Beim Monitoring sind dies entsprechend Metriken. Diese können von IaaS-Komponenten wie virtuellen Maschinen, von höherwertigen Services wie gemanagten Datenbanken, von Plattformen wie Kubernetes, von Microservices, aber auch von Applikationen selbst ausgehen. Zusätzlich ist es notwendig, Incidents im Auge zu behalten, egal ob in Form von Alerts, Fehlerberichten oder auch Service Level Objectives. Mit der Operations Suite lassen sich all diese Daten zusammenführen, genauer betrachten, visualisieren und zur Fehlersuche benutzen.
Der Zugriff auf Monitoringdaten kann bei GCP sowohl zentral als dezentral erfolgen. In der Google-Cloud sind alle Ressourcen Projekten zugeordnet. In der Operations Suite kann jedes Projekt für sich die Daten allein sammeln und auswerten. Wollen Sie jedoch über die ganze Organisation hinweg den Überblick über alle Systeme behalten, dann sollten Sie mehrere Projekte zu einem Monitoring Workspace hinzufügen.
Gesamten Artikel im IT-Administrator-Heftarchiv lesen
