Dnes: 25. července 2014    | Registrace | Hledáme | Redakce | Info | Testy | Školení | Ocenění | Nápověda | Čtenář: nepřihlášen

Rychlé odkazy
  • Hlavní stránka
  • Seznam rubrik
  • Ankety
  • Editoriály
  • TOP 15
  • KONFERENCE 2008
  • KONFERENCE 2007
  • KONFERENCE 2006
  • KONFERENCE 2005
  • KONFERENCE 2004
  • Sborník
  • Testy
  • Virtuální školení
  • Personalizace


  • Hledáte práci?
    Hledáme redaktora - pojďte s námi tvořit Databázový svět!

    Vyhledávání

    Hledej
    na Databázovém světě!



    Rozšířené vyhledávání

    Rubriky
    Aktuality
    Bezpečnost
    Business
    Česká scéna
    Datové sklady
    Dokumentace
    Dotazovací jazyky
    Hardware
    Historie
    Komentáře
    Literatura
    Metodologie
    Nondb
    Open Source
    Poradna
    Produkty
    Případové studie
    Redakce
    Rozhovory
    Standardy
    Technologie
    Tipy - triky
    Tiskové zprávy
    Vývoj
    Vývojové nástroje
    Zajímavosti

    Co je to?
    Systémový katalog
    Struktury, ve kterých jsou uloženy informace o dané databázi, případně databázovém serveru. Někdy je možné se z anglického Data Dictionary setkat s pojmem datový slovník.

    Akce
    Dynamická Datová Centra
    - na semináři se seznámíte s komplexním řešením a koncepcí Dynamických Datových Center od Fujitsu Siemens Computers se speciálním důrazem na řešení FlexFrame.

    Textová inzerce
    IBPhoenix - Vše o InterBase a Firebirdu.

    Smějete se rádi? - Pak je pro vás Vtipník to pravé!

    Prodejce reklamy - Hledáme schopného prodejce reklamního prostoru, možnost i externí spolupráce.

    Moodle v ČR - LMS Moodle a e-learning profesionálně od společnosti PragoData Consulting

    Přihlášený čtenář
    Nepřihlášený čtenář

    O portálu
    Databázový svět
    ISSN: 1213-5933

    Web je optimalizován pro rozlišení 1024x768, nicméně kromě větších rozlišení podporujeme i 800x600. Podrobnosti najdete zde.

    Chcete-li mít kdykoliv možnost zkontrolovat obsah našeho portálu, můžete využít podporu rss. Podrobnosti najdete zde.
    Tipy a triky pro Oracle XII. – Jak na řízení přístupu na úrovni záznamů?
    Vydáno dne 15. 04. 2008

    [Tipy - triky] - Ve dvanáctém pokračování seriálu věnovaného praktickým tipům a trikům pro databázovou platformu Oracle Database se podíváme na řízení přístupu k datům na úrovni jednotlivých záznamů. Cílem seriálu je přinášet vám nejen praktické informace, které vám mohou pomoci při správě či vývoji na této platformě, ale také upozorňovat na zajímavé funkce. O kterých možná ani nevíte, že existují.



    Jednou z důležitých funkcí databáze je řízení přístupu k datům. Dnešní aplikace ale už je málokdy vystačí s řízením přístupu na úrovni jednotlivých tabulek. Čím dál častěji je třeba zajistit detailnější řízení přístupu na úrovni jednotlivých záznamů. V dnešním pokračování si proto ukážeme, jak lze pro tyto účely použít mechanismus Virtual Private Database.

    Důležitým pravidlem při řízení přístupu k datům je zajištění principu nejnižších možných práv – uživatel (a potažmo i aplikace či modul) by tedy měl mít přístup pouze k takovým datům a operacím, které jsou nezbytně nutné pro plnění jeho pracovní role. Čím více práv má uživatel nad rámec svých potřeb, tím větší škody může napáchat jejich zneužitím, nebo prostě omylem. To samé platí i pro práva, se kterými pracují jednotlivé aplikace – čím přesněji se podaří řídit přístup přímo na úrovni databáze, tím menší budou i následky zneužití případných bezpečnostních děr na úrovni aplikace (například pomocí SQL Injection).

    Tradiční mechanismy objektových práv ale přestávají stačit. V jednodušších případech pomůže vytvoření pohledu. Jak ale jednoduše vynutit například tato pravidla při přístupu k seznamu objednávek?

    • Zákazník má přístup jen ke svým objednávkám
    • Obchodník má přístup jen k objednávkám, které sám prodal
    • Manažer má mít přístup jen k objednávkám, které prodal on sám, nebo některý z jeho podřízených

    Oracle na tyto požadavky reagoval už ve verzi databáze 8i vytvořením technologie Virtual Private Database. Je součástí Enterprise Edition. I když jde o relativně unikátní technologii, její základní logika je jednoduchá. Kdykoliv uživatel zadá dotaz pracující s chráněnou tabulkou, databáze automaticky připojí k SQL dotazu definovanou bezpečnostní podmínku. Teprve takto vzniklý výsledný dotaz je optimalizován a proveden. Bezpečnostní podmínka přitom není statická, je generována uloženou procedurou v době spuštění dotazu. Podmínka se tak může lišit v závislosti na aktuálním uživateli (jiná podmínka pro zaměstnance, jiná pro zákazníky), IP adrese klienta, nebo libovolných jiných faktorech.

    Máme-li již základní objekty v databázi, stačí pro implementaci Virtual Private Database dva kroky:

    1. Napsat PL/SQL funkci vracející bezpečnostní podmínku
    2. Vytvořit bezpečnostní politiku, a tím spojit výše vytvořenou funkci s určitou tabulkou

    Níže si celý postup ukážeme na příkladu vynucení již dříve uvedených pravidel pro přístup k seznamu objednávek. Pokud si postup chcete vyzkoušet, na konci článku najdete skript pro vytvoření základních objektů, na které budeme nyní aplikovat Virtual Private Database.

    1. Vytvoření PL/SQL funkce generující bezpečnostní podmínku
    Operaci proveďte jako vlastník dat – uživatel OBJEDNAVKY.

    CREATE OR REPLACE FUNCTION obj_vpd_sec (
      schema_name IN VARCHAR2,
      table_name IN VARCHAR2)RETURN VARCHAR2 AS
        l_user_id uzivatele.user_id%TYPE;
        l_typ uzivatele.typ%TYPE;
        l_podminka VARCHAR2(4000);
    BEGIN
      --Zjištění informací o aktuálním uživateli
      SELECT user_id,typ
        INTO l_user_id,l_typ
        FROM uzivatele
        WHERE username = sys_context('USERENV','SESSION_USER');
    
      IF (l_typ=1 or l_typ=2) THEN
        --Obchodník či manager smí pracovat s 
        --objednávkami, které prodal
        l_podminka := l_podminka ||'(obchodnik='
                      || l_user_id||')';
        IF (l_typ = 2) THEN
          -- Manager smí navíc pracovat s objednávkami
          -- svých podřízených
          l_podminka := l_podminka || ' OR obchodnik in ('
                        || 'SELECT user_id 
                              FROM objednavky.uzivatele '
                        || '   CONNECT BY nadrizeny = PRIOR user_id'
                        || '   START WITH nadrizeny =' 
                        || l_user_id || ')';
        END IF;
      ELSE
        --Zákazník smí pracovat jen se svými objednávkami
        l_podminka:= '(zakaznik=' || l_user_id ||')';
      END IF;
      RETURN l_podminka;
      EXCEPTION
        WHEN no_data_found THEN
          -- Ani zákazník, ani zaměstnanec - nevracet žádná data
      return '(1=2)';
    END;
    /
    

    Funkce načte informace o aktuálním uživateli a podle typu uživatele vygeneruje text příslušné podmínky:

    • Zákazník smí vidět jen své objednávky:
      (zakaznik = <číslo uživatele>)
      
    • Obchodník smí vidět jen objednávky, které sám prodal:
      (obchodnik = <číslo uživatele>)
      
    • Manažer smí vidět jen ty objednávky, které prodal on sám, nebo některý z jeho podřízených:
      (obchodnik = <číslo uživatele>) 
        OR obchodnik in (
          SELECT user_id 
            FROM objednavky.uzivatele 
            CONNECT BY nadrizeny = PRIOR user_id
            START WITH nadrizeny = <číslo uživatele>
          )
      

    2. Vytvoření bezpečnostní politiky
    Funkci generující bezpečnostní podmínky již máme. Nyní vytvoříme bezpečnostní politiku, a tím dříve vytvořenou funkci zaregistrujeme k tabulce OBJ. Operaci proveďte jako uživatel SYSTEM.

    BEGIN
      dbms_rls.add_policy(
        object_schema=>'OBJEDNAVKY',  
        object_name => 'OBJ',
        policy_name => 'OBJEDNAVKY_POLICY',
        function_schema => 'OBJEDNAVKY',
        policy_function => 'OBJ_VPD_SEC',
        update_check  => TRUE);
    END;
    /
    

    Při každém dalším přístupu k tabulce OBJ se od teď použije bezpečnostní podmínka, kterou vrací procedura OBJ_VPD_SEC. Parametr update_check=TRUE zajistí, že se podmínka aplikuje nejen při čtení dat (ať již v rámci dotazu či čtení vstupních dat pro DML operaci), ale testují se i uživatelem měněná data. Uživatel ani nemůže vložit či změnit záznam tak, aby záznam odporoval bezpečnostní podmínce.

    Test funkčnosti
    Implementovaný mechanismus Virtual Private Database nyní vyzkoušíme. Ověříme, zda každý uživatel vidí pouze ty objednávky, které dle výše uvedených pravidel má vidět.

    Manažer SEFICEK vidí objednávky, ve kterých figuruje jako obchodník, ale i ty, které prodali jeho podřízení (uživatelé 2 a 3).

    CONNECT seficek@orcl
    SELECT * 
      from OBJEDNAVKY.OBJ;
    
    OBJ_ID     ZAKAZNIK   OBCHODNIK  ZBOZI                  CENA
    ---------- ---------- ---------- ---------------- ----------
             1          4          2 Propisky               2520
             2          5          3 Bloky                  3425
             3          4          3 Ořezávátka             1250
             4          5          2 Tužky                   860
             5          4          1 Propisky               2520
    

    Obchodník NOVACEK (user_id=2) vidí objednávky, ve kterých figuruje jako obchodník.

    CONNECT novacek@orcl
    SELECT * 
      from OBJEDNAVKY.OBJ;
    
    OBJ_ID     ZAKAZNIK   OBCHODNIK  ZBOZI                  CENA
    ---------- ---------- ---------- ---------------- ----------
             1          4          2 Propisky               2520
             4          5          2 Tužky                   860
    

    Zákazník MALY (user_id=4) vidí jen svoje objednávky.

    CONNECT maly@orcl
    SELECT * 
      from OBJEDNAVKY.OBJ;
    
    OBJ_ID    ZAKAZNIK   OBCHODNIK  ZBOZI                  CENA
    ---------- ---------- ---------- ---------------- ----------
             1          4          2 Propisky               2520
             3          4          3 Ořezávátka             1250
             5          4          1 Propisky               2520
    

    Ostatní uživatelé databáze neuvidí v tabulce OBJEDNAVKY.OBJ žádná data. To se při stávající podobě funkce OBJ_VPD_SEC týká i vlastníka tabulek, uživatele OBJEDNAVKY. Pokud by měl vlastník tabulek vidět data, bylo by potřeba patřičně upravit funkci OBJ_VPD_SEC. Výjimku ve VPD má pouze uživatel SYS a uživatelé se systémovým právem EXEMPT ACCESS POLICY. Ti vidí vždy veškerá data.

    Protože jsme při volání DBMS_RLS.ADD_POLICY použili parametr update_check=TRUE, omezuje se nejen rozsah záznamů, nad kterými se jednotlivé dotazy a DML operace provádějí, ale kontrolují se také hodnoty vkládané uživateli. Uživatel NOVACEK (user_id=2) tedy není schopný vložit objednávku, ve které není uvedený jako obchodník. Totéž platí i pro UPDATE.

    CONNECT novacek@orcl
    INSERT INTO objednavky.obj 
        (obj_id, zakaznik, obchodnik, zbozi, cena) 
      VALUES 
        (6,5,2,'Ořezávátka',1860);
    
    1 row created.
    
    INSERT INTO objednavky.obj
        (obj_id, zakaznik, obchodnik, zbozi, cena) 
      VALUES 
        (7,5,3,'Ořezávátka',1860);
    
    ERROR at line 1:
    ORA-28115: policy with check option violation
    
    UPDATE objednavky.obj 
      SET obchodnik = 1 
      WHERE obchodnik = 2;
    
    ERROR at line 1:
    ORA-28115: policy with check option violation
    

    Uvedený příklad je samozřejmě zjednodušený tak, aby z něj bylo zřejmé základní použití Virtual Private Database. Při skutečném nasazení této technologie bychom nejspíš uvažovali ještě o některých dalších změnách z důvodů optimalizace:

    1. Pokud by PL/SQL funkce generující podmínku byla sama o sobě náročná na zdroje a přitom pro určité spojení vracela stále tutéž hodnotu, bylo by možné definovat politiku jako context-sensitive. Databáze by si pak pamatovala vrácenou hodnotu pro určité spojení a nevolala funkci při každém dotazu nad tabulkou.
    2. Stejně jako je obvykle dobré z bezpečnostních i výkonnostních důvodů nahradit hodnoty v dotazech vázanými proměnnými (bind variables), bylo by v tomto případě vhodné použít Application Context pro uložení hodnoty ID a typu uživatele v rámci databázového spojení. Hodnoty bychom mohli naplnit například v logon triggeru. V generované bezpečnostní podmínce bychom se pak na tyto hodnoty odkazovali funkcí SYS_CONTEXT.
    3. Pokud by se jako výkonnostní problém ukázal vnořený hierarchický dotaz, který je v bezpečnostní podmínce generován pro manažery, bylo by opět možné uvažovat o nacachování jeho výsledků – například v globální proměnné typu nested array uvnitř PL/SQL balíku. Generovaná PL/SQL podmínka by se pak odkazovala na obsah tohoto pole. Samozřejmě by to znamenalo, že případné změny v hierarchii zaměstnanců by se projevily až po dalším přihlášení.

    Skript pro vytvoření základních objektů
    Výše uvedený příklad využívá databázové objekty, které si můžete vytvořit následujícím skriptem. Tyto operace proveďte jako uživatel SYSTEM (nebo jiný DBA).

    -- SCHÉMA pro aplikační objekty
    CREATE USER objednavky IDENTIFIED BY objednavky
       DEFAULT TABLESPACE users QUOTA UNLIMITED ON users;
    GRANT CONNECT, CREATE TABLE, CREATE PROCEDURE TO objednavky;
    -- UŽIVATELÉ - Zaměstnanci a zákazníci
    CREATE USER seficek IDENTIFIED BY seficek;
    CREATE USER novacek IDENTIFIED BY novacek;
    CREATE USER maly IDENTIFIED BY maly;
    GRANT CONNECT TO seficek,novacek,maly;
    -- TABULKY A DATA
    CREATE TABLE objednavky.uzivatele (
       user_id number primary key,
       username varchar2(30) unique,
       jmeno varchar2(30),
       -- typ:0=zakaznik, 1=obchodnik, 2=manager
       typ number CHECK (typ IN (0,1,2)), 
       nadrizeny number references objednavky.uzivatele);
    
    CREATE TABLE objednavky.obj (
       obj_id number primary key,
       zakaznik number references objednavky.uzivatele,
       obchodnik number references objednavky.uzivatele,
       zbozi varchar2(30),
       cena number);
    
    INSERT INTO objednavky.uzivatele
        VALUES (1,'SEFICEK', 'Tomáš Šéfíček', 2,null);
    
    INSERT INTO objednavky.uzivatele 
        VALUES (2,'NOVACEK','Petr Nováček', 1,1);
    
    INSERT INTO objednavky.uzivatele 
        VALUES (3,'STARY','Zdeněk Starý',1,1);
    
    INSERT INTO objednavky.uzivatele 
        VALUES (4,'MALY','Jiří Malý',0,null);
    
    INSERT INTO objednavky.uzivatele 
        VALUES (5,'CHUDOBA','Pavel Chudoba',0,null);
    
    INSERT INTO objednavky.obj VALUES (1,4,2,'Propisky',2520);
    INSERT INTO objednavky.obj VALUES (2,5,3,'Bloky',3425);
    INSERT INTO objednavky.obj VALUES (3,4,3,'Ořezávátka',1250);
    INSERT INTO objednavky.obj VALUES (4,5,2,'Tužky',860);
    INSERT INTO objednavky.obj VALUES (5,4,1,'Propisky',2520);
    COMMIT;
    
    -- Práva uživatelů na tabulku objednávek
    GRANT select, insert, update, delete 
    			ON objednavky.obj TO seficek, novacek, maly;
    

    Dnešní ukázky si můžete vyzkoušet na Oracle Database Enterprise Edition. Tu si pro testovací účely můžete stahnout z Oracle Technology Network.

    O autorovi
    David Krch (*1976) pracuje ve společnosti Oracle Czech na pozici Technology Sales Consultant. Vystudoval obor Informační technologie na Vysoké škole ekonomické. Od roku 2001 působí ve firmě Oracle Czech na pozici Technology Sales Consultant, ve které je zodpovědný za podporu prodeje technologií Oracle. Z počátku se zaměřoval na portálová řešení. Od roku 2002 se specializuje na podporu prodeje databáze Oracle a témata související se zajištěním provozu, jako je bezpečnost a vysoká dostupnost. Jako nezávislý vývojář vyvíjel na zakázku databázové aplikace s využitím desktopových databází.

    Související články:
    Tipy a triky pro Oracle XVI. – rychlejší aplikace i bez změn dotazů podruhé (03.02.2009)
    Tipy a triky pro Oracle XV. – rychlejší aplikace i bez změn dotazů poprvé (21.11.2008)
    Tipy a triky pro Oracle XIV. – datová komprese (21.10.2008)
    Tipy a triky pro Oracle XIII. – externí data rychle (17.09.2008)
    Tipy a triky pro Oracle XI. – Error Logging Tables (12.11.2007)
    Tipy a triky pro Oracle X. – bojujete s češtinou v Oracle podruhé? (14.05.2007)
    Tipy a triky pro Oracle IX. – bojujete s češtinou v Oracle? (06.02.2007)
    Tipy a triky pro Oracle VIII. – jak na přenosy velkých dat podruhé (03.01.2007)
    Tipy a triky pro Oracle VII. – jak na přenosy velkých dat poprvé (21.11.2006)
    Tipy a triky pro Oracle VI. – trochu jiné triggery (25.09.2006)
    Tipy a triky pro Oracle V. – změna dat v pohledu? (06.09.2006)
    Tipy a triky pro Oracle IV. – analytické funkce podruhé (14.08.2006)
    Tipy a triky pro Oracle III. – analytické funkce poprvé (19.07.2006)
    Tipy a triky pro Oracle II. – jak na hierarchické struktury? (07.06.2006)
    Tipy a triky pro Oracle I. – jak na automatické přidělování ID? (05.05.2006)

    ( Celý článek! | Autor: David Krch | Počet komentářů: 0 | Přidat komentář | Informační e-mailVytisknout článek )

    Vyhledávání
     

    Nenechte si ujít
    Seriál 365 x SQL - Tipy triky pro SQL

    Anketa
    Uvítali byste reinkarnaci Databázového světa?

    Ano 
     (2441 hl.)
    Ne 
     (1947 hl.)

    Celkem hlasovalo: 4388


    Poslední komentáře
    frontierd@126.com
    frontierd@126.com
    frontierd@126.com
    c
    http://www.coachoutl

    Newsletter
    Přihlaste si nezávazně - i bez registrace - odběr informačního newsletteru. Podrobné informace najdete zde.

    Emailová adresa:


    Kalendář
    <<  Červenec  >>
    PoÚtStČtSoNe
     123456
    78910111213
    14151617181920
    21222324252627
    28293031   

    Redakci připojuje


    Nejčtenější

    Databáze je prázdná!


    Nejvíce komentářů

    Databáze je prázdná!


    Reklama






    Nenechte si ujít články na dalších webech




    Na této stránce použité názvy programových produktů, firem apod. mohou být ochrannými známkami
    nebo registrovanými ochrannými známkami příslušných vlastníků.

    Databázový svět | dfKlub - digitální fotografie | Vtipník - vtipy přímo k Vám | Reminder - přestaňte zapomínat | Databázový svět

    Copyright (c) 2004 AVRE Publishing, spol. s r.o. Všechna práva vyhrazena