Otázka č. 19

Zajímalo by mě, jestli existuje nějaká směrnice, norma či podobný oficiální dokument, který v rámci Application Managementu jednoznačně vyžaduje oddělení podpory SW od vývoje SW (vyloženě, že to musí být jiná osoba). V globále se jedná o zamezení vývojářům k jakýmkoliv produkčním datům, ale je otázkou, jestli stačí jen dát vývojářům jiné role do vývoje a jiné role do produkce, nebo jestli to skutečně dle nějakých norem musí být jiná osoba?

ODPOVĚĎ

Odpověď Vladimíra Váni – z pohledu ISO norem týkajících se informační bezpečnosti:

ČSN ISO/IEC 27001 (definuje požadavky)

ISO/IEC 27002 (definuje postupy a doporučení pro realizaci opatření)

Výtah z normy 27001:

A.10 Řízení komunikací a řízení provozu
A.10.1 Provozní postupy a odpovědnosti
A.10.1.3 Oddělení povinností

Opatření:

Pro snížení příležitostí k neoprávněné modifikaci nebo zneužití aktiv organizace musí být zajištěno oddělení jednotlivých povinností a odpovědností.

A.10.1.4 Oddělení vývoje, testování a provozu

Opatření:

Pro snížení rizika neoprávněného přístupu k provoznímu systému, anebo jeho změn, musí být zajištěno oddělení prostředků vývoje, testování a provozu.

Výtah z normy 27002:

10.1.3 – Pro snížení příležitostí k neoprávněné modifikaci nebo zneužití aktiv organizace by mělo být zajištěno oddělení jednotlivých povinností a odpovědností.

Princip oddělení povinností minimalizuje riziko úmyslného nebo nedbalostního zneužití systému. Pozornost by měla být věnována oblastem s nedílnou odpovědností jednotlivce, který by mohl mít přístup k aktivům, mohl by je modifikovat nebo používat bez řádného oprávnění, aniž by to bylo zjištěno. Vyvolání události by mělo být odděleno od jejího schválení. Při návrhu opatření by měla být zajištěna možnost spolčení angažovaných jedinců.

V malých organizacích může být tato metoda řízení obtížně použitelná, přesto by měl být tento princip v rámci možností aplikován. Všude, kde je oddělení složité, by měla být zvážena jiná opatření, jako monitorování činností, auditní záznamy a dohled nadřízených zaměstnanců. Je důležité, aby bezpečnostní audit zůstal nezávislý.

10.1.4 – Pro prevenci provozních problémů by měla být zajištěna nezbytná úroveň oddělení provozního, testovacího a vývojového prostředí a zavedena vhodná opatření.

V úvahu by měla být vzata následující opatření:

1. měla by být stanovena a dokumentována pravidla pro převod programů z vývojového do provozního prostředí
2. vývojové a provozní programové vybavení by mělo být provozováno na různých počítačích nebo v různých doménách či adresářích
3. překladače, editory a jiné systémové utility by neměly být dosažitelné z provozních systémů, pokud to není nutné
4. testovací prostředí by mělo co nejvíce simulovat provozní prostředí
5. pro provozní a testovací systémy by měly být používány různé uživatelské profily. Nabídky by měly zobrazovat vhodné identifikační zprávy, aby se snížilo riziko chyby
6. citlivá data by neměla být kopírována do testovacích systémů

Další informace:

Vývoj a testování mohou způsobit vážné problémy, například nechtěnou modifikaci souborů, prostředí nebo způsobení systémové chyby. Je proto potřebné mít známé a stabilní prostředí, které zaručí smysluplnost testování a rozpozná nevhodný přístup vývojářů.
Tam, kde má vývojový a testovací personál přístup k provoznímu systému, může být schopen vnést do něj neschválený a neotestovaný kód nebo změnit provozní data. V některých systémech by tato možnost mohla být zneužita k podvodu nebo k zavedení netestovaného nebo škodlivého kódu. Takový kód může způsobit vážné provozní problémy.

Vývojáři a osoby provádějící testování mohou také představovat hrozbu pro důvěrnost provozních dat. Vývojové a testovací práce v případě, že sdílejí stejné výpočetní prostředí, mohou umožnit i nechtěné změny programů a informací. Oddělení vývojových, testovacích a provozních zařízení je proto žádoucí pro snížení rizika nežádoucích změn nebo neautorizovaného přístupu k provozním programům a obchodním datům.

Abych to shrnul – Je tedy požadováno:

1. oddělit samotné prostředí vývoje od ostrého provozu (kvůli hrozbě přerušení, příp. smíchání testovacího a ostrého provozu s negativními následky)
2. zajistit ochranu dat vhodným způsobem – tak, aby byl zajištěn přístup pouze oprávněným osobám

Jedná-li se o programátora, který bude testovat systém s daty (jež byla převzata např. z ostrého systému, ze zálohy apod.), pak buď tato data nesmí podléhat ochraně, nebo musí být „anonymizována“, nebo musí být např. programátor zavázán mlčenlivostí (smluvně, NDA či jednostranným prohlášením s vymezením sankcí – dokazování zneužití je ovšem velmi problematické).

Odpověď Vladimíra Kufnera – z pohledu ITIL[1]:

Já tedy neodpovím jinak než odkazem na žlutou knihu ITIL V2[2], kde se ITSM a Application Management (AM) považují ještě oficiálně za 2 různé disciplíny, viz níže přiložený výňatek žluté knihy.

Tato publikace jakkoliv napsaná IBM (sic)[3] a formulovaná jiným způsobem než vlastní publikace ITIL a v jiné struktuře, je asi jedinou, která reálně popisuje běžný stav této praxe. Podle mého názoru by SW development měl být formálně rozpoznaným procesem v SD, patří tam stejně jako je tomu v CobIT. Klidně by se mohl odkazovat na metodiky pro SDLC[4] jako je Agile, RUP a celá řada dalších (to ostatně do jisté míry dnes v ITIL V3 je, problémem ale je, že ten proces oficiálně NEEXISTUJE). AM by pak měl být spíše jakýmsi „super-procesem“ překračujícím hranice SD/ST a SO[5].

To podle mého názoru pokračuje i v éře ITIL V3, kde se AM dostalo do vínku SO, i když tam podle mého názoru patří jen část této disciplíny. Viz např. obr. 5.1 v SO: zde se předpokládá oddělení developmentu a operations. V kap. 6.5 SO je zmínka, že AM je not usually the same as the Applications Development teams, a to v celé kapitole dále pokračuje a je dále rozpracováváno. Správa provozu ve smyslu každodenního provozu je pokryta funkcí IT Operations Managementu, což se tedy nekryje s funkcí AM. Na straně druhé, celková správa provozu – SO – zahrnuje obě tyto funkce, takže by se dalo odvážně tvrdit, že to vlastně ITIL neodděluje.

Dle Davida W.[6], tohle uspořádání bylo spíše reakcí na to, že se SW Development ani AM neobjevil v SD, kam by to spíše patřilo, takže se rozhodli přijít s konceptem funkce AM v SO.

Ale zpět k dotazu. ITIL z principu svého pojetí neobsahuje striktní, rigidní zákazy čehokoliv, jsou zde pouze doporučení. A toto tam definitivně NENÍ[7].

Takovéto doporučení o striktním oddělení vývoje a podpory se poprvé objevilo někdy na konci 80. let někde u Gartnerů, bylo poměrně dost dlouho podporováno některými firmami v oblasti edukace ITIL, typicky Pink Elephant, takže se to dost vžilo, u nás to bylo někdy hodně násilně vymáháno (zažil jsem to v některých velkých firmách z oblasti bankovnictví a telco).

Druhou věcí je, jaká je realita, co se doporučuje atd. Zde se ve smyslu textace knih ITIL V3 víceméně předpokládá, že to takto odděleno je. Např. v publikaci SO najdeme celou řadu rolí, včetně analytických, ale něco jako SW vývojář tam rozhodně není. Jak již jsem zmínil, je tam dále celá řada odkazů, kde se výslovně zmiňuje rozdíl mezi AM (resp. Developmentem) a běžnou správou provozu.

Legrace je, že si ITIL V3 přivlastnilo super-proces Application management ve formě Funkce a srovnává ji v SO s rolí Application Development, ta druhá role ale nikde není popsána, asi se předpokládá, že to každý zná

P.S. Podle mých střípků z APMG se toto hodně diskutovalo při Update ITIL V3.1[8], kdy se přišlo s názorem, že by SW Development nebo Application Development měl být samostatným procesem, ale nakonec převážil názor, že se nesmí zvyšovat počet procesů, takže SW Development a Project Management budou kandidáty až na ITIL V4

[1] S vysvětlivkami a doplňujícími poznámkami pod čarou od Jiřího Skály

[2] Office of Government Commerce. Application Management. London, U.K. : TSO, 2002. ISBN 9780113308668

[3] Publikace Application Management má 4 autory, dva jsou z IBM a dva z Microsoftu

[4] SDL = Software Development Life Cycle

[5] SD = Service Design; ST = Service Transition; SO = Service Operation. Jedná se jednak o jedny z klíčových publikací ITIL V3, a jednak o názvy fází životního cyklu služby.

[6] David Wheeldon = jeden ze dvou autorů publikace Service Operation (SO)

[7] ITIL pouze upozorňuje na nutnost oddělovat testovací a produkční data, aby nemohlo dojít k jejich záměně nebo zneužití (ST, kap. 4.5.4.9, poslední odstavec, první a druhá odrážka). Jakým způsobem má být takovéto oddělení dat realizováno, již ITIL neuvádí. Pokud je však v podniku toto oddělení realizováno na principu organizačně-procesním, tzn., specialisté application developmentu nemají vůbec přístup k produkčním datům, lze o takovémto řešení prohlásit, že je v souladu s ITIL J.

[8] Dne 11.6.2011 publikovalo OGC dokument „ITIL® UPDATE FAQs – Summer 2011“, ke stažení např. zde, kde je uvedeno, že ve verzi ITIL V3.1 bude v publikaci SO změněno rovněž toto: The relationship between application management activities versus application development activities is also clarified. Datum vydání publikací verze 3.1 je stanoveno na 29.6.2011.