Modelování aplikačních komponent v CMDB

06.09.2025

Aplikace představuje jednu ze základních entit, kterou používá většina organizací, která začínají používat Konfigurační databázi CMDB. Dalšími jsou Zařízení (Device, Hardware), Servery (entita představující operační systém, sloužící aplikaci), datové zdroje (databáze) a výměny dat mezi aplikacemi (API, messaging, batch). Z pohledu enterprise architektury je dále důležitá vazba aplikací na služby, procesy, capability (business vrstva), vazba na informace (vlastnictví a pořizování dat, primární aktiva dle NIS2), vazba na organizaci (týmy a role, které aplikace používají, business vlastník, IT vlastník, klíčový uživatel, hlavní analytik) a vazba na technologie/platformy. Na posledně zmíněnou oblast, která je klíčová pro plánování migrací, technologického dluhu nebo cloud strategy, se zaměříme v tomto článku.

Rozpad aplikace na jednotlivé komponenty, jejich spolupráce (komunikace) a vazba na infrastrukturu, sítě a lokace je často předmětem detailních schémat a dokumentace popisujících bezpečnost, redundanci, škálovatelnost a řadu dalších aspektů. Tyto informace máme k dispozici ve formě nejrůznějších nestrukturovaných (PDF, Word, PowerPoint) nebo semi-strukturovaných (schémata vytvořená v odpovídajícím nástroji) dat. Vedle toho potřebujeme evidovat tato data i ve strukturované formě. To nám totiž umožní provázat data aplikací s nižšími vrstvami a poskytnout podklady pro plánování změn, řešení incidentů, identifikaci závislostí, hrozeb a zranitelností, risk assessment, racionalizaci aplikací apod. Zároveň je vhodné mít flexibilitu v míře, v jaké tyto informace budeme evidovat. Představíme si to na následujícím příkladu.

V aplikačním katalogu evidujeme vedle dalších informací na záložce Architektura základní informace o použitých technologiích v následujícím členění:

• Front end / UI
• Aplikační logika (Back-end)
• Datová vrstva
• Integrace a messaging
• Bezpečnostní a síťové komponenty
• Monitoring, správa a podpora provozu
• Specifické pomocné služby

To nám umožní poskytnout rychlý přehled o architektuře aplikace a neomezit se pouze na základní schéma Klient – Aplikační server – Databáze. Níže uvedený formulář nám umožní snadno a rychle evidovat použití poskytovatele statického obsahu, reverse proxy/load balanceru, API gateway, cache, integračních komponent, poskytovatele identit, Web Application firewall, Secrets manageru, logování, monitoringu, CI/CD pipeline, scheduleru, zpracování souborů, AI/ML komponent nebo notifikací.

Obrázek 1: Karta Architektura v katalogu aplikací

Tento přehled poskytuje informace o použitých technologiích, ale neukazuje provazbu na konkrétní servery, na nichž komponenty běží a není specifický vzhledem ke konkrétním instancím aplikace.  Produkční instance se může např. značně lišit od testovací (jiná infrastruktura, vysoká dostupnost, failover a clusterové řešení…). Toto nám umožní entita Aplikačních komponent, které představují vazbu Instance aplikace a OS Serveru (Machine) s klasifikací komponenty viz Architektura výše.

Obrázek 2: Přehled Aplikačních komponent

Provazba na Machine nám umožní vykreslit schéma infrastruktury aplikace a zobrazit On premise a Cloud komponenty, identifikovat hardware redundanci nebo naopak riziko single point of failure.

Obrázek 3: Schéma infrastruktury

V evidenci můžeme jít ještě níže a zachytit komunikaci jednotlivých komponent. Evidujeme zdrojovou a cílovou aplikační komponentu, jejich IP adresy, použitý port a protokol. Tento přehled nám umožní získat prvotní představu a identifikovat potenciální slabiny při použití zastaralých protokolů. Komunikaci můžeme popsat i z pohledu zajištění autenticity, integrity, důvěrnosti, použití kryptografických primitiv a jejich parametrů, ochrany proti downgrade útoku nebo připravenosti na post quantum kryptografii.

Obrázek 4: Komunikace aplikačních komponent

Někdy cítíme frustraci ze zastaralých technologií, které aplikace používají a dlouhodobě se je nedaří nahradit. Prvořadým cílem by přitom mělo být mít přesnou představu o aktuálním stavu, aby bylo možné zhodnotit rizika, navrhnout varianty a naplánovat potřebnou migraci. Do tohoto se můžeme pustit hned a začít u položek, které máme na starosti my sami nebo v týmu s kolegy. Katalog aplikací evidující technologie na několika úrovních (záložka Architektura, Aplikační komponenty a Komunikace Aplikačních komponent) nám toto umožní prakticky dosáhnout prostřednictvím postupné aktualizace informací z nejvyšší úrovně až k té detailní.

Přečtěte si více o configuration management a ObjectGearsCMDB.