Sichere Systeme: Unterschied zwischen den Versionen
Keine Bearbeitungszusammenfassung |
Keine Bearbeitungszusammenfassung |
||
(33 dazwischenliegende Versionen desselben Benutzers werden nicht angezeigt) | |||
Zeile 1: | Zeile 1: | ||
'''Sicherer Systeme''' - Konstruktion sicherer Systeme | |||
== Beschreibung == | |||
; Entwicklungsprozess | |||
* Dezidierte Methoden bislang kaum entwickelt | * Dezidierte Methoden bislang kaum entwickelt | ||
; Allgemeine methodische Regeln | |||
* top-down Vorgehensweise aus Software-Engineering | * top-down Vorgehensweise aus Software-Engineering | ||
* Schwierig, da Angreifer viele Möglichkeiten hat | * Schwierig, da Angreifer viele Möglichkeiten hat | ||
; 1975 Saltzer und Schröder | |||
* | * Nach wie vor gültig | ||
===== Erlaubnis | == Allgemeine Prinzipien == | ||
; Allgemeine Konstruktionsprinzipien | |||
{| class="wikitable options" | |||
|- | |||
! Option !! Beschreibung | |||
|- | |||
| [[#Erlaubnis|Erlaubnis]] || fail-safe defaults | |||
|- | |||
| [[#Vollständigkeit|Vollständigkeit]] || complete mediation | |||
|- | |||
| [[#Need-to-Know|Need-to-Know]] || | |||
|- | |||
| [[#Benutzerakzeptanz|Benutzerakzeptanz]] || | |||
|- | |||
| [[#Offener Entwurf|Offener Entwurf]] || open design | |||
|- | |||
| [[#KISS - Prinzip|KISS - Prinzip]] || | |||
|- | |||
| [[#Validierung/Evaluierung|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 | * 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 === | |||
; 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 | * AppAmor | ||
* SELinux | * SELinux | ||
* Rollenbasierte Rechte | * Rollenbasierte Rechte | ||
=== Benutzerakzeptanz === | |||
; Sicherheitsmechanismen müssen | |||
* 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 | |||
* 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 | ||
* No security through obscurity | * No security through obscurity | ||
Zeile 48: | Zeile 71: | ||
* „Schlüssel unter der Fußmatte“ | * „Schlüssel unter der Fußmatte“ | ||
=== KISS - Prinzip === | |||
[[Keep it simple, stupid]] | [[Keep it simple, stupid]] | ||
=== Validierung/Evaluierung === | |||
; Üben und Testen | |||
;Testen | |||
* Methodisches Testen des implementierten Systems | * Methodisches Testen des implementierten Systems | ||
* Verifizierung der sicherheitsrelevanten Funktionen | * Verifizierung der sicherheitsrelevanten Funktionen | ||
Zeile 64: | Zeile 84: | ||
* Evaluierung durch Dritte | * Evaluierung durch Dritte | ||
[[Kategorie: | <noinclude> | ||
== Anhang == | |||
=== Siehe auch === | |||
{{Special:PrefixIndex/{{BASEPAGENAME}}}} | |||
==== Links ==== | |||
===== Projekt ===== | |||
===== Weblinks ===== | |||
[[Kategorie:Entwurf]] | |||
</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