5.1 Einführung

5 Datenschutz und Datensicherheit
5.1
Einführung
! Datenschutz bedeutet Schutz der Persönlichkeitsrechte, nicht (primär) den Schutz der Daten
! Datensicherheit bedeutet Schutz der Daten vor unberechtigtem Zugriff und vor Manipulation
! Datensicherung bedeutet Schutz der Daten vor unbeabsichtigter Zerstörung und Höherer Ge”
walt“
=⇒ Mehrbenutzer-Kontrolle und Recovery-Maßnahmen
! Eigentliches Problem: Schutz der Information
" Information = Daten im Kontext
Beispiel 5-1: Eine an sich harmlose“ Datei mit Daten von Patienten mit Gerinnungsstörun”
gen ( Bluter-Datei“) erlangt hohe Sensitivität durch zusätzliches (externes) Wissen“ (→
”
”
HIV–Risikogruppe“).
”
" Die Relation zwischen zwei Entities ist oft sensitiver als die Entities selbst.
Beispiel 5-2: Erlaubter Zugriff auf Mitarbeiter(PersNr, Name, Adresse) und auf Gehaltsgruppen(GrNr, Gehalt); keine Erlaubnis, die Relation zu verfolgen (Annahme: Mitarbeiter-Attribut
Gehaltsgruppe ausgeblendet).
c M. Scholl, 2004/05 – Informationssysteme: 5. Datenschutz und Datensicherheit
#
5-1
! Gefahrenpotential:
" Verletzung der Privatsphäre
Problem: juristisch und ethisch schwer fassbar
" Freisetzung geheimer Daten
! direkt (Durchsickern)
! indirekt (Ableiten)
Problem:
Oft fehlendes Unrechtsbewusstsein, da man Information nicht stehlen“, sondern
”
nur teilen“ kann
”
" Manipulation zugänglicher Daten
! Manipulation im kleinen“:
”
(Einfügen und Löschen von Teilen, Ändern, Kopieren)
! Manipulation im großen“:
”
(Überschreiben, Löschen)
! Ursachen:
" kritische (sensitive) Daten und Relationen
" unverträgliche (unsichere, inkompatible) Software
" verletzliche Systeme (mangelnde Schutzvorkehrungen)
c M. Scholl, 2004/05 – Informationssysteme: 5. Datenschutz und Datensicherheit
#
5-2
5.2
Datenschutz
! Bundesdatenschutzgesetz (BDSG, 1990)
" Zweck und Anwendungsbereich (§1 BDSG)
Zweck dieses Gesetzes ist es, den einzelnen davor zu schützen, dass er durch den Umgang
”
mit seinen personenbezogenen Daten in seinem Persönlichkeitsrecht beeinträchtigt wird.“
! . . . gilt für die Erhebung, Verarbeitung und Nutzung personenbezogener Daten. . .“
”
! Geltung für öffentliche Stellen des Bundes (und der Länder, soweit nicht ein Landes-DSG
geregelt) und für nicht-öffentliche Stellen (natürliche und juristische Personen)
!
" Prinzipien im BDSG
! Zulässigkeit der Datenverarbeitung und -nutzung (§4 BDSG)
# durch ein Gesetz oder andere Rechtsvorschrift erlaubt bzw. angeordnet oder
# aufgrund der Einwilligung des Betroffenen
! Datengeheimnis (§5 BDSG), Zweckbindung (§39 BDSG)
# unbefugte Verarbeitung bzw. Nutzung verboten
! Rechte des Betroffenen
# Recht auf Auskunft
# Recht auf Berichtigung, Sperrung und Löschung
# Anrufung des Datenschutz-Beauftragten
Diese Rechte können nicht ausgeschlossen oder beschränkt werden!
! Anonymisierung bei sonstiger Verwendung
c M. Scholl, 2004/05 – Informationssysteme: 5. Datenschutz und Datensicherheit
#
5-3
" Technische und Organisatorische Maßnahmen (§9 BDSG)
! Zugangskontrolle
(Unbefugten den Zugang zu den EDV-Anlagen verwehren)
! Datenträgerkontrolle
(Unbefugtes Lesen, Kopieren, Verändern und Entfernen von Datenträgern verhindern)
! Speicherkontrolle
(Unbefugte Eingabe sowie Kenntnisnahme, Veränderung und Löschung von Daten verhindern)
! Benutzerkontrolle
(Bei Nutzung der Systeme und der Datenübertragung)
! Zugriffskontrolle
(Zugriff nur der Zugriffsberechtigung entsprechend)
! Übermittlungskontrolle
(Feststellung und Überprüfung der Kommunikationspartner)
! Eingabekontrolle
(Feststellung und Überprüfung: welche personenbezogenen Daten wann von wem eingegeben werden)
! Auftragskontrolle
(Verarbeitung ausschließlich den Weisungen des Auftraggebers entsprechend)
! Transportkontrolle
(kein Unbefugtes Lesen, Kopieren, Verändern und Löschen bei der Datenübertragung bzw. beim Datenträger-Transport)
! Organisationskontrolle
(Organisation gemäß den Anforderungen des BDSG gestalten)
c M. Scholl, 2004/05 – Informationssysteme: 5. Datenschutz und Datensicherheit
#
5-4
5.3
5.3.1
Datensicherheit
Überblick
! Mechanismen an der Systemschnittstelle
" Benutzer-Identifikation
" Authentifizierung
! Interne Sicherheitsmechanismen
" Zugriffskontrolle
" Datenflusskontrolle
" Inferenz-Kontrollmechanismen
" Kryptographie
c M. Scholl, 2004/05 – Informationssysteme: 5. Datenschutz und Datensicherheit
#
5-5
5.3.2
Benutzer-Identifikation und Authentifizierung
Identifikation
! Frage: An welchen Nachweis kann der Informationszugriff gebunden sein?
" universell gültige Eigenschaft, die einen Menschen von allen anderen Menschen abgrenzt
Beweis: Identifikator (z.B. Fingerabdruck, Passwort)
" in einem bestimmten Kontext gültige Eigenschaft eines Menschen
Beispiel: Qualifikation eines Arztes Beweis: Credential (z.B. Diplom)
Authentifikation
! Prüfung der Identität/von Eigenschaften von Personen und Instanzen (z.B. Computersysteme);
erforderlich für ACLs und persönliche Capabilities
" Personen: Benutzerauthentifikation in Informationssystemen
" Instanzen: z.B. Authentifikation von Servern in Netzwerken über kryptographische Protokolle
c M. Scholl, 2004/05 – Informationssysteme: 5. Datenschutz und Datensicherheit
#
5-6
Arten von Benutzerauthentifikation
. . . basierend auf
! Wissen
" Identifikatoren: Passwörter, PINs, Unterschriften
" Credentials: Kenntnisse
" Nachteile: bewusste oder unbewusste Weitergabe
! Besitz
" Identifikatoren: Ausweise
" Credentials: Zeugnisse, Schlüssel, Karten
" Nachteile: Diebstahl, Weitergabe
! Biometrie
" Identifikatoren: Fingerabdruck, Retina, Sprache, Tastendruckverhalten
" Nachteile: nicht rückrufbar“
”
c M. Scholl, 2004/05 – Informationssysteme: 5. Datenschutz und Datensicherheit
#
5-7
5.3.3
Autorisierung (Zugriffskontrolle)
5.3.3.1
Einschränkung des Weltausschnitts
! Sichten-Konzept in (relationalen) Datenbanken
" Einschränkung der Attributmenge (Projektion): Verstecken“ von nicht benötigten/nicht be-
”
rechtigten Attributen
" kann z.T. auch das Verfolgen von Beziehungen verhindern (vgl. Beispiel 5-2: Mitarbeiter ⇐⇒
Gehaltsgruppe)
" Einschränkung der sichtbaren Wertemenge (Selektion)
! Abstrakte Datentypen
" Information-Hiding, keine Information über Interna
" Zugriff nur über definiertes Interface ggf. keine Änderung, nur eingeschränkte Anfragen usw.
" in manchen Datenbanksystemen: stored procedures“
”
! Shells
" oft menugesteuerte Programme
" eingeschränkte Funktionalität, angepasst an die Benutzer (-gruppe)
" entsprechend dem ADT-Konzept
c M. Scholl, 2004/05 – Informationssysteme: 5. Datenschutz und Datensicherheit
#
5-8
5.3.3.2
Autorisierungsmechanismen
! In den meisten heute verfügbaren (Mehrbenutzer-) Betriebs- und Datenbanksystemen vorhanden.
Zutrittskontrolle
Zugangskontrolle
Zugriffskontrolle
" Zutrittskontrolle: logistische Maßnahmen ( verschlossene Türen“)
”
" Zugangskontrolle: Identifikation und Authentifizierung von Benutzern
" Zugriffskontrolle: Durchsetzung von Einschränkungen beim Zugriff auf Informationen und
Dienste in Kombination mit Rechteverwaltung und -überprüfung
Grundlage: elementares Zugriffsmodell
! Subjekte S: aktiv handelnde Einheiten, die
Subjekt (S)
Operation (Op)
Objekt (O)
! Zugriffsoperationen Op auf
! Objekten O ausführen.
c M. Scholl, 2004/05 – Informationssysteme: 5. Datenschutz und Datensicherheit
#
5-9
! Konzept der Zugriffskontrollmatrix
" Matrix (Subjekt × Objekt → Recht) (welcher Benutzer darf was mit welchen Objekten tun)
" Subjekt: jeder Benutzer und damit jeder Prozess, der durch einen identifizierbaren Benutzer
gestartet wurde
" Objekt: Datei, Relation, Record, Feld
" Recht: erlaubte Operation (verschiedene Ausprägungen)
! see, search: feststellen der Objekt-Existenz
! pass: feststellen einer Beziehung
! move, copy: Transport eines Objektes bzw. des Inhalts
! execute: Ausführung eines (Programm-)Objekts
! read: lesen des Objektes (des Inhalts)
! write, change: verändern eines Objektes
! extend: erweitern eines Objektes
! delete: löschen des Objektes
! control: ändern der Zugriffsrechte für ein Objekt
oft auch Eigentümer-Konzept:
! own: potentiell alle Rechte am Objekt, Selbstbeschränkung“ möglich
”
c M. Scholl, 2004/05 – Informationssysteme: 5. Datenschutz und Datensicherheit
#
5-10
! Verwaltung der Zugriffskontrollmatrix — Problem: Matrix ist u.U. sehr groß
1. Lösungsansatz: Partitionierung
" Access Control List (ACL)
⇒ Liste der Berechtigten beim Objekt
⊕ günstig bei relativ geringer Benutzeranzahl
Subjekt (S)
Operation
Objekt (O)
" Capability-List (Bsp: read-password für File)
⇒ je Objekt ein Codewort,
⇒ je Benutzer eine Liste der Codewörter für Objekte
⊕ Schnelle Prüfung der Berechtigung (HW-Unterstützung)
' Es kann Objekte geben, zu denen niemand Rechte besitzt
' Keine Möglichkeit des selektiven Rechte-Entzugs (Codewort geändert =⇒ Recht allen Subjekten entzogen)
Subjekt (S)
Operation
Capabity
Objekt (O)
2. Lösungsansatz: Hierarchisierung
" Gruppen für Subjekte (d.h. Benutzergruppen)
Beispiel: UNIX verwaltet die Berechtigungen in einer dreistufigen Hierarchie der Benutzer:
owner (der Eigentümer), group (Benutzergruppe des Eigentümers) und world (Rest der
Welt)
" Verzeichnis-Strukturen (directories) für Objekte
Dieses Konzept ist in den meisten Betriebssystemen realisiert
c M. Scholl, 2004/05 – Informationssysteme: 5. Datenschutz und Datensicherheit
#
5-11
! Mögliche Erweiterungen der Zugriffskontrollmatrix
" Wertabhängigkeit (Zugriffsrecht abh. vom Objekt-Inhalt)
" Kontextabhängigkeit (Terminal-ID, Uhrzeit,...)
! Vergabe und Entzug von Berechtigungen
" Es darf keine Rechte-Erweiterung möglich sein!
" Jedes neue Subjekt erbt“ die Berechtigungen des Vaters
”
" Weitergabe der Rechte u.U. möglich
Beispiel: SQL: Jan vergibt ein Leserecht an Klaus
..GRANT
..ON
..TO
..WITH
SELECT
MITARBEITER
KLAUS
GRANT OPTION
Recht
Objekt (Mitarbeiter-Relation)
Adressat
Klaus darf das Recht weitergeben
" Rechte-Entzug ggf. kaskadierend!
Beispiel: SQL: Jan entzieht Klaus das Leserecht
..REVOKE SELECT
Recht
..ON
MITARBEITER Objekt (Mitarbeiter-Relation)
..FROM
KLAUS
Betroffener Benutzer
Entzug bei Partitionierung der Matrix (ACL, Capabilities) ist u.U. problematisch (s. oben)
c M. Scholl, 2004/05 – Informationssysteme: 5. Datenschutz und Datensicherheit
#
5-12
5.3.3.3
Autorisierung in SQL
! Syntaktische Grundstruktur in SQL:1

ff 
ff
8
9
<[ TABLE ] relview =
ON DOMAIN domain
:
;
...
GRANT
ALL PRIVILEGES
REVOKE
<privilege> [, <privilege>, . . . ]
ff

PUBLIC
TO
[ WITH GRANT OPTION ]∗)
userid1 [, userid2, . . . ]
8
SELECT
>
>
>
>
DELETE
>
>
<
INSERT [(Attrib1 [, Attrib2 , . . . ])]
<privilege> ::=
>
UPDATE [(Attrib1 [, Attrib2 , . . . ])]
>
>
>
>
>
:REFERENCES [(Attrib1 [, Attrib2 , . . . ])]
...
∗) nur in Verbindung mit GRANT wählbar
9
>
>
>
>
>
>
=
>
>
>
>
>
>
;
1 Entsprechend dem SQL 92 Standard
c M. Scholl, 2004/05 – Informationssysteme: 5. Datenschutz und Datensicherheit
#
5-13
! Wirkungsweise/Erläuterungen:
" Jeder Benutzer hat die volle Verfügungsgewalt (Lesen, Ändern, Löschen) über die von ihm/ihr
erzeugten ( privaten“) Relationen.
”
" Andere Benutzer haben per Default keinerlei Zugriffsrechte auf private“ Relationen anderer
”
Benutzer.
" Ein Benutzer kann Zugriffsrechte auf seine privaten“ Relationen an andere Benutzer (gezielt
”
oder an alle) vergeben.
" Die Art des Zugriffsrechts kann beschränkt werden (z.B. auf lesenden Zugriff)
" Beschränkung des Lesezugriffs auf ausgewählte Attribute mittels VIEW-Mechanismus.
" Beschränkung des Änderungsrechts (UPDATE) auf ausgewählte Attribute durch explizite An-
gabe der Attribute in der UPDATE-Klausel.
" Erteilung der Erlaubnis zur Weitergabe ( Vererbung“) von Zugriffsrechten (=⇒ WITH GRANT
OPTION).
”
c M. Scholl, 2004/05 – Informationssysteme: 5. Datenschutz und Datensicherheit
#
5-14
Weitergabe von Rechten und Entzug weitergegebener Rechte
Mit Hilfe des Zusatzes with grant option“ kann das Recht zur Weitergabe der verliehenen Rechte
”
vergeben werden
Beispiel 5-3: Nehmen wir an, DB-Benutzer Maier ist Eigentümer der Tabelle Angestellter. Maier
hat die Möglichkeit, Zugriffsrechte an DB-Benutzer zu vergeben. Maier setzt folgende DB-Befehle
ab:
GRANT SELECT ON Angestellter TO Seifert WITH GRANT OPTION
GRANT SELECT ON Angestellter TO Schulze WITH GRANT OPTION
Seifert und Schulze können nun das erhaltene Select-Recht an andere DB-Benutzer weitergeben.
Frage: Was geschieht mit weitergegebenen Rechten, wenn Maier die Rechte bei Seifert oder Schulze
wieder entzieht?
⇒ Rechte sollten auch von Dritten entzogen werden, es sei denn, diese haben das Recht auf anderem
”
Weg“ zusätzlich erhalten.
c M. Scholl, 2004/05 – Informationssysteme: 5. Datenschutz und Datensicherheit
#
5-15
Wirkung des REVOKE-Befehls
Syntax: REVOKE <privileges> [ON <relations>] FROM <users> [CASCADE]
Beispiele:
REVOKE SELECT ON Angestellter FROM Seifert
REVOKE UPDATE ON Angestellter FROM Seifert
REVOKE RESOURCE FROM Seifert
REVOKE DBA FROM Seifert CASCADE
Kaskadierende Rücknahme: Bei Zurücknahme von weitergegebenen Rechten werden die VergabePfade und Zeitpunkte analysiert. Die Zeitmarken werden verwendet, um zu entscheiden, ob ein
Recht überhaupt von einem bestimmten Benutzer vergeben worden sein kann.
Mit Hilfe eines DAG erfolgt eine Buchführung über Rechtevergabe und -weitergabe
! Knoten stellen die DB-Benutzer dar, die ein Select-Recht bei der Relation Angestellter haben
! Kanten indizieren die Richtung der Rechtevergabe
! Beschriftung der Kanten stellen Zeitstempel dar, die die Vergabezeit dokumentieren
c M. Scholl, 2004/05 – Informationssysteme: 5. Datenschutz und Datensicherheit
#
5-16
Beispiel 5-4: Benutzer B entzieht in der folgenden Situation dem Benutzer D das Select-Recht.
Ausgangssituation
10
B
30
A
40
E
60
F
70
Notation:
A – DB -Benutzer Mayer
B – DB -Benutzer Seifert
C – ...
G
D
20
50
C
Benutzer D muss nun so gestellt werden, als ob er das Select-Recht nie von B erhalten hätte.Für E,
F gilt: E kann das Recht nur auf dem Weg B–D erhalten haben, F dagegen auch über C–D.
Endsituation
10
B
A
D
20
50
C
60
F
Bei anderen Zeitstempeln im ansonsten gleichen DAG ergäbe sich bei demselben Rechteentzug:
Ausgangssituation
10
B
30
A
40
E
D
20
C
70
Endsituation
60
G
10
B
A
50
F
D
20
c M. Scholl, 2004/05 – Informationssysteme: 5. Datenschutz und Datensicherheit
#
C
70
5-17
REVOKE ohne kaskadierendes Zurücknehmen
Benutzer B entzieht Benutzer D ein zum Zeitpunkt 30 gewährtes Recht ohne CASCADE“:
”
Ausgangssituation
10
B
Endzustand
40
30
A
E
C
50
G
10
40
B
70
A
D
20
60
70
F
D
20
c M. Scholl, 2004/05 – Informationssysteme: 5. Datenschutz und Datensicherheit
#
C
50
E
60
G
F
70
5-18
Grundsätzliche Probleme
! Sichere Benutzeridentifikation/Authentifizierung Voraussetzung
! Berechtigungen (als Objekte) sind sehr schutzbedürftig
⇒ potentiell stärkerer Schutzmechanismus notwendig
! Schutz der Objekte, nicht des Inhalts
⇒ implizite Weitergabe und sogar Erweiterung (!) der Berechtigung möglich
Beispiel:
Jan hat das Leserecht für Objekt O,
Klaus besitzt dieses Recht nicht.
Jan hat kein Recht, Klaus das Leserecht einzuräumen.
Dennoch kann Jan dieses Recht an Klaus weitergeben:
Jan erzeugt eine Kopie O’ des Inhalts von O, und vergibt
(in der Rolle des Eigentümers von O’) das Leserecht an Klaus.
Zugriffskontrolle dem Ermessen (der Willkür) der Benutzer überlassen
⇒ discretionary access control (DAC)
Gefahr:
trojanische Pferde: Programme, die diesen Sachverhalt nutzen, um unbemerkt Daten
weiterzugeben!!
c M. Scholl, 2004/05 – Informationssysteme: 5. Datenschutz und Datensicherheit
#
5-19
5.3.4
Datenflusskontrolle
! Ansatz:
Die unerlaubten Datenflüsse bei DAC sollen verhindert werden. Die Kontrolle wird
erzwungen
⇒ mandatory access control (MAC).
! Bell-LaPadula Modell2 verbindet Ermächtigungen für Objekte und Zuständigkeitsbereiche der
Subjekte
! Modell ist militärischen Umgebungen nachempfunden
! Bedingt Änderung der Definition von DB-Operationen
⇒ multi-level relational system (MLS)
Möglichkeit/Notwendigkeit, sog. Cover Stories“ zu definieren: Falsche Daten für Benutzer mit
”
niedriger Berechtigung, damit diese keinen Verdacht schöpfen“
”
⇒ Phänomen der Polyinstanzierung“: d.h. evtl. mehrere Instanzen eines Objektes sichtbar
”
! sehr hoher Aufwand, aber auch für kommerzielle RDBMS verfügbar (z.B. Trusted Oracle“)
”
! Beispiel 5-5: In der folgenden Relation sei PersNr Primärschlüssel. Nur ein Benutzer mit der
Berechtigung geheim“ soll die wahre Mission von J. Bond kennen.
”
PersNr
007
007
C1
offen
offen
Mission
Urlaub
Fireball
C2
offen
geheim
➀
➁
2 (Bell und LaPadula Nov. 1973 + June 1974); auch beschrieben in (Oppliger 1992).
c M. Scholl, 2004/05 – Informationssysteme: 5. Datenschutz und Datensicherheit
#
5-20
5.3.5
Klassifikation der Computer-Systeme
! Orange Book
. . . Klassifikation nach DoD Trusted Computer Systems Evaluation Criteria“ (TCSEC)
”
Klasse D: Hält keiner Prüfung für höhere Klassen stand
Klasse C: discretionary access control ist realisiert, darunter
C1: discretionary security protection“
”
The Trusted Computing Base (TCB) of a class (C1) system nominally satisfies the discretionary security
”
requirements by providing separation of users and data. It incorporates some form of credible controls
capable of enforcing access limitations on an individual basis, i.e., ostensibly suitable for allowing users
to be able to protect project or private information and to keep other users from accidentally reading or
destroying their data. The class (C1) environment is expected to be one of cooperating users processing
data at the same level(s) of sensitivity.“
C2: controlled access protection“
”
Systems in this class enforce a more finely grained discretionary access control than (C1) systems, making
”
users individually accountable for their actions through login procedures, auditing of security-relevant events,
and resource isolation.“
c M. Scholl, 2004/05 – Informationssysteme: 5. Datenschutz und Datensicherheit
#
5-21
Klasse B: mandatory access control ist realisiert, darunter
B1: labeled security protection“
”
Class (B1) systems require all the features required for class (C2). In addition, an informal statement of
”
the security policy model, data labeling, and mandatory access control over named subjects and objects
must be present. The capability must exist for accurately labeling exported information. Any flaws identified
by testing must be removed.“
B2: structured protection“
”
In class (B2) systems, the TCB is based on a clearly defined and documented formal security policy model
”
that requires the discretionary and mandatory access control enforcement found in class (B1) systems
be extended to all subjects and objects in the ADP system. In addition, covert channels are addressed.
The TCB must be carefully structured into protection-critical and non- protection- critical elements. The
TCB interface is well-defined and the TCB design and implementation enable it to be subjected to more
thorough testing and more complete review. Authentication mechanisms are strengthened, trusted facility
management is provided in the form of support for system administrator and operator functions, and
stringent configuration management controls are imposed. The system is relatively resistant to penetration.“
B3: security domains“
”
The class (B3) TCB must satisfy the reference monitor requirements that it mediate all accesses of
”
subjects to objects, be tamperproof, and be small enough to be subjected to analysis and tests. To this
end, the TCB is structured to exclude code not essential to security policy enforcement, with significant
system engineering during TCB design and implementation directed toward minimizing its complexity. A
security administrator is supported, audit mechanisms are expanded to signal security- relevant events, and
system recovery procedures are required. The system is highly resistant to penetration.“
c M. Scholl, 2004/05 – Informationssysteme: 5. Datenschutz und Datensicherheit
#
5-22
Klasse A: verified design“
”
Systems in class (A1) are functionally equivalent to those in class (B3) in that no additional architectural
”
features or policy requirements are added. The distinguishing feature of systems in this class is the analysis
derived from formal design specification and verification techniques and the resulting high degree of assurance that the TCB is correctly implemented. This assurance is developmental in nature, starting with a
formal model of the security policy and a formal top-level specification (FTLS) of the design. In keeping
with the extensive design and development analysis of the TCB required of systems in class (A1), more
stringent configuration management is required and procedures are established for securely distributing the
system to sites. A system security administrator is supported.“
c M. Scholl, 2004/05 – Informationssysteme: 5. Datenschutz und Datensicherheit
#
5-23
5.3.5.1
Probleme der Datenflusskontrolle
! Nur Sicherheitsmodelle – kein Integritätsschutz
Beispiel:
Ein Benutzer mit niedriger clearance kann im Prinzip beliebige (unsinnige, bewusst falsche) Daten
in höher klassifizierte Objekte schreiben, wodurch eine Integritätsverletzung nicht ausgeschlossen
werden kann.
⇒ Integritätsschutz-Modelle
! Möglichkeit impliziter Datenflüsse und verdeckter Kanäle“
”
" Beispiel:
(x ∈ {0, 1}) if x = 0 then y := 0 else y := 1
Hier wird der Wert von x implizit an y weitergereicht.
Lösungsansatz: Datenflussdetektoren
" Beispiel:
Offenlegung der Information durch physikalische Phänomene wie Rechenzeit, ResourceAuslastung, usw.
Lösungsansatz: Setzen von Zeit- bzw. Resource-Vorgaben beim Programmstart
c M. Scholl, 2004/05 – Informationssysteme: 5. Datenschutz und Datensicherheit
#
5-24
! Überklassifikation
" Informationsfluss von unten nach oben“, ggf. höher als notwendig.
”
Beispiel:
Die Ankündigung eines neuen Produkts ist bis zur Messe-Vorstellung geheim, danach offen.
Lösung: Ein Sicherheitsbeauftragter, der das Recht zur expliziten Degradierung von Objekten
besitzt.
Beispiel:
Startet ein Benutzer mit der Berechtigung geheim einen Prozess, der ausschließlich offenklassifizierte Daten verarbeitet, so werden sämtliche Ausgaben dennoch geheim-klassifiziert.
" Modell-Anpassung: high-water-mark-Modell
Nur die höchste benötigte Klassifikation, nicht die höchste mögliche.
Beispiel:
Solange der Benutzerprozess ausschließlich offen-klassifizierte Daten verarbeitet, werden auch
die Ausgaben als offen klassifiziert. Erst mit dem Zugriff auf sensitive Daten steigt die Klassifikation auf das notwendige Niveau.
! Programm-Abbruch
" Problem: jede Art einer abnormal termination (z.B. mit der Möglichkeit, core dump zu
erzeugen)
" Lösungsansatz: Detektoren, Verifikation
c M. Scholl, 2004/05 – Informationssysteme: 5. Datenschutz und Datensicherheit
#
5-25
5.3.5.2
Inferenz-Kontrollmechanismen
! Anwendung: statistische DB, medizinische IS
Ziel der Anfragen ist die Auskunft über Populationen, nicht dagegen über einzelne Individuen.
! Anfrage Q bestimmt eine Menge von Records ( query set“) Auf dieser Menge sind dann aus”
schließlich statistische Funktionen (count, sum, max, median, . . .) erlaubt.
! Gefahr: Rekonstruktion der vertraulichen Originalinformation durch Rückschlüsse aus den statistischen Ergebnissen auf individuelle Daten
! Angriff:
" Vorwissen über ein Individuum“
”
" größere Anzahl ineinandergreifender Anfragen
" Deduktion weiterer Daten durch Inferenz
"
Statistische“ Anfrageergebnisse aus sehr kleinen Grundmengen (→ Kontrolle der Ergebnis”
größen)
c M. Scholl, 2004/05 – Informationssysteme: 5. Datenschutz und Datensicherheit
#
5-26
5.3.5.3
Kontrolle der Anzahl der Records im Query Set
! Beispiel:
Falls Anfrage Q mit count(query set) = 1 zulässig, dann liefert jede Anfrage (Q ∧ X) Ja/Nein für
jedes beliebige X
! Ansatz 1: Keine Antwort, falls
(count(query set) < k) or (count(query set) > N − k )
Dabei ist: N = Anzahl Records in der DB,
k Schranke für die # Datensätze im query set
" Möglicher Angriff:
! individual tracker für einzelne (bekannte) Individuen
! general tracker für jede unbeantwortbare“ Anfrage
”
! Typische Vorgehensweise: query set durch Hinzunahme weiterer Records groß (≥ k) setzen,
anschließend die Erweiterung“ wieder durch einen tracker eliminieren.
”
! Typsiche Vorgehensweise für individual tracker:
Person charakterisiert durch Anfrage Q
Zerlege: Q in (Q = A ∧ B), so dass
sowohl (A)
als auch (A ∧ ¬B) beantwortbar ist
[ tracker ]
damit: Q = A ∧ ¬(A ∧ ¬B)
[ von Hand“ ]
”
c M. Scholl, 2004/05 – Informationssysteme: 5. Datenschutz und Datensicherheit
#
5-27
" Beispiel 5-6:
Gegeben sei die folgende Mitarbeiter-Relation mit k = 2.
NAME
Anton
Barbara
Claire
Doris
Elmar
Frauke
Günter
Hans
Ines
Janine
GESCHL
M
W
W
W
M
W
M
M
W
W
ABTEILUNG
Vertrieb
Buchhaltung
Vertrieb
Einkauf
Rechenzentrum
Werbung
Rechtsabteilung
Werbung
Vertrieb
Vertrieb
GEHALT
5000
3500
4400
3800
4000
3900
5200
4000
4200
3800
# KURSE
3
0
1
1
0
0
0
0
1
1
...
Wir wissen, dass Anton (männlich) im Vertrieb beschäftigt ist. Nun wollen wir sein Gehalt mit
Hilfe eines individual tracker erfragen“.
”
c M. Scholl, 2004/05 – Informationssysteme: 5. Datenschutz und Datensicherheit
#
5-28
SELECT COUNT(*) FROM MITARBEITER
WHERE GESCHL = ‘M’
Antwort: 4 (> k)
SELECT COUNT (*) FROM MITARBEITER
WHERE GESCHL = ‘M’ AND
NOT(ABTEILUNG = ‘Vertrieb’)
Antwort: 3 (> k)
⇒ Es gibt nur einen Mann im Vertrieb; dieser muss also Anton sein.
SELECT SUM(GEHALT) FROM MITARBEITER
WHERE GESCHL = ‘M’
Antwort: 18200
SELECT SUM (GEHALT) FROM MITARBEITER
WHERE GESCHL = ‘M’ AND
NOT(ABTEILUNG = ‘Vertrieb’)
Antwort: 13200
=⇒ Antons Gehalt beträgt also 18200 − 13200 = 5000 DM.
c M. Scholl, 2004/05 – Informationssysteme: 5. Datenschutz und Datensicherheit
#
5-29
" Schlussfolgerungen zu Ansatz 1:
! Individualisierung (Zuordnung) der Daten möglich
! Jede Anfrage mit (2k . . . n − 2k) Records bildet general tracker! Gesucht: Antwort zum
Prädikat P , mit Hilfe des trackers T
Vorgehen: P := (P ∨ T ) + (P ∨ ¬T ) − (T ∨ ¬T )“
”
Menge
definiert durch T
Menge def. durch P
Menge
definiert durch not T
Menge aller
Datensätze
(Multimenge!)
☞ Einschränkung der query set-Größe allein ⇒ kein Schutz
! Ansatz 2: Keine Antwort, falls count((query set) ∩ (query set einer alten“ Anfrage)) > k
”
☞ Im allgemeinen nicht praktikabel (Aufwand!)
! Ansatz 3: Partitionierte“ DB: Gruppen von Individuen
”
" Anfragen nur an Mengen von Gruppen (auch einzelne),
" keine Anfragen an Subsets der Gruppen
" Möglich: Micro-Aggregation“ ⇒ Durchschnitts-Individuen
”
☞ Ergebnis: Relativ sicher Aber: evtl. nutzlose Information durch falsche Gruppenwahl
Aufwand bei insert/update/delete (ggf. Umgruppierung)!
c M. Scholl, 2004/05 – Informationssysteme: 5. Datenschutz und Datensicherheit
#
5-30
5.3.5.4
Verzerrung der Ergebnisse (Rundung, Fälschung)
! Verzerrung muss groß genug sein, um tracker zu verhindern, und klein genug sein, damit die
statistischen Aussagen noch sinnvoll sind
! Ansatz 1: exakte Antwort durch Zufallszahl verändert
Beispiel: Pseudozufallszahl ⇒ bei gegebener Anfrage evtl. immer gleiche Antwort
Wichtig: Mittelwert /= 0, da er sonst herausgerechnet“ werden kann
”
Dennoch angreifbar: Durch tracker, Einfügen von Dummy-Records und durch Vergleiche der
Ergebnisse mehrerer Anfragen
! Ansatz 2: Jeder Wert in jedem Record wird verfälscht!
Ergebnis: Relativ sicher, damit Personen mit hoher clearance noch lesen können: Verfälschung erst
bei der statistischen Auswertung
! Ansatz 3: Data Swapping: Werte einzelner Records werden vertauscht
" Isolierter Wert erlaubt keinen Rückschluss auf ein Individuum
" Statistiken über maximal k Attribute unverfälscht (k = vom DBA definierte Schranke)
" Aber: wie findet man Mengen (Kandidaten) ⇒ hoher Aufwand
c M. Scholl, 2004/05 – Informationssysteme: 5. Datenschutz und Datensicherheit
#
5-31
5.3.5.5
Zufallsauswahl eines Teils der gesamten DB
! Ansatz: Pseudozufällige (reproduzierbare) Auswahl der gesamten DB
" Jeder Record des query set wird mit Wahrscheinlichkeit p zur Ergebnisbildung herangezogen
Beispiel: p = 0.9375 → count, sum mit etwa 1% Fehler
" Ergebnis: Sehr wirkungsvoll: Keine Kontrolle über count(query set)
" Aber: nicht für kleine DB: keine repräsentative Auswahl möglich
! Fazit: 100%-sichere statistische DB nicht zu erwarten
! Anmerkung:
In kommerziellen DB sind oft mächtigere Anfragen als hier betrachtet möglich,
der Schutzmechanismus kann daher fast immer umgangen werden (Frage des
Aufwands)
c M. Scholl, 2004/05 – Informationssysteme: 5. Datenschutz und Datensicherheit
#
5-32
5.3.6
Kryptographie
5.3.6.1
Symmetrische Kryptosysteme:
! Gleicher Schlüssel zur Ver- und Entschlüsselung
! Prinzip: (m: Klartext-Nachricht, m0: Chiffretext, S: Schlüssel)
" Verschlüsselung: Funktion encode“ eS (m) = m 0
”
" Entschlüsselung: Funktion decode“ dS (m 0 ) = m
”
m
m'
e
m
d
unsicherer Kanal
d
e
S
sicherer Kanal
! Verschiedene Verfahrensklassen: Substitution, Permutation, Mischsysteme (z.B. DES)
! Probleme:
" Schlüsselaustausch (sicherer Kanal erforderlich!)
" Prinzipielle Sicherheit nur bei
! einmaliger Verwendung
! eines zufälligen Schlüssels ( Pseudozufall“ reicht nicht aus)
”
! gleicher Länge wie die Nachricht ( one-time pad“)
”
c M. Scholl, 2004/05 – Informationssysteme: 5. Datenschutz und Datensicherheit
#
5-33
! Beispiel
Einfache monoalphabetische Substitution mit Schlüssel und ihre Cryptanalyse
Klartextalphabet:
a b c d e f g h i j k l m n o p q r s t u v w x y z
Schlüsselalphabet:
b e r t a c d f g h i j k l m n o p q s u v w x y z
Klartext:
die abordnung der gegenseite wird im laufe der kommenden woche in der
”
hauptstadt eintreffen“
Verschlüsselter Text:
tgabemptluldtapdadalqagsawgptgkjbucatap
”
imkkaltalwmrfagltapfbunsqsbtsaglspaccal“
Cryptanalytischer Ansatz: Häufigkeitsanalyse
1. Ermittle die relative Zeichen-Häufigkeit im verschlüsselten Text
⇒ Einzelne Buchstaben, Zweiergruppen, Doppelbuchstaben usw.
a b c d e f g h i j k l m n o p q r s t u v w x y z
15 4 3 3 1 2 6 0 1 1 3 8 3 1 0 6 2 1 5 8 3 0 2 0 0 0
P
= 78
Die Analyse ergibt: tap“ = 2x, kk“, cc“, . . .
”
”
”
c M. Scholl, 2004/05 – Informationssysteme: 5. Datenschutz und Datensicherheit
#
5-34
2. Vergleiche mit Häufigkeiten in (versch.) Sprachen-Tabellen
⇒ deutsch: e (18.5%), n (11.5), r (7), i (8), s (7), t (5), u (5), . . .
3. Entschlüsselungsversuch durch Zuordnung (Versuch und Irrtum)
! Beispiel: Data Encryption Standard, NBS 19773
" Blockchiffre: Verschlüsselt werden 64-bit lange Datenblöcke (Worte)
" Schlüssel: 56 bit (erweitert um 8 Paritätsbits)
" Methode: Produktchiffre, abwechselnde“ Permutation/Substitution
”
Kritik:
⇒ Schlüssel zu kurz (durch erschöpfende Suche leicht zu brechen) ⇒ Substitutionsfunktion nicht
veröffentlicht (geheime Abkürzung“?)
”
Abhilfe: Mehrfachverschlüsselung mit DEA (mehrere Iterationen)
3 Data Encryption Algorithm (DEA), ANSI X3.92, 1981
c M. Scholl, 2004/05 – Informationssysteme: 5. Datenschutz und Datensicherheit
#
5-35
5.3.6.2
Asymmetrische (public-key) Kryptosysteme:
! Ein öffentlicher (public) Schlüssel P zur Verschlüsselung und
! ein geheimer (secret/private) Schlüssel S zur Entschlüsselung
! Prinzip: " Verschlüsselung: eP (m) = m0
m: Klartext-Nachricht,
m0: Chiffretext
" Entschlüsselung: dS (m 0 ) = m
P
SB
B
m
m'
e
m
d
unsicherer Kanal
d
e
SA
P
A
! Signaturen (Authentifizierung, digitale Unterschrift) möglich
! Grundlage der Sicherheit“: Trap-door-Einwegfunktionen,
”
" Faktorisierungsproblem
" Berechnung des diskreten Logarithmus4
" Knapsackproblem (additiv, multiplikativ) [NP-vollst.]
" Dekodierung für fehlererkennende Codes [NP-vollst.]
! Achtung: u.U. ist sogar ein auf einem NP-vollst. Problem basierendes Verfahren leicht zu brechen,
evtl. kann die sog. Klartext-Attacke erfolgreich sein!
4 Beispiel für diskreten Logarithmus: 3x ≡ 1( mod 5), x ∈ Z
c M. Scholl, 2004/05 – Informationssysteme: 5. Datenschutz und Datensicherheit
#
5-36
! RSA-Kryptosystem (Faktorisierungsproblem)5
" Parameter: r = p1 p2
S ∈ [0, ϕ(r ) − 1]
p1, p2 ∼ 100 − stellige Primzahlen
ϕ(r) = (p1 − 1)(p2 − 1) (Eulersche Fkt.)
ggt(S, ϕ(r )) = 1
! damit existiert ein eindeutiges P ∈ [0, ϕ(r ) − 1] mit
! P ∗ S ≡ 1 (mod ϕ(r ))
[ zu finden mit Hilfe von p1, p2 mit dem Euklidischen Alg. ]
" Öffentlicher Schlüssel: (r, P )
" Geheimer Schlüssel: (r, S)
" Verschlüsselung: m P mod r
" Entschlüsselung: m 0
S
mod r
(O(log P ) Schritte) . . . öffentl. Schlüssel des Empfängers
(O(log S) Schritte)
" Beispiel 5-7: p1 = 3, p2 = 5, damit r = 15, ϕ(r ) = 2 ∗ 4 = 8
Sei S = 7, damit gesuchtes P aus [0, 7] mit P ∗ 7 = 1 modulo 8 also: P = 7.
Der Klartext sei als die Zahl m = 13 codiert.
Damit ergibt sich der Chiffretext zu:
m0 = mP mod r = 137 mod 15 = 62748517 mod 15 = 7
Die Entschlüsselung:
m = m0S mod r = 77 mod 15 = 823543 mod 15 = 13
5 (Rivest et al. 1978)
c M. Scholl, 2004/05 – Informationssysteme: 5. Datenschutz und Datensicherheit
#
5-37
! Nachrichtenaustausch mit ausschließlich privaten Schlüsseln
" Voraussetzung: Ver- und Entschlüsselung kommutativ:
!
!
!
!
A sendet
B sendet
A sendet
B entschlüsselt
eSA (m)
eSB (eSA (m))
dSA (eSB (eSA (m))) = eSB (m)
dSB (eSB (m)) = m
an B
an A zurück
an B
" Nachteil: die Nachricht wird dreimal übertragen
⇒ kryptoanalytischer Ansatz möglich
! Nachrichtenaustausch mit Signatur (digitale Unterschrift)
" Voraussetzung: geeignetes public-key Kryptosystem
!
!
!
!
A unterschreibt
A sendet
B entschlüsselt
B verifiziert
eSA (m)
ePB eSA (m)
dSB (ePB (eSA (m))) = eSA (m)
dPA (eSA (m))
an B
Bemerkung: Verifikation durch Lesbarkeit des Klartextes
c M. Scholl, 2004/05 – Informationssysteme: 5. Datenschutz und Datensicherheit
#
5-38
5.3.6.3
Zusammenfassung: Kryptographie
! Verschiedene Ebenen der Verschlüsselung möglich:
" Betriebssystem mit einem Systemschlüssel
" Benutzer mit privatem Schlüssel
" Applikation mit applikationsspezifischem Schlüssel
! Voraussetzungen für erfolgreiche Chiffrierung:
" Verschlüsselung konsequent (trotz Zeitaufwand)
" Schlüssel geheim
" Algorithmus nicht modifizierbar und nicht umgehbar
! Vorteile der Verschlüsselung:
" Verhindert unbefugtes Lesen
" Verhindert unerlaubtes Einfügen, Löschen, Modifikation (Backup notwendig)
" Hindert die Ausbreitung von Viren; hilft ggf., Viruszugriffe zu erkennen (Backup notwendig)
! Nachteile:
" Aufwand
" DB-Anfragen (Prädikatauswertung) oft nur auf entschlüsselten Daten möglich
c M. Scholl, 2004/05 – Informationssysteme: 5. Datenschutz und Datensicherheit
#
5-39
5.4
Zusätzliche Literaturhinweise
! Allgemeine Übersichten, Lehrbücher:(Denning 1983; Fernandez et al. 1981; Oppliger 1992; Bauer 1993; Castano
et al. 1995)
! Zeitschriften: Datenschutz und Datensicherung (Vieweg), Computers & Security (Elsevier)
! Spezialliteratur zur Vertiefung: (Abadi 1991; Kargers 1991; Lampson 1973; Lunt 1990; IEEE Security 1980)
! außerdem: diverse Newsgroups, WWW-Sites
Abadi, M. (1991). A Calculus for Access Control in Distributed Systems, Kap. In: Advances in Cryptology Proceedings CRYPTO’91, LNCS 576. Springer.
Bauer, F. L. (1993). Kryptologie - Methoden und Maximen. Springer.
Bell, D.E. und L. LaPadula (Nov. 1973 + June 1974). Secure Computer Systems. Technical Report ESD-TR73-278, MITRE Cooperation, Bedford, MA.
Castano, S., M. Fugini, G. Martella und P. Samarati (1995). Database Security . Addison-Wesley / ACM Press.
Denning, D. E. (1983). Cryptography and Data Security . Addison-Wesley.
Fernandez, E. B., R. C. Summers und C. Wood (1981). Database Security and Integrity . Addison-Wesley.
IEEE Security (1980). Security and Privacy, Proc. IEEE Symposium on Security and Privacy . Vol. I: 1980-1984,
Vol. II: 1985-1987.
Kargers, P. A. (1991). A Retrospective on the VAX VMM Security Kernel. IEEE Transactions on Software
Engineering, 17(11):1147–1165.
Lampson, B. W. (1973). A Note on the Confinement Problem. Communications of the ACM, 16(10):613–615.
Lunt, T. F. (1990). The SeaView Security Model. IEEE Transactions on Software Engineering, 16(6):593–607.
Oppliger, R. (1992). Computersicherheit. Vieweg.
Rivest, R.L., L. Adleman und A. Shamir (1978). A Method for Obtaining Digital Signature and Public-Key
Cryptosystems. Communications of the ACM, 21(2):120–126.
c M. Scholl, 2004/05 – Informationssysteme: 5. Datenschutz und Datensicherheit
#
5-40