Anwendungsfälle

Vier Wege, mit denen Cloud Area Networking das Netzwerk ersetzt, mit dem Sie leben mussten.

Eine Policy-Ebene. Ein Identitätsmodell. Von der Niederlassung in Bayern bis zur Region eines Hyperscalers – überall gleich.

StandorteMulti-Cloud & RZIdentität & ZugriffOT & Compliance

Anwendungsfall 01 — Standorte

Niederlassungen, ohne den Ballast.

Ihr Homeoffice läuft auf einem einfachen Router und einem Endgerät, dem Sie Ihre sensibelsten Aufgaben anvertrauen. Warum verlangt dann jede neue Niederlassung weiterhin Firewall, SD-WAN-Box, NAC-Stack und VPN-Konzentrator, bevor sich ein einziger Mitarbeiter anmelden kann?

every site = new attack surface · every laptop = VPN credential

Realität heute

Jeder neue Standort bedeutet Hardware, VLANs, Tunnel zur Zentrale, Verträge, Angriffsfläche. Dann öffnet jemand im Café den Laptop und das ganze Konstrukt ist ohnehin umgangen. Sie zahlen Firewall-Preise, um ein Gebäude zu schützen – nicht die Daten.

Der CanMe-Weg

Sicherheit gehört an den Endpunkt, nicht an den Eingang. Jedes Gerät trägt eine kryptografische Identität, und die Policy reist mit – zu Hause, im Büro, beim Kunden. Der Standort wird bewusst langweilig: Router, Internet, ein Gate. Nichts öffentlich, nichts angreifbar.

In der Praxis

Eine Filiale mit 12 Personen in München, hinter einem einfachen Business-Router:

  • Gate einstecken – der Standort ist am selben Nachmittag live
  • Das NAS ist ein Dark Service: sichtbar nur für das Team, dem es gehört
  • Drucker funktionieren vor Ort – und sonst nirgends
  • Ein Legacy-MES-Terminal mit SMB-v1 – erreichbar nur für benannte Techniker
  • Keine öffentliche IP, keine Firewall-Regeln, kein Site-to-Site-VPN

Das bekommen Sie

Branch-CapEx bricht ein

Ein Gate ersetzt Firewall, NAC und VPN-Konzentrator in einem Gerät.

Rollout in Minuten, nicht Wochen

Einstecken, in Core beanspruchen, Services definieren, fertig.

Null öffentliche Angriffsfläche

Was nicht sichtbar ist, kann nicht angegriffen werden.

Modern, Legacy und OT — ein Standort

Isolation per Identität, nicht per VLAN.

Anwendungsfall 02 — Multi-Cloud & Rechenzentrum

Multi-Cloud, ohne die Hub-and-Spoke-Steuer.

Die Cloud sollte elastisch sein. Dann haben wir sie in NAT, IPSec-Tunnel und eine Hub-and-Spoke-Topologie verpackt – entworfen für eine Welt, die es nicht mehr gibt.

one hub per cloud · standalone Devices orphaned

Realität heute

Jeder Hyperscaler bringt einen Vertrag, einen Tunnel, eine Routing-Tabelle mit. Dev, Test und Prod können sich keinen Adressraum teilen, ohne dass etwas bricht. Zukäufe scheitern an überlappenden CIDRs. Die agile Cloud-Story endet, sobald ein Ticket beim Netzwerkteam landet.

Der CanMe-Weg

CanMe nimmt das Netzwerk aus der Entscheidung. Maschinen und Menschen erreichen Dienste, weil die Policy es sagt – nicht weil zwei Subnetze zufällig routbar sind. IP-Überlappung spielt keine Rolle mehr: Zwischen den Zonen gibt es gar keine Routen. Jede Cloud, jeder Hoster, eine Policy-Ebene.

In der Praxis

Drei Azure-Subscriptions, alle auf 10.0.0.0/16, eine OT-Maschine in Ingolstadt, ein Lasttest bei Hetzner:

  • Ein Entwickler schiebt von zu Hause einen Container von Hetzner nach Ingolstadt
  • Klassisch: Re-IP, Change Requests, Firewall-Ausnahmen – drei Wochen
  • Mit CanMe: Seine Identität gewährt Zugriff auf Service-Ebene, für das Testfenster
  • Fenster zu, Zugriff weg. Das Netzwerk hat von der Workload nie erfahren

Das bekommen Sie

Keine Hub-and-Spoke-Steuer

Traffic fließt dorthin, wo er hingehört – nicht durch einen zentralen Choke Point.

Überlappende IPs sind irrelevant

Routing nach Identität, nicht nach Range.

Neue Umgebungen in Stunden

Jede Cloud, jeder Hoster, jeder Partner – dieselbe Policy.

Sandbox ohne Exposition

Teams experimentieren überall, ohne einen einzigen Port zu öffnen.

Anwendungsfall 03 — Identität & Zugriff

PIM ist erledigt. PAM ist das, was als Nächstes kommt.

Sie haben zwei Jahre gebraucht, um Entra ID sauber aufzustellen. Dann standen Sie im Serverraum und stellten fest: Der Zugriff auf die Dinge, die wirklich zählen, hängt noch an einer Firewall-Regel, die jemand 2017 geschrieben hat.

Auditor added to Audit-Q3Wait for ticket · firewall change · jump host setup

PIM solved · PAM still tickets, jump hosts, and tribal knowledge

Realität heute

PIM hat Nutzer sauber in Anwendungen gebracht. PAM – die Netzwerk- und Infrastrukturebene – besteht weiter aus Jump-Hosts, VPN-Konten und Firewall-Tickets. Onboarding geht schnell. Offboarding ist ein Gebet. Jeder Auditor, jedes Wartungsteam, jeder Techniker ist ein Zugang, der vergessen werden kann.

Der CanMe-Weg

Zugriff wird zur Eigenschaft der Identität, und die Identität liegt in Ihrem IDP. Nutzer in eine Gruppe in Entra ID aufnehmen – und genau der Zugriff entsteht, auf den diese Gruppe Anspruch hat. Wieder entfernen, und er ist überall weg, in Echtzeit. Kein Ticket, keine Firewall-Änderung.

In der Praxis

Drei Personen, drei sehr verschiedene Anforderungen – alle über Gruppenmitgliedschaft gelöst:

  • Ein Auditor braucht fünf Tage Lesezugriff auf eine Reporting-Datenbank – die Gruppe läuft von selbst ab
  • Eine neue Ingenieurin braucht SCADA ab Tag eins – geerbt aus der Rolle ihres Teams
  • Ein Techniker braucht sonntags um 22:00 eine CNC-Steuerung – zeitlich begrenzte Gruppe, in Sekunden drin
  • Keine Firewall-Änderung. Vollständiger Audit-Trail je Identität, Dienst und Sitzung

Das bekommen Sie

Deterministisches Offboarding

Eine Quelle der Wahrheit. Keine verwaisten Accounts.

Schluss mit Access-Review-Feuerwehr

Entra ID ist der Report.

Reaktion in Echtzeit

Notfall-Zugriff für Hersteller in Sekunden, nicht in Stunden.

Ein Modell über IT, OT, Cloud, SaaS

PAM, das endlich zu PIM passt.

Anwendungsfall 04 — OT, Legacy & Compliance

Produktion ins Zero Trust – ohne eine einzige Maschine anzufassen.

NIS-2 ist es egal, dass Ihre umsatzstärkste Maschine noch SMB-v1 spricht. Ihrem Auditor auch.

vendor plugs in → reaches every machine · air-gap is fiction

Realität heute

Industrie- und Legacy-Systeme lassen sich nicht patchen und nicht mit einem Agenten umhüllen. Der Air-Gap ist Fiktion, sobald ein Hersteller sich zur Fernwartung aufschaltet. NIS-2, KRITIS und IEC 62443 verlangen Segmentierung, der Betrieb verlangt Verfügbarkeit. Das Netzwerkteam verliert in jedem Fall.

Der CanMe-Weg

Ein Hardware Gate steht vor der Maschine, der Linie oder der Zelle. Die Maschine ändert sich nicht. Die SPS ändert sich nicht. Das Protokoll ändert sich nicht. Was sich ändert, ist, wer sie erreicht – entschieden über Identität, in Echtzeit. Ein Controller, ein Audit-Trail, eine Antwort für den Prüfer.

In der Praxis

Eine Fertigung: 40 Maschinen, drei Protokolle, zwölf Hersteller mit gelegentlichem Fernzugriff:

  • Gates stehen pro Linie vor den Maschinen
  • Jeder Hersteller erreicht nur seine eigenen Maschinen – nie die Linie nebenan, nie das MES
  • Interne Instandhalter bekommen breiteren, rollenbasierten Zugriff
  • Keine öffentlichen IPs, keine offenen eingehenden Ports
  • „Wer war am Dienstag um 03:47 auf Maschine 14?“ – eine Abfrage

Das bekommen Sie

NIS-2 & KRITIS ohne Maschinentausch

Segmentierung und Zugriffskontrolle ohne Eingriff in die Produktion.

Hersteller-Fernwartung, kontrolliert

Schluss mit dem größten unverwalteten Risiko.

Brownfield, Greenfield, Cloud, OT

Ein Policy-Modell über den ganzen Bestand.

Compliant by Construction

Operativ einfach, Audit-bereit per Default.

Ein Netzwerk. Eine Policy. Ein Identitätsmodell.

Vom Homeoffice bis zur Fertigungshalle, von einer Hyperscaler-Region bis zur Niederlassung in Bayern – Cloud Area Networking ist überall gleich, weil Sicherheit eine Eigenschaft der Identität sein sollte, nicht des Standorts.

Ihr Szenario gefunden? Darunter steckt mehr.

Die Plattform-Seite zeigt die fünf Bausteine, aus denen jeder dieser Anwendungsfälle zusammengesetzt ist. Die Whitepaper führen das Argument vollständig aus – je 13 Seiten, kostenlos, ohne Gespräch.