Security: Grundlagen

Akademie

Security: Grundlagen

Schutzziele, Bedrohungsmodelle und klassische Entwurfsprinzipien.

Schutzziele und Bedrohungsmodell

Begriffe vorab

  • Vertraulichkeit: Nur Berechtigte erhalten Zugriff auf Informationen.
  • Integrität: Daten und Systeme sind korrekt und nicht unbemerkt verändert.
  • Verfügbarkeit: Informationen und Dienste stehen bereit, wenn sie gebraucht werden.
  • Bedrohung: Ein mögliches Ereignis, das Schaden verursachen kann.
  • Schwachstelle: Eine Schwäche, die eine Bedrohung ausnutzen kann.
  • Risiko: Zusammenspiel aus Eintrittswahrscheinlichkeit und Schadenshöhe.
  • Bedrohungsmodell: Strukturierte Antwort auf die Frage: Wer greift was warum und wie an?

Die drei Schutzziele

Informationssicherheit wird klassisch an drei Schutzzielen festgemacht: Vertraulichkeit, Integrität und Verfügbarkeit (englisch „CIA“). Auch das Gesetz greift sie auf: Artikel 32 der DSGVO verlangt, Vertraulichkeit, Integrität, Verfügbarkeit und Belastbarkeit der Systeme und Dienste auf Dauer sicherzustellen. Die Ziele können in Konflikt geraten: Ein System, das niemand erreicht, ist vertraulich, aber nicht verfügbar. Ein offenes System ist verfügbar, aber kaum vertraulich.

Wie Schaden entsteht

Eine Bedrohung (z. B. ein Angreifer, ein Defekt oder ein Bedienfehler) nutzt eine Schwachstelle aus und gefährdet ein Schutzziel eines Werts (Daten, Dienst, Ruf). Das Risiko ergibt sich aus Wahrscheinlichkeit und Schadenshöhe. Sicherheit heißt deshalb nie „alles verhindern“, sondern Risiken bewusst senken, übertragen, akzeptieren oder vermeiden.

Ein Bedrohungsmodell in vier Fragen

  1. Was schützen wir? (Werte, z. B. Kundendaten, Login, Verfügbarkeit des Shops)
  2. Wovor? (Angreifertypen, Fehler, Ausfälle)
  3. Was tun wir dagegen? (Maßnahmen)
  4. Haben wir es gut genug gemacht? (Prüfung, Tests, Überprüfung nach Vorfällen)

Wer diese vier Fragen für ein neues Projekt schriftlich beantwortet, entdeckt viele Lücken, bevor Code geschrieben wird.

Ein durchgespieltes Beispiel: Online-Kursseite

Werte: Zugangsdaten der Lernenden, Kursinhalte, Verfügbarkeit vor einem Prüfungstermin. Bedrohungen: gestohlene Passwörter, manipulierte Plugins, Überlastung. Mögliche Maßnahmen: Mehrfaktor-Anmeldung (Vertraulichkeit), Updates und Integritätsprüfung (Integrität), Backups und Lastgrenzen (Verfügbarkeit). Das Restrisiko – etwa ein unbekannter Fehler in einem Plugin – wird bewusst benannt und mit Überwachung und Wiederherstellungsplan abgefedert.

Ein Sicherheitskonzept beginnt mit der Frage „Was ist uns wichtig?“, nicht mit der Frage „Welches Produkt kaufen wir?“.

Zum Selbermachen

  1. Wähle ein eigenes Projekt und beantworte die vier Fragen des Bedrohungsmodells in je drei Sätzen.
  2. Ordne jede Maßnahme einem der drei Schutzziele zu und prüfe, ob eines unbesetzt bleibt.

Verwandte Themen

Agentische KI → „Agenten: Sicherheit“ (Prompt Injection, Lethal Trifecta) und „KI-Sicherheit & Alignment“ zeigen, wie dieselben Grundideen auf KI-Systeme übertragen werden. WordPress → „WordPress-Plugin-Deepdive“ und „Digitale Barrierefreiheit“ ergänzen die praktische Webentwicklung.

Prüfstatus: Belegt (Stand 1. Oktober 2026): Die Nennung der drei Schutzziele in Art. 32 DSGVO wurde gegen Gesetzestext-Wiedergaben geprüft. Nicht einzeln belegt: die CIA-Definitionen in eigenen Worten (allgemein etabliert, hier nicht gegen eine einzelne Norm belegt), das Beispiel (konstruiert) und die Vier-Fragen-Struktur (verbreitete Methodik, nicht auf eine Quelle zurückgeführt).

Quellen

  • DSGVO (Verordnung (EU) 2016/679), Art. 32 „Sicherheit der Verarbeitung“
  • Hinweis: Die Schutzziele sind u. a. in ISO/IEC 27000 definiert; diese Norm wurde hier nicht eingesehen.

Klassische Entwurfsprinzipien nach Saltzer und Schroeder

Begriffe vorab

  • Prinzip der geringsten Rechte: Jede Person und jedes Programm erhält nur die Rechte, die es braucht.
  • Fail-safe Defaults: Zugriff beruht auf ausdrücklicher Erlaubnis, nicht auf fehlendem Verbot.
  • Complete Mediation: Jeder Zugriff wird geprüft, nicht nur der erste.
  • Defense in Depth: Mehrere unabhängige Schutzschichten statt einer einzigen.
  • Angriffsfläche: Summe aller Stellen, an denen ein Angreifer ansetzen kann.

Ein Aufsatz von 1975, der noch gilt

Jerome Saltzer und Michael Schroeder veröffentlichten 1975 den Aufsatz „The Protection of Information in Computer Systems“. Darin stehen acht Entwurfsprinzipien, die bis heute zitiert werden: Economy of Mechanism (so einfach und klein wie möglich), Fail-safe Defaults (Erlaubnis statt Ausschluss), Complete Mediation (jeder Zugriff wird geprüft), Open Design (Sicherheit darf nicht von der Geheimhaltung des Entwurfs abhängen), Separation of Privilege (mehrere Bedingungen für den Zugriff), Least Privilege (so wenige Rechte wie möglich), Least Common Mechanism (wenig gemeinsam genutzte Mechanismen) und Psychological Acceptability (Schutz muss bedienbar sein).

Was daraus im Alltag folgt

  • Geringste Rechte: Ein Plugin, das nur Bilder skaliert, braucht keinen Schreibzugriff auf die gesamte Datenbank. Ein Datenbankkonto für die Anwendung braucht keine Administratorrechte.
  • Fail-safe Defaults: Neue Funktionen sind zunächst für niemanden freigegeben und werden gezielt geöffnet.
  • Complete Mediation: Berechtigungen werden bei jeder Anfrage serverseitig geprüft. Ein ausgeblendeter Menüpunkt ist kein Schutz.
  • Open Design: Starke Verfahren sind öffentlich bekannt; geheim bleiben nur die Schlüssel.
  • Psychologische Akzeptanz: Wenn Sicherheit nervt, wird sie umgangen. Gute Schutzmaßnahmen sind so bequem wie möglich.

Defense in Depth

Kein einzelner Schutz ist perfekt. Mehrere Schichten – zum Beispiel Eingabeprüfung, Ausgabekodierung, eingeschränkte Rechte und Protokollierung – sorgen dafür, dass ein Fehler an einer Stelle nicht sofort zum Schaden führt. Das Prinzip taucht in der Praxis überall auf: OWASP empfiehlt etwa, eine Content Security Policy mit weiteren Schutzmaßnahmen gegen Cross-Site-Scripting zu kombinieren, weil sie allein schwer korrekt einzurichten und umgehbar sein kann.

Beispiel: Admin-Funktion in einer Webanwendung

Eine Funktion „Benutzer löschen“ prüft (1) ob die Person angemeldet ist, (2) ob sie die Berechtigung dafür hat und (3) ob die Anfrage eine gültige Absicht belegt (Nonce bzw. Token). Fällt eine Prüfung aus, scheitert die Aktion – das ist Fail-safe Default und Separation of Privilege in einem.

Sicherheit durch Einfachheit: Jede Funktion, die du nicht baust, kann nicht angegriffen werden.

Zum Selbermachen

  1. Prüfe ein eigenes Projekt: Welche Konten oder Plugins haben mehr Rechte, als sie brauchen?
  2. Schreibe für eine kritische Aktion auf, welche drei voneinander unabhängigen Prüfungen sie absichern.

Verwandte Themen

Webanwendungen → „OWASP Top 10“ zeigt, was passiert, wenn Prinzipien wie Complete Mediation verletzt werden (Broken Access Control). Agentische KI → „Agenten: Sicherheit“ (Prompt Injection, Lethal Trifecta) und „KI-Sicherheit & Alignment“ zeigen, wie dieselben Grundideen auf KI-Systeme übertragen werden.

Prüfstatus: Belegt (Stand 1. Oktober 2026): Titel, Autoren, Jahr und die acht Prinzipien des Aufsatzes wurden gegen den Aufsatz bzw. Verzeichnisquellen geprüft. Die OWASP-Aussage zu CSP stammt aus dem XSS Prevention Cheat Sheet. Nicht einzeln belegt: die Übertragung der Prinzipien auf heutige Beispiele (Einordnung in eigenen Worten) und das Admin-Beispiel (konstruiert).

Quellen

  • Jerome H. Saltzer, Michael D. Schroeder – „The Protection of Information in Computer Systems“ (Proceedings of the IEEE, 1975)
  • OWASP Cheat Sheet Series – „Cross Site Scripting Prevention“