Wie moderne Sicherheitsplattformen die Regeln organisieren

Jede Sicherheitsplattform steht irgendwann vor der gleichen grundlegenden Frage:

Wie sollten die Sicherheitsregeln organisiert sein?

Auf den ersten Blick klingt dies wie eine einfache Entscheidung bei der Datenmodellierung. In der Praxis bestimmt sie die tägliche Realität des Sicherheitsbetriebs: wie schnell Vorfälle behoben werden können, wie sicher Richtlinien entwickelt werden können, wie leicht neue Büros oder Benutzergemeinschaften eingebunden werden können und ob Wachstum zu Klarheit oder Chaos führt.

In den letzten zehn Jahren haben sich die SASE- und SSE-Plattformen auf eine kleine Anzahl von Architekturmustern geeinigt. Diese Muster werden oft in realen Produkten kombiniert, aber jedes repräsentiert eine eigene Designphilosophie mit eigenen Stärken und Fehlermöglichkeiten.

Das Verständnis dieser Modelle – und der Dimensionen, in denen sie sich unterscheiden – erklärt, warum sich moderne Plattformen von einer enginezentrierten Denkweise weg und hin zu strukturierteren, skalierbaren Ansätzen bewegen.

Dimension 1: Wie Regeln gruppiert werden

(Die primäre Achse der Politikgestaltung)

1. Regeldatenbank pro Security Engine

(Das fragmentierte Modell)

Dies ist der älteste und immer noch weit verbreitete Ansatz.

Jede Sicherheitsfunktion verfügt über eine eigene, unabhängige Regeldatenbank :

• Firewall
• IDS / IPS
• DLP
• Malware-Scans
• URL- und Kategorie-Filterung
• SaaS-Kontrollen
• Mehrere GenAI / LLM Leitplanken

In modernen Umgebungen handelt es sich nicht mehr nur um eine Handvoll Engines. Allein die „GenAI-Sicherheit“ umfasst mehrere spezialisierte Sub-Engines, wie z.B.:

• prompte Erkennung von Injektionen,
• Validierung der Eingabe/Ausgabe von Tools
• Code-Erkennung
• Inhaltliche Sicherheit
• Kategorisierung und Filterung von Inhalten
• eingebettete URL-Sicherheit
• Semantische DLP

Jede Engine hat ihre eigene Anpassungslogik, ihre eigenen Aktionen, ihren eigenen Lebenszyklus und ihren eigenen Betreiber.

Stärken

• Tiefe, spezialisierte Kontrolle
• Eindeutige Verantwortlichkeit von Domänenexperten
• Unabhängige Entwicklung von Sicherheits-Engines

Strukturelle Grenzen

• Fragmentierte Sichtbarkeit der Verkehrsströme
• Widersprüchliche Entscheidungen zwischen Motoren
• Hoher operativer Aufwand
• Schlechte Skalierbarkeit bei Vervielfachung der Motoren

Dieses Modell spiegelt ein isoliertes Sicherheitsteam wider – und birgt die gleichen Herausforderungen in Bezug auf Koordination und Funktionsfähigkeit.

2. Eine einzige, einheitliche Regelbasis

(Das konsolidierte Modell)

Im Zuge der Vereinheitlichung der Plattformen schwenkten viele in das entgegengesetzte Extrem: alle Entscheidungen wurden in einer globalen Regeltabelle zusammengefasst .

Jede Regel definiert:

• Übereinstimmungsbedingungen (Benutzer, Anwendung, Ziel, Kontext)
• Verweise auf Prüfprofile für DLP, Malware, GenAI und andere Engines

Stärken

• Eine Regel erklärt eine Entscheidung
• Leichtere Prüfung und Fehlerbehebung
• Passt gut zum Zero-Trust-Denken („eine Absicht = eine Regel“)

Strukturelle Grenzen

• Regeltabellen werden in komplexen Umgebungen sehr groß
• Profiländerungen können einen großen Explosionsradius haben
• Fachärzte verlieren Autonomie
• Governance wird zum Engpass

Dieses Modell zeichnet sich durch Transparenz und Einfachheit aus, lässt sich aber in großen oder sich schnell verändernden Organisationen oft nicht sicher skalieren.

3. Regelbasis pro Zieltyp

(Das Reiseziel-Zuerst-Modell)

Eine neuere Entwicklung sieht vor, dass sich die Regeln danach richten, wohin der Datenverkehr fließt, und nicht danach, welche Maschine ihn untersucht.

Typische Zielkategorien sind:

• Internet
• SaaS-Anwendungen
• Private Anwendungen

Jeder Zielorttyp hat seine eigene Regelbasis für die Zugriffskontrolle, die unterschiedliche Vertrauensmodelle, Risiken und Semantiken widerspiegelt. Die Regeln werten nach wie vor umfangreiche Übereinstimmungsbedingungen aus und führen zu einer Entscheidung auf Sitzungsebene, ob der Zugriff erlaubt oder verweigert wird.

Stärken

• Klare Trennung der Zugriffsabsichten
• Ein intuitiveres mentales Modell für Administratoren
• Vorhersehbare Leistungsmerkmale
• Geringere Vermischung unzusammenhängender politischer Logik

Strukturelle Grenzen

• Das allein ist noch keine Lösung für die Zersiedelung der Landschaft
• Erfordert eine zusätzliche Struktur für eine saubere Skalierung über große Organisationen hinweg

Eine zielorientierte Organisation verbessert die Übersichtlichkeit, aber es wird eine weitere Dimension benötigt, um Umfang und Wiederverwendung zu verwalten.

Dimension 2: Umfang und Wiederverwendung von Policies

(Orthogonal zur Regelgruppierung)

Die folgenden Modelle beantworten eine andere Frage:

Wie werden Richtlinien verpackt, wiederverwendet und auf verschiedene Standorte, Benutzer oder Umgebungen angewendet?

Sie können mit jedem der oben genannten Ansätze zur Regelgruppierung kombiniert werden.

4. Konfigurations-Profile

(Politik als Objekt erster Klasse)

Konfigurationsprofile stellen eine Abstraktion auf höherer Ebene dar, die Richtlinien enthält, anstatt selbst eine Richtlinie zu sein.

Ein Konfigurationsprofil bündelt in der Regel:

• • Eine oder mehrere Regelbasen für die Zugriffskontrolle
  • Inspektionsprofile (Logik „zulassen, aber scannen“)

Engine-spezifische Sicherheitsobjekte (DLP-Objekte, GenAI-Kontrollen, IDS-Signaturen, usw.)

Das Profil wird zu einer übertragbaren Sicherheitsmaßnahme, die auf alle Bereiche angewendet werden kann:

• Physische Büros
• Regionen
• Logische Seiten
• Benutzergemeinschaften

Anstatt die Logik des Geltungsbereichs (z. B. Standort oder Region) in jede Regel einzubetten, wird der Geltungsbereich der Richtlinie durch Anwendung des entsprechenden Konfigurationsprofils festgelegt.

Warum das wichtig ist

• Reduziert die Explosion von Regeln
• Verbessert die Lesbarkeit und Wartbarkeit
• Ermöglicht klarere RBAC-Grenzen
• Macht Richtlinienänderungen sicherer und vorhersehbarer

Dieser Ansatz wird in modernen SASE- und SSE-Plattformen immer häufiger verwendet, auch wenn er nicht ausdrücklich als solcher gekennzeichnet ist.

5. Vererbung von Richtlinien

(Mehrschichtige Kontrollmodelle)

Ein weiteres weit verbreitetes – aber oft implizites – Muster ist die Vererbung.

Policen sind hierarchisch aufgebaut:

• Eine globale Basislinie
• Regionale oder funktionale Überlagerungen
• Standort- oder gruppenspezifische Überschreibungen

Die Vererbung ermöglicht es Unternehmen, Standardeinstellungen gemeinsam zu nutzen und gleichzeitig eine kontrollierte Spezialisierung zu ermöglichen.

Kompromisse

• Leistungsstark aber komplex
• Fehlersuche erfordert das Verständnis der Auflösungsreihenfolge
• Schlecht gestaltete Vererbung kann wirksame Politik verschleiern

Vererbung wird oft mit Konfigurationsprofilen kombiniert, um Wiederverwendung und Übersichtlichkeit in Einklang zu bringen.

Die Dimensionen zusammenbringen

Moderne Sicherheitsplattformen verlassen sich selten auf ein einziges Modell.

Stattdessen kombinieren sie:

• Zielbasierte Regelorganisation (Klarheit der Absicht)
• Konfigurationsprofile (Richtlinieneinteilung und Wiederverwendung)
• Vererbung (kontrollierte Spezialisierung)
• Profilbasierte Inspektion (Motormodularität)

Dieser vielschichtige Ansatz spiegelt eine zentrale Erkenntnis wider:

Die Komplexität der Sicherheit kann nicht beseitigt, sondern nur strukturiert werden.

Wo AI>sicher ist

AI>Secure von Aryaka macht seine architektonischen Entscheidungen in diesen beiden Dimensionen deutlich:

• Dimension 1 – Regelorganisation: Zielbasiertes Regelmodell, das die Zugriffskontrolle für Internet-, SaaS- und private Anwendungen organisiert.
• Dimension 2 – Richtlinien-Scoping und Wiederverwendung: Konfigurationsprofilbasierter Ansatz, bei dem Zugriffsregelwerke, Inspektionsprofile und engine-spezifische Sicherheitsobjekte in wiederverwendbaren Richtlinieneinheiten gebündelt und auf logische Standorte angewendet werden.

Innerhalb dieser Struktur:

• Jede Regel wertet umfangreiche Übereinstimmungsbedingungen aus (Netzwerkattribute, URL und Anwendungskontext, Benutzeridentität, Reputationssignale).
• Zuerst wird eine Entscheidung auf Sitzungsebene getroffen, ob die Daten zugelassen oder abgelehnt werden.
• Die Prüfung auf Datenebene wird nur dann durchgeführt, wenn die Sitzung erlaubt ist. Dies gewährleistet eine vorhersehbare Durchsetzung und eine effiziente Nutzung von Deep Inspection Engines.
• Die Inspektionsabsicht ist explizit, und zwar über Inspektionsprofile, die mit den Regeln verknüpft sind – und nicht über versteckte Regelketten.

Durch die Kombination von zielorientierter Regelorganisation mit konfigurationsprofilbasiertem Scoping vermeidet AI>Secure beide Extreme:

Fragmentierung über motorenspezifische Regelbasen

Ausbreitung und Explosionsradius einer einzigen globalen Regeltabelle

Warum diese Architektur jetzt wichtig ist

Der Aufstieg von SaaS, privaten Anwendungen und GenAI-gesteuerten Arbeitsabläufen hat die Sicherheitsanforderungen grundlegend verändert:

• Entscheidungen hängen von einem reichhaltigen Kontext ab
• Inspektion ist teuer und muss gewollt sein
• Viele Sicherheits-Engines
• Richtlinien müssen über Standorte, Benutzer und Arbeitslasten hinweg skalierbar sein

Die Regelarchitektur musste sich entsprechend weiterentwickeln.

Die Zukunft der Gestaltung von Sicherheitsrichtlinien liegt nicht in mehr Regeln oder intelligenteren Engines. Es geht um eine klare Trennung der Belange, eine eindeutige Absicht und Architekturen, die skalierbar sind, ohne unter ihrer eigenen Komplexität zusammenzubrechen.

Das ist die Richtung, in die sich die Branche bewegt – und die architektonische Grundlage, auf der AI>Secure aufgebaut ist.