Toto je objekt systému MBI.

MBI (Management Byznys Informatiky) je portál obsahující zobecněná řešení v řízení provozu a rozvoje IT, resp. podnikové informatiky.

Pokud máte zájem získat více informací o tomto objektu (vazby na další objekty, přílohy, apod.), ale i získat mnoho dalších užitečných materiálů, můžete tak učinit ZDE / (registrace je bezplatná).

Úloha : Softwarový audit
Softwarový audit
Kód úlohy

Standardní kód úlohy v MBI.

:
U705A
Autor návrhu úlohy

Jméno a příjmení autora úlohy

:
Macek, J. (iPodnik)
Předpokládaná pravděpodobnost užití v praxi

Předpokládaná pravděpodobnost užití úlohy v praxi, hodnoty 0 - 1. Např. 0,7 - úlohu lze využít v 7 z 10 podniků. Hodnoty jsou průběžně testovány a upřesňovány na základě anket a průzkumů.

:
0.5
Charakteristiky úlohy

Charakteristiky úlohy

1. “Softwarový audit“ – cíl, účel

Cílem softwarového auditu je:

  1. zjištění nesrovnalostí v počtu vlastněných licencí a instalovaných aplikací,
  2. minimalizace rizika z používání nelegálního softwaru,
  3. připravení organizace na zavedení software asset managementu,
  4. sběr klíčových informací k prokázání vlastnictví softwaru,
  5. eliminace rizika z používání neautorizovaného softwaru ve firemním prostředí,
  6. zjištění skutečného stavu softwarových aktiv a jeho hodnoty.
2. Obsah úlohy

Softwarový audit je kontrola používaného softwaru v rámci organizace. Soustředí se na nabývací dokumentaci a soulad s licenčními podmínkami dle této dokumentace. Může ho iniciovat management podniku nebo vydavatel softwaru. Výsledky softwarového auditu přináší licenční čistotu, ale bez software asset managementu jsou dlouhodobě neudržitelné. Korektní stav, který audit nastolí, vydrží jen opravdu krátkou dobu, pokud nebudou fungovat procesy SAM. Zavést procesy SAM není levné, ale eliminují rizika jak finanční, tak trestní. Audit je prospěšný pro obě strany. Zákazník z něj získá licenční korektnost a vydavatel jistotu, že jeho produkt je užíván, dle pokynů. Audit může být vstupní bránou do SAM. V tomto případě má audit funkci počátečního úklidu a bývá tvrdým uvedením do reality. Druhým způsobem je nejprve vymyslet celou IT koncepci, určit co potřebujeme a jak to budeme využívat. Začneme vytvořením softwarových profilů. Profil určuje, kdo a co potřebuje dle jednotlivých rolí v rámci organizace. Někdo dostane pouze základní aplikace, někdo specifické aplikace. Dále vytvoříme seznam schválených aplikací a proces pro schvalování jiného softwaru. Celý proces zavádění SAM je detailněji rozebrán v úloze Software asset management, ale je nutné si uvědomit, že začínat by se mělo v oddělení lidských zdrojů, kde se specifikují jednotlivé role a jejich požadavky.

Podstata SAM :

SAM je obecně postup pro zavedení interních procesů správy softwaru a optimalizaci investic a nákladů při pořízení a užívání IT aktiv. Díky SAM společnost získá povědomí o softwarových prostředcích, zda je dokáže efektivně využívat, optimálně nakupovat a jednoduše spravovat. K zavádění SAM je vhodné použít osvědčené metodiky, které jsou přizpůsobeny potřebám společnosti. Součástí je inventarizace a softwarový audit.

Typy auditu:

Nařízený (forced) :

  1. Nařizuje autor (vydavatel softwaru).
  2. Audit je prováděn profesionální společností (v ČR se v případě Microsoft produktů jedná pouze o konzultantské firmy PwC, KPMG, Deloitte a E&Y).
  3. Pokud audit dohledá více než 5% rozpor s realitou, pak hradí náklady auditu zákazník (neoficiální cena bývá mezi 10-15ti tisíc euro).
  4. Pokuty při nalezení nesrovnalostí jsou u Microsoftu 1,75 % ceny všech licencí + dokoupení chybějících licencí. U jiných vydavatelů je to podobné.
  5. U specifických licenčních ujednání, jako je SPLA, se identifikují všechny nesrovnalosti zpětně od začátku využívání služby zákazníkem. V tomto případě poskytovatel může hradit až 125 % ceny softwaru.
  6. Příklad: Firma, která má zanedbanou evidenci licencí, má v průměru 20 % softwaru špatně zalicencovaného, a pokud k tomu připočítáme pokutu, dokoupení licencí a cenu auditu, tak firma tímto zanedbáním riskuje okolo 50 % hodnoty veškerého svého softwarového majetku. A protože cca 20 % IT rozpočtu je dnes vyčleněno na HW, jedná se o nesmyslný risk, který mnohé společnosti přehlížejí.

Dobrovolný:

  1. Provádí se z vlastní vůle společnosti a má preventivní charakter. Není však příliš častý.
  2. Nákladově vychází podobně jako nucený audit, ale existuje zde více času na vypořádání se s výsledky auditu a nastavením procesů tak, aby se to v budoucnu nestávalo.
  3. Mnohdy i při zdání, že licencování je v pořádku, se většinou nesrovnalosti nedostane pod 10 % a společnost bude při nuceném auditu penalizována a bude muset licence tak nebo tak dokoupit. U dobrovolného auditu se vyhne pokutě a dá vše do pořádku svým vlastním tempem bez tlaku auditorské společnosti.

Autorské právo a audit:

Při vývoji softwaru vzniká autorství, kterého se již výrobce nemůže vzdát, může ho však předat a nebo může přenášet práva na užívání. Uživatelská práva jsou specifikována v licenčních podmínkách a autor softwaru má do licenčních podmínek zakomponovanou pasáž o právu na kontrolu dodržování těchto ustanovení. Funguje to na principu důvěry. Tento trust-based model je postavený na tom, že vydavatel uděluje uživateli práva a věří, že uživatel nebude produkt užívat v rozporu s těmito podmínkami. Ponechává si však právo vloženou důvěru ověřit auditem. Nešťastný začátek auditu je reakce zákazníka, že auditor nemá žádné právo audit provádět. Již zde, zákazník dokázal, že nečetl licenční podmínky a celý proces může být velice zdlouhavý a nepříjemný pro obě strany. Nakonec však vždy zákazník prohraje. Uživatel má povinnost proaktivně dokázat, že využívá produkt dle licenčních podmínek. V případě autorského zákona neplatí, co není zakázané, je povoleno. Dodržování autorského zákona prosazuje kromě vydavatele softwaru také stát. Trestní sazba za nedodržování autorského zákona je až 8 let odnětí svobody za prohřešky, které přesahují pět milionů korun. Což při cenách softwarových produktů není pro větší organizaci nijak vysoké číslo. Trestní sazba je krajním, ale reálným řešením, protože vydavatelé softwaru se vždy snaží situaci urovnat a získat své peníze.

Nabývací doklady :

Nabývací doklady se z účetního hlediska nesmí vyhodit po celou dobu fungování společnosti. Auditor se například může dožadovat dokladu k softwaru, na kterém bylo zpracováváno účetnictví před deseti lety. A i když tento software je již vyřazený, je třeba doložit, že v době užívání tohoto softwaru na správu účetnictví, byl správně zalicencován. I k těmto situacím může docházet a je tedy nutné nabývací doklady pečlivě ukládat a počítat při zavádění SAM i s náklady na jejich správu a uložení. Ukládat se například musí u FPP i celé balení a krabice.

Účetně se může software vést jako hmotný i nehmotný majetek, jako investiční majetek, ale i jako služba (např. software assurance). Software v průběhu jeho životního cyklu může měnit charakter a přesouvat se mezi účetními skupinami. Vše záleží na vedení společnosti. Vyplívá z toho však, že klasická inventura v tomto případě nepomůže.

Audit trvá v ideálním případě šest týdnů. V realitě však může trvat i čtvrt roku. Auditor může při zbytečném protahování stanovovat lhůty, ale jakmile je vidět součinnost, snaží se dohodnout.

Audit se zpravidla provádí u organizací, které mají více než 200 zařízení. Audit samozřejmě může potkat i menší organizace, ale u menších organizací je častější self assesment. To znamená, že vydavatel se zeptá statutárního orgánu společnosti, zda je vše v pořádku a nechá si to podepsat. Pokud to tak není a schválení proběhlo bez vnitřní kontroly, při opravdovém auditu to společnosti výrazně přihorší. Tento princip sebehodnocení funguje spíše v USA, kde by si majitel firmy nedovolil odsouhlasit něco, co nemá ověřené.

Modely nákupu licencí :

  1. dle potřeby po kusech – Nákupy licencí nemají koncepci. Díky tomu se špatně se dohledávají doklady a riziko nesrovnalostí roste každým nákupem,
  2. dle plánu po balíkách – Při nákupu se zákazník drží plánu rozvoje IT a dopředu ví, jaké bude mít v budoucnu požadavky. Dle toto nakupuje určité balíky licencí pro celou firmu, které připravuje přímo vydavatel. Snižuje se tím riziko podlicencování a v TCO vychází tato varianta lépe i při vyšší úvodní investici. Také existuje menší pravděpodobnost nuceného auditu.

Problematické scénáře :

  1. virtualizace – scénáře, které zahrnují virtulizaci můžou zkomplikovat situaci. Například licence na fyzických serverech se mohou přehazovat jednou za 90 dní. Pokud v té době na fyzickém serveru běží virtuální server a ten se následně přesune na jiný fyzický server, který není zalicencovaný, porušují se tím licenční podmínky. Při auditu se musí prokázat, kdy a kde byla určitá licence přiřazena. A to bývá opět velice složité. Řešením je software assurance. Díky software assurance můžu licence přiřazovat libovolně v průběhu času.
  2. BYOD - velice problematické z pohledu licencování. Prokazování, zda software je správně licencován, využíván pro firemní účely či osobní účely a zda nepřináší riziko pro společnost, je mnohdy nemožné. Řešením je opět software assurance, které dokáže licenčně ošetřit tyto případy.
  3. obecně u problematických scénářů to funguje následovně: Pokud existuje cesta, jak správně zařízení či uživatele zalicencovat, povinností zákazníka to tak vykonat.

Nejčastější licenční scénáře , při kterých dochází k nesprávnému licencování (zdroj: Microsoft Yammer):

  1. využití edic Microsoft Office určených pro domácnosti ve firemním IT prostředí,
  2. instalace aplikací Office v rámci Office 365 na více zařízení užívaných více uživateli,
  3. chybějící doklady o nabytí software a přiřazení licencí konkrétním uživatelům,
  4. neoprávněné využití hromadné instalace a aktivace u licencí koupených s počítačem a v krabicovém balení,
  5. neoprávněná instalace předchozích verzí software (tzv. downgrade),
  6. upgrade desktopového operačního systému Windows bez podkladové licence,
  7. chybějící přístupové licence (CAL) a neoprávněný nepřímý přístup (tzv. multiplexing),
  8. nedostatečný počet přístupových licencí CAL v režimu CAL per Device,
  9. nesprávné verze přístupových licencí CAL (Client Access License),
  10. neoprávněné přenesení OEM licencí na jiné zařízení,
  11. terminálový přístup k aplikacím Office,
  12. nesprávné využití licencí Windows Server Standard při virtualizaci,
  13. využití licence získané v rámci programu MSDN a MSDN Platforms pro produkční účely,
  14. sdílení licencí mezi mateřskou společností a jejími pobočkami,
  15. použití klientského operačního systému Windows jako serveru pro aplikace.

Závěr :

Společnosti jsou zvyklé najímat právníky a daňové poradce, ale licenčního konzultanta nikoliv. Rizika jsou přitom hodně podobná, jako ve finančním účetnictví. Kombinace znalosti IT a práva je ve společnosti neobvyklá a je třeba vyhledat experta. Pokud však na to firma nemá prostředky, pak musí alespoň číst licenční podmínky delší dobu, než je průměrných čtyřicet vteřin.

3. Vstupy úlohy:
  • Evidence softwarových aktiv (D234A ),
  • Katalog IT služeb (D111A ),
  • Aplikační architektura (D053A ),
  • Technologická architektura (D054A ),
  • Datová architektura (D055A ),
  • Softwarová architektura (D056A ),
  • Analýza stavu technologické infrastruktury (D233A ),
  • Plán rozvoje technologické infrastruktury (D235A ).
4. Výstupy úlohy:
  • Evidence softwarových aktiv (D234A ), aktualizovaný,
  • Katalog IT služeb (D111A ), aktualizovaný.
5. Podmínky úspěšnosti úlohy
  • Poskytnutí plné součinnosti auditorské společnosti,
  • Respektování licenčních podmínek a ujednání,
  • Dohledatelnost nabývacích dokladů,
  • Dostupnost finanční rezervy na nápravu vzniklé situace,
  • Přehlednost podnikové infrastruktury,
  • Znalost licenčních podmínek a podnikového práva.
6. Doporučené praktiky
  • Vedení organizace musí být do SAM zapojeno v maximální míře,
  • Pravidelná evidence a inventarizace softwaru,
  • Zavedení principů a praktik software asset managementu,
  • Komunikace informací v rámci podnikové kultury,
  • Za výsledky auditu by měla být definována zodpovědná osoba či oddělení,
  • Pravidelné překládání zprávy o připravenosti na softwarový audit od podnikového auditora.
7. “Softwarový audit“ - klíčové aktivity

7.1. Sběr vstupních informací

Rozhodnutí v podobě oficiálního dopisu od auditorské společnosti (z pověření vydavatelem) - Tato situace nastává v případě nuceného auditu.

  1. Auditor dá požadavek na tyto informace:
    1. Informace o infrastruktuře, výpis z Active Directory, topologií sítí, datových center atd.
    2. Informace o stanicích a instalovaném softwaru. Pokud má firma nástroj na evidenci softwaru, který eviduje přes 90 % stanic, použijí se informace z těchto nástrojů. Pokud je zákazník nemá, pak mu auditor dává skript, který pustí do sítě a tyto informace získá – zde vzniká zdržení. Skript se musí schválit IT oddělením a otestovat. Až poté si ho zákazník pustí do sítě a dodá potřebné informace. Pokud zařízení není v síti, eviduje se manuálně.
    3. Informace o nákupech softwaru z účetních výkazů.
  2. Získané informace ze sítě a z manuálních kontrol se předají auditorovi. Musí se jednat alespoň o 80% vzorek skutečného stavu. Zbytek se extrapoluje. To může mít negativní efekt na zákazníka. Pokud je z 80 % zařízení čtvrtina špatně zalicencována, auditor usoudí, že tomu tak je i u chtějících 20 %. Je tedy v zájmu firmy dodat co nejvíce informací a co možná největší počet stanic a serverů.
  3. Pokud má firma zavedeny nástroje na evidenci softwaru, nemusí je mít vždy správně implementovány a nástroje samy o sobě licenčním podmínkám nerozumí. Je třeba vždy mít ve firmě někoho, kdo licencování rozumí a dokáže nástroje nastavit a správně interpretovat výsledky, které poskytují. Může to být člověk interní nebo externí licenční konzultant. Auditor nemusí výsledky z těchto nástrojů brát v potaz.
7.2. Zjištění, kdo a jak stanice a produkty používá nebo používal
7.3. Porovnávání informací od zákazníka se skutečným stavem
  1. Porovnávání probíhá na dálku nebo přímo na místě,
  2. Například v datovém centru se namátkově kontrolují fyzické servery a porovnávají se údaje od zákazníka a skutečný stav na místě nebo porovnávají účetní záznamy s nahlášeným stavem.
  3. Opět je použita metoda extrapolace.
7.4. Řešení přístupových scénářů
  1. U serverových licencí je to jednoduché, ale u klientských přístupů nikoliv.
  2. Software nepočítá přistupujících uživatele a přenáší tedy zodpovědnost na zákazníka. Například u RDS se licencuje per user (na jméno uživatele), per device (na zařízení a kdo zařízení používá, není důležité) nebo kombinací obou možností.
  3. Častá chyba vzniká u nepřímého využívání licence tzv. nepřímé přístupy (multiplexing):
    1. Tento problém vzniká například, když na backendu používáme per user/per device zalicencovaný software, který je automatizovaně spojený se zákaznickou aplikací (e-shop). Zákazník, tedy nepřímo využívá licence tohoto softwaru.
    2. Vzhledem k tomu, že nikdy firma neví, kolik licencí pro zákazníky bude potřebovat, musí se přejít na licencování per core, které nám zajistí neomezené uživatelské využití softwaru. U licencování fyzických jader se však musí platit i za jádra, která nevyužívám. Záleží tedy na propočtu, co se vyplatí více.
    3. Pokud firma nepočítala s touto situací při tvorbě celého systému, bude muset v budoucnu zakoupit licence nové.
    4. Alternativním řešením (pokud je již infrastruktura postavená na licencích klient-server) je umístění mezičlánku do procesu.
    5. Vždy je třeba při nákupu licencí plánovat do budoucna a ptát se dodavatelů, jak by se řešili podobné situace. Zpětně je vymahatelnost špatná.
  4. U online služeb je situace o něco jednodušší. Kdo nemá přiřazenou licenci, službu si nespustí. Problém může vzniknout u různých servisních a administrátorských přístupů, které poskytovatel neplatí, ale může je při nepozornosti využívat i neautorizovaný člověk. To může vést k licenčnímu rozporu.
7.5. Sumarizace získaných informací
  1. Výsledkem je počet chybějících nebo přebývajících licencí jednotlivých produktů.
  2. V tomto čase zákazník dohledává všechny nabývací doklady.
7.6. Porovnání výsledného počtu licencí a jejich spárování s nabývacími doklady

Auditor prochází i nabývací doklady a hledá cross-reference napříč společností.

7.7. Příprava výstupní zprávy
  1. Zpráva obsahuje fakta a míru extrapolace.
  2. Pokud zákazník tuto zprávu rozporuje, pak se akceptuje s výhradami.
7.8. Předání zprávy vydavateli (objednateli auditu)
  1. Ten určí, kolik bude stát narovnání a dává lhůtu 30 dnů na vypořádání.
  2. Soudit se v tomto případě není rozumné. Spory se řeší na místě příslušných soudech, ale dle právního prostředí autora (např. dle práva anglosaského v případě Microsoftu). To může znamenat, že zákazník musí jednat v intencích autora a toto dokazování bývá složité a nákladné.
  3. Posledním bodem je domluva vydavatele produktu se zákazníkem o ceně a platebních podmínkách. Při spolupráci ze strany zákazníka v průběhu celého procesu je domluva vždy snazší a výhodnější pro obě strany.

7.9. Řešení nesrovnalostí v softwarovém auditu

Softwarový audit definuje typy nesrovnalostí:

Existují dvě situace, které mají stejnou pravděpodobnost výskytu:

  1. Podlicencování – situace, kdy zákazník má měně licencí než instalovaných produktů, zařízení či uživatelů
  2. Přelicencování – zákazník má licencí naopak více. Tento případ je o něco lepší, avšak u licencí trvalých, je to také náklad, který by příště, např. při nákupu nové verze nebo jiného produktu, nemusel vzniknout.

Oběma případům se dá zabránit software asset managementem, jehož nedílnou součástí je softwarový audit.