Gegevensbanken_2012_Les9_Beveiliging

Gegevensbanken 2012
Beveiliging van
gegevensbanken
Prof. Bettina Berendt
http://people.cs.kuleuven.be/~bettina.berendt/
Beveiliging van
gegevensbanken:
Motivatie &
Samenvatting
2
Waar zijn we?
Les #
1
2
2
3
4,5
6
7
8
9
10
11
12
13
14,15
16
17
wie
ED
ED
ED
KV
KV
KV
KV
KV
BB
BB
BB
BB
BB
BB
BB
ED
wat
Conceptueel model
intro, ER
EER, (E)ER naar relationeel schema
Relationeel model
relationeel model
& variaties
Relationele algebra & relationeel calculus
SQL
Programma's verbinden met gegevensbanken
Functionele afhankelijkheden & normalisatie
PHP
Beveiliging van gegevensbanken
Geheugen en bestandsorganisatie
Externe hashing
Fysisch model /
Indexstructuren
vragen
Queryverwerking
Transactieverwerking en concurrentiecontrole
Data mining en data warehousing
Nieuwe thema‘s /
XML, NoSQL
vooruitblik
3
Verbreden & beperken
• Relationeel model & SQL: maak gegevens
– zo beschikbaar als mogelijk
– in zo algemene vorm als mogelijk
• Beveiliging: beperk beschikbaarheid – omwille van
veiligheid & privacy
• [Nieuwe thema‘s / Vooruitblik] NoSQL: beperk
algemeenheid – omwille van efficientie
4
Probleemvoorbeeld 1
5
Probleemvoorbeeld 2
04/06/11
nor24malisatie
6
Een aanpak tot oplossing: toegangscontrole
7
Agenda
Concepten, bedreigingen, controlemaatregelen
Toegangscontrole
Inferentiecontrole
Flow control (“Controle van de stroom van informatie”)
8
Agenda
Concepten, bedreigingen, controlemaatregelen
Toegangscontrole
Inferentiecontrole
Flow control (“Controle van de stroom van informatie”)
9
Aspecten van beveiliging
• Beveiliging:
= bescherming tegen ongeoorloofde toegang
• Verschillende aspecten:
– wettelijk / ethisch
• bv. privacy-bescherming
– bedrijfspolitiek
• wat mag aan wie meegedeeld worden?
– systeemgebonden aspecten
• bv. op welk niveau toegang afschermen?
– DBMS, besturingssysteem, hardware?
• meerdere niveaus van bescherming
– bv. top secret, secret, confidential, unclassified
10
Security (veiligheid) en privacy
• Veiligheidsdoelstellingen - de CIA Triad: confidentiality, integrity,
availability
• Integriteit geeft de mate aan waarin de informatie actueel en correct
is. Kenmerken zijn juistheid, volledigheid en geautoriseerdheid van
de transacties.
• Beschikbaarheid bevat de garanties voor het afgesproken niveau
van dienstverlening gericht op de beschikbaarheid van de dienst op
de afgesproken momenten (bedrijfsduur, waarbij rekening wordt
gehouden met uitvalstijden, storingen en incidenten). Kenmerken van
beschikbaarheid zijn tijdigheid, continuïteit en robuustheid.
• Vertrouwelijkheid is het kwaliteitsbegrip waaronder
privacybescherming maar ook de exclusiviteit van informatie
gevangen kan worden. Het waarborgt dat alleen geautoriseerden
toegang krijgen en dat informatie niet kan uitlekken.
• Bedreigingen: acties (enz.) die deze eigenschappen in gevaar brengen
11
Privacy
• Klassieke definitie in de informatica benadrukt vooral
– Vertrouwelijkheid
• Wettelijke definities (en ook informatica) benadrukken
– Controle
– “the right of the individual to decide what information about
himself should be communicated to others and under what
circumstances” (Westin, 1970)
• Maar een interdisciplinaire aanpak toont aan
– dat het niet uitsluitend om verbergen (vertrouwelijkheid!) gaat,
maar ook om openstellen
– dat het construeren van identiteit(en) in private en publieke
domeinen centraal is
 ons actueel onderzoek, meer daarover later in de cursus
12
Types van controlemaatregelen
• Toegangscontrole
– voor multi-user gegevensbank
– DBMS schermt de totale gegevensbank af door: accounts,
database audits
– DBMS moet beveiliging en authorisatie (machtiging) voorzien
• mogelijkheid tot bepalen wie wat mag
• Types:
– "discretionary": op inviduele basis
– "mandatory": op basis van classificatie van gebruikers en gegevens
– gebaseerd op rollen (ipv individuele gebruikers)
• Inferentiecontrole
– toegangsbeperking bij statistische gegevensbanken
• Flow control (“controle van de stroom van informatie”)
• Encodering en encryptie van gegevens
13
Agenda
Concepten, bedreigingen, controlemaatregelen
Toegangscontrole
Inferentiecontrole
Flow control (“Controle van de stroom van informatie”)
14
Rol van de DBA (database administrator)
– heeft geprivilegieerde account (system account) met
krachtige mogelijkheden, o.a.
•
•
•
•
1. creëren van een account
2. privileges toekennen (GRANT ...)
3. privileges intrekken (REVOKE ...)
4. accounts een bepaalde classificatie toekennen
– 1: controleert toegang tot hele gegevensbank
– 2, 3, 4:
controleert wie wat mag (authorisatie)
• 2,3 op individueel vlak,
• 4
op algemener vlak
15
Toegangsbescherming en -controle
• gebruiker heeft account, moet inloggen
– accounts en paswoorden door DBMS bijgehouden
• DBMS registreert bij inloggen
– accountnummer en gebruikte terminal
• systeemlog moet worden uitgebreid
– voor elke transactie: bijhouden wie ze uitvoerde
• "audit":
– controle van de logs gedurende zekere periode (indien
vermoeden van geknoei/fraude)
16
Toegangscontrole gebaseerd op privileges
• methode:
– toekenning van rechten (privileges): granting
– intrekken van rechten:
revoking
• 2 niveaus:
– account
– relatie
17
Privileges op account-niveau
• niet in SQL, moeten door DBMS ontwerpers voorzien
worden
• CREATE SCHEMA / TABLE / VIEW
• ALTER
• DROP
• MODIFY
• SELECT
18
Privileges op relatie-niveau (1)
•
•
•
•
wel in SQL beschikbaar
bv. toelating tot MODIFY van specifieke relatie
evt. nog specifieker: bepaalde attributen
toegangsmatrixmodel
– 1 rij per gebruiker, 1 kolom per object
– inhoud van 1 cel : toegelaten operaties
19
Privileges op relatie-niveau (2)
•
Elke relatie R heeft een eigenaar
– opgegeven bij creatie
– eigenaar heeft alle toegangsrechten
op R
– kan privileges doorgeven aan andere
accounts  granting
•
…
herinner
je nog ?
Mogelijke types van privileges in
SQL:
– SELECT privilege op R
– MODIFY ( UPDATE / DELETE /
INSERT ) privileges
– ALTER privilege
– REFERENCES privilege
20
Machtiging d.m.v. views
• als hulpmiddel voor beveiliging
• bv. eigenaar A van relatie R wil B slechts toegang
geven tot bepaalde attributen van R
• A creëert view V met die attributen
• A kent SELECT privilege op V toe aan B
• Opm: om view te creëren:
– SELECT privilege nodig op alle relaties die door de view
gebruikt worden
21
Toekennen / intrekken van privileges in SQL
• GRANT ...
• REVOKE ...
22
Voortplanting van privileges
• privilege geven inclusief "GRANT OPTION"
– kan door ontvanger opnieuw doorgegeven worden
• intrekken van privilege:
– privileges doorgegeven door die account moeten mee
ingetrokken worden
23
Voorbeeld met 4 accounts A1 .. A4 (1)
• Toelating tot creëren van relaties (door DBA)
– In SQL1: CREATETAB privilege
– In SQL2: hangt vast aan databankschema
• binnen dit schema mag de gebruiker tabellen maken
CREATE SCHEMA EXAMPLE AUTHORIZATION A1;
•
A1 creëert relaties EMPLOYEE en DEPARTMENT
 is eigenaar van deze relaties
 en heeft dus alle relatieprivileges daarvoor
24
Voorbeeld (2)
•
A1 kent A2 privilege toe om tupels toe te voegen / weg te laten
zonder doorgeefmogelijkheid
GRANT INSERT, DELETE ON EMPLOYEE, DEPARTMENT TO A2;
•
A1 geeft toelating tot SELECT aan A3, inclusief
doorgeefmogelijkheid
GRANT SELECT ON EMPLOYEE, DEPARTMENT TO A3
WITH GRANT OPTION;
•
A3 geeft toelating tot SELECT aan A4
GRANT SELECT ON EMPLOYEE TO A4;
25
Voorbeeld (3)
•
A1 trekt select-privilege op EMPLOYEE van A3 weer in: (A4 is
privilege automatisch ook kwijt)
REVOKE SELECT ON EMPLOYEE FROM A3;
•
A1 geeft A3 een beperkt privilege (via view):
CREATE VIEW A3EMPLOYEE AS
SELECT Name, Bdate, Address
FROM
EMPLOYEE
WHERE Dno = 5;
GRANT SELECT ON A3EMPLOYEE TO A3
WITH GRANT OPTION;
•
A1 laat A2 toe attribuut SALARY te wijzigen:
GRANT UPDATE ON EMPLOYEE(Salary) TO A2;
26
Beperkingen op doorgeven
•
horizontaal
– aan maximaal i accounts doorgeven
•
verticaal
– in de diepte beperkt
– grant optie van waarde j kan doorgegeven worden met waarde j – 1
•
•
•
het opgeven van deze beperkingen is (nog) niet in SQL voorzien
... maar wel in bepaalde web toepassingen:
Voorbeeld 1 (welke beperking is dit?)
27
Voorbeeld 2: Welke beperking is dit?
Tip: Wat zijn “relaties”, wat zijn “privileges”?
28
Multi-niveau beveiliging
• Tot nu: gewone toeganscontrole
– discretionary access control
• voor bepaalde toepassingen
– mandatory access control
– meerdere niveaus van gebruikers en data
• bv. top secret (TS), secret (S), confidential (C), unclassified(U)
– toegepast op
• subjecten (gebruikers, accounts, programma's)  "clearance“ of
vergunning
• objecten: relatie, tupel, kolom, ...  “classificatie“
– vaak gecombineerd met discretionary access control
29
Twee beperkingen (O = object, S = subject)
• S mag O lezen  class(S)  class(O)
– "simple security property"
• S mag O schrijven  class(S)  class(O)
– "star property"
30
Welke beperking werd hier „niet opgevolgd“?
(Tip: wat zijn de class(.) waarden van de „gegevensbanken“, objecten
en subjecten in deze pagina?)
• ter herinnering:
• S mag O lezen  class(S)  class(O)
• "simple security property"
• S mag O schrijven  class(S)  class(O)
• "star property"
?
31
“Class“ beperkingen in schema
• per attribuut een klassificatieattribuut
• voor elk tupel heeft elke attribuutwaarde een
klassificatie;
• tupel t als geheel krijgt klassificatie TC
– (TC(t) = max (Ci )
• R(A1, C1, A2, C2, ...., An, Cn, TC)
– “multi-niveau relatie schema”
32
Eigenschappen van multi-niveau relatie schemas
• Schijnbare sleutel ("apparent key"):
– attributen die normaal gezien een sleutel zouden vormen
• Wegens multi-niveau beveiliging worden sommige
tupels nu meerdere keren opgeslagen
 poly-instantiatie
– verschillende tuples kunnen dezelfde schijnbare sleutel
hebben, maar verschillende attribuutwaarden voor gebruikers
met verschillend clearance niveau
• Filtering:
– laten doorsijpelen van informatie uit tupels van hoger niveau
naar lager niveau, met verwijdering van die informatie die op
dat lager niveau niet zichtbaar mag zijn
33
Voorbeeld (1)
originele tupels
34
Voorbeeld (2)
originele tupels
tupels gefilterd voor
C-users
35
Voorbeeld (3)
originele tupels
tupels gefilterd voor
C-users
tupels gefilterd voor
U-users
36
Voorbeeld (4)
originele tupels
tupels gefilterd voor
C-users
tupels gefilterd voor
U-users
na
UPDATE EMPLOYEE
SET JobPerformance =
“Excellent”
WHERE Name = “Smith” ;
door een C-user (waarom?)
37
Entiteitsintegriteit
• schijnbare sleutel heeft geen nulwaarden
• alle attributen van schijnbare sleutel hebben zelfde
classificatie binnenin 1 tupel
• alle andere attributen hebben minstens even hoge
classificatie
38
Polyinstantiatie uitgelegd
• bv. gebruiker met clearance C voert update uit
– update mag niet geweigerd worden omdat er al een waarde op
niveau S bestaat
• anders krijgt C-gebruiker info over niveau S
– we willen die waarde ook niet laten overschrijven
–  tupel met hogere classificatie blijft ongewijzigd
–  een nieuw gewijzigd tupel komt op niveau C
UPDATE EMPLOYEE
SET
Job_performance = "Excellent"
WHERE Name = "Smith";
39
Rol-gebaseerde toegangscontrole
• GRANT en REVOKE niet aan individuele gebruikers,
maar aan rollen („studenten“, „proffen“, „administratieve
medewerkers“)
• CREATE ROLE / DESTROY ROLE
• Gebruikers worden aan rollen toegewezen
• Rol-hiërarchieën:
– GRANT ROLE full_time TO employee_type1
– GRANT ROLE intern TO employee_type2
40
Agenda
Concepten, bedreigingen, controlemaatregelen
Toegangscontrole
Inferentiecontrole
Flow control (“Controle van de stroom van informatie”)
41
Statistische gegevensbanken
• doel:
– opvragen van samenvattende statistieken, niet van individuele
informatie
• er moet voorkomen worden dat individuele waarden
opgevraagd worden
– bv. enkel aggregaatsfuncties toelaten (COUNT, AVG, ...)
– Maar ...
42
Inferentieproblemen
PERSON
Name
Institution Department
Position
Nationality
Income
SELECT COUNT(*) FROM PERSON
WHERE ...;
SELECT AVG(Income) FROM PERSON
WHERE ...;
•
Wat gebeurt er (bv) als de WHERE condities zijn:
–
–
–
–
Instelling = K.U. Leuven
Departement = Computerwetenschappen
Positie = Professor
Nationaliteit = Duits
43
Oplossingen
• beperkingen inbouwen als te weinig tupels aan conditie
voldoen
• geen opeenvolgende queries met dezelfde conditie
toelaten
• kleine onnauwkeurigheden inbouwen
 (ook) een onderdeel van “privacy-preserving data
mining”
44
Agenda
Concepten, bedreigingen, controlemaatregelen
Toegangscontrole
Inferentiecontrole
Flow control (“Controle van de stroom van informatie”)
45
Wat is Flow control?
• Welke informatie “stroomt” tussen objecten?
• Informatie “stroomt” van object X naar object Y als een programma
waarden van X leest en waarden naar Y schrijft
• Flow controls: verzekeren dat informatie van een object niet naar
een minder beschermd object stroomt
• Flow policy: bepaalt de channels (kanalen) waarlangs die
informatie mag stromen
• Meest eenvoudig:
– Vertrouwelijke informatie (C – confidential) en niet-vertrouwelijke
informatie (N – nonconfidential)
– Stroom mag niet van class C naar class N
–  Bell-LaPadula model van multiniveau beveiliging (zie boven)
– hier: objecten, subjecten/gebruikers, programma’s
46
Covert channels
• Covert channels: informatie stroomt van hoger naar lager niveau
 bedreiging
• Hoe?
– Bv. door samenwerking van de knopen in een gedistribueerde GB
• Hoe voor te komen?
– Één voorstel: de programmeur mag geen toegang krijgen tot gevoelige
gegevens nadat het programma opgestart is
47
Flow and Facebook applications
„[Facebook] applications (like quizzes) could access
almost everything on a user profile, including
hometown, groups you belong to, events attended,
favorite books, and more. [And] … your profile
information becomes available to developers when your
friends take the same quiz.„
http://www.readwriteweb.com/archives/how_to_delete_facebook_applications
_and_why_you_should.php (April 22, 2010)
48
Tenslotte: wiens vertrouwelijkheid werd hier
doorgebroken?
49
Vooruitblik
Concepten, bedreigingen, controlemaatregelen
Toegangscontrole
Inferentiecontrole
Flow control (“Controle van de stroom van informatie”)
Fysische vragen: Geheugen en bestandsorganisatie
50
Bronnen
• Deze slides zijn gebaseerd op Henk Olivié‘s slides voor
Gegevensbanken 2009 en op Elmasri & Navathe,
Fundamentals of Database Systems, Addison Wesley /
Pearson, 5e editie 2007.
• Alle kopieën zonder bronspecificatie: Elmasri &
Navathe, Fundamentals of Database Systems, Addison
Wesley / Pearson, 5e editie 2007.
• Verdere figuren en bronnen: zie tekst of “Powerpoint
comments field”
• Bedankt iedereen!
51