Cybersicherheitsarchitektur

Eine Sicherheitsarchitektur ist kein Schaubild der eingekauften Werkzeuge. Sie beschreibt Annahmen über Vertrauen, Grenzen, Kontrollen, Zuständigkeiten und Wiederanlauf für einen konkreten Betrieb. Ausgangspunkt sind Geschäftsdienste, aus denen Pflichten entstehen: Bestellungen annehmen, Produktion steuern, Gehälter zahlen, Kundendaten bearbeiten, Zugänge bereitstellen oder administrative Identitäten verwalten. Für jeden Dienst erfassen wir die benötigten Informationen und Systeme, betroffene Personen und Organisationen, externe Abhängigkeiten sowie die Folgen eines Verlusts von Vertraulichkeit, Integrität, Verfügbarkeit oder nachvollziehbarer Verantwortlichkeit.

Die Istaufnahme folgt Daten und Befugnissen, nicht nur dem Organigramm. Sie umfasst Nutzer, Administratoren, Workloads, Dienstkonten, Geräte, Anwendungen, APIs, Netze, Cloud-Mandanten, Lieferanten, Repositories, Sicherungen und Managementebenen. Internetexponierte Systeme sind nur ein Teil des Bildes. Ebenso wichtig sind implizites Vertrauen im internen Netz, Fernwartung, gemeinsam genutzte Konten, unkontrollierte Exporte und Schlüssel, die zwischen Umgebungen wandern. Unbekannte Assets oder Verbindungen werden als offene Evidenzlücke ausgewiesen und nicht stillschweigend als sicher bewertet.

Ein Bedrohungsmodell hält die Sicherheitsarchitektur verhältnismäßig. Für den vereinbarten Ausschnitt beschreiben wir plausible Akteure, Ziele, Eintrittswege, Privilegienketten, sensible Handlungen und Missbrauchsfälle. Eine öffentliche Website, ein Zahlungsablauf und eine Produktionsanlage brauchen unterschiedliche Annahmen. Wir trennen die technische Schwachstelle vom praktisch nutzbaren Angriffspfad und diesen wiederum vom geschäftlich wesentlichen Szenario. Die Priorität ergibt sich aus Auswirkung, Erreichbarkeit, Voraussetzungen, vorhandenen Schutzmaßnahmen und Wiederherstellungsaufwand – nicht allein aus einem Scannerwert.

Zur Entwurfsgrundlage gehören auch rechtliche, vertragliche, versicherungsbezogene und kundenseitige Anforderungen, die der Auftraggeber bereitstellt. Ein Rahmenwerk kann Entscheidungen ordnen; die bloße Erwähnung von NIST, ISO, CIS, PCI DSS oder einer anderen Norm ist jedoch kein Konformitätsnachweis. Im Angebot steht, ob es um Architekturprüfung, Zielbild, Umsetzungsbegleitung, Kontrollbewertung oder Vorbereitung auf eine gesonderte Prüfung geht. Zertifizierung, Attestierung, Rechtsauslegung und Penetrationstest sind nicht automatisch mit dem Begriff Sicherheit beauftragt.

Die Kalkulation folgt dieser Evidenzgrenze. Umfang der Landschaft, Zahl der Mandanten und Standorte, Cloud- und On-Premises-Anteil, OT oder regulierte Daten, Qualität bestehender Unterlagen, Zugang zur Architektur, Workshops, Szenarien, benötigte Artefakte, Umsetzungsbeteiligung und Prüftiefe verändern den Aufwand. Wir versprechen weder die Verhinderung jedes Vorfalls noch die Abnahme durch jeden Prüfer. Die Abnahme belegt die vereinbarten Entscheidungen, Dokumente und Tests; das verbleibende Risiko und die betriebliche Wirksamkeit müssen anschließend verantwortlich geführt und beobachtet werden.

Moderne Geschäftsdienste liegen selten hinter einer einzigen sinnvollen Netzgrenze. Beschäftigte arbeiten mobil, Dienstleister administrieren Systeme, Kunden verwenden Portale, Anwendungen rufen APIs auf und Automatisierungen handeln über technische Identitäten. Die Architektur fragt daher: Wer oder was fordert Zugriff an, auf welche Ressource und Aktion, von welchem Gerät und in welchem Kontext, nach welcher Regel, für welche Dauer und auf Grundlage welcher Signale? Ein Standort im internen Netz kann ein Merkmal sein, ist aber kein hinreichender Vertrauensbeweis.

Das Identitätsmodell erfasst Belegschaft, Kunden, Partner, Administratoren, Anwendungen, Workloads, Geräte und Notfallkonten. Dokumentiert werden führende Identitätsquelle, Föderation, Registrierung, Authentisierung, Autorisierung, Sitzungsdauer, Gerätezustand, Aufbewahrung von Zugangsdaten und Geheimnissen, Eintritt-Wechsel-Austritt, delegierte Administration und Notfallzugang. Parallele Verzeichnisse, lokale Konten und unverwaltete Dienstschlüssel werden nicht aus dem Zielbild ausgeblendet, sondern als befristete Ausnahme mit Eigentümer und Behandlung geführt.

Minimalberechtigung wird als Betriebsregel formuliert. Rollen und Richtlinien erlauben die kleinste zweckmäßige Handlung an einer definierten Ressource für einen definierten Zeitraum. Administrative Aufgaben können stärkere Authentisierung, verwaltete Geräte, Genehmigung, zeitlich begrenzte Erhöhung, protokollierte Sitzungen oder einen eigenen Administrationspfad verlangen. Wo eine kompromittierte oder unredliche Identität nicht denselben folgenreichen Vorgang auslösen und freigeben darf, werden Aufgaben getrennt. Notfallkonten sind eng begrenzt, überwacht, getestet und nach Nutzung Gegenstand von Rotation und Prüfung.

Die Stärke der Anmeldung muss zur Bedrohung und Berechtigung passen. Mehrfaktor-Authentisierung senkt bestimmte Zugangsdatenrisiken, korrigiert aber keine übermäßige Autorisierung, unsichere Kontowiederherstellung, gestohlene Sitzungen, bösartige OAuth-Zustimmung oder überprivilegierte Workloads. Wo das Risiko es verlangt, betrachten wir phishingresistente Verfahren, Tokenziel und -lebensdauer, bedingten Zugriff, Geräteregistrierung, Altprotokolle, Kennwortrücksetzung, Helpdesk-Prüfung und Sitzungswiderruf. Auch Umgehungs- und Wiederherstellungswege werden getestet, nicht nur der reguläre Anmeldedialog.

Zero Trust ist eine Entwurfs- und Betriebsdisziplin, kein Produktetikett. Ressourcen, Identitäten, Geräte, Anwendungen und Datenflüsse erhalten explizite Regeln und verwertbare Telemetrie; Zugriff wird, soweit die Plattform es zulässt, je Sitzung oder Handlung bewertet; Netzzugehörigkeit vererbt kein blindes Vertrauen. Der Plan kann vorhandene Fähigkeiten nutzen und dienstweise vorgehen. Ein vollständiger Neuaufbau ist nicht grundsätzlich nötig, und das Aktivieren eines Herstellermerkmals macht eine Umgebung noch nicht zur Zero-Trust-Architektur.

Die Zielarchitektur zeigt, wo sich Vertrauen ändert und wo eine Kontrolle Missbrauch verhindern, begrenzen, erkennbar machen oder die Wiederherstellung unterstützen kann. Wir verfolgen ein- und ausgehenden sowie internen Verkehr, administrative Zugänge, Anwendungsaufrufe, Datenbewegungen, Softwareauslieferung, Lieferantenverbindungen und Sicherungspfade. Segmentierung folgt der Schutzfläche und möglichen lateralen Wegen, nicht willkürlichen Netzzonen. Jede Grenze hat Zweck, Durchsetzungspunkt, Richtlinienverantwortlichen, Ausfallverhalten, Protokollquelle und Prüfverfahren.

Cloud- und SaaS-Dienste brauchen eine geteilte Verantwortungsmatrix für den konkreten Anbieter und das jeweilige Servicemodell. Die Sicherheit des Providers konfiguriert nicht automatisch Identitäten, Datenberechtigungen, Mandanteneinstellungen, Schlüssel, Anwendungen und Wiederanlauf des Kunden. Wir erfassen Organisations- und Kontostruktur, Landing Zones, Netzexposition, Föderation, privilegierte Rollen, Protokollierung, Verschlüsselung und Schlüsselverantwortung, Workload-Identität, Secret-Verwaltung, Posture-Kontrollen, Datenstandort sowie Providerabhängigkeiten. Multi-Cloud wird nur eingeplant, wenn Landschaft und Betriebskapazität es wirklich erfordern.

Anwendungs- und API-Sicherheit werden mit Architektur und Auslieferung verbunden. Vertrauensgrenzen, Eingabebehandlung, Authentisierung und Autorisierung, Objektzugriff, Geheimnisse, Herkunft von Abhängigkeiten, Build-Berechtigungen, Artefaktintegrität, Releasefreigabe, Laufzeitisolation und Auditereignisse werden risikogerecht behandelt. OWASP ASVS kann prüfbare Anforderungen liefern; seine Nennung belegt aber keine erreichte Stufe. Soll es Abnahmekriterium sein, müssen Version, ausgewählte Anforderungen, Evidenz und prüfende Stelle eindeutig feststehen.

Datenschutz folgt Lebenszyklus und tatsächlicher Nutzung. Wir klassifizieren die für den Dienst erforderlichen Informationen und ordnen Erhebung, Übertragung, Verarbeitung, Speicherung, Export, Aufbewahrung und Löschung den Verantwortlichen und Zugriffsvorgaben zu. Verschlüsselung wird mit Endpunkt, Protokoll, Schlüsselverwahrung, Rotation, Sicherung und Wiederherstellung beschrieben; das Wort verschlüsselt allein ist kein ausreichender Nachweis. Minimierung, Tokenisierung, Feldberechtigungen und kontrollierter Export können die Exposition gezielter senken als ein weiteres Randgerät.

Endpoint-, E-Mail-, Netz-, Anwendungs-, Identitäts- und Datenkontrollen müssen zusammenarbeiten. Mehrschichtige Verteidigung bedeutet nicht, überlappende Werkzeuge ohne Entscheidungsmodell einzukaufen. Wir prüfen, ob Kontrollen dieselbe verlässliche Identität nutzen, sich Richtlinien widersprechen, Telemetrie verloren geht, ein Providerausfall neue Lücken schafft oder ein manueller Schritt kritische Macht behält. Überflüssige Doppelungen dürfen entfallen; eine einfache kompensierende Maßnahme kann bleiben, wenn ein Austausch mehr Risiko erzeugt. Jede Empfehlung nennt Abhängigkeit, Eigentümer, beabsichtigte Risikobehandlung und Abschlussnachweis.

Eine präventive Kontrolle ist unvollständig, wenn ihr Ausfall unsichtbar bleibt. Wir bestimmen Ereignisse, die Missbrauch, Richtlinienumgehung, Privilegänderung, Konfigurationsdrift, auffällige Datenbewegung, Kontrollausfall oder Wiederherstellung zeigen. Protokolle brauchen Quelle, belastbare Zeit, Identität, Aufbewahrung, Integritätsschutz, Zugriffsmodell und Verantwortlichen. Alles unbegrenzt zu sammeln ist weder eine Strategie noch automatisch rechtmäßig. Telemetrie wird für eine konkrete Erkennung, Untersuchung, Pflicht oder Kontrollprüfung erhoben, die jemand tatsächlich betreibt.

Erkennungsabdeckung wird an wesentlichen Szenarien gemessen. Jede Regel oder Analyse nennt beobachtbares Verhalten, benötigte Felder, Auswertungspunkt, Schwelle oder Logik, Schweregrad, erwartbare Fehlalarme, Triageverantwortung, Reaktionsfenster und zu sichernde Evidenz. Ausbleibende Logs und abgeschaltete Sensoren gelten als Kontrollfehler, nicht als ruhiger Betrieb. Ein Dashboard mit Alarmen, aber ohne Fallverantwortung, Eskalation und Abschlussbeleg, ist noch keine betriebsfähige Detection-Funktion.

Eindämmung muss Geschäfts- und Sicherheitszwänge berücksichtigen. Die Architektur legt fest, welches Konto, Gerät, Token, Netzsegment, Workload oder welche Integration isoliert werden kann, wer dies freigibt, welche Abhängigkeiten betroffen sind und wie der Zugriff zurückkehrt. Automatische Eindämmung bleibt Szenarien mit geprüfter Sicherheit und begrenzter Folge vorbehalten. Wenn sofortiges Abschalten Menschen, Beweise oder einen kritischen Dienst gefährden könnte, braucht der Ablauf die richtige menschliche Befugnis und alternative Schutzmaßnahmen.

Wiederherstellung wird vor dem Vorfall entworfen. Dokumentiert werden kritische Dienstabhängigkeiten, Wiederanlaufreihenfolge, vom Auftraggeber gesetzte Ziele für Datenverlust und Unterbrechung, Trennung von Backups und Replikaten, unabhängige Administration, Wiederherstellungsidentitäten, mögliche Clean-Room-Umgebung und Prüfschritte. Ein erfolgreicher Sicherungslauf beweist noch keine Wiederherstellbarkeit. Repräsentative Restore- und Failover-Übungen müssen Daten, Anwendungen, Identitäten, Konfiguration und Betriebsübergabe gemeinsam bestätigen. RPO, RTO oder Verfügbarkeit werden nur zugesagt, wenn die Abhängigkeitskette dies trägt und der Vertrag sie nennt.

Incident Readiness verbindet technische und organisatorische Wege. Ansprechpartner, Providereskalation, Beweissicherung, Kommunikation, rechtliche und regulatorische Entscheidungen, Kundenpflichten und Eigentum an Folgemaßnahmen werden für den beauftragten Umfang benannt. Architekturarbeit kann Runbook-Grundlagen und Übungsszenarien liefern, ist aber kein versteckter 24/7-Response-Vertrag. Fortlaufendes Monitoring, Forensik, Krisenkommunikation oder Notfalleinsatz brauchen einen gesonderten schriftlichen Auftrag mit Zeiten, Befugnissen, Kanälen und Konditionen.

Das Maßnahmenregister verbindet jeden Befund mit Geschäftsdienst, Bedrohungsszenario, betroffenem Asset, vorhandener Absicherung, Zielzustand, Behandlung, Abhängigkeit, verantwortlicher Person und Abschlussbeleg. Wir vermeiden Scheingenauigkeit: Ein Reifegrad kann definierte Beobachtungen vergleichbar machen, zeigt aber nicht jede unbekannte Exposition. Befunde werden als bestätigt, nachvollziehbar abgeleitet oder derzeit nicht prüfbar gekennzeichnet. Bei schwacher Evidenz kann der nächste Schritt gezielte Erhebung oder Validierung sein statt eines sofortigen Einkaufs.

Die Reihenfolge berücksichtigt Risikogewicht und Lieferrealität. Grundlagen wie Identitätseigentum, Asset-Erfassung, getrennte Administration, isolierte Sicherungen oder zentrale Protokollierung ermöglichen häufig mehrere spätere Maßnahmen. Ein Quick Win ist nur wertvoll, wenn er einen echten Pfad verkleinert. Große Änderungen werden in Entscheidungspunkte, Piloten, Migrationen und Rückfalloptionen geteilt. Budget, Fähigkeiten, Pflegeaufwand, Anbieterbindung, Nutzerbelastung und Betriebskapazität fließen ein, damit keine Zielarchitektur entsteht, die das Unternehmen nicht betreiben kann.

Abnahme erfolgt anhand von Szenarien und Evidenz. Je nach Auftrag können freigegebene Diagramme und Entscheidungsprotokolle, Richtlinienexporte, Konfigurationsnachweise, Identitäts- und Rollentests, verweigerter Zugriff, Secret-Rotation, Logeingang, Alarmtriage, Isolation, Restore-Übungen, Anwendungskontrollen und Ausnahmen geprüft werden. Jeder Fall hat Voraussetzung, Akteur, Handlung, erwartetes Ergebnis und gespeicherten Nachweis. Ein grüner Konsolenscreenshot genügt nicht, wenn Regel, getestete Identität, Zeitpunkt und Quelle nicht reproduzierbar sind.

Penetrationstest, Schwachstellenscan, Codeprüfung und Konfigurationsreview beantworten unterschiedliche Fragen. Sie können Teile der Architektur validieren, beweisen aber jeweils nicht die Sicherheit des gesamten Dienstes. Das Angebot nennt enthaltene Methoden, autorisierte Ziele und Zeiten, Datenbehandlung, Testsicherheit, Bewertungsmodell, Nachtest und Bericht. Eingreifende Tests finden nie ohne ausdrückliche schriftliche Erlaubnis statt. Wenn Unabhängigkeit vom Entwurfsverantwortlichen sinnvoll oder vorgeschrieben ist, empfehlen wir eine getrennte Prüfpartei.

Die Architektur bleibt ein lebendes Entscheidungsdokument. Neue Lieferanten, Zukäufe, mobiles Arbeiten, Anwendungen, KI-Agenten, Vorschriften, Vorfälle oder wesentliche Konfigurationsänderungen können das Vertrauensmodell verschieben. Deshalb gehören Review-Auslöser, Ablauf von Ausnahmen, Zugriffsrezertifizierung, Kontrollindikatoren, Testtakt und Dokumentenverantwortung zur Übergabe. Fortlaufende Governance oder Managed Operations bestehen nur bei gesondertem Auftrag. Sicherheitsrisiko lässt sich nicht an eine Zeichnung oder Beratung abgeben; Konten, Daten und Entscheidungen bleiben beim Unternehmen.