Grundschutz++ Architektur: die Praktik ARCH erklärt
Grundschutz++ Architektur: was die Praktik ARCH zu Netzsegmenten, Netzplan, Firewall, WLAN und Ausfallsicherheit verlangt und wie kleine Netze sinnvoll starten.
Die Grundschutz++ Architektur legt fest, wie Ihr Netz aufgebaut sein sollte, damit ein einzelner Fehler oder ein infizierter Rechner nicht gleich den ganzen Betrieb trifft. Die Praktik «Architektur» (Kürzel ARCH) im neuen IT-Grundschutz des BSI beschreibt die Grundstruktur der IT: welche Netzbereiche es gibt, welche Verbindungen erlaubt sind und wie das Netz nach außen geschützt wird.
Warum das wichtig ist
In vielen kleinen Betrieben hängen Büro-PCs, Server, Drucker, Kameras und das Gäste-WLAN im selben Netz. Gelangt ein Angreifer an einer Stelle hinein, erreicht er von dort alles. Ein gut aufgeteiltes Netz bremst Angriffe, erleichtert die Überwachung und hält Störungen auf einen Bereich begrenzt.
Was verbindlich ist
Verpflichtend ist, dass es festgelegte Regeln zur Architektur des Netzes gibt und dass diese aufgeschrieben, Zuständigen zugewiesen, bekannt gemacht und regelmäßig überprüft werden. Empfohlen sind unter anderem ein Netzplan, getrennte Netzbereiche für Gäste, Server, Drucker und Verwaltung, ein abgesicherter Übergang ins Internet und ein verschlüsseltes WLAN.
Der erste Schritt
Lassen Sie sich von Ihrer IT oder Ihrem Dienstleister einen aktuellen Netzplan zeigen. Fehlt er, ist das der erste Auftrag. Fragen Sie danach gezielt: Ist das Gäste-WLAN vom Firmennetz getrennt? Können Drucker und Kameras auf die Server zugreifen?
Die Praktik «Architektur» (ARCH) ist im Anwenderkatalog Grundschutz++ für die Struktur und die Sicherheitsprinzipien der IT-Infrastruktur zuständig. Der folgende Überblick zur Grundschutz++ Architektur beruht auf dem Katalogstand vom 22. Oktober 2026.
Ziel der Praktik
Der Katalog beschreibt ARCH so: Die Praktik «definiert die grundlegende Struktur sowie die Sicherheitsprinzipien der IT-Infrastruktur und leitet daraus Anforderungen für einzelne IT-Komponenten ab». Ziel ist eine sichere und skalierbare Basis. Genannt werden die Gestaltung der Netzarchitektur und übergreifende Konzepte, beispielsweise für Kryptografie oder den Schutz vor Schadsoftware.
Die Anforderungen selbst sind im aktuellen Katalogstand fast ausschließlich netzbezogen. Bereits die erste MUSS-Anforderung spricht von der «Architektur des Netzes und damit verbundener Infrastrukturen».
Aufbau: neun Gruppen, 63 Anforderungen
| Gruppe | Inhalt |
|---|---|
| ARCH.1 Grundlagen | Verfahren und Regelungen zur Netzarchitektur, Zuständigkeiten, Überprüfung |
| ARCH.2 Netzdesign | Netzsegmente, Einschränkung von Verbindungen (extern, Gäste, Server/Clients, OT, Test, Drucker), DMZ, Management-Netz, Inventar der Netze, Netzplan, Topologieüberwachung |
| ARCH.3 Wireless LAN | Netzabdeckung, eigene SSIDs, verschlüsselte Anbindung |
| ARCH.4 Zugangsbeschränkungen | Netzzugangskontrolle, autorisiertes Routing, Authentifizierung von Routingprotokollen |
| ARCH.5 Perimeterschutz | Filterung und Inspektion am Übergang, Blockieren anfälliger Protokolle, Split Tunneling, DNS- und Webfilter, P-A-P-Struktur |
| ARCH.6 Weitverkehrsnetz | Verschlüsselung von WAN-Verbindungen, kontrollierte Verbindungsführung |
| ARCH.7 Dedizierte Systeme | dedizierte Hostsysteme für Server, Test- und Entwicklungsumgebungen getrennt vom Betrieb |
| ARCH.8 Ausfallsicherheit | Redundanz im Kernnetz, redundante TK-Anbindung und Server |
| ARCH.9 Kapazitätsmanagement | Dimensionierung der Netzanbindung, Lastverteilung, Skalierung, CDN, DoS-Schutz |
Die verbindlichen MUSS-Anforderungen
ARCH.1.1 «Architektur MUSS Verfahren und Regelungen zur Architektur des Netzes und damit verbundener Infrastrukturen verankern.»
ARCH.1.1.1 «Architektur MUSS die Verfahren und Regelungen dokumentieren.»
ARCH.1.1.2 «Architektur MUSS die mit den Verfahren und Regelungen verbundenen Aufgaben zuständigen Personen oder Rollen zuweisen.»
ARCH.1.1.3 «Architektur MUSS die zuständigen Personen oder Rollen über die Verfahren und Regelungen informieren.»
ARCH.1.2 «Architektur MUSS die Verfahren und Regelungen regelmäßig und anlassbezogen auf Aktualität überprüfen.»
Weitere MUSS-Anforderungen enthält ARCH nicht. Die technischen Vorgaben sind als SOLLTE oder KANN formuliert.
Wichtige SOLLTE-Anforderungen
SOLLTE heißt nach der BSI-Definition, dass eine Anforderung normalerweise erfüllt werden muss und Abweichungen sorgfältig abzuwägen und stichhaltig zu begründen sind.
ARCH.2.1 «Architektur für Netze SOLLTE eine Unterteilung des internen Netzes in Netzsegmente unter Berücksichtigung der Anforderungen der Institution und des Schutzbedarfes verankern.»
ARCH.2.2 «Architektur für Netze SOLLTE Verbindungen zwischen Netzsegmenten anhand von Kriterien einschränken.»
ARCH.2.2.2 «Architektur für Netze SOLLTE Verbindungen zwischen Gastnetz und internem Netz einschränken.»
ARCH.2.2.3 «Architektur für Netze SOLLTE Verbindungen zwischen Hostsystemen und Clients einschränken.»
ARCH.2.4 «Architektur SOLLTE ein Inventar der Netze einschließlich interner Segmente, externer Netzanschlüsse und deren Verwendungszweck dokumentieren.»
ARCH.2.5 «Architektur für Netze SOLLTE einen Netzplan dokumentieren.»
ARCH.3.4 «Architektur für WLANs SOLLTE die Netzanbindung nach einem anerkannten Standard verschlüsseln.»
ARCH.5.2 «Architektur für IT-Systeme SOLLTE direkte Verbindungen von diesen ins öffentliche Netz blockieren.»
ARCH.5.1.11 «Architektur für Externe Netzanschlüsse SOLLTE eine P-A-P-Struktur für eingehende und ausgehende Verbindungen installieren.»
Weitere Segmentierungsvorgaben der Standard-Stufe betreffen OT-Systeme (ARCH.2.2.5), eine demilitarisierte Zone (ARCH.2.2.6), Management-Netze (ARCH.2.2.7), die Trennung von Test und Betrieb (ARCH.2.2.8), IPv4 und IPv6 (ARCH.2.2.9) sowie Drucker (ARCH.2.2.10).
Normale und erhöhte Sicherheitsstufe
47 Anforderungen gehören zur Standard-Sicherheitsstufe «normal-SdT» (5 MUSS, 42 SOLLTE), 16 zur Stufe «erhöht», alle als KANN formuliert und damit nach BSI je nach Situation, also nach Risikoanalyse, umzusetzen.
Zur erhöhten Stufe gehören unter anderem Mikrosegmentierung (ARCH.2.3), ein eigenes VoIP-Netz (ARCH.2.2.4), physische Segmentierung (ARCH.2.2.11), Sprungserver (ARCH.2.2.12), Quarantäne bei der Netzzugangskontrolle (ARCH.4.1.2), Produktdiversität am Perimeter (ARCH.5.1.13), redundante TK-Anbindung und Server (ARCH.8.2, ARCH.8.3) sowie Schutz gegen volumetrische DoS-Angriffe (ARCH.9.5).
Typische Nachweise
- Netzplan (20 Anforderungen): Segmente, erlaubte Verbindungen, Inventar der Netze, WLAN-Struktur
- Konfigurationshistorie (17): umgesetzte Einstellungen, etwa WLAN-Verschlüsselung, Redundanz, WAN-Verschlüsselung
- Firewallregeln (15): Filterung am Perimeter und zwischen Systemen
- IT-Betriebskonzept (8): Regelungen und übergreifende Festlegungen
Betroffene Zielobjekte
Am häufigsten genannt sind «Netze» (26 Anforderungen) und «Externe Netzanschlüsse» (14). Hinzu kommen Anwendungen, WLANs, interne Netzsegmente, IT-Systeme, Hostsysteme und Virtualisierungslösungen. Für die Strukturmodellierung bedeutet das: Netze und Netzanschlüsse sollten als eigene Zielobjekte erfasst sein, nicht nur die Geräte.
Bezug zum bisherigen IT-Grundschutz
Im Kompendium 2023 lagen diese Themen in der Schicht NET, vor allem in NET.1.1 Netzarchitektur und -design, NET.3.1 Router und Switches und NET.3.2 Firewall. Der Mapping-Entwurf des BSI ordnet diesen Bausteinen die meisten Bezüge zur Praktik ARCH zu.
Grundschutz++ Architektur im kleinen Netz
- Netzplan erstellen: eine Zeichnung mit Internetanschluss, Firewall oder Router, Switches, WLAN, Servern, Clients, Druckern und Cloud-Anbindungen. Ergänzt um eine Tabelle der Netze mit Zweck, das deckt ARCH.2.4 und ARCH.2.5 ab.
- Mit wenigen Segmenten beginnen: Gäste, Clients, Server, Drucker und Geräte wie Kameras oder Telefonanlage. Viele Business-Router und Firewalls unterstützen VLANs.
- Verbindungen beschränken: zwischen den Segmenten nur das erlauben, was gebraucht wird, und das in den Firewallregeln dokumentieren.
- Server nicht direkt ins Internet: ausgehende Verbindungen von Servern beschränken (ARCH.5.2), erreichbare Dienste in eine DMZ oder zu einem Dienstleister auslagern.
- Verwaltungszugänge schützen: Management-Oberflächen nicht aus dem Internet erreichbar machen (ARCH.5.1.6).
- WLAN prüfen: eigene SSIDs, aktuelle Verschlüsselung, Gäste getrennt.
Die P-A-P-Struktur aus ARCH.5.1.11 ist eine SOLLTE-Anforderung der Standard-Stufe und für kleine Netze ein vergleichsweise großer Schritt. Wenn Sie davon abweichen, halten Sie Abwägung und Begründung fest, wie es die SOLLTE-Definition verlangt.
Häufige Fragen
Muss ein kleines Netz wirklich in Segmente aufgeteilt werden?
ARCH.2.1 empfiehlt die Unterteilung als SOLLTE, und zwar unter Berücksichtigung der Anforderungen der Institution und des Schutzbedarfs. Wie fein Sie segmentieren, entscheiden Sie also selbst. Eine Trennung von Gästen, Clients, Servern und Geräten ist ein häufiger Ausgangspunkt.
Was ist eine P-A-P-Struktur?
P-A-P steht für Paketfilter, Application-Level-Gateway, Paketfilter, also eine mehrstufige Absicherung des Netzübergangs. ARCH.5.1.11 empfiehlt sie als SOLLTE für eingehende und ausgehende Verbindungen.
Gehört Kryptografie auch zur Praktik Architektur?
Die Beschreibung der Praktik nennt übergreifende Konzepte für Kryptografie und Schadsoftware-Schutz. Im aktuellen Katalogstand stehen konkrete Anforderungen dazu aber vor allem in den Praktiken Berechtigung (Schlüsselmanagement) und Konfiguration.
Welche Unterlagen erwartet ein Prüfer bei ARCH?
Laut Katalog vor allem den Netzplan, die Firewallregeln, die Konfigurationshistorie und das IT-Betriebskonzept mit den Regelungen zur Netzarchitektur.