News
ZurückPrivate Netze über Projektgrenzen hinweg
Bei cloudscale kannst du zusammengehörende Cloud-Ressourcen in Projekten gruppieren (etwa um dein Test- vom Prod-Setup zu trennen) und so den Beteiligten auch abgestufte Berechtigungen erteilen. Mit privaten Netzen verbindest du virtuelle Server, wenn einzelne davon (z.B. ein DB-Backend) nicht aus dem Internet erreichbar sein sollen. Und wieso diese zwei Konzepte nicht miteinander kombinieren? Network Sharing erlaubt es dir, private Netze bei Bedarf mit anderen Projekten zu teilen – auch über Account- bzw. Organization-Grenzen hinweg.
Separate Projekte, gemeinsames Netz
Mit privaten Netzen kannst du virtuelle Server an einem Cloud-Standort sozusagen intern "verkabeln", so etwa einen Webserver, der Anfragen von Clients entgegennimmt, mit dem zugehörigen Datenbank-Backend. Wenn einzelne Server gar nicht aus dem Internet erreichbar sein müssen, minimierst du damit nicht zuletzt die Angriffsfläche. Verbinde deine Server und Load-Balancer nun auch dann mittels privatem Netz, wenn sie sich nicht im gleichen Projekt befinden.
Projekte bringen nämlich nicht nur Übersicht und Ordnung in deine Cloud-Ressourcen: Sind in deiner Organization unterschiedliche Teams mit der Wartung bspw. von Web-Workern und DB-Clustern betraut, legst du deren Zugriffsrechte im Control Panel für jedes Projekt separat fest. Mit getrennten Projekten und einem geteilten privaten Netz kannst du dann sowohl die Zuständigkeiten sauber abbilden als auch die Datenbanken vom Internet abschotten, während sie gleichzeitig von den Web-Workern aus erreichbar bleiben.
Ein weiteres Beispiel für eine solche Trennung könnte etwa sein, wenn du das Management deiner Firewall an einen externen Dienstleister ausgelagert (und dieser "Partner Organization" im Control Panel Berechtigungen im "Firewall-Projekt" gewährt) hast; der gefilterte Traffic kann dann im privaten Netz zu den Servern in deinen anderen Projekten fliessen. Oder vielleicht hast du einen zentralisierten Log-Server, den du – Stichwort: "Segregation of Duties" – in einem eigenen Projekt betreibst. Schliesslich kannst du so auch die Reichweite eines API-Tokens begrenzen, das du zur Automatisierung in einem Tool hinterlegt hast.
Geteilte Netze nutzen
Wenn sich zwei Projekte ein privates Netz teilen sollen, lege vorab fest, welches der Projekte der "Owner" des Netzes sein soll. Nur aus diesem Projekt heraus können später Details wie der Name oder die MTU des Netzes geändert werden. Zum eigentlichen Teilen (oder um später den Kreis der teilnehmenden Projekte zu ändern) gib kurz unserem Support Bescheid, den Link dazu findest du im Control Panel unter "Network > Sharing".
Die Eigenschaften des privaten Netzes sind für alle beteiligten Projekte sichtbar, insbesondere etwa der Name des Netzes, um es beim Anschliessen eines Servers sicher zu identifizieren. Unter "Network > Ports" ebenfalls sichtbar sind die MAC-Adressen und – sofern via DHCP verwaltet – die IP-Adressen aller Geräte an diesem Netz: einerseits sind diese technischen Details sowieso für alle im Netz zugänglich (etwa mittels ARP-Requests), andererseits helfen sie dir, Kollisionen und ihre Folgefehler zu vermeiden. Nicht sichtbar sind hingegen die Namen von Servern und Load-Balancern in fremden Projekten; solche Geräte erscheinen einfach als "Other Device".
Apropos IP-Adressen: Du kannst in dem privaten Netz beliebige IPs nutzen und so auch darauf Rücksicht nehmen, wenn ein beteiligtes Projekt bereits einem bestimmten Adressschema folgt. Mehr Informationen zur Konfiguration des gewünschten Subnets und weiteren DHCP-Features findest du in unserem Beitrag zum Managed DHCP.
Geteilte private Netze erlauben dir, den internen Datenfluss zwischen den richtigen Systemen zu gewährleisten, ohne dass diese alle im gleichen Projekt (und damit von den gleichen Personen verwaltet) sein müssen. So kannst du Berechtigungen präziser gliedern oder auch Services zentralisieren, die von mehreren Projekten genutzt werden – innerhalb deiner Organization genauso wie mit Partner Organizations.
Network? Go!
Dein cloudscale-Team