mirror of
https://github.com/theoleuthardt/hwr-notes.git
synced 2026-06-06 02:21:07 +00:00
docs: add obsidian hwr docs
This commit is contained in:
theoleuthardt
parent
b2636f4b92
commit
850aa3455d
245 changed files with 30757 additions and 0 deletions
|
|
@ -0,0 +1,314 @@
|
|||
# Sicherungskonzepte – Zusammenfassung
|
||||
**Dozent:** A. Zimmermann | HWR Berlin | 2026 | **Folien 1–49**
|
||||
|
||||
---
|
||||
|
||||
## 1. Einführung (Folien 1–12)
|
||||
|
||||
### Datensicherheit (Folie 3)
|
||||
|
||||
**Datensicherheit** = Alle technischen und organisatorischen Maßnahmen zum Schutz der Daten vor **Verfälschung, Zerstörung und unzulässiger Weitergabe**.
|
||||
|
||||
- Informationssicherheit ist nicht nur Technik, sondern auch abhängig von **organisatorischen und personellen** Rahmenbedingungen
|
||||
- Das **BSI** (Bundesamt für Sicherheit in der Informationstechnik) veröffentlicht das IT-Grundschutzhandbuch (ab 2005: IT-Grundschutz-Kataloge) unter www.bsi.bund.de
|
||||
|
||||
### Schadenskategorien (Folien 5–6)
|
||||
|
||||
| Kategorie | Beschreibung | Beispiel |
|
||||
|---|---|---|
|
||||
| **Verlust der Verfügbarkeit** | Grundlegende Informationen nicht vorhanden | Keine Geldtransaktionen, Online-Bestellungen oder Produktionsprozesse möglich |
|
||||
| **Verlust der Vertraulichkeit** | Ungewollte Offenlegung von Informationen | Personenbezogene Daten, Umsatz, Marketing, Forschungsdaten gelangen an Konkurrenz |
|
||||
| **Verlust der Integrität** | Gefälschte Daten | Fehlbuchungen, falsche Lieferungen, fehlerhafte Produkte |
|
||||
| **Verlust der Authentizität** | Daten falscher Person zugeordnet | Zahlungsanweisungen zu Lasten Dritter, falsche digitale Willenserklärungen |
|
||||
|
||||
### Relevante Gesetze (Folie 7)
|
||||
|
||||
| Gesetz | Kürzel | Jahr |
|
||||
|---|---|---|
|
||||
| Bundesdatenschutzgesetz | BDSG | 1990/2003/2009 |
|
||||
| Telekommunikationsgesetz | TKG | 2004 |
|
||||
| Telemediengesetz | TMG | 2007 |
|
||||
| Signaturgesetz | SigG | 2001 |
|
||||
| Diverse Landesdatenschutzgesetze | — | — |
|
||||
|
||||
### Grundprinzipien der Sicherheit (Folien 8–12)
|
||||
|
||||
| Prinzip | Beschreibung |
|
||||
|---|---|
|
||||
| **Authentifizierung** | Subjekte (Benutzer, Rechner, Dienste) müssen ein Konto besitzen und sich mit gültigem Anmeldenamen + Kennwort anmelden; moderne DB erlauben auch Betriebssystem-Authentifizierung und Zertifikate |
|
||||
| **Autorisierung** | System muss Zugriffsrechte implementieren: Leserechte (ohne Änderung), Änderungsrechte (inkl. Lesen), volle Rechte (inkl. Weitergabe); Verweigerung/Entziehung möglich |
|
||||
| **Protokollierung** | Alle wichtigen Vorgänge müssen überwacht werden: Lesen/Ändern/Löschen, Anmeldung, DB-Start/Stop, Kontenverwaltung; Mindestangaben: **wer**, **was**, **wann**; in Oracle: **Auditing** |
|
||||
|
||||
**Beispiel Verletzung:** Web-Server ordnet alle Anfragen einem pauschalen Konto zu → Verletzung der Authentifizierung → potenzieller Angreifer kann unsinnige Anfragen senden.
|
||||
|
||||
---
|
||||
|
||||
## 2. Integrität (Folien 13–23)
|
||||
|
||||
### Definition (Folie 14)
|
||||
|
||||
**Integrität (Konsistenz)** = Zustand der Daten, in dem sie korrekt, vollständig und widerspruchsfrei sind.
|
||||
|
||||
| Art | Beschreibung |
|
||||
|---|---|
|
||||
| **Semantische Integrität** | Werte gehören zum Wertebereich, richtige Datentypen, keine Tippfehler |
|
||||
| **Referentielle Integrität** | Korrektheit der Primär- und Fremdschlüssel, Existenz der Verweise |
|
||||
| **Logische Integrität** | Transaktionen, zusammengehörende Operationen |
|
||||
|
||||
### Gewährleistung der Integrität (Folie 15)
|
||||
|
||||
| Ebene | Beschreibung |
|
||||
|---|---|
|
||||
| **Datenbank** (bessere Lösung) | Klauseln in DDL-Anweisungen |
|
||||
| **Anwendung** (zusätzliche Lösung) | Programmcode der Anwendung |
|
||||
|
||||
**Vorteile der DB-Ebene** (Folie 16):
|
||||
- DB selbst gewährleistet Konsistenz → inkonsistente Zustände unmöglich
|
||||
- Ein-/Ausschaltbar (z. B. beim Import)
|
||||
- Standardisierte Möglichkeiten
|
||||
- Unabhängig von einzelnen Anwendungen
|
||||
- Schnellere Anwendungsentwicklung
|
||||
|
||||
### Integritätsverletzende Operationen (Folie 17)
|
||||
|
||||
- **DML:** INSERT, UPDATE, DELETE
|
||||
- **DDL:** ALTER, DROP, RENAME
|
||||
|
||||
### Aktionen bei Integritätsverletzung (Folie 18)
|
||||
|
||||
| Aktion | Beschreibung |
|
||||
|---|---|
|
||||
| **Rollback** | Abbrechen der Operation und Zurücksetzen auf Zustand davor |
|
||||
| **Cascade** | Propagieren der Operation auf alle beteiligten Tabellen |
|
||||
| **Set Null** | Betroffene Attribute auf NULL setzen |
|
||||
|
||||
### Referentielle Integrität (Folie 19)
|
||||
|
||||
Die Werte eines **Fremdschlüssels** müssen auch als Werte des **Primärschlüssels** vorhanden sein.
|
||||
|
||||
### Constraint-Typen (Folie 20)
|
||||
|
||||
| Constraint | Beschreibung |
|
||||
|---|---|
|
||||
| **PRIMARY KEY** | Attribut(e) bilden primären Schlüssel; automatisch wird Index angelegt (Oracle) |
|
||||
| **FOREIGN KEY** | Attribut(e) bilden PK in einer anderen Tabelle |
|
||||
| **ON DELETE CASCADE** | Löschen in PK-Tabelle löscht auch FK-Datensätze |
|
||||
| **NOT NULL** | Attribut muss einen Wert haben |
|
||||
| **UNIQUE** | Werte sind einmalig |
|
||||
| **CHECK** | Logischer Ausdruck muss wahr sein |
|
||||
|
||||
### Beispiele (Folien 21–22)
|
||||
|
||||
```sql
|
||||
CREATE TABLE Studenten (
|
||||
MatrNr INTEGER PRIMARY KEY,
|
||||
Name VARCHAR(30) NOT NULL,
|
||||
Semester INTEGER CHECK Semester BETWEEN 1 AND 13
|
||||
);
|
||||
|
||||
CREATE TABLE Professoren (
|
||||
PersNr INTEGER PRIMARY KEY,
|
||||
Name VARCHAR(30) NOT NULL,
|
||||
Rang CHAR(2) CHECK (Rang IN ('C2', 'C3', 'C4')),
|
||||
Raum INTEGER UNIQUE
|
||||
);
|
||||
|
||||
CREATE TABLE voraussetzen (
|
||||
Vorgaenger INTEGER REFERENCES Vorlesungen(VorlNr) ON DELETE CASCADE,
|
||||
Nachfolger INTEGER REFERENCES Vorlesungen(VorlNr) ON DELETE NO ACTION,
|
||||
PRIMARY KEY (Vorgaenger, Nachfolger)
|
||||
);
|
||||
|
||||
CREATE TABLE pruefen (
|
||||
MatrNr INTEGER REFERENCES Studenten ON DELETE CASCADE,
|
||||
VorlNr INTEGER REFERENCES Vorlesungen,
|
||||
PersNr INTEGER REFERENCES Professoren,
|
||||
Note NUMERIC(2,1) CHECK (Note BETWEEN 0.7 AND 5.0),
|
||||
PRIMARY KEY (MatrNr, VorlNr)
|
||||
);
|
||||
```
|
||||
|
||||
### Trigger (Folie 23)
|
||||
|
||||
**Trigger** = Prozedur/Funktion, die bei bestimmten Ereignissen **automatisch** gestartet wird.
|
||||
|
||||
**Auslöser:**
|
||||
- DML: INSERT, DELETE, UPDATE
|
||||
- DDL: CREATE, ALTER, DROP
|
||||
- An-/Abmeldung, Start/Stop der DB
|
||||
|
||||
**Zeitpunkt:**
|
||||
|
||||
| Zeitpunkt | Beschreibung |
|
||||
|---|---|
|
||||
| **BEFORE** | Vor der Änderung |
|
||||
| **AFTER** | Nach der Änderung |
|
||||
| **INSTEAD OF** | Statt der Änderung |
|
||||
|
||||
---
|
||||
|
||||
## 3. Rechte (Folien 24–31)
|
||||
|
||||
### User/Schema-Konzept in Oracle (Folie 25)
|
||||
|
||||
- Zentral: **User (Benutzer)**, auch **Schema** genannt
|
||||
- Oracle-DB besteht aus verschiedenen Schemen, innerhalb derer ERM realisiert sind
|
||||
- Vordefinierte Benutzer: **SYS** und **SYSTEM** (alle Rechte)
|
||||
- Alle anderen Benutzer müssen erstellt und mit Rechten versehen werden
|
||||
|
||||
### Zugriffsrichtlinien (Folie 26)
|
||||
|
||||
Klare Richtlinien sollten festlegen: wer darf zugreifen, auf welche Ressourcen, welche Zugriffsart, an welchen Tagen/Uhrzeiten, von welchen Computern, wer erlaubt/informiert/protokolliert/abrechnet.
|
||||
|
||||
### Sicherheitsmechanismen (Folie 27)
|
||||
|
||||
| Mechanismus | Beschreibung |
|
||||
|---|---|
|
||||
| **DAC** (Discretionary Access Control) | Regel: {O, S, R, P, F} – Objekte, Subjekte, Zugriffsrechte, Prädikat, Recht zur Rechtevergabe |
|
||||
| **MAC** (Mandatory Access Control) | Hierarchie der Prozesse mit Markierungen (Einstufung); Kommunikation nur bei gleichem Niveau |
|
||||
|
||||
### Privilegien (Folie 28)
|
||||
|
||||
| Typ | Beispiele |
|
||||
|---|---|
|
||||
| **Systemprivilegien** | Anmeldung, Anlegen/Löschen von Tabellen/Benutzern/Prozeduren, Abfragen von Systemtabellen, Verwaltung von Tablespaces |
|
||||
| **Objektprivilegien** | Abfragen von Tabellen, Ändern von Inhalten, Verwenden von Funktionen |
|
||||
|
||||
**Empfehlung:** Sinnvolle **Rollenmatrix** erstellen; Benutzer bekommen keine Privilegien direkt, sondern über **Rollen**.
|
||||
|
||||
### Benutzerverwaltung (Folien 29–31)
|
||||
|
||||
```sql
|
||||
-- Benutzer erstellen
|
||||
DROP USER Student07;
|
||||
CREATE USER Student07 IDENTIFIED BY system
|
||||
DEFAULT TABLESPACE users
|
||||
TEMPORARY TABLESPACE temp
|
||||
QUOTA UNLIMITED ON users;
|
||||
|
||||
-- Passwort ändern
|
||||
ALTER USER Student07 IDENTIFIED BY System01;
|
||||
|
||||
-- Rolle erstellen und Rechte vergeben
|
||||
DROP ROLE StudentRole;
|
||||
CREATE ROLE StudentRole;
|
||||
GRANT CREATE session, CREATE table, CREATE view,
|
||||
CREATE synonym, CREATE procedure, CREATE trigger
|
||||
TO StudentRole;
|
||||
GRANT StudentRole TO Student07;
|
||||
|
||||
-- Objektprivilegien (direkt, nicht empfohlen)
|
||||
GRANT SELECT ON Tabelle13 TO Student07, Student08;
|
||||
GRANT INSERT, SELECT ON Student03.TabelleA TO Student07;
|
||||
GRANT ALL ON database TO dba_user02;
|
||||
|
||||
-- Spalten-basierte Rechte
|
||||
GRANT UPDATE (Spalte1), INSERT (Spalte2, Spalte3)
|
||||
ON Tabelle52 TO Student07;
|
||||
```
|
||||
|
||||
**Befehle:** Nur **GRANT** (Rechte vergeben) und **REVOKE** (Rechte entziehen).
|
||||
|
||||
---
|
||||
|
||||
## 4. Backup (Folien 32–49)
|
||||
|
||||
### Definition (Folien 33–34)
|
||||
|
||||
**Backup (Datensicherung)** = Speicherung der Daten, mit der ein System nicht direkt arbeitet.
|
||||
|
||||
**Eigenschaften:**
|
||||
- Kann mehrere Dateien und Verzeichnisse beinhalten
|
||||
- Kann wie eine oder mehrere Dateien aussehen
|
||||
- Kann verschlüsselt und/oder komprimiert sein
|
||||
- Kann sich über mehrere Datenträger verbreiten
|
||||
|
||||
**Backup-Archiv** = Sammlung von mehreren Backups.
|
||||
|
||||
**Zwecke:**
|
||||
1. Wiederherstellung nach Absturz
|
||||
2. Wiederherstellung eines bestimmten Zeitpunkts für Statistik (z. B. Jahresbericht)
|
||||
3. Wiederherstellung für planmäßige Funktionalität (z. B. Forschungsprojekte)
|
||||
|
||||
**Regel:** In allen nicht privaten Systemen muss man immer Backup planen und regelmäßig durchführen.
|
||||
|
||||
### RAID (Folien 35–38)
|
||||
|
||||
**RAID** (Redundant Array of Inexpensive/Independent Disks) ist **kein Backup**!
|
||||
|
||||
| Eigenschaft | Beschreibung |
|
||||
|---|---|
|
||||
| Funktion | Redundante Speicherung auf mehreren Festplatten |
|
||||
| Bei Ausfall | Daten können von anderer Platte gelesen/geschrieben werden |
|
||||
| Hot-Swap | Kaputte Platte im laufenden Betrieb austauschbar |
|
||||
| Software-RAID | Von fast allen Betriebssystemen unterstützt |
|
||||
| Hardware-RAID | Betriebssystemunabhängig |
|
||||
|
||||
- RAID erfüllt **keine** Backup-Funktionen
|
||||
- RAID kann als **Speicherort** für Backup verwendet werden
|
||||
|
||||
### Oracle Backup-Tools (Folie 39)
|
||||
|
||||
| Tool | Beschreibung |
|
||||
|---|---|
|
||||
| **exp/imp** | Ältere Versionen |
|
||||
| **expdp/impdp** | Neuere Versionen (Data Pump) |
|
||||
| **RMAN** | Recovery Manager |
|
||||
|
||||
**Weitere Tools (Folie 40):** Linux (cp, tar, bzip, gzip, dd), Windows (copy, Server-Sicherung), Drittanbieter (Acronis, Paragon, Fwbackups, Bacula).
|
||||
|
||||
### Backup-Medien (Folien 41–42)
|
||||
|
||||
| Medium | Beschreibung |
|
||||
|---|---|
|
||||
| **DAS** | Direct Attached Storage (lokale Festplatte) |
|
||||
| **NAS** | Network Attached Storage (Netzwerk) |
|
||||
| **SAN** | Storage Area Network (Netzwerk) |
|
||||
| Magnetband | Bandlaufwerk mit Roboter, bis zu 4 GiB |
|
||||
| CD/DVD/Blu-Ray | Optische Medien |
|
||||
| USB-Geräte | Externe Speicher |
|
||||
| FireWire-Geräte | Externe Speicher |
|
||||
| Cloud | Sicherheit bedenklich |
|
||||
|
||||
**Generationsprinzip (Großvater–Vater–Sohn):**
|
||||
- 3 Datenträger rotierend: 1. Sicherung → Großvater, 2. → Vater, 3. → Sohn
|
||||
- 4. Sicherung: Großvater wird zum Sohn überschrieben, Rollen rotieren
|
||||
- Je mehr Datenträger, desto sicherer
|
||||
|
||||
### Backup-Methoden (Folie 43)
|
||||
|
||||
| Methode | Beschreibung |
|
||||
|---|---|
|
||||
| **Online/Hot Backup** | DB läuft weiter, Daten werden im laufenden Betrieb gesichert; Gefahr: nicht-konsistenter Zustand; DB liefert spezifische Lösungen |
|
||||
| **Offline/Cold Backup** | DB wird heruntergefahren, geschlossene Dateien kopiert; Datenbestand ist **immer konsistent** |
|
||||
|
||||
### Sicherungsarten (Folien 44–47)
|
||||
|
||||
| Art | Umfang | Markierung? | Wiederherstellung | Vorteil/Nachteil |
|
||||
|---|---|---|---|---|
|
||||
| **Normal** | Alle ausgewählten Daten | Ja (als gesichert) | Nur diese Sicherung | Einfach, aber groß |
|
||||
| **Kopie** | Wie Normal | Nein | — | Keine Auswirkung auf andere Strategien |
|
||||
| **Täglich** | Nur heute geänderte Daten | Ja | — | Klein, tagesbezogen |
|
||||
| **Inkrementell** | Nur seit letzter Sicherung geänderte Daten | Ja | Letzte Normal + alle Inkrementellen in Reihenfolge | Wenig Zeit/Speicher, aber aufwändige Wiederherstellung |
|
||||
| **Differenziell** | Nur seit letzter normaler Sicherung geänderte Daten | Nein | Letzte Normal + letzte Differenzielle | Einfache Wiederherstellung, aber wachsende Größe |
|
||||
|
||||
### Sicherungsstrategien (Folie 48)
|
||||
|
||||
| Strategie | Beispiel |
|
||||
|---|---|
|
||||
| Nur normale Sicherungen | Monatlich |
|
||||
| Normal + Inkrementell | Jährlich normal, monatlich inkrementell |
|
||||
| Normal + Differenziell | Jährlich normal, monatlich differenziell |
|
||||
|
||||
**Wichtig:** Anforderungen des Unternehmens und Speicherbedarf müssen berücksichtigt werden.
|
||||
|
||||
---
|
||||
|
||||
## Zusammenfassung
|
||||
|
||||
| Bereich | Kernkonzepte |
|
||||
|---|---|
|
||||
| **Grundprinzipien** | Authentifizierung, Autorisierung, Protokollierung |
|
||||
| **Integrität** | Semantisch, Referentiell, Logisch; Constraints (PK, FK, NOT NULL, UNIQUE, CHECK); Trigger |
|
||||
| **Rechte** | DAC/MAC, System-/Objektprivilegien, Rollen, GRANT/REVOKE |
|
||||
| **Backup** | Hot/Cold, Normal/Inkrementell/Differenziell, RAID ≠ Backup, Generationsprinzip |
|
||||
Loading…
Add table
Add a link
Reference in a new issue