Baze podataka – MySQL, Oracle, PostgreSQL, MS SQL Server, Access, modelovanje podataka …

Prava pristupa podacima – prvi deo

Saturday, 17.05.2008 – Srdjan

SQL baze podataka nam omogućavaju izvestan nivo kontrole pristupa podacima. Ova kontrola se postiže upotrebom GRANT komande i njenih varijacija GRANT SELECT, GRANT INSERT, GRANT UPDATE, GRANT DELETE. Da bi se primenila ovakva pravila pristupa bitno je da svaki korisnik sistema ima svoje jedinstveni nalog na nivou baze podataka. Mnogi proizvođači baza podataka dopunjuju standardnu ponudu sa dodatnim pravima pristupa kao što su column-level security i row-level security.

PostgreSQL nema mogućnost definisanja column i row level pristupa podacima. Da li postoji mogućnost da se ove tehnologije simuliraju ako su nam potrebne? Postoji, ali nažalost zahteva dodatni trud.

Kako napraviti prava pristupa podacima u okviru PostgreSQL-a? Pokazaću kroz jedan mali primer.

Predpostavimo da u okviru informacionog sistema imamo i podsistem za kadrovsku evidenciju i obračun zarada. Predpostavimo da imamo tri korisnika sistema:
– Pera šef službe prodaje
– Mika radnik u službi prodaje
– Laza šef službe nabavke
Dakle, po organizacionoj šemi Pera i Laza su na istom hijerarhijskom nivou dok je Mika podređen Peri.

Kreiramo tri korisnika sistema:

CREATE ROLE pera LOGIN;
CREATE ROLE mika LOGIN;
CREATE ROLE laza LOGIN;

U delu podsistema za kadrovsko i plate imamo jednu tabelu:

CREATE TABLE radnici (
ime VARCHAR(10) NOT NULL PRIMARY KEY,
datum_rodjenja DATE NOT NULL,
-- sluzba u okviru firme kojoj radnik organizaciono pripada
-- sluzbe su kodirane po semi: N = nabavka, P = prodaja
sluzba CHAR(1) NOT NULL CHECK (sluzba IN ('N', 'P')),
plata NUMERIC(10,2) NOT NULL DEFAULT 0 CHECK (plata > 0.00)
);

Ovu tabelu ćemo popuniti test podacima

INSERT INTO radnici (ime, datum_rodjenja, sluzba, plata)
VALUES ('pera', '1969-04-04', 'P', 50000);
INSERT INTO radnici (ime, datum_rodjenja, sluzba, plata)
VALUES ('mika', '1977-02-09', 'P', 35000);
INSERT INTO radnici (ime, datum_rodjenja, sluzba, plata)
VALUES ('laza', '1979-12-07', 'N', 48000);

Pera i Laza kao šefovi imaju sva prava pristupa nad podacima, dok Mika moze samo da čita podatke.

GRANT SELECT, INSERT, UPDATE, DELETE ON radnici TO pera;
GRANT SELECT                         ON radnici TO mika;
GRANT SELECT, INSERT, UPDATE, DELETE ON radnici TO laza;

Na ovaj način smo sprečili Miku da unosi nove radnike u tabelu ili da menja postojeće podatke (da poveća sebi platu 🙂 ).

Ovim smo ujedno i završili sa pravima pristupa koji nam se nude nad tabelama. Ali, šta ako nam ovakva prava pristupa nisu dovoljna? Kako dalje poboljšati bezbednost podataka?

Column-level security ili vertikalna prava pristupa

Javlja nam se nov zahtev pred naš sistem – Platu smeju da vide samo šefovi!

Klasičan pristup rešavanju ovog problema je da se početna tabela razdvoji na dve tabele koje su u relaciji 1:1 i nad kojima se posebno daju prava pristupa. Pa ajde da to i uradimo.

Prvo, kreiramo novu tabelu u kojoj će se čuvati podaci o platama.

CREATE TABLE plate (
ime VARCHAR(10) NOT NULL PRIMARY KEY REFERENCES radnici,
plata NUMERIC(10,2) NOT NULL DEFAULT 0 CHECK (plata > 0.00)
);

Drugo, prepisujemo podatke o platama iz tabele Radnici u tabelu Plate.

INSERT INTO plate (ime, plata)
SELECT ime, plata
FROM radnici;

Trece, brišemo kolonu plata iz tabele Radnici.

ALTER TABLE radnici DROP COLUMN plata;

Četvrto, dodeljujemo prava pristupa nad tabelom Plate šefovima.

GRANT SELECT, INSERT, UPDATE, DELETE ON plate TO pera;
GRANT SELECT, INSERT, UPDATE, DELETE ON plate TO laza;

Ovim smo potpuno sprečili Miku da vidi podatke o plate.

Dodatno da bismo olakšali posao čitanja podataka kreiraćemo jedan pogled kroz koji ćemo objediniti podatke iz tabela Radnici i Plate.

CREATE VIEW radnici_i_plate (
ime, datum_rodjenja, sluzba, plata
) AS
SELECT r.ime, r.datum_rodjenja, r.sluzba, p.plata
FROM radnici AS r
LEFT OUTER JOIN
plate AS p
ON r.ime = p.ime;

Takođe, šefovima moramo dati pravo da koriste ovaj pogled

GRANT SELECT ON radnici_i_plate TO pera;
GRANT SELECT ON radnici_i_plate TO laza;

Sada naši šefovi sada lako mogu da pročitaju podatke o radnicima i njihovim platama pomoću upita

SELECT ime, datum_rodjenja, sluzba, plata
FROM radnici_i_plate

Promenom strukture podataka obezbedili smo nekakav column-level security, to jest sprečili smo pojedine korisnike da pristupaju kolonama sa osetljivim podacima.
Pošto smo izmenuli strukturu meni je draže da ovakva prava pristupa nazivam ‘vertikalna prava pristupa’.

Do sad smo upotrebiljavali isključivo standardan SQL i gornji primeri se mogu pokrenuti i na drugim database engine-ima, a ne samo na PostgreSQL-u.

U sledećem nastavku ćemo videti kako se u PostgreSQL-u može implementirati Oracle-ov row-level security.