Partitioning für Datenschutz

[Torcas]

Hallo zusammen,
ich sitze gerade über meiner Bachelorarbeit, die sich um die Konzeption eines Sicherheitskonzeptes in einem Data Warehouse dreht. Dabei bin ich aktuell drüber, versch. Sicherheitskonzepte zu definieren wie man seine Daten vor unbefugtem Zugriff schützen kann.

Dabei gehe ich darauf ein, dass ein User sich immer über eine Business Intelligence Plattform mithilfe eines technischen Users auf der Datenbank anmeldet und dann entsprechende Daten sehen kann.

Nun zu meiner Frage:
Ich habe mir überlegt, ob es nicht auch möglich ist über Partitionen den Datenschutz sicherzustellen.
Vorgestellt habe ich mir eine doppelte (falls möglich?!) Bereichspartitionierung nach der Zeit und nach einem Kriterium. Geht so etwas?

Und falls ja, hätte ich weiter die Frage, ob man den Zugriff auf solch eine Partition einschränken kann über Grants. Im Web habe ich nur gefunden dass dies nicht möglich sein soll? Wie kann ich sonst eine Partition nur für Datenbankuser A und eine andere für Datenbankuser B bereitstellen?

Danke schonmal für eure Hilfe!
Falls ihr noch Informaitonen braucht, einfach raus damit

 

[drdimitri]

Um Zugriffsrechte zu verwalten gibt es mehrere Konzepte.
Eine davon ist es die Trennung zwischen dem Tabellenowner und dem lesenden User.

Diesem kann man Rechte geben bzw. entziehen. Möchte man nur bestimmte Daten einer Tabelle sichtbar machen, kann man z.B. eine View definieren und dort in der WHERE Bedingung eine entsprechenden Einschränkung definieren. Für eine partitionierte Tabelle würde man in d r View nur die entsprechende Partition selektieren:

Create view xy as Select * from tabelle partition (name_der_partition)

Hierfür gibt es auch in der Datenbank selbst die Virtual Private Database bzw. Transparent Data Encryption. Mehr Info per google.

 

[akretschmer]

Andere Alternative wäre RLS (Row Level Security), bei der man die Zugriffsrechte der Zeilen einer Tabelle benutzerabhängig machen kann. Also z.B. daß Meier und Schulze beide Datensätze eingeben können, in einem Feld dann aber deren Name stehen muß und später sowohl Meier als auch Schulze nur ihre eigenen Datensätze sehen/bearbeiten können. Ich weiß jetzt aber nicht, ob ORA dies bietet.

 

[akretschmer]

test=# create table messung (datum date, user_name text, val int) partition by range(datum);
CREATE TABLE
test=*# create table m_2016 partition of messung for values from ('2016-01-01') to ('2017-01-01');
CREATE TABLE
test=*# create table m_2017 partition of messung for values from ('2017-01-01') to ('2018-01-01');
CREATE TABLE
test=*# create policy read_own_data on messung for select using (current_user=user_name);
CREATE POLICY
test=*# alter table messung enable row level security;
ALTER TABLE
test=*# commit;
COMMIT
test=# grant all on messung to hans;
GRANT
test=*# grant all on messung to willi;
GRANT
test=*# commit;
COMMIT

--
-- als superuser
--

test=*# insert into messung values ('2017-02-01','hans',20);
INSERT 0 1
test=*# insert into messung values ('2017-03-01','willi',20);
INSERT 0 1
test=*# insert into messung values ('2016-04-01','willi',20);
INSERT 0 1
test=*# insert into messung values ('2016-05-01','hans',20);
INSERT 0 1
test=*# commit;
COMMIT

--
-- Abfrage
--

test=# \c - hans
Sie sind jetzt verbunden mit der Datenbank »test« als Benutzer »hans«.
test=> select * from messung ;
  datum  | user_name | val
------------+-----------+-----
 2016-05-01 | hans  |  20
 2017-02-01 | hans  |  20
(2 Zeilen)

test=*> \c - akretschmer
Sie sind jetzt verbunden mit der Datenbank »test« als Benutzer »akretschmer«.
test=# \c - willi
Sie sind jetzt verbunden mit der Datenbank »test« als Benutzer »willi«.
test=> select * from messung ;
  datum  | user_name | val
------------+-----------+-----
 2016-04-01 | willi  |  20
 2017-03-01 | willi  |  20
(2 Zeilen)

test=*>

Wie man sieht, die Benutzer sehen nur "ihre" Datensätze. Hat erst einmal nix mit Partitionierung zu tun, funktioniert hier aber auch.

 

[drdimitri]

Gugst du:
Enforcing Row-Level Security with Oracle Label Security

Quasi beliebig komplex implementierbar.