¶ Netz- und Informationssysteme
Geschützte Detailarchitektur: Diese öffentliche Musterseite enthält keine realen Netzpläne, IP-Adressen, Hostnamen, Filterregeln, Zugangsdaten, Schwachstellen oder Notfallzugänge. Sie zeigt Methodik, Registerfelder und Entscheidungslogik. Operative Architekturen und Konfigurationen bleiben in einer angemessen geschützten Ablage. Beispielampeln belegen weder Umsetzung noch Wirksamkeit.
¶ Dokumenteninformationen
| Feld | Wert |
|---|---|
| Dokumenten-ID | NIS2-REG-03-04 |
| Dokumentenart | Register-, Architektur- und Betriebssteuerung für Netz- und Informationssysteme |
| Wiki.js-Pfad | /NIS2/03-Assets-Prozesse-und-Dienste/Netz-und-Informationssysteme |
| Verantwortlich | System-/Service-Owner, Netzwerkverantwortung und Informationssicherheitsfunktion |
| Mitwirkende | Enterprise-/Lösungsarchitektur, IT-/OT-Betrieb, Cloud, IAM, BCM, Datenschutz, Einkauf und Lieferantenmanagement |
| Status | Entwurf – keine reale Architektur dokumentiert, freigegeben oder geprüft |
| Version / Stand | 0.3 / 09.08.2026 |
| Schutzklasse | Methodik intern; logische Architektur vertraulich; technische Detailarchitektur streng zugriffsgeregelt |
| Review | mindestens jährlich sowie bei wesentlichen Änderungen, Vorfällen oder neuen Risiken |
Architektur, Schnittstellen, Sicherheitszonen und Betriebsverantwortung dienstbezogen steuern. Eigene redaktionelle SVG-Grafik. Zum Vergrößern in einem neuen Tab öffnen.
¶ 1. Steuerungscockpit
■ Kritische Systeme ohne Owner
—
keine Echtdaten im Muster-Wiki
—
keine Echtdaten im Muster-Wiki
▲ Ungeklärte externe Verbindungen
—
keine Echtdaten im Muster-Wiki
—
keine Echtdaten im Muster-Wiki
● Segmentierungs- und Monitoringlücken
—
keine Echtdaten im Muster-Wiki
—
keine Echtdaten im Muster-Wiki
? Supportende ohne Entscheidung
—
keine Echtdaten im Muster-Wiki
—
keine Echtdaten im Muster-Wiki
Ein fehlender Wert wird als „— / nicht ermittelt“ dargestellt und niemals als null offene Punkte interpretiert. Das Cockpit wird nur aus freigegebenen Registern und definierten Abfragen gespeist.
¶ 2. Zweck und Nutzen
Die Seite verbindet den gesetzlichen Dienstescope mit der technischen Realität. Sie soll nachvollziehbar beantworten:
- welche Netz- und Informationssysteme einen relevanten Dienst tatsächlich tragen,
- wo System-, Verantwortungs- und Vertrauensgrenzen verlaufen,
- welche Kommunikation zwischen Zonen, Systemen und Dritten erforderlich ist,
- wie Benutzer-, Administrations-, Überwachungs- und Wiederherstellungswege getrennt werden,
- welche Basisdienste mehrere kritische Leistungen gleichzeitig beeinflussen,
- welche Sicherheits-, Betriebs- und Lebenszyklusanforderungen je Objekt gelten und
- ob Architektur, Betrieb, Notbetrieb und Nachweise konsistent sowie aktuell sind.
Sie ist kein öffentlicher Netzplan. Die sichtbare Ebene unterstützt Governance, Audit und Managemententscheidungen; technische Detaildaten bleiben geschützt.
¶ 3. Rechtlicher und fachlicher Bezug
| Bezug | Bedeutung für die Arbeitsseite |
|---|---|
| § 30 Abs. 1 BSIG | Störungen der Verfügbarkeit, Integrität und Vertraulichkeit der für Dienste genutzten Systeme, Komponenten und Prozesse sollen durch geeignete, verhältnismäßige und wirksame Maßnahmen vermieden beziehungsweise ihre Auswirkungen minimiert werden. |
| § 30 Abs. 2 BSIG | Der gefahrenübergreifende Ansatz umfasst unter anderem Risikoanalyse, Vorfallbewältigung, Betriebskontinuität, Lieferkette, sichere Beschaffung/Entwicklung/Wartung, Wirksamkeitsprüfung, Kryptografie, Zugriffskontrolle und gesicherte Kommunikation. |
| DVO (EU) 2024/2690 | Für die erfassten digitalen Einrichtungsarten konkretisiert sie unter anderem verständliche und aktuelle Netzarchitektur, unnötige Kommunikation, Fernzugriff, Netzsegmentierung, getrennte Administration und regelmäßige Reviews. |
| BSI IT-Grundschutz NET.1.1 | bietet fachliche Orientierung für Netzarchitektur, Zonierung, Segmentierung, zulässige Kommunikationsbeziehungen und getrennte Administrations-/Überwachungswege. |
Die Durchführungsverordnung (EU) 2024/2690 gilt nicht automatisch für jede NIS2-Einrichtung. Der Vorrang nach § 30 Abs. 3 BSIG betrifft die dort genannten digitalen Einrichtungsarten. Für andere Organisationen kann sie als konkretisierende Orientierung dienen, sofern keine widersprechenden oder spezielleren Anforderungen gelten.
¶ 4. Was als Netz- und Informationssystem betrachtet wird
| Objektgruppe | Beispiele | nicht übersehen |
|---|---|---|
| Anwendungen und Plattformen | Fachanwendung, Datenbank, Middleware, Verzeichnisdienst | Control Plane, Mandanten- und Plattformabhängigkeit |
| Netze und Kommunikation | LAN, WAN, WLAN, VPN, Internet, Mobilfunk, SD-WAN | Routing, DNS, Proxy, Zertifikate und Leitungswege |
| Endpunkte und Server | Clients, mobile Geräte, Server, virtuelle Instanzen | Managementagenten, Images, Boot- und Recoverypfade |
| Cloud- und SaaS-Systeme | IaaS, PaaS, SaaS, Identitäts- und Sicherheitsdienste | Region, Unterauftragnehmer, APIs, Support- und Notzugänge |
| OT, IoT und Gebäudetechnik | Steuerungen, Maschinen, Sensoren, Zutritt, Klima, Energie | Fernwartung, proprietäre Protokolle, lange Lebenszyklen |
| Sicherheits- und Managementsysteme | Firewall, EDR, SIEM, Scanner, PAM, Backup | Eigenabhängigkeiten, Ausfall und Manipulationsschutz |
| Identitäten und Kryptografie | IdP, MFA, PKI, Schlüssel- und Geheimnisverwaltung | Break-Glass, Zertifikatslaufzeiten, Vertrauensanker |
| Betrieb und Wiederanlauf | Monitoring, Ticketing, Automatisierung, Repository, Recoveryumgebung | getrennte Kommunikation und Offline-/Notfallzugriff |
| externe technische Leistung | MSP, MSSP, Rechenzentrum, Telekommunikation, Wartung | Providerzugang, Servicegrenze, Exit und Nachweise |
Entscheidend ist nicht Eigentum, sondern der Beitrag zur Diensterbringung. Auch gemietete, eingebettete, gemeinsam genutzte oder vollständig extern betriebene Systeme können zum Scope gehören.
¶ 5. System-of-Record und Registerbeziehungen
| führende Quelle | führt | verweist auf |
|---|---|---|
| Diensteregister | Dienst, Empfänger, Owner und Scope | Prozesse, Systeme und Lieferanten |
| Asset-/Systeminventar | Identität, Typ, Owner, Standort, Lebenszyklus | Dienst, Schutzbedarf, Schwachstellen |
| Architekturregister | Komponenten, Zonen, Vertrauens- und Betriebsgrenzen | System-IDs, Diagrammversion und Entscheidungen |
| Kommunikationsregister | Quelle, Ziel, Zweck, Richtung, Freigabe und Review | Zone, System, Datenfluss und Filterreferenz |
| Berechtigungsregister | Rollen, privilegierte Rechte, technische Konten | System, Owner, Rezertifizierung |
| Lieferanten-/Cloud-Register | Anbieter, Dienst, Unterauftragnehmer, Region und Exit | Vertrag, System, Zugriff und Nachweis |
| Risiko-/Maßnahmenregister | Szenario, Bewertung, Behandlung und Restrisiko | System, Dienst, Kontrolle und Entscheidung |
| Nachweisregister | Nachweisbedarf, Scope, Zeitraum, Ergebnis und Ablage | Kontrolle, Test, Owner und Review |
Redundante Listen werden vermieden. Jede Seite zeigt die für ihre Steuerung erforderliche Sicht, verwendet aber dieselben stabilen IDs.
¶ 6. Rollen und Entscheidungskompetenz
| Rolle | Verantwortlicher Beitrag | darf nicht allein freigeben |
|---|---|---|
| Geschäftsleitung/IT-Leitung | Architekturprinzipien, Ressourcen, wesentliche Risiken und Ausnahmen | technische Detailkonfiguration ohne Fachprüfung |
| Architekturverantwortung | Zielarchitektur, Systemgrenzen, Zonen und Architekturentscheidungen | operative Wirksamkeit ohne Test |
| Netzwerkverantwortung | Segmente, Verbindungen, Filterung, Kapazität und Netzmonitoring | fachliche Notwendigkeit einer Datenbeziehung |
| System-/Service-Owner | Dienstebezug, Betrieb, Lebenszyklus, Wiederherstellung und Nachweise | Risikoakzeptanz außerhalb seiner Befugnis |
| IAM-/PAM-Verantwortung | Identitäten, privilegierte Zugänge, Notkonten und Rezertifizierung | unbefristeten externen Zugriff ohne Dienst-Owner |
| IT-/OT-/Cloud-Betrieb | Konfiguration, Wartung, Protokollierung, Störung und technische Dokumentation | eigene Ausnahme ohne unabhängige Genehmigung |
| Informationssicherheit | Risiko-, Bedrohungs-, Kontroll- und Wirksamkeitsprüfung | Geschäftsentscheidung zum Restrisiko |
| Einkauf/Lieferantenmanagement | Providerzugänge, Servicegrenzen, Nachweise, Vertrag und Exit | technische Eignung ohne Owner |
| Change-/Projektverantwortung | Auswirkungsprüfung, Test, Rollback, Abnahme und Dokumentationsupdate | Notfallfreigabe ohne definierten Prozess |
| Audit/Compliance | Nachvollziehbarkeit, Aktualität, Stichproben und Abweichung | operative Selbstprüfung als alleiniger Nachweis |
¶ 7. Architektur- und Dokumentationsebenen
| Ebene | Inhalt | Zielgruppe | typische Schutzklasse |
|---|---|---|---|
| Dienstsicht | relevante Leistungen, Hauptsysteme und externe Abhängigkeiten | Management, Audit, Fachbereich | intern |
| logische Architektur | Zonen, Vertrauensgrenzen, Hauptflüsse und Betriebsgrenzen | Architektur, Sicherheit, Betrieb | vertraulich |
| technische Architektur | Komponenten, Cluster, Schnittstellen, Leitungs- und Failoverdetails | berechtigte Technikrollen | vertraulich bis streng geschützt |
| Konfigurationsbasis | Sollwerte, Härtung, Regeln, Automatisierung und Ausnahmen | Betrieb und Kontrolle | streng zugriffsgeregelt |
| Betriebsdokumentation | Monitoring, Wartung, Störung, Backup und Bereitschaft | Betrieb, Incident, BCM | rollenbezogen geschützt |
| Wiederanlaufdokumentation | Reihenfolge, Notzugänge, Schlüssel, Ersatzwege und Rückkehr | befugte Notfallrollen | besonders geschützt |
Die Dokumentation ist so detailliert wie für Entscheidung, Betrieb und Wiederherstellung erforderlich, aber nur für den jeweiligen Empfängerkreis sichtbar.
¶ 8. Visuelle Referenzarchitektur
1 · Externe/Internet
Kunden, Partner, Provider, Angriffsfläche
Kunden, Partner, Provider, Angriffsfläche
2 · Übergang/DMZ
Proxy, Gateway, veröffentlichte Dienste
Proxy, Gateway, veröffentlichte Dienste
3 · Dienst/Produktion
Anwendungen, Daten, OT, Cloud-Workloads
Anwendungen, Daten, OT, Cloud-Workloads
4 · Management
Administration, PAM, Konfiguration
Administration, PAM, Konfiguration
5 · Schutz/Recovery
Logging, EDR, Backup, Notfallwege
Logging, EDR, Backup, Notfallwege
Die Nummerierung ist eine Leserichtung, kein Netzplan und keine pauschale Sollarchitektur. Tatsächliche Zonen, Übergänge und Kommunikationsbeziehungen folgen Dienst, Risiko, Schutzbedarf, Funktion und technischer Machbarkeit. Jeder Übergang benötigt eine kontrollierte Beziehung; direkte Abkürzungen werden als Ausnahme sichtbar.
¶ 9. Zonen- und Segmentkatalog
| Zone/Segment | Zweck | typische Systeme | besonderes Prüfthema |
|---|---|---|---|
| Benutzer | reguläre Arbeitsmittel und Benutzerzugriffe | Clients, VDI, Druck, Kollaboration | seitliche Bewegung, Gerätezustand |
| Server/Produktion | produktive Fach- und Plattformdienste | Anwendungen, Datenbanken, Middleware | Schutzbedarf, Ost-West-Kommunikation |
| DMZ/Übergang | kontrollierte Kommunikation nach außen | Reverse Proxy, Mail-/API-Gateway | minimale Freigaben, Härtung, Monitoring |
| Administration | privilegierte Verwaltung | Jump Host, PAM, Managementtools | getrennte Identität, Zweckbindung |
| Security/Monitoring | Erkennung und Sicherheitssteuerung | SIEM, Scanner, EDR-Management | Integrität, Verfügbarkeit, Rückkanäle |
| Backup/Recovery | Sicherung und Wiederherstellung | Backupserver, Repository, Recoverytools | Isolation, Unveränderbarkeit, Notzugriff |
| Entwicklung/Test | Entwicklung, Qualitätssicherung und Testdaten | CI/CD, Testsysteme, Repositories | Trennung von Produktion, Geheimnisse |
| OT/Produktion | industrielle oder sicherheitsrelevante Steuerung | SPS, HMI, Engineering, Sensorik | Verfügbarkeit, Safety, Legacy, Fernwartung |
| Gäste/unkontrollierte Geräte | begrenzter Zugang ohne internes Vertrauen | Gäste-WLAN, Fremdgeräte | konsequente Trennung und Internetzugang |
| Partner/Dritte | definierte B2B- oder Servicebeziehungen | Extranet, Site-to-Site, Anbieterzugang | Vertrag, Scope, zeitliche Begrenzung |
| Cloud/Mandant | extern betriebene Plattformen und Dienste | IaaS, PaaS, SaaS | Shared Responsibility, Control Plane |
Zonenbezeichnungen dürfen organisationsspezifisch abweichen. Entscheidend sind eindeutiger Zweck, Owner, Schutzanforderung, erlaubte Beziehungen, technische Durchsetzung und regelmäßige Prüfung.
¶ 10. Kommunikations- und Freigabematrix
| Feld | Mindestinhalt | Qualitätsmerkmal |
|---|---|---|
| Verbindungs-ID | stabile Referenz | mit Change und Regelwerk verknüpft |
| Quelle/Ziel | System- und Zonen-ID | keine Sammelbegriffe ohne Grenze |
| fachlicher Zweck | benötigte Dienstfunktion | vom Dienst-/System-Owner bestätigt |
| Richtung/Initiator | ein- oder beidseitig | technisch korrekt beschrieben |
| Protokoll-/Portklasse | erforderliche Kommunikation | keine unnötigen Bereiche oder „any“ |
| Identität/Authentisierung | Mensch, System, Zertifikat, Schlüssel | eindeutige Vertrauensbasis |
| Schutz | Verschlüsselung, Integrität, Filterung | Schutzbedarf und Risiko angemessen |
| Betriebszeit | dauerhaft, zeitgesteuert oder ereignisbezogen | minimal erforderliche Dauer |
| Protokollierung/Alarm | Quelle, Ereignis, Schwelle und Empfänger | auswertbar und getestet |
| Abschaltung/Notfall | Kill-Switch, Owner und Rückfall | praktisch erreichbar |
| Freigabe/Review | Genehmigende, Datum, Ablauf und Ergebnis | überfällige Beziehung wird sichtbar |
¶ Beispielhafte Zonenmatrix
| von \ nach | Benutzer | Produktion | Administration | Backup | Internet/Dritte |
|---|---|---|---|---|---|
| Benutzer | ! PRÜFEN | ◆ DIENST | × SPERREN | × SPERREN | ◆ KONTROLLE |
| Produktion | ○ BEGRÜNDEN | ! TRENNEN | × SPERREN | ◆ BACKUP | ▲ AUSNAHME |
| Administration | × TRENNEN | ◆ VERWALTEN | ! INTERN | ◆ BACKUP | × AUSNAHME |
| Dritte | × SPERREN | ▲ BEFRISTET | ▲ GATEWAY | × SPERREN | ○ EXTERN |
Legende: × sperren/trennen · ▲ nur als genehmigte Ausnahme oder befristeter Übergang · ! gesondert prüfen/begrenzen · ◆ definierte kontrollierte Beziehung · ○ Kontext außerhalb der konkreten Matrix oder noch zu begründen.
Die Matrix ist ein Prinzipienmuster, keine freigegebene Firewallregel. Jede reale Beziehung benötigt eine fachliche und technische Einzelprüfung.
¶ 11. Vertrauensgrenzen und erlaubte Kommunikation
Eine Vertrauensgrenze entsteht nicht nur am Internet. Sie kann zwischen Mandanten, Standorten, Sicherheitsklassen, Benutzer- und Verwaltungswegen, IT und OT, intern und extern betriebenen Komponenten oder verschiedenen Verantwortungsbereichen liegen.
| Grundsatz | Steuerungsfolge |
|---|---|
| „deny by default“ | nur nachgewiesene, erforderliche Kommunikation zulassen |
| geringstes Vertrauen | Quelle, Gerät, Identität und Kontext prüfen |
| lokale Kommunikation | unnötige Zonenwechsel vermeiden |
| Zweckbindung | Verbindung nur für dokumentierte Dienstfunktion |
| geringe Angriffsfläche | unnötige Dienste, Protokolle und Richtungen deaktivieren |
| zeitliche Begrenzung | Wartungs- und Drittzugänge nur im benötigten Fenster |
| Nachvollziehbarkeit | Freigabe, technische Regel, Protokoll und Review verknüpfen |
| sichere Abschaltung | kompromittierte Beziehung ohne unkontrollierte Nebenwirkung trennbar |
¶ 12. Administrative und privilegierte Pfade
1 · persönliche Anmeldung
starke Authentisierung und Gerätezustand
starke Authentisierung und Gerätezustand
2 · privilegierte Identität
getrennt, befristet und rezertifiziert
getrennt, befristet und rezertifiziert
3 · kontrollierter Übergang
PAM, Jump Host oder Managementzone
PAM, Jump Host oder Managementzone
4 · Zielsystem
minimaler Scope und nachvollziehbare Sitzung
minimaler Scope und nachvollziehbare Sitzung
| Prüffeld | Mindeststeuerung |
|---|---|
| Identität | persönliche und administrative Identitäten getrennt; technische Konten eindeutig verantwortet |
| Authentisierung | starke beziehungsweise mehrstufige Authentisierung nach Risiko; sichere Wiederherstellung |
| Gerät | autorisiertes, gehärtetes und überwachtes Administrationsgerät |
| Übergang | kontrollierter Sprung-/PAM-/Managementweg statt direkte Administration aus Benutzerzonen |
| Berechtigung | geringster Umfang, Genehmigung, Befristung und Funktionstrennung |
| Sitzung | Protokollierung, Alarmierung und risikobasierte Sitzungsüberwachung |
| Notfall | Break-Glass-Zugang getrennt geschützt, getestet und nach Nutzung überprüft |
| Entzug | unverzüglich bei Rollenwechsel, Austritt, Anbieterwechsel oder Verdacht |
¶ 13. Fernzugriff und Zugänge Dritter
| Phase | Prüfpunkte | Nachweis |
|---|---|---|
| Bedarf | Dienst, Ziel, Tätigkeit, Person/Organisation, Zeitfenster | genehmigter Auftrag |
| Einrichtung | eindeutige Identität, MFA, autorisiertes Gerät, minimaler Netzpfad | technische Freigabe |
| Nutzung | Aktivierung erst bei Bedarf, Überwachung, Kontakt und Eskalation | Verbindungs-/Sitzungsnachweis |
| Ende | automatische/operative Deaktivierung und Zugriffsprüfung | Abschaltbestätigung |
| Review | Notwendigkeit, Umfang, Auffälligkeiten, Vertrag und Unterauftragnehmer | Rezertifizierung |
Unbeaufsichtigte Dauerzugänge, gemeinsam genutzte Anbieterkennungen, unklare Fernwartungsgeräte und nicht abschaltbare Verbindungen werden priorisiert behandelt.
¶ 14. Identitäts- und Basisdienste
| Basisdienst | Abhängigkeit | Ausfall-/Manipulationswirkung | notwendige Vorsorge |
|---|---|---|---|
| Identitätsdienst/IdP | Anmeldung und Autorisierung | Benutzer und Administration blockiert oder übernommen | Redundanz, Notzugriff, Monitoring |
| DNS | Namensauflösung und Dienstfindung | Dienste scheinbar ausgefallen oder umgeleitet | sichere Konfiguration, Redundanz, Protokollierung |
| Zeit/NTP | Protokolle, Authentisierung, Zertifikate | falsche Korrelation, Token-/Zertifikatsfehler | vertrauenswürdige Quellen, Alarmierung |
| PKI/Zertifikate | TLS, Geräte- und Systemidentität | Verbindungsabbruch oder Vertrauensmissbrauch | Laufzeit-, Schlüssel- und Sperrmanagement |
| Schlüssel/Secrets | Zugriff, Verschlüsselung und Automatisierung | Datenverlust oder unbefugter Zugriff | getrennte Verwaltung, Rotation, Recovery |
| Routing/SD-WAN | Erreichbarkeit und Pfadwahl | großflächige Unterbrechung oder Umleitung | sichere Administration, Fallback, Überwachung |
| Konfigurations-/Code-Repository | Wiederaufbau und Änderung | falsche oder fehlende Sollkonfiguration | Integrität, Backup, getrennte Freigabe |
| Monitoring/Ticketing | Erkennung und Koordination | Blindflug und verzögerte Reaktion | unabhängige Überwachung/Notkommunikation |
Basisdienste werden nicht wegen geringer Benutzerzahl als unkritisch eingestuft. Ihre Kaskadenwirkung kann deutlich größer sein als die eines sichtbaren Fachsystems.
¶ 15. Sichere Konfiguration und Härtung
| Baustein | Sollzustand | Abweichungsregel |
|---|---|---|
| Baseline | versioniert, freigegeben und für Plattform/Rolle geeignet | Grund, Risiko, Kompensation, Owner, Ablauf |
| unnötige Funktionen | deaktiviert oder entfernt | fachliche Notwendigkeit belegen |
| Standardkonten/-kennwörter | geändert, deaktiviert oder geschützt | technische Ausnahme überwachen |
| Protokolle/Kryptografie | freigegebene sichere Varianten | Migration und befristete Kompensation |
| Managementschnittstellen | nur über definierte Verwaltungswege | direkte Zugriffe als Ausnahme |
| Protokollierung | relevante Ereignisse mit Zeit, Identität und Kontext | Lücke mit Risiko und Termin |
| Integrität | signierte/prüfbare Software, Konfiguration und Images | Herkunft und Ausnahme dokumentieren |
| Zeit/Zeitzone | synchronisiert und konsistent | Alarm bei Abweichung |
| lokale Firewall/Schutzsoftware | rolle- und risikogerecht | technische Einschränkung behandeln |
| Konfigurationsprüfung | automatisiert und/oder manuell gegen Soll | Scope und Aussagegrenze dokumentieren |
Ein erfolgreicher Scan bestätigt nur den geprüften Ausschnitt. Nicht geprüfte Systeme, manuelle Einstellungen, Laufzeitverhalten oder die Wirksamkeit im Angriffsszenario bleiben gesondert zu beurteilen.
¶ 16. Schwachstellen-, Patch- und Lebenszyklussteuerung
| Status | visuelle Kennzeichnung | Steuerungsfolge |
|---|---|---|
| unterstützt/aktuell | ✓ GRÜN | regulär überwachen und Nachweise aktuell halten |
| Einschränkung/Frist | ! GELB | Patch, Kompensation oder Migration terminieren |
| kritisch/nicht unterstützt | × ROT | unverzüglich bewerten, eskalieren und behandeln |
| ungeklärt | ○ GRAU | Hersteller, Version, Exposure und Owner klären |
| Prüffeld | erforderliche Verknüpfung |
|---|---|
| Hersteller/Produkt/Version | eindeutige Asset- und Softwareidentität |
| Exposition | intern, extern, privilegiert, OT oder Lieferantenzugriff |
| Dienstekritikalität | Auswirkung und Behandlungspriorität |
| Schwachstelle | Quelle, Ausnutzbarkeit, Bedrohung und betroffene Konfiguration |
| Patchfähigkeit | Wartungsfenster, Abhängigkeit, Test und Rollback |
| Supportende | Termin, Ablöseplan, Budget und Risikoentscheidung |
| Kompensation | konkrete Kontrolle, Wirkungsannahme und Prüfung |
| Ausnahme | Befristung, Owner, Genehmigung und Review |
¶ 17. Protokollierung, Überwachung und Angriffserkennung
| Ebene | Ereignisbeispiele | erforderlicher Kontext |
|---|---|---|
| Identität | Anmeldung, MFA, Rechteänderung, Notkonto | Person/System, Quelle, Ziel, Ergebnis |
| Netzwerk | Verbindung, Blockierung, Routing-/DNS-Änderung | Zonen, Dienst, Richtung, Regelreferenz |
| System | Prozess, Dienst, Konfiguration, Integrität | Asset, Version, Benutzer, Change |
| Anwendung/API | Transaktion, Fehler, Missbrauch, Authentisierung | Dienst, Mandant, Schnittstelle, Korrelation |
| Cloud/Control Plane | Rollen, Schlüssel, Richtlinie, Ressource | Konto, Region, Identität, Anbieterereignis |
| OT/IoT | Engineeringzugriff, Konfigurations- oder Zustandsänderung | Anlage, Safety-Kontext, Bedienrolle |
| Sicherheitswerkzeug | Alarm, Sensorzustand, Signatur-/Agentenlücke | Abdeckung, Regel, Schwere, Behandlung |
¶ Von der Quelle bis zur Reaktion
| Stufe | Kontrollfrage | Qualitätsnachweis |
|---|---|---|
| 1 · erfassen | liefert die richtige Quelle die erforderlichen Ereignisse? | Testereignis und Abdeckungsmatrix |
| 2 · übertragen | sind Transport, Zeit und Integrität geschützt? | technische Konfiguration und Prüfung |
| 3 · speichern | sind Zugriff, Aufbewahrung und Datenschutz geregelt? | Berechtigung und Lösch-/Aufbewahrungskonzept |
| 4 · erkennen | existiert ein geeigneter Anwendungsfall mit Kontext? | Regel, Test und erwartetes Ergebnis |
| 5 · alarmieren | erreicht der Alarm eine handlungsfähige Rolle? | Alarmierungs- und Bereitschaftstest |
| 6 · reagieren | sind Triage, Eindämmung, Beweissicherung und Eskalation möglich? | Übung/Vorfallauswertung |
| 7 · verbessern | werden Lücken und Fehlalarme korrigiert? | Maßnahme, Nachprüfung und Trend |
Für Betreiber kritischer Anlagen können nach § 31 BSIG zusätzliche Anforderungen an Systeme zur Angriffserkennung gelten. Betreiberstatus, betroffene Anlage und technische Reichweite werden getrennt festgestellt.
¶ 18. Kapazität, Redundanz und Resilienz
| Thema | scheinbar ausreichend | belastbare Prüfung |
|---|---|---|
| redundante Komponente | zwei Geräte vorhanden | getrennte Fehlerdomäne, Konfiguration und Stromversorgung |
| zweite Leitung | anderer Vertrag | anderer physischer Weg und Vorleister |
| Cluster | automatisches Failover konfiguriert | Last-, Split-Brain- und Rückschwenktest |
| Cloud-Multi-Zone | mehrere Zonen gewählt | regionale und Control-Plane-Abhängigkeiten geprüft |
| Backup | Sicherung erfolgreich | isolierter Restore mit Daten- und Fachabnahme |
| Ersatzgerät | Hardware im Lager | kompatibel, aktuell, konfigurierbar und rechtzeitig einsetzbar |
| Notzugang | Konto vorhanden | Schlüssel verfügbar, Nutzung getestet und überwacht |
| Notkommunikation | Mobilnummernliste | Netz-/Providerkonzentration und Aktualität geprüft |
Hochverfügbarkeit ist keine Behauptung über Business Continuity. Dienst-RTO, RPO, Mindestbetriebsniveau, Datenkonsistenz, Personal, Anbieter und fachliche Abnahme werden Ende-zu-Ende getestet.
¶ 19. Cloud- und hybride Systeme
| Kontrollbereich | eigene Verantwortung | Anbieter-/Vertragsprüfung |
|---|---|---|
| Mandant/Konto | Rollen, Richtlinien, Schlüssel, Konfiguration | Plattformschutz, Support, Isolation |
| Netzpfad | private/öffentliche Endpunkte, Filter, DNS | Providerarchitektur, DDoS, Region |
| Protokollierung | Aktivierung, Export, Korrelation | verfügbare Ereignisse und Aufbewahrung |
| Resilienz | Architektur, Backup, Wiederanlauf, Exit | Zonen/Regionen, SLA, Wiederherstellung |
| Schwachstellen | Workloads, Images, Abhängigkeiten | Plattformpatching und Information |
| Vorfall | Erkennung, Triage, eigene Meldung | Benachrichtigung, Kontakte, Beweise |
| Unterauftragnehmer | Risikobewertung und Akzeptanz | Liste, Änderungen, Orte, Durchgriff |
„Cloud“ ist keine eigene Vertrauensstufe. Jede Control Plane, API, Identität, Region, Datenbeziehung und Administrationsgrenze wird konkret zugeordnet.
¶ 20. OT, IoT und eingebettete Systeme
| Besonderheit | typische Einschränkung | risikogerechte Option |
|---|---|---|
| lange Lebensdauer | Hersteller-/Supportende vor Anlagenende | Segmentierung, Monitoring, Ersatz-/Migrationsplan |
| Verfügbarkeits-/Safetybezug | Standardscan oder Neustart kann Betrieb gefährden | abgestimmte passive Erkennung und Wartungsfenster |
| proprietäre Protokolle | geringe Authentisierung/Verschlüsselung | sichere Gateways und restriktive Beziehungen |
| Fernwartung | Hersteller benötigt kurzfristigen Zugriff | befristeter, überwachter Übergang mit Freigabe |
| Altgeräte | kein Agent oder Patch möglich | technische Kompensation und Risikoentscheidung |
| Engineeringstation | hohe Privilegien und Wechselmedien | dedizierte Härtung, Kontrolle und Backup |
| physischer Zugang | direkte lokale Schnittstellen | Sicherheitsbereich, Versiegelung, Protokollierung |
Schutzmaßnahmen werden mit Betrieb, Arbeitssicherheit und Anlagensicherheit abgestimmt. Eine ungetestete Sicherheitsänderung darf keine neue gefährliche Betriebswirkung erzeugen.
¶ 21. Technischer Baustein: aufklappbare Architekturprüfung
Die Prüffelder können in Workshops einzeln geöffnet werden. Sie ersetzen kein freigegebenes Architekturreview oder technisches Prüfprotokoll.
Prüfpfad A · Scope und Systemgrenze
- Welcher relevante Dienst wird durch das System oder Netz unterstützt?
- Sind System-, Mandanten-, Standort-, Provider- und Betriebsgrenzen eindeutig?
- Sind Daten-, Benutzer-, Administrations-, Monitoring- und Recoverypfade erfasst?
- Sind gemeinsam genutzte Basisdienste und indirekte Abhängigkeiten zugeordnet?
- Stimmen Diensteregister, Assetinventar, Architektur und Datenflüsse überein?
Prüfpfad B · Zonen und Kommunikation
- Sind Zonen nach Funktion, Schutzbedarf, Exposition und Risiko gebildet?
- Ist jede Kommunikationsbeziehung fachlich notwendig, minimal und genehmigt?
- Sind Produktion, Entwicklung/Test, Administration, Backup und Dritte angemessen getrennt?
- Gibt es direkte Pfade, „any“-Regeln, temporäre Freigaben oder unbekannte Verbindungen?
- Sind Filterung, Authentisierung, Verschlüsselung, Logging, Abschaltung und Review getestet?
Prüfpfad C · Administration und externe Zugänge
- Werden privilegierte Identität, Administrationsgerät, Übergang und Ziel getrennt kontrolliert?
- Sind Anbieterzugänge persönlich, mehrstufig authentisiert, befristet und abschaltbar?
- Sind Notkonten unabhängig erreichbar, sicher verwahrt, getestet und überwacht?
- Werden Sitzungen und Rechteänderungen protokolliert und risikoorientiert ausgewertet?
- Erfolgen regelmäßige Rezertifizierung und unverzüglicher Entzug?
Prüfpfad D · Betrieb, Erkennung und Wiederherstellung
- Sind Baseline, Patchstand, Supportende, Abweichungen und sichere Änderung nachvollziehbar?
- Decken Logging und Monitoring kritische Identitäten, Übergänge und Systeme ab?
- Erreichen Testalarme die zuständige Rolle und lösen sie den vorgesehenen Prozess aus?
- Sind Kapazität, Failover, Restore, Datenkonsistenz und fachliche Abnahme praktisch getestet?
- Werden Befunde mit Risiko-, Maßnahmen-, Incident- und Nachweisregister verknüpft?
¶ 22. Datenqualität und Steuerungsampel
✓ GRÜN · belastbar
Scope, Owner, Architektur, Regeln und Nachweise aktuell und bestätigt.
Scope, Owner, Architektur, Regeln und Nachweise aktuell und bestätigt.
! GELB · eingeschränkt
Einzelne Lücken oder Annahmen mit Owner, Risiko und Termin dokumentiert.
Einzelne Lücken oder Annahmen mit Owner, Risiko und Termin dokumentiert.
× ROT · kritisch/offen
Wesentliche Grenze, Verbindung, Schutzmaßnahme oder Nachweis unzureichend.
Wesentliche Grenze, Verbindung, Schutzmaßnahme oder Nachweis unzureichend.
○ GRAU · ungeprüft
Keine belastbare Aussage; nicht als unkritisch oder konform interpretieren.
Keine belastbare Aussage; nicht als unkritisch oder konform interpretieren.
Die Ampel bewertet stets einen benannten Aspekt und Scope – zum Beispiel „Segmentierungsnachweis für Zone X, Stand Y“. Ein pauschales „System grün“ wäre zu ungenau.
¶ 23. Architektur- und Kontrollstatus
| Status | Bedeutung | nächster Schritt |
|---|---|---|
| ○ ERFASST | Objekt und Owner angelegt | Scope und Quellen prüfen |
| ◆ MODELLIERT | Architektur und Beziehungen beschrieben | Risiko-/Kontrollprüfung |
| ◇ GEPRÜFT | fachliche und technische Prüfung erfolgt | Abweichungen behandeln |
| ▲ FREIGABE OFFEN | Entscheidung oder Nachweis fehlt | befugte Freigabe einholen |
| ✓ FREIGEGEBEN | definierter Stand freigegeben | betreiben, überwachen, reviewen |
| ↻ REVIEW FÄLLIG | Frist oder Trigger erreicht | neu bewerten und bestätigen |
| × GESPERRT/ÜBERHOLT | Stand nicht mehr zulässig | ersetzen, abschalten oder Ausnahme entscheiden |
¶ 24. Änderungs- und Architekturreview
| Prüfschritt | Leitfrage | Ergebnis |
|---|---|---|
| 1 · Anlass | Was wird warum geändert und welcher Dienst ist betroffen? | Change-/Projektbezug |
| 2 · Scope | Welche Systeme, Daten, Zonen, Anbieter und Standorte ändern sich? | Auswirkungsbereich |
| 3 · Risiko | Welche Bedrohungen, Abhängigkeiten und Schutzbedarfe verändern sich? | aktualisierte Bewertung |
| 4 · Design | Sind Segmentierung, Identität, Kryptografie, Logging und Resilienz geeignet? | Architekturentscheidung |
| 5 · Umsetzung | Sind Baseline, Berechtigung, Migration und Verantwortliche vorbereitet? | Umsetzungsplan |
| 6 · Test | Sind Funktion, Sicherheit, Last, Monitoring, Backup und Rollback geprüft? | Test-/Abnahmebericht |
| 7 · Freigabe | Wer darf Produktivsetzung und Restrisiko genehmigen? | dokumentierte Entscheidung |
| 8 · Nachlauf | Stimmen Inventar, Diagramm, Regeln, Notfallplan und Nachweise? | aktualisierte Dokumentation |
Notfalländerungen folgen einem beschleunigten, aber dokumentierten Weg. Risiko, befugte Entscheidung, Protokollierung und nachträgliche Prüfung entfallen nicht.
¶ 25. Reviewauslöser
| Auslöser | mindestens zu prüfen |
|---|---|
| neuer/geänderter Dienst | Scope, Abhängigkeiten, Schutzbedarf und RTO/RPO |
| neue Cloud-/Providerleistung | Verantwortungsgrenze, Netzpfad, Identität, Logging und Exit |
| neuer Standort/Netz | Zonen, Leitungswege, physische Sicherheit und Notbetrieb |
| neue externe Verbindung | Zweck, Authentisierung, Vertrag, Abschaltung und Review |
| Supportende/Schwachstelle | Exposition, Kompensation, Ablösung und Restrisiko |
| Vorfall/Alarm-/Testbefund | Ursache, Erkennungslücke, Segmentierung und Reaktionsweg |
| Organisations-/Ownerwechsel | Verantwortung, Berechtigung, Bereitschaft und Kontakt |
| geänderte Risikolage | Architekturgrundsätze, Kontrollen und Wirksamkeitsprüfung |
| regulärer Termin | Vollständigkeit, Aktualität und fortbestehende Notwendigkeit |
¶ 26. Fiktives Musterregister
| ID | Musterobjekt | Dienstbezug | Zone/Betriebsmodell | Status | Datenqualität | offener Punkt |
|---|---|---|---|---|---|---|
| DEMO-NI-001 | Muster-Anwendungsplattform A | Beispieldienst A | Produktion / intern | ◇ GEPRÜFT | ! GELB | technischer RTO-Nachweis offen |
| DEMO-NI-002 | fiktiver Providerzugang B | Musterprozess B | Dritte / hybrid | ▲ FREIGABE OFFEN | × ROT | Befristung und Sitzungslogging offen |
| DEMO-NI-003 | Beispiel-OT-Komponente C | Musterleistung C | OT / lokal | ○ ERFASST | ○ GRAU | Owner, Version und Supportstatus klären |
Alle Namen, Zustände und Befunde sind fiktiv. Sie dürfen nicht als reale System-, Sicherheits- oder Wirksamkeitsaussage verwendet werden.
¶ 27. Sinnvolle Registeransichten
| Ansicht | Filter | Nutzen |
|---|---|---|
| Management | kritischer Dienst, rote/graue Qualität, überfällige Entscheidung | Ressourcen und Eskalation |
| Architektur | Systemgrenze, Zone, Verbindung, Abweichung | Designkonsistenz |
| Netzwerkbetrieb | Regeln, Ablauf, temporäre Verbindung, Review | Regel- und Segmentsteuerung |
| IAM/PAM | privilegierte Identität, Drittzugriff, Notkonto | Berechtigungs- und Zugriffskontrolle |
| SOC/Monitoring | Quelle, Use Case, Sensorstatus, Alarmtest | Erkennungsabdeckung |
| Lifecycle | Version, Schwachstelle, Patch, Supportende | technische Schulden und Ablösung |
| BCM | Kritikalität, Abhängigkeit, RTO/RPO, Restore/Failover | Wiederanlauf und Resilienz |
| Audit | Freigabe, Quelle, Prüfung, Nachweis und offene Abweichung | Nachvollziehbarkeit |
¶ 28. Kennzahlen und Berichtswesen
| Kennzahl | Aussage | mögliche Eskalation |
|---|---|---|
| kritische Systeme ohne bestätigten Owner | Verantwortungslücke | jede K1/K2-Zuordnung berichten |
| unbekannte/ungeklärte externe Verbindungen | unkontrollierte Angriffsfläche | sofortige Untersuchung |
| überfällige Kommunikationsreviews | veraltete Freigaben | Owner und Führung informieren |
| direkte Administrationspfade aus Benutzerzonen | erhöhte Kompromittierungswirkung | priorisierte Architekturmaßnahme |
| privilegierte/Providerzugänge ohne Rezertifizierung | unklare Berechtigungsnotwendigkeit | Sperrung oder Entscheidung |
| kritische Systeme ohne aktuelle Baselineprüfung | Konfigurationsunsicherheit | risikobasierte Prüfung |
| Systeme außerhalb Support ohne Behandlung | steigendes Lebenszyklusrisiko | Ablöse-/Akzeptanzentscheidung |
| Logging-/Monitoringlücken bei kritischen Systemen | eingeschränkte Erkennung | Sensor-/Use-Case-Maßnahme |
| verfehlte Failover-/Restoreziele | Resilienzannahme nicht bestätigt | Korrektur und Nachtest |
| Änderungen ohne aktualisierte Architektur | Dokumentations- und Kontrolllücke | Changeprozess korrigieren |
Kennzahlen benötigen Datenquelle, Scope, Stichtag, Nenner, Zielwert, Toleranz, Trend, Owner und Kommentar. Eine hohe Anzahl kann auch verbesserte Erkennung statt schlechtere Sicherheit bedeuten; Interpretation und Datenqualität gehören in den Bericht.
¶ 29. Nachweise und geschützte Ablage
| Nachweis | belegt | Schutz |
|---|---|---|
| freigegebener Architekturstand | definierte Grenzen, Zonen und Komponenten | vertraulich |
| Kommunikations-/Regelreview | Notwendigkeit, technische Entsprechung und Aktualität | besonders geschützt |
| IAM-/PAM-/Drittzugriffsreview | Berechtigungsumfang und Entzug | vertraulich |
| Baseline-/Konfigurationsprüfung | geprüfter Soll-Ist-Stand | vertraulich |
| Schwachstellen-/Patchnachweis | Bewertung, Behandlung und Frist | geschützt |
| Logging-/Alarmierungstest | Datenquelle, Erkennung und Eskalation | geschützt |
| Kapazitäts-/Failover-/Restoretest | technische Fähigkeit und Grenzen | vertraulich |
| Change-/Abnahme-/Rollbackprotokoll | kontrollierte Änderung | intern/vertraulich |
| Risiko-/Ausnahmeentscheidung | Restrisiko, Kompensation, Befristung | Entscheidungsschutz |
Das öffentliche Wiki referenziert Nachweis-ID, Status, Owner, Prüfzeitraum und geschützten Ablageort, veröffentlicht aber keine verwertbaren Angriffspfade oder operativen Originale.
¶ 30. Häufige Fehler
| Fehler | Folge | Korrektur |
|---|---|---|
| Inventarliste wird mit Architektur verwechselt | Beziehungen und Vertrauensgrenzen fehlen | logische und technische Sichten ergänzen |
| Netzplan enthält alles, aber keinen Dienstebezug | Schutzpriorität bleibt unklar | Dienst-, Prozess- und Kritikalitäts-IDs verknüpfen |
| VLAN gilt automatisch als Sicherheitssegment | Regel-, Identitäts- und Kontrollwirkung ungeprüft | technische Durchsetzung und Test belegen |
| „interne“ Kommunikation wird pauschal erlaubt | seitliche Bewegung und Kaskaden | erforderliche Beziehungen einzeln begründen |
| Administratoren nutzen normale Benutzerpfade | Kompromittierung überträgt sich | Identität, Gerät und Managementweg trennen |
| Anbieterzugang bleibt dauerhaft aktiv | unnötige externe Angriffsfläche | befristet aktivieren und überwachen |
| SIEM-Anbindung gilt als Erkennung | Use Case, Kontext und Reaktion fehlen | Ende-zu-Ende-Alarmtest durchführen |
| Hochverfügbarkeit ersetzt Restore/BCM | Korruption und gemeinsame Ursachen bleiben | isolierten Restore und Notbetrieb testen |
| Cloud wird außerhalb des Netzscopes betrachtet | Control Plane, API und Identität fehlen | hybride Vertrauensgrenzen modellieren |
| detaillierte Netzpläne werden öffentlich abgelegt | Angriffs- und Betriebsinformationen offengelegt | geschützte Ablage und Referenz verwenden |
¶ 31. Qualitätsgate vor Freigabe
| Prüffrage | Musterstatus |
|---|---|
| Sind relevante Dienste, Systeme, Komponenten und technische Owner vollständig verknüpft? | Offen |
| Sind System-, Betriebs-, Mandanten-, Provider- und Vertrauensgrenzen eindeutig? | Offen |
| Sind Zonen, Verbindungen, Zwecke, Freigaben und Reviews aktuell? | Offen |
| Sind Benutzer-, Administrations-, Monitoring- und Recoverypfade angemessen getrennt? | Offen |
| Sind externe und Anbieterzugänge persönlich, befristet, überwacht und abschaltbar? | Offen |
| Sind Identitäts-, DNS-, Zeit-, PKI-, Schlüssel- und Managementabhängigkeiten berücksichtigt? | Offen |
| Sind Baselines, Schwachstellen, Patches, Supportende und Ausnahmen nachvollziehbar? | Offen |
| Sind Logging, Angriffserkennung, Alarmierung und Reaktion getestet? | Offen |
| Sind Kapazität, Failover, Restore, Datenkonsistenz und fachliche Abnahme bestätigt? | Offen |
| Sind Cloud-, OT-, Standort- und Lieferantenverantwortungen einbezogen? | Offen |
| Sind Architektur, Inventar, Datenflüsse, Risiken, Notfallpläne und Nachweise konsistent? | Offen |
| Bleiben sensible technische Originale geschützt? | Offen |
¶ 32. Offene Entscheidungen vor produktiver Nutzung
| Entscheidung | Verantwortliche Funktion | Musterstatus |
|---|---|---|
| führende Architektur- und Kommunikationsregister | IT-Leitung / Architektur | Offen |
| Zonenmodell und Vertrauensgrenzen | Architektur / Informationssicherheit | Offen |
| Freigabe- und Reviewregeln für Verbindungen | Netzwerk / Dienst-Owner | Offen |
| Administrations-, PAM- und Notzugangskonzept | IAM / Betrieb / Sicherheit | Offen |
| Mindestbaselines und Ausnahmeprozess | Betrieb / Informationssicherheit | Offen |
| Logging-/Monitoring- und Erkennungsabdeckung | SOC / Betrieb / Datenschutz | Offen |
| Patch-, Supportende- und Ablösekriterien | IT-Leitung / Assetmanagement | Offen |
| Resilienz-, Failover- und Restoretests | BCM / Betrieb / Dienst-Owner | Offen |
| Cloud-, OT- und Drittzugriffsstandards | Architektur / Einkauf / OT | Offen |
| geschützte technische Ablage und Berechtigungen | Dokumenten-/Systemverantwortung | Offen |
Bis zur dokumentierten Freigabe bleiben sämtliche Musterwerte, Matrizen und Ampeln Entwurf.
¶ 33. Verknüpfte Seiten
| Thema | Wiki-Seite |
|---|---|
| Dienstescope | Relevante Dienste und Prozesse |
| Assets und Systeme | Asset- und Systeminventar |
| Informationswege | Daten- und Informationsflüsse |
| Kritikalität | Kritikalität und Abhängigkeiten |
| externe Technik | Externe Dienste und Cloud |
| Standorte | Standorte und Infrastruktur |
| Risiken | NIS2-Risikoregister |
| Nachweise | NIS2-Nachweisregister |
| Netzregelung | Netzwerke und Kommunikation |
| Zugriff | Zugriff und Berechtigungen |
| Überwachung | Protokollierung und Überwachung |
| Betrieb/Changes | IT-Betrieb und Änderungen |
| Schwachstellen/Patches | Schwachstellen- und Patchmanagement |
| Wiederanlauf | Wiederanlaufplanung |
| technische Nachweise | Patch- und Schwachstellennachweise |
¶ 34. Offizielle Grundlagen und Orientierung
| Quelle | Verwendung |
|---|---|
| § 30 BSIG | Risikomanagementmaßnahmen für die zur Diensterbringung genutzten Systeme, Komponenten und Prozesse |
| § 31 BSIG | zusätzliche Anforderungen für Betreiber kritischer Anlagen, insbesondere Systeme zur Angriffserkennung |
| Durchführungsverordnung (EU) 2024/2690 | für die erfassten digitalen Einrichtungsarten insbesondere Netzsicherheit, Segmentierung, Zugriff und Reviews |
| BSI IT-Grundschutz NET.1.1 – Netzarchitektur und -design | fachliche Orientierung für Netzrichtlinie, Zonierung, Segmentierung und zulässige Kommunikation |
Anwendbarkeit, Rechtsstand, Scope und sektorale Anforderungen werden vor produktiver Nutzung aktuell geprüft. Alle externen Links öffnen in einem neuen Tab.
¶ 35. Weiterführende Unterstützung durch SMCT MANAGEMENT
SMCT MANAGEMENT
Unterstützung bei NIS2-Scope, Architektur-, Netz-, Betriebs- und Nachweissteuerung sowie der Verbindung zu ISO 27001 und Business Continuity.
Informationen zur NIS2-Beratung öffnen
Unterstützung bei NIS2-Scope, Architektur-, Netz-, Betriebs- und Nachweissteuerung sowie der Verbindung zu ISO 27001 und Business Continuity.
Informationen zur NIS2-Beratung öffnen
¶ 36. Änderungshistorie
| Version | Datum | Änderung | Freigabe |
|---|---|---|---|
| 0.3 | 09.08.2026 | Seite fachlich und visuell neu aufgebaut; Cockpit, Scope-/Registermodell, Referenzarchitektur, Zonen- und Kommunikationsmatrix, Administrationspfad, Basisdienste, Härtung, Lebenszyklusampel, Erkennungskette, Cloud/OT, aufklappbare Architekturprüfung, Statuslogik, Musterregister, Kennzahlen und Qualitätsgate ergänzt | Ausstehend |
| 0.2 | 08.08.2026 | Rollen, Dokumentationsebenen, Zonen, Zugänge, Härtung, Überwachung, Resilienz und Freigabekriterien fachlich vertieft | Ausstehend |
| 0.1 | 08.08.2026 | Musterregister für Netz- und Informationssysteme erstellt | Ausstehend |