BAKALÁŘSKÁ PRÁCE. Bezpečnost ASP.NET aplikací. ASP.NET Web Application Security. Marek Pavelek

Rozměr: px
Začít zobrazení ze stránky:

Download "BAKALÁŘSKÁ PRÁCE. Bezpečnost ASP.NET aplikací. ASP.NET Web Application Security. Marek Pavelek"

Transkript

1 BAKALÁŘSKÁ PRÁCE Marek Pavelek

2 Un ico rn Co lle ge Un ico rn Co lle ge, V K ap slo vn ě /2, P ra h a 3, Ná ze v p rá ce v ČJ: Ná ze v p rá ce v AJ: Be zp e čno st AS P. NET ap lika cí AS P. NE T W eb Ap p licat io n Se cu rit y Au to r: Ma re k P a ve le k Aka de m ický ro k: / Ko nt a kt: E -ma il: pa ve le kma re gma il. co m Te l. : (+4 20 )

3 1. ZADÁNÍ 3

4 2. ABSTRAKT Tato bakalářská práce je zaměřena na oblast bezpečnosti v prostředí ASP.NET. Cílem práce je analyzovat toto prostředí a popsat, jaké prostředky je možné pro zabezpečení aplikace implementované v ASP.NET využít. Významnou částí je popis způsobů ověřování pomocí operačního systému Windows, služby Passport a formulářů a s tím spojený popis autorizace neboli přidělování práv těmto ověřeným uživatelům a jejich přiřazování do rolí. V další části práce vysvětluje, jak zabezpečit komunikaci s aplikací tak, aby tuto komunikaci útočníci nemohli odposlouchávat ani nijak měnit. Dále jsou popsána nejčastější zranitelná místa webových aplikací představující určité hrozby a jim odpovídající řešení v prostředí ASP.NET. V poslední části je popsána implementace multiuživatelské aplikace uchovávající citlivá data uživatelů za využití určitých bezpečnostních prvků ASP.NET ve Visual Studio Aplikace využívá vestavěných komponent pro ukázku efektivnosti práce s webovými aplikacemi nad.net frameworkem. Klíčová slova: bezpečnost ASP.NET aplikací, ověřování ASP.NET, autorizace ASP.NET, role v ASP.NET, šifrování dat v ASP.NET, zranitelná místa webové aplikace, hrozby webové aplikace, zabezpečená komunikace. 4

5 3. ABSTRACT This Bachelor thesis focuses on security in the ASP.NET environment. The thesis aims to analyze the ASP.NET environment and to describe available means of securing applications implemented in this environment. A significant portion of the thesis is devoted to the description of methods of verification through the Windows operating system, the Passport service and forms and the related description of authorization or, in other words, allocation of rights to these verified users and assignment of users to roles. The thesis goes on to explain how to secure communication with an application so that hackers cannot tap into or alter this communication. This is followed by a description of the most vulnerable spots in and potential threats to web applications and a description of the corresponding solutions in the ASP.NET environment. The last part describes implementation of a multi-user application that stores sensitive user data by using certain security elements of ASP.NET in Visual Studio The application makes use of built-in components to demonstrate the effectiveness of work with web applications over the.net framework. Keywords: security of ASP.NET applications, ASP.NET verification, ASP.NET authorization, ASP.NET roles, data encryption in ASP.NET, vulnerable spots in web applications, threats to web applications, secured communication. 5

6 4. PROHLÁŠENÍ Prohlašuji, že svou bakalářskou práci na téma jsem vypracoval samostatně pod vedením vedoucího bakalářské práce a s použitím odborné literatury a dalších informačních zdrojů, které jsou v práci citovány a jsou též uvedeny v seznamu literatury a použitých zdrojů. Jako autor uvedené bakalářské práce dále prohlašuji, že v souvislosti s vytvořením této bakalářské práce jsem neporušil autorská práva třetích osob, zejména jsem nezasáhl nedovoleným způsobem do cizích autorských práv osobnostních a jsem si plně vědom následků porušení ustanovení 11 a následujících autorského zákona č. 121/2000 Sb. V Praze dne.. Marek Pavelek 6

7 5. PODĚKOVÁNÍ Děkuji vedoucímu bakalářské práce Petru Buchlákovi a konzultantu Petru Pušovi za účinnou metodickou, pedagogickou a odbornou pomoc a další cenné rady při zpracování mé bakalářské práce. 7

8 6. OBSAH Zadání... 3 Abstrakt... 4 Abstract... 5 Prohlášení... 6 Poděkování... 7 Obsah... 8 Úvod Použité konvence Model zabezpečení ASP.NET aplikací Architektura zabezpečení Principál Ověřování Ověřování systému Windows Ověřování pomocí účtu služby Passport Ověřování založené na formulářích Režim ověřování None Autorizace Způsoby autorizace v ASP.NET Role Možnosti autorizace na business vrstvě Zabezpečení konfiguračních souborů Členství Architektura API členství Zabezpečení komunikace Zajištění zabezpečené komunikace Utajení a integrita Certifikáty SSL (Secure Sockets Layer) Kryptografie Symetrická kryptografie Implementace symetrických šifer v ASP.NET Asymetrická kryptografie Implementace asymetrických šifer v ASP.NET Jednosměrná kryptografie (heš, otisk) Implementace hešů v ASP.NET Zabezpečení klíče Hrozby SQL Injection Cross-Site Scripting (XSS) Session hijacking Man-In-The-Middle Denial of Service (DoS) Automatizované zakládání účtů Kritická bezpečnostní chyba Multiuživatelská aplikace Implementační technologie Popis aplikace Big picture řešení Use-case diagram Přehled aktérů Přehled use-case

9 12.3 Základní struktura Nastavení formulářové autentizace Přistup k databázi Zabezpečení WCF Dostupnost pouze pro členy Konfigurace rolí Klíčové stránky aplikace Přihlašovací stránka (~/Anonym/Login.aspx) Registrační stránka (~/Anonym/Register.aspx) Práce s kartou (~/Prihlasen/AktivacePlatebniKarty.aspx) Informace o kartě (~/Prihlasen/PlatebniKartaInfo.aspx) Hodnocení zájezdů (~/Prihlasen/rozcestnik.aspx) Závěr Conclusion Seznam použité literatury Seznam použitých internetových zdrojů Seznam použitých symbolů a zkratek Seznam obrázků Seznam tabulek Seznam zdrojových kódů Seznam příloh Příloha 1 Vlastnosti a metody důležitých tříd API rolí...77 Příloha 2 Vlastnosti a metody důležitých tříd API členství...78 Příloha 3 CD obsahující projekt představené aplikace, projekt představené aplikace pro otestování s přiloženým manuálem a SQL skripty

10 7. ÚVOD ASP.NET slouží pro vývoj dynamických stránek, webových aplikací a webových služeb běžících na straně serveru. Tato technologie zapadá do.net Frameworku a její obrovskou výhodou je poskytování již předem naimplemetovaných částí aplikace, které by programátor sám musel zdlouhavě psát. Webové aplikace lze vyvíjet v mnoha programovacích jazycích díky CLR (Common Language Runtime). V této práci je použit programovací jazyk C# a integrované prostředí Visual Studio Bezpečnost je základní součástí implementace systémů a měla by se plánovat již od samého počátku. To platí zejména u webových aplikací, k nimž má přístup kde kdo. Spousta webových stránek se tomuto oboru nevěnuje a je velice snadné na ně provést útok. Cílem této práce je analyzovat prostředí ASP.NET z hlediska zabezpečeného přístupu a správy citlivých dat. Analýza definuje i nejčastější zranitelná místa webové aplikace a s tím spojené řešení na eliminaci těchto míst. Práce je určena pro čtenáře, kteří již mají určité zkušenosti s programováním v jazyce C# a základní znalosti tvorby webových aplikací pomocí ASP.NET. Případné neznámé pojmy a zkratky jsou uvedeny v poznámkách pod čarou, nebo na konci práce v kapitole Použité konvence 1. Neproporcionální písmo objekty, odkazy v textu, soubory, fragmenty kódu jsou psaný tímto písmem. 2. Tučné písmo je použito pro důležité informace. 10

11 8. MODEL ZABEZPEČENÍ ASP.NET APLIKACÍ První kapitola popisuje, s čím klient komunikuje, když přistupuje k ASP.NET aplikaci, s čím komunikuje samotná aplikace a zdali je to bezpečné. Dále jsou vysvětleny pojmy jako ověřování, autorizace a sepsány jejich možné způsoby a jak tyto způsoby obecně implementovat. 8.1 Architektura zabezpečení Při komunikaci klienta s ASP.NET aplikací prochází klient přes Internet Information Services(IIS). IIS je aplikace umožňující realizovat webový server. Jejím obsahem je Správce IIS, díky kterému můžeme pohodlně spravovat webový server. V případě přístupu klienta na server je nejprve provedeno ověření IIS, pokud je aktivní, a až poté je klient ověřen ASP.NET aplikací. Obrázek 1: Bezpečnostní architektura technologie ASP.NET Zdroj: technet.microsoft.com/cs-cz/library/cc aspx, vlastní úprava Jak již bylo zmíněno, konfiguraci IIS serveru provádíme pomocí Správce IIS. Aplikace ASP.NET se konfiguruje v souborech s příponou.config (Web.config, machine.config..). Aplikaci ASP.NET je umožněno využívat nízkoúrovňové zabezpečovací funkce platformy.net Framework. Jedná se konkrétně o zabezpečení přístupu ke kódu, které má za úkol omezit přístup 11

12 škodlivého kódu, a zabezpečení založené na rolích, které je reprezentováno jmenným prostorem System.Security.Permissions. (technet.microsoft.com/cs-cz/library/cc aspx) Principál Slouží jako základ bezpečnosti v.net Frameworku a je reprezentován jmenným prostorem System.Security.Principal. Jmenný prostor definuje rozhraní IPrincipal a IIdentity. IPrincipal slouží pro ověření, zda je uživatel obsažen v určité roli metodou IsInRole(), a poskytuje identitu tohoto uživatele. Pomocí rozhraní IIdentity můžeme získat informace o identitě konkrétního uživatele, jako jsou například jméno, typ ověřování a odpověď na otázku, zda je uživatel ověřen. Spolu tvoří základ pro ověřování podle rolí. Tato rozhraní jsou přidružena k jednotlivým vláknům aplikace. Pro zjištění kontextu zabezpečení aktuálního uživatele slouží třída Thread.CurrentPrincipal. Obrázek 2: Implementační třídy rozhraní IPrincipal a IIdentity Zdroj: Microsoft Corporation (2004), vlastní úprava Rozhraní obsahují jednotlivé implementace tříd pro různé způsoby ověřování. WindowsPrincipal slouží pro aplikace používající ověřování systému Windows. GenericPrincipal pak pro aplikace používající formulářovou, passportovou a vlastní autentizaci. WindowsIdentity obsahuje informace o uživateli v systému Windows. Tyto informace získáme zavoláním statické metody WindowsIdentity.GetCurrent(). V objektu WindowsIdentity je umístěna i vlastnost Token, která vrací token uživatelského účtu. 12

13 FormsIdentity nese informace o uživateli ověřeném formulářovou autentizací. V objektu FormsIdentity je WindowsIdentity umístěna vlastnost na rozdíl od vlastnosti Ticket FormsAuthenticationTicket s v případě informacemi o autentizaci uživatele. GenericIdentity reprezentuje informace o logickém uživateli, jež není spravován žádným operačním systémem. Používá se v případě vlastní implementace ověřování a autorizace. PassportIdentity obsahuje informace o ověřeném uživateli ve službě Passport včetně informací o profilu této identity. 8.2 Ověřování Proces, ve kterém se zkoumá identita určitého subjektu. Pokud je identita známá, je subjekt považován za ověřený a je mu povolen přístup do zabezpečené části systému. Nejčastěji se zkoumá identita uživatele na základě uživatelského jména a hesla, nebo předloženého certifikátu. Jako další subjekt, u kterého se zkoumá identita, si můžeme představit systém, který přistupuje k jinému systému. Je známo, že rozsáhlé aplikace obsahují mnoho subsystémů, mezi kterými se také musí aplikovat ověřování, a byla by veliká bezpečnostní chyba u nich identitu neověřovat. Proces ověřování si lze představit v reálném životě. Jste například budoucí zaměstnanec Jaderné elektrárny Temelín. Nejprve vás musí zaměstnavatel přijmout. To znamená, že mu předložíte například vaše CV a občanský průkaz. Poté, co jste přijat, obdržíte jako každý zaměstnanec pracovní oděv a kartičku s přístupovými údaji, na níž je uvedeno i vaše jméno a příjmení. Tedy kartička a pracovní oděv vás neustále identifikují jako zaměstnance Temelína. Celkový proces ověřování má za úkol identifikovat uživatele. Zde si musíme uvědomit, že ověřování neprovádíme pouze jednou a to konkrétně při přihlašování uživatele do systému, ale ověřování provádíme pro každý požadavek. (MACDONALD, FREEMAN, SZPUSZTA, 2010, s. 27) Režimy ověřování v prostřední ASP.NET Žádné Ověřování systému Windows Ověřování založené na formulářích Ověřování pomocí účtu služby Passport 13

14 Totožnost uživatele tedy získáme způsobem, kterým se řídí zvolený typ ověřování. Ověřování můžeme také využít pro přizpůsobování, například pro nastavení vzhledu webu a vkládání vlastního obsahu. Možností je samozřejmě mnoho, nejedná se tedy pouze o personalizaci. Důležitým faktem je, že ověřování nemůže omezovat procesy uživatele. K tomuto účelu slouží autorizace (viz kapitola 8.3). (MICROSOFT CORPORATION, 2004, s. 42) Režim ověřování se v ASP.NET nastavuje v souboru Web.config, který se nachází v kořenovém virtuálním adresáři aplikace. Jedná se konkrétně o část kódu: <authentication mode="none Windows Passport Forms"> Do uvozovek se uvádí pouze jeden z těchto čtyř režimů ověřování. Každý z nich je popsán v následujících podkapitolách Ověřování systému Windows Tento způsob ověřování se využívá hlavně ve firemním intranetu, kde mají uživatelé vytvořený účet ve Windows, přes který se do systému přihlašují. Systém tedy využívá již existující údaje o uživatelích a jejich členství ve skupinách. Největším přínosem této metody je, že lze provádět neviditelné ověřování, při němž (v závislosti na použitých nastaveních a architektuře sítě) není nutná samostatná přihlašovací procedura. Ověřování není implementováno v ASP.NET, ale provádí se na úrovni Internetové informační služby (IIS). Díky tomu odpadají starosti spojené s přihlašovací stránkou a vše, co k ní náleží (validita dat, přístup do databáze a další věci s tím spojené). Jedna z obrovských výhod spočívá v použití nástroje Správce služby IIS, v kterém se provádí veškerá konfigurace tohoto režimu. (MACDONALD, FREEMAN, SZPUSZTA, 2010, s ) Důležitým bezpečnostním prvkem v ověřování systému Windows je zosobnění, jenž nám dává možnost dočasně měnit identitu využívanou ASP.NET k provádění určitých úloh. Zosobnění je ve výchozím nastavení zakázáno. To znamená, že jsou úlohy prováděny pod stejným uživatelským účtem (většinou ASPNET účet). Pro povolení zosobnění v aplikaci musíte do souboru Web.config přidat prvek < identity >. Povolení zosobnění pro aplikaci <identity impersonate="true"/> Zosobnění uživatele pro všechny požadavky aplikace <identity impersonate="true" username="unicorn\pavelekm" password="pass"/> 14

15 Pro dočasné provádění úloh pod zvolenou identitou slouží metoda WindowsIdentity.Impersonate(), kterou voláme přímo v kódu programu. Metoda pracuje buď s tokeny účtů, a nebo instancí. Token obsahuje informace o ověření uživatele. ( /cs-cz/library/cc787120(WS.10).aspx) Pokud máme token již uložený v proměnné, zosobnění vyvoláme velice jednoduše: WindowsIdentiy.Impersonate(token); Samotná instance aktuálně přihlášeného uživatele se volá následovně: (WindowsIdentity)HttpContext.Current.User.Identity; Obrázek 3: Identita protéka přes síťové hopy Zdroj: MacDonald, Freeman, Szpuszta (2010), vlastní úprava Se zosobněním souvisí i pojem delegování. Při použití zosobnění nelze přistupovat na jiný server v síti pod dočasnou identitou. Delegování je založeno na stejném konceptu jako zosobnění, ale přístup na jiný server umožňuje způsobem, který převezme ticket ověřeného uživatele a pošle ho jinému serveru v síti. Delegování lze využít v integrovaném ověřování systému Windows jen v případě, pokud má původní server patřičná oprávnění a je zde ověřovací protokol Kerberos (více o protokolu Kerberos v kapitole ). V metodě ověřování algoritmem digest není delegování možné, naopak v základním ověřování lze delegování uplatnit po splnění určitých podmínek. (MACDONALD, FREEMAN, SZPUSZTA, 2010, s ) 15

16 Obrázek 4: Ověřování systému Windows Zdroj: MacDonald, Freeman, Szpuszta (2010), vlastní úprava 16

17 Základní ověřování Obrázek 5: Přihlašovací okno základního ověřování s varováním Zdroj: /wiki/index.php? title=website_authentication Uživatel zadá své uživatelské jméno a heslo do přihlašovacího okna. To se mu zobrazí při přístupu do systému, který žádá ověření. Na základě tohoto pověření se prokáže identita uživatele. Jedná se o internetový standard založený na specifikaci RFC Heslo uživatele je kódováno algoritmem Base64 ještě před jeho odesláním do sítě. Základní ověřování není bezpečné a mělo by se používat společně v kombinaci se SSL šífrováním nebo s jinou formou bezpečné komunikace (viz kapitola 9) a to z důvodu nekryptování přihlašovacích údajů po jejich odeslání od klienta na server. Nekryptovaná data jsou lákavou kořistí pro potencionální útočníky, pro něž je získání přihlašovacích dat tímto způsobem velice jednoduché. Microsoft z tohoto důvodu umístil do přihlašovacího okna varování, ve kterém zmiňuje, že odeslání vyplněných údajů není bezpečné. (MACDONALD, FREEMAN, SZPUSZTA, 2010, s. 118) 1 Stránky tohoto standardu jsou: 17

18 Obrázek 6: Proces základního ověřování Zdroj: Vlastní ilustrace Ověřování algoritmem Digest Byl zaveden v IIS 5.0. Stejně jako základní ověřování požaduje od klienta zadání jeho ověřovacích údajů v podobě přihlašovacího okna. Jeho výhodou oproti základnímu ověřování je zdokonalené zabezpečení při odesílání pověření uživatele v rámci sítě pomocí heše MD5 2. Nevýhodou tohoto ověřování je, že ho lze použít jen v případě, kdy klient používá webový prohlížeč Internet Explorer 5.0 a vyšší verze. V případě, že potencionální útočník získá heš, není mu k ničemu. Původní heslo se z něho získat nedá a ani ho nelze použít pro opakované útoky (více o heši v kapitole 10.3). ( /cs-cz/library/cc782661(WS.10).aspx) Obrázek 7: Proces ověřování algoritmem Digest Zdroj: Vlastní ilustrace 2 Algoritmus s délkou heše 128-bit používaný pro ukládání hesel 18

19 Integrované ověřování systému Windows Tato metoda ověřování je velice zajímavá v tom, že ověřování se provádí automaticky bez nutnosti zadávat uživatelské jméno a heslo na straně klienta. Samotné ověření pak probíhá přes server IIS, který zažádá klienta, aby se ověřil. Webový prohlížeč klienta automaticky odešle token reprezentující účet aktuálního uživatele systému Windows. V případě odmítnutí tokenu IIS serverem je uživateli zobrazeno běžné přihlašovací okno. Metoda ověřování před odesláním jednosměrně zakóduje přihlašovací údaje, díky tomu je tato metoda považována za bezpečnou. Jako jediný webový prohlížeč, který tuto metodu podporuje, je Internet Explorer. Z tohoto důvodu je většinou implementován v intranetových řešeních. Pro fungování musí být také na straně IIS serveru zakázáno anonymní ověřování. (MACDONALD, FREEMAN, SZPUSZTA, 2010, s. 119) První ověřovací protokol využívající Integrované ověřování systému Windows se nazývá Kerberos 5. Tento protokol je extrémně bezpečný a lze ho využít v případě, že na straně klienta a serveru je nainstalován systém Windows 2000 nebo vyšší a pracují v doméně Active Directory 3. Vysoce bezpečný je i druhý protokol NTLM (NT LAN Manager), který využijeme tam, kde Kerberos využít nelze. Rozdíl mezi těmito protokoly z pohledu ověřování klientů je následující. NTLM ověřuje klienty mechanismem výzva/odezva, zatímco Kerberos pracuje na principu ticketů. Nutno zmínit, že Kerberos oproti NTLM podporuje i delegování. (cs.wikipedia.org/wiki/kerberos_(protokol)) Ověřování pomocí účtu služby Passport Služba Passport je poskytována společností Microsoft bezplatně. Během vývoje této služby ji Microsoft několikrát přejmenoval a nyní nese název Windows Live ID. Myšlenka spočívá v jednotném přihlášení uživatele pod určité webové servery podporující tuto službu. Díky tomu se uživatel, který chce získat přístup k chráněným prostředkům určitého webového serveru, nemusí znovu přihlašovat a pamatovat si tak různá uživatelská jména a hesla k těmto webovým serverům. Některé webové servery požadují například i vaši adresu, telefonní číslo a ostatní osobní informace. Samozřejmě je velice nepříjemné vyplňovat tyto informace při každé registraci na webovou stránku. I na straně druhé musí provozovatelé služeb bezpečně uchovávat citlivá uživatelská data a nakládat s nimi podle stanovených norem daného státu. (www.lupa.cz/clanky/microsoft-passport-v-koncich-nebo-na-zacatku/?labelsboxlabelid=38&do=labelsbox-switch) 3 Adresářová služba od společnosti Microsoft. 19

20 Z pohledu bezpečnosti používá služba Windows Live ID standardní bezpečnostní technologie šifrující pověření uživatele při každém jeho přenosu. Proces ověřování neprobíhá na straně webového serveru, který ověření žádá. Pouze klienta přesměruje na stránku služby Windows Live ID, kde potřebné přihlašovací údaje vyplní. Posléze je ověřený klient znovu přesměrován na původní stránku. Obrázek 8: Proces ověřování službou Passport Zdroj: vlastní úprava Domovská stránka této služby je Zde si můžete vytvořit váš vlastní Windows Live ID účet a využívat přednastavených služeb jako Hotmail 4, Messenger5, SkyDrive6 a jiné. Pokud chcete Windows Live ID implementovat do ASP.NET aplikace, má Microsoft přichystané velice jednoduché řešení. Nese název Windows Live ID Web Authentication Software Development Kit (SDK) a můžete si ho zdarma stáhnout na stránkách Microsoftu. (zdrojak.root.cz/clanky/implementace-prihlasovani-pomoci-live-id/) 4 zdarma od společnosti Microsoft 5 Klient pro instant messaging od společnosti Microsoft 6 Služba pro uchovávání dat od společnosti Microsoft 20

21 8.2.3 Ověřování založené na formulářích Toto téma rozeberu podrobněji než předchozí způsoby ověřování, jelikož se jedná o nejpoužívanější ověřování v ASP.NET aplikacích a toto ověřování jsem použil i v mé multiuživatelské ASP.NET aplikaci. Jak je již z názvu patrné, ověřování je prováděno na základě formuláře. Ve většině případů je tento formulář umístěn na přihlašovací stránku webu a obsahuje textová pole pro zadání uživatelského jména a hesla. Tyto údaje jsou následně odeslány na server a porovnány s daty v datovém zdroji. Formulářová autentizace je založena na ověřovacích lístcích. V případě, že se uživatel úspěšně přihlasí do systému, je mu vygenerován lístek obsahující základní informace o uživateli, pomocí něhož se prokazuje v budoucí komunikaci se serverem. Jesliže lístek uživatel nevlastní a přistupuje na část stránky, kde jej vlastnit musí, ASP.NET ho automaticky přesměruje na přihlašovací stránku. Předávání se provádí převážně pomocí cookies, které se ukládají v klientském počítači. Taktéž je možno lístek předávat v URL požadavku, kde je lístek zakódován. Pokud uživatel přistupuje na server, který mu již cookies odeslal, jeho internetový prohlížeč tato data odešle zpět serveru. (www.aspnet.cz/articles/188-jak-funguje-forms-authentication-a-autentizacni-tickety) Obrázek 9: Proces formulářové autentizace bez existence autentizační Cookie Zdroj: Vlastní ilustrace Autentizační lístek obsahuje následující informace: Náhodná hodnota - osm náhodně vygenerovaných bajtů Verze obsahuje číslo formátu lístku Uživatelské jméno obsahuje uživatelské jméno, kterému slouží toto pověření Datum a čas vystavení který den a v kolik hodin byl lístek vystaven Datum a čas vypršení kdy a v kolik hodin lístek vyprší 21

22 Uživatelská data tato hodnota je naplněna libovolnou informací, kterou sem může vložit programátor Délka trvání - uvádí se zde, zdali je pověření trvalé, či nikoliv V textu výše jsem zmínil, že se jedná o nejpoužívanější způsob ověřování, ale neřekli jsme si přoč. Prvním důvodem je volnost provedení. Na rozdíl od ověřování pomocí Windows nebo služby Passport si zde můžete určovat, jak bude ověřování implementováno, kam se budou citlivé informace ukládat, jak dlouho zůstane ticket u klienta, popřípadě jaký bude mít vzhled vaše přihlašovací stránka. Dalším rozdílem je funkčnost ve všech webových prohlížečích. Pro zpřístupnění formulářové autentizace nemusíte nastavovat atribut <authentication mode=""> v souboru Web.config, jelikož je tento atribut při vytvoření nového projektu implicitně nastavena na Forms. Značka <forms> v sekci <authentication> představuje důležité volby ověřování. Tyto volby jsou shrnuty v následující tabulce. Tabulka 1: Atributy pro element <forms> Atribut Možnost Popis name Určuje název HTTP cookie pro ověřování. Výchozí hodnota je nastavena na.aspxauth. V případě, že na jednom serveru běží více jak jedna aplikace, je potřeba tuto hodnotu změnit pro každý Web.config aplikace. loginurl Určuje, kam bude uživatel přesměrován v případě, že nevlastní ověřovací cookie. Základním nastavením je stránka default.aspx. protection Určuje typ šifrování, které se pro ověřovací cookies použije. Původní hodnota je nastavena na All. All Ověřovací cookie se šifruje (pomocí šifry Triple-DES) a podepisuje. None Tato možnost není doporučována a znamená, že ověřovací cookies se nešifrují ani nepodepisují. Encryption Ověřovací cookie se šifruje použítím šifry Triple-DES nebo DES Validation Ověřovací cookie se podepisuje timeout Udává počet minut do vypršení platnosti ověřovací cookie. Původní hodnota je nastavena na 30. path Specifikuje cestu pro cookies zaslaných aplikací. Původni hodnota je /. requiressl Určuje, zdali je SSL připojení vyžadováno pro přenost ověřovacích cookie. Původní hodnota je nastavena na false. true Pokud na webovém serveru není aktivováno SSL, webový prohlížeč nebude přenášet ověřovací cookie. To znamená, že 22

23 formulářová autentizace nebude funkční. flase SlidingExpir ation Na webovém serveru není vyžadováno aktivní SSL Určuje, zda se bude doba života ověřovacího cookie prodlužovat (vyresetováním expirační doby) na základě nově vytvořených požadavků. Původní hodnota je nastavena na false. true Klouzavá expirační doba je aktivována. false Klouzavá expirační doba není aktiví. cookieless Specifikuje, zda bude ASP.NET aplikace zasílat ověřovací cookie klientovi. UseCookies Bude zasílat klientovi ověřovací cookie. V případě, že klientský prohlížeč cookie nepodporuje, ověření nebude fungovat a uživatel se nikdy nepřihlásí. UseUri Ověřovací lístek se nebude zasílat v cookies, ale bude zakódován do URL. AutoDetect Pokud prohlížeč cookies podporuje, ověřovací lístek je předáván pomocí cookies, v opačném případě bude kódován do URL. UseDeviceP Ověřovací lístek je předán volbou specifikovanou v profilu zařízení. Tento profil je uložen na webovém serveru. rofile Zdroj: msdn.microsoft.com/en-us/library/1d3t3c61.aspx Režim ověřování None Nedochází k zádnému ověřování. Pokud plánujete vytvořit vlastní ověřování například pomocí jiné služby než Passport, je tento režim na místě. 8.3 Autorizace Proces autorizace je v zabezpečených systémech nezbytný. Nastává hned po ověření subjektu a jeho úkolem je stanovovat práva a omezení tomuto subjektu. Pomocí autorizace tedy docílíme dalšího stupně bezpečnosti systému v podobě omezení přistupu k zabezpečeným prostředkům nepověřeným subjektům. Stejně jako u ověřování si autorizaci můžeme představit v reálném životě. Pokračujme tedy se zaměstancem Temelína, který je již ověřen. Zaměstnanec má stanovenou určitou práci, kterou má za úkol vykonat. Tato práce je uskutečněna v některém ze segmentů této elektrárny. Zaměstnanec tedy musí projít určitým počtem segmentů, aby se dostal k tomu svému, kde má práci vykonat. K tomuto účelu slouží jeho karta, která ho identifikuje. Díky ní prochází segmenty, které má od zaměstnavatele povoleny. V případě, že chce zaměstnanec projít segmentem, ve 23

24 kterém nic dělat nemá, zabezpečovací dvěře (popřípadě ochranka) ho do tohoto segmentu nepustí. Nebylo by zrovna vhodné, aby zaměstnanec obsluhující stroj pro odvoz jaderného odpadu měl přístup k panelu pro manipulaci s jadernými tyčemi Způsoby autorizace v ASP.NET Autorizace podle souboru Provádí se na základě práv v souborovém systému serveru. Jak jistě víte, v souborovém systému NTFS lze nastavovat uživatelská a skupinová oprávnění k souborům. Autorizace podle souboru je prováděna modulem FileAuthorizationModule. V případě, že chce uživatel přistoupit k souboru, FileAuthorizationModule se podívá na oprávnění tohoto uživatele vztahující se k tomuto souboru, a pokud tato práva nevlastní, vyhodí výjimku, při které je uživateli zobrazena informace ohledně zamezení přístupu. Samozřejmě tento způsob autorizace lze uplatnit pouze s ověřováním systému Windows. K souborům je možné připojit seznamy ACL (Access Control Lists), pomocí nichž lze řídit oprávnění přístupu k těmto souborům. (MRNKA, 2005, s ) Obrázek 10: Proces autorizace podle souboru Zdroj: Vlastní ilustrace 24

25 Autorizace podle adresy URL Prováděna modulem UrlAuthorizationModule. Mapuje uživatele a role na části oboru názvů URL. Modul implementuje pozitivní i negativní autorizační výroky. To znamená, že modul lze použít k selektivnímu povolení nebo odepření přistupu k libovolným částem oboru názvů URL pro určité skupiny, uživatele nebo role. (technet.microsoft.com/cs-cz/library/cc779441(ws.10).aspx) Autorizace podle adressy URL nastavuje sekce <authorization> v souboru Web.config. První element uvádí o jakou autorizaci se jedná. Allow udává pozitivní a deny negativní. Za tímto elementem následují atributy users=".." a roles="..". Pro správnou funkčnost musí být alespoň jeden z atributů uveden. Do uvozovek za atributem users se uvadí přihlašovací jména uživatelů a do atributu roles víčet rolí. Dalším a posledním atributem, jež lze zde zadat je verbs="..". Atribut určuje, na jaké požadavky se autorizace vztahuje. Do atributu verbs se vkládá hodnota GET, POST nebo HEAD7. (MRNKA, 2005, s. 53) Obrázek 11: Proces autorizace podle URL Zdroj: Vlastní ilustrace 7 Metody požadavku protokolu HTTP 25

26 Do uvozovek atributů lze uvést dva zástupné znaky. První znak * zastupuje všechny uživatele. Druhý znak? zastupuje pouze anonymní uživatele. Těchto znaků můžete využít například pokud máte v ASP.NET projektu vytvořenu hierarchii pomocí složek a potřebujete zabezpečit určité stránky tak, aby na ně mohli pouze ověření uživatelé. Stačí vytvořít soubor Web.config například pomocí klávesové zkratky CTRL+SHIFT+A v této složce a konfigurační soubor nastavit následovně: <configuration> <system.web> <authorization> <deny users="?" /> </authorization> </system.web> </configuration> Toto nastavení zamezí přistupovat neověřeným uživatelům k čemukoliv ve složce. Pokud adresář obsahuje podadresář, ve kterém je také soubor Web.config, nastavení v něm má vyšší váhu než nastavení práv adresáře nadřazeného. Při práci s autorizací v souboru Web.config využijeme i element <location> s atributem path="..". To konkrétně v případě aplikace práv pouze na jednotlivé soubory. Do elementu se vkládá cesta ke stránce, ke které se nastavení autorizace vztahuje. <location path="stranka.aspx"> <system.web>... </system.web></location> 26

27 8.3.2 Role Zastupuje určitý počet subjektů a jsou na ni mapována práva a omezení. V příkladu se zaměstnancem jsou také využity role. Není možné, aby společnost, která má nad 1000 zaměstnanců, určovala práva a omezení pro každého zaměstnance zvlášť. To by znamenalo, že v případě každého nově příchozího/odchozího zaměstnance by se mu musela práva a omezení přidělovat/odebírat zvlášť. Samozřejmě by toto řešení zabralo spoustu času a díky použití rolí pouze nově příchozího zaměstnance do určité role obsadíme a automaticky dostane práva a ověření vztahující se k této roli. Ve webových systémech se s ničím jiným než s rolemi nesetkáme. Možná se najdou unikáty aplikující práva na jednotlivé uživatele, ale dovolím si tvrdit, že je to pouze z nezkušenosti daného programátora. ASP.NET má pro práci s rolemi předem vytvořené API (Application Programming Interface)8. Pomocí tohoto API můžete spravovat role velice jednoduše. Lze ho využít jak pro ověřování založené na formulářích, tak i ověřování systému Windows. Pro aktivaci API stačí přidat do souboru Web.config element <rolemanager> s atributem enabled="true". <configuration> <system.web> <rolemanager enabled="true" /> <providers>... </providers> </system.web> </configuration> Poskytovatelé rolí se konfigurují v podelementu <provider> elementu <roleman- ager>. Podrobnější konfigurace je ukázána v kapitole Rozhraní obsahující třídy, funkce a jíné. Programátor pak tohoto obsahu může využívat. 27

28 Architektura API rolí v ASP.NET Skládá se ze čtyř hlavních částí: Ověřovací prvky pro bezpečnost Vestavěné bezpečnostní komponenty ASP.NET. Například pomocí komponenty LoginView můžeme vytvářet rozdílné pohledy v závislosti na rolích. API pro role V této části jsou umístěny třídy API rolí jmenného prostoru System.Web.Security. Všechny metody a vlastnosti tříd jsou znázorněny v příloze 1. Nejdůležitější třídy jsou: Třída Roles obsahuje metody a vlastnosti pro správu rolí. Jedna z hojně využívaných metod je IsUserInRole(), která zjistí, zda je uživatel v roli umístěné ve vstupní hodnotě metody. Třída RolePrincipal Dědí z třídy IPrincipal a úkolem této třídy je spojovat role s autentizovaným uživatelem. Třída RoleManagerModule Zajišťuje, že aktuálně přihlášenému uživateli budou přiděleny role pro každý jeho požadavek. Poskytovatelé rolí Implementují přístup k úložišti dat API rolí. Pro poskytovatele je základní třída RoleProvider, z které ostatní poskytovatelé dědí. ASP.NET obsahuje tři zabudované poskytovatele rolí: Poskytovatel SQL Serveru Pracuje s databázemi SQL serveru. Je reprezentován třídou SqlRoleProvider. Samotné uložení dat do databáze probíhá přes connectionstring definovaný u konkrétního poskytovatele v souboru Web.config. Pro práci s API rolí je nutno importovat určité tabulky představující úložnou strukturu rolí do SQL databáze pomocí spouštěcího souboru aspnet_regsql.exe umístěného v adresáři: [disk]:\windows\microsoft.net\framework[verze] Poskytovatel Authorization Store Mapuje role z Microsoft Authorization Manager (AzMan) do rolí v ASP.NET. Je reprezentován třídou AuthorizationStoreRoleProvider. Poskytovatel Windows Token Získává informace o rolích pro ověřeného uživatele Windows založeného na asociacích skupiny Windows. (MACDONALD, FREEMAN, SZPUSZTA, 2010, s. 143, 158) 28

29 Obrázek 12: Architektura API rolí Zdroj: vlastní úprava Možnosti autorizace na business vrstvě Jak již jistě víte, většina webových aplikací pracuje na třívrstvé architektuře 9. Výše zmíněné možnosti autorizace pracují na vrstvě prezentační. ASP.NET obsahuje možnosti autorizace i na business vrstvě. Při použití takovéto autorizace je aplikace schopna povolit, či nepovolit uživateli k volání metod, vytváření instancí tříd atp. Jedná se konkrétně o: 9 Skládá se ze tří vrstev : Prezentační vrstva funkce uživatelského rozhraní. Aplikační vrstva logika aplikace. Datová vrstva funkce pro přístup k datům. 29

30 Role-based security Model autorizace je založen na principálovi (viz kapitola 8.1.1), kde ke zjištění, zda je uživatel obsažen v roli, slouží metoda IsInRole(). Pro tento model však existuje ještě jeden způsob pro práci s autorizací. Využívá se třídy PrincipalPermission. Při vytváření instance této třídy se uvádí jako jeden ze vstupních parametrů název role. Po zavolání metody Demant() na vytvořené instanci třídy PrincipalPermission se vyhodnotí, zda aktuálně přihlášený uživatel do role patří. Pokud uživatel do role nepatří, je vyhozena bezpečnostní výjimka. Tento model lze implementovat i pomocí atributu PrincipalPermission, který se přiřazuje určité třídě nebo metodě. Kód pak může vypadat následovně: Použití třídy PrincipalPermission PrincipalPermission kontrola = new PrincipalPermission(null, "Administrators"); Použití atributu PrincipalPermission [PrincipalPermission(SecurityAction.Demand, Role= "Administrators")] (MACDONALD, FREEMAN, SZPUSZTA, 2010, s ) Code Access Security (CAS) Veškeré Windows aplikace mají přístup k prostředkům jako registry systému Windows, místní disky, protokoly událostí atd. Může se tedy snadno stát, že v případě spuštění škodlivého kódu se tyto prostředky poškodí (např. smazání důležitých souborů operačního systému, editace registrů). CAS tyto prostředky systému chrání před záludnými kódy. Tedy říká kódu, co má povoleno dělat a co ne podle jeho stupně důvěryhodnosti. Pokud CLR věří kódu natolik, aby ho spustil, a kód začne dělat něco, na co nemá právo, je vyhozena bezpečnostní výjimka. CAS je založeno na těchto pojmech: Oprávnění Určuje to, co má kód povoleno dělat. Je vydáváno pro jednotlivé kódové skupiny. 30

31 Sady oprávnění Abychom skupinám nemuseli přiřazovat jednotlivá oprávnění, existují právě sady oprávnění, které jednotlivá oprávnění sdružují. Mezi ně patří například FullTrust (neomezený přístup k chráněným prostředkům), UIPermission (oprávnění k využívání uživatelského rozhraní). Kódové skupiny Sady oprávnění nejsou přidělovány jednotlivým knihovnám, ale skupinám, do kterých jsou knihovny přiřazeny. Řazení probíhá na základě vlastností. Každá skupina řadí knihovny pouze podle jediné vlastnosti. Nejvyužívanější je vlastnost zóna, která určuje, odkud knihovna pochází. Knihovna však může patřit do několika skupin, v takovém případě je provedeno sjednocení oprávnění z těchto skupin. (NAGEL, EVJEN, GLYNN, SKINNER, WATSON, 2008, s ) Zabezpečení konfiguračních souborů Při práci s ASP.NET by vás mohlo zajímat, co se stane v případě, zadáte-li do prohlížeče adresu k souboru Web.config. Budete s ním moci manipulovat? Odpověď zní - samozřejmě ne. Webový server IIS má registrované přípony souborů, mezi ně patří i přípona.config. Server IIS tedy zamezí stahování konfiguračních souborů ASP.NET. Není vhodné ukládat všechny konfigurační informace do jednoho konfiguračního souboru. Například nechcete, aby zaměstnanec firmy mohl spravovat a vidět jiný obsah než sekci <pages>. Toho lze dosáhnout pomocí externalizace sekcí konfiguračních souborů. Jednoduše se vytvoří nový konfigurační soubor např. Pages.config, který bude uchovávat již zmíněnou sekci <pages>. Do souboru Web.config stačí k sekci <pages> přidat atribut configsource="pages.config", ať ví, kde má hledat. Zaměstnanci pak zamezíme přístup k souboru Web.config a přidáme potřebná oprávnění na soubor Pages.config. Pokud chcete bezpečnost konfiguračních souborů ještě zvýšit, ASP.NET podporuje šifrování částí kódu v konfiguračních souborech. Je doporučeno šifrovat sekci <connectionstrings>, protože se jedná o velice citlivé informace nesoucí uživatelské jméno a heslo pro přístup k databázi. Šifrování sekcí konfiguračních souborů lze provést pomocí nástroje aspnet_regiis umístněného v [disk]:\windows\microsoft.net\framework\[verze]. Lze si zde i zvolit, pomocí jakého algoritmu budou data šifrována. 31

32 8.4 Členství Internetové aplikace pracují většinou s uživateli a jejich správou. Jak již bylo zmíněno, bezpečnostní architektura ASP.NET obsahuje různé způsoby ověřování a autorizace uživatelů. Nebylo však nic řečeno o jejich vytváření, odstraňování, změnách hesla apod. Tato oblast je implementována pomocí API členství (membership API). Tohoto API se využívá spolu s ověřováním založeném na formulářích. Členství zpřístupníme a nakonfigurujeme v souboru Web.config elementem <membership>. V něm se například určuje, v jaké formě bude uloženo heslo uživatele, zda je povolena změna hesla atd. <configuration> <system.web> <Membership> <providers>... </providers> </system.web> </configuration> Tento element obsahuje podelement <providers>, ve kterém jsou poskytovatelé členství. Podrobnější konfiguraci tohoto elementu popisuje kapitola definováni

33 8.4.1 Architektura API členství Je velice podobná architektuře API rolí. Skládá se také ze čtyř hlavních částí: Ovládací prvky pro bezpečenost Microsoft Visual Studio obsahuje vestavěné bezpečnostní komponenty pro formulářovou autentizaci a infrastrukturu členství. Ty lze snadno přizpůsobovat a tím dosáhnout efektivní práce v poměru s časovou náročností na jejich implementaci. Komponenty Login, LoginStatus, LoginView, CreateUserWizard a ostatní jsou umístěny ve skupině Login panelu ToolBox. API pro členství Obsahuje třídy pro API členství umístěné ve jmenném prostoru System.Web.Security. Všechny metody a vlastnosti tříd jsou znázorněny v příloze 2. Nejdůležitější jsou třídy Membership a MembershipUser. Třída Membership Obsahuje statické metody a vlastnosti pro správu uživatelů, jejich ověřování a pro přístup k jejich rolím. Tyto metody pracují se základním poskytovatelem aplikace pro členství. Třída MembershipUser Ztvárňuje jedniného uživatele a obsahuje metody a vlastnosti pro práci s ním. Poskytovatelé členství Implementují přístup k úložišti dat API členství. Pro poskytovatele je základní třída MembershipProvider, z které ostatní poskytovatelé dědí. ASP.NET obsahuje dva zabudované poskytovatele členství: Poskytovatel SQL serveru Poskytovatel pracuje s databázemi SQL serveru. Je reprezentován třídou SqlMembershipProvider. Samotné uložení dat do databáze probíhá přes connectionstring definovaný u konkrétního poskytovatele v souboru Web.config. Členství potřebuje pro práci určité tabulky. Ty je možné do SQL databáze importovat pomocí spouštěcího souboru aspnet_regsql.exe umístěného v adresáři: [disk]:\windows\microsoft.net\framework\[verze] Poskytovatel Active Directory poskytovatel pracuje s Active Directory. Reprezentován třídou ActiveDirectoryMembershipProvider. Úložiště členství Reprezentuje konkrétní úložiště, kam se budou jednotlivé položky API členství ukládat a odkud jsou načítány. (MACDONALD, FREEMAN, SZPUSZTA, 2010, s ) 33

34 Obrázek 13: Architektura API členství Zdroj: MacDonald, Freeman, Szpuszta (2010), vlastní úprava 34

35 9. ZABEZPEČENÍ KOMUNIKACE V aplikaci jsou citlivá data přenášena přes různé body. Přenos těchto dat po různých kanálech musíme zabezpečit, aby nebyly prozrazeny, popřípadě pozměněny. V této kapitole si vysvětlíme pojmy utajení a integrita. Následně si uvedeme, čím tyto pojmy zajistit v prostředí ASP.NET aplikace Zajištění zabezpečené komunikace Utajení a integrita Pro zabezpečenou komunikaci jsou velmi důležité dvě vlastnosti. První z nich je Utajení, které má na starost, aby nikdo neměl přístup k citlivým datům, která zpracovává určitý uživatel. Jako řešení se využívá šifrování. Pomocí tohoto přistupu docílíme utajení a důvěryhodnosti dat. Šifrováním se zabývá celá kapitola 10. Na rozdíl od utajení druhá vlastnost nesoucí název integrita zabraňuje pozměnění dat v průběhu přenosu neautorizovanými subjekty po určitém kanále. Integrita je narušena v případě poškození těchto dat, jelikož již nenesou původní informaci. Pro udržení integrity se využívají Message Authentication Codes (MAC) představující krátkou informaci pro ověření zprávy a také lze využít otisků (viz kapitola 10.3). (MICROSOFT CORPORATION, 2004, s. 33) Certifikáty Jedná se o veřejný klíč podepsaný certifikační autoritou (CA) 10. Jsou potřeba pro fungování SSL (viz kapitola ) na serveru. Certifikát tedy získáme od určité certifikační autority. Po jeho získání je ho možné nainstalovat na webový server, v našem případě na server IIS. Certifikát přidáme na server pomocí Správce IIS po vybrání položky Certifikáty serveru z menu. Na webovém serveru může být nainstalováno více certifikátů sloužících pro více webových stránek. Dříve tu však tato možnost nebyla. Standardem certifikátů je certifikát X Subjekt vydávající certifikáty. Zaručuje správnost informací v nich obsažených. 35

36 Obrázek 14: Struktura certifikátu X.509 verze 3 Zdroj: vlastní úprava Možnosti certifikátů Self-signed certifikát si vydáváte a podepisujete sami. Certifikát nelze použít pro ověření identity. Používají se v uzavřeném prostření (firma, škola). Vlastní certifikační autorita server provozuje vlastní certifikační autoritu. Důležitým krokem u této možnosti je chránit privátní klíč, kterým CA certifikáty podepisuje. V případě úniku klíče můžete všechny své certifikáty vyhodit. Stejně tak jako u Self-signed je tato metoda spíše pro intranetovou oblast. Těžko neznámého uživatele donutíme k tomu, aby si vaši CA nastavil jako důvěryhodnou kořenovou autoritu. Komerční certifikační autorita certifikáty jsou vydávány komerční certifikační autoritou, která má jasně stanovenou certifikační politiku. Tato možnost je placená a cena se pohybuje okolo Kč. Nejznámější komerční certifikační autority jsou: VeriSign, Comodo, GoDaddy. (technet.microsoft.com/cs-cz/edge/zadost-o-ssl-certifikat-cz) 36

37 9.1.3 SSL (Secure Sockets Layer) Protokol zajišťující bezpečnou a spolehlivou komunikaci aplikací. Díky této technologii budou citlivá data aplikace splňovat utajení (viz kapitola ) a integritu (viz kapitola ). Protokol SSL se využívá i při ověřování uživatele, kdy jsou přihlašovací údaje šifrovány právě tímto protokolem. Nevýhodou použití SSL je snížená výkonnost serveru a s tím spojené prodloužení doby odezvy. Tuto nevýhodu můžeme snížit například tím, že SSL aplikujeme pouze na klíčové akce v naší aplikaci, jako je přihlášení, platba kartou atd. Obrázek 15: Pozice protokolu SSL v TCP/IP modelu Zdroj: rubrika=tutorialy&temaid=171&clanekid=187 SSL šifruje HTTP komunikaci, ale nemění způsob zacházení s těmito HTTP dotazy. Důvodem je práce SSL na nižší vrstvě. V případě ASP.NET zajišťuje šifrování a dešifrování IIS. HTTP komunikace, která je šifrována protokolem SSL, začíná prefixem https://. Klient přistupující na stránku se zabezpečenou komunikací nejdříve stáhne veřejný klíč serveru. U tohoto klíče následně zkontroluje, zda pochází opravdu od serveru na který přistupuje. Ověření pravosti klíče řeší právě certifikační autorita. Internetový prohlížeč, nebo úložiště certifikačních autorit ve Windows uchovává určitý seznam takzvaných důvěřyhodných CA. Pokud CA není v tomto seznamu, internetový prohlížeč zobrazí varování uživateli, že certifikát není bezpečný. (http://www.brainweb.cz/ssl-certifikaty) Obrázek 16: Informace o zabezpečené komunikaci Zdroj: Autorem vytvořeno v internetovém prohlížeči Google Chrome 37

38 10. KRYPTOGRAFIE Kryptografie neboli šifrování je nauka o metodách utajování smyslu zpráv převodem do podoby, která je čitelná jen se speciální znalostí. (cs.wikipedia.org/wiki/kryptografie) Slouží k zajištění utajení (viz kapitola ) a integrity (viz kapitola ) dat. Lze ji také použít k ověřování, kde zkoumá, zda data pocházejí od příslušného uživatele. V.NET je reprezentována jmenným prostorem System.Security.Cryptography. Naleznete zde šifrovací algoritmy, pomocné třídy, třídy pro práci s certifikáty X.509, třídy pro šifrování a podepisování XML dokumentů. Kryptografie v.net je založena na proudech. K fungování této proudové architektury nám slouží dvě třídy. První z nich je třída ICryptoTransform, která definuje kryptografickou transformaci po blocích. Druhá třída CryptoStream obaluje obyčejný proud a za scénou používá ICryptoTransform. Na třídě CryptoStream můžeme volat metodu jak pro čtění, tak pro zápis. (MACDONALD, FREEMAN, SZPUSZTA, 2010, s. 216).NET framework dokáže pracovat s šifrováním symetrickým, asymetrickým a jednosměrným (heše). V následujících několika podkapitolách si tyto typy šifrování blíže představíme a ukážeme si důležité třídy pro implementaci. V ASP.NET aplikacích se kryptografie používá například k šifrování: Hesla Sekce konfiguračních souborů(viz 8.3.3) ViewState Ověřovací Cookies Citlivé informace aplikace(důležité firemní dokumenty, informace o platební kartě atd.) 38

39 10.1 Symetrická kryptografie Obrázek 17: Proces šifrování a dešifrování symetrické kryptografie Zdroj: Vlastní ilustrace Algoritmy pracující na principu jednoho klíče. K vykonávání šifrování i dešifrování je použit stejný klíč. Výhodou tohoto přístupu je nízka výpočetní náročnost. Symetrické šifrování je tedy většinou několikanásobně rychlejší než šifrování asymetrické. (cs.wikipedia.org/wiki/symetrick%c3%a1_kryptografie) Tabulka 2: Symetrické algoritmy, které podporuje.net Abstraktní algoritmus Výchozí implementace Platná délka Maximální délka klíče klíče DES DESCryptoServiceProvider TripleDES TripleDESCryptoServiceProvider 128, RC2 RC2CryptServiceProvider 40 až Rijndael RijndaelManaged 128,192, Zdroj: MacDonald, Freeman, Szpuszta (2010) 39

40 Implementace symetrických šifer v ASP.NET Symetrické šifry v ASP.NET reprezentuje bázová třída 11 SymmetricAlgorithm, která obsahuje všechny abstraktní symetrické algoritmy, jež lze v ASP.NET implementovat. Tabulka 3: Nejdůležitější metody třídy SymmetricAlgorithm Název metody Popis Create() Vytvoří instanci třídy algoritmu, který udáme v závorce. GenerateKey() Vygeneruje náhodný klíč, který slouží jako klíč pro určitý algoritmus. GenerateIV() Vygeneruje inicializační vektor, který přidává náhodná data do zašifrovaného proudu. CreateEncryptor() Zašifruje objekt s patřičným inicializačním vektorem. klíčem a CreateDecryptor() Dešifruje objekt s patřičným inicializačním vektorem. klíčem a Zdroj: msdn.microsoft.com/en-us/library/system.security.cryptography.symmetricalgorithm.aspx Obecný postup šifrování dat 1. Data určená pro šifrování musíme převést do bajtového pole, které bude sloužit jako vstupní parametr. 2. Vytvoříme algoritmus pomocí třídy SymmetricAlgorithm a metody Create(). 3. Vygenerujeme klíč a inicializační vektor voláním metod GenerateKey(), GenerateIV() na vytvořené instanci třídy SymmetricAlgorithm. 4. Zašifrujeme data pomocí třídy CryptoStream a metody CreateEncryptor() na vytvořené instanci třídy SymmetricAlgorithm Obecný postup dešifrování dat 1. Vytvoříme algoritmus pomocí třídy SymmetricAlgorithm a metody Create(). 2. Načteme si klíč a inicializační vektor z procesu šifrování. Tyto hodnoty uložíme do vlastnosti Key a IV třídy vytvořené instance v kroku Nazýváno také jako rodič, base class, parent 40

41 3. Dešifrujeme data pomocí třídy CryptoStream a metody CreateDecryptor() na vytvořené instanci třídy SymmetricAlgorithm. 4. Získané bajty převedeme na text Asymetrická kryptografie Obrázek 18: Proces šifrování a dešifrování asymetrické kryptografie Zdroj: Vlastní ilustrace Na rozdíl od symetrických šifrovacích algoritmů, asymetrické používají k šifrování a dešifrování odlišné klíče, ale jsou mnohem pomalejší. První klíč se označuje jako veřejný, ten lze poskytnout každému. Soukromý klíč slouží k dešifrování informací. Tedy v případě, že vlastníte soukromý klíč, můžete informace dešifrovat. V případě obrázku 7 tedy nemusíme Alici posílat klíč, který umí tato data dešifrovat. Asymetrické šifry se používají také pro elektronický podpis 12. (projektysipvz.gytool.cz/projektysipvz/default.aspx?uid=555) 12 Údaje v elektronické podobě, které jsou připojené k datové zprávě nebo jsou s ní logicky spojené a které slouží jako metoda k jednoznačnému ověření identity podepsané osoby ve vztahu k datové zprávě. (http://business.center.cz/business/pravo/zakony/epodpis/cast1.aspx) 41

42 Tabulka 4: Asymetrické algoritmy, které podporuje Abstraktní algoritmus Výchozí implementace Platná délka klíče Maximální délka klíče RSA RSACryptoServiceProvider (8 bitové přírůstky) 1024 DSA DSACryptoServiceProvider (64 bitové přírůstky) 1024 Zdroj: MacDonald, Freeman, Szpuszta (2010) Implementace asymetrických šifer v ASP.NET Implementace je velice podobná symetrickým šifrám. Rozdíl spočívá ve správě klíčů. Asymetrické šifrování je v ASP.NET reprezentováno bázovou třídou AsymmetricAlgorithm. V tabulce 3 jsou uvedeny dva algoritmy využívané pro asymetrické šifrování v ASP.NET, ale pouze RSA se pro tento účel využívá. Algoritmus DSA je určen pro digitální podpisy. Tabulka 5: Nejdůležitější metody třídy RSACryptoServiceProvider Název metody Popis ToXmlString() Vrací řetezec s XML strukturou, obsahující hodnoty pro výpočet privátního nebo veřejného klíče. V případě vstupní hodnoty true se exprotuje jak veřejný tak i soukromý klíč, pakliže je hodnota false exportuje se jen klíč veřejný. FromXmlString() Převede Encrypt() Zašifruje data Decrypt() Dešifruje data formát ToXmlString(). klíče. Opak metody Zdroj: msdn.microsoft.com/enus/library/system.security.cryptography.rsacryptoserviceprovider_methods(v=vs.71).aspx Obecný postup vytváření soukromého a veřejného klíče 1. Vytvoříme instanci třídy RSACryptoServiceProvider. 2. Zavoláme metodu ToXmlString() s parametrem true. Tím získáme privátní klíč, který je nutno uložit na bezpečné místo(viz kapitola 10.4). 3. Zavoláme metodu ToXmlString() s parametrem false. Máme tedy k dispozici veřejný klíč, který můžeme poskytnout osobě, která nám chce posílat šifrovaná data. 42

43 Obecný postup šifrování dat 1. Data určená pro šifrování musíme převést do bajtového pole, které bude sloužit jako vstupní parametr. 2. Vytvoříme instanci třídy RSACryptoServiceProvider. 3. Načteme veřejný klíč volání metody FromXmlString(). 4. Zašifrujeme data voláním metody Encrypt() na vytvořené instanci třídy RSACryptoServiceProvider Obecný postup dešifrování dat 1. Vytvoříme instanci třídy RSACryptoServiceProvider. 2. Načteme klíče voláním metody FromXmlString(). 3. Dešifrujeme data metodou Decrypt() na instanci třídy RSACryptoServiceProvider. 4. Získané bajty převedeme na text Jednosměrná kryptografie (heš, otisk) Algoritmům se říká jednosměrné, protože prostý text dokáží pouze zašifrovat. Prostý text je šifrován, ale ani ten, kdo ho šifruje, neví pomocí jakého klíče. Heše se využívájí hlavně pro šifrování hesel. Díky tomu naše heslo nemůže přečíst ani správce webu, správce databáze a zbytek vývojového týmu daného serveru. Samozřejmě tím ztížíme práci i potencionálním útočníkům na náš server. (blok.net-vor.cz/bezpecnost-hesel-v-php) V případě, že útočník získá otisky hesel, pomocí různých metod lze získat původní hesla. Bezpečnost hesel se dá zvýšit takzvaným solením. Sůl je určitý řetězec znaků, který se přidává na vstup při hešování hesla. Jako sůl můžeme zvolit libovolný řetězec, který by měl být jiný pro každého uživatele. Metoda solení nám pomůže částečně odvrátit některé útoky, jako je například útok s předgenerovanými tabulkami (rainbow tables), ale není nám nic platná proti útoku hrubou silou. (www.phpguru.cz/clanky/soleni-hesel) 43

44 Tabulka 6: Hešohovací algoritmy, které podporuje.net Abstraktní algoritmus Výstupní velikost (bit) Výchozí implementace KeyedHashAlgorithm 160 HMACSHA1;MacTripleDES MD5 128 MD5CryptoServiceProvider SHA1 160 SHA1CryptoServiceProvider SHA SHA256Managed SHA SHA384Managed SHA SHA512Managed Zdroj: Microsoft Corporation (2004) Implementace hešů v ASP.NET Heše jsou v ASP.NET reprezentovány bázovou třídou HashAlgorithm. Neobsahují tolik metod jako třídy pro symetrické a asymetrické šifrování, jelikož zde nejsou potřeba žádné klíče. Tabulka 7: Nejdůležitější metody třídy HashAlgorithm Název metody Popis Create() Vytvoří instanci třídy algoritmu, který uvedeme v závorce. ComputeHash() Zahešuje data Zdroj: msdn.microsoft.com/en-us/library/system.security.cryptography.hashalgorithm.aspx Obecný postup šifrování dat 1. Data určená pro šifrování musíme převést do bajtového pole, které bude sloužit jako vstupní parametr. 2. Vytvoříme algoritmus pomocí třídy HashAlgorithm a metody Create(). 3. Zavoláme metodu ComputeHash() na instanci třídy HashAlgorithm, jejíž vstupní hodnota budou naše data, která chceme šifrovat. 44

45 10.4 Zabezpečení klíče Vygenerované klíče a inicializační vektory je potřeba někde uchovávat (např. Web.config). To z toho důvodu, abychom měli tyto dvě hodnoty shodné pro šifrování i dešifrování. Zvýšení bezpečnosti můžeme dosáhnout pomocí šifrování těchto klíčů. To by znamenalo, že bychom vygenerovali nový klíč a ten museli také někde uložit. K šifrování klíčů nám slouží Data Protection API(DRAPI), které šifruje data vygenerovaným klíčem stroje, případně klíčem uživatele. Systému tedy sdělujeme, ať něco zašifruje či dešifruje, tímto klíčem. Přístup ke klíči však nemáme. K tomuto účelu je v System.Security.Cryptography.ProtectedData. (MACDONALD, FREEMAN, SZPUSZTA, 2010, s. 218) 45 ASP.NET vytvořena třída

46 11. HROZBY Aplikaci lze napadnout nespočtem metod. V této kapitole si představíme nejznámější hrozby webové aplikace a zároveň si řekneme, čím se před nimi chránit v prostředí ASP.NET SQL Injection Jedná se o změnu SQL dotazu přes neošetřené formulářové nebo jiné vstupy. V případě, že naše aplikace není chráněna proti tomuto typu útoku, útočník může získat hesla z databáze či editovat a mazat data. Jeden z nejčastějších dotazů je porovnání uživatelského jména a hesla ze vstupních dat s daty databáze. Mějme tedy tento dotaz: "Select Count(*) from Users Where UserName = ' " + TextBoxName.Text + " ' And Password = ' " + TextBoxPass.Text + " ' "; Dotaz vrátí počet nalezených řádků. V případě, že nic nenajde, vrátí 0 a uživatel nebude přihlášen. V případě této implementace SQL dotazu lze velice jednoduše provést SQL Injection. Stačí pouze do textboxů napsat: 'or '1' = '1 Tento dotaz může například vrátit první řádek, který se shoduje. V případě multiuživatelské aplikace vytvořené pro tuto práci byl vytvářen jako první administrátorský účet, tudíž po tomto dotazu byste se úspěšně přihlásil jako uživatel s plnými právy. (mikesdotnetting.com/article/113/preventing-sql-injection-in-asp.net) Obrázek 19: Ukázka útoku pomocí SQL injection Zdroj: Vlastní ilustrace 46

47 Proti SQL Injection se lze samozřejmě bránit a to vcelku jednoduše. Mezi způsoby obrany proti SQL Injection patří: Validace dat - je jedním ze způsobů obrany, při kterém se ověřuje vstup z formulářových prvků podle určitého podkladu. V ASP.NET k tomuto účelu slouží různé validační prvky jako RegularExpressionValidator, RangeValidator, CustomValidator. Parametrizované dotazy - jsou další způsob, jak SQL Injection pokořit. Jedná se o využití parametrizovaných vstupů v SQL dotazech. Tyto vstupy jsou před vykonáním dotazu automaticky ošetřeny o nebezpečné znaky Cross-Site Scripting (XSS) Jedná se o útoky prováděné klientským skriptovacím jazykem (JavaScript, Jscript a jiné), případně HTML, XHTML.13. Útočníkovi je díky bezpečnostní mezeře povoleno webové aplikaci podstrčit vlastní kód. Tento kód může být až tak nebezpečný, že danou stránku znefunkční nebo díky němu získá citlivá uživatelská data. Mezi nejznámější typy útoků patří: Perzistentní útok - provádí se, pokud je obsah stránky brán z databáze. Například návštěvní kniha, diskusní fóra. V případě, že vložíme do návštěvní knihy příspěvěk obsahující skript, je následně uložen do databáze a zobrazen všem uživatelům, kteří do návštěvní knihy vstoupí. Okamžitý útok (non-persistent) - provádí se úpravou části URL adresy. Na rozdíl od perzistentního útoku se skript provede ihned po odeslání požadavku na server. Lokální útok - je proveden tak, že škodlivý kód je spuštěn z uživatelského počítače. Útočí se tedy na lokální webové aplikace. Například Internet Explorer považuje klientské skripty spouštěné v lokální zóně za bezpečné. Je jim dovoleno přistupovat k souborům na disku a zneužití těchto skriptů nese veliké riziko. (cs.wikipedia.org/wiki/cross-site_scripting) ASP.NET poskytuje vestavěnou obranu proti tomuto typu útoků. Je však stále potřeba validovat vstupní data jako hlavičky, formulářová pole, cookies a nepřiřazovat data formulářových polí přímo. Vestavěná obrana je reprezentována parametrem ValidateRequest. Je zde i další předprogramovaná obrana EnableEventValidation. Ta snižuje riziko neoprávněných postbacků a callbacků. Oba parametry jsou v základní konfiguraci nastaveny na hodnotu true. 13 Novější verze jazyka HTML. 47

48 Pro ASP.NET je také volně stažitelná knihovna Anti-XSS na MSDN portále obsahující potřebné nástroje pro účinnou obranu. Obrázek 20: Ilustrace perzistentního XSS útoku Zdroj: Vlastní ilustrace 11.3 Session hijacking Jedná se o útok, jehož cílem je získat uživatelskou session určité webové aplikace. Díky tomu se útočník bude moci přihlásit do webové aplikace pod uživatele, jehož session získal. Útočník může session uživatele získat několika způsoby: Útok hrubou silou při němž se útočník snaží session ID uhodnout. Například pomocí programu, který náhodně generuje session ID. Útok, který se snaží session ID spočítat, nikoliv náhodně vygenerovat. Session fixation znamená útok, při kterém útočník vygeneruje nové session ID a snaží se ho oběti podstrčit. Steal útok používá různé techniky jako Cross-Site Scripting, Man-In-The-Middle k získání session ID. (cs.wikipedia.org/wiki/session#session_hijacking) ASP.NET generuje session ID o velikosti 120-bit, takže útok hrubou silou či odhad dá útočníkovi pěkně zabrat. Dalším důležitým bezpečnostním prvkem je nastavit platnost session po určitou dobu. Webová aplikace by také měla používat protokol SSL (viz kapitola ), který se postará o to, aby útočník s odcizenou session ID nemohl nic podniknout. Před XSS útokem na 48

49 cookies se bráníme pomocí příkazu HttpOnly, ten zabrání přístup skriptů k těmto cookies. HttpOnly můžeme nastavit například v souboru Web.config. <httpcookies httponlycookies="true"/> Jednotlivé Cookies pak obsahují část, ve které je vyznačeno, že se jedná o HttpOnly. Na to reaguje internetový prohlížeč (který ovšem příkaz HttpOnly podporuje) a omezí veškerý přístup klientských skriptů k hodnotám Cookies. Mezi prohlížeče podporující tuto funkčnost patří například: Internet Explorer 8, Mozzila Firefox 5.0.1, Opera 11, Safari 5, Google Chrome 13 a jiné. Obrázek 21: Ilustrace útoku session fixation Zdroj: ptgmedia.pearsoncmg.com/images/chap4_ /elementlink s/04fig17.jpg, vlastní úprava 11.4 Man-In-The-Middle Útočník se snaží odposlouchávat komunikaci mezi účastníky tak, že se stane prostředníkem. Tedy veškerá komunikace půjde přes něj a oběť si toho ani nevšimne. Mějme příklad s Alicí a Bobem, kde si mezi sebou vymění veřejné klíče. Útočník zachytí klíč Alice, zamění ho za svůj a pošle Bobovi. Stejně postupuje i u Boba. Výsledkem je, že Alice a Bob šifrují zprávu veřejným klíčem útočníka a vůbec o tom nevědí. Kdykoliv tedy Alice nebo Bob něco pošlou, útočník to zachytí a dešifruje svým klíčem, znovu zašifruje a následně odešle druhé straně. (www.krypta.cz/articles.php?id=94) 49

50 Před tímto typem útoku se bráníme pomocí důvěryhodné třetí strany, v případě webových aplikací certifikační autoritou (viz ). Ta klíč Alice a Boba podepíše a v situaci záměny klíčů za útočníkův druhá strana zjistí, že to není klíč, který má obdržet. Obrázek 22: Princip útoku Man-In-The-Middle Zdroj: Vlastní ilustrace 11.5 Denial of Service (DoS) Útok spočívá ve snaze znepřístupnit určité internetové stránky nebo služby. Nejedná se o průnik do systému s cílem získat nebo poškodit data. Hlavním principem DoS útoků je přehltit server požadavky, aby neměl čas na vyřízení ostatních. Při přehlcení serveru požadavky docílíme toho, že doba odezvy pro normální uživatele je zcela nesnesitelná, nebo celý server spadne. DoS útoky obsahují mnoho různých druhů, cíl útoku je ale stejný. Distribuovaný DoS (DDoS) využívá více počítačů k útoku. Počet počítačů může sahat až k tisícům. Tohoto čísla útočník docílí pomocí infikování počítačů škodlivým kódem, který pak provádí tento útok. Infikovaný počítač je označován jako Zombie. Ping of Death je útok pomocí pozměněných paketů v protokolu IP. Tato změna se týkala velikosti paketu a docházelo tak většinou k přetečení zásobníku (buffer overflow) a pádu webové aplikace. Tento typ útoku je již velmi starý a známý. Většina systémů je v dnešní době proti tomuto útoku imunní. 50

51 SYN Flood je jeden z nejrozšířenějších útoků. Na cílový server jsou odesílány falešné požadavky SYN, které slouží pro zahájení komunikace klienta se serverem. Při velkém množství těchto falešných požadavků dojde k zaplnění bufferů pro polootevřená spojení a server nebude schopen obsluhovat další příchozí SYN požadavky. SYN Flood se ve většině případů kombinuje s falšováním IP adres (IP spoofing) 14. V prostředí IIS a ASP.NET se proti těmto útokům můžeme účinně bránit pomocí kvalitní konfigurace síťových uzlů. Z hlediska webového serveru existuje v IIS takzvané škrcení aplikací. To má za úkol omezit počet žádostí, kterým bude vyhověno. Dále můžeme obranu implementovat přímo v kódu ASP.NET. (http://www.adminxp.cz/security/index.php?aid=193) Obrázek 23: Princip DDoS útoku Zdroj: Vlastní ilustrace 14 Útočník maskuje vlastní IP adresu, nebo se vydává za někoho jiného. 51

52 11.6 Automatizované zakládání účtů Princip tohoto útoku spočívá v zakládání mnoha účtů v cílené webové aplikaci. Tohoto útoku se využívá například na mailové schránky, které následně slouží jako zdroj spamu 15. Tento útok je nepříjemný z hlediska dat v databázi. V případě, že útočník začne generovat jeden registrační formulář za druhým a nebude mu v tom nic bránit, tak to pro naši aplikaci zrovna ideální zabezpečení není. Může se lehce stát, že databáze bude během chvilky plná a uživatelé se nebudou moci registrovat. Ochrana před tímto typem útoku je takzvaná CAPTCHA (Completely Automated Public Turing test to tell Computers and Humans Apart). Jedná se o Turingův test 16, kde má dotazující za úkol opsat kód z vygenerovaného obrázku nebo mluveného textu. Na internetu je CAPTCHA poskytována mnoha společnostmi zdarma. Mezi hojně využívanou patří Recaptcha, která obsahuje i mluvený text pro zrakově postižené. Obrázek 24: Recaptcha umístěná ve formuláři Zdroj: Autorem vytvořeno v Google Chrome CAPTCHA však není jistá obrana. Vynalézaví hackeři vytvářejí nové a nové možnosti, jak tento typ obrany obejít. To se podařilo například u nejznámějšího českého webu Seznam.cz, Yahoo! či ového serveru Hotmail. V dnešní době existuje i software pro rozpoznávání a analýzu zvuku, takže prolomit audio ochranu lze také. 15 Nevyžádané sdělení zaplavující ovou schránku, diskusní fóra atd. 16 Standardní podoba testu spočívá v rospoznání člověka od stroje. 52

53 11.7 Kritická bezpečnostní chyba I ASP.NET se nevyhne chybám v implementaci. Mezi poslední kritickou chybu v předešlém roce patří možnost dekódovat zašifrovaná data na vzdáleném serveru a získání dat z webových aplikací ASP.NET, jako je například soubor Web.config. Při využití této chyby lze získat přístup k administrátorským účtům aplikací. Na tuto zranitelnost byl vydán již hotfix. Samotný útok se prováděl tak, že hacker zahltil aplikaci šifrovaným textem a následně si zaznamenávál obsah chybových hlášení. Opakováním tohoto procesu a analýzou chybových hlášek byl pak schopen získat šifrovací klíč a vytvořit si tak cestu k zakódovanému obsahu. (http://computerworld.cz/bezpecnost/microsoft-varuje-pred-kritickou-chybou-v-asp-net-kteraohrozuje-web-7741 ) 53

54 12. MULTIUŽIVATELSKÁ APLIKACE Kapitola popisuje důležité kroky při tvorbě ASP.NET aplikace, ve které implementuji většinu probraných bezpečnostních prvků v této bakalářské práci. V práci se snažím využít všech výhod programování ASP.NET aplikací ve Visual Studiu Implementační technologie Pro vývoj aplikace BOSS travel byl použit:.net Framework verze 4.0 Programovací jazyk C# 2010 Microsoft Visual Studio 2010 Ultimate verze 10.0 Microsoft SQL Server 2008 R2 Internet Information Services (IIS) verze 7.5 Microsoft SQL Server Management Studio verze Popis aplikace Slouží pro demonstraci bezpečnostních prvků v rámci ASP.NET. Je zde pracováno s ověřováním založeným na formulářich a autorizace je prováděna podle adresy URL. Aplikace dále pracuje na základě API členství a rolí. Logika aplikace je řešena pomocí webových služeb WCF. Pro bezpečnou komunikaci je použit SSL protokol s self-signed certifikátem. Cílem aplikace je vyhnout se nejznámějším útokům (viz kapitola 10) v prostředí webových aplikací a uchovávat tak bezpečně citlivá data uživatelů. Obrázek 25: Funkčnosti aplikace Zdroj: Vlastní ilustrace 54

55 Big picture řešení Obrázek 26: Big picture řešení Zdroj: Vlastní ilustrace 55

Část IV - Bezpečnost 21. Kapitola 19 Bezpečnostní model ASP.NET 23

Část IV - Bezpečnost 21. Kapitola 19 Bezpečnostní model ASP.NET 23 5 Obsah O autorech 15 O odborných korektorech 15 Úvod 16 Rozdělení knihy 16 Komu je tato kniha určena? 18 Co potřebujete, abyste mohli pracovat s touto knihou? 18 Sdělte nám svůj názor 18 Zdrojové kódy

Více

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

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 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íce

Informační systém pro e-learning manuál

Informační systém pro e-learning manuál Informační systém pro e-learning manuál Verze 1.00 Úvod Tento dokument popisuje způsob práce s informačním systémem pro elektronické vzdělávání. Systém je určený pro vytvoření elektronického kurzu a jeho

Více

Šifrování Autentizace Bezpečnostní slabiny. Bezpečnost. Lenka Kosková Třísková, NTI TUL. 22. března 2013

Š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íce

SSL Secure Sockets Layer

SSL 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íce

Elektronický podpis. Základní princip. Digitální podpis. Podpis vs. šifrování. Hashování. Jednosměrné funkce. Odesílatel. Příjemce

Elektronický podpis. Základní princip. Digitální podpis. Podpis vs. šifrování. Hashování. Jednosměrné funkce. Odesílatel. Příjemce Základní princip Elektronický podpis Odesílatel podepíše otevřený text vznikne digitálně podepsaný text Příjemce ověří zda podpis patří odesílateli uvěří v pravost podpisu ověří zda podpis a text k sobě

Více

Internet Information Services (IIS) 6.0

Internet Information Services (IIS) 6.0 Internet Information Services (IIS) 6.0 V operačním systému Windows Server 2003 je obsažena i služba IIS v 6.0. Služba IIS poskytuje jak www server tak i některé další služby (FTP, NNTP,...). Jedná se

Více

POKYNY K REGISTRACI PROFILU ZADAVATELE

POKYNY K REGISTRACI PROFILU ZADAVATELE POKYNY K REGISTRACI PROFILU ZADAVATELE Stav ke dni 4. 12. 2012 Obsah: 1 Úvod... 3 1.1 Podmínky provozu... 3 1.2 Pokyny k užívání dokumentu... 3 2 Registrace profilu zadavatele... 4 2.1 Přihlášení uživatele...

Více

Asymetrická kryptografie a elektronický podpis. Ing. Mgr. Martin Henzl Mgr. Radim Janča ijanca@fit.vutbr.cz

Asymetrická kryptografie a elektronický podpis. Ing. Mgr. Martin Henzl Mgr. Radim Janča ijanca@fit.vutbr.cz Asymetrická kryptografie a elektronický podpis Ing. Mgr. Martin Henzl Mgr. Radim Janča ijanca@fit.vutbr.cz Obsah cvičení Asymetrická, symetrická a hybridní kryptografie Matematické problémy, na kterých

Více

Zabezpečení proti SQL injection

Zabezpečení proti SQL injection Zabezpečení proti SQL injection ESO9 intranet a.s. Zpracoval: Tomáš Urych U Mlýna 2305/22, 141 Praha 4 Záběhlice Dne: 19.9.2012 tel.: +420 585 203 370-2 e-mail: info@eso9.cz Revize: Urych Tomáš www.eso9.cz

Více

Registr práv a povinností

Registr práv a povinností Registr práv a povinností Doporučené postupy a nastavení internetového prohlížeče pro práci v aplikaci AIS RPP Doporučené postupy a nastavení internetového prohlížeče pro práci v aplikaci AIS RPP v4.0

Více

APS Administrator.OP

APS Administrator.OP APS Administrator.OP Rozšiřující webový modul pro APS Administrator Přehled přítomnosti osob v oblastech a místnostech Instalační a uživatelská příručka 2004 2013,TECH FASS s.r.o., Věštínská 1611/19, Praha,

Více

Kryptografie, elektronický podpis. Ing. Miloslav Hub, Ph.D. 27. listopadu 2007

Kryptografie, elektronický podpis. Ing. Miloslav Hub, Ph.D. 27. listopadu 2007 Kryptografie, elektronický podpis Ing. Miloslav Hub, Ph.D. 27. listopadu 2007 Kryptologie Kryptologie věda o šifrování, dělí se: Kryptografie nauka o metodách utajování smyslu zpráv převodem do podoby,

Více

Národní elektronický nástroj. Import profilu zadavatele do NEN

Národní elektronický nástroj. Import profilu zadavatele do NEN Národní elektronický nástroj Import profilu zadavatele do NEN V 1.2 2014 Obsah 1 Cíl...... 2 2 Nutné podmínky k umožnění importu profilu zadavatele...... 2 3 Povinnosti zadavatele dle metodiky k vyhlášce

Více

[1] ICAReNewZEP v1.2 Uživatelská příručka

[1] ICAReNewZEP v1.2 Uživatelská příručka [1] ICAReNewZEP v1.2 Uživatelská příručka 06.10.2011 [2] Obsah 1 - ÚVOD... 3 2 - POUŽITÉ ZKRATKY... 3 3 POŽADAVKY... 4 3.1 POŽADAVKY PRO SPRÁVNÝ CHOD APLIKACE... 4 3.2 POŽADAVKY NA OBNOVOVANÝ CERTIFIKÁT...

Více

Příručka nastavení funkcí snímání

Příručka nastavení funkcí snímání Příručka nastavení funkcí snímání WorkCentre M123/M128 WorkCentre Pro 123/128 701P42171_CS 2004. Všechna práva vyhrazena. Uplatňovaná ochrana autorských práv se vztahuje na všechny formy a záležitosti

Více

Obsah. Úroveň I - Přehled. Úroveň II - Principy. Kapitola 1. Kapitola 2

Obsah. Úroveň I - Přehled. Úroveň II - Principy. Kapitola 1. Kapitola 2 Úroveň I - Přehled Úroveň II - Principy Kapitola 1 Kapitola 2 1. Základní pojmy a souvislosti 27 1.1 Zpráva vs. dokument 27 1.2 Písemná, listinná a elektronická podoba dokumentu 27 1.3 Podpis, elektronický

Více

Konfigurace pracovní stanice pro ISOP-Centrum verze 1.21.32

Konfigurace pracovní stanice pro ISOP-Centrum verze 1.21.32 Informační systém ISOP 7-13 Vypracováno pro CzechInvest Konfigurace pracovní stanice pro ISOP-Centrum verze 1.21.32 vypracovala společnost ASD Software, s.r.o. Dokument ze dne 20.2.2015, verze 1.00 Konfigurace

Více

Mobilita a roaming Možnosti připojení

Mobilita a roaming Možnosti připojení Projekt Eduroam Projekt Eduroam je určený pro bezdrátové a pevné připojení mobilních uživatelů do počítačové sítě WEBnet. Mohou jej využívat studenti, zaměstnanci a spřátelené organizace. V rámci tohoto

Více

Extrémně silné zabezpečení mobilního přístupu do sítě.

Extrémně silné zabezpečení mobilního přístupu do sítě. Extrémně silné zabezpečení mobilního přístupu do sítě. ESET Secure Authentication (ESA) poskytuje silné ověření oprávnění přístupu do firemní sítě a k jejímu obsahu. Jedná se o mobilní řešení, které používá

Více

Gymnázium a Střední odborná škola, Rokycany, Mládežníků 1115

Gymnázium a Střední odborná škola, Rokycany, Mládežníků 1115 Gymnázium a Střední odborná škola, Rokycany, Mládežníků 1115 Číslo projektu: Číslo šablony: 28 CZ.1.07/1.5.00/34.0410 Název materiálu: Ročník: Identifikace materiálu: Jméno autora: Předmět: Tématický celek:

Více

Testovací protokol. webový generátor PostSignum. sada PIIX3; 1 GB RAM; harddisk 20 GB IDE OS: Windows Vista Service Pack 2 SW: Internet Explorer 9

Testovací protokol. webový generátor PostSignum. sada PIIX3; 1 GB RAM; harddisk 20 GB IDE OS: Windows Vista Service Pack 2 SW: Internet Explorer 9 Příloha č. 4 1 Informace o testování estovaný generátor: 2 estovací prostředí estovací stroj č. 1: estovací stroj č. 2: estovací stroj č. 3: Certifikáty vydány autoritou: estovací protokol webový generátor

Více

Architektura rodiny operačních systémů Windows NT Mgr. Josef Horálek

Architektura rodiny operačních systémů Windows NT Mgr. Josef Horálek Architektura rodiny operačních systémů Windows NT Mgr. Josef Horálek = Velmi malé jádro = implementuje jen vybrané základní mechanismy: = virtuální paměť; = plánování vláken; = obsluha výjimek; = zasílání

Více

Šifrování ve Windows. EFS IPSec SSL. - Encrypting File System - Internet Protocol Security - Secure Socket Layer - Private Point to Point Protocol

Šifrování ve Windows. EFS IPSec SSL. - Encrypting File System - Internet Protocol Security - Secure Socket Layer - Private Point to Point Protocol Šifrování ve Windows EFS IPSec SSL PPTP - Encrypting File System - Internet Protocol Security - Secure Socket Layer - Private Point to Point Protocol 18.11.2003 vjj 1 Bezpečnost? co chci chránit? systém

Více

Max Homebanking PS uživatelský manuál rozhraní pro automatické stahování dat

Max Homebanking PS uživatelský manuál rozhraní pro automatické stahování dat Max Homebanking PS uživatelský manuál rozhraní pro automatické stahování dat Obsah 1 Úvod... 2 2 Nastavení přístupů k rozhraní... 2 2.1 Popis obrazovky... 2 2.1.1 Nastavení datových extraktů z banky...

Více

Dokumentace. k projektu Czech POINT. Popis použití komerčního a kvalifikovaného certifikátu

Dokumentace. k projektu Czech POINT. Popis použití komerčního a kvalifikovaného certifikátu Dokumentace k projektu Czech POINT Popis použití komerčního a kvalifikovaného certifikátu Vytvořeno dne: 11.4.2007 Aktualizováno: 19.2.2009 Verze: 3.3 2009 MVČR Obsah 1. Vysvětleme si pár pojmů...3 1.1.

Více

Co je Czech Point? Podací Ověřovací Informační Národní Terminál, zredukovat přílišnou byrokracii ve vztahu

Co je Czech Point? Podací Ověřovací Informační Národní Terminál, zredukovat přílišnou byrokracii ve vztahu Czech Point Co je Czech Point? Podací Ověřovací Informační Národní Terminál, tedy Czech POINT je projektem, který by měl zredukovat přílišnou byrokracii ve vztahu občan veřejná správa. Czech POINT bude

Více

Bezpečnost v ASP.NET. Ladislav Mrnka lmrnka@students.zcu.cz

Bezpečnost v ASP.NET. Ladislav Mrnka lmrnka@students.zcu.cz Bezpečnost v ASP.NET Ladislav Mrnka lmrnka@students.zcu.cz Motto If anyone tells you that security ends with the OS, they are dead wrong. Many times excellent network and hostbased security has been bypassed

Více

Uživatelská příručka

Uživatelská příručka Uživatelská příručka Popis postupu nastavení zabezpečené komunikace s CDS pomocí aplikace Outlook Express. Verze: C 23.10.2007 CDS D4_Instalace_OutlookExpressSettings.doc Strana 1 z 10 OBSAH 1 Úvod a shrnutí...4

Více

Registr práv a povinností

Registr práv a povinností Registr práv a povinností Doporučené postupy a nastavení internetového prohlížeče pro práci v aplikaci AIS RPP list č.1/20 OBSAH 1 Úvod... 3 2 Doporučené nastavení prohlížeče... 4 2.1 Problém s certifikátem...

Více

MATLABLINK - VZDÁLENÉ OVLÁDÁNÍ A MONITOROVÁNÍ TECHNOLOGICKÝCH PROCESŮ

MATLABLINK - VZDÁLENÉ OVLÁDÁNÍ A MONITOROVÁNÍ TECHNOLOGICKÝCH PROCESŮ MATLABLINK - VZDÁLENÉ OVLÁDÁNÍ A MONITOROVÁNÍ TECHNOLOGICKÝCH PROCESŮ M. Sysel, I. Pomykacz Univerzita Tomáše Bati ve Zlíně, Fakulta aplikované informatiky Nad Stráněmi 4511, 760 05 Zlín, Česká republika

Více

Artlingua Translation API

Artlingua Translation API Artlingua Translation API Dokumentace Jan Šváb, Artlingua, a.s. 2015 Revize: 2015-09-22 - verze API : v1 Obsah Obsah... 2 Předávání dokumentů k překladu... 3 Implementace klientské aplikace pro Translation

Více

Provozní dokumentace. Seznam orgánů veřejné moci. Příručka pro běžného uživatele

Provozní dokumentace. Seznam orgánů veřejné moci. Příručka pro běžného uživatele Provozní dokumentace Seznam orgánů veřejné moci Příručka pro běžného uživatele Vytvořeno dne: 7. 7. 2011 Aktualizováno: 11. 2. 2015 Verze: 2.2 2015 MVČR Obsah Příručka pro běžného uživatele 1 Úvod...3

Více

Certifikát. První kroky s certifikátem

Certifikát. První kroky s certifikátem Certifikát První kroky s certifikátem Vážená klientko, vážený kliente, děkujeme Vám za projevení důvěry a blahopřejeme k získání Vašeho certifikátu. Co je to osobní certifikát Osobní certifikát je soubor,

Více

1 Administrace systému 3. 1.3 Moduly... 3 1.4 Skupiny atributů... 4 1.5 Atributy... 4 1.6 Hodnoty atributů... 4

1 Administrace systému 3. 1.3 Moduly... 3 1.4 Skupiny atributů... 4 1.5 Atributy... 4 1.6 Hodnoty atributů... 4 CRM SYSTÉM KORMORÁN PŘÍRUČKA ADMINISTRÁTORA Obsah 1 Administrace systému 3 1.1 Uživatelské účty.................................. 3 1.2 Přístupová práva................................. 3 1.3 Moduly.......................................

Více

Programové vybavení OKsmart pro využití čipových karet

Programové vybavení OKsmart pro využití čipových karet Spojujeme software, technologie a služby Programové vybavení OKsmart pro využití čipových karet Ukázky biometrické autentizace Ing. Vítězslav Vacek vedoucí oddělení bezpečnosti a čipových karet SmartCard

Více

Uživatelská dokumentace

Uživatelská dokumentace Uživatelská dokumentace Verze 14-06 2010 Stahování DTMM (v rámci služby Geodata Distribution) OBSAH OBSAH...2 1. O MAPOVÉM SERVERU...3 2. NASTAVENÍ PROSTŘEDÍ...3 2.1 Hardwarové požadavky...3 2.2 Softwarové

Více

9. Sítě MS Windows. Distribuce Windows. Obchodní označení. Jednoduchý OS pro osobní počítače, pouze FAT, základní podpora peer to peer sítí,

9. Sítě MS Windows. Distribuce Windows. Obchodní označení. Jednoduchý OS pro osobní počítače, pouze FAT, základní podpora peer to peer sítí, 9. Sítě MS Windows MS Windows existoval ve 2 vývojových větvích 9x a NT, tyto později byly sloučeny. V současnosti existují aktuální verze Windows XP a Windows 2003 Server. (Očekává se vydání Windows Vista)

Více

Správa zařízení Scan Station Pro 550 a Servisní nástroje zařízení Scan Station

Správa zařízení Scan Station Pro 550 a Servisní nástroje zařízení Scan Station Správa zařízení Scan Station Pro 550 a Servisní nástroje zařízení Scan Station Konfigurační příručka A-61732_cs 7J4367 Správa zařízení Kodak Scan Station Pro 550 Obsah Rozdíly... 1 Instalace... 2 Vytváření

Více

Uživatelská dokumentace

Uživatelská dokumentace Uživatelská dokumentace k projektu CZECH POINT Popis použití komerčního a kvalifikovaného certifikátu Vytvořeno dne: 20.5.2008 Aktualizováno: 23.5.2008 Verze: 1.3 Obsah Uživatelská dokumentace...1 Obsah...2

Více

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

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 Registrační číslo projektu: CZ.1.07/1.5.00/34.0553 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 schopnost, který je spolufinancován

Více

Současný svět Projekt č. CZ.2.17/3.1.00/32038, podpořený Evropským sociálním fondem v rámci Operačního programu Praha adaptabilita

Současný svět Projekt č. CZ.2.17/3.1.00/32038, podpořený Evropským sociálním fondem v rámci Operačního programu Praha adaptabilita Aktivní webové stránky Úvod: - statické webové stránky: pevně vytvořený kód HTML uložený na serveru, ke kterému se přistupuje obvykle pomocí protokolu HTTP (HTTPS - zabezpečený). Je možno používat i různé

Více

Úvod - Podniková informační bezpečnost PS1-2

Úvod - Podniková informační bezpečnost PS1-2 VŠFS; Aplikovaná informatika - 2006/2007 1 Bezpečnost informací BI Ing. Jindřich Kodl, CSc. Úvod - Podniková informační bezpečnost PS1-2 VŠFS; Aplikovaná informatika - 2006/2007 2 Literatura Kovacich G.L.:

Více

Internet, www, el. pošta, prohlížeče, služby, bezpečnost

Internet, www, el. pošta, prohlížeče, služby, bezpečnost Internet, www, el. pošta, prohlížeče, služby, bezpečnost Internet jedná se o fyzické propojení komponent nacházejících se v počítačových sítí všech rozsahů LAN, MAN, WAN. Patří sem koncové uživatelské

Více

Generování žádosti o certifikát Uživatelská příručka pro prohlížeč Opera

Generování žádosti o certifikát Uživatelská příručka pro prohlížeč Opera Generování žádosti o certifikát Uživatelská příručka pro prohlížeč Opera První certifikační autorita, a.s. Verze 8.15 1 Obsah 1. Úvod... 3 2. Požadavky na software... 3 3. Instalace kořenového certifikátu

Více

Michaela Sluková, Lenka Ščepánková 15.5.2014

Michaela Sluková, Lenka Ščepánková 15.5.2014 ČVUT FJFI 15.5.2014 1 Úvod 2 3 4 OpenPGP Úvod Jak? Zašifrovat email lze pomocí šifrování zprávy samotné či elektronickým podpisem emailových zpráv. Proč? Zprávu nepřečte někdo jiný a nemůže být změněna,

Více

1. Administrace služby Bezpečný Internet přes webovou aplikaci WebCare GTS

1. Administrace služby Bezpečný Internet přes webovou aplikaci WebCare GTS 1. Administrace služby Bezpečný Internet přes webovou aplikaci WebCare GTS Pro přístup do administrace služby GTS Bezpečný Internet používejte zákaznický WebCare GTS Czech, který je přístupny přes webové

Více

Microsoft SharePoint Portal Server 2003. Zvýšená týmová produktivita a úspora času při správě dokumentů ve společnosti Makro Cash & Carry ČR

Microsoft SharePoint Portal Server 2003. Zvýšená týmová produktivita a úspora času při správě dokumentů ve společnosti Makro Cash & Carry ČR Microsoft SharePoint Portal Server 2003 Zvýšená týmová produktivita a úspora času při správě dokumentů ve společnosti Makro Cash & Carry ČR Přehled Země: Česká republika Odvětví: Velkoobchod Profil zákazníka

Více

K práci je možné přistoupit následujícím způsobem. Odkaz na práci se nachází na osobním webu autora práce: http://stpr.cz/.

K práci je možné přistoupit následujícím způsobem. Odkaz na práci se nachází na osobním webu autora práce: http://stpr.cz/. 2. Seznámení K práci je možné přistoupit následujícím způsobem. Odkaz na práci se nachází na osobním webu autora práce: http://stpr.cz/. 2.1. Uživatel (učitel) Uživatelem (učitelem) se myslí osoba, která

Více

Bezpečnostní aspekty informačních a komunikačních systémů KS2

Bezpečnostní aspekty informačních a komunikačních systémů KS2 VŠFS; Aplikovaná informatika; SW systémy 2005/2006 1 Bezpečnost informací BI Ing. Jindřich Kodl, CSc. Bezpečnostní aspekty informačních a komunikačních systémů KS2 VŠFS; Aplikovaná informatika; SW systémy

Více

Nová áplikáce etesty zá te z ove testová ní

Nová áplikáce etesty zá te z ove testová ní Nová áplikáce etesty zá te z ove testová ní Verze 0.4 Datum aktualizace 28. 11. 2014 1 Obsah 1 Úvod... 2 1.1 Podpora - kontakty... 2 1.2 Zdroje... 2 1.3 Zkratky... 2 2 Předpoklady pro testování... 3 2.1

Více

Postup získání certifikátu pro uživatele WEB aplikací určených pro Sběry dat pro IS VaV

Postup získání certifikátu pro uživatele WEB aplikací určených pro Sběry dat pro IS VaV Postup získání certifikátu pro uživatele WEB aplikací určených pro Sběry dat pro IS VaV verze 1.2 Praha 18.12.2002 Obsah WEB aplikace určené pro sběry dat do CEP, CEZ a RIV plně podporují práci s certifikáty.

Více

SecureStore I.CA. Uživatelská příručka. Verze 2.16 a vyšší

SecureStore I.CA. Uživatelská příručka. Verze 2.16 a vyšší Uživatelská příručka Verze 2.16 a vyšší Obsah SecureStore I.CA 1. ÚVOD... 3 2. PŘÍSTUPOVÉ ÚDAJE KE KARTĚ... 3 2.1 Inicializace karty... 3 3. ZÁKLADNÍ OBRAZOVKA... 3 4. ZOBRAZENÍ INFORMACÍ O PÁRU KLÍČŮ...

Více

Práce s e-mailovými schránkami v síti Selfnet

Práce s e-mailovými schránkami v síti Selfnet Práce s e-mailovými schránkami v síti Selfnet Obsah návodu Základní informace k nastavení schránky selfnet.cz...2 Doporučené parametry nastavení e-mailového klienta...2 Základní informace k nastavení e-mailové

Více

Bezpečná autentizace přístupu do firemní sítě

Bezpečná autentizace přístupu do firemní sítě Bezpečná autentizace přístupu do firemní sítě ESET Secure Authentication (ESA) poskytuje silné ověření oprávnění přístupu do firemní sítě a k jejímu obsahu. Jedná se o mobilní řešení, které používá dvoufaktorové

Více

Příloha č. 12. Systém společného přihlašování, tzv. Single Sign On, ochrana dat

Příloha č. 12. Systém společného přihlašování, tzv. Single Sign On, ochrana dat Název projektu: Redesign Statistického informačního systému v návaznosti na zavádění egovernmentu v ČR Příjemce: Česká republika Český statistický úřad Registrační číslo projektu: CZ.1.06/1.1.00/07.06396

Více

Seminární práce do předmětu: Bezpečnost informačních systémů. téma: IPsec. Vypracoval: Libor Stránský

Seminární práce do předmětu: Bezpečnost informačních systémů. téma: IPsec. Vypracoval: Libor Stránský Seminární práce do předmětu: Bezpečnost informačních systémů téma: IPsec Vypracoval: Libor Stránský Co je to IPsec? Jedná se o skupinu protokolů zabezpečujících komunikaci na úrovni protokolu IP (jak už

Více

Jak efektivně ochránit Informix?

Jak efektivně ochránit Informix? Jak efektivně ochránit Informix? Jan Musil jan_musil@cz.ibm.com Informix CEE Technical Sales Information Management Jsou Vaše data chráněna proti zneužití? 2 Ano, pokud... 3 Nepoužitelné Steve Mandel,

Více

MS SQL Server 2008 Management Studio Tutoriál

MS SQL Server 2008 Management Studio Tutoriál MS SQL Server 2008 Management Studio Tutoriál Vytvoření databáze Při otevření management studia a připojením se ke konkrétnímu sql serveru mám v levé části panel s názvem Object Explorer. V tomto panelu

Více

Téma 3: Správa uživatelského přístupu a zabezpečení I. Téma 3: Správa uživatelského přístupu a zabezpečení I

Téma 3: Správa uživatelského přístupu a zabezpečení I. Téma 3: Správa uživatelského přístupu a zabezpečení I Téma 3: Správa uživatelského přístupu a zabezpečení I 1 Teoretické znalosti V tomto cvičení si vysvětlíme, co to uživatelské a skupinové účty a jak jsou ve Windows 7 spravovány. Vyzkoušíte optimalizaci

Více

Dokumentace. k projektu Czech POINT. Příručka pro správce AIS. Vytvořeno dne: 23. 1. 2012 Aktualizováno: - Verze: 1.0 2012 MVČR

Dokumentace. k projektu Czech POINT. Příručka pro správce AIS. Vytvořeno dne: 23. 1. 2012 Aktualizováno: - Verze: 1.0 2012 MVČR Dokumentace k projektu Czech POINT Příručka pro správce AIS Vytvořeno dne: 23. 1. 2012 Aktualizováno: - Verze: 1.0 2012 MVČR Obsah 1. Úvod...3 1.1. Účel dokumentu...3 1.2. Manažerské shrnutí...3 1.3. Definice

Více

Ing. Přemysl Brada, MSc., Ph.D. Ing. Martin Dostal. Katedra informatiky a výpočetní techniky, FAV, ZČU v Plzni

Ing. Přemysl Brada, MSc., Ph.D. Ing. Martin Dostal. Katedra informatiky a výpočetní techniky, FAV, ZČU v Plzni Webové aplikace Ing. Přemysl Brada, MSc., Ph.D. Ing. Martin Dostal Katedra informatiky a výpočetní techniky, FAV, ZČU v Plzni Harmonogram Dopolední blok 9:00 12:30 Ing. Dostal Úvod, XHTML + CSS Ing. Brada,

Více

BRICSCAD V15. Licencování

BRICSCAD V15. Licencování BRICSCAD V15 Licencování Protea spol. s r.o. Makovského 1339/16 236 00 Praha 6 - Řepy tel.: 235 316 232, 235 316 237 fax: 235 316 038 e-mail: obchod@protea.cz web: www.protea.cz Copyright Protea spol.

Více

Uživatelská příručka

Uživatelská příručka B2B CENTRUM a.s. 3.2011 Obsah Začínáme... 3 Přihlášení a zapomenuté heslo... 3 Vytvoření uživatele... 3 Editace osobních údajů... 5 Vkládání souborů... 6 Elektronický podpis... 8 Stavební deník... 11 Identifikační

Více

Administrace služby - GTS Network Storage

Administrace služby - GTS Network Storage 1. Návod k ovládání programu Cisco VPN Client (IP SECový tunel pro přístup GTS Network Storage) Program Cisco VPN client lze bezplatně stáhnout z webových stránek GTS pod odkazem: Software ke stažení http://www.gts.cz/cs/zakaznicka-podpora/technicka-podpora/gtspremium-net-vpn-client/software-ke-stazeni.shtml

Více

Certifikáty a jejich použití

Certifikáty a jejich použití Certifikáty a jejich použití Verze 1.0 Vydání certifikátu pro AIS Aby mohl AIS volat egon služby ISZR, musí mít povolen přístup k vnějšímu rozhraní ISZR. Přístup povoluje SZR na žádost OVM, který je správcem

Více

APS 400 nadministrator

APS 400 nadministrator APS 400 APS 400 nadministrator Balík programů pro správu systému APS 400 Instalační příručka 2004 2008,TECH FASS s.r.o., Plavecká 503, 252 42 Jesenice, www.techfass.cz, techfass@techfass.cz (vydáno dne

Více

Průvodce instalací modulu Offline VetShop verze 3.4

Průvodce instalací modulu Offline VetShop verze 3.4 Průvodce instalací modulu Offline VetShop verze 3.4 Úvod k instalaci Tato instalační příručka je určena uživatelům objednávkového modulu Offline VetShop verze 3.4. Obsah 1. Instalace modulu Offline VetShop...

Více

Použití programu WinProxy

Použití programu WinProxy JIHOČESKÁ UNIVERZITA V ČESKÝCH BUDĚJOVICÍCH PEDAGOGICKÁ FAKULTA KATEDRA INFORMATIKY Použití programu WinProxy pro připojení domácí sítě k internetu Semestrální práce z předmětu Lokální počítačové sítě

Více

db-direct internet Customer Self Administration (vlastní správa uživatelů) Uživatelská příručka

db-direct internet Customer Self Administration (vlastní správa uživatelů) Uživatelská příručka db-direct internet Customer Self Administration (vlastní správa uživatelů) Uživatelská příručka Deutsche Bank, pobočka Praha Verze 8.2 červenec 2009 Obsah Obsah... 1 Úvod... 2 Detailní popis... 3 Zavedení

Více

TECHNICKÁ SPECIFIKACE VEŘEJNÉ ZAKÁZKY

TECHNICKÁ 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íce

Bezpečnost v Gridech. Daniel Kouřil EGEE kurz 12. prosince 2006. Enabling Grids for E-sciencE. www.eu-egee.org

Bezpečnost v Gridech. Daniel Kouřil EGEE kurz 12. prosince 2006. Enabling Grids for E-sciencE. www.eu-egee.org Bezpečnost v Gridech Daniel Kouřil EGEE kurz 12. prosince 2006 www.eu-egee.org EGEE and glite are registered trademarks Proč bezpečnost Ochrana uživatele citlivá data ochrana výzkumu Ochrana majitele prostředků

Více

Odesílání citlivých dat prostřednictvím šifrovaného emailu s elektronickým podpisem standardem S/MIME

Odesílání citlivých dat prostřednictvím šifrovaného emailu s elektronickým podpisem standardem S/MIME Odesílání citlivých dat prostřednictvím šifrovaného emailu s elektronickým podpisem standardem S/MIME Je dostupnou možností, jak lze zaslat lékařskou dokumentaci elektronicky. Co je třeba k odeslání šifrovaného

Více

Šifrování (2), FTP. Petr Koloros p.koloros [at] sh.cvut.cz. http://sut.sh.cvut.cz

Šifrování (2), FTP. Petr Koloros p.koloros [at] sh.cvut.cz. http://sut.sh.cvut.cz Šifrování (2), FTP Petr Koloros p.koloros [at] sh.cvut.cz http://sut.sh.cvut.cz Obsah Úvod do šifrování FTP FTP server ProFTPd Šifrovaný přístup Virtuální servery Síť FTPek na klíč FTP File Transfer Protokol

Více

Instalace Active Directory

Instalace Active Directory Instalace Active Directory Proces implementace Active Directory se sestává z několika kroků. Před vlastní instalací je zapotřebí zvážit mnoho faktorů. Špatně navržená struktura Active Directory způsobí

Více

2015 GEOVAP, spol. s r. o. Všechna práva vyhrazena.

2015 GEOVAP, spol. s r. o. Všechna práva vyhrazena. 2015 GEOVAP, spol. s r. o. Všechna práva vyhrazena. GEOVAP, spol. s r. o. Čechovo nábřeží 1790 530 03 Pardubice Česká republika +420 466 024 618 http://www.geovap.cz V dokumentu použité názvy programových

Více

Aplikace a služba Money Dnes Publisher v deseti krocích

Aplikace a služba Money Dnes Publisher v deseti krocích 2 Money Dnes Publisher Uživatelská příručka Aplikace a služba Money Dnes Publisher v deseti krocích Tento step-by-step manuál vás provede korektním nastavením ovladače Money Dnes Publisher pomocí přiloženého

Více

GTL GENERATOR NÁSTROJ PRO GENEROVÁNÍ OBJEKTŮ OBJEKTY PRO INFORMATICA POWERCENTER. váš partner na cestě od dat k informacím

GTL GENERATOR NÁSTROJ PRO GENEROVÁNÍ OBJEKTŮ OBJEKTY PRO INFORMATICA POWERCENTER. váš partner na cestě od dat k informacím GTL GENERATOR NÁSTROJ PRO GENEROVÁNÍ OBJEKTŮ OBJEKTY PRO INFORMATICA POWERCENTER váš partner na cestě od dat k informacím globtech spol. s r.o. karlovo náměstí 17 c, praha 2 tel.: +420 221 986 390 info@globtech.cz

Více

KSRZIS. Postup kroků nutných pro napojení nemocničního informačního systému s registrem NSHNU v prostředí registrů resortu zdravotnictví

KSRZIS. Postup kroků nutných pro napojení nemocničního informačního systému s registrem NSHNU v prostředí registrů resortu zdravotnictví Koordinační středisko pro resortní zdravotnické informační systémy Budějovická 15/743 140 00 Praha 4 Počet stran: 10 KSRZIS Postup kroků nutných pro napojení nemocničního informačního systému s registrem

Více

Postup pro vytvoření žádosti o digitální certifikát pro ověřovací a produkční prostředí Základních registrů

Postup pro vytvoření žádosti o digitální certifikát pro ověřovací a produkční prostředí Základních registrů Postup pro vytvoření žádosti o digitální certifikát pro ověřovací a produkční prostředí Základních registrů Verze dokumentu: 1.2 Datum vydání: 25.května 2012 Klasifikace: Veřejný dokument Obsah 1. Žádost

Více

Už ivatelska dokumentace

Už ivatelska dokumentace Už ivatelska dokumentace Aplikace Portál úspěšných projektů je určena k publikování informací o projektech realizovaných za přispění některého z Operačních programů v gesci Ministerstva vnitra České republiky.

Více

Autentizace uživatelů

Autentizace uživatelů Autentizace uživatelů základní prvek ochrany sítí a systémů kromě povolování přístupu lze uživatele členit do skupin, nastavovat různá oprávnění apod. nejčastěji dvojicí jméno a heslo další varianty: jednorázová

Více

Platforma.NET 11.NET Framework 11 Visual Basic.NET Základní principy a syntaxe 13

Platforma.NET 11.NET Framework 11 Visual Basic.NET Základní principy a syntaxe 13 Obsah Úvod 11 Platforma.NET 11.NET Framework 11 Visual Basic.NET 12 1 Základní principy a syntaxe 13 Typový systém 13 Hodnotové typy 13 Struktury 15 Výčtové typy 15 Referenční typy 15 Konstanty 16 Deklarace

Více

Active Directory organizační jednotky, uživatelé a skupiny

Active Directory organizační jednotky, uživatelé a skupiny Active Directory organizační jednotky, uživatelé a skupiny V databázi Active Directory jsou uloženy objekty organizačních jednotek, uživatelských účtů a skupin. Organizační jednotka představuje jakýsi

Více

Jan Forman Manuál 30.5.2013. CLASSIFICATIO N: public / veřejný dokument IDE NTIFICATIO N N U MBER: 0000000000001 AUTH OR:

Jan Forman Manuál 30.5.2013. CLASSIFICATIO N: public / veřejný dokument IDE NTIFICATIO N N U MBER: 0000000000001 AUTH OR: CLASSIFICATIO N: public / veřejný dokument TITLE: Manuál k webovému rozhraní hostingu P ub l i c URL: http://janforman.org/files/webhosting.pdf OFFICE NAME AND ADDRESS: --- IDE NTIFICATIO N N U MBER: 0000000000001

Více

Vývoj moderních technologií při vyhledávání. Patrik Plachý SEFIRA spol. s.r.o. plachy@sefira.cz

Vývoj moderních technologií při vyhledávání. Patrik Plachý SEFIRA spol. s.r.o. plachy@sefira.cz Vývoj moderních technologií při vyhledávání Patrik Plachý SEFIRA spol. s.r.o. plachy@sefira.cz INFORUM 2007: 13. konference o profesionálních informačních zdrojích Praha, 22. - 24.5. 2007 Abstrakt Vzhledem

Více

Microsoft Windows Server System

Microsoft Windows Server System Microsoft Windows Server System Uživatelský autentikační systém od společnosti truconnexion komplexně řeší otázku bezpečnosti interních počítačových systémů ebanky, a.s. Přehled Země: Česká republika Odvětví:

Více

Více úrovňové informační systémy a jejich certifikace podle zákona č.412/2005 Sb., ve znění pozdějších předpisů

Více úrovňové informační systémy a jejich certifikace podle zákona č.412/2005 Sb., ve znění pozdějších předpisů Více úrovňové informační systémy a jejich certifikace podle zákona č.412/2005 Sb., ve znění pozdějších předpisů Vyhláška č. 523/2005 Sb., o bezpečnosti informačních a komunikačních systémů a dalších elektronických

Více

Šachmatky Resortní část

Šachmatky Resortní část Instalační manuál Šachmatky Resortní část název dokumentu: autor: DATA SOLUTIONS s.r.o. verze: 1.0 datum: 11.05.11 stádium: důvěrnost: Finální verze Určeno správcům sítě název souboru: SM_Instalacni Manual_Resort_110511.doc

Více

Poznámky k verzi Remote support platform 3.1

Poznámky k verzi Remote support platform 3.1 What's New Verze dokumentu: 1.0 2014-05-09 Verze dokumentu Následující tabulka poskytuje přehled nejdůležitějších změn dokumentu. Verze Datum Popis 1.0 2014-05-09 První verze 2 All rights reserved. Verze

Více

Uživatelská dokumentace

Uživatelská dokumentace Uživatelská dokumentace Konfigurace webového prohlížeče Verze 01-04 2013 e-utilityreport - vyjadřování k existenci sítí OBSAH OBSAH... 2 1. O SLUŽBĚ E-UTILITYREPORT... 2 2. NASTAVENÍ PROSTŘEDÍ... 3 2.1

Více

Individuální projekt z předmětu webových stránek 2012/2013 - Anketa

Individuální projekt z předmětu webových stránek 2012/2013 - Anketa Individuální projekt z předmětu webových stránek 2012/2013 - Anketa Daniel Beznoskov, 2 IT A Skupina 1 Úvod Prohlášení o autorství Prohlašuji, že jsem individuální projekt z předmětu webových stránek na

Více

Vystavení osobního komerčního certifikátu PostSignum v operačním systému MAC OSx

Vystavení osobního komerčního certifikátu PostSignum v operačním systému MAC OSx Vystavení osobního komerčního certifikátu PostSignum v operačním systému MAC OSx Tento návod popisuje všechny kroky od vystavení certifikátu až po odeslání a podepsání dat v obchodním systému CS OTE v

Více