Technická dokumentace

Transkript

1 Přílha č. 1 zadávací dkumentace veřejné zakázky Dluhdbé ukládání digitálních dkumentů Technická dkumentace Veškeré pžadavky a ustanvení uvedené v tét přílze jsu pvinné, musí být bsaženy v nabídce a musí být uchazečem splněny. Předmětem plnění veřejné zakázky s názvem Dluhdbé ukládání digitálních dkumentů jsu: Ddávka a implementace řešení dluhdbéh úlžiště digitálních dkumentů Ddávka a implementace HW garantvanéh úlžiště d Technlgickéh centra Plzeňskéh kraje

2 1 Řešení dluhdbéh ukládání digitálníh bsahu 1.1 Obecný ppis řešené blasti Pd pjmem dluhdbé ulžení je v kntextu tét zadávací dkumentace míněn důvěryhdné ulžení elektrnických (tzv. digital-brn ) neb digitalizvaných (skenvaných, převedených neb autrizvaně knvertvaných) dkumentů p dluhu dbu tedy v řádu desítek let, případně natrval. Základním pžadavkem je chrana dkumentu a zajištění čitelnsti jeh bsahu p celu dbu ulžení, přičemž chranu dkumentu a jeh čitelnstí je myšlena především schpnst důvěryhdně uchvat a zbrazit infrmační bsah dkumentu p celu dbu ulžení, a t nezávisle na pužitém frmátu či technlgii. Prblematika dluhdbéh ukládání digitálníh bsahu se v rámci výzvy IOP č. 08 řešila pr tři becné skupiny bsahu, který pr který je důležité zajistit dluhdbé bezpečné ulžení na úrvni kraje: 1. uzavřené elektrnické dkumenty a spisy ze spisvé sl užby p dbu běhu jejich skartační lhůty (krajská digitální spisvna, KDS), 2. digitalizvané dkumenty, ftgrafie a jiný materiál významné kulturní hdnty (krajský digitální repzitář, KDR), 3. statní elektrnické ( digital-brn ) neb digitalizvané subry bez specifickéh zařazení (krajské digitální úlžiště, KDÚ). Pptávané řešení se sustřeďuje na první skupinu, tedy na řešení krajské digitální spisvny (KDS), která je pr zadavatele klíčvá. Zadavatel nicméně d buducna předpkládá ptřebu zajištění dl uhdbéh a důvěryhdnéh ukládání i pr statní skupiny záznamů. Vzhledem k pdbnsti uvedených tří typů úlžišť a v suladu s dpručením zadavatel pžaduje, aby nabídnuté řešení byl d buducna svými technickými parametry schpn zajistit dluhdbé ukládání všech tří uvedených skupin bsahu, se všemi specifiky, které se k těmt skupinám bsahu vážu viz pžadavky typizvanéh prjektvéh záměru Digitalizace a ukládání z výzvy IOP č. 08 (viz Vlastní rzšíření nabízenéh řešení funkcinality krajskéh digitálníh repzitáře a krajskéh digitálníh úlžiště není v rámci tét veřejné zakázky pptáván, nicméně d buducna musí být mžné tt rzšíření zajistit puze knfigurací a parametrickými úpravami řešení, bez nutnsti přizvat nvé licence. Hvří -li se prt dále v tét zadávací dkumentaci krajské digitální spisvně či zkráceně KDS, je tím myšlen pptávané řešení dluhdbéh úlžiště, nastavené jak krajská digitální spisvna ; bdbně t platí pr případné pužití KDR a KDÚ. Dluhdbé úlžiště bude kmunikvat s dalšími infrmačními systémy, prvzvanými jednak půvdci ukládanéh bsahu na jedné straně, a zpracvateli bsahu na straně druhé. Řešení prt musí být na tut kmunikaci připraven. V případě krajské digitální spisvny se jedná především elektrnické spisvé služby jedntlivých půvdců a na Nárdní digitální archiv. Významná bude také vazba na systém epusa, který bude vůči navrhvanému řešení zajišťvat centrální správu uživatelských identit. Zárveň musí řešení variantně umžnit prvést všechny krky živtníh cyklu ulženéh záznamu plně manuálně (pr případ nerealizvané neb nefungující integrace). Řešení bude služit pr kraj, bce v kraji, pr zřizvané a zakládané rganizace kraje a bcí, d buducna není vylučen případné rzšíření další subjekty veřejné správy na území kraje (v případě rzšíření funkcinality úlžiště další typy bsahu). Důležitým pžadavkem prt je, aby řešení byl dstatečně rbustní a jeh architektura dpvídala jeh rzsahu a významu (pčet a velikst ukládaných záznamů, velký pčet uživatelů a jejich věření prti centrálnímu systému správy identit kraje, distribuvaná správa, mžnst hrmadných změn, dpvídající zajištění auditní stpy atd.).

3 Sučástí ddávky budu také pdpůrné nástrje, nutné pr zajištění důležitých funkcí KDS. Tyt nástrje musí být implementvány jak samstatné mduly tak, aby byly využitelné i dděleně d dluhdbéh úlžiště. Záznamy, určené pr dluhdbé ulžení, je nutné před vlastním ulžením většinu zpracvat. Sučástí pptávanéh řešení prt bude pracvní úlžiště jak nástrj pr řízení lgických úlžišť nad subrvým úlžištěm se základními vlastnstmi jednduchéh DMS systému, které umžní jedntlivým půvdcům pracvní ulžení a přípravu dat, následně určených k dluhdbému ulžení. Jak sučást řešení je pžadvána ddávka samstatnéh nástrje pr knverzi datvých frmátů d PDF/A pr zajištění převdu dkumentů d krektníh archivníh frmátu, a dále samst atný nástrj pr manuální tvrbu SIP balíčků pr půvdce, kteří svji spisvu službu nebudu mít na dluhdbé úlžiště napjenu. 1.2 Obecný ppis stávajícíh stavu Půvdci bsahu a spisvé služby v kraji Největšími půvdci dkumentů na území kraje jsu Plzeňský kraj (krajský úřad) a Statutární měst Plzeň (magistrát a úřady městských částí). Krajský úřad pužívá elektrnicku spisvu službu AthenA splečnsti PilsCm. Měst Plzeň pužívá elektrnicku spisvu službu espis splečnsti ICZ. Kraj dále prvzuje hstvanu spisvu službu Galatea v rámci řešení VIRTUOS ( která je k dispzici bcím na území kraje a krajem zřizvaným rganizacím. V sučasné dbě využívá tut spisvu službu přes 100 bcí různé veliksti a něklik desítek rganizací kraje. Větší města na území kraje pužívají různé spisvé služby, ve velké většině se jedná známá zavedená řešení elektrnické spisvé služby. Malé bce většinu vedu spisvu službu v listinné pdbě. Cílem kraje je vybudvat řešení dluhdbéh ukládání digitálních dkumentů především pr výše uvedené půvdce a napjit na tt dluhdbé úlžiště jejich stávající elektrnické spisvé služby. Priritu je přitm napjení největších půvdců a nejrzšířenějších el. spisvých služeb. Předpkládaný bjem dkumentů, vyžadujících ulžení v krajské digitální spisvně, byl ve studii prveditelnsti v rce 2010 dhadnut na 2 4 TB rčně, z th zhruba plvina dkumentů se skartační lhůtu d 2 let Stávající řešení digitálních dkumentů Elektrnická spisvá služba AthenA na KÚPK bsahuje mdul spisvny, ten však v pdbě, v jaké je nyní implementván, nesplňuje velku část pžadavků, kladených na řešení KDS v tét zadávací dkumentaci. Jeh sučasná rle je především evidenční. Nutnu pdmínku je prt prpjení el. spisvé služby AthenA s pptávaným řešením Správa uživatelských identit Plzeňský kraj pužívá pr řízení uživatelských identit ve svých infrmačních systémech tři hlavní typy Identity Management systémů:

4 1. Marbes EOS + MS Active Directry pr identity uživatelů KÚPK a rganizací, pr které dbr infrmatiky KÚPK zajišťuje svěřenu správu ICT (Správa a údržba silnic Plzeňskéh kraje, Centrální nákup Plzeňskéh kraje, Zdravtnický hlding) celkem cca 650 uživatelů. 2. epusa pr identity uživatelů z řad bcí a uživatelů z příspěvkvých rganizací kraje a bcí, kteří přistupují k infrmačním systémům kraje. D epusa autmaticky přenášeny identity uživatelů z MS AD. Identity z epusa jsu zárveň dále přenášeny d JIP (CzechPOINT) řádvě jde tisíce uživatelů. 3. SSO databáze pr statní uživatele především z řad bčanů a pdnikatelů pr přístup d systémů, ve kterých není nutná garance důvěryhdnsti identity řádvě tisíce uživatelů. Pr infrmační systémy, prvzvané jen pr vnitřní ptřebu Krajskéh úřadu, je využita autentizace s využitím dménvéh přihlášení (MS AD). U celkrajských řešení, která jsu určena i pr uživatele mim KÚ a kam bude patřit i pptávané dluhdbé úlžiště, je pr autentizaci uživatelů využívána aplikace SSO, která zajišťuje integrvané věření uživatelů a zachvání principu jednh přihlášení (single sign-n) d všech aplikací kraje, ke kterým má uživatel přidělená práva. Jedná se prprietární řešení Plzeňskéh kraje pr věřvání uživatelů z více zdrjů, kmunikující s aplikacemi prstřednictvím SOAP Web Services prtklem SAML. 1.3 Obecné pžadavky na řešení Kvalita řešení Pr řešení dluhdbéh úlžiště, které má být implementván, jsu stanveny následující cíle na pžadvanu kvalitu: uživatelská přívětivst efektivita škálvatelnst a mdularita kmpatibilita prcesů s mdelem OAIS Uživatelská přívětivst Uživatelům musí být umžněn vyknávat svu práci maximálně efektivně. Na základě přiměřensti musí být prt splněny následující pžadavky: Efektivit a veškerá uživatelská rzhraní musí být v českém jazyce (puze u rzhraní pr technicku admini straci řešení je pvlen i anglický jazyk) funkcinality systému musí být c nejvíce samvysvětlující, intuitivní, s relevantní nápvědu úplná dkumentace (administrátrská, uživatelská) v českém jazyce Řešení musí uživateli maximálně zjednduš vat a autmatizvat především činnsti, které se čast pakují. Nesmí p uživateli vyžadvat pakvané zadávání stejných dat. Všude tam, kde t přichází v úvahu, musí nabízené řešení nabízet mžnst hrmadnéh zpracvání (vstup, vydávání, skartace, změna vlastníka neb právnění) k více dkumentům najednu. Škálvatelnst a mdularit a Je pžadvána bezprblémvá škálvatelnst řešení, jak c se týká mnžství dat (pčtu dkumentů i jejich bjemu), tak pčtu půvdců (předávajících úřadů) a jejich uživatelů. Škálvatelnst nesmí být mezena

5 licenčně ani výknvě. Je vyžadvána mdulární stavba řešení. Jedntlivé kmpnenty řešení mhu být dstaveny, upgradvány atd. nezávisle na fungvání zbytku. Řešení se svým klím kmunikuje výhradně prstřednictvím defi nvanéh a ppsanéh aplikačníh rzhraní na bázi standardů a tevřených technlgií. OAIS-kmpatibilita (Open Archival Infrmatin System, ISO Standard 14721:2003) OAIS kncept je standardem ve frmě referenčníh mdelu pr dynamický, rzšiřitelný archi vní infrmační systém. S hledem na uchazečem nabízené c elkvé řešení se čekává, že se uchazeč rientuje v systémvém řešení dle OAIS mdelu a jeh řešení bude tent mdel respektvat. Pžadavek na kmpatibilitu s knceptem OAIS se vztahuje puze na vlas tní dluhdbé úlžiště, ne na pdpůrné nástrje. 1.4 Pžadvaný rzsah realizace Účelem tét části veřejné zakázky je vytvření a následná údržba dluhdbéh úlžiště, implementvanéh tak, aby plnil funkci krajské digitální spisvny, vytvření a následná údržba pracvníh úlžiště, implementace pdpůrných nástrjů a dále návrh suvisejících prcesů, rganizačních změn a smluvníh mdelu užívání. Uchazeč má v rámci zadaných rámcvých pdmínek nabídnut sftwarvu a systémvu architekturu, která umžňuje zadavateli dluhdbě zabezpečit stabilní prvz dluhdbéh úlžiště s důsledným zaměřením na dluhdbé a důvěryhdné uchvání dat se zajištěním jejich přístupnsti v každém čase a vybudváním archivačních prcesů pdle OAIS mdelu (ISO Standard :2003). Řešení musí být vysce škálvatelným, flexibilním mdulárně budvaným systémem, stabilním v datvé dispnibilitě a bezpečnsti. Předmětem plnění je: a) ddávka řešení a pskytnutí licence k jeh užívání, včetně přízení případných dalších licencí, nezbytných pr řádné plnění předmětu veřejné zakázky, b) implementace řešení, c) technická pdpra a údržba řešení. Dále jsu jedntlivé bdy upřesněny. Ddávka řešení a pskytnutí licence k jeh užívání, včetně přízení případných dalších licencí Licence dluhdbéh úlžiště, zahrnující nemezený pč et půvdců a jejich lgických úlžišť (předpkládá se v řádu tisíců), nemezený pčet uživatelů (předpkládá se v řádu desítek tisíc), nemezený pč et ulžených bjektů a pr nemezenu velikst úlžiště (pr ptřeby K DS se předpkládá velikst úlžiště v řádech desítek TB) Licence pracvníh úlžiště za stejných pdmínek jak v předchzím bdě Sučástí ddávky jsu veškeré nutné licence prduktů třetích stran, které nepskytne zadavatel (je upřesněn dále) a které jsu nezbytné pr řádný prvz řešení na zařízení zadavatele v suladu s tut zadávací dkumentací, Veškeré licence se pskytnu pr 3 ddělená prstředí (předpkládá se prdukční, testvací/vývjvé a šklící instance) platí zvlášť pr dluhdbé úlžiště a zvlášť pr samstatný nástrj pracvní úlžiště V rámci licence dluhdbéh úlžiště bude umžněn pužívat samstatný nástrj pr manuální tvrbu SIP balíčků na libvlném pčtu pčítačů zadavatele a jeh smluvních partnerů, kteří využívají služeb dluhdbéh úlžiště

6 Řešení nesmí být v žádném dalším hledu licenčně neb technicky mezen (velikstí úlžiště, pčtem spisů, dkumentů, typem bsahu, pčtem napjených aplikací apd.) Zadavatel pžaduje htvé, plně funkční řešení (uchazeč prkáže nasníma nu prezentací prduktu, přilženu k nabídce na CD/DVD viz pžadavky na bsah nabídky v Zadávací dkumentaci) Implementace řešení Implementace bude zahrnvat následující činnsti: Zpracvání prváděcíh prjektu (ppíše technické, rganizační a prcesní ptřeby a dpady a stanví přesný harmngram implementace) včetně rámcvé vstupní analýzy, Ddávka testvacíh a šklícíh prstředí, které bude živen jak první, Ddávka a implementace vlastníh řešení, Instalace a knfigurace prdukčníh prstředí, Piltní věření integračníh rzhraní frmu realizace plně funkčníh napjení těcht řešení elektrnických spisvých služeb půvdců na území kraje: spisvá služba Krajskéh úřadu Plzeňskéh kraje AthenA splečnsti PilsCm, Spisvá služba GalateA splečnsti PilsCm, kteru Plzeňský kraj hstuje pr bce a zřizvané rganizace jak sučást řešení VIRTUOS, Spisvá služba espis splečnsti ICZ zadavatelem vybranéh půvdce, Spisvá služba IS RADNICE VERA zadavatelem vybranéh půvdce. Zadavatel zajistí sučinnst půvdců při věřvání napjení. Prvedení šklení správců dluhdbéh úlžiště v rzsahu minimálně 2 šklících dní a klíčvých uživatelů (nejvýše 100 sb) v rzsahu 1 šklicí den na skupinu (každá skupina sb). Šklení prběhne v prstrách zadavatele, p dhdě bu stran je mžné prvést šklení i v jiných vhdných vybavených prstrách. Případné náklady na zajištění prstr nese v tm případě ddavatel. Zpracvání dkumentace finálníh vyhtvení včetně detailníh ppisu všech rzhraní a jejíh předání před přechdem na prduktivní prvz, Zajištění metdické i technické pdpry, Zpracvání kmpletní prvzní a bezpečnstní dkumentace řešení, včetně ppisu pravidelné údržby řešení, příprava strategických plánů pdle metdiky PLATTER, Pskytnutí sučinnsti při aktualizaci infrmační kncepce, vnitřních směrnic úřadu a jiných interních dkumentů, na které má implementace řešení vliv, Pskytnutí pdkladů a knzultací, ptřebných pr prvedení interníh auditu dluhdbéh úlžiště pdle DRAMBORA ( Zpracvání návrhu smluvy s dběrateli služeb krajské digitální spisvny včetně prvzních pdmínek a SLA. Technická pdpra a údržba řešení Na údržbu a pdpru řešení bude s vybra ným uchazečem uzavřena smluva technické pdpře na dbu neurčitu. Vybraný uchazeč bude v rámci tét smluvy pvinen zajistit, že veškeré funkce řešení, ppsané v tét zadávací dkumentaci a ddané splu s dílem a dkumentací díla budu dpvídat becně platným právním předpisům ČR a platným standardům, které musí pdle zákna neb pdle tét zadávací dkumentace ddržvat. Rzsah pdpry a údržby je pdrbněji specifikván dále v tmt dkumentu.

7 1.5 Funkční pžadavky řešení Dluhdbé úlžiště Základní pžadavky na vybudvání dluhdbéh úlžiště jsu následující vybudvání dluhdbéh úlžiště jak sučásti TC Kraje v suladu s pžadavky kladenými na důvěryhdnu instituci a stanvení a plnění pdmínek udržitelnsti prvzu v sučasnsti i buducnsti. nastavení dluhdbéh úlžiště pr ptřeby krajské digitální spisvny (KDS), tedy systémvéh řešení dluhdbéh a důvěryhdnéh uchvávání a zpřístupňvání úředních elektrnických dkumentů vytvřených určenými půvdci všechny vyřízené spisy a jiné dkumenty určenéh půvdc e jsu p dbu trvání skartační lhůty ulženy ve spisvně. P dbu ulžení elektrnickéh dkumentu musí být v suladu se záknem archivnictví a spisvé službě a jeh prváděcími předpisy zajištěna chrana ulžených infrmací před ztrátu, důvěryhdnst ulžených infrmací (nezměněnst a prkazatelnst vzniku v uvedeném čase) a čitelnst ulžených infrmací v buducnsti. Tedy ulžený dkument má mít tyt charakteristiky (dle standardu ISO Recrds Management): autenticity (authenticity) pr dkument může být prkázán, že je tím č em se dmníváme, že je (dkument neztratil smysl, význam), že byl vytvřen neb deslán danu sbu a že byl vytvřen neb deslán v daný čas, hdnvěrnsti (reliability) na dkument se můžeme splehnut, nebť jeh bsah je důvěryhdný, jelikž úplně a přesně vyjadřuje transakce, aktivity neb fakta, která ppisuje, integrity (integrity) dkument je kmpletní a nezměněný d kamžiku vstupu d KDS, pužitelnsti (usability) dkument může být dhledán, získán, prezentván a interpretván (je čitelný). přebírání, zpracvání, ulžení a zpřístupňvání úředních dkumentů a jejich metadat ze systémů elektrnických spisvých služeb a dalších AIS smluvních půvdců na území Kraje vlastníkem dkumentů ulžených v dluhdbém úlžišti zůstává příslušný půvdce. Kraj je správcem a prvzvatelem dluhdbéh úlžiště a s půvdci uzavírá smluvy ulžení dkumentů (službě) mžnst prvádění skartačníh řízení a t tak, že každý půvdce prvádí vzdáleně ska rtační řízení nad svými dkumenty, které má v dluhdbém úlžišti ulženy. Skartační řízení (skartační prces) musí být prváděn pdle platné legislativy a za pdpry legislativu stanvených rgánů. Řešení dluhdbéh úlžiště jak systém na dluhdbé a důvěryhdné uchvávání elektrnických dkumentů musí dpvídat standardu OAIS (Open Archival Infrmatin System nrma ISO 14721:2003). Ten specifikuje základní funkční části tevřenéh archivu, kmunikaci s klím, prcesy a infrmační mdel ve frmě infrmačních balíčků přijímaných, pskytvaných a především ulžených v úlžišti. Pr zabezpeč ení důvěryhdnsti a prvzu dluhdbéh úlžiště je nutné vypracvat a udržvat dluhdbý strategický plán cílů. Tyt cíle, resp. plány (např. technlgický, řízení lidských zdrjů, financvání, krizvý plán apd.) by měly vymezit všechna důležitá hlediska budvání a prvzu důvěryhdnéh úlžiště a tím umžňují předem definvat cíle, pstupy aktivity a rle, veducí k jejich naplnění. Řešení dluhdbéh úlžiště musí být ddán tak, aby mhl být pravidelně pdrbván internímu auditu a externí kntrle dle předem stanvené metdiky a vydefinvaných nástrjů.

8 Řešení KDS musí být v suladu s následujícími standardy: Zákn č. 499/2004 Sb. archivnictví a spisvé službě a změně některých záknů, ve znění pzdějších předpisů Vyhláška č. 259/2012 Sb. pdrbnstech výknu spisvé služby Nrma ISO Recrds Management Nárdní standard pr elektrnické systémy spisvé služby (NSESSS) Nrma ISO 14721:2003 standard OAIS Dkumenty, struktura a metadata ukládána v balíčcích AIP dle platné legislativy a se strukturu dle tevřenéh becně uznávanéh standardu (zadavatel předpkládá využití standardu METS viz Pdpra metadat ve frmátech METS, NSESSS, PREMIS ( případně i další frmáty pdle ptřeb zákazníka, včetně suladu metadat s platnu legislativu Mžnst aplikace časvých razítek a elektrnických značek, a t i více autrit na kmpletní balíčky AIP neb dávky balíčků, včetně mžnsti pakvané aplikace, s pužitím standardu umžňujícíh buducí věření platnsti razítka, pdle zákna č. 227/2000 Sb. elektrnickém pdpisu Vyhvuje prvzu spisvny/archivu pdle strategickéh plánu cílů směrnice PLATTER (viz např. či KDS musí být tevřený systém, který bude pskytvat služby vůči klním subjektům a dalším systémům a t zejména v blastech: Příjem dkumentů d spisvny Tat funkční část řeší příjem elektrnických dkumentů d půvdců ve stanveném frmátu a struktuře. Kmpnenty tét části mají za úkl přebírat hetergenní data d různých půvdců (úředních systémů), připravit je tak, aby byla schpna archivace a tat data předávat d části řešení Správa spisvny, administrace a bezpečné ukládání. Dkumenty by měly být d spisvny předávány zejména elektrnickými systémy spisvých služeb a agendvými infrmačními systémy - pracujícími jak ERMS systémy s pvinnými funkcemi uvedenými v Nárdním standardu, případně dalšími aplikacemi prdukujícími dkumenty. Řešení umžní manuální přípravu a příjem SIP balíčku s pmcí samstatnéh nástrje viz dále. Oblast Příjmu musí být v suladu s následujícími pžadavky: Kntrla frmální struktury SIP balíčků a kntrla na škdlivý bsah (antivirvá kntrla) s pužitím karanténní zóny Kntrla pvinných plžek ppisných metadat a přípustných frmátů subru Kntrla vazeb mezi dkumenty a číselníkvých plžek Zjištění a evidence technických metadat Kntrla zda balíček bsahuje platné autentifikační prvky (třeba elektrnický pdpis a časvé razítk). Genervání balíčků AIP a jejich řízené ukládání, tj. knzistentní ulžení metadat a bsahu archivních balíčků sučasně d archivníh úlžiště a systému správy dat pdle OAIS Předpkládá se, že v rámci implementace funkcinality krajské digitální spisvny budu dkumenty v SIP balíčcích typicky ddány v pžadvaných výstupních datvých frmátech (pdle 23 vyhlášky č. 259/2012 Sb.), tj. buď v těcht frmátech již vznikly, neb d nich byly převedeny půvdcem před příjmem balíčku. Řešení

9 však musí být schpn v rámci příjmu akceptvat i SIP balíčky, které budu krmě výstupních datvých frmátů bsahvat riginální zdrjvé frmáty dkumentů. Dluhdbé úlžiště sam sbě musí becně akceptvat balíčky s bsahem v jakémkli frmátu, který určí správce danéh typu úlžiště Správa spisvny, administrace a bezpečné ukládání Cílem tét funkční části je naplnění pžadavků na dluhdbst a důvěryhdnst uchvání a zajištění transparentnsti vůči klním subjektům. Řešení archivace má za úkl převzít d kmpnent Příjem dkumentů d spisvny vstupní připravené archivní jedntky, předávat je d archivníh úlžiště, knfigurvatelnu část metadat spravvat v přístupvé databázi (myslí se tím Data Management) a řídit systém ukládání. Vycházejíce z funkčních pžadavků na SW řešení musí být nabídka vyhtvena z hlediska HW (server, datvé úlžiště), který je v TCK. HW se může případně rzšířit bez kapacitníh mezení p c elu dbu prvzvání dluhdbéh úlžiště. Pr každéh půvdce je v systému KDS vytvřen lgicky ddělený prstr (lgický segment, lgické úlžiště) s vlastním řízením přístupvých práv, kde je ulžen kmpletní jím předaný bsah. Administrace i přístup k bsahu balíčků spisvny je pr každéh půvdce striktně ddělený, přičemž každý půvdce by měl mít definvanéh vlastníh správce, který administruje příjem balíčků, skartační řízení i další perace a spravuje číselníky i uživatele pr danéh půvdce. Správci mhu správu svéh bsahu dbrvlně delegvat na další uživatele mim rganizaci. V rámci lgickéh úlžiště se mhu evidvat balíčky pr jedntlivé rganizační jedntky půvdce. Také pužité číselníky (např. spisvý a skartační plán) musí být definvány a spravvány pr každéh půvdce dděleně. Administrátr systému KDS zajišťuje technicky prvz pr všechny půvdce, ale nespravuje ulžený bsah. Dkument musí být pvažván za prvěřený už v kamžiku, kdy vstupuje d spisvny. Spisvna nezaručuje autenticitu v tm smyslu, že by věřvala samtný dkument, ale zaručuje nezměnitelnst dkumentů ulžených v balíčcích d kamžiku předání d systému KDS a dluhdbě umžňuje autenticitu ulžených balíčků prkázat. Autenticitu balíčků ulžených v KDS a jejich nezměnitelnst je mžné zajistit sftwarvými i hardwarvými prstředky, třeba i externím autentifikačním způsbem prkazujícím daná data v čase a také příslušnými rganizačními patřeními. Mim všech prstředků chrany balíčků prti neprávněné mdifikaci a smazání je nutné na ulžené balíčky aplikvat i časvá razítka. Ta umžní dluhdbě prkázat autenticitu ulžených balíčků a jejich existenci v čase bez hledu na pužitu technlgii, i v případě buducí změny technlgií a přesunu dat na jiná média. Pravidelná aplikace časvých razítek na kmpletní bsah balíčků zajistí nezměnitelnst bsahu ulženéh v libvlných, spisvnu akceptvaných, frmátech. Zvlené technlgie a frmát časvých razítek by měly dpvídat účelům dluhdbé archivace, včetně krektníh ddržení standardů v tét blasti (je vyžadván sulad se standardem XML Advanced Electrnic Signatures). Řešení musí umžňvat takvu variantu metdy chrany balíčků, která nevyžaduje aplikaci časvéh razítka na jeden každý balíček, ale zajistí důvěryhdnst jejich bsahu hrmadě, jiným bezpečným algritmem, který umžní hrmadnu aplikaci časvéh razítka na splečný hash, spčítaný na základě bezpečnéh, běžně pužívanéh algritmu. Řešení musí umžňvat aplikaci časvých razítek něklika (minimálně tří) nezávislých autrit (TSA). Zejména prti změnám bsahu zapříčiněným technickými prblémy a degradací pužitých médií aplikují systém KDS i peridické věřvání kntrlních sučtů nad všemi ulženými balíčky AIP. Určité funkce bezpečnstníh a

10 autentizačníh charakteru je vhdné pnechat také na technlgických funkcích úlžiště, které na daném hardwarvém zařízení asi nejlépe prvedu ptřebné krky a patření. Veškeré perace s balíčky tzn. vstupní perace, výdej balíčků, perace ve skartačním řízení, perace pr zajištění autenticity balíčků musí být zaznamenány. Tyt záznamy budu bsahvat zejména čas prvedení, ppis perace a příslušnéh uživatele. Tyt záznamy budu dluhdbě ulženy stejným způsbem a se stejnu péčí jak primární bsah v archivním úlžišti systému KDS. Jedině tak je mžné zajistit dluhdbst a důvěryhdnst ulžení a jejich autenticitu. Řešení musí být v suladu s následujícími pžadavky pr Bezpečné ulžení: Sftware KDS bude pr ukládání balíčků AIP umžňvat pužití technlgie typu NAS/CAS/diskvé úlžiště, případně i v kmbinaci Sučástí tét veřejné zakázky je ddávka a implementace HW garantvanéh úlžiště. Řešení dluhdbéh úlžiště bude pr úlžiště typu CAS primárně využívat tt garantvané úlžiště, b ude však umžňvat integraci na jiné typy bezpečných úlžišť Mžnst ukládání a kntrly integrity d více fyzických diskvých úlžišť přím dluhdbým úlžištěm Peridické vytváření časvých razítek a jejich zabezpečené ulžení a evidence. Peridická kntrla knzistence ulžených dat na aplikační úrvni. Administrátrem dsuhlasená autmatická náhrada AIP balíčků, které byly zjištěny jak pškzené, z identických nepškzených kpií na úrvni práce s úlžištěm Neplatné SIP balíčky budu dmítnuty a půvdci vrácen chybvý kód. Odmítnutí bude lgván. Dkumenty budu ulženy ve frmě archivních balíčků AIP v archivním frmátu, bsahujících bsah dkumentů splečně s metadaty Jedntlivý AIP se nesmí děleně ukládat na více datvých nsičích a t ani při nedstatečném mnžství místa na jednm médiu Řešení musí pracvat s úlžišti tak, aby byl mžné je rzdílvě zálhvat, a t i p delší dbě pužívání uchazeč v nabídce ppíše způsb práce s úlžištěm, sučástí plnění bude zpracvání plánu zálhvání Ulžené balíčky AIP musí být dstupné i prstřednictvím standardníh rzhraní úlžiště i bez pužití specifickéh SW pr účely migrace a bnvy. Autrizace - mezení přístupů na základě klasifikace dkumentu, půvdce, uživatelských skupin a rlí uživatelů. Mdul pvlí přístup ke čtení bsahu neb metadat pdle rlí přihlášenéh uživatele a právnění příslušnéh balíčku. Prvádění transakčních záznamů přístupu k jedntlivým ulženým balíčkům veškerý přístup k balíčkům bude důsledně lgván Evidence veškerých přístupů k ulženým dkumentům v pdbě auditních záznamů Auditní záznamy veškeré manipulaci s infrmačními balíčky musí být ukládané d bezpečnéh úlžiště pdle vlby zadavatele pdpra syslg neb SNMP traps Systém KDS musí plnit veškeré funkce spi svny, tedy musí pdprvat i skartační řízení včetně všech náležitstí ve smyslu NSESSS. Pr účely práce s analgvými a hybridními dkumenty bude pdprvána evidence a zařazvání d fyzických ukládacích jedntek a spisven, evidence zápůjček a nahlížení d spisu, tvrbu tiskvých sestav zalžených nad ukládacími jedntkami ptřebných pr schvalvání skartačních návrhů, tedy věci bvyklé ve spisvnách papírvých dkumentů/spisů. Oblast Správa spisvny musí být v suladu s následujícími pžadavky:

11 Imprt, evidence a správa číselníků, zejména tyt číselníky - půvdci, spisvý a a skartační plán, pvlené subrvé frmáty, kategrizace dkumentů pdle kritérií přístupnsti, pžadavků na zachvání důvěryhdnsti, Přehled přijímaných a ulžených balíčků Kntrla knzistence ulžených balíčků AIP nezávisle na vlastnstech pužitéh archivníh úlžiště Pdpra skartačníh řízení s přístupem schvalujícíh archiváře Mžnst migrace ulžených frmátů subrů Mžnst exprtu a předání d Nárdníh digitálníh archi vu Oddělená správa a administrace technlgie systému KDS (kteru prvádí prvzvatel) d správy a administrace datvéh bsahu (kteru prvádí správci pvěření jedntlivými půvdci) KDS je lgicky rzdělen na jedntlivé lgické segmenty (spisvny) pr jedntlivé půvdce KDS, resp. jeh mdul archivníh úlžiště musí mít mžnst nastavení ukládání balíčků AIP d jedntlivých půvdců d lgicky, případně i fyzicky, ddělených částí úlžiště. Z phledu Administrace musí být řešení v suladu s následujícími pžadavky: Správa jedntlivých půvdců a jejich lgických segmentů (v případě KDS spisven jedntlivých půvdců) Skupiny uživatelů, uživatelé a rle a právnění, navázané na Identity Management systémy kraje přebírání uživatelských účtů, základních rlí právnění (minimálně na úrvni přístup an/ne ) a zařazení uživatelů d rganizací ze systému epusa Ověřvání uživatelů prstřednictvím řešení SSO Plzeňskéh kraje Histrické a buducí verze číselníků Centrální administrace a přístup pr správce půvdců Řízení prcesu příjmu, přehled stavu příjmu balíčků SIP, pdpra řešení případných prblémů se strukturu a bsahem balíčků při příjmu. Řízení prcesů migrace, spuštění migrace subrvých frmátů v ulžených balíčcích a přehled prvedených migracích. Samtné nástrje pr migraci frmátů nejsu předmětem plnění, řešení však musí být připraven na tent prces a na buducí rzšíření tyt nástrje. Skartační řízení, příprava návrhu a jeh schvalvání, prvedení skartace, případně exprtu d jinéh archivu v definvaném frmátu (typicky NDA, d buducna např. NDK). Správa funkcinality kntrly knzistence, včetně zajištění dkumentace tht prcesu. Správa číselníků, zajišťuje pr administrátry půvdce aktualizaci číselníků pužívaných v rámci vstupn í kntrly a vyhledávání. Důvěryhdné ukládání transakčních záznamů pr účely auditu, zaznamenávání veškerých prvedených perací nad ulženými balíčky (příjem, kntrla, transfrmace, ukládání, čtení). Přístup k transakčním záznamům, zbrazení transakčních záznamů pr účely auditu Vyřazvání dkumentů ze spisvny V rámci tét funkční části je řešena příprava návrhu a jeh schvalvání, prvedení skartace, případně exprtu d Nárdníh digitálníh archivu (případně d jinéh dluhdbéh úlžiště) v definvaném frmátu.

12 Na základě definvaných skartačních režimů systém navrhne příslušné perace v rámci skartačníh řízení a umžní psuzení a změny ve skartačním návrhu právněným uživatelům. Přitm musí být zajištěna pdpra i pr analgvé dkumenty a hybridní dkumenty. P schválení skartačníh návrhu systém jedntlivě prvede nad digitálně ulženými dkumenty příslušné perace tedy smazání bsahu dkumentů neb exprt d NDA. V případě, že NDA nepskytne v dbě plnění tét zakázky ppsané rzhraní na NDA, bude realizace funkcinality předávání digitálních archiválií implementvána až p zpřístupnění tht rzhraní v buducnu, a t zdarma jak sučást placené pdpry. Dkumenty jsu ve faktickém i právním vlastnictví půvdce a ten je za ně zdpvědný. Skartační řízení tedy prstřednictvím funkcí KDS prvádí určený pracvník půvdce. D NDA jsu balíčky předávány p uknčení skartačníh řízení ve frmátu určeném v NSESSS. Tyt balíčky jsu vytvřeny z balíčků AIP ulžených ve spisvně, přičemž jsu předávána puze metadata pžadvaná Nárdním archivem a příslušný digitální bsah. Knkrétní rzhraní a pravidla pr předávání nejsu v sučasné dbě stanvena. Systém KDS by měl umžnit i následnu dluhdbu archivaci pr ptřeby půvdce u vybraných skupin digitálních dkumentů, které byly již předány d NDA neb skartvány. Na rzdíl d analgvých dkumentů je v případě digitálních dkumentů z principu mžné uchvávat více instancí riginálníh dkumentu. Pr pdpru práce s digitálními i analgvými dkumenty musí KDS minimálně zajistit: příjem d spisvny (ve frmě SIP balíčku bsahujícím puze metadata dkumentu/spisu) evidenci ve spisvně, minimálně v rzsahu: základní metadata (zejména pr vyhledávání ve spisvně) + všechna metadata ulžená splu s dkumentem/spisem předaná d spisvny (dle vyhlášky č. 259/2012 Sb., metadata dle nárdníh standardu) přiřazení k věcné skupině pdle spisvéh plánu přirazení skartačníh režimu (skartační znak, skartační lhůta) míst ulžení (slvní neb číselníkvé určení místa fyzickéh ulžení) další pvinná či vlitelná metadata pdle specifikace zadavatele skartační řízení infrmvání uplynutí skartačních lhůt zařazení d skartačníh návrhu sestavení seznamu balíčků dkumentů/spisů k vyřazení (splu s digitálními) pdle skartačních perací S neb A, vyřešení perací V záznam prvedení skartačníh řízení Funkce skartačníh řízení zbrazení všech dkumentů, kterým uplynula skartační lhůta, zařazení d skartačníh řízení, kntrla knfliktů (hledání a řešení knfli ktu skartačních režimů, vyřazvání částí spisů neb suvisejících spisů/dkumentů) sestavení a úprava skartačníh návrhu kntrla a schválení skartačníh návrhu sestavení seznamu balíčků dkumentů/spisů k vyřazení (splu s digitálními) pdle skartačních perací S neb A na základě schválení skartačníh návrhu prvedení vyřazení: přens d nárdníh archivu exprt d pžadvané struktury digitálníh archivu, p ptvrzeném přensu může nastat zničení dkumentů a některých metadat. skartace - zničení dkumentů a některých metadat, pnechání základních údajů dkumentu a údajů skartaci.

13 prcesní řešení skartačníh řízení části balíčku (mžnst umístění více spisů s různými skartačními značkami v jednm AIP balíčku) záznam prvedení skartačníh řízení Přístup k bsahu spisvny Základním cílem tét funkční části je zpřístupnění ulžených elektrnických dkumentů puze právněným uživatelům. Přístup k datům v KDS by měl být mžný prstřednictvím uživatelskéh rzhraní, které bude umžňvat vyhledávání pdle evidvaných metadat a výdej bsahu ve frmě balíčků DIP (Disseminatin Infrmatin Package). Také by měl být umžněn asistvané znázrnění dkumentu. Vedle uživatelskéh rzhraní by měl být umžněn přístup i prstřednictvím ppsanéh aplikačníh rzhraní pr zpřístupnění externími aplikacemi, například systémy ESSL, neb prtálvými systémy. Každý přístup k ulženému balíčku právněnými uživateli půvdce i v případě nahlížení d spisu bude zaznamenán a trvale evidván. Přístup k dkumentům ulženým v KDS musí být mezen puze na právněné uživatele na základě klasifikace dkumentu a uživatelské rle. U vybraných typů dkumentů může být vyžadván i schválení zpřístupnění balíčku právněným uživatelem. Přístup k bsahu spisvny musí být v suladu s následujícími pžadavky Mžnst pužití případnéh stávajícíh systému DMS/ECM neb stávajícíh prtálu pr přístup k dkumentům nezávisle na SW KDS. Prgramvé rzhraní API pr přístup k dkumentům Vyhledání ulžených balíčků na základě zvlených metadat. Mžnst vyžádání a schvalvání výdeje balíčků DIP, evidence výdeje balíčků DIP Pstupení ulžených dkumentů ve frmě DIP, systém umžní výběr dkumentů a jejich zaslání právněnému uživateli ve standardizvané pdbě. Zabezpečení přístupu a autentizace uživatelů. Zajištění přístupu uživatelů k ulženým metadatům a dkumentům Pdpůrné nástrje Dále jsu uvedeny nástrje, jejichž ddání je v rámci plnění pžadván. Nástrje musí být mžné pužít samstatně, dděleně d zbytku řešení. Musí být však se zbytkem řešení prpjené v míře, nezbytné pr zajištění funkcinality celéh řešení Pracvní úlžiště Sučástí pptávanéh řešení bude zřízení pracvníh úlžiště, které umžní jedntlivým půvdcům pracvní ulžení a přípravu dat, následně určených k dluhdbému ulžení. Pracvní úlžiště bude kncipván tak, aby byl případně využitelné i samstatně pr krátkdbé či střednědbé bezpečné ulžení nestrukturvaných záznamů, bez vazby na dluhdbé úlžiště. U pracvníh úlžiště se nepředpkládá fungvání dl e principů OAIS. Funkční pžadavky Pracvní úlžiště bude služit k přímému, rychlému ukládání dat vybraných kategrií p dhdě s jejich půvdci. Data budu ukládána přím ve frmě subrů. Subry nebudu pvinně bsahvat ppisná

14 metadata v jedntně stanveném frmátu. Pracvní úlžiště musí zajistit splehlivé ulžení, zálhvání a případnu aplikaci základních retenčních plitik. V pracvním úlžišti musí být mžné jednduchým způsbem zakládat a spravvat ddělená lgická úlžiště pr jedntlivé půvdce s vlastním řízením přístupvých práv. Není nutné, aby pracvní úlžiště nabízel funkcinalitu nad rámec běžnéh subrvéh systému (NFS, CIFS, FTP aj.) puze se základním řízením uživatelských právnění na úrvni každéh lgickéh úlžiště. Nemezená licence Je pžadvána nemezená licence pr jednu instalaci pracvníh úlžiště, umžňující nemezený pč et půvdců (lgických úlžišť), nemezený pčet ulžených bjektů, nemezený pčet uživatelů s plným přístupem a bez licenčníh mezení kapacity celéh úlžiště Implementace Prvním krkem implementace bude zpracvání prváděcíh prjektu v nezbytně nutném rzsahu. Schválený prváděcí prjekt bude služit jak zadání pr vlastní implementaci, ppíše technické, rganizační a prcesní ptřeby a dpady a stanví přesný harmngram implementace. Sučástí implementace bude ddávka testvacíh a šklicíh prstředí, které bude živen jak první. Následně prběhne implementace vlastníh řešení d prstředí Technlgickéh centra Plzeňskéh kraje a jeh pstupné živení. P celu dbu platnsti smluvy technické pdpře zajistí ddavatel technicku pdpru nástrje. Sučástí implementace bude šklení správy pracvníh úlžiště pr administrátry (dvě skupiny, každá d pčtu 15 sb v rzsahu 1 den). Sučástí implementace je zpracvání kmpletní prvzní a bezpečnstní dkumentace, včetně ppisu pravidelné údržby řešení, havarijních plánů a plánu bnvy. Zhtvitel pskytne sučinnst při aktualizaci infrmační kncepce, vnitřních směrnic úřadu a jiných intern ích dkumentů, na které má implementace řešení vliv. Před přechdem na prduktivní prvz bude předána dkumentace finálníh vyhtvení včetně pdrbnéh ppisu všech rzhraní v takvé úrvni detailu, která umžní případnu buducí integraci řešení bez nutné sučinnst ddavatele. Zhtvitel zpracuje v rámci tét části plnění návrh smluvy s dběrateli služeb KDÚ včetně prvzních pdmínek a SLA Samstatný nástrj pr knverzi datvých frmátů d PDF/A Je pžadván samstatný nástrj, běžící na serveru za davatele, který bude služit pr autmatizaci tvrby a skládání PDF subrů. Nástrj bude přes aplikační rzhraní (API) nabízet jiným infrmačním systémům službu knverze subrů z frmátů jejich půvdních aplikací resp. z uznávaných standardních frmátů d krektníh frmátu řady PDF/A. Nezbytnu pdmínku je plně krektní výstupní frmát PDF/A v suladu se standardem ISO. Nástrj bude pskytvat služby dluhdbému úlžišti a d buducna ptenciálně i dalším infrmačním systémům zadavatele.

15 Nástrj musí být schpen převést minimálně tyt vstupní frmáty dkumentů: Micrsft Office 2000+, frmáty) Micrsft Visi 2003, 2007 (VSD) Micrsft Prject 2003, 2007 (MPP) OpenOffice 2.0+ (ODT, ODS, DOP, ODG, ODF) Webvé subry (HTML) Obrazvé frmáty (JPEG, GIF, BMP, TIFF, PNG) (DOC, XLS, PPT,WPD, MPP, RTF, TXT, Micrsft Office Open XML PDF 1.3 až 1.7, PDF/A, PDF/X včetně skenvaných bez textvé slžky Nástrj musí d výstupníh subru autmaticky vkládat ptřebné typy písma a být schpen získat strukturvané infrmace (např. značky přístupnsti ) z půvdních aplikací, služící k vytváření PDF/A-1a subrů. Prces knverze musí využívat technlgii ptickéh rzpznávání znaků (OCR) v případě tak, aby výsledný PDF/A dkument zachval stejný vzhled jak riginál, ale na rzdíl d něj bsahval text (značvané jak text ver image PDF neb searchable PDF ). Pužitá OCR funkcinalita musí být schpna bez prblémů zpracvat české texty s diakritiku. Ddaná licence musí plně pkrývat prstředí, na kterém bude nástrj prvzván (předpkládá se jeden vyhrazený virtuální server v prstředí, ppsaném dále v tmt dkumentu). Zadavatel pžaduje licenci bez mezení pčtu knvertvaných dkumentů a bez mezení uživatelů. D pdpry ddávanéh řešení uchazeč zahrne i práv na pdpru a na nvé verze tht nástrje. Sučástí implementace bude šklení správy nástrje pr administrátry (jedna skupina cca 5 sb v rzsahu 1 den) Tvrba SIP balíčků Pr případ, kdy bude d dluhdbéh úlžiště nutné ulžit bsah, který není předáván autmaticky prstřednictvím vstupníh rzhraní z jiné integrvané aplikace, bude ddán nástrj, který zajistí manuální vytváření vstupních SIP balíčků. Tent nástrj vytvří vstupní balíček SIP, zahrne d něj připravené subry (kmpnenty) a umžní zadat ppisná metadata. Přitm budu využívány číselníky evidvané v dluhdbém úlžišti, cž usnadní přípravu validních metadat. Stejně jak v případě předávání d dluhdbéh úlžiště prstřednictvím aplikačníh rzhraní budu balíčky při vstupu autmaticky kntrlvány. Licenčně nebude nástrj jakkli mezen, bude jej mci nemezeně využívat jakýkli subjekt, který užívá dluhdbé úlžiště neb tt užívání zvažuje, a t bezplatně. Pdpra dluhdbéh úlžiště se vztahuje i na tent nástrj. Sučástí implementace bude šklení správy nástrje pr administrátry (jedna skupina cca 5 sb v rzsahu 0,5 dne).

16 1.6 Technická specifikace řešení Dluhdbé úlžiště Dluhdbé úlžiště, zalžené na principech OAIS, přistupuje k ukládaným dkumentům a spisům jak k balíčkům, bsahujícím předmětná data a sučasně jejich metadata za účelem dluhdbéh a důvěryhdnéh ulžení. Pdle fáze jejich živtníh cyklu se jedná vstupní (SIP), archivní (AIP) a výstupní (DIP) balíčky. Rzhraní pr přístup k těmt systémům je specificky navržen pr příjem a výdej balíčků v příslušném frmátu definvaném na základě standardů. Vzhledem k zajištění bezpečnsti a knzistence ulžených dat prbíhá příjem dat d úlžiště asynchrnně v rámci prcesu, který se skládá z něklika kntrlních a transfrmačních prcedur Architektura řešení Pptávané řešení dluhdbéh úlžiště musí být pstavené jak minimálně třívrstvé, s jasně ddělenu částí ukládání dat d aplikační lgiky. Pr prvzní strukturvaná data bude využita relační databáze (RDBMS). Zadavatel nabízí k dispzici využití MS SQL Server 2012 Enterprise Editin a předpkládá jeh využití. V případě, že řešení uchazeče bude vyžadvat RDBMS jinéh výrbce, je uchazeč d nabídky pvinen zahrnut licence tht RDBMS ve srvnatelné edici a rzsahu, včetně pdpry a maintenance a zajistit pršklení 3 pracvníků zadavatele v rzsahu 2 dní. Vlastní ukládaný bsah (AIP balíčky) bude ulžen ve vyhrazeném úlžišti NAS (TIER2 neb TIER3 Technlgickéh centra kraje) neb CAS, pr každé lgické úlžiště v ddělené struktuře. Rzhdnutí pužití úlžiště NAS/CAS bude nastavitelné na úrvni každéh lgickéh úlžiště minimálně v těcht variantách: Využití puze úlžiště NAS pr veškerý bsah Využití puze úlžiště CAS Využití úlžiště NAS pr AIP balíčky a úlžiště CAS pr vybrané bezpečnstní infrmace (hashe, časvá razítka, auditní lgy) Veškerá integrační rzhraní a realizvané vazby budu detailně ppsány. Zadavatel pžaduje, aby integrační vazby byly realizvány prtklem WS/SOAP, pkud tmu nebudu bránit vážné důvdy mim vliv ddavatele. Sučástí ddávky bude detailní ppis struktury ukládaných dat tak, aby byl mžné v případě nuze przumět datvému bsahu a přenést jej d jinéh typu úlžiště i v případě, kdy aplikační část řešení nebude funkční. Řešení musí umžnit bezpečnstní klasifikaci dat a řízení bezpečnsti na základě tét klasifikace. U veškerých změn v ukládaném bsahu musí být mžné držet histrii. Sučástí ddávky budu havarijní plány, ppisující minimálně prcesy: Zálhy Obnvy ze zálhy Pstupu v případě havárie Migrace úlžiště na jiný hardware (při zachvání stávajícíh typu úlžiště) Nuzvý hrmadný exprt dat pr přens d jinéh typu úlžiště

17 Kmpnenty dluhdbéh úlžiště Systém digitální spisvny, implementvaný nad dluhdbým úlžištěm, se musí skládat z těcht sftwarvých kmpnent, které musí splečně splňvat výše uvedené funkční pžadavky: Vstupní mdul Příjem dat Zajišťuje kmunikaci s půvdcem, autentizaci, autrizaci a ulžení přijatých balíčků SIP d pracvníh úlžiště. Kntrla kvality vstupních dat (kntrla datvé struktury, kntrla na bsah škdlivéh kódu) Kntrluje frmální strukturu balíčků a přítmnst virů a jinéh škdlivéh bsahu balíčků. V rámci tht mdulu je zřízena i tzv. karanténní zóna pr zajištění splehlivsti kntrl. Řízení příjmu Kntrla ppisných a technických metadat, kntrla přípustnsti subrvých frmátů a jejich vnitřní validity, kntrla struktury balíčku SIP a vzájemnéh prvázání balíčků. Genervání balíčků AIP Autmatické dplnění zejména technických metadat, knverze frmátů metadat, mžnst manuálníh dplnění metadat, vstupní migrace frmátů včetně genervání náhledů pr prezentaci dat archivu v určeném frmátu. Řízení ukládání Zajišťuje knzistentní ulžení metadat a bsahu archivních balíčků sučasně d archivníh systému, systému správy dat a systému pr přístup bezpečným a prkazatelným způsbem v suladu s Nárdním standardem elektrnických spisvých služeb. Mdul správy dat Evidence číselníků Zajišťuje ukládání a přístup k číselníkům pužívaným v rámci vstupní kntrly a vyhledávání. Jedná se zejména tyt číselníky - půvdci, klasifikace, pvlené subrvé frmáty, spisvé plány jedntlivých půvdců, kategrizace dkumentů pdle kritérií přístupnsti, pžadavků na zachvání důvěryhdnsti, dby ulžení. Evidence přijímaných a ulžených balíčků. Zajišťuje vedení a přístup ke katalgu ulžených dkumentů včetně stavu příjmu a ulžení. Evidence kntrly knzistence. Ulžení kntrlních sučtů jedntlivých ulžených balíčků AIP na aplikační úrvni pr účely peridické kntrly knzistence ulženéh bsahu nezávisle na vlastnstech pužitéh archivníh úlžiště. Evidence prcesů skartace a archivace. Infrmace stavu skartace a infrmace stavu jedntlivých balíčků AIP zařazených d skartačníh řízení. Archivní systém Bezpečné ulžení Zajišťuje vlastní bezpečné ulžení bsahu balíčků AIP d zvlenéh úlžiště NAS/CAS Mdul administrace Řízení prcesu příjmu

18 Pr administrátra zajišťuje přehled stavu příjmu balíčků SIP, umžňuje řešení prblémů se strukturu a bsahem balíčků při příjmu. Řízení prcesů migrace Spuštění migrace subrvých frmátů v ulžených balíčcích a přehled prvedených migracích. Skartační řízení Příprava návrhu a jeh schvalvání, prvedení skartace, případně exprtu d Nárdníh digitálníh archivu (případně d jinéh dluhdbéh úlžiště) v definvaném frmátu. Správa kntrly knzistence Přehled průběhu věřvání kntrlních sučtů a nalezených prblémech s ulžením balíčků AIP. Správa číselníků Zajišťuje pr administrátry půvdce a archivu aktualizaci a čtení číselníků pužívaných v rámci vstupní kntrly a vyhledávání. Ukládání transakčních záznamů. Pr účely auditu zaznamenává veškeré prvedené perace nad ulženými balíčky (příjem, kntrla, transfrmace, ukládání, čtení). Ulžené záznamy jsu zárveň ukládány d úlžiště ve frmě AIP. Přístup k transakčním záznamům Zbrazení transakčních záznamů pr účely auditu v suladu s pžadavky na lgvání viz dále. Přístupvý mdul Zabezpe čení přístupu a autentizace uživatelů. Zajištění přístupu uživatelů k ulženým metadatům a dkumentům. Identifikace a autentizace uživatelů bude realizvána prti řešení SSO Plzeňskéh kraje. Identifikace uživatelů a jejich zařazení k rganizaci (půvdci) bude přebírána z řešení epusa. Autrizace - mezení přístupů na základě klasifikace dkumentu, půvdce, uživatelských skupin a rlí uživatelů. Základní právnění (minimálně přístup an/ne) bude přebírán z rle v systému epusa, jemnější členění právnění bude řešení udržvat samstatně. Mdul pvlí přístup ke čtení bsahu neb metadat pdle rlí přihlášenéh uživatele a právnění příslušnéh balíčku. Vyhledání ulžených balíčků na základě zvlených metadat. Uživatel bude mít mžnst vyhledávat nad metadaty zvlenéh lgickéh úlžiště v rámci svých uživatelských právnění. Pstupení ulžených dkumentů ve frmě DIP výběr dkumentů a jejich zaslání právněnému uživateli ve standardizvané pdbě Prvádění transakčních záznamů přístupu k jedntlivým ulženým balíčkům Systém eviduje veškeré přístupy k ulženým dkumentům a archivuje je. Prgramvé rzhraní API na externí prtál pr přístup V případě, že bude nasazen externí prtálvé řešení, umžňující publikaci vybranéh bsahu, bude tt rzhraní pužit pr jeh přístup d úlžiště Otevřené rzhraní vůči dalším systémům Rzhraní pr přístup k KDS musí být specificky navržen pr příjem a výdej balíčků v příslušném frmátu definvaném na základě standardů. Vzhledem k zajištění bezpečnsti a knzistence ulžených dat prbíhá příjem dat d úlžiště asynchrnně v rámci prcesu, který se skládá z něklika kntrlních a transfrmačních prcedur. Operace vstupníh rzhraní minimálně zajistí:

19 Přens balíčků SIP d spisvny Pskytvání infrmací stavu zpracvání přijatých balíčků Pskytvání infrmací stavu ulžených balíčků Pskytvání bsahu číselníků pužitých při validaci vstupních dat a správě spisvny Vstup na fyzickém (dneseném) médiu Nástrj na přípravu frmálních balíčku (viz dále). Operace výstupníh rzhraní minimálně zajistí: Integrace Výdej bsahu ze spisvny (balíčky DIP) Pskytvání infrmací stavu žádsti výdej Pskytvání infrmací prběhlých skartačních řízeních Pskytvání infrmací skartaci a archivaci dkumentů Otevřené rzhraní pr vstup dkumentů a jejich metadat pdle specifikace XML frmátu NSESSS pr předávání dkumentů a jejich metadat d archivu Kmunikace na vstupu pstavená na Web Services Výstup dat (archiválií) d Nárdníh digitálníh archivu pdle specifikace Nárdníh archivu Aplikace pr manuální vytváření vstupních SIP balíčků Integrační rzhraní vůči elektrnickým spisvým službám, dstupným na trhu Nástrje Pracvní úlžiště Pracvní úlžiště bude vybudván jak úlžiště se základní funkcinalitu, nabízející běžné základní služby subrvéh systému (FS). Typicky budu data ulžena na vrstvě úlžiště TIER2 neb TIER3. Pžadavky na pracvní úlžiště Bezpečnst z phledu dstupnsti, důvěrnsti a integrity ulžených dkumentů Evidence typů ukládaných dat v katalgu pracvníh úlžiště Organizace dkumentů/dat d adresářů či slžek; Práce s dkumenty pmcí více rzhraní (HTTP/S, S/FTP, CIFS, NFS) Mžnst umístění celéh lgickéh úlžiště na TIER2, TIER3 neb CAS Pdpra standardizvaných a tevřených typů filesystémů Pdpra imprtu většíh mnžství subrů, exprtu a migrace dat na jiný HW Integrace funkcinality autentizace uživatelů s řešením SSO Plzeňskéh kraje Centrální administrace úlžiště přím z katalgu lgických úlžišť (lgická úlžiště, bjemvé kvóty, autnmní správa uživatelů) Mžnst namapvání úlžiště neb jeh části jak lgickéh disku v MS Windws na pčítači uživatele (např. CIFS) Nepvinná funkcinalita pracvníh úlžiště Tat funkcinalita není pvinnu sučástí řešení (řešení bude tímt směrem v buducnu rzvíjen): Plná pdpra technik ILM a HSM pr ukládání dat

20 Pdpra elektrnických pdpisů a časvých razítek Zaznamenávání histrie práce s dkumenty pr účely auditu; Řízení uživatelských přístupvých právnění na úrvni celéh lgickéh úlžiště; Vnitřní členění lgických úlžišť Pracvní úlžiště bude rzdělen na jedntlivé lgické segmenty. Tyt lgické segmenty (lgická úlžiště) budu definvány v katalgu pracvníh úlžiště a na jejich základě bude vytvřena lgická struktura úlžiště. Pr každý segment bude definván typ ukládaných dat, frmát datvých subrů, ukládací plitika, půvdce datvých subrů a přístupvá pravidla. Segment bude samstatně upravvatelný z phledu místa ulžení a z phledu řízení přístupvých práv. V katalgu budu evidvány jedntlivé lgické segmenty úlžiště s těmit parametry: Název lgickéh segmentu a textvý ppis významu ulžených dat Půvdce dat v lgickém segmentu, jeh kntaktní sby Typy ukládaných dat a frmáty datvých subrů v rámci lgickéh segmentu Přístupvé prtkly Pravidla řízení živtnsti dat v lgickém segmentu Pravidla ukládacích plitik pžadvanéh způsbu ulžení s hledem na rychlst přístupu (má vliv na knfiguraci HSM). Definice skupin uživatelů právněných k přístupu k subrům danéh lgickéh segmentu. Pdrbný ppis subrvých frmátů (dkumentace, standard), kd standard vydal a udržuje, kd jiný standard ještě pužívá. Předpisy/nrmy pdle kterých je třeba zajistit bezpečnst dat (sbní data, data chráněná autrským záknem) v jedntlivých lgických segmentech. Pravidla způsbu kryptvání, peridicita bměny kryptvacích klíčů, dstupnst a způsb zajištění dstupnsti klíčů pr vybrané lgické segmenty úlžiště. Katalg musí umžňvat přidávat, měnit a debírat parametry administrátrem. Změny záznamů v katalgu musí být verzvané, aby byl dhledatelný stav záznamů k určenému datu. Data katalgu musí být ulžena d databáze neb jiným způsbem, který umžní jejich jednduché zálhvání. Katalg musí umžňvat exprty a tiskvé výstupy v nezbytném rzsahu. Přístup d katalgu musí být umžněn jen právněným, Zajištění přístupu uživatelů k ulženým metadatům a dkumentům (dle předem definvaných rlí v Identity management, pdpra SSO včetně přidělení právnění dle členství ve skupinách) s mžnstí nastavení práv minimálně na úrvni nic/čtení/změna/admin všech záznamů katalgu Knverze datvých frmátů PDF/A Nástrj bude fungvat jak centrální servervé řešení, které bude pužité pr knverzi subrů z běžně pužívaných jiných frmátů d frmátu PDF/A. Kmunikvat s dalšími infrmačními systémy bude prstřednictvím plně zdkumentvanéh rzhraní (API), pstavenéh na běžně pužívaných technlgiích, které umžní kntrlu těcht infrmačních systémů nad prcesem knverze. Pr knverzi z datvých frmátů aplikací třetích stran se předpkládá instalace těcht aplikací na server, na kterém bude nástrj prvzván, nástrj je bude využívat pr převd. Licence aplikací třetích stran zajistí zadavatel, nejsu předmětem pptávky.