I​ - CLOUD COMPUTING SECURITY

Question 1

I.3 Was bedeutet Infrastructure as Code und worin liegen die Vorteile?

Answer 1

Infrastructure as Code (IaC) ist die Verwaltung und Bereitstellung von Infrastruktur durch Code statt durch manuelle Prozesse. Mit IaC werden Konfigurationsdateien erstellt, die die Infrastrukturspezifikationen enthalten, was die Bearbeitung und Verteilung von Konfigurationen erleichtert. Außerdem wird so sichergestellt, dass jedes Mal dieselbe Umgebung bereitgestellt wird. Durch die Kodifizierung und Dokumentation der Konfigurationsspezifikationen unterstützt IaC das Konfigurationsmanagement und hilft dabei, undokumentierte Ad-hoc-Konfigurationsänderungen zu vermeiden.

Durch Cloud Computing ist die Anzahl an Komponenten in der Infrastruktur immens gestiegen und ohne IaC ist es äußerst schwierig dies zu managen.

Vorteile sind:
- Kostenreduzierung
- Kürzere Deploymentzeiten
- Fehlervermeidung
- Höhere Konsistenz der Infrastruktur
- weniger Konfigurationsfehler
- Keine Provisionierung von Entwicklern vor dem Deployment notwendig

Z.b
1. Terraform
• Beispiel: Bereitstellung einer EC2-Instanz auf AWS

2. AWS CloudFormation
   • Beispiel: Erstellen eines S3-Buckets
3. Ansible (für Konfigurationsmanagement)
   • Beispiel: Installieren von Apache auf einem Server

Ein konkretes Beispiel für Infrastructure as Code ist die Verwendung von Terraform, um auf AWS eine virtuelle Maschine bereitzustellen. Dabei schreibe ich ein Terraform-Skript, das z. B. eine EC2-Instanz mit einem bestimmten Betriebssystem, einer Sicherheitsgruppe und einem SSH-Zugriff definiert. Das Skript kann versioniert, automatisiert ausgeführt und jederzeit reproduzierbar aufgesetzt werden – ganz ohne manuelles Klicken in der AWS-Konsole.”

Question 2

I.4 Erläutern Sie was hinter dem Begriff DevOps steht anhand eines Beispieles und wie sich Security in dieses Konzept miteinfügt.

Answer 2

DevOps ist ein Ansatz, bei dem die Bereiche Softwareentwicklung (Development) und IT-Betrieb (Operations) enger zusammenarbeiten. Ziel ist es, Software schneller, zuverlässiger und kontinuierlich bereitzustellen.

Ein klassisches Beispiel: Früher haben Entwickler ihren Code geschrieben, und irgendwann hat das Operations-Team ihn in Produktion gebracht. Dabei kam es oft zu Problemen – z. B. weil die Infrastruktur nicht passte oder der Code Fehler hatte. Mit DevOps arbeiten beide Teams von Anfang an gemeinsam – das spart Zeit und verhindert viele Missverständnisse.

Ein wichtiges Prinzip ist: „You build it, you run it.“ Das heißt, das Team, das etwas entwickelt, ist auch für den Betrieb verantwortlich. Dadurch steigt die Qualität und Verantwortung.

DevOps funktioniert typischerweise in einem Zyklus, der sich ständig wiederholt:
Plan → Build → Test → Deploy → Operate → Monitor → Feedback → und zurück zum Plan.

Dabei kommen moderne Tools zum Einsatz, zum Beispiel: Docker, Kubernetes (z. B. AKS oder GKE), AWS oder OpenShift – je nach Infrastruktur.

Und wie passt Security hier rein?

Security darf nicht erst am Ende bedacht werden, sondern muss von Anfang an mitgedacht werden – in jedem Schritt des DevOps-Zyklus. Das nennt man auch „DevSecOps“.

Das heißt zum Beispiel:
• Quellcode wird regelmäßig geprüft (Code Reviews)
• Automatische Sicherheits-Scanner werden eingesetzt – sowohl statisch (ohne Ausführung) als auch dynamisch (während der Laufzeit)
• Es werden nur vertrauenswürdige Bibliotheken und Images verwendet
• Microservices sind voneinander isoliert, damit Angriffe sich nicht ausbreiten können
• Daten und Geheimnisse werden verschlüsselt gespeichert – z. B. mit einem zentralen Key Management
• Es gibt ein zentrales Identity- und Access-Management
• Und es wird aktiv über mögliche Bedrohungen nachgedacht (Threat Modeling)

All das sorgt dafür, dass Sicherheit kein Bremsklotz, sondern ein fester Bestandteil im Entwicklungsprozess ist.

//////
Ein Ansatz zur Software Entwicklung und Systemadministration
- Setzt sich zusammen aus Development und Operations
- Kommt aus der “Agilen Softwaredevelopment”

Beispiel: Continuous Integration und Continuous Deployment (CI/CD) Pipeline

Angenommen, ein Softwareentwicklungsteam arbeitet an einer Webanwendung. Traditionell könnten die Entwickler die Anwendung entwickeln und an die IT-Operations-Teams übergeben, um sie in der Produktionsumgebung bereitzustellen. Dieser Prozess kann zeitaufwändig sein und zu Verzögerungen führen. Mit DevOps wird dieser Prozess umgestaltet:

1. Continuous Integration (CI): Die Entwickler schreiben kontinuierlich Code und fügen ihn in eine gemeinsame Code-Repository ein. Eine automatisierte CI-Pipeline führt Tests und Qualitätsprüfungen auf diesem Code aus, um sicherzustellen, dass er fehlerfrei ist.
2. Continuous Deployment (CD): Wenn der Code den CI-Tests besteht, wird er automatisch in die Produktionsumgebung bereitgestellt. Dies geschieht in einer CD-Pipeline. Die Bereitstellung erfolgt häufig in kleinen, inkrementellen Schritten, um das Risiko zu minimieren.
3. Monitoring und Feedback: In der Produktionsumgebung wird die Anwendung kontinuierlich überwacht. Alle Probleme oder Fehler werden erfasst und an das Entwicklungsteam zurückgemeldet. Das Feedback aus der Produktion wird verwendet, um die Anwendung ständig zu verbessern.

Integration von Sicherheit in DevOps:

1. Security as Code: Sicherheitsrichtlinien und -maßnahmen werden als Code definiert und in den CI/CD-Prozess integriert. Dies ermöglicht die automatische Überprüfung der Sicherheit bei jedem Schritt der Bereitstellung.
2. Automatisierte Sicherheitstests: Sicherheitstests, wie Schwachstellen-Scans und Penetrationstests, werden in den CI/CD-Pipeline integriert, um Schwachstellen frühzeitig zu erkennen und zu beheben.
3. Sicherheitsüberwachung: Kontinuierliche Überwachung der Anwendung in der Produktionsumgebung, um Sicherheitsvorfälle frühzeitig zu erkennen. Dies kann die Überwachung von Angriffsversuchen und verdächtigem Verhalten umfassen.

Question 3

I.1​ Erklären Sie die essenziellen Charakteristika, Deployment Models und Service Models von Cloud Computing.

Answer 3

Basis: Virtualisierung und Containerisierung

Nach der CSA (Cloud Security Alliance) ist die SOA (Service orientated Architecture) essenziell; Services werden normalerweise über eine Rest-API (stateless, cacheable, uniform Interface) zur Verfügung gestellt.

Cloud muss: Multi-Client-fähig und Flat-Rates

Nach NIST 2011 hat Cloud-Konzept 5 Charakteristika, 4 Deployment- & 3 Service Modelle.

Charakteristika
• On-demand Self-Service: User können Ressourcen (z.B. Diskspace) nach Bedarf erwerben.
• Broad Network Access: Ressourcen sind über das Netzwerk zugänglich und können daher durch verschiedene Plattformen genutzt werden.
• Resource Pooling: User kann auf Ressourcenpool zugreifen, die aber nicht hardware-spezifisch sind.​
• Rapid Elasticity: Ressourcen können flexibel skaliert werden.​
• Measured Service: Pay what you get.​

Deployment Modelle​
• Private Cloud: Cloud für exklusiven Gebrauch einer Organisation
• Public Cloud: Öffentlich erreichbar, von Provider gehosted​
• Hybrid Cloud: Mischform aus private und public, z.B. sensible Daten in der private, Rest in​ der public Cloud​
• Community Cloud: Gemeinschaftlich genutzt, oft Unis, z.B. OpenCloudMesh​

Service Modelle​
• Infrastructure as a Service (IaaS): Grundlegendste Form, liefert “Hardware”-Ressourcen, z.B. AWS EC2, Azure Compute​
• Platform as a Service (PaaS): “Solution Stack”, liefert Plattform, um eigene Anwendungen zu entwickeln, z.B. Google App Engine, Azure App Service, AWS Elastic Beanstack​
• Software as a Service (SaaS): Liefert Software, meist Business-Applikationen, z.B. Microsoft Office 365, Amazon WorkMail, Salesforce

/////

1. On-Demand Self-Service

➡️ Was heißt das?
Man kann IT-Ressourcen wie Server oder Speicherplatz selbst und sofort buchen, ohne auf jemanden warten zu müssen.

➡️ Beispiel:
Ich melde mich bei AWS an und starte eine virtuelle Maschine direkt über die Web-Oberfläche – dauert nur wenige Minuten.

⸻

2. Broad Network Access

➡️ Was heißt das?
Cloud-Dienste sind über das Internet verfügbar – auf PCs, Handys, Tablets, überall.

➡️ Beispiel:
Ich greife über mein Smartphone auf Google Drive zu und bearbeite ein Dokument, das im Büro erstellt wurde.

⸻

3. Resource Pooling

➡️ Was heißt das?
Die Cloud-Anbieter stellen Ressourcen wie Server oder Speicher in einem gemeinsamen Pool bereit – die Nutzer teilen sich die Hardware, aber bekommen logisch getrennte Ressourcen.

➡️ Beispiel:
Wenn ich bei Microsoft Azure einen Dienst buche, weiß ich nicht, auf welchem Server er läuft – das spielt auch keine Rolle.

⸻

4. Rapid Elasticity

➡️ Was heißt das?
Die Cloud passt sich flexibel an: Mehr oder weniger Ressourcen – je nach Bedarf – und das automatisch.

➡️ Beispiel:
Ein Online-Shop hat an Black Friday plötzlich mehr Besucher. Die Cloud skaliert automatisch hoch, um alles zu bewältigen, und danach wieder runter.

⸻

5. Measured Service

➡️ Was heißt das?
Man bezahlt nur das, was man wirklich nutzt – alles wird genau gemessen.

➡️ Beispiel:
Bei Google Cloud wird mir genau angezeigt, wie viel Speicherplatz ich genutzt habe – und nur das wird abgerechnet

Question 4

I.2​AWS/Azure Security - Was versteht man unter Shared Security Model in den unterschiedlichen Ausprägungen (Infrastructure Services, Container Services, Abstracted Services, …)?

Answer 4

Shared Security Model beschreibt die Aufteilung der Sicherheitsverantwortung zwischen Cloud-Diensteanbieter und Kunden. Je nach Servicemodel kann die Responsibility variieren.

Infrastructure as a Service: Anbieter ist für Infrastruktur verantwortlich (Rechen-zentren, Netzwerke, Hardware – physische Sicherheit, Virtualisierungsschicht).
Kunde ist verantwortlich für das Betriebssystem, die Middleware, die Anwendungen und die Daten. Kunde muss Anwendungen patchen und für Zugriffskontrolle sorgen.

Container Services: Anbieter ist für Infrastruktur und Container-Orchestrierungs-Plattformen (z.B. Kubernetes) verantwortlich. Kunde verantwortet Container-Images, Configs und darin laufende Anwendungen.

Abstracted Services: Anbieter übernimmt Großteil der Verantwortung, Kunde kümmert sich „nur“ um sichere Nutzung der Dienste (Verwaltung der Benutzerkonten, Zugriffsrechte und Sicherheit der
eigenen Daten).

Platform as a Service (PaaS):
- Cloud-Anbieter: Der Anbieter ist verantwortlich für die Sicherheit der Plattform, auf der die Anwendungen laufen. Dies kann die Sicherheit der Laufzeitumgebung, der Datenbanken und der Netzwerke umfassen.
- Kunde: Der Kunde ist verantwortlich für die Sicherheit seiner Anwendungen und der darin gespeicherten Daten. Dies umfasst die Konfiguration und Absicherung der Anwendungen selbst.

Question 5

I.5​ AWS – Virtual Private Cloud – Erklären sie die Core Concepts dahinter mit den jeweiligen Security-Maßnahmen, die eingesetzt werden können.

Answer 5

VPC kann einen isolierten Teil der AW Cloud erstellen, innerhalb dessen die AWS-Ressourcen in einem virtuellen Netzwerk betrieben werden können.
Core-Konzepte: Subnetze, Security Groups, NACL, Routing in VPC, Private Connectivity Capabilities, VPN Connections

a. Subnetting: Netzwerksegmentierung
Zuerst wird durch die Zuweisung eines CIDR-Blocks (Classless Inter-Domain Routing) ein IP-Adressbereich für die ganze VPC erstellt (Bildung der Subnetze innerhalb)

b. Security Groups: Virtuelle Firewalls, die die Kontrolle des ein- und ausgehenden Datenverkehrs zu den Amazon EC2-Instanzen regeln. Security Groups sind stateful und arbeiten auf der Instanzebene, nicht auf der Subnetzebene.
Outbound-Verkehr ist standardmäßig erlaubt, Inbound nur mit bestimmten Regeln.
Security Groups haben nur erlaubende Regeln.

c. NACL: Network Access Control List.
Sicherheitsmechanismus auf Netzwerkebene, um Datenverkehr von und zu Subnetzen zu steuern. NACLs sind stateless, die Pakete müssen nach definierten Regeln überprüft werden. Es gibt erlaubende und verweigernde Regeln (=flexiblere Verkehrskontrolle).

d. Routing in VPC: Jedes Subnetz in einer VPC ist mit einer Routentabelle verknüpft, die bestimmt, wohin der Netzwerkverkehr von und zu den Instanzen im Subnetz geleitet wird. Man kann unterschiedliche Routentabellen für verschiedene Subnetze erstellen, um den Datenverkehr entsprechend den Sicherheits- und Netzwerkanforderungen zu steuern.

e. Private Connectivity Capabilities: Möglichkeit, private Verbindungen zwischen VPC und anderen Netzwerkdiensten herzustellen.
Kernaspekte = VPC Peering (Netzwerkverbindung zwischen zwei VPCs), Direct Connect (private Verbindung von eigenem Büro/Rechenzentrum zur VPC), Endpoint Services (Zugriff auf private Cloud-Dienste ohne Datenverkehr über Internet)

f. VPN-Connections: Tunneling, Verschlüsselung, Authentifizierung

Question 6

I.6 Welche Szenarien gibt es zur Migration der Workload einer on Premise Infrastructur in die Cloud?

Answer 6

1. Rehosting - Lift-and-Shift
   - Bestehende virtuelle oder physische Server aus dem Rechenzentrum in die Cloud verschieben.
2. Replatforming - “Lift-Thinker-And-Shift”
   - Einige Optimierungen für die Cloud Umgebung werden durchgeführt. z.B Alle Datenbanken werden in eine Database-as-a-Service Plattform migriert, um die Zeit zum Managen zu veringern
3. Repurchasing
   - Ersetzen von Software durch Cloud basierte SaaS Lösungen z.B CRM to Salesforce, HR to Workday or CMS to Drupal
4. Refactoring / Re-architecting
   - Komplettes umdenken wie eine Applikation aufgebaut ist, meist mit Cloud-native features
   - z.B von einer Monolithic architecture zu einer mehr service orientierten
5. Retire
   - Legacy Anwendungen oder Systeme die nicht mehr useful sind retieren um Geld zu sparen.
6. Retain
   - Wenn es keinen Sinn macht, lieber nicht in die Cloud gehen

Question 7

I.7​ Erläutern Sie Identity & Access Management in der Cloud am Beispiel von AWS IAM.

Answer 7

Kernkomponenten:
Benutzer (User): Person/Dienst, der/die auf Ressourcen im AWS zugreifen kann.
Sie können Anmeldeinformationen wie Benutzernamen, Passwörter oder MFA haben.

Gruppen (Groups): Sammlung von Usern.
Berechtigungen können auf Basis von Gruppen erteilt werden – erleichtert Berechtigungsverwaltung.

Rollen (Roles): Identität mit Berechtigungspolicies.
Bestimmen, was die Identität auf AWS tun kann. Wenn Rolle angenommen wird, erhält der User temporäre Sicherheitsanmeldeinformationen.

Berechtigungspolicies (Policies): Objekte in AWS, die Berechtigungen definieren und mit Usern, Gruppen und Rollen verbunden werden können.
Sie bestimmen, welche Aktionen erlaubt/verboten sind.
Policies werden in JSON geschrieben.

Die Funktionsweise umfasst Authentifizierung, Autorisierung, zentrale Verwaltung (über IAM-Konsole, CLI oder API), detaillierte Bedingungen (Erlaubnis/Verweigerung von Zugriffen) und Best Practices (z.B. Least Privilege).

//////
IAM umfasst die Verwaltung von Identitäten (Authentifizierung) von Usern bzw. Clients/Servern/Applikationen und deren Autorisierung. In AWS nutzt jedes einzelne Service IAM, um API-Calls zu authentifizieren und autorisieren. Es besteht dabei die Möglichkeit, dass Federated Identities verwendet werden können, d.h. dass andere Anbieten (z.B. Google, Facebook, Okta, etc.) die Identitäten verwalten und bereitstellen.

Ablauf:
1. Benutzer oder Applikation verwendet Credentials, um sich bei AWS zu authentifizieren. Authentifizierung erfolgt über IAM-User, Federated User, IAM-Rolle oder Applikation (AWS Account muss dem trusten).
2. Request für die Autorisierung wird gesendet an den gewünschten Service (z.B. S3-Bucket). Service vergleicht Identity mit Liste autorisierter Identities und welche Policies enforced sind.
3. Wenn Autorisierung erfolgreich, dann kann entsprechen den Policies gearbeitet werden.

Question 8

I.8 Was bedeutet Immutable Infrastructure und welchen Vorteil hat sie?

Answer 8

Infrastrukturkomponenten werden nicht modifiziert, sondern bei Änderung komplett neu erstellt.

Kernprinzipien:
Unveränderlichkeit,
Versionierung (neue Instanz = neue Version),
Automatisierung (zentral = Tools wie IaC, Terraform, AWS CloudFormation),
Konsistenz (= Reduktion des „Works on my machine“-Problems),
Skalierbarkeit und Wiederherstellbarkeit

Vorteile:
Reduzierte Fehlerrate und vereinfachte Fehlersuche (da keine Änderungen)
schnellere/zuverlässigere Bereitstellung (erfolgen standardisiert),
verbesserte Sicherheit (potentielle Vulnerabilities können bei jeder Neuerstellung beseitigt werden)
schnellere Disaster Recovery
Vermeidung von Konfigurationsdrift, parallele Umgebungen

Question 9

I.9​ Was bedeutet Severless Computing und welche Vorteile hat es?

Answer 9

Es müssen hierbei keine Server mehr verwaltet werden und Entwickler schreiben lediglich Code. Die Provisionierung, Verwaltung und Skalierung wird vollständig vom Cloud-Provider übernommen. Serverless-Apps werden in Containern bereitgestellt, die nur bei Bedarf ausgeführt werden.

Vorteile:
- Applikationen skalieren automatisch
- Applikationscode wird nur auf Anfrage ausgeführt (“only when invoked”)
- Entwickler müssen nur Applikationscode schreiben
- Kein Servermanagement notwendig
- Höhere Abstraktion als bei PaaS
- Kostenverrechnung nach Nutzung/Verwendung des Codes

////: alternativ Antwort

Cloud Computing = Function-as-a-Service (FaaS). Cloud-Anbieter verwaltet die komplette Infrastruktur, Entwickler können sich auf Code und Deployment konzentrieren.
Anbieter übernimmt serverseitig Verantwortung (Bereitstellung, Wartung, Skalierung, Sicherheit).
Kernaspekte:
Ereignisgesteuerte Architektur (serverless Functions werden durch Trigger aktiviert),
keine langfristige Serververwaltung (Plattform kümmert sich um Ressourcen), Zustandslosigkeit (es werden keine Informationen über frühere Ausführungen gespeichert)
Vorteile:
Kosteneffizienz: Keine Zahlung für ungenutzte Serveraktivitäten
Entwicklungsflexibilität: Developer müssen sich nicht um Infrastruktur kümmern
Skalierbarkeit: Automatisch und nahtlos