# 15.4 Cloud-Netzwerke, VPC, Subnetze und Security Groups Cloud-Dienste brauchen genau wie lokale Systeme ein Netzwerk. In der Cloud werden Netzwerke aber nicht mit physischen Switches und Routern aufgebaut, sondern überwiegend virtuell. Typische Bestandteile eines Cloud-Netzwerks: - virtuelles Netzwerk - Subnetze - Routingtabellen - Security Groups - Network Security Groups - virtuelle Firewalls - Load Balancer - öffentliche IP-Adressen - private IP-Adressen - NAT-Gateways - VPN-Gateways - DNS - Peering Merksatz: Cloud-Netzwerke sind virtuell, müssen aber genauso sauber geplant werden wie lokale Netzwerke. --- **Warum Cloud-Netzwerke wichtig sind** Viele Cloud-Fehler entstehen nicht durch die Anwendung, sondern durch Netzwerk- oder Sicherheitskonfiguration. Beispiele: virtuelle Maschine nicht erreichbar Datenbank öffentlich erreichbar Webserver hat falsche Security Group Subnetz hat keine passende Route Cloud-Dienst kann Backend nicht erreichen VPN zur Cloud funktioniert nicht DNS zeigt auf falsches Ziel Load Balancer erreicht keine Instanz Merksatz: Cloud-Probleme sind oft Netzwerk-, Routing- oder Firewall-Probleme. --- **Virtuelles Netzwerk** Ein virtuelles Netzwerk ist ein logisch getrenntes Netzwerk in der Cloud. Je nach Anbieter heißt es zum Beispiel: VPC VNet Virtual Network Virtual Private Cloud Es enthält Cloud-Ressourcen wie: virtuelle Maschinen Subnetze Datenbanken Load Balancer Container VPN-Gateways NAT-Gateways Merksatz: Virtuelles Netzwerk = eigenes logisch getrenntes Cloud-Netz. --- **VPC** VPC steht für: Virtual Private Cloud Eine VPC ist ein virtuelles, logisch isoliertes Netzwerk innerhalb einer Public Cloud. In einer VPC legt man fest: IP-Adressbereich Subnetze Routing Sicherheitsregeln Gateways Verbindungen zu anderen Netzen Merksatz: VPC ist ein privater Netzwerkbereich innerhalb der Cloud. --- **VNet** VNet steht für: Virtual Network Der Begriff wird in manchen Cloud-Plattformen für virtuelle Netzwerke verwendet. Die Grundidee ist ähnlich wie bei VPC: eigener IP-Bereich Subnetze Routing Sicherheitsregeln Cloud-Ressourcen Verbindungen zu anderen Netzen Merksatz: VNet und VPC beschreiben ähnliche Cloud-Netzwerk-Konzepte. --- **IP-Adressbereich im Cloud-Netz** Beim Anlegen eines Cloud-Netzes wird ein IP-Adressbereich festgelegt. Beispiel: 10.20.0.0/16 Daraus können mehrere Subnetze gebildet werden. Beispiele: 10.20.1.0/24 Web-Subnetz 10.20.2.0/24 App-Subnetz 10.20.3.0/24 Datenbank-Subnetz Wichtig: Der Adressbereich darf sich nicht ungewollt mit lokalen Netzen überschneiden. Merksatz: Cloud-IP-Planung muss zu lokaler Netzplanung passen. --- **Subnetze in der Cloud** Subnetze teilen ein virtuelles Netzwerk in kleinere Bereiche auf. Typische Subnetze: Web-Subnetz App-Subnetz Datenbank-Subnetz Management-Subnetz Public Subnet Private Subnet Gateway-Subnetz Vorteile: bessere Struktur gezielte Sicherheitsregeln getrennte Routingtabellen Trennung von öffentlichen und internen Ressourcen Merksatz: Subnetze strukturieren Cloud-Netze. --- **Public Subnet** Ein Public Subnet ist ein Subnetz, das direkt oder indirekt Zugang zum Internet haben kann. Typische Ressourcen: Load Balancer öffentlich erreichbarer Webserver Bastion Host NAT-Gateway Reverse Proxy Wichtig: Nicht jede Ressource in der Cloud gehört in ein Public Subnet. Merksatz: Public Subnet nur für Komponenten, die wirklich öffentlich erreichbar sein müssen. --- **Private Subnet** Ein Private Subnet enthält interne Ressourcen, die nicht direkt aus dem Internet erreichbar sein sollen. Typische Ressourcen: Datenbanken interne Backends interne APIs Anwendungssysteme Verarbeitungssysteme Container-Worker interne Dienste Merksatz: Private Subnet schützt interne Cloud-Ressourcen vor direktem Internetzugriff. --- **Public und Private Subnet vergleichen** | Merkmal | Public Subnet | Private Subnet | |---|---|---| | Internetzugriff eingehend | möglich | normalerweise nicht direkt | | typische Systeme | Load Balancer, Bastion Host | Datenbank, Backend | | Schutzbedarf | hoch | sehr hoch | | Routing | oft zum Internet Gateway | oft über NAT oder interne Routen | | Ziel | öffentliche Erreichbarkeit | interne Verarbeitung | Merksatz: Öffentlich erreichbare Systeme nach außen, interne Systeme nach innen trennen. --- **Internet Gateway** Ein Internet Gateway verbindet ein Cloud-Netz mit dem Internet. Es ermöglicht: eingehende Verbindungen aus dem Internet ausgehende Verbindungen ins Internet Ob eine Ressource wirklich erreichbar ist, hängt zusätzlich ab von: öffentlicher IP-Adresse Routingtabelle Security Group Firewall-Regeln Dienststatus Merksatz: Internet Gateway allein macht eine Ressource nicht automatisch erreichbar. --- **NAT-Gateway** Ein NAT-Gateway erlaubt internen Ressourcen, Verbindungen ins Internet aufzubauen, ohne selbst direkt aus dem Internet erreichbar zu sein. Beispiel: Datenbankserver im Private Subnet lädt Updates herunter aber: Internet kann nicht direkt zur Datenbank verbinden Merksatz: NAT-Gateway erlaubt ausgehenden Internetzugriff für private Ressourcen. --- **Internet Gateway und NAT-Gateway vergleichen** | Merkmal | Internet Gateway | NAT-Gateway | |---|---|---| | Zweck | Verbindung Cloud-Netz ↔ Internet | ausgehender Zugriff aus privaten Netzen | | eingehend aus Internet | möglich, wenn erlaubt | normalerweise nicht | | typischer Einsatz | Public Subnet | Private Subnet | | Schutzwirkung | keine alleinige Schutzmaßnahme | versteckt private Ressourcen vor direktem Zugriff | Merksatz: Internet Gateway verbindet öffentlich. NAT-Gateway ermöglicht ausgehend. --- **Routingtabellen in der Cloud** Routingtabellen legen fest, wohin Pakete gesendet werden. Typische Ziele: lokales Cloud-Netz Internet Gateway NAT-Gateway VPN-Gateway Peering-Verbindung Firewall-Appliance andere Subnetze lokales Unternehmensnetz Merksatz: Routingtabellen bestimmen Wege im Cloud-Netz. --- **Lokale Route** Jedes Cloud-Netz hat normalerweise eine lokale Route. Diese erlaubt Kommunikation innerhalb des virtuellen Netzwerks. Beispiel: 10.20.0.0/16 local Damit können Subnetze innerhalb des Cloud-Netzes grundsätzlich miteinander kommunizieren, sofern Sicherheitsregeln es erlauben. Merksatz: Lokale Route erlaubt Kommunikation innerhalb des Cloud-Netzes. --- **Route ins Internet** Für Internetzugriff braucht ein Public Subnet typischerweise eine Route wie: 0.0.0.0/0 über Internet Gateway Für Private Subnets kann die Standardroute über ein NAT-Gateway gehen: 0.0.0.0/0 über NAT-Gateway Merksatz: Standardroute entscheidet, wohin unbekannte Ziele gehen. --- **Route zum Firmennetz** Bei Hybrid Cloud braucht die Cloud eine Route zum lokalen Unternehmensnetz. Beispiel: lokales Firmennetz: 192.168.10.0/24 Route in Cloud: 192.168.10.0/24 über VPN-Gateway Gleichzeitig braucht das Firmennetz eine Rückroute zum Cloud-Netz. Merksatz: Hybrid Cloud braucht Hin- und Rückroute. --- **Rückroute in Cloud-Szenarien** Viele Fehler entstehen, weil nur der Hinweg geplant wurde. Beispiel: Cloud-Server erreicht lokales System nicht. Oder: lokaler Client erreicht Cloud-Server, aber Antwort kommt nicht zurück. Mögliche Ursache: Rückroute fehlt Firewall blockiert Rückverkehr NAT verändert Adressen asymmetrisches Routing Merksatz: Auch in der Cloud gilt: Ohne Rückweg keine funktionierende Verbindung. --- **Security Group** Eine Security Group ist eine virtuelle Firewall-Regelgruppe für Cloud-Ressourcen. Sie steuert meist: eingehenden Verkehr ausgehenden Verkehr Protokolle Ports Quellen Ziele Security Groups werden oft direkt einer Ressource zugeordnet, zum Beispiel einer virtuellen Maschine. Merksatz: Security Group = Firewall-Regeln direkt an der Cloud-Ressource. --- **Inbound und Outbound** Inbound bedeutet: eingehender Verkehr zur Ressource Outbound bedeutet: ausgehender Verkehr von der Ressource Beispiel Webserver: Inbound: TCP 443 von Internet erlaubt Outbound: Verbindung zur Datenbank oder zu Updateservern erlaubt Merksatz: Inbound und Outbound getrennt prüfen. --- **Stateful Security Group** Viele Security Groups arbeiten stateful. Stateful bedeutet: Wenn eine Verbindung erlaubt wurde, ist der Rückverkehr automatisch erlaubt. Beispiel: Client verbindet zu Webserver TCP 443. Antwortpakete des Webservers zurück zum Client werden automatisch zugeordnet. Merksatz: Stateful-Regeln merken sich Verbindungen. --- **Network ACL** Eine Network ACL ist eine Zugriffsliste auf Netzwerk- oder Subnetzebene. Je nach Cloud-Plattform kann sie: eingehende Regeln prüfen ausgehende Regeln prüfen stateless arbeiten Regelreihenfolge beachten Stateless bedeutet: Rückverkehr muss separat erlaubt werden. Merksatz: Network ACLs wirken oft näher am Subnetz und können stateless sein. --- **Security Group und Network ACL vergleichen** | Merkmal | Security Group | Network ACL | |---|---|---| | Ebene | Ressource oder Instanz | Subnetz oder Netzwerkebene | | Zustand | oft stateful | oft stateless | | Rückverkehr | häufig automatisch erlaubt | häufig separat nötig | | Einsatz | feine Ressourcenregeln | zusätzliche Netzgrenze | | Fehlerquelle | falsche Quelle oder Port | fehlender Rückverkehr oder Regelreihenfolge | Merksatz: Security Group und Network ACL können beide blockieren. --- **Network Security Group** Network Security Group wird oft abgekürzt: NSG Eine NSG ist eine Regelgruppe, die Netzwerkverkehr auf Subnetz- oder Ressourceneebene steuern kann. Typische Angaben: Quelle Ziel Port Protokoll Richtung Priorität Aktion Beschreibung Merksatz: NSG ist eine Cloud-Regelgruppe für Netzwerkzugriffe. --- **Regelreihenfolge und Priorität** Manche Cloud-Regelwerke arbeiten mit Prioritäten. Dabei gilt: Regel mit höherer Priorität oder niedrigerer Nummer wird zuerst geprüft Je nach Plattform ist die genaue Logik unterschiedlich. Wichtig: spezifische Regeln vor allgemeinen Regeln Deny-Regeln beachten Standardregeln verstehen Merksatz: Regelreihenfolge kann entscheiden, ob Verkehr erlaubt oder blockiert wird. --- **Quelle und Ziel in Cloud-Regeln** In Cloud-Regeln können Quellen und Ziele sein: IP-Adressen Subnetze Security Groups Tags Service Accounts Load Balancer Cloud-Dienste Internet Beispiel: Webserver-Security-Group darf zur Datenbank-Security-Group auf TCP 5432. Das ist oft besser als: gesamtes Netz darf zur Datenbank. Merksatz: Cloud-Regeln möglichst gezielt formulieren. --- **Öffentliche IP-Adresse** Eine öffentliche IP-Adresse macht eine Ressource grundsätzlich aus dem Internet adressierbar. Aber erreichbar ist sie nur, wenn zusätzlich passen: Routing Security Group Firewall Dienst Betriebssystem-Firewall DNS Load Balancer Zertifikat Merksatz: Öffentliche IP allein reicht nicht für funktionierenden Zugriff. --- **Private IP-Adresse** Private IP-Adressen werden innerhalb des Cloud-Netzes genutzt. Typisch für: interne Kommunikation Datenbanken Backends interne APIs Server-zu-Server-Kommunikation Hybrid-Cloud-Verbindungen Merksatz: Private IPs sind für interne Kommunikation im Cloud-Netz. --- **Öffentliche und private IP vergleichen** | Merkmal | öffentliche IP | private IP | |---|---|---| | Erreichbarkeit | aus Internet möglich | nur intern oder über Verbindung | | Einsatz | Webzugriff, Load Balancer | Backend, Datenbank, interne Dienste | | Risiko | höher | geringer, aber nicht risikofrei | | Schutz | Firewall, Security Group, TLS | Segmentierung, Regeln, IAM | Merksatz: Öffentlich nur, wenn es wirklich nötig ist. --- **Load Balancer in der Cloud** Ein Load Balancer verteilt Anfragen auf mehrere Ziele. Ziele können sein: virtuelle Maschinen Container App-Instanzen Backends Servergruppen Aufgaben: Lastverteilung Health Checks Hochverfügbarkeit TLS-Terminierung Weiterleitung Skalierung unterstützen Merksatz: Load Balancer verteilt Anfragen und erhöht Verfügbarkeit. --- **Health Check** Ein Health Check prüft, ob ein Backend gesund ist. Beispiele: TCP-Port erreichbar? HTTP-Status 200? bestimmter Pfad antwortet? Anwendung meldet gesund? Antwortzeit akzeptabel? Wenn ein Backend ungesund ist, leitet der Load Balancer keinen Verkehr mehr dorthin. Merksatz: Health Check entscheidet, ob ein Backend Verkehr bekommt. --- **Typische Load-Balancer-Fehler** Häufige Fehler: Backend-Port falsch Health Check falscher Pfad Security Group blockiert Load Balancer Backend-Dienst läuft nicht TLS-Zertifikat falsch falscher Host-Header falsches Protokoll Backend in falschem Subnetz keine gesunden Ziele Merksatz: 502 oder 503 in der Cloud hängt oft mit Load Balancer oder Backend zusammen. --- **Cloud-DNS** Cloud-DNS verwaltet Namen für Cloud-Ressourcen. Typische Aufgaben: öffentliche DNS-Zonen private DNS-Zonen interne Namen Load-Balancer-Namen Service Discovery Hybrid-DNS Weiterleitung zu lokalen DNS-Servern Merksatz: Cloud-DNS verbindet Namen mit Cloud-Ressourcen. --- **Private DNS-Zone** Eine Private DNS-Zone ist nur innerhalb bestimmter Netzwerke sichtbar. Beispiel: app.internal.cloud Nur Systeme im Cloud-Netz oder verbundenen Netzen können diesen Namen auflösen. Merksatz: Private DNS ist für interne Cloud-Namen. --- **Public DNS-Zone** Eine Public DNS-Zone ist öffentlich abfragbar. Beispiel: www.firma.de Sie wird für öffentlich erreichbare Dienste genutzt. Wichtig: Öffentlicher DNS-Eintrag bedeutet nicht, dass Zugriff auch erlaubt ist. Merksatz: Public DNS ist sichtbar, Zugriff hängt trotzdem von Routing und Regeln ab. --- **Cloud Peering** Peering verbindet zwei virtuelle Netzwerke miteinander. Beispiel: VPC A ↔ VPC B Oder: VNet A ↔ VNet B Ziel: private Kommunikation zwischen Cloud-Netzen Wichtig: Routen Security Groups DNS Überschneidung von IP-Netzen Berechtigungen Merksatz: Peering verbindet Cloud-Netze privat miteinander. --- **Peering ist kein Transit automatisch** Ein häufiger Denkfehler: Wenn Netz A mit B verbunden ist und B mit C verbunden ist, kann A automatisch C erreichen. Das stimmt nicht immer. Viele Peering-Verbindungen sind nicht automatisch transitiv. Merksatz: Peering bedeutet nicht automatisch Durchleitung zu dritten Netzen. --- **Transit Gateway oder Hub-and-Spoke** In größeren Cloud-Netzen nutzt man oft zentrale Netzwerkarchitekturen. Beispiel: Hub-Netz mit Firewall, VPN, Internetzugang und zentralen Diensten Spoke-Netze für Anwendungen, Abteilungen oder Umgebungen Vorteil: zentrale Kontrolle einheitliches Routing bessere Segmentierung übersichtliche Sicherheitsregeln Merksatz: Hub-and-Spoke ordnet viele Cloud-Netze zentral. --- **Cloud-VPN** Cloud-VPN verbindet Cloud-Netze mit anderen Netzen. Beispiele: Cloud ↔ lokales Rechenzentrum Cloud ↔ Niederlassung Cloud ↔ andere Cloud Wichtig: passende IP-Netze Routing auf beiden Seiten Firewall-Regeln Verschlüsselung Monitoring Redundanz Merksatz: Cloud-VPN braucht Planung auf Cloud-Seite und lokaler Seite. --- **Direktverbindung zur Cloud** Neben VPN kann es direkte private Verbindungen zu Cloud-Anbietern geben. Eigenschaften: private Verbindung meist stabilere Leistung geringere Latenz möglich höhere Bandbreite möglich kein normaler Internetweg oft teurer und aufwendiger Merksatz: Direktverbindung kann für kritische Hybrid-Cloud-Szenarien sinnvoll sein. --- **Bastion Host in der Cloud** Ein Bastion Host ist ein besonders geschützter Sprungserver. Zweck: Adminzugriffe auf private Cloud-Ressourcen ermöglichen, ohne diese direkt ins Internet zu stellen. Beispiel: Admin → Bastion Host → private VM Wichtig: MFA Logging beschränkte Quellen regelmäßige Updates keine Dauerzugänge starke Härtung Merksatz: Bastion Host reduziert direkte öffentliche Adminzugriffe. --- **Managementports nicht öffentlich öffnen** Kritische Managementports sollten nicht offen im Internet liegen. Beispiele: SSH TCP 22 RDP TCP 3389 Datenbankports Admin-Weboberflächen Kubernetes-API Storage-Adminzugänge Besser: VPN Bastion Host Zero-Trust-Zugang private Subnetze eingeschränkte Quell-IP MFA Merksatz: Managementzugänge gehören nicht breit ins Internet. --- **Cloud-Firewall** Eine Cloud-Firewall kann zentrale Filterung übernehmen. Sie schützt zum Beispiel: Internetzugang Verbindungen zwischen Subnetzen Verbindung zu lokalen Netzen Cloud-zu-Cloud-Verkehr DMZ-ähnliche Bereiche Funktionen können sein: Paketfilter Stateful Inspection Anwendungskontrolle IDS/IPS URL-Filter Logging Merksatz: Cloud-Firewall ergänzt Security Groups und Netzsegmentierung. --- **Cloud-Netzsegmentierung** Auch in der Cloud sollte man Systeme trennen. Beispiele: Web-Schicht App-Schicht Datenbank-Schicht Management-Schicht Entwicklungsumgebung Testumgebung Produktionsumgebung DMZ-ähnliche Zone Merksatz: Cloud braucht Segmentierung wie lokale Netze. --- **Drei-Schichten-Architektur in der Cloud** Ein typisches Muster: Web-Schicht: öffentlich erreichbar über Load Balancer App-Schicht: nur intern vom Webserver erreichbar Datenbank-Schicht: nur von App-Servern erreichbar Vorteil: bessere Sicherheit klare Kommunikationswege weniger Angriffsfläche Merksatz: Datenbanken gehören normalerweise nicht direkt ins Internet. --- **Umgebungen trennen** Cloud-Ressourcen sollten nach Umgebung getrennt werden. Typische Umgebungen: Entwicklung Test Staging Produktion Warum? Testfehler sollen Produktion nicht stören. Rechte können getrennt werden. Kosten können getrennt werden. Änderungen werden kontrollierter. Sicherheitsregeln sind klarer. Merksatz: Entwicklung, Test und Produktion sauber trennen. --- **Cloud-Netzwerk und IAM** Netzwerkregeln allein reichen nicht. Auch Identitäten und Rechte sind wichtig. Beispiel: Benutzer darf Security Group ändern. Benutzer darf öffentliche IP vergeben. Benutzer darf Route zum Internet setzen. Benutzer darf Firewall-Regel öffnen. Diese Rechte können sicherheitskritisch sein. Merksatz: Wer Cloud-Netzwerke ändern darf, kann Sicherheit stark beeinflussen. --- **Cloud-Netzwerk-Fehlkonfigurationen** Häufige Fehler: Datenbank öffentlich erreichbar SSH offen für das ganze Internet RDP offen für das ganze Internet Security Group zu breit falsche Route ins Internet Private Subnet versehentlich öffentlich fehlende Rückroute falscher Load-Balancer-Health-Check keine Logs veraltete Bastion Hosts Peering ohne Sicherheitsprüfung Merksatz: Viele Cloud-Sicherheitsprobleme sind Netzwerk-Fehlkonfigurationen. --- **Cloud-Netzwerk-Logging** Wichtige Logquellen: Flow Logs Firewall-Logs Load-Balancer-Logs DNS-Logs VPN-Logs IAM-Logs Routing-Änderungen Security-Group-Änderungen WAF-Logs Merksatz: Netzwerklogs zeigen, welcher Verkehr erlaubt oder blockiert wurde. --- **Flow Logs** Flow Logs zeigen Netzwerkverbindungen auf Ebene von Metadaten. Sie enthalten typischerweise: Quelle Ziel Port Protokoll Aktion Zeit Datenmenge Interface oder Ressource Sie zeigen normalerweise nicht den vollständigen Paketinhalt. Merksatz: Flow Logs zeigen Verbindungsdaten, aber keinen kompletten Paketmitschnitt. --- **Cloud-Netzwerk-Monitoring** Überwacht werden sollten: VPN-Tunnelstatus Load Balancer Backend-Gesundheit Paketverlust Latenz Bandbreite Firewall-Drops DNS-Fehler öffentliche IPs ungewöhnlicher Datenverkehr Kosten durch Traffic Merksatz: Cloud-Netzwerk-Monitoring schützt Betrieb und Kosten. --- **Cloud-Netzwerk-Fehlersuche** Sinnvolle Reihenfolge: 1. Quelle und Ziel bestimmen. 2. IP-Adressen prüfen. 3. DNS prüfen. 4. Subnetz prüfen. 5. Routingtabelle prüfen. 6. Security Group prüfen. 7. Network ACL oder NSG prüfen. 8. Load Balancer prüfen. 9. Zielsystem und Dienst prüfen. 10. Host-Firewall prüfen. 11. Logs prüfen. 12. Rückweg prüfen. Merksatz: Auch in der Cloud gilt: DNS, Route, Firewall, Dienst und Rückweg prüfen. --- **Fehlerbild: Cloud-VM nicht per SSH erreichbar** Mögliche Ursachen: keine öffentliche IP DNS zeigt falsch Routing zum Internet fehlt Security Group blockiert TCP 22 Network ACL blockiert SSH-Dienst läuft nicht Host-Firewall blockiert falscher Benutzer oder Schlüssel Bastion Host nötig Quell-IP nicht erlaubt Merksatz: SSH-Fehler in Cloud mit IP, Route, Security Group, Dienst Schlüssel und Bastion prüfen. --- **Fehlerbild: Webdienst in Cloud nicht erreichbar** Mögliche Ursachen: DNS falsch Load Balancer falsch Zertifikat falsch Security Group blockiert TCP 443 Backend ungesund Health Check falsch Anwendung läuft nicht falscher Port private Ressource ohne öffentliche Freigabe WAF blockiert Merksatz: Webfehler in Cloud mit DNS, Load Balancer, Security Group, TLS und Backend prüfen. --- **Fehlerbild: Cloud-Datenbank öffentlich erreichbar** Das ist meistens ein Sicherheitsproblem. Mögliche Ursachen: Datenbank in Public Subnet öffentliche IP vergeben Security Group zu breit Firewall-Regel erlaubt 0.0.0.0/0 Authentifizierung schwach kein Private Endpoint falsches Routing Besser: Private Subnet Zugriff nur von App-Schicht Security Group gezielt keine öffentliche IP Verschlüsselung starke Authentifizierung Merksatz: Datenbanken gehören normalerweise nicht öffentlich ins Internet. --- **Fehlerbild: Cloud und On-Premises erreichen sich nicht** Mögliche Ursachen: VPN-Tunnel down Route in Cloud fehlt Route lokal fehlt Firewall blockiert Security Group blockiert IP-Netze überschneiden sich DNS falsch NAT falsch Rückroute fehlt Cloud-Gateway falsch konfiguriert Merksatz: Hybrid-Verbindungen brauchen Regeln und Routen auf beiden Seiten. --- **Checkliste: Cloud-Netzwerk sicher planen** IP-Adressbereich eindeutig wählen. Subnetze sauber trennen. Public und Private Subnets unterscheiden. Datenbanken nicht öffentlich bereitstellen. Managementzugänge nicht breit öffnen. Security Groups eng setzen. Rückwege planen. Hybrid-Routen dokumentieren. DNS-Konzept erstellen. Logging aktivieren. Monitoring einrichten. Änderungen dokumentieren. Rechte zur Netzwerkänderung begrenzen. Merksatz: Cloud-Netzwerk zuerst planen, dann Ressourcen bereitstellen. --- **Typische IHK-Fragen** In AP1 und AP2 kann zum Beispiel gefragt werden: - Was ist ein virtuelles Netzwerk in der Cloud? - Was bedeutet VPC? - Was ist ein Subnetz in der Cloud? - Was ist der Unterschied zwischen Public Subnet und Private Subnet? - Was ist ein Internet Gateway? - Was ist ein NAT-Gateway? - Wofür nutzt man Routingtabellen in der Cloud? - Was ist eine Security Group? - Was ist eine Network ACL? - Was ist eine NSG? - Was ist der Unterschied zwischen öffentlicher und privater IP? - Wofür nutzt man einen Load Balancer? - Was ist ein Health Check? - Was ist Cloud Peering? - Warum ist Peering nicht automatisch transitiv? - Warum sollte eine Datenbank nicht öffentlich erreichbar sein? - Wie geht man bei Cloud-Netzwerk-Fehlersuche vor? --- **Typische Prüfungsfallen** Cloud-Netzwerke sind virtuell, aber echte Netzplanung bleibt nötig. VPC und VNet beschreiben virtuelle Cloud-Netze. Public Subnet ist nicht für alle Systeme geeignet. Private Subnet schützt vor direkter öffentlicher Erreichbarkeit. Internet Gateway allein reicht nicht für Zugriff. NAT-Gateway erlaubt typischerweise ausgehende Verbindungen. Routingtabellen bestimmen Wege. Rückroute nicht vergessen. Security Groups wirken wie virtuelle Firewalls. Network ACLs können zusätzlich blockieren. Stateful und stateless unterscheiden. Öffentliche IP bedeutet höheres Risiko. Datenbanken nicht öffentlich freigeben. Load Balancer braucht gesunde Backends. Health Check muss zum Dienst passen. Peering ist nicht automatisch transitiv. Cloud-Firewall ersetzt nicht saubere Segmentierung. Managementports nicht breit ins Internet öffnen. Cloud-Netzwerkänderungen sind sicherheitskritisch. Flow Logs zeigen Metadaten, nicht vollständige Pakete. --- **Wichtige Begriffe kurz erklärt** | Begriff | Kurze Erklärung | |---|---| | virtuelles Netzwerk | logisch getrenntes Cloud-Netz | | VPC | Virtual Private Cloud | | VNet | Virtual Network | | Subnetz | Teilbereich eines Cloud-Netzes | | Public Subnet | öffentlich angebundenes Subnetz | | Private Subnet | internes Subnetz ohne direkte öffentliche Erreichbarkeit | | Internet Gateway | Verbindung eines Cloud-Netzes zum Internet | | NAT-Gateway | ausgehender Internetzugriff für private Ressourcen | | Routingtabelle | Wege zu Zielnetzen | | lokale Route | Route innerhalb des Cloud-Netzes | | Security Group | virtuelle Firewall-Regelgruppe | | Network ACL | Zugriffsliste auf Netzwerk- oder Subnetzebene | | NSG | Network Security Group | | Stateful | Rückverkehr wird automatisch zugeordnet | | Stateless | Rückverkehr muss separat erlaubt werden | | öffentliche IP | aus dem Internet adressierbare IP | | private IP | interne Adresse im Cloud-Netz | | Load Balancer | verteilt Anfragen auf Ziele | | Health Check | Prüfung der Backend-Gesundheit | | Cloud-DNS | Namensauflösung für Cloud-Ressourcen | | Private DNS-Zone | interne DNS-Zone | | Public DNS-Zone | öffentlich sichtbare DNS-Zone | | Peering | Verbindung zwischen Cloud-Netzen | | Hub-and-Spoke | zentrale Netzwerkarchitektur | | Cloud-VPN | VPN-Verbindung zu Cloud-Netz | | Bastion Host | gehärteter Sprungserver | | Flow Logs | Metadaten zu Netzwerkverbindungen | --- **IHK-sichere Kurzformulierung** Cloud-Netzwerke bestehen aus virtuellen Netzwerken wie VPC oder VNet, Subnetzen, Routingtabellen, Security Groups, Network ACLs, Gateways, Load Balancern und DNS. Public Subnets sind für öffentlich erreichbare Komponenten wie Load Balancer oder Bastion Hosts gedacht, während Private Subnets interne Ressourcen wie Datenbanken oder Backends schützen. Ein Internet Gateway verbindet ein Cloud-Netz mit dem Internet, während ein NAT-Gateway privaten Ressourcen ausgehenden Internetzugriff ermöglicht. Security Groups und NSGs wirken als virtuelle Firewall-Regeln. Bei Cloud-Netzwerk-Fehlern müssen DNS, IP-Adressen, Routing, Security Groups, Network ACLs, Load Balancer, Zielsysteme, Host-Firewalls und Rückwege geprüft werden. --- **Merksätze** Cloud-Netzwerke sind virtuell, aber echte Netzplanung bleibt nötig. VPC = Virtual Private Cloud. VNet = Virtual Network. Virtuelles Netzwerk ist logisch getrennt. IP-Bereiche sauber planen. Cloud-Netze dürfen sich nicht ungewollt überschneiden. Subnetze strukturieren Cloud-Ressourcen. Public Subnet für öffentliche Komponenten. Private Subnet für interne Komponenten. Datenbank nicht öffentlich erreichbar machen. Internet Gateway verbindet zum Internet. NAT-Gateway ermöglicht ausgehenden Zugriff. Routingtabellen bestimmen Wege. Standardroute entscheidet bei unbekannten Zielen. Hybrid Cloud braucht Hin- und Rückrouten. Security Group ist virtuelle Firewall. Inbound und Outbound getrennt prüfen. Stateful merkt sich Verbindungen. Stateless braucht separate Rückregeln. Network ACL kann zusätzlich blockieren. NSG steuert Netzwerkzugriffe. Öffentliche IP nur wenn nötig. Private IP für interne Kommunikation. Load Balancer verteilt Anfragen. Health Check prüft Backend-Gesundheit. Cloud-DNS kann öffentlich oder privat sein. Peering verbindet Cloud-Netze. Peering ist nicht automatisch transitiv. Hub-and-Spoke schafft zentrale Kontrolle. Cloud-VPN braucht Routen beidseitig. Bastion Host schützt Adminzugriffe. Managementports nicht breit öffnen. Segmentierung gilt auch in der Cloud. IAM beeinflusst Netzwerksicherheit. Flow Logs zeigen Verbindungsmetadaten. Cloud-Fehlersuche: DNS, Route, Security Group, Dienst, Rückweg.