Wednesday 27 October 2010

Upgrade z verze UCM 10g na verzi 11g

Byť je to zřejmě ještě trochu předčasné, pokusme se zastavit nad tím, co by se muselo stát, aby se zákazník provozující verzi 10g zupgradoval na 11g.

Nejprve si položme otázku, co vlastně představuje běžící řešení (toto je poměrně obecná úvaha, která se ani zdaleka netýká jen Oracle UCM): řešení beží na nějakém hardware, na kterém je nainstalován nějaký běžící kód (software), další důležitou částí je pak konfigurace řešení a nakonec v tom celém jsou uložena nějaká data. Software bychom si pak mohli ještě rozdělit na standardní programy (např. balíková řešení, ale i třeba operační systém) a specifické programy (customizace - v UCM jsou to komponenty vyvíjené na míru potřebám konkrétního klienta).

Těchto pět částí, tj. hardware, standardní software, specifický software, konfigurace a data, představuje problém, se kterým se musíme vypořádat při upgradech, ale i třeba při budování záložního řešení, či obnově při výpadku.

a) hardware
Je smutnou pravdou, že při aktualizaci software, zejména jedná-li se o aktualizaci generační, bývá zpravidla nezbytné plně zaměnit hardware. Navíc vzhledem k tomu, že velmi často je prostě technicky nemožné "otočením klíčku" jedno řešení nahradit druhým, bývá nutné, aby po nějakou dobu běžela "staré" a "nové" řešení paralelně vedle sebe. Dnes může být řešením aplikační grid (či přímo "cloud"), pro zákazníky se skromnější infrastrukturou mohou vypomoci testovací či školící prostředí. S jistou mírou redundance je však třeba počítat vždy.

b) standardní software
Je-li řešení psáno jako vícevrstvé a dovolí-li to nároky na výkon a na bezpečnost, je možné při upgrade dosáhnout jisté synergie. Bohužel, díky zásadním změnám v architektuře mezi verzemi 10g a 11g existují v podstatě jen dvě komponenty, které jsou oběma společné - databáze a LDAP.

c) specifický software (v UCM custom komponenty)
Toto je samozřejmě šedá množina, o které se a priori nedá říct nic, než že je vše potřeba řádně otestovat, popř. opravit. V UCM je výhoda, že oba releases jsou minimálně psané v Javě, která je (teoreticky) plně přenositelná. Většina komponent je proto buď rovnou přenositelná nebo vyžaduje jen drobné úpravy. Existují výjimky, které se týkají změn v architektuře. Hlavní body jsou popsány v tomto příspěvku na fóru.
V ČR je využití custom komponent (s výjimkou jediného projektu, který je však ještě na starší verzi Stellentu) zatím minimální. Proto by s tímto bodem neměly být problémy.

d) konfigurace
Problém přenosu či uchování konfigurace se týká samozřejmě i např. přenosu mezi testovacími a produkčními prostředími. V UCM je k tomuto účelu určena komponenta Configuration Migration Utility (CMU), která umí exportovat či importovat většinu standardní konfigurace. Výjimku tvoří nastavení vytvořená v .cfg souborech (které je možné přenést jako takové) a pak konfigurace vytvořená pomocí některých komponent (např. i Folders; tj. definice hierarchie virtuálních adresářů).

e) data
I pro data, tj. vložené dokumenty a jejich metadata, existuje administrační aplikace zvaná Archiver. Původní využití této aplikace, jak možná napovídá název, bylo pro ukládání starších dokumentů do offline archivu. Již za časů Stellentu se však aplikace začala využívat i pro synchronizaci obsahu mezi servery, tedy potenciálně i pro migrace z jedné verze na další. V některých specifických případech (např. aktualizace metadat) je možné aplikaci využít i pro export a import dat ze stejného systému.

Pro verzi 11gR2 již existují specifikace, jak různé nástroje pro migraci konfigurace a dat sjednotit do jedné aplikace; rovněž bude implementována mnohem rozsáhlejší podpora pro hromadné operace nad více dokumenty.

Wednesday 20 October 2010

Records Management vs. Spisová služba, část 3. - teoretické možnosti ochrany dlouhodobě ukládaných dokumentů

V dnešním článku se zaměříme na ochranné prvky pro dlouhodobé ukládání elektronických dokumentů tak, jak je zná zákon 499/2004, tj. na elektronický podpis a časové razítko, stejně jako na další alternativní možnosti, jak zaručit 3 aspekty dlouhodobého uložení, tj. čitelnost, prokazatelnost a neměnnost.

Asi každý zná základní fakta, že dokument v digitální podobě se považuje za pravý, byl-li podepsán platným uznávaným elektronickým podpisem nebo označen platnou elektronickou značkou osoby ... a opatřen kvalifikovaným časovým razítkem. Stejně tak je známé, že elektronický podpis je platný max. po dobu 1 roku a časové razítko max. 5 let.

Na počátku jsou problémy hlavně s podpisy - zejm. jejich platností. Bude-li dokument opatřen platným podpisem, ale dorazí-li k příjemci až po vypršení platnosti, je problém. Toto je problém zejména ve spojitosti s autorizovanou konverzí el. dokumentu na listinnou podobu, ke které nemusí dojít okamžitě po doručení dokumentu.
Další drobnou komplikací souvidející z datovými schránkami je to, že u většiny schránek (typicky u osobních schránek), má doručení přes datové schránky stejnou právní platnost jako by byl dokument podepsán. To je možné vyřešit podepisováním - zde asi spíš značkou organizace - na příjmu.
Je-li však dokument podepsán, stejně není vyhráno, protože je třeba provést ověření platnosti podpisu. To je možné až na "next-business-day", protože rejstříky zneplatněných certifikátů se aktualizují (prý) někdy přes noc. Jen na okraj: ergo, datové schránky z podstaty věci není možné užít na "rychloobrátkové" dokumenty, kdy je třeba reagovat v rámci hodin či 1-2 dnů.
Z hlediska dlouhodobého uložení je však důležitější, že protokol o ověření platnosti podpisu (razítka) je také ZD a musí být uložen spolu s průvodním dokumentem.
K časovému razítku jen asi poznámku, že u datových schránek jimi sice opatřuje zprávu sám systém, jedná se však o razítko na celou zprávu (chcete-li: na zprávu v obálce), nikoliv na razítko přiloženého dokumentu/-ů. Ergo, budete-li chtít s dokumenty pracovat odděleně, budete jej muset zřejmě stejně přerazítkovat (pokud tak neučinil odesílatel).

Řekněme, že s tím se nějak vypořádáme. K problémům, na něž zatím neexistuje jasná odpověď, pak dojde v okamžiku vypršení platnosti časového razítka. Na nastalou situaci existují dva právní názory: jeden tvrdí, že pak je třeba dokument znovu přerazítkovat; druhý tvrdí, že není třeba dělat nic, protože v okamžiku zakládání dokumentu bylo vše platné. S druhým názorem by se mělo bojovat - pokud dojde k prolomení šifry, na které jsou založeny podpisy a razítka, může pak někdo "vyrobit" Vámi podepsaný dokument opatřený časovým razítkem, který jste nikdy neviděli. Aby toho nebylo málo, dodejme, že i ukládání elektronických podpisů není věčné - ukládají se myslím na 10 či 12 let, takže po této době se již ani nebude možné dopátrat, kdo to vlastně dokument podepsal.
Ani přerazítkovávání však není příliš lákavá možnost (tedy, pokud nejste certifikační autorita): pokud za rok vytvoříte X dokumentů, pak za 5 let budete přerazítkovávat X, za 10 let 2X, za 15 let 3x atd. A to prosím zpravidla najednou - nejspíš po měsíčních dávkách. Tedy náklady a jakási práce (nejspíš plně automatizovaná - RM systémy vám v tom mohou pomoci sledováním vypršení platnosti časového razítka).

Abychom už měli přehled úplný, dodejme ještě problém, který se zatím nikde moc neeskaloval - problém s čitelností. Dnes je čitelnost řešena taxatorním vyjmenováním formátů, ve kterých je možné dokumenty dlouhodobě ukládat - např. pro texty to je primárně PDF/A. Protože se však bavíme o dlouhých skartačních lhůtách -u některých dokumentů to může být na desítky let či "navždy", dá se předpokládat, že i od tohoto formátu se někdy upustí. Pokud někdo vyspecifikuje, jak PDF/A převést na formát XYZ (bude to další instituce pro autorizovanou konverzi?), je třeba dořešit, jak tento nový dokument svázat s původním obsahem, který obsahuje již dávno neplatné a možná i neexistující identifikátory původce -nejspíš tedy bude možné nějak "přibalit" XYZ k původnímu obsahu a držet vše pohromadě - toto je ostatně myšlenka tzv. archívních balíčků (AIP) z normy OAIS, kterou bude zřejmě nezbytné brzy zapracovat do zákona či vyhlášky.

Slíbil jsem ale přehled dalších možností, jak by se daly tři pilíře implementovat jinak:

1. certifikace systému
První možností jsou certifikace - u nás nejspíš stát jmenuje autoritu, která prověří systém (pro MoReq2 existuje sada testovacích případů, kterými bude testovaný systém prověřen). Poté platí, že je-li dokument vložen do systému jako ZD, pak je autentický a nezměněný. Tento princip dokáže řešit všechny tři pilíře (i konverzi je možné otestovat) a je užit např. v Belgii.

2. nezávislý arbitr

Myšlenkou tohoto řešení je, že bude existovat jeden centrální systém, ve kterém budou uloženy kopie všech dokumentů - pokud budete chtít mít jistotu, zeptáte se, zda dokument, který máte k dispozici, je originálem, za který se vydává. Toto řešení - zatím jen pro dokumenty z datových schránek pod hlavičkou CEED či CEDD - prezentovali někteří dodavatelé. Pokud by zároveň s licencí na provozování systému získali právo na provádění konverzí z důvodů čitelnosti, mohlo by to pro určité omezené celky (např. datové schránky) fungovat. Neumím si však představit, že by to fungovalo jako řešení pro RM obecně (když nic jiného: jak by se u tohoto Velkého Bratra řešila bezpečnost obsahu dokumentů?)

3. ochrana hardwarovými prostředky
Pro neměnnost a autenticitu dokumentu existuje ještě jedno řešení: využití technologií WORM (write-once-read-many), které z definice nedovolují obsah měnit. Protože však ani hardware není věčný, mají tato řešení podporu redundantního ukládání záznamu, resp. garanci dostupnosti. Fakticky se tak jedná o jakousi speciální verzi certifikace systému.

Wednesday 13 October 2010

Records Management vs. Spisová služba, část 2.

Abychom se dokázali posunout dále a vyhnuli se pokud možno termínové pasti, je třeba si narovnat základní pojmy: pro anglický termín document budu nadále používat český ekvivalent dokument a pro anglický termín record navrhuji založený, popř. zaknihovaný či zaregistrovaný dokument (zkráceně ZD).

Tento termín v sobě implicitně obsahuje informaci, že ZD je dokument, který prošel nějakým dalším procesem; osobně preferuji adjektivum založený, protože vychází ze zvyklosti, kdy se důležité listinné dokumenty, na kterým organizaci záleželo, zakládaly do spisů.

Takto vybaveni pokusíme zapátrat na internetu po definici pojmu records management. Poměrně vyčerpávající jsem našel na mé oblíbené wikipedii, a to zde. Až se probereme detaily, zkuste jen ze zvědavosti srovnat detaily s definicí spisové služby tamtéž.

1. RM je způsob uchovávání ZD organizace od jejich vzniku až po případnou dobu jejich skartace; RM zahrnuje klasifikaci, uložení, zabezpečení a zničení ZD (v některých případech i jejich archivní uchovávání)
... v této obecné rovině moc rozdílů nenajdeme

2. ISO 15489:2001 (jedna z mezinárodních norem specifikující pojem records management) zahrnuje do RM:
  • nastavení politik a standardů
  • přiřazení zodpovědností a odpovědností
  • vydání směrnic
  • poskytování řady služeb spojených se správou a užíváním ZD
  • navržení, zprovoznění a udržování systémů pro správu ZD
  • integraci RM s ostatními systémy a procesy organizace
... zde už pár drobných rozdílů najdeme. Především, musíme si uvědomit, že rozmach RM nastal (jak se ostatně v anglickém článku na wikipedii zmiňuje) po aféře společnosti Enron, která ve spolupráci s poradenskou firmou Arthur Andersen, podváděla své investory - na základě zfalšované či ztracené dokumentace.
U nás je praxe trochu jiná - RM či spisovou službu organizace provádějí, "protože to po nich stát chce"; často však aniž by stát sám věděl proč, či měl mechanismy jak provádět kontrolu
Můj oblíbený příklad, který uvádím při prezentacích: podle zákona 499/2004 Sb. mají povinnost uchovávat dokumenty také politické strany. Ve smyslu výše uvedeného případu Enron/Andersen by bylo zajímavé provést kontrolu, zda politické strany také neuvádějí v omyl své investory, tj. voliče...
Jiný případ nesouvisí přímo s dokumenty: během své civilní služby v polovině devadesátých let jsem na základní škole Na Líše prováděl kontrolu počtu plynových masek pro děti. Masky byly staré, zaprášené, nemyslím, že by v případě chemického poplachu byly velkou pomocí a naopak možná by spíš způsobily pár problémů v případě cvičení. Přesto, kdyby se ztratila byť jediná, tak paní ředitelku zavřou...
Ale k meritu věci: rozdíl mezi RM a spisovou službou je ten, že RM je mnohem více metodologie, či proces, který slouží k ochraně něčeho, co buď organizace, nebo stát chce chránit. Jeho hlavní podstatou je říct, co se má dělat a kdo je za to zodpovědný a je mnohem volnější v provedení jak. Naopak, spisová služba je hlavně povinnost. Specifikuje co, je velmi detailní v jak, ale je velmi vágní v definování odpovědnosti (zkuste si např. najít v textech najít slovo "odpovědn*"). V jisté extrémní interpretaci se naplnění povinnosti chápe jako "implementace (aplikace) spisové služby" - tj. termínem "spisová služba" se míní sama aplikace.

3. zastavme se ještě u standardů
Pokud připustíme, že i v komerční organizaci existují elektronické dokumenty, které má smysl dlouhodobě uchovávat, ale na které se nevztahuje zákon 499/2004 Sb. (nebo jiný, např. 235/2004 Sb., který se vztahuje na účetní dokumenty - účtenky a faktury, pokud by byly vydávány v elektronické podobě) - může se jednat o nejrůznější vnitrofiremní standardy a procedury, či např. osobní údaje zaměstnanců či údaje o zákaznících (zde může RM pomoci zejména se zákonnou skartací danou zákonem 101/2000 Sb. o ochraně osobních údajů), pak standardy uvedené v zákoně o spisové službě, resp. jeho prováděcí vyhlášce, mohou být značně na obtíž - asi není nic špatného na formátu PDF/A (zajišťujícím čitelnost), dost možná však nebudou třeba elektronický podpis (autenticita - vnitrofiremní systémy si jistě s autenticitou vkladatele poradí), ani časové razítko (neměnnost - opět, organizace bude "věřit" svému systému), nemluvě o košatém metadatovém modelu Národního standardu.

4. časově omezená platnost ochranných prvků aneb legislativní časovaná bomba?
V neposlední řadě je třeba zmínit snad již poměrně známý fakt, že ochranné prvky zajišťující dlouhodobé uložení, mají samy časově poměrně omezenou platnost - což. J. Peterka nazývá ve svém článku "Časovanou bombou v e-Governmentu". Toto téma si zaslouží samostatný článek.

Wednesday 6 October 2010

Records Management vs. Spisová služba, část 1.

Pokud bych se měl vyjádřit expresívně, pak v tom v tom tvůrci národního standardu pro spisové služby, byť možná ve vleku zákonodárce, udělali pěkný bordel.

Národní standard je do značné míry překladem evropské normy MoReq2 (mimochodem, už se připravuje nový standard MoReq2010 - bude se tedy Národní standard aktualizovat?), který ovšem obsahuje některé "překladatelské boty" (že by cui bono?), které ve svém důsledku vedou k naprostému zmatení pojmů. Totiž, větu, která v originále zní:
"some documents become records"
přeložili jako
"záznamy se stávají dokumenty"
(to jest prohodili pojmy).

Pojem "Electronic Records Management System" pak překládají jako "Elektronický systém spisové služby", což má evidentně navodit dojem, že "spisová služba" je tím pravým ořechovým pro udržování elektronických dokumentů.
Jakkoli je těchto pojmech beze vší pochyby značný překryv a existují organizace, kde plně splývají, spisová služba není totéž co records management a naopak.
Problém s termínem spisová služba je totiž ten, že je poměrně jasně specifikován zákonem 499/2004 Sb. - §63 stanoví kdo spisovou službu vykonává a §70 potom jakým způsobem.
Termíny spisová služba a records management tedy splývají výhradně u organizací uvedených v §63.
Sám zákon 499/2004 Sb. však stanoví, že "Povinnost uchovávat dokumenty a umožnit výběr archiválií mají" též další organizace dané zákonem. A pokud by tak nepřikazoval zákon, v přiměřené míře by tak měl přikazovat zdravý rozum (minimálně pro tu část věty "uchovávat dokumenty"), protože pro řadu organizací představují dokumenty a jejich efektivní správa skutečnou hodnotu. A troufnu si tvrdit, že přestože by řada z nich ocenila (možná pod vlivem okolností) records management, spisová služba by pro ně byla zbytečnou přítěží.

V čem tedy spočívá rozdíl?

(Pokračování příště)