Slovník pojmů eGovernmentu
Speciální | A | Á | B | C | Č | D | Ď | E | É | Ě | F | G | H | CH | I | Í | J | K | L | M | N | Ň | O | Ó | P | Q | R | Ř | S | Š | T | Ť | U | Ú | Ů | V | W | X | Y | Ý | Z | Ž | VŠE
T |
|---|
TDD / BDDTDD staví na cyklu „test–kód–refaktor“ a zajišťuje navržitelnost a testovatelnost. BDD popisuje chování v jazyce domény (Given-When-Then) a podporuje shodu byznysu a IT. Společně snižují regresní chyby a urychlují bezpečné změny. Umožňují jasnou Definition of Done navázanou na automatizované testy. V eGovernmentu pomáhají přesně zachytit legislativní pravidla jako spustitelné specifikace. Vyžadují kulturu verzování a CI/CD, jinak jsou jen teorie. Investice se vrací v údržbě a při auditech. Chybí-li discipliny sklouzne tým k „pozdním“ testům a drahým chybám. | |
TLS/SSL, vzájemné TLSTLS chrání integritu a důvěrnost komunikace a brání odposlechu a manipulaci. Správa certifikátů a protokolů je kritická kvůli zranitelnostem a kompatibilitě. mTLS přidává silnou autentizaci mezi službami v interních API a mikro-architekturách. Politiky musí řešit expirace, rotace klíčů a revokace. Observabilita sleduje selhání handshake a latenci po zapnutí šifrování. Automatizace (ACME) snižuje provozní zátěž a lidské chyby. Oddělení tajemství a least-privilege přístupy zvyšují bezpečnost. Chybná konfigurace TLS je častým zdrojem výpadků a úniků.
| |
TOGAF (The Open Group Architecture Framework)Patří mezi nejrozšířenější architektonické rámce a je využíván i ve veřejné správě. TOGAF obsahuje metodiku ADM (Architecture Development Method), která popisuje kroky, jak architekturu postupně rozvíjet. Zahrnuje také referenční modely, typy pohledů, metamodel a doporučené artefakty. Ve veřejné správě se TOGAF obvykle nepřejímá doslova, ale slouží jako inspirace pro národní architektonické rámce. Výhodou je, že vytváří společný jazyk pro architekty, manažery a dodavatele. Pokud se aplikuje příliš dogmaticky, může být vnímán jako těžkopádný a odtržený od reality. Důležité je vybrat z něj to, co dává smysl dané organizaci, a přizpůsobit rozsah dokumentace. V praxi TOGAF pomáhá strukturovat práci architektů a provázat ji s řízením projektů a portfolia.
| |
Technický referenční modelTRM dává společný slovník pro platformy, middleware, protokoly a bezpečnost. Slouží jako vodítko pro návrh architektur i pro nákupy a SLA. Pomáhá snížit technologickou roztříštěnost a vendor lock-in. Musí mít verze, jasná kritéria přidání/odebrání a přechodové lhůty. Napojení na Standardizační katalog ISVS a SIB drží konzistenci. TRM zrychluje rozhodování – tým sahá po ověřených kategoriích. Měření adopce ukazuje, kde TRM „nežije“ v praxi. Chybí-li TRM každý projekt „vynalézá“ zásobník nanovo. | |
Technický správce (služeb) ISTechnický správce (služeb) informačního systému odpovídá za technickou stránku fungování systému – tedy za infrastrukturu, provoz, integrace, technickou bezpečnost a plnění parametrů služeb (SLA). Tuto roli často plní interní IT útvar nebo externí dodavatel na základě smlouvy o poskytování služeb. Mezi jeho konkrétní úkoly patří: správa serverů, databází a middleware, nasazování nových verzí aplikací, monitoring dostupnosti a výkonu, zálohování a obnova, správa přístupových práv v technických nástrojích, řešení incidentů a koordinace změn. Technický správce je rovněž povinen respektovat požadavky zákona o kybernetické bezpečnosti a souvisejících vyhlášek, případně dalších bezpečnostních standardů organizace. Klíčové je, aby úzce spolupracoval s věcným správcem – technické změny musí odpovídat potřebám agendy a nesmí ohrozit právní jistotu uživatelů ani integritu dat.
| |
TokenV praxi může jít o fyzické zařízení (hardwarový token), SMS kód, mobilní aplikaci nebo čistě softwarový objekt. V moderních systémech se často používají přístupové tokeny v protokolech typu OAuth nebo OpenID Connect. Token obsahuje informace o uživateli, čase platnosti a rozsahu oprávnění. Systémy token ověřují a na jeho základě rozhodují, zda požadavek povolit. Výhodou je, že samotné heslo nebo jiný primární prostředek přihlášení se nepřenáší při každém požadavku. Tokeny musí mít omezenou dobu platnosti a být chráněné před únikem, jinak mohou být zneužity. Ve veřejné správě se tokeny využívají jak pro autentizaci uživatelů, tak pro komunikaci mezi systémy. V praxi je nutné mít jasná pravidla, jak se tokeny vydávají, obnovují, revokují a logují.
| |
TokenizaceTokeny minimalizují šíření citlivých údajů v systémech a logách. Mapovací trezor drží vazbu mezi tokenem a skutečnými daty pod silnou kontrolou. Hodí se pro platby, PII a integrační scénáře s více dodavateli. Zmenšuje rozsah auditů a usnadňuje princip minimálních práv. Implementace vyžaduje vysokou dostupnost a výkon trezoru i v špičkách. Tokeny mohou mít formát zachovávající vzor (např. maskované číslo), ale bez zpětné informace. řídicí rámec řeší životní cyklus tokenu a práva na detokenizaci. Špatná tokenizace dává falešný pocit bezpečí.
| |
Transformace ITTransformace řeší modernizaci aplikací, cloud, automatizaci i nové role a dovednosti. Úspěch vyžaduje sponzorství, jasný business case a roadmapu v inkrementech. Technická část musí jít ruku v ruce s řízením změny u lidí a procesů. Měření dopadů sleduje kvalitu služeb, rychlost dodávek a náklady. Rizika zahrnují závislost na dodavatelích, migrační výpadky a odpor k změně. Komunikace a trénink jsou klíčové pro adopci. řídicí rámec drží konzistenci, bezpečnost a standardy. Chybí-li vypínání starých systémů se přínosy rozpustí v dluhu. | |
Transparentní řízení projektůProjekty publikují plány, stavy, rozpočty a rizika v přiměřené granularitě. Decision log a change log zajišťují dohledatelnost „proč“ a „kdy“. Standardizované reporty a dashboardy snižují potřebu ad-hoc dotazů. Otevřené metriky podporují včasné zásahy a realistická očekávání. V eGovernmentu posiluje důvěru veřejnosti i kontrolních orgánů. Zapojení stakeholderů probíhá pravidelně a strukturovaně. Citlivá data se klasifikují a sdílí jen s oprávněnými. Chybí-li transparentnosti bují politikaření a „překvapení“ na konci. | |