LF4.3 – Schutzobjekte und Schutzbedarf vorbereiten

Drei Schutzobjekt-Typen im Lernfall

Diese Einteilung ist für den SemaTrain-Lernfall bewusst reduziert. Sie ersetzt keine vollständige organisationsweite BSI-Grundschutz-Modellierung.

Warum eindeutige IDs helfen

Bezeichnungen wie „Server“, „Daten“ oder „Programm“ sind für eine spätere Begründung zu ungenau. Eine kurze ID macht Verweise eindeutig und verhindert, dass verschiedene Objekte versehentlich vermischt werden.

• I-01 – Rollen- und Berechtigungszuordnungen
• I-02 – Kontostatus und Benutzerkennung
• A-01 – Benutzerverwaltungsanwendung
• S-01 – Administrationsarbeitsplatz
• S-02 – Anwendungsserver
• S-03 – Speichersystem für die Anwendungsdaten

Zweck und betriebliche Funktion dokumentieren

Die Bezeichnung allein erklärt nicht, warum ein Objekt im Arbeitsbereich relevant ist. Deshalb wird zusätzlich beschrieben, welche Aufgabe es dort erfüllt.

Abhängigkeiten sichtbar machen

Schutzobjekte stehen nicht isoliert nebeneinander. Eine Information kann in einer Anwendung verarbeitet werden; die Anwendung kann von einem IT-System abhängen; mehrere Objekte können dieselbe technische Plattform nutzen.

Für den Lernfall kann beispielsweise dokumentiert werden:

• I-01 wird in A-01 verarbeitet.
• A-01 benötigt S-02, um bereitgestellt zu werden.
• S-02 nutzt S-03 für persistente Anwendungsdaten.
• Administratoren greifen von S-01 auf A-01 zu.

Diese Beziehungen helfen später dabei, Auswirkungen plausibler Schadensszenarien nachvollziehbar auf konkrete Objekte zu beziehen.

Schutzziele vorbereiten – nicht bewerten

Für jedes Schutzobjekt kann bereits festgehalten werden, welche der drei Schutzziele Vertraulichkeit, Integrität und Verfügbarkeit im späteren Bewertungsprozess betrachtet werden müssen.

Das ist noch keine Schutzbedarfsstufe. Ein Eintrag wie „Vertraulichkeit: relevant“ bedeutet nicht automatisch „Schutzbedarf hoch“.

Vorgaben aus LF4.2 zuordnen

Die Vorgabenmatrix aus LF4.2 wird nicht neu erfunden. Stattdessen werden relevante Nachweise an die Schutzobjekte angebunden.

• Die fiktive K-27-Regel zur dokumentierten Rollen- und Berechtigungszuordnung kann I-01 und A-01 betreffen.
• Die fiktive Regel zur Kontodeaktivierung kann A-01 und die darin verarbeiteten Kontoinformationen betreffen.
• Bei personenbezogenen Informationen bleibt die in LF4.2 belegte DSGVO-Einordnung relevant; Datenschutz wird aber nicht auf alle Schutzobjekte pauschal übertragen.
• BSI-Standard 200-2 bleibt methodische Fachquelle für den weiteren Weg der Schutzbedarfsanalyse.

Schutzobjektliste als Arbeitsergebnis

Typische Fehlentscheidungen vermeiden

• Information, Anwendung und IT-System ohne Begründung vermischen.
• Den gesamten Unternehmensbestand aufnehmen, obwohl der Arbeitsbereich klar abgegrenzt ist.
• Aus „Schutzziel relevant“ bereits eine finale Schutzbedarfskategorie ableiten.
• Eine technische Maßnahme auswählen, bevor Schadensszenarien und Bedrohungen bewertet wurden.
• Unklare Abhängigkeiten erfinden, statt sie als offenen Punkt zu kennzeichnen.
• Eine vollständige BSI-Grundschutz-Modellierung vorziehen, obwohl LF4.3 nur die curricular benötigte Vorbereitung verlangt.

PRAXISAUFGABE

Praktische Lernaufgabe

Erstellen Sie aus den folgenden fiktiven Angaben eine Schutzobjektliste:

• Die Benutzerverwaltung verarbeitet Benutzerkennung, Kontostatus sowie Rollen- und Berechtigungszuordnungen.
• Die Anwendung wird auf einem Anwendungsserver betrieben.
• Anwendungsdaten liegen auf einem separaten Speichersystem.
• Administratoren nutzen einen dafür vorgesehenen Arbeitsplatz.
• Die in LF4.2 dokumentierten K-27-Vorgaben gelten weiterhin.

Vergeben Sie IDs, ordnen Sie jeden Gegenstand einem Typ zu, beschreiben Sie Zweck und Abhängigkeiten, markieren Sie den Schutzzielbezug und dokumentieren Sie mindestens einen offenen Punkt.

Nicht durchführen: finale Schutzbedarfskategorie vergeben, Schadensklasse festlegen, Bedrohungen gewichten oder Maßnahmen auswählen.

Praxisauftrag

Selbsttraining – keine Abgabe erforderlich.

Erstellen Sie für einen vollständig fiktiven, klar abgegrenzten Arbeitsbereich eine Schutzobjektliste mit mindestens neun Einträgen:

• mindestens drei Informationen,
• mindestens drei Anwendungen,
• mindestens drei IT-Systeme,
• zu jedem Eintrag eine eindeutige ID und eine betriebliche Funktion,
• mindestens eine relevante Abhängigkeit, sofern vorhanden,
• Schutzzielbezug als Vorbereitung,
• relevante Vorgabe oder Nachweis aus einer bereits geklärten Quellenebene,
• offene Punkte ausdrücklich kennzeichnen.

Vergeben Sie noch keine finale Schutzbedarfskategorie. Klassifizieren Sie noch keine Schadensszenarien, gewichten Sie noch keine Bedrohungen und setzen Sie noch keine technische Maßnahme um.

SELBSTKONTROLLE

Selbstkontrolle

• Kann ich Information, Anwendung und IT-System voneinander unterscheiden?
• Kann ich jedem Schutzobjekt eine eindeutige ID und Funktion zuordnen?
• Kann ich relevante Abhängigkeiten dokumentieren?
• Kann ich die drei Schutzziele als Vorbereitung erfassen, ohne daraus bereits eine Stufe abzuleiten?
• Kann ich Vorgaben aus LF4.2 passend zuordnen?
• Kennzeichne ich unklare Zuordnungen als offenen Punkt?
• Bleibt die Schadens- und Schutzbedarfsbewertung für LF4.4 offen?

REFLEXION

Reflexion

• Warum ist eine eindeutige Schutzobjekt-ID für spätere Begründungen hilfreich?
• Welche Fehler entstehen, wenn Anwendung und IT-System nicht getrennt werden?
• Welche Abhängigkeit würde im eigenen Beispiel besonders viele Schutzobjekte betreffen?
• Warum reicht „Verfügbarkeit ist relevant“ noch nicht für eine Schutzbedarfskategorie?
• Welche offenen Punkte müssen vor LF4.4 noch geklärt werden?