Sichere Systeme: Unterschied zwischen den Versionen
Keine Bearbeitungszusammenfassung |
|||
| (19 dazwischenliegende Versionen desselben Benutzers werden nicht angezeigt) | |||
| Zeile 1: | Zeile 1: | ||
''' | '''Sicherer Systeme''' - Konstruktion sicherer Systeme | ||
== Beschreibung == | == Beschreibung == | ||
; Entwicklungsprozess | ; Entwicklungsprozess | ||
| Zeile 8: | Zeile 9: | ||
* Schwierig, da Angreifer viele Möglichkeiten hat | * Schwierig, da Angreifer viele Möglichkeiten hat | ||
; 1975 Saltzer und Schröder | ; 1975 Saltzer und Schröder | ||
* Nach wie vor gültig | * Nach wie vor gültig | ||
== Allgemeine Prinzipien == | |||
; Allgemeine Konstruktionsprinzipien | ; Allgemeine Konstruktionsprinzipien | ||
{| class="wikitable options" | {| class="wikitable options" | ||
| Zeile 17: | Zeile 18: | ||
! Option !! Beschreibung | ! Option !! Beschreibung | ||
|- | |- | ||
| Erlaubnis | | [[#Erlaubnis|Erlaubnis]] || fail-safe defaults | ||
|- | |- | ||
| Vollständigkeit | | [[#Vollständigkeit|Vollständigkeit]] || complete mediation | ||
|- | |- | ||
| Need-to-Know || | | [[#Need-to-Know|Need-to-Know]] || | ||
|- | |- | ||
| Benutzerakzeptanz || | | [[#Benutzerakzeptanz|Benutzerakzeptanz]] || | ||
|- | |- | ||
| Offener Entwurf | | [[#Offener Entwurf|Offener Entwurf]] || open design | ||
|- | |- | ||
| KISS - Prinzip || | | [[#KISS - Prinzip|KISS - Prinzip]] || | ||
|- | |- | ||
| Validierung / Evaluierung || | | [[#Validierung/Evaluierung|Validierung/Evaluierung]] || | ||
|} | |} | ||
=== Erlaubnis | === Erlaubnis === | ||
; Verbot mit Erlaubnisvorbehalt | ; Fail-Safe Defaults | ||
* Grundsätzlich jeder Zugriff verboten | * Verbot mit Erlaubnisvorbehalt | ||
* | * Grundsätzlich ist jeder Zugriff verboten | ||
* Default Deny | |||
* Nur durch explizite Erlaubnis wird Zugriffsrecht gewährt | * Nur durch explizite Erlaubnis wird Zugriffsrecht gewährt | ||
* Whitelisting | * [[Whitelisting]] | ||
=== Vollständigkeit === | === Vollständigkeit === | ||
; Jeder Zugriff ist auf Zulässigkeit zu prüfen! | ; Jeder Zugriff ist auf Zulässigkeit zu prüfen! | ||
Complete Mediation | ; Complete Mediation | ||
* System, das nur beim Öffnen Erlaubnis prüft, nicht bei jedem Schreiben, verletzt das Prinzip | * System, das nur beim Öffnen Erlaubnis prüft, nicht bei jedem Schreiben, verletzt das Prinzip | ||
* Rechte können sich zwischendurch verändert haben | * Rechte können sich zwischendurch verändert haben | ||
=== Need-to-Know === | === Need-to-Know === | ||
; Prinzip der minimalen Rechte | |||
* Jedes Subjekt bekommt nur genau die Zugriffsrechte, die es zur Erfüllung seiner Aufgaben benötigt | * Jedes Subjekt bekommt nur genau die Zugriffsrechte, die es zur Erfüllung seiner Aufgaben benötigt | ||
; Systeme, in dem Administratoren unbeschränkte Rechte haben, verstoßen gegen dieses Prinzip | |||
* AppAmor | * AppAmor | ||
* SELinux | * SELinux | ||
* Rollenbasierte Rechte | * Rollenbasierte Rechte | ||
=== Benutzerakzeptanz === | === Benutzerakzeptanz === | ||
| Zeile 59: | Zeile 61: | ||
* einfach zu nutzen sein | * einfach zu nutzen sein | ||
* routinemäßig und automatisch angewandt werden | * routinemäßig und automatisch angewandt werden | ||
* Akzeptanz (economy of mechanism) | |||
=== Offener Entwurf (open design) | === Offener Entwurf === | ||
; Offener Entwurf (open design) | |||
; Sicherheit eines Systems darf nicht von der Geheimhaltung spezieller Verfahren abhängig sein | ; Sicherheit eines Systems darf nicht von der Geheimhaltung spezieller Verfahren abhängig sein | ||
* Verwendete Verfahren und Mechanismen, die beim Entwurf des Systems verwendet werden, müssen offen gelegt werden | * Verwendete Verfahren und Mechanismen, die beim Entwurf des Systems verwendet werden, müssen offen gelegt werden | ||
| Zeile 70: | Zeile 74: | ||
[[Keep it simple, stupid]] | [[Keep it simple, stupid]] | ||
=== Validierung / Evaluierung === | === Validierung/Evaluierung === | ||
;Testen | ; Üben und Testen | ||
* Methodisches Testen des implementierten Systems | * Methodisches Testen des implementierten Systems | ||
* Verifizierung der sicherheitsrelevanten Funktionen | * Verifizierung der sicherheitsrelevanten Funktionen | ||
| Zeile 89: | Zeile 93: | ||
===== Weblinks ===== | ===== Weblinks ===== | ||
[[Kategorie: | [[Kategorie:Entwurf]] | ||
</noinclude> | </noinclude> | ||
Aktuelle Version vom 9. Dezember 2023, 07:46 Uhr
Sicherer Systeme - Konstruktion sicherer Systeme
Beschreibung
- Entwicklungsprozess
- Dezidierte Methoden bislang kaum entwickelt
- Allgemeine methodische Regeln
- top-down Vorgehensweise aus Software-Engineering
- Schwierig, da Angreifer viele Möglichkeiten hat
- 1975 Saltzer und Schröder
- Nach wie vor gültig
Allgemeine Prinzipien
- Allgemeine Konstruktionsprinzipien
| Option | Beschreibung |
|---|---|
| Erlaubnis | fail-safe defaults |
| Vollständigkeit | complete mediation |
| Need-to-Know | |
| Benutzerakzeptanz | |
| Offener Entwurf | open design |
| KISS - Prinzip | |
| Validierung/Evaluierung |
Erlaubnis
- Fail-Safe Defaults
- Verbot mit Erlaubnisvorbehalt
- Grundsätzlich ist jeder Zugriff verboten
- Default Deny
- Nur durch explizite Erlaubnis wird Zugriffsrecht gewährt
- Whitelisting
Vollständigkeit
- Jeder Zugriff ist auf Zulässigkeit zu prüfen!
- Complete Mediation
- System, das nur beim Öffnen Erlaubnis prüft, nicht bei jedem Schreiben, verletzt das Prinzip
- Rechte können sich zwischendurch verändert haben
Need-to-Know
- Prinzip der minimalen Rechte
- Jedes Subjekt bekommt nur genau die Zugriffsrechte, die es zur Erfüllung seiner Aufgaben benötigt
- Systeme, in dem Administratoren unbeschränkte Rechte haben, verstoßen gegen dieses Prinzip
- AppAmor
- SELinux
- Rollenbasierte Rechte
Benutzerakzeptanz
- Sicherheitsmechanismen müssen
- einfach zu nutzen sein
- routinemäßig und automatisch angewandt werden
- Akzeptanz (economy of mechanism)
Offener Entwurf
- Offener Entwurf (open design)
- Sicherheit eines Systems darf nicht von der Geheimhaltung spezieller Verfahren abhängig sein
- Verwendete Verfahren und Mechanismen, die beim Entwurf des Systems verwendet werden, müssen offen gelegt werden
- No security through obscurity
- Sicherheit kryptografischer Verfahren sollte nicht darauf basieren, dass Verschlüsselungsverfahren nicht bekannt ist.
- „Schlüssel unter der Fußmatte“
KISS - Prinzip
Validierung/Evaluierung
- Üben und Testen
- Methodisches Testen des implementierten Systems
- Verifizierung der sicherheitsrelevanten Funktionen
- Testziele, -pläne, -verfahren festlegen, dokumentieren.
- Vollständigkeit der Tests
- Code Review
- Evaluierung durch Dritte