INFORMAČNÁ BEZPEČNOSŤ 9

Prezentácia na tému: "INFORMAČNÁ BEZPEČNOSŤ 9"— Prepis prezentácie:

1 INFORMAČNÁ BEZPEČNOSŤ 9
RNDr. Eva KOSTRECOVÁ, PhD.

2 VÝVOJ, IMPLEMENTÁCIA A ÚDRŽBA SYSTÉMOV
Obsah prednášky: Bezpečnostné požiadavky na informačný systém Bezpečnosť v aplikačných programových systémoch Kryptografické opatrenia Bezpečnosť systémových súborov Bezpečnosť vo vývoji a podporných procesoch

3 ÚVOD Jedným zo základných cieľov informačnej bezpečnosti je zabudovanie ochrany a zaistenie bezpečnosti informácií do samotného informačného systému. Chrániť dôvernosť, integritu, dostupnosť a autenticitu údajov a informácií nachádzajúcich sa v operačných systémoch, databázach alebo v aplikačných programových systémoch by malo byť prvoradým a kľúčovým záujmom každej spoločnosti.

4 VÝVOJ A NÁKUP SYSTÉMOV A TECHNOLÓGIÍ
Pri vývoji a nákupe systémov a technológií by mala byť zabezpečená ich kompatibilita s implementovanými alebo pripravovanými bezpečnostnými opatreniami. Vývoj, rozširovanie alebo významné zmeny systémov alebo technológií by mali byť vykonávané v zhode so schválenou metodikou vývoja. Vyvíjané a nakupované systémy a technológie: musia vyhovovať požiadavkám riadiacich dokumentov bezpečnostnej politiky, mali by byť byť nasadené do prevádzky až po úspešnom absolvovaní akceptačných testov, vydaní stanoviska špecialistu pre bezpečnosť o splnení bezpečnostných cieľov, formálnom akceptovaní používateľmi a podpísaní protokolu o odovzdaní do rutinnej prevádzky, musí byť zabezpečená dostupnosť systémovej, prevádzkovej a používateľskej dokumentácia.

5 BEZPEČNOSTNÉ POŽIADAVKY A ŠTANDARDY PRE VÝVOJ A ZMENY SYSTÉMU
Formulovanie bezpečnostných požiadaviek na nové systémy alebo vylepšenia existujúcich informačných systémov by malo byť v súlade so štandardami prijatými v riadiacich dokumentoch bezpečnostnej politiky spoločnosti. Štandardy pre vývoj systémov slúžia na zníženie výskytu chýb v systéme a na formalizáciu vývojového procesu. Vývoj by mal prebiehať v súlade so schválenými metodickými, technickými, technologickými a kvalitatívnymi požiadavkami. Dôležitým atribútom vývoja je kontrola kvality, ktorú by mal vykonávať pracovník spoločnosti nezávislý od vývojového tímu.

6 BEZPEČNOSTNÉ POŽIADAVKY NA TECHNOLOGICKÚ ZHODU
Pri návrhu technického riešenia a výbere technológie je potrebné okrem požiadaviek prevádzkového a technického charakteru zohľadniť aj požiadavky bezpečnostného charakteru: požiadavky na dostupnosť systémov - napríklad zabezpečenie trvalej prevádzky, záručný a pozáručný servis, redundantnosť systému a jeho častí, vzdialený dohľad a manažment, požiadavky na zabezpečenie integrity systémov a kompaktné riešenie dodávaného systému, požiadavky na kontrolné mechanizmy a registráciu systémových záznamov, požiadavky na dôvernosť technických špecifikácií systému a na ochranu konfiguračných a prevádzkových údajov zo systému.

7 PROJEKTOVÉ RIADENIE VÝVOJA
Vývoj a úpravy softvérových aplikácií sa obvykle v spoločnostiach riadia formou projektu. V dokumentácii projektu musia byť presne špecifikované procedúry a zodpovednosti týkajúce sa údajov, vývoja, modifikácie a schválenia vyvinutého produktu, uskladnenia, distribúcie, údržby a riadenia jednotlivých prvkov konfigurácie. Osoby zúčastnené na projekte, ich zodpovednosti a funkčné vzťahy musia byť popísané v plánoch riadenia projektu. Činnosti zabezpečujúce kvalitu vývoja musia garantovať, že bezpečnostné požiadavky týkajúce sa produktu a procesu vývoja sú zhodné s definovanými cieľmi. Manažér projektu by mal zodpovedať za: návrh pravidiel prístupu k údajom na každej úrovni organizácie projektu, výber životného cyklu koncepčných a vývojových metód, návrh prostredia potrebného pre koncepciu a vývoj - vývojové prostredie, testovacie prostredie, prevádzkové prostredie,

8 PROJEKTOVÉ RIADENIE VÝVOJA /2
popis všeobecnej štruktúry databáz, noriem pre integritu a dôvernosť, popis bezpečnostného rozhrania aplikácie, popis bezpečnostných služieb – elektronický podpis, šifrovanie, správu modifikácií a toku údajov, riadenie spracovaní, riadenie chybových správ, vypracovanie procedúry opätovného reštartu a iných prevádzkových procedúr, špecifikáciu školení používateľov a správcov systému, špecifikáciu podpory a údržby, návrh procedúr, technických špecifikácií a pravidiel pre administráciu a používanie identifikačných prostriedkov a riadenie prístupových práv používateľov a správcov systému, návrh pravidiel a procedúr pre zálohovanie systému, údajov a jeho konfigurácie.

9 BEZPEČNOSTNÁ KAPITOLA
Pri definovaní projektu na vývoj alebo úpravu softvérovej aplikácie by mali byť špecifikované základné bezpečnostné požiadavky tak na jeho priebeh, ako aj na výsledný produkt. Počas fázy špecifikácie systému musia byť bezpečnostné požiadavky špecifikované v dokumente Bezpečnostná kapitola. Bezpečnostná kapitola musí obsahovať: analýzu rizík a návrh na riadenie zistených rizík - ich riadenie, prenesenie, alebo akceptovanie, návrh bezpečnostných opatrení pre všetky identifikované prostredia v súlade s Bezpečnostnou architektúrou spoločnosti a s použitím bezpečnostných mechanizmov stanovených v zmysle Bezpečnostnej architektúry spoločnosti,

10 BEZPEČNOSTNÁ KAPITOLA /2
návrh požadovaných výnimiek - garant softvérovej aplikácie sa môže rozhodnúť aplikovať slabšie bezpečnostné opatrenia alebo vynechať navrhované bezpečnostné opatrenia s tým, že akceptuje bezpečnostné riziko a ponesie zaň plnú zodpovednosť. Výnimky by mal schváliť špecialista pre bezpečnosť, návrh procedurálnych opatrení v súlade s Manuálom bezpečnosti spoločnosti, zoznam nepokrytých rizík, určenie garanta softvérovej aplikácie, návrh na registráciu systému u príslušného orgánu štátnej správy a vypracovanie bezpečnostného projektu, ak sa pri prevádzke aplikácie budú spracovávať osobné údaje. Garant softvérovej aplikácie zodpovedá aj za prenesenie bezpečnostných požiadaviek a formulácií do zmlúv s dodávateľmi a za formuláciu stratégie obnovy a vypracovanie plánov kontinuity funkcií.

11 BEZPEČNOSTNÁ KAPITOLA /3
Po schválení by mali byť časti bezpečnostnej kapitoly rozpracované do technických špecifikácií a procedúr. V procedúrach a technických špecifikáciách by mali byť rozpracované nasledujúce činnosti: klasifikácia údajov a spôsoby manipulácie s nimi, vrátane médií a papierovej dokumentácie, definovanie používateľských skupín, oprávnení a používateľských profilov, definovanie zodpovedností v oblasti bezpečnosti a administrácie prístupových práv používateľov, konfigurácia operačných systémov, softvéru a aplikácií, špecifikácia prevádzky v záložnom režime. Bezpečnostné požiadavky na projekt by mali byť, rovnako ako ostatné požiadavky na projekt, v ďalších fázach projektu naprogramované, integrované, testované, inštalované, akceptované, verifikované a auditované.

12 KONTROLA TOKU ÚDAJOV Pri vývoji je potrebné zakomponovať do softvérových aplikácií programové kontroly pri vstupe, spracovaní a výstupe údajov. Vo vyvíjaných aplikáciách by mali byť v priebehu definovania koncepcie projektu navrhnuté vhodné programové kontroly na kontrolu platnosti vstupných a výstupných údajov, interného spracovania a prostriedky na vytváranie auditných záznamov. Počas špecifikácie projektu je potrebné zostaviť plány testov. Programové kontroly musia byť prispôsobené klasifikácii údajov, ktoré sú aplikáciou spracovávané. Dôležité kontroly by mali byť umiestnené v samostatných moduloch, ktoré budú pred uvedením do prevádzky otestované a chránené pred neautorizovaným prístupom. Návrh kontrol by mal byť zrealizovaný v súlade so stanovenými bezpečnostnými požiadavkami a na základe výsledkov rizikovej analýzy daného systému.

13 KONTROLA VSTUPNÝCH ÚDAJOV
Údaje by mali byť pri vstupne do aplikácie skontrolované pomocou programových kontrol zameraných na: zlú postupnosť údajov – vstupné údaje musia nasledovať v postupnosti a všetky hodnoty mimo postupnosti alebo duplicitné hodnoty musia byť odmietnuté, hodnoty mimo povoleného rozsahu, hodnoty nad alebo pod povolený limit – vstupné údaje budú vyžadovať dodatočnú autorizáciu, chybné znaky v údajových položkách – údaje musia spĺňať preddefinované kritériá, chýbajúce alebo nekompletné údaje, neautorizované alebo nekonzistentné údaje, pravidelnú kontrolu obsahu kľúčových alebo údajových položiek a potvrdenie ich platnosti a integrity, kontrolu, či v papierových vstupných dokumentoch neboli vykonané neautorizované zmeny.

14 KONTROLA VSTUPNÝCH ÚDAJOV /2
Predmetom procedúr pre spracovanie chýb pri kontrole platnosti a správnosti údajov by malo byť: odmietnutie iba transakcií obsahujúcich chyby, odmietnutie celej dávky, v ktorej sa chybná transakcia nachádzala, akceptovanie dávky, jej dočasné pozastavenie a oprava chýb, akceptovanie dávky a označenie chybných transakcií, definovanie zodpovedností všetkých zamestnancov, ktorí sa podieľajú na procese vstupu údajov. V prípadoch, keď je integrita transakcie a identifikácia jej odosielateľa kritická, je potrebné zvážiť kontroly pôvodu - autentizácia, certifikácia, nepopierateľnosť autorstva a zaviesť kontroly prenosov súborov - kontrolovanie dátumu a hodiny prenesených údajov, priemernej dĺžky trvania prenosu.

15 KONTROLA SPRACOVANIA Údaje, ktoré boli do aplikácie správne vložené môžu byť poškodené chybou spracovania alebo zámerne. Takýmto narušeniam sa dá predchádzať kontrolami platnosti údajov, ktoré sú zapracované priamo v aplikácii. Počas návrhu aplikácie musí byť zabezpečená implementácia takých obmedzení, ktoré minimalizujú možnosť chýb vedúcich k strate integrity údajov. Požadované kontroly závisia od typu aplikácie a dopadov, ktoré môžu vzniknúť pri chybnom spracovaní. Doporučuje sa vykonať nasledujúce kontroly spracovania: kontroly dávok alebo relácií na zosúladenie zostatkov údajových súborov po aktualizácii transakcií, porovnanie výstupných a nasledujúcich vstupných zostatkov spracovateľských procesov,

16 KONTROLA SPRACOVANIA /2
kontrola platnosti údajov vygenerovaných systémom, kontrola integrity údajov alebo softvéru prenášaného medzi servermi alebo vzdialenými počítačmi, hash kódy záznamov alebo súborov, kontroly, že aplikačné procesy bežia v správnom čase, kontroly, ktoré zabezpečia, že procesy bežia v správnom poradí, ukončia sa v prípade chyby a ďalšie spracovanie je pozastavené, až kým problém nie je vyriešený.

17 KONTROLA VÝSTUPNÝCH ÚDAJOV
Proces výstupu údajov z aplikácií zahŕňa tlač, prenos údajov do iných aplikácií alebo procesov, čítanie a export údajov používateľmi. Kontrola údajov vystupujúcich z aplikácií má za cieľ overiť, že spracovanie prebehlo v poriadku. Aplikácie sú založené na predpoklade, že ak sa vykoná vhodná kontrola platnosti, testovanie a overenie údajov, výstupné údaje sú vždy v poriadku. Kontrola výstupných údajov môže pozostávať z nasledujúcich aktivít: kontrola počtu položiek, pomocou ktorej sa overí, že všetky údaje boli spracované, poskytnutie dostatočných informácii príjemcovi údajov, aby mohol na ich základe určiť ich správnosť, kompletnosť, presnosť a klasifikáciu, vytvorenie procedúr popisujúcich reakciu na chyby pri testovaní platnosti výstupných údajov,

18 KONTROLA VÝSTUPNÝCH ÚDAJOV /2
definovanie zodpovedností všetkých zamestnancov, ktorí sa zúčastňujú na procese výstupu údajov, uloženie všetkých citlivých alebo kritických tlačív a formulárov na bezpečnom mieste, citlivé výstupy, formuláre alebo podpisy generované výpočtovou technikou musia byť kontrolované, distribúcia výstupných správ musí byť kontrolovaná, pokiaľ sa výstupné dokumenty distribuujú elektronicky, je nevyhnutné zabezpečiť riadenie logického prístupu k nim, doba uchovávania výstupných dokumentov musí zodpovedať platným legislatívnym úpravám, v prípade citlivých údajov, musí príjemca potvrdiť ich prijatie.

19 ODDELENIE VÝVOJOVÉHO, TESTOVACIEHO A PRODUKČNÉHO PROSTREDIA
Je potrebné zabrániť narušeniu prevádzkového prostredia softvérovej aplikácie v dôsledku neoverených a neautorizovaných činností, ktoré môžu vzniknúť pri vývoji a zmenách aplikácie alebo systému a vytvoriť oddelené prostredia pre vývoj, testovanie a prevádzku systému. Jednotlivé prostredia musia byť nezávislé a každé prostredie musí byť dostatočne chránené pred neautorizovanou činnosťou používateľov, pracovníkov vývoja a správcov systémov a mali by byť splnené nasledujúce podmienky: vyvíjaný a prevádzkový systém musia bežať na logicky oddelených prostrediach, vývojové a testovacie aktivity musia byť oddelené,

20 ODDELENIE VÝVOJOVÉHO, TESTOVACIEHO A PRODUKČNÉHO PROSTREDIA /2
kompilátory, editory a iné vývojové prostriedky nesmú byť prístupné z prevádzkového prostredia, pokiaľ potrebuje používateľ prístup do testovacieho a prevádzkového prostredia, musí mať rôzne heslá pre každý zo systémov, jednotlivé prostredia systémov musia byť viditeľne označené napríklad nápisom na hlavnej obrazovke alebo odkazom v menu, zamestnanci vývoja nesmú mať prístup do prevádzkového prostredia. Ak je takýto prístup dočasne potrebný, musia byť prijaté opatrenia pre zabezpečenie autentizácie pracovníkov vývoja.

21 KRYPTOGRAFICKÉ OPATRENIA
Na účely ochrany informácií, ich dôvernosti, integrity, autenticity a dostupnosti by si mala spoločnosť vytvoriť vlastnú politiku a procedúry pre používanie kryptografických techník a manipuláciu a správu s kľúčmi. Kryptografické riešenie ochrany informácií by malo byť chápané ako súčasť procesu ohodnotenia rizík a výberu opatrení, aby sa určila úroveň ochrany, ktorá by mala byť informáciám poskytnutá.

22 ŠIFROVANIE Šifrovanie je kryptografická technika, ktorú možno použiť na ochranu dôvernosti informácií. Mala by byť v spoločnosti používaná na ochranu citlivých alebo kritických informácií. V dokumente Politika používania kryptografických opatrení by mal byť podľa kategórie údajov stanovený typ a kvalita používaného šifrovacieho algoritmu a dĺžka používaných kryptografických kľúčov. Pri implementovaní kryptografickej politiky spoločnosti by sa mali zvážiť predpisy a štátne obmedzenia, ktoré sa môžu vzťahovať na používanie kryptografických techník v rôznych častiach sveta a otázky medzinárodného toku zašifrovaných informácií.

23 DIGITÁLNE PODPISY Digitálne podpisy poskytujú prostriedok ochrany autenticity a integrity elektronických dokumentov. Používajú sa na verifikáciu osoby, ktorá podpísala konkrétny elektronický dokument a kontrolu, či obsah podpísaného dokumentu bol alebo nebol zmenený. Digitálne podpisy môžu byť implementované použitím kryptografickej techniky založenej na unikátnom páre kľúčov, kde jeden kľúč sa používa na vytvorenie podpisu - súkromný kľúč, a druhý na overenie podpisu - verejný kľúč. Pozornosť je potrebné venovať typu a kvalite algoritmu podpisu a dĺžke kľúčov, ktoré sa majú používať. Kryptografické kľúče, používané na digitálne podpisy, by mali byť iné, než tie, ktoré sa používajú na šifrovanie.

24 KONTROLA PRÍSTUPU K ZDROJOVÝM KÓDOM
Aby sa zabránilo možnému poškodeniu alebo nesprávnemu fungovaniu programového vybavenia, je potrebné aplikovať pravidlá pre kontrolu prístupu k zdrojovým kódom a zabrániť ich neautorizovanej modifikácii alebo strate. Preto je potrebné zabezpečiť plnenie nasledujúcich pravidiel: zdrojové kódy programov sa nesmú nachádzať v prevádzkovom prostredí, pre každú aplikáciu musí byť určený správca knižnice zdrojových kódov, pracovníci podpory nesmú mať neobmedzený prístup ku knižniciam zdrojových kódov, zdrojové kódy, ktoré sa vyvíjajú alebo menia, nesmú byť uložené v knižniciach prevádzkových zdrojových kódov, aktualizácia knižníc zdrojových kódov a ich poskytovanie programátorom musí podliehať schváleniu garanta a môže byť vykonaná len správcom knižnice,

25 KONTROLA PRÍSTUPU K ZDROJOVÝM KÓDOM /2
výpisy zdrojových kódov musia byť uložené v zabezpečenom prostredí, všetky prístupy ku knižniciam zdrojových kódov musia byť zachytené v auditnom zázname, staré verzie zdrojových kódov a ich podporné programy musia byť archivované a označené dátumom a časom, kedy boli využívané v prevádzke. Spolu s nimi musia byť zaznamenané aj použité dátové modely a procedúry pre spracovanie. Zmeny vykonané v zdrojových kódoch musia byť zapísané do databázy zmien. Databáza zmien slúži na sledovanie zmien zdrojového kódu a umožňuje v prípade potreby rekonštruovať históriu vykonaných zmien.

26 ZMENY V SYSTÉMOCH Pri každej zmene konfigurácie systému je potrebné:
Zamestnanci spoločnosti nesmú svojvoľne zasahovať do konfigurácie systémov a ich komponentov a všetky realizované zmeny musia byť autorizované oprávnenou osobou. Pri každej zmene konfigurácie systému je potrebné: zdokumentovať všetky zmeny v technickom nastavení systému a uchovať nové nastavenia, zdokumentovať zmeny v pracovných postupoch, informovať dotknuté útvary o realizovaných zmenách, preškoliť zamestnancov na nové postupy, zaznamenať zmeny do všetkých exemplárov dokumentácie.

27 ZMENY OPERAČNÝCH SYSTÉMOV
Operačné systémy musia byť pravidelne aktualizované - inštalácia nových verzií podporovaných výrobcom, inštalácia záplat. V prípade zmeny operačného systému je potrebné otestovať, či zmena nemá vplyv na prevádzku a bezpečnosť používateľských aplikácií. Je potrebné zabezpečiť: overenie funkčnosti programových kontrol, vykonanie testov, oznámenie o zmene operačného systému v dostatočnom predstihu, aby potrebné testy a overenia mohli byť vykonané pred implementáciou, implementáciu potrebných zmien do plánov kontinuity funkcií, zabezpečenie aktualizácie systémovej dokumentácie a archivácia predošlej verzie, zabezpečenie modifikácie procedúr a technických špecifikácií.

28 REŠTRIKCIE NA ZMENY SOFTVÉROVÝCH BALÍKOV
Zásadné zmeny softvérových balíkov by mali byť obmedzené na minimum. Pokiaľ sa takáto zmena považuje za nevyhnutnú, je potrebné zvážiť: riziko, že zabudované kontrolné mechanizmy budú narušené, možnosť dosiahnuť požadovanú zmenu od dodávateľa ako súčasť štandardnej aktualizácie, dopady na prevádzku a ďalšiu údržbu systému. Ak je zmena nevyhnutná, je potrebné originálny softvér uložiť a zmenu vykonať na identickej kópii. Všetky zmeny musia byť testované a dokumentované, aby v prípade potreby mohli byť zapracované do budúcich verzií systému.

29 REŠTRIKCIE NA ZMENY SOFTVÉROVÝCH BALÍKOV /2
Vývojové prostredie musí byť kontrolované a malo by byť zabezpečené overenie, či zmeny systému a jeho komponentov negatívne neovplyvňujú jeho bezpečnosť. Pri kontrole zmenových konaní sa doporučuje overiť, či: nebola znížená účinnosť bezpečnostných a kontrolných procedúr v systéme, zamestnanci správy a podpory majú prístup len k potrebným častiam systému, bolo vykonané formálne schválenie zmeny, bolo odsúhlasené zavedenie zmeny do prevádzkového prostredia štandardným spôsobom.

30 SKRYTÉ KANÁLY A TRÓJSKE KONE
Skryté kanály a Trójske kone môžu spôsobiť nepriame prezradenie údajov a môžu byť aktivované zmenou parametrov prístupných zo zabezpečeného aj nezabezpečeného prostredia alebo vložením údajov do údajového toku. Trójske kone sú navrhnuté tak, aby ovplyvnili systém neautorizovaným spôsobom a neboli ľahko identifikovateľné. Na ochranu pred takýmito hrozbami je potrebné: kupovať softvér len z renomovaných zdrojov, kupovať softvér spolu so zdrojových kódom, ktorý môže byť overený, používať vyskúšané produkty, preskúmať zdrojový kód pred využitím aplikácie v ostrej prevádzke, kontrolovať prístup k zdrojovým kódom inštalovaných aplikácií a ich modifikácie, pre prácu s kľúčovými aplikáciami využívať osvedčených a autorizovaných zamestnancov.

31 TESTOVANIE SYSTÉMU Každá zmena systému by mala byť pred nasadením do prevádzkového prostredia spustená v testovacej prevádzke v testovacom prostredí. V testovacej prevádzke sa vykonajú testovacie scenáre v súlade s požiadavkami akceptačných kritérií pre nasadenie do prevádzky. Pri zmenách, ktoré ovplyvňujú alebo môžu ovplyvniť kritické funkcie systému, by mal byť vykonaný tieňový beh systému, ak je to technicky a ekonomicky možné. V prípade, že zmeny systému sú vykonávané dodávateľsky, mala by každá zmluva s dodávateľom obsahovať klauzulu, v rámci ktorej sú definované: dĺžka testovacej prevádzky, rozsah činností, ktoré sa budú v testovacej prevádzke overované, povinnosti dodávateľa počas testovacej prevádzky - odstraňovanie závad, konzultácie a úpravy do vopred stanoveného termínu.

32 OCHRANA TESTOVACÍCH ÚDAJOV
Údaje použité na testovanie by mali byť podľa typu a stupňa ich klasifikácie chránené a kontrolované. Testovanie si vyžaduje údaje, ktoré sú čo najpodobnejšie dátam prevádzkového prostredia. Použitie osobných údajov, údajov chránených legislatívou SR a ostatných citlivých údajov na testovacie účely by malo byť zakázané. Pred použitím na testovanie by mali byť takého údaje „depersonalizované“. Na ochranu údajov používaných pre testovacie účely by mali byť aplikované nasledujúce opatrenia: údaje určené na testovanie nesmú obsahovať citlivé údaje, procedúra na kontrolu prístupu k prevádzkovým údajom musí byť aplikovaná aj pre prípad testovacích údajov, každé kopírovanie prevádzkových údajov do testovacieho prostredia musí byť schválené garantom testovaného systému, prevádzkové údaje musia byť vymazané z testovacieho prostredia ihneď po ukončení testovania, každé kopírovanie a použitie prevádzkových údajov musí byť zaznamenané v auditnom zázname.

33 PREBERANIE SYSTÉMOV DO PREVÁDZKY
Pri preberaní kúpenej, vyvinutej alebo zmenenej časti systému alebo jeho komponentov do prevádzkového prostredia je nevyhnutné, aby boli jednoznačne definované postupy, na základe ktorých kompetentní zamestnanci spoločnosti preberú dotknuté časti systému a tým ich uvedú do prevádzky. Nové systémy, nové verzie a aktualizácie systému by mali byť do prevádzkového prostredia nasadené až po úspešných akceptačných testoch, na základe protokolu o prevzatí do rutinnej prevádzky, podpísaného garantom a zabezpečení systémovej, prevádzkovej a používateľskej dokumentácie.

34 PREBERANIE SYSTÉMOV DO PREVÁDZKY /2
Pred zavedením systému do prevádzkového prostredia by mali byť posúdené: príprava na zaradenie do prevádzkového prostredia, kompletnosť dodávky a dôveryhodnosť distribúcie, vylúčenie poškodenia alebo nesprávnej práce, oprava chýb, fyzický a logický prístup dodávateľa, certifikácia.

35 PRÍPRAVA NA ZARADENIE DO PREVÁDZKOVÉHO PROSTREDIA
Príprava na zaradenie do prevádzkového prostredia by mala obsahovať: schválenie výsledkov testovania, stanovenie požiadaviek na rozsah a kapacitu spolupracujúcich systémov, zotavenie sa z chýb a procedúry pre reštart systému, uskutočnenie detailnej analýzy rizík a schválenie bezpečnostných opatrení a prepojenia s bezpečnostným systémom, zabezpečenie kontinuity funkcií v prípade výpadku systému, posúdenie, či inštalácia zmeny alebo novej časti systému negatívne neovplyvní existujúci systém, najmä v období špičkovej prevádzky, zmazanie účtov vytvorených pre vývoj a testovanie aplikácie, čo zabráni úmyselnému alebo náhodnému narušeniu bezpečnostných opatrení vývojovými pracovníkmi, pripravenosť prevádzkových procedúr a technických špecifikácií, úspešnosť konverzie údajov.

36 KOMPLETNOSŤ DODÁVKY A VIERYHODNOSŤ DISTRIBÚCIE
Kompletnosť dodávky a dôveryhodnosť distribúcie novej alebo zmenenej časti systému by mala obsahovať nasledujúce kontroly: dodávka bola zrealizovaná v plnom rozsahu, dodávka bola zrealizovaná dôveryhodným distribučným mechanizmom, dodávateľ zrealizoval všetky úkony, na ktoré sa zmluvne zaviazal, systém, zmeny alebo nové časti systému sú inštalované v súlade s technickými normami a pri inštalácii boli zohľadnené požiadavky a odporúčania výrobcu, systém, jeho časti alebo zmeny vykonávajú všetky činnosti, ktoré boli špecifikované pri objednávaní a sú zahrnuté v predmete zmluvy, bola dodaná technická dokumentácia - schémy, popisy, pracovné postupy, bola dodaná technika pre konfiguráciu, kalibráciu a meranie, boli vykonané školenia obsluhy a správy systému.

37 VYLÚČENIE POŠKODENIA ALEBO NESPRÁVNEJ PRÁCE
Vylúčenie poškodenia alebo nesprávnej práce by malo obsahovať nasledujúce činnosti: aktualizácia prevádzkového programového vybavenia je vykonávaná len určeným zamestnancom po schválení garantom systému, aktualizácia sa vykonáva pri zablokovanom prístupe používateľov do systému, komponenty prevádzkového prostredia obsahujú len spustiteľný kód, nie zdrojové texty programov, spustiteľný kód môže byť do prevádzkového prostredia nainštalovaný, ak sú moduly dostatočne otestované a boli aktualizované príslušné zdrojové kódy v programových knižniciach.

38 OPRAVA CHÝB Aktivita oprava chýb by mala obsahovať nasledujúce činnosti: rozhodnutiu implementovať novú verziu, zmenu alebo časť systému musí predchádzať zváženie jeho bezpečnostných vlastností, nových bezpečnostných funkcií a analýza počtu a závažnosti bezpečnostných problémov, ktoré sa v systéme vyskytujú, z dôvodu možnej chyby novej verzie je potrebné vykonať zálohovanie predchádzajúcich verzií softvéru, kontrola, či nová verzia je oficiálne podporovaná výrobcom, záplaty (patche) je potrebné inštalovať v prípadoch, keď pomáhajú eliminovať alebo redukovať bezpečnostné slabiny systému. Pre všetky aktualizácie v prevádzkovom prostredí by mal existovať auditný záznam.

39 FYZICKÝ A LOGICKÝ PRÍSTUP DODÁVATEĽA CERTIFIKÁCIA
Fyzický a logický prístup pracovníkom dodávateľa k prevádzkovým častiam systému by mal byť poskytovaný: len pre podporné účely a nevyhnutné prípady, každý takýto prístup musí byť schválený garantom systému, aktivity dodávateľa v systéme by mali byť sledované a monitorované. Ak sa z dôvodu spracovávania citlivých údajov v systéme vyžaduje certifikácia, je potrebné overiť, či systém, zmena alebo nová časť systému vyhovuje požiadavkám na certifikáciu v súlade s požiadavkami platných zákonov a smerníc pre spracovanie citlivých údajov.