Zabezpečení přístupu k dokumentům v Oracle UCM, část 4

4. Stavy položky v UCM
Kromě dříve zmíněných mechanismů může být přístup k položce omezen také díky interní stavové logice (reprezentované interním atributem Status, kterou není možné aktualizovat jako ostatní metadata). V podstatě platí, že není-li položka ve stavu Released, je buď něco špatně a nebo čeká na dokončení nějakého interního tasku.

Které akce mohou měnit stav položky?
a) nastavení ReleaseDate či ExpirationDate - položka je ve stavu Done či Expired a zobrazuje se výhradně v administrátorské aplikaci Repository Manager
b) vstup položky (nové verze položky) do workflow - položka je ve stavu Review resp. Edit resp. Pending a kromě Repository Manageru ji mohou vidět i účastníci workflow, kterým je přiřazena
c) konverze nativního dokumentu do web-viewable formátu (je-li užíváno) - položka je ve stavu GenWWW, tento stav by měl mít krátké trvání
d) smazání položky - položka je ve stavu Deleted

O změně hodnoty stavu položky viz. tento manuál, str. 1-16.

5. Speciální komponenty
Není asi překvapením, že kromě těchto standardních mechanismů existuje i nespočet bezpečnostních mechanismů dodávaných komponentami. Jako příklad uveďme rozšíření vyplývající ze standardní komponenty RecordsManager (DoD Edition) - viz zde. Zde se jedná o tzv. klasifikaci položky ('Důvěrné', 'Tajné', 'Supertajné'). Tato konkrétní implementace je velmi podobná bezpečnostním třídám - kromě nastavení atributu položky je však vyžádováno, aby si položka s sebou nesla i základní informace o klasifikaci resp. deklasifikaci položky; fakticky se tedy jedná o doplnění dalších metadat, které se základním atributem souvisí.
Jiným případem z oblasti RecordsManageru jsou tzv. doplňující označení (supplemental markings). Jedná se opět o textovou klasifikaci položky, na základě je možné přiřadit přístup k položce uživatelům. Na rozdíl od bezpečnostních skupin, či účtů, může být jedné položce přiřazeno více označení a uživatel má přístup k položce jen tehdy, má-li definováno oprávnění ke všem přiřazeným označením.

Zabezpečení přístupu k dokumentům v Oracle UCM, část 3

3. Přístupové seznamy (Access Control Lists)
Dalším mechanismem na definici přístupu jsou přístupové seznamy (Access Control Lists, ACLs). Jakkoli se nakonec setkáme s již známými oprávněními (permissions), jsou ACLs jistým způsobem jiné, než bezpečnostní skupiny či účty. A to především tím, že vůbec nic dopředu nedeklarují - přístup ke každé položce je možné definovat až na úrovni jednotlivé položky, tj. přímo v metadatech konkrétní položky je seznam uživatelů či skupin uživatelů, kteří mají v daném okamžiku k položce přístup. V předchozí větě bylo také naznačeno, že u ACLs se mnohem častěji dá předpokládat, že se budou v čase měnit. Řízené změny (např. v rámci workflows) jsou v pořádku, neřízené změny (odchod či změna pozice zaměstnance) se však mohou stát pěknou noční můrou - proto je třeba k implementaci ACLs přistupovat s mnohem větším rozmyslem.

ACLs se do Stellentu dostaly díky komponentě Collaboration Manager. Jejich popis proto najdeme v tomto manuálu. V poměrně nedávno uveřejněné notě na Metalinku (ID 603148.1) je však uveden i popis, jak využít tento mechanismus bez nainstalování komponenty.

Nasazení v rámci Collaboration Manageru má i tu výhodu, že poměrně úspěšně předchází riziku nekontrolovaného bujení zmatku v ACLs - ACLs se využívají jen v rámci tzv. projektů, které mají svého manažera spravujícího přístup a velmi často i předem danou délku trvání projektu, po které nezřídka dojde k zakonzervování dokumentace.

Jakkoli platí, že ACLs je skutečně možné definovat až na úrovni položky, velmi často se nastavení dědí, a to ze složky, do které je položka přiřazena (o nastavení složek viz tento manuál). Speciálními složkami jsou pak již zmíněné projekty - na této úrovni spravují přístup projektoví manažeři.

U ACLs, podobně jako u účtů také platí, že je možné v hierarchii práva nejen přidávat, ale i odebírat (do definice se přidá uživatel či skupina s prázdným seznamem oprávnění). Jinak také platí, že ACLs jsou doplňkem k ostatním mechanismům a výsledné oprávnění vzniká jako průnik všech oprávnění vztahujících se na položku. Při využití komponenty Collaboration Manager jsou automaticky všechny položky z projektů převedeny do bezpečnostní skupiny 'Project'. S výjimkou opodstatněných případů proto doporučuji tyto mechanismy raději nemíchat.

Pokračování v budoucích článcích.

Zabezpečení přístupu k dokumentům v Oracle UCM, část 2

2. Účty

Mechanismem, který dále rozšiřuje možnosti zabezpečení, jsou tzv. účty (accounts). I při jejich užití se využívá mechanismus oprávnění (permissions) popsaných v prvním článku. Na rozdíl od bezpečnostních skupin

• je využívání účtů volitelné - jejich užívání je nezbytné nejprve povolit (více viz manuál)
• účty jsou definovány hierarchicky a nejlépe odpovídají situaci, kdy je možné položky rozdělit dle nějaké pevné hierarchie (např. geograficky)
• hierarchii účtů resp. příslušnost uživatelů k organizačním jednotkám v hierarchii, ze které je možné odvodit oprávnění, je velmi často možné získat z LDAP - tento fakt se velmi často a s velkým úspěchem v praxi využívá
• oprávnění přístupu k účtu je možné přiřadit jak roli, tak přímo uživateli
  

Technicky jsou účty definovány na straně položek opět jako atribut (jedno z metadat). V rámci definice Role se pak definuje přístup k účtu podobně jako přístup k bezpečnostní skupině. Fakticky však přiřazení přístupu znamená přístup ke všem položkám, jejich účet má prefix shodný s přiděleným právem.
Účty jsou doplňkem, nikoliv nahrazením bezpečnostních skupin. Slučování těchto bezpečnostních mechanismů se děje operací průniku oprávnění vyplývajících z obou:

Pokračování v dalších týdnech.

Zabezpečení přístupu k dokumentům v Oracle UCM, část 1

Jednou ze základních vlastností každého ECM systému je zabezpečení přístupu k dokumentům jen pro ty uživatele, kteří jej mají mít. Jakým způsobem je tato otázka řešena v Oracle UCM?

1. Bezpečnostní skupiny
Základním a povinným mechanismem jsou tzv. bezpečnostní skupiny. Bezpečnostní skupina je atribut položky (jedno z metadat), jehož nastavením se specifikuje, kdo bude mít k položce přístup a jaký přístup systém uživateli dovolí. Vztah mezi bezpečnostní skupinou jako atributem položky a přístupem konkrétního uživatele nejlépe popisuje následující obrázek:

Každá položka má přiřazenu právě jednu bezpečnostní skupinu a každý uživatel může mít přiřazeno více rolí. V případě více rolí je celkové oprávnění uživatele dáno jako maximální oprávnění mezi všemi přiřazenými rolemi k dané bezpečnostní skupině (př.: má-li role X přiřazená uživateli oprávnění {R - Read} na bezpečnostní skupinu SG1 a role Y oprávnění {R - Read, W - Write}, pak uživatel s rolemi X a Y bude mít na položky skupiny SG1 výsledné oprávnění {RW})

Co je to oprávnění?
Kdo se fakticky o autorizaci operací je oprávnění (permission). Oprávnění může být nastaveno na čtyřech úrovních:

• R - Read; toto oprávnění dává uživateli právo číst obsah i metadata vložené položky. U mechanismu bezpečnostních skupin je třeba poznamenat, že při vyhledávání se filtr na bezpečnostní skupiny vkládá přímo do WHERE klauzule dotazu - proto se nedoporučuje definovat více než 50 bezpečnostních skupin; na druhou stranu může při vhodném navržení systému tento mechanismus vyhledávání značně urychlit
• W - Write; toto oprávnění dává uživateli právo vkládat nové verze položek dané bezpečnostní skupiny, či měnit jejich metadata. Pro změnu atributu bezpečnostní skupiny musí mít uživatel právo W v obou skupinách.
• D - Delete; toto oprávnění dává uživateli právo mazat položky
  
• A - Administer; toto oprávnění dává uživateli právo vstupovat s položkou do ad-hoc workflows. Při užití některých dalších bezpečnostních mechanismů (např. Access Control Lists) musí mít uživatel toto oprávnění, aby mohl měnit bezpečnostní nastavení.

Oprávnění je možné přiřadit pouze kaskádově - tj. uživatel s oprávněním D automaticky získává i oprávnění R a W.

Pokračování v budoucích článcích.
Více na toto téma v tomto manuálu.