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)
Datum poslední úpravy

Datum poslední úpravy úlohy ve tvaru rrrr.mm.dd.

:
2016-04-08
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:
    • zjištění nesrovnalostí v počtu vlastněných licencí a instalovaných aplikací,
    • minimalizace rizika z používání nelegálního softwaru,
    • připravení organizace na zavedení software asset managementu,
    • sběr klíčových informací k prokázání vlastnictví softwaru,
    • eliminace rizika z používání neautorizovaného softwaru ve firemním prostředí,
    • zjištění skutečného stavu softwarových aktiv a jeho hodnoty.
2. Obsah úlohy
  • Poznámka : Detailní vymezení obsahu úlohy je v PDF příloze skupiny úloh "Řízení a správa IT zdrojů" (TG701 ).
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í
  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:
    • Podlicencování – situace, kdy zákazník má měně licencí než instalovaných produktů, zařízení či uživatelů,
    • 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.