Aplikace univerzálního rámce řízení přístupu
|
|
- Zbyněk Kříž
- před 7 lety
- Počet zobrazení:
Transkript
1 Aplikace univerzálního rámce řízení přístupu Karel Burda, Petr Ležák Fakulta elektrotechniky a komunikačních technologií VUT v Brně burda@feec.vutbr.cz, xlezak02@stud.feec.vutbr.cz Abstrakt Současné systémy řízení přístupu v počítačových sítích (např. RADIUS, IEEE 802.1X) jsou velmi různorodé, úzce specializované a neschopné vzájemné spolupráce. Možným řešením těchto problémů je univerzální rámec řízení přístupu, který je založen na myšlence, že všechna zařízení počítačové sítě jsou vybavena tzv. portály řízení přístupu. Každý takový portál řídí přístup jiných zařízení k aktivům daného zařízení nebo vyjednává přístup aplikací z daného zařízení k aktivům jiných zařízení. Ke komunikaci mezi portály byl navržen dvoustranný protokol ACP. Zprávy tohoto protokolu umožňují sjednání požadovaných aktiv, sjednání metody autentizace, uskutečnění autentizace, schválení přístupu a účtování přístupů. Kombinace určitým způsobem řetězených nebo vložených transakcí protokolu ACP umožňují realizovat libovolně složitá schémata řízení přístupu. Cílem tohoto článku je prezentovat možnosti univerzálního rámce řízení přístupu na několika aplikacích. 1 Úvod Současné systémy řízení přístupu v počítačových sítích (např. systémy podle standardu RADIUS, IEEE 802.1X, Kerberos, OpenID atd.) jsou velmi různorodé. Specializují se na jediný scénář přístupu a ke komunikaci využívají jediný přenosový protokol. Důsledkem uvedených okolností je skutečnost, že nejsou schopny vzájemné spolupráce. Možným řešením uvedených problémů je univerzální rámec řízení přístupu [1], který je založen na myšlence, že všechna zařízení počítačové sítě jsou vybavena tzv. portály řízení přístupu. Portál řízení přístupu je součást operačního systému, která řídí přístup jiných zařízení k aktivům daného zařízení nebo vyjednává přístup aplikací z daného zařízení k aktivům jiných zařízení. Ke komunikaci mezi portály byl navržen dvoustranný protokol ACP [2]. Zprávy tohoto protokolu umožňují sjednání požadovaných aktiv, sjednání metody autentizace, uskutečnění autentizace, schválení přístupu a účtování přístupů. Kombinace určitým způsobem řetězených nebo vložených transakcí protokolu ACP umožňují realizovat libovolně složitá schémata řízení přístupu. Cílem tohoto článku je prezentovat výzkumníkům a vývojovým specialistům možnosti zmiňovaného rámce řízení přístupu. V následujících kapitolách je stručně popsán protokol ACP a dvě možné aplikace univerzálního rámce řízení přístupu. První aplikací je řízení přístupu osob z cizích organizací do prostorů tzv. domácí organizace a druhou aplikací je elektronický platební systém pro drobné nákupy. V závěru článku je uvedeno stručné shrnutí univerzálního rámce řízení přístupu a jsou zhodnoceny jeho možnosti. 2 Protokol ACP Protokol ACP (Access Control Protocol) je univerzální dvoustranný protokol určený pro řízení přístupu k aktivům. Strana, která požaduje přístup k aktivům, se nazývá Žadatel a strana, která tato aktiva poskytuje se nazývá Poskytovatel. Jeden kompletní běh protokolu ACP, tj. postupnost zpráv mezi Žadatelem a Poskytovatelem, která souvisí s řízením přístupu k požadovaným aktivům, se nazývá transakce. Formát zpráv protokolu ACP je uveden na obr. 1 Code Identifier Length AVP 1... AVP n Obr. 1: Formát zpráv protokolu ACP. Záhlaví zprávy protokolu ACP sestává z následujících polí: Code (1 oktet): Toto pole určuje typ zprávy (viz dále). Identifier (3 oktety): Toto pole identifikuje konkrétní transakci v daném spoji. Length (3 oktety): Toto pole udává celkovou délku zprávy v oktetech. Zbytek zprávy sestává z n bloků AVP (Attribute-Value Pair), kde n = 0, 1, 2,... Formát bloku AVP uvádí obr. 2. Type Length Value Obr. 2: Formát bloku AVP. Blok AVP sestává z následujících polí: Type (1 oktet): Toto pole určuje typ AVP, tj. atribut (např. výsledek autentizace, zpráva EAP atd.). Length (1 nebo 2 oktety): Toto pole určuje délku pole Value v oktetech. Value (maximálně oktetů): Toto pole obsahuje hodnotu atributu. Kapacita tohoto pole postačuje pro přenos celých zpráv EAP, kryptografických certifikátů, fotografií osob atd. V návrhu internetového standardu [2] je definována řada různých typů AVP. Jedná se o jména entit, adres zařízení, kódy metod, kódy aktiv, kryptografická primitiva apod. Lze tak jimi vytvářet široké spektrum variant řízení přístupu. Navíc je návrh standardu otevřený a tak je možné definovat další typy AVP podle potřeb konkrétní aplikace. V protokolu ACP je definováno šest typů zpráv: 37 1
2 Start. Tato zpráva zahajuje novou transakci. Odesílatelem této zprávy je vždy Žadatel. Zpráva Start může obsahovat kód požadovaného aktiva (pokud Žadatel tento kód zná) i typ autentizace (pokud Žadatel zná typ autentizace, kterou Poskytovatel pro dané aktivum vyžaduje). Finish. Tato zpráva ukončuje transakci a odesílatelem této zprávy je vždy Poskytovatel. Zpráva Finish obsahuje oznámení pro Žadatele, případné další údaje nebo samotné aktivum (např. digitálně podepsaný výsledek autentizace). Offer. Tato zpráva je vždy odesílána Poskytovatelem a obsahuje nabídku dostupných aktiv nebo nabídku autentizací, které jsou pro dané aktivum Poskytovatelem požadovány. Specification. Tato zpráva je vždy odesílána Žadatelem jako reakce na zprávu Offer. Zpráva obsahuje Žadatelovu volbu z nabízených aktiv nebo autentizačních metod. Request. Tyto zprávy jsou odesílány Poskytovatelem a jsou užity k autentizaci. Autentizaci začíná vždy Poskytovatel. Response. Tyto zprávy jsou odesílány Žadatelem a jsou užity k autentizaci. Elementární transakci protokolu ACP ilustruje Tab. 1. V prvním sloupci tabulky jsou uvedeny zprávy, které odesílá Žadatel. Druhý sloupec tabulky uvádí zprávy odeslané Poskytovatelem a třetí sloupec je věnován poznámkám. Každý řádek tabulky reprezentuje jeden krok protokolu ACP. Tab. 1: Schéma elementární transakce protokolu ACP. Žadatel Poskytovatel Poznámky Start Specification Specification Response Offer Offer Request Finish Zahájení transakce. Zahajuje vždy Žadatel. Sjednání požadovaného aktiva. Pokud Žadatel požadované aktivum uvede ve zprávě Start nebo existuje jediná možnost, tak může být vynecháno. Sjednání typu autentizace. Pokud Žadatel příslušný typ autentizace uvede ve zprávě Start, tak může být vynecháno. Výměna autentizačních zpráv. Podle typu autentizace může být dvojic Request - Response více. Oznámení Poskytovatele o schválení přístupu a o ukončení transakce. Transakce protokolu ACP mohou být redukovány. Výměna dvojic zpráv Offer-Specification není nutná, pokud Žadatel požadované aktivum i příslušnou autentizační metodu uvede ve zprávě Start. Lze rovněž vypustit výměnu zpráv Request - Response pokud Žadatel i Poskytovatel jsou koncovými uzly bezpečného kanálu (např. kanálu TLS [3]). Důvodem je skutečnost, že autentičnost protější strany je zaručena autentizací provedenou v rámci vybudování bezpečného kanálu. V takovém případě lze transakci ACP redukovat pouze na výměnu zpráv Start a Finish. Takto redukovanou transakci protokolu lze například použit ke komunikaci mezi jednotlivými prvky systému řízení přístupu. Stejný přístup lze využít i pro účtování. Na jedné transakci se podílejí vždy pouze dva portály (tj. dvě zařízení), avšak na řízení přístupu se mohou podílet i další zařízení. Pro zahrnutí více zařízení existují dvě možnosti. První možností je sekvenční zřetězení více transakcí. V takovém případě Žadatel v transakci získá nějaká aktiva (např. podepsaný výsledek autentizace) a tato aktiva použije v následující transakci. Druhou možností jak do řízení přístupu zahrnout více zařízení je vložení nové transakce do již probíhající transakce.v tomto případě musí být k ukončení nějaké dřívější transakce nejprve uskutečněna nová transakce. Příkladem je situace, kdy Poskytovatel otevře novou transakci k externímu autentizátoru, aby autentizoval Žadatele (viz obr. 3). Na tomto obrázku je Žadatelem Uzel 1 a Poskytovatelem je Uzel 2. Uzel 1 pošle Uzlu 2 zprávu Start 1. Tato zpráva zahájí Transakci 1. Zpráva Start 1 obsahuje požadované aktivum a příslušný typ autentizace a proto se výměna zpráv Offer a Specification neuskuteční. Nyní musí být autentizován Uzel 1, avšak Uzel 2 nezná verifikační faktor Uzlu 1 a proto tuto autentizaci nemůže provést. Z tohoto důvodu Uzel 2 vybuduje bezpečný kanál TLS k příslušnému autentizátoru, kterým je v tomto případě Uzel 3. V průběhu budování kanálu TLS se Uzel 2 a Uzel 3 navzájem autentizují. Uzel 2 zahájí ve vybudovaném kanálu TLS vůči Uzlu 3 Transakci 2. Požadovaným aktivem této transakce je provedení autentizace Uzlu 1, Žadatelem je Uzel 2 a Poskytovatelem je Uzel 3. Zpráva Start 2 rovněž obsahuje požadované aktivum a příslušný typ autentizace a proto se výměna zpráv Offer a Specification neuskuteční. Uzel 3 proto hned zahájí autentizaci vysláním zprávy Request 2. Uzel 2 vyjme příslušná AVP z této zprávy a odešle je ve zprávě Request 1, která je zprávou Transakce 1. Uzel 1 vypočítá autentizační odpověď a tuto odpověď odešle do Uzlu 2 ve zprávě Response 1. Uzel 2 z této zprávy vyjme příslušná AVP a odešle je ve zprávě Response 2, která je zprávou Transakce 2. Uzel 3 provede autentizační výpočty a výsledek autentizace zašle ve zprávě Finish 2. Tato zpráva současně ukončuje Transakci 2. Uzel 2 na základě výsledku autentizace rozhodne o přístupu k požadovanému aktivu a toto rozhodnutí je zasláno Uzlu 1 ve zprávě Finish 1. Uzel 1 Uzel 2 Uzel 3 Start 1 Start 2 Request 1 Response 1 Finish 1 Request 2 Response 2 Finish 2 1. transakce 2. transakce Obr. 3: Princip vložení transakce. 37 2
3 3 Řízení přístupu osob Prvním příkladem využití univerzálního rámce řízení přístupu je systém řízení přístupu osob do areálů nebo budov. Stávající systémy umožňují řídit přístup osob patřících do dané organizace [4]. Tato tzv. domácí organizace v praxi spolupracuje s řadou dalších organizací (tzv. cizí organizace) a přitom se často požaduje, aby pracovníci cizích organizací měli přístup do vybraných prostorů domácí organizace (úklid, pravidelný servis apod.). Soudobé přístupové systémy však s přístupovými systémy jiných organizací nedokáží spolupracovat. Proto je nutné přístup osob z cizích organizací řešit jiným způsobem. Nejčastěji jejich autentizací provádí ostraha domácí organizace nebo jsou jim dočasně vydány autentizační předměty (např. přístupové karty). Uvedená řešení jsou však rigidní a obsahují bezpečnostní rizika. Navrhovaný systém je postaven na spolupráci přístupových systémů domácí i cizí organizace. Základní strukturu navrženého řešení ilustruje obr. 4. Obr. 4: Systém řízení přístupu do domácí organizace. Osoba X cizí organizace je vybavena bezkontaktní autentizační kartou Z. U vstupu do prostor domácí organizace se nachází dveřní terminál A, který je vybaven čtečkou autentizačních karet a zároveň je připojen prostřednictvím lokální sítě LAN k přístupovému serveru B domácí organizace. Tento server má přístup na Internet a může proto komunikovat s přístupovým serverem Y cizí organizace. Autentizační karta Z, dveřní terminál A a také oba přístupové servery B i Y obsahují portál. Zprávy protokolu ACP mezi kartou Z a terminálem A se přenášejí bezdrátovým kanálem podle standardu ISO Zprávy mezi A - B a mezi B - Y se přenášejí v kanálu TLS. Kanál TLS mezi A a B je trvalý. Kanál TLS mezi B a Y může být podle frekvence přístupů buď trvalý nebo dočasný. Dočasný kanál se buduje pro každý jednotlivý přístup. Zprávy protokolu ACP přenášené v kanálech TLS jsou považovány za autentické, protože v rámci budování kanálu TLS došlo k ověření identity protistrany. Předpokládejme, že bezpečnostní správci obou organizací se dohodli na autentizační metodě typu výzva-odpověď. Bezpečnostní správce cizí organizace vydal osobě X ze své organizace autentizační kartu Z, která obsahuje identifikátor karty X@Y a tajný klíč K X. Stejné údaje jsou uloženy rovněž v serveru Y. Princip navrhovaného řešení systému řízení přístupu spočívá v tom, že autentizaci osob z domácí organizace provádí server B a autentizaci osob z cizí organizace provádí server Y. Komunikaci související s řízením přístupu osoby z cizí organizace ilustruje obr. 5. Obr. 5: Komunikace k řízení přístupu do domácí organizace. První transakce probíhá mezi kartou Z a terminálem A. Aby držitel karty nemusel svoji kartu držet u čtečky po celou dobu řízení přístupu, tak účelem této transakce je získat údaje pro následnou autentizaci, kterou provede buď server B nebo Y. Ve zprávě Start 1 uvede karta svůj identifikátor X@Y (AVP typu NAME_SUP_G). Protože aktivum je v tomto případě jediné (otevření dveří) a autentizační metoda je předem dána, tak jsou vynechány výměny zpráv typu Offer Specification. Terminál proto v reakci na zprávu Start 1 vyšle zprávu Request 1, kde je uvedena náhodná výzva R (AVP typu INIT). Karta pomocí tajného klíče K X vypočítá odpověď W = f(r, K X ) a odešle ji ve zprávě typu Response 1 (AVP typu HMAC). Terminál popsanou transakci uzavře zprávou Finish 1. Druhá transakce proběhne mezi terminálem A a serverem domácí organizace B. Terminál ve zprávě Start 2 vyšle informace potřebné pro autentizaci držitele karty. Zpráva bude obsahovat identifikátor terminálu (AVP typu NAME_SUP_L), kód aktiva, kterým je žádost o autentizaci (AVP typu AS- SET_G), identifikátor autentizovaného, kterým je řetězec X@Y (AVP typu NAME_ENT_G), výzvu R (INIT) a odpověď na výzvu W (HMAC). Server z identifikátoru autentizovaného zjistí, že držitel karty náleží do cizí organizace a proto zahájí třetí transakci k serveru Y. Zpráva Start 3 bude obsahovat identifikátor domácího autentizačního serveru (AVP typu NAME_SUP_G), kód aktiva, kterým je žádost o autentizaci (AVP typu ASSET_G), identifikátor autentizovaného, kterým je řetězec X@Y (AVP typu NAME_ENT_G), výzvu R (INIT) a odpověď na výzvu W (HMAC). Portál serveru Y provede vlastní výpočet odpovědi W a porovná ji s přijatou odpovědí. Pokud W = W, tak autentizovaná osoba disponuje autentizační kartou s klíčem K X, tj. jedná se o kartu osoby X. Ve zprávě Finish 3 server Y uvede výsledek autentizace (AVP typu RE- SULT) a tím je třetí transakce ukončena. Server B na základě výsledku autentizace rozhodne o tom, zda zůstanou dveře zavřené, či se mají otevřít. Toto rozhodnutí (AVP typu RE- SULT) je předáno terminálu A ve zprávě Finish 2, kterou je zároveň ukončena i druhá transakce. Jak již bylo uvedeno, výhodou popsaného řešení je možnost spolupráce přístupových systémů různých organizací. Využívá se přitom výhoda jednotného protokolu pro výměnu zpráv souvisejících s řízením přístupu. 37 3
4 4 Drobné elektronické platby Dalším příkladem možností univerzálního rámce řízení přístupu je systém drobných elektronických plateb. Tento systém by měl uživatelům umožnit provádět drobné on-line platby, jako je například koupě elektronické jízdenky městské hromadné dopravy, koupě vstupenky do muzea, platba za parkování apod. V navrhovaném systému jsou do sítě připojeny portály bank a zainteresovaných prodejců. Uživatelé jsou vybaveni vhodnými komunikačními zařízeními (např. chytrý telefon, ipad apod.). Tato komunikační zařízení (dále komunikátory) disponují vlastním portálem. Uživatel dostane při založení svého účtu u banky dva tajné klíče. Klíč K E je určen k šifrování zpráv mezi portálem banky (B) a portálem komunikátoru (K) a klíč K A je určen k autentizaci zpráv vyměňovaných mezi B a K. V navrhovaném systému dále předpokládáme komunikační systém podle obr. 6. V tomto systému portály bank B a portály prodejců P komunikují přes počítačovou síť prostřednictvím dočasných nebo trvalých spojů typu TLS. Jejich vzájemná komunikace je tímto způsobem utajená a autentizovaná. Komunikace mezi portály komunikátorů K a portály bank B je zajištěna stejnou počítačovou sítí, do které mají komunikátory přístup prostřednictvím přístupových bodů AP. Bezdrátové spojení mezi komunikátorem a AP může být řešeno podle standardu IEEE Přístupové body v tomto případě nemusí zajišťovat utajení ani autentičnost přenášených dat. Komunikátorům je dovolena pouze komunikace s portály bank a jen pomocí protokolu ACP. Tím je zajištěno, že platební komunikační systém nebude zneužíván uživateli pro účely surfování apod. Obr. 6: Komunikační systém pro drobné elektronické platby. Nyní si popíšeme možné řešení komunikace. Předpokládejme, že uživatel si chce zakoupit elektronickou jízdenku do prostředku místní hromadné dopravy (MHD). Prodejcem P tedy bude portál serveru příslušného podniku MHD. Uživatel si prostřednictvím svého komunikátoru vybere jeden z dosažitelných přístupových bodů. S ním zahájí komunikaci ilustrovanou na obr. 7. Protože portál AP funguje v navrhovaném řešení pouze jako tranzitní uzel, tak na obrázku uveden není. Ve zprávě Start 1 komunikátor uvádí AVP, ze kterých lze zjistit identifikátor banky B (AVP typu NAME_PRO_G) a identifikátor komunikátoru K (AVP typu NAME_SUP_L). Portál AP si ověří, že se jedná o zprávu protokolu ACP. Pokud je identifikátor banky na seznamu povolených příjemců, tak zprávu Start 1 této bance odešle. Portál banky ze zprávy Start 1 zjistí, že s ním byla zahájena nová transakce. Podle identifikátoru K zjistí potřebné klíče K E a K A. Portál B zašle zpět zprávu Offer 1,1, ve které nabízí dostupná aktiva (AVP typu ASSET_L_TX). Mimo jiné je zde uvedena možnost koupě jízdenky MHD. Uživateli se na obrazovce jeho komunikátoru objeví nabízená aktiva. Vybere si aktivum koupě jízdenky MHD a portál K zašle do B zprávu Specification 1,1, ve které je toto aktivum uvedeno (AVP typu ASSET_L). Portál B vyšle další zprávu Offer 1,2, ve které nabízí jednotlivé typy jízdenek podle ceny (opět AVP typu ASSET_L_TX). Uživateli se na obrazovce komunikátoru objeví nabídka jízdenek podle ceny. Dejme tomu, že si vybere jízdenku MHD v ceně X Kč. Tuto informaci portál K zašle do B ve zprávě Specification 1,2 (opět AVP typu ASSET_L). Tím proběhlo sjednání aktiva. Obr. 7: Komunikace k nákupu elektronické jízdenky. Nyní je zapotřebí uskutečnit autentizaci komunikátoru. Předpokládejme, že v popisovaném případě je v portálech přednastaven jediný typ autentizace a tak je sjednání typu autentizace vynecháno a přikročí se okamžitě k autentizaci. Portál B odešle zprávu Request 1, která pro kontrolu obsahuje vybrané aktivum (ASSET_L_TX) a náhodné číslo (AVP typu INIT). Zřetězení kódu aktiva a náhodného čísla nazveme výzva R. Uživatel zkontroluje, zda se skutečně jedná o požadované aktivum a vydá příkaz k prokázání identity. Komunikátor zašle ve zprávě Response 1 odpověď W = f(r, K A ), což je autentizační kód (AVP typu HMAC), který přísluší výzvě R. Portál B provede vlastní výpočet odpovědi W a porovná ji s přijatou odpovědí. Pokud W = W, tak komunikátor zná autentizační klíč K A majitele příslušného bankovního účtu. Tím byla provedena autentizace uživatele a zároveň ověřena i jeho volba. Portál B nyní zahájí transakci s portálem P, jejímž cílem je koupě jízdenky MHD v ceně X Kč. Předpokládáme, že mezi P a B existuje kanál TLS, takže spojení mezi touto dvojicí je utajené a autentizované. Portál B zašle do P zprávu Start 2, kterou zahajuje novou transakci. V této zprávě žádá o zaslání požadované jízdenky (ASSET_L). Portál P ve zprávě Finish 2 tuto jízdenku zašle (AVP typu PROVE). Tím tato transakce mezi B a P končí. Provozovatel portálu P důvěřuje provozovateli portálu B a proto předpokládá, že cena jízdenky (X Kč) bude v nejbližším zúčtovacím termínu bankou převedena z účtu uživatele na jeho účet. Portál B jízdenku zašifruje klíčem K E a ve zprávě Finish 1 (AVP typu ENC) ji odešle portálu K. Tím je zároveň ukončena také první transakce. Komunikátor jízdenku klíčem K E dešifruje a uživatel se jí bude moci v dopravním prostředku prokázat. 37 4
5 Popsanou komunikaci lze zjednodušit tak, že pokud si komunikátor z předchozích transakcí bude ukládat kódy aktiv, tak uživatel si bude moci aktivum vybrat ještě před zahájením transakce. Zpráva Start 1 bude ještě navíc obsahovat kód vybraného aktiva a obě výměny zpráv Offer - Specification bude možné vynechat. Popsané řešení je jedno z mnoha. Samozřejmě existují další varianty řešení, kdy mohou být použity jiné autentizační metody a jiné kryptografické metody. Mohou být rovněž použity i jiné scénáře. Ve všech těchto případech však pokaždé vystačíme s konceptem portálů, které navzájem komunikují prostřednictvím zpráv protokolu ACP. Oproti stávajícímu řešení SMS jízdenek je navržené řešení poněkud složitější, avšak na druhou stranu je univerzálnější. Stávající systémy SMS jízdenek nedovolují interaktivní volbu aktiv a k autentizaci lze používat pouze metodu, která je v mobilních telefonech standardizovaná. Výše popsané řešení dovoluje interaktivní volbu aktiv a také volbu typu autentizační metody. Provozovatelé systému drobných plateb tak nejsou omezeni na nějaký konkrétní komunikační systém ani na autentizační metodu v něm implementovanou. [4] Burda K., Strašil I.: Univerzální rámec pro přístupové systémy. In Bezpečnostní technologie, Systémy a Management Univerzita Tomáše Bati ve Zlíně, s Závěr V článku je stručně popsán univerzální rámec pro řízení přístupu. Principem tohoto rámce je skutečnost, že každé síťové zařízení je vybaveno portálem, který řídí přístup k aktivům daného zařízení a současně vyjednává pro aplikace daného zařízení přístup k aktivům jiných zařízení. Výhodou tohoto řešení je skutečnost, že portály spolu komunikují jednotným protokolem ACP, který jim umožňuje sjednání požadovaných aktiv, sjednání metody autentizace, uskutečnění autentizace, schválení přístupu i účtování přístupů. Transakce protokolu ACP lze vzájemně vázat a vytvářet tak prakticky libovolně složitá schémata řízení přístupu. V článku byly prezentovány dva příklady využití univerzálního rámce řízení přístupu. První příklad ilustroval možnost spolupráce přístupových systémů do areálů různých organizací. Druhý příklad prezentoval možnosti sjednávání podmínek a parametrů přístupu spolu s možností aplikace obecného systému řízení přístupu jako platebního systému. Oba uvedené příklady ilustrovaly univerzalitu navrženého řešení a pestrou škálu jeho aplikací. Z tohoto důvodu se popsaný univerzální rámec řízení přístupu jeví slibným řešením pro budoucnost. Literatura [1] Burda K.: Univerzální rámec pro řízení přístupu v počítačových sítích. Elektrorevue - Internetový časopis, roč. 2011, č. 9, s Dostupné online: < [2] Burda K., Strasil I., Pelka T., Stancik P.: Access Control Protocol (ACP). IETF, Fremont Dostupné online: < [3] Dierks T., Rescorla E.: The Transport Layer Security (TLS) Protocol. [RFC 5246]. IETF, Fremont Dostupné online: < 37 5
Řízení přístupu v počítačových sítích
Řízení přístupu v počítačových sítích Karel Burda Fakulta elektrotechniky a komunikačních technologií VUT v Brně Email: burda@feecvutbrcz Abstrakt Článek rozšiřuje teorii řízení přístupu Je v něm upřesněna
VíceBezpečnost elektronických platebních systémů
Katedra matematiky, Fakulta jaderná a fyzikálně inženýrská, České vysoké učení technické v Praze Plán Platby kartou na terminálech/bankomaty Platby kartou na webu Internetové bankovnictví Platby kartou
VíceSSL Secure Sockets Layer
SSL Secure Sockets Layer internetové aplikační protokoly jsou nezabezpečené SSL vkládá do architektury šifrující vrstvu aplikační (HTTP, IMAP,...) SSL transportní (TCP, UDP) síťová (IP) SSL poskytuje zabezpečenou
VíceBezpečnost internetového bankovnictví, bankomaty
, bankomaty Filip Marada, filipmarada@gmail.com KM FJFI 15. května 2014 15. května 2014 1 / 18 Obsah prezentace 1 Bezpečnost internetového bankovnictví Možná rizika 2 Bankomaty Výběr z bankomatu Možná
Více1 Pro účely této vyhlášky se rozumí a) základnovou stanicí základnová stanice veřejné komunikační sítě,
Částka 133 Sbírka zákonů č. 357 / 2012 Strana 4733 357 VYHLÁŠKA ze dne 17. října 2012 o uchovávání, předávání a likvidaci provozních a lokalizačních údajů Ministerstvo průmyslu a obchodu v dohodě s Ministerstvem
VíceProjekt: 1.5, Registrační číslo: CZ.1.07/1.5.00/ Digitální podpisy
VY_32_INOVACE_BEZP_08 Projekt: 1.5, Registrační číslo: CZ.1.07/1.5.00/34.0304 Digitální podpisy Základní myšlenkou elektronického podpisu je obdoba klasického podpisu, jež má zaručit jednoznačnou identifikaci
Vícembank.cz mtransfer Okamžitá notifikace o mtransferu Dokumentace pro externího partnera
mtransfer Okamžitá notifikace o mtransferu Dokumentace pro externího partnera 1/6 Obsah 1 SLOVNÍK POJMŮ... 3 2 ÚVOD... 4 3 POPIS ŘEŠENÍ NPM... 4 4 ZPŮSOB KOMUNIKACE EXTERNÍHO PARTNERA S MBANK - SPECIFIKACE
VíceVYSOKÉ UČENÍ TECHNICKÉ V BRNĚ
VYSOKÉ UČENÍ TECHNICKÉ V BRNĚ BRNO UNIVERSITY OF TECHNOLOGY FAKULTA ELEKTROTECHNIKY A KOMUNIKAČNÍCH TECHNOLOGIÍ ÚSTAV TELEKOMUNIKACÍ FACULTY OF ELECTRICAL ENGINEERING AND COMMUNICATION DEPARTMENT OF TELECOMMUNICATIONS
Víceeobčan a egovernment ISSS 2013 Petr Mayer Atos IT Solutions and Services, s.r.o.
eobčan a egovernment ISSS 2013 Petr Mayer Atos IT Solutions and Services, s.r.o. eobčan a egovernment Elektronická identifikace občana I. Vize Atos MyCity II. Stav ID dokladů v Evropě III. Stav ID dokladů
VíceVYSOKÉ UČENÍ TECHNICKÉ V BRNĚ
VYSOKÉ UČENÍ TECHNICKÉ V BRNĚ BRNO UNIVERSITY OF TECHNOLOGY FAKULTA ELEKTROTECHNIKY A KOMUNIKAČNÍCH TECHNOLOGIÍ ÚSTAV TELEKOMUNIKACÍ FACULTY OF ELECTRICAL ENGINEERING AND COMMUNICATION DEPARTMENT OF TELECOMMUNICATIONS
VíceProtokol TELNET. Schéma funkčních modulů komunikace protokolem TELNET. Telnet klient. login shell. Telnet server TCP/IP.
Protokol TELNET Schéma funkčních modulů komunikace protokolem TELNET Telnet klient Telnet server login shell terminal driver Jádro TCP/IP TCP/IP Jádro Pseudo terminal driver Uživatel u terminálu TCP spojení
VíceISMS. Autentizace ve WiFi sítích. V Brně dne 5. a 12. prosince 2013
ISMS Případová studie Autentizace ve WiFi sítích V Brně dne 5. a 12. prosince 2013 Pojmy Podnikové WiFi sítě Autentizace uživatelů dle standardu 802.1X Hlavní výhodou nasazení tohoto standardu je pohodlná
VícePEPS, NIA a mojeid. Budoucnost elektronické identity. Jaromír Talíř
PEPS, NIA a mojeid Budoucnost elektronické identity Jaromír Talíř jaromir.talir@nic.cz 03.12.2016 Obsah Přeshraniční autentizace Projekt STORK, nařízení eidas a CZ.PEPS Elektronická identita v ČR NIA a
VíceAndrew Kozlík KA MFF UK
Autentizační kód zprávy Andrew Kozlík KA MFF UK Autentizační kód zprávy Anglicky: message authentication code (MAC). MAC algoritmus je v podstatě hashovací funkce s klíčem: MAC : {0, 1} k {0, 1} {0, 1}
VíceSpecifikace rozhraní. Oznamovací povinnost podle zákona č. 307/2013 Sb., ve znění pozdějších předpisů. Martin Falc, SW architekt.
C E R T I C O N www.certicon.cz V Á C L A V S K Á 1 2 1 2 0 0 0 P R A H A 2 Specifikace rozhraní Oznamovací povinnost podle zákona č. 307/2013 Sb., ve znění pozdějších předpisů Martin Falc, SW architekt
VíceManuál pro implementaci služby PLATBA 24. Datum: 17. prosince 2014 Verze: 1.49
Manuál pro implementaci služby PLATBA 24 Datum: 17. prosince 2014 Verze: 1.49 1 Úvodní informace ke službě PLATBA 24... 3 1.1 Obecný popis služby... 3 1.2 Administrativní předpoklady k využití služby PLATBA
VíceObchodní podmínky pro poskytnutí a užívání elektronického platebního prostředku
Obchodní podmínky pro poskytnutí a užívání elektronického platebního prostředku platné od 12.12.2016 pro dříve uzavřené smlouvy platné od 1.3.2017 Článek I Předmět úpravy Českomoravská záruční a rozvojová
VícePrezentace platebního systému PAIMA
Prezentace platebního systému PAIMA Ing. Vlastimil Beneš 19.5.2011 SmartCard Forum 2011 1 Obsah prezentace Základní vlastnosti Architektura Proč DESFire Použití SAM Závěr 19.5.2011 SmartCard Forum 2011
VíceUŽIVATELSKÝ MANUÁL. pro 485COM FW 2.x (MODBUS)
pro 485COM FW 2.x (MODBUS) Obsah Obsah 3 1. Instalace 4 1.1 Podpora operačních systémů 4 1.2 Podpora USB modemů 4 1.3 Instalace USB modemu 4 1.4 Instalace aplikace 4 2. Nastavení 5 2.1 Nastavení jazykové
VícePředstavíme základy bezdrátových sítí. Popíšeme jednotlivé typy sítí a zabezpečení.
10. Bezdrátové sítě Studijní cíl Představíme základy bezdrátových sítí. Popíšeme jednotlivé typy sítí a zabezpečení. Doba nutná k nastudování 1,5 hodiny Bezdrátové komunikační technologie Uvedená kapitola
VíceJe to SMTP a POP3 server který spolupracuje s GSM branami Alphatech. Převádí SMS zprávy na emaily a emaily na SMS zprávy.
SMS-Mail Je to SMTP a POP3 server který spolupracuje s GSM branami Alphatech. Převádí SMS zprávy na emaily a emaily na SMS zprávy. Z čeho se systém s programem SMS-Mail skládá : GSM brána Datové propojení
VíceCASE MOBILE MOBIL JAKO AUTENTIZAČNÍ TOKEN
CASE MOBILE MOBIL JAKO AUTENTIZAČNÍ TOKEN APLIKACE CASE MOBILE PŘINÁŠÍ KOMFORTNÍ A BEZPEČNOU DVOUFAKTOROVOU AUTENTIZACI Z MOBILNÍHO ZAŘÍZENÍ. BEZPEČNĚ SE PŘIHLÁSÍTE, AUTORIZUJETE TRANSAKCI, ELEKTRONICKY
VícePříručka pro dodavatele. Systém EZVR 1.1 Verze dokumentu 1.3 Datum vydání:
Příručka pro dodavatele Systém EZVR 1.1 Verze dokumentu 1.3 Datum vydání: 1.10.2017 1 2 1. Úvod do systému...3 2. Technické požadavky a zabezpečení systému...3 3. Registrace nového dodavatele...4 4. Přihlášení
VícePostup nastavení bezpečné E-mailové schránky pro zákazníky Logicentra
Postup nastavení bezpečné E-mailové schránky pro zákazníky Logicentra Důvod přidělování speciálních schránek. Podle posledních statistik kolem 90 % všech E-mailů na Internetu tvoří nevyžádaná pošta. Patří
VíceProtokol TELNET. Schéma funkčních modulů komunikace protokolem TELNET. Telnet klient. login shell. Telnet server TCP/IP TCP/IP.
Protokol TELNET Schéma funkčních modulů komunikace protokolem TELNET Telnet klient Telnet server login shell terminal driver Operační systém TCP/IP TCP spojení TCP/IP Pseudo terminal driver Operační systém
VíceProtokol pro zabezpečení elektronických transakcí - SET
Protokol pro zabezpečení elektronických transakcí - SET Ing. Petr Číka Vysoké učení technické v Brně, Fakulta elektrotechniky a komunikačních technologií, Ústav telekomunikací, Purkyňova 118, 612 00 Brno,
VíceTECHNICKÁ SPECIFIKACE VEŘEJNÉ ZAKÁZKY
Příloha č. 3 k č.j. MV-159754-3/VZ-2013 Počet listů: 7 TECHNICKÁ SPECIFIKACE VEŘEJNÉ ZAKÁZKY Nové funkcionality Czech POINT 2012 Popis rozhraní egon Service Bus Centrální Místo Služeb 2.0 (dále jen CMS
VícePLATEBNÍ KARTY PPF banky a.s.
PLATEBNÍ KARTY PPF banky a.s. PPF banka a.s., Evropská 2690/17, P.O. Box 177, 160 41 Praha 6 1/14 Obsah: 1. Všeobecné informace...3 2. Placení prostřednictvím Karty na internetu...3 3. 3D Secure...4 3.1.
VíceRegistrační číslo projektu: CZ.1.07/1.5.00/34.0553 Elektronická podpora zkvalitnění výuky CZ.1.07 Vzděláním pro konkurenceschopnost
Registrační číslo projektu: CZ.1.07/1.5.00/34.0553 Elektronická podpora zkvalitnění výuky CZ.1.07 Vzděláním pro konkurenceschopnost Projekt je realizován v rámci Operačního programu Vzdělávání pro konkurence
VíceERP-001, verze 2_10, platnost od
ERP-001, verze 2_10, platnost od 2010.08.01. ELEKTRONICKÉ PŘEDEPISOVÁNÍ HUMÁNNÍCH LÉČIVÝCH PŘÍPRAVKŮ ERP-001.pdf (208,89 KB) Tímto technickým dokumentem jsou, v souladu s 80 zákona č. 378/2007 Sb., o léčivech
VíceJednotný identitní prostor Provozní dokumentace
Jednotný identitní prostor Provozní dokumentace Vytvořeno dne: 21. 2. 2012 Aktualizováno: 23. 5. 2017 Verze: 1.2 2017 MVČR Obsah 1. Úvod... 3 1.1. Účel provozní dokumentace... 3 1.2. Související dokumenty...
VícePopis nejčastějších funkčností v aplikaci MojeBanka
Tento dokument popisuje následující funkčnosti aplikace. Kliknutím na odkaz vyberte příslušnou kapitolu. zadání tuzemského příkazu v úhradě v CZK zadání zahraniční platby ověření stavu odeslané transakce
VíceCCNA I. 3. Connecting to the Network. CCNA I.: 3. Connecting to the network
CCNA I. 3. Connecting to the Network Základní pojmy Konvergence sítí (telefony, TV, PC, GSM) SOHO (Small Office and Home Office) nabídka a prodej produktů evidence objednávek komunikace se zákazníky zábava
VíceSdělení informací o poplatcích
Sdělení informací o poplatcích Název poskytovatele účtu: Waldviertler Sparkasse Bank AG Název účtu: Osobní účet Populár VIP Datum: 31.10.2018 Tento dokument obsahuje informace o poplatcích za používání
VíceEXTRAKT z technické normy ISO
EXTRAKT z technické normy ISO Extrakt nenahrazuje samotnou technickou normu, je pouze informativním materiálem o normě. Inteligentní dopravní systémy Kooperativní ITS Zkušební architektura ISO/TS 20026
VícePopis nejpoužívanějších funkčností aplikace MojeBanka
OBSAH Kliknutím na text Zadání tuzemského příkazu k úhradě v CZK... se rychle 2 dostanete na Vyplnění formuláře... požadovanou 3 stránku Autorizace... 4 Zadání zahraniční / SEPA platby... 5 Vyplnění formuláře...
Více1. 3. 2013. Akceptace karet v dopravě
1. 3. 2013 Akceptace karet v dopravě Platba v dopravě bezkontaktní kartou ČSOB ve spolupráci s DP města Liberec a Jablonec a DP Brno zprovoznila kiosky na prodej jízdenek pomocí bezkontaktní karty. Každá
VíceEXTRAKT z české technické normy
EXTRAKT z české technické normy Extrakt nenahrazuje samotnou technickou normu, je pouze informativním ICS 35.240.60 materiálem o normě. Dopravní telematika Vyhrazené spojení krátkého rozsahu (DSRC) Datová
VíceArchitektura odbavovacího systému s použitím BČK
Autor: Jindřich Borka, Jiří Matějec Architektura odbavovacího systému s použitím BČK ČD - Telematika a.s., Pernerova 2819/2a, 130 00 Praha 3 XT-Card a.s., Sokolovská 100, 186 00, Praha 8 Agenda ČD-Telematika
VíceObchodní podmínky pro poskytování Služeb přímého bankovnictví Equa bank a.s.
Stránka 1 z 7 Obchodní podmínky pro poskytování Služeb přímého bankovnictví Equa bank a.s. I. Úvodní ustanovení 1. Tyto Podmínky jsou obchodními podmínkami ve smyslu čl. I. bod 3 VOP vydané v souladu se
VíceKarta klienta Integrace agend zdravotních a sociálních
Karta klienta Integrace agend zdravotních a sociálních Jiří Schlanger Ministerstvo zdravotnictví ČR Vladimír Šiška Ministerstvo práce a sociálních věcí ČR ISSS 2011, 4.4.2011 Co je to Karta klienta? Karta
VíceNávod k nastavení EET v systému Kredit
Návod k nastavení EET v systému Kredit 1 Kancelář Zavedením EET se v Kanceláři 8 stávající funkčnosti nemění, pouze jsou rozšířené možnosti konfigurace číselníků a dle nastavení skupin klientů je vynuceno
VíceSlužba vzdáleného pečetění I.CA RemoteSeal. Ing. Roman Kučera První certifikační autorita, a.s
Služba vzdáleného pečetění I.CA RemoteSeal Ing. Roman Kučera První certifikační autorita, a.s. 5. 4. 2018 Hovořit budeme o splnění povinnosti veřejnoprávního podepisujícího danou 8 zákona č. 297/2016 Sb.:
VíceZadání příkazu k převodu do zahraničí a v cizí měně do tuzemska ve službě ČSOB BusinessBanking 24
Zadání příkazu k převodu do zahraničí a v cizí měně do tuzemska ve službě ČSOB BusinessBanking 24 Obsah 1. Příkaz k převodu do zahraničí... 2 1.1. Zadání příkazu k převodu do zahraničí... 2 1.2. Tvorba
VíceAdministrativní pokyny pro aplikaci Madridské dohody o mezinárodním zápisu známek a Protokolu k této dohodě. (ve znění platném k 1.
Administrativní pokyny pro aplikaci Madridské dohody o mezinárodním zápisu známek a Protokolu k této dohodě (ve znění platném k 1. lednu 2008) OBSAH První část: Definice Kapitola 1: Zkrácené výrazy,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,1
Vícebit/p6d-h.d 22. března
bit/pd-h.d 22. března 2003 Needham-Schroederův protokol... * základní varianta Needham a Schroeder 978 * zajímavý zejména z historických důvodů, protože je základem mnoha autentizačních protokolů a protokolů
VíceAdministrativní pokyny pro aplikaci Madridské dohody o mezinárodním zápisu známek a Protokolu k této dohodě
Administrativní pokyny pro aplikaci Madridské dohody o mezinárodním zápisu známek a Protokolu k této dohodě (ve znění platném k 1. listopadu 2017) Obsah První část - Definice... 2 Kapitola 1: Zkrácené
VícePopis nejčastějších funkcí aplikace MojeBanka business
Tento dokument popisuje následující funkčnosti aplikace MojeBanka. Kliknutím na odkaz vyberte příslušnou kapitolu. zadání jednorázového příkazu k úhradě zadání zahraniční platby odeslání dávkového příkazu
Více7. Aplikační vrstva. Aplikační vrstva. Počítačové sítě I. 1 (5) KST/IPS1. Studijní cíl. Představíme si funkci aplikační vrstvy a jednotlivé protokoly.
7. Aplikační vrstva Studijní cíl Představíme si funkci aplikační vrstvy a jednotlivé protokoly. Doba nutná k nastudování 2 hodiny Aplikační vrstva Účelem aplikační vrstvy je poskytnout aplikačním procesům
VíceElektronická komunikace s ČSSZ
Elektronická komunikace s ČSSZ Elektronická komunikace není ani v roce 2017 povinná. Nicméně je dobré být připraven a na elektronickou komunikaci se připravit. Elektronická komunikace v DUNA MZDY se týká
VíceDigitální identita Moderní přístup k identifikaci klienta. Pavel Šiška, Štěpán Húsek, Deloitte Digital - Technology Services
Digitální identita Moderní přístup k identifikaci klienta Pavel Šiška, Štěpán Húsek, Deloitte Digital - Technology Services Digitální identita Moderní přístup k identifikaci klienta za pomoci federované
VíceDokumentace. k modulu. podnikový informační systém (ERP) Datové schránky
Dokumentace k modulu podnikový informační systém (ERP) Nastavení datové schránky Datová schránka je elektronické úložiště, které je určené k doručování písemností státních institucí (orgánů veřejné moci)
VícePRO ZAJIŠTĚNÍ AŽ 50% ÚSPORY MULTIFUNKČNÍ VÝDEJNÍ AUTOMATY / / S DISTRIBUČNÍ APLIKACÍ IDS
9 PRO ZAJIŠTĚNÍ AŽ 50% ÚSPORY MULTIFUNKČNÍ VÝDEJNÍ AUTOMATY / / S DISTRIBUČNÍ APLIKACÍ IDS IDS APLIKACE IDS - INTEGRATED DISTRIBUTION SYSTEM Aplikace j možnost definovat, vytvářet a tisknout veškeré reporty
VíceModernizace odbavovacího a informačního systému MHD v Hradci Králové II.
VYSVĚTLENÍ ZADÁVACÍ DOKUMENTACE Č. 5 dle 98 zákona č. 134/2016 Sb., o zadávání veřejných zakázek k nadlimitní sektorové veřejné zakázce na dodávky s názvem: Modernizace odbavovacího a informačního systému
Více1.1. Základní informace o aplikacích pro pacienta
Registrace a aktivace uživatelského profilu k přístupu do aplikace systému erecept pro pacienta, přihlášení do aplikace systému erecept pro pacienta na základě registrovaného profilu v NIA nebo elektronického
VíceUŽIVATELSKÁ PŘÍRUČKA DUNA modul EET
OBSAH 1. ELEKTRONICKÁ EVIDENCE TRŽEB (EET)... 1 1.1. Nastavení EET... 1 1.2. Číselník Formy úhrad... 3 1.3. EET v agendě Kasa... 3 1.4. EET ve vystavených fakturách... 4 1.5. EET v pokladním dokladu...
VícePrezentace pro konferenci Smart city Brno
Prezentace pro konferenci Smart city Brno - Česká spořitelna, a.s. CHYTRÁ řešení v dopravě, Brno Vývoj odbavení cestujících Včera Dnes Zítra PAPÍROVÉ JÍZDENKY DOPRAVNÍ KARTY, SMS BANKOVNÍ KARTY, MOBILNÍ
VíceČESKÁ TECHNICKÁ NORMA
ČESKÁ TECHNICKÁ NORMA ICS 35.240.15 2003 Bankovnictví - Bezpečný přenos souborů (drobné obchody) ČSN ISO 15668 97 9120 Listopad Banking - Secure file transfer (retail) Banque - Transfert de fichier de
VíceBEZPEČNÁ SPRÁVA KLÍČŮ POMOCÍ HSM. Petr Dolejší Senior Solution Consultant
BEZPEČNÁ SPRÁVA KLÍČŮ POMOCÍ HSM Petr Dolejší Senior Solution Consultant OCHRANA KLÍČŮ A ZOKB Hlavní termín kryptografické prostředky Vyhláška 316/2014Sb. o kybernetické bezpečnosti zmiňuje: v 17 nástroj
VíceIdentifikátor materiálu: ICT-3-03
Identifikátor materiálu: ICT-3-03 Předmět Téma sady Informační a komunikační technologie Téma materiálu TCP/IP Autor Ing. Bohuslav Nepovím Anotace Student si procvičí / osvojí architekturu TCP/IP. Druh
Víceeidas odstartuje Německo Jaromír Talíř
eidas odstartuje Německo Jaromír Talíř jaromir.talir@nic.cz 24. 11. 2017 Obsah Vzájemné uznávání eid podle eidas Německá elektronická identifikace Nové německé eid systémy DomainID Verimi Vzájemné uznávání
VíceTechnická specifikace Platební brána IBS
Technická specifikace Platební brána IBS Verze 1 Strana 1 z 6 1. Obecné Platební brána je určena k platbě za zboží nebo služby nakoupené v internetovém obchodě, kdy uživatel je přesměrován na přihlašovací
VíceRegistrace a aktivace uživatelského profilu k přístupu do systému erecept pro pacienta
Registrace a aktivace uživatelského profilu k přístupu do systému erecept pro pacienta 1. Obecné 1.1. Základní informace o aplikacích pro pacienta Pro pacienty je zpřístupněná webová a mobilní aplikace.
VíceCeník pro úsek Privátní bankovnictví. - depozitní produkty a služby. Právnické osoby
Ceník pro úsek Privátní bankovnictví - depozitní produkty a služby Právnické osoby platný od 20. 2. 2019 1. SAZEBNÍK POPLATKŮ Korunový běžný účet Modré konto Modré konto je poskytováno klientům úseku Privátní
VíceTabletová aplikace. Uživatelský manuál
Uživatelský manuál Obsah Základní informace... 4 Instalace a přihlášení... 5 Verze CLOUD... 5 Verze SERVER... 8 Verze DEMO... 10 Nastavení displeje, tlačítek... 11 Obecná konfigurace... 11 GPS pozice...
VícePříloha číslo 6 - Technický popis řešení poukazování hotovostních plateb vybraných druhů daní
Příloha číslo 6 - Technický popis řešení poukazování hotovostních plateb vybraných druhů daní Technický popis řešení poukazování hotovostních plateb vybraných druhů daní Popis služby Poukazování hotovostních
VíceMobilita v IP verze 6 Úvod
Mobilita v IP verze 6 Úvod Lukáš Repka IP je nejzákladnějším nosným protokolem rodiny TCP/IP. Všechny ostatní protokoly jsou přenášeny přímo v datové části IP s příslušným identifikačním číslem vyššího
VíceBezpečnost bezdrátové komunikace 9 Téma číslo 1: bezpečnost 10. Základy bezpečnosti komunikačních sítí 13 Bezpečnost sítě 14 Bezpečnostní politika 15
Bezpečnost bezdrátové komunikace 9 Téma číslo 1: bezpečnost 10 KAPITOLA 1 Základy bezpečnosti komunikačních sítí 13 Bezpečnost sítě 14 Bezpečnostní politika 15 Šifrování 15 Soukromý klíč 15 Veřejný klíč
VíceRelační vrstva SMB-Síťový komunikační protokol aplikační vrstvy, který slouží ke sdílenému přístupu k souborům, tiskárnám, sériovým portům.
Aplikační vrstva http-protokol, díky kterému je možné zobrazovat webové stránky. -Protokol dokáže přenášet jakékoliv soubory (stránky, obrázky, ) a používá se také k různým dalším službám na internetu
VíceAutentizace uživatele připojeného přes 802.1X k přepínači Cisco Catalyst 2900/3550 pomocí služby RADIUS
Autentizace uživatele připojeného přes 802.1X k přepínači Cisco Catalyst 2900/3550 pomocí služby RADIUS Semestrální projekt z předmětu Směrované a přepínané sítě 2004/2005 David Mikula Marek Bielko Standard
VíceEXTRAKT z mezinárodní normy
EXTRAKT z mezinárodní normy Extrakt nenahrazuje samotnou technickou normu, je pouze informativním materiálem o normě ICS: 03.220.01; 35.240.60 CALM Systém managementu hlášení sond dat ISO 25114 37 stran
VíceAUTENTIZAČNÍ SERVER CASE BEZPEČNÁ A OVĚŘENÁ IDENTITA
AUTENTIZAČNÍ SERVER CASE BEZPEČNÁ A OVĚŘENÁ IDENTITA SERVER CASE BYL NAVRŽEN JAKO CENTRÁLNÍ AUTENTIZAČNÍ A AUTORIZAČNÍ SYSTÉM. JEHO PRIMÁRNÍM ÚKOLEM JE USNADNIT INTEGRACI SILNÝCH BEZPEČNOSTNÍCH METOD DO
VíceXENGO. nová definice mobility UŽIVATELSKÁ PŘÍRUČKA
XENGO nová definice mobility UŽIVATELSKÁ PŘÍRUČKA Obsah 1. Jak zapnout/vypnout terminál XENGO? 3 2. Jak nabíjet terminál XENGO? 4 3. Jak uskutečnit prodej s čipovou platební kartou? 5 4. Jak zrušit prodej
VíceSbírka tipů pro SERVIS 24
Sbírka tipů pro SERVIS 24 AKTIVACE LIMITY 3D SECURE SMS PIN Obsah Aktivace elektronického výpisu... 1 Změna limitů u platební karty... 2 Oblíbené položky... 3 Zrychlené převody... 4 Recyklace plateb...
VíceManuál pro majitele Korporátní karty. Manuál pro majitele Korporátní karty
Manuál pro majitele Korporátní karty Obsah příručky 1 MojeBanka Business...3 1.1 Přihlášení do aplikace MojeBanka Business...3 1.2 Elektronické výpisy v sekci evýpisy...3 1.3 Výpisy v sekci Výpisy transakcí...4
VíceInteligentní systém pro parkování ve městě
1 Brno, 20. 3. 2018 2 Inteligentní systém pro parkování ve městě JAK TO FUNGUJE? APLIKACE V MOBILNÍM TELEFONU UKAZUJE POTŘEBNOU INFORMACI ZPRACOVÁNÍ DAT A PŘEDÁVÁNÍ ÚDAJŮ ZÁKAZNÍKOVI Senzory jsou nervový
VíceSmart City ekosystém CZ&SK. Martin Dolejs, MasterCard. Martin Chval, Plzeňské dopravní podniky, a.s.
Smart City ekosystém CZ&SK Martin Dolejs, MasterCard Martin Chval, Plzeňské dopravní podniky, a.s. SMART CITIES CZ & SK Smart cities Globální pohled a predikce Více než 50% celosvětové populace žije ve
VíceAUTOMATICKÝ VÝBĚR POHLEDÁVEK (NEZAPLACENÝCH PŘEDPISŮ) PRO UPOMÍNKY...
EVIDENCE UPOMÍNEK Nový systém upomínek od verze 2.14 podstatně rozšiřuje stávající možnosti a dává k dispozici automatický systém generace ( bez nutnosti výběrů ). Stávající systém, kdy si uživatel určuje
VíceCisco Networking Accademy. 7. Bezdrátové sítě (Wireless Networks)
Cisco Networking Accademy 7. Bezdrátové sítě (Wireless Networks) Elektromagnetické spektrum vlnová délka a frekvence vhodnost pro různé technologie licenční vs. bezlicenční použití zdravotní omezení IRF
VíceBezdrátové sítě Wi-Fi Původním cíl: Dnes
Bezdrátové sítě Nejrozšířenější je Wi-Fi (nebo také Wi-fi, WiFi, Wifi, wifi) Standard pro lokální bezdrátové sítě (Wireless LAN, WLAN) a vychází ze specifikace IEEE 802.11. Původním cíl: Zajišťovat vzájemné
VíceELEKTRONICKÁ EVIDENCE TRŽEB
ELEKTRONICKÁ EVIDENCE TRŽEB 1) Vyšel zákon o povinnosti elektronické evidence tržeb. 2) Bude platit pro všechny firmy a podnikatele, kteří přijímají platby v hotovosti (nebo platební kartou) bez ohledu
VíceKLASICKÝ MAN-IN-THE-MIDDLE
SNIFFING SNIFFING je technika, při které dochází k ukládání a následnému čtení TCP paketů. Používá se zejména při diagnostice sítě, zjištění používaných služeb a protokolů a odposlechu datové komunikace.
VíceUživatelský manuál Citfin, spořitelní družstvo Potřebujete poradit? Volejte infolinku nebo pište na
Uživatelský manuál Citfin, spořitelní družstvo Potřebujete poradit? Volejte infolinku +420 234 092 333 nebo pište na info@citfin.cz! OBSAH Vstup do internetového bankovnictví... 3 Přihlášení do internetového
VíceUživatelská příručka. FORMULÁŘE (propojení s ISVZ-US)
Uživatelská příručka FORMULÁŘE (propojení s ISVZ-US) Elektronický nástroj pro zadávání veřejných zakázek verze 1.1.0. 2017 Osigeno s.r.o. Formuláře 1/11 1 OBSAH 1 Obsah...2 2 Seznam zkratek...3 3 Úvod...3
VíceEXTRAKT z české technické normy
EXTRAKT z české technické normy Extrakt nenahrazuje samotnou technickou normu, je pouze informativním 35.240.60 materiálem o normě. Komunikační infrastruktura pro pozemní mobilní zařízení (CALM) Architektura
VíceTechnická specifikace struktury ABO formátu UHL1 DATOVÝ SOUBOR
Technická specifikace struktury ABO formátu Formát ABO se v České republice a na Slovensku běžně používá pro výměnu finančních zpráv. Jeho struktura je pevně definována, a to podle dále uvedeného přehledu.
VíceCeník pro úsek Privátní bankovnictví - depozitní produkty a služby Právnické osoby
Ceník pro úsek Privátní bankovnictví - depozitní produkty a služby Právnické osoby platný od 16. 1. 2019 1. SAZEBNÍK POPLATKŮ KORUNOVÝ BĚŽNÝ ÚČET MODRÉ KONTO Modré konto je poskytováno pro fyzické osoby
VíceEXTRAKT z mezinárodní normy
EXTRAKT z mezinárodní normy Extrakt nenahrazuje samotnou technickou normu, je pouze informativním materiálem o normě TNICEN ISO/TR 14806 Inteligentní dopravní systémy Požadavky veřejné dopravy osob na
VíceProjekt - Plzeňská karta Představení systému
Projekt - Plzeňská karta Představení systému Zbyněk Proška Plzeňské městské dopravní podniky, a.s. Strana 1 Co je Plzeňská karta? Bezkontaktní čipová karta vybavená čipem firmy Philips typu Mifare standard
VíceČeská národní banka Příloha č. 6 pravidel systému CERTIS. Postupy pro testování
Příloha č. 6 pravidel systému CERTIS Postupy pro testování Verze 6 účinnost od 1. listopadu 2018 OBSAH 1 ÚVOD... 3 1.1 Základní informace... 3 1.2 Kontakty... 3 2 POSTUP TESTOVÁNÍ... 4 PROTOKOL O TESTOVÁNÍ...
VíceŠifrování Autentizace Bezpečnostní slabiny. Bezpečnost. Lenka Kosková Třísková, NTI TUL. 22. března 2013
Šifrování Autentizace ní slabiny 22. března 2013 Šifrování Autentizace ní slabiny Technologie Symetrické vs. asymetrické šifry (dnes kombinace) HTTPS Funguje nad HTTP Šifrování s pomocí SSL nebo TLS Šifrování
VíceZADÁVACÍ DOKUMENTACE K VEŘEJNÉ ZAKÁZCE ZADÁVANÉ DLE ZÁKONA Č. 137/2006 SB., O VEŘEJNÝCH ZAKÁZKÁCH, VE ZNĚNÍ POZDĚJŠÍCH PŘEDPISŮ (DÁLE JEN ZÁKON )
ZADÁVACÍ DOKUMENTACE K VEŘEJNÉ ZAKÁZCE ZADÁVANÉ DLE ZÁKONA Č. 137/2006 SB., O VEŘEJNÝCH ZAKÁZKÁCH, VE ZNĚNÍ POZDĚJŠÍCH PŘEDPISŮ (DÁLE JEN ZÁKON ) 1. NÁZEV VEŘEJNÉ ZAKÁZKY Název veřejné zakázky: Mixážní
VíceSamoobslužné odbavení čipových karet
Samoobslužné odbavení čipových karet Odbavovací a informační systém samoobslužných zón projektu Plzeňská karta Mgr. Martin Chval Plzeňské městské dopravní podniky, a. s. Plzeňské městské dopravní podniky,
VíceProject:Úplné elektronické podání
Project:Úplné elektronické podání Den publikace: 23 Lis 2016 Verze 1.0 Atributy modelu: Obsah 0 Celkovy prehled 1 Vyber, identifikace, autentizace 2 Priprava podani 3 Podani, ukon 4 Ulozeni a potvrzeni
VícePříloha č.1 Smlouvy č. VPPx o dodávce elektřiny v roce 2007. Zásady komunikace. Článek I. Způsob předávání dat
Příloha č.1 Smlouvy č. VPPx o dodávce elektřiny v roce 2007 Zásady komunikace Článek I. Způsob předávání dat (1) Přenos informací (obchodních návrhů) mezi smluvními stranami bude zajištěn prostřednictvím
VíceModernizace odbavovacího a informačního systému MHD v Hradci Králové II.
VYSVĚTLENÍ ZADÁVACÍ DOKUMENTACE Č. 8 dle 98 zákona č. 134/2016 Sb., o zadávání veřejných zakázek k nadlimitní sektorové veřejné zakázce na dodávky s názvem: Modernizace odbavovacího a informačního systému
VíceEXTRAKT z mezinárodní normy
EXTRAKT z mezinárodní normy Extrakt nenahrazuje samotnou technickou normu, je pouze informativním materiálem o normě ICS: 03.220.01; 35.240.60 Komunikační infrastruktura pro pozemní mobilní zařízení (CALM)
VíceINTERNETOVÉ BANKOVNICTVÍ ARTESA IDEAL
INTERNETOVÉ BANKOVNICTVÍ ARTESA IDEAL Příručka pro klienty V případě jakýchkoliv dotazů nás kontaktujte na info@artesa.cz nebo na čísle 800 128 836. 1/23 Artesa, spořitelní družstvo, www.artesa.cz, info@artesa.cz
Více