Bezpe čnosť informačných systémov

1. Bezpečnosť informačných systémov Bezpečnosť Java a J2EE aplikácii

2. Obsah • Bezpečnosť Java 2 aplikácii • Sandbox • Security Manager • Policy file • Bezpečnosť J2EE aplikácii • Úvod • Autentifikácia • Autorizácia • Security pattern

3. Bezpečnosť Java 2 aplikácie • Sandbox • SecurityManager • Policy File • Príklad

4. Sandbox • Bezpečnostný model prístupu aplikácii k zdrojom • Základnou myšlienkou je poskytnúť aplikácii priestor, aby mohla bežať a zároveň tento priestor obmedziť nejakými hranicami • Java sandbox je zodpovedný za ochranu mnoho zdrojov a to na rôznych úrovniach.

5. Rôzne úrovne obmedzenia • minimálny sandbox - obsahuje len zdroje potrebné na beh programu. Dovoľuje prístup k CPU, obrazovke, klávesnici, myške a jeho pridelenej pamäti. • Sandbox, ktorý okrem predchádzajúceho obsahuje aj prístup k web servru, z ktorého bol stiahnutý – štandardný typ. • Sandbox, ktorý okrem predchádzajúceho obsahuje možnosť prístupu k množine programovo špecifických zdrojov (lokálne súbory, lokálny počítač atď) • Otvorený sandbox, v ktorom programy majú prístup k ľubovoľným zdrojom.

6. Vývoj modelu sandbox – JDK 1.0 • pôvodný model • ponúkal veľmi obmedzené prostredie pre vykonávanie nedôveryhodného kódu (untrusted code) získaného z otvorenej siete • Kontrolu prístupu vykonáva security manager

7. Vývoj modelu sandbox – JDK 1.1 • JDK 1.1 poskytlo novú koncepciu podpisovania apletov • Ak bol aplet digitálne podpísaný a ak verejný kľúč určený na overenie podpisu bol rozpoznaný ako pravdivý, s apletom sa pracovalo ako s dôveryhodným (trusted) lokálnym kódom a bol mu poskytnutý plný prístup k systémovým zdrojom. • Podpísané aplety sa doručovali spolu s podpisom v označenom JAR súbore.

8. Vývoj modelu sandbox – JDK 1.2 • Aj lokálny a aj vzdialený kód sa stáva predmetom bezpečnostných zásad, ktoré definujú množinu práv • Oprávnenia sú pridelené zdrojom kódu • Konfigurácia sa vykonáva v súborebezpečnostných pravidiel (security policy) • Runtime systém organizuje kód do individuálnych domén • Každá doména sa zaoberá množinou tried, ktoré majú tie isté práva

9. Security Manager Môžeme si predstaviť štyri úrovne útoku na prostredie Java • Modifikácie systému, ak program má práva na čítanie a zápis a spraví nejaké zmeny v systéme • Porušenie súkromia, ak program má právo čítať a kradne súkromné údaje zo systému • Odopretie služby, ak program používa systémové prostriedky bez požiadania v takom rozsahu, že systém nedokáže vykonávať svoju činnosť (čas procesora a pod. – cycle stealing) • Falošná prezentácia, ak sa program tvári ako skutočný užívateľ systému, môže posielať maily vo vašom mene a pod. Security manager dokáže zabrániť prvým dvom z týchto útokov.

10. Security Manager • Security managerje hlavným prvkom pri riadení prístupu aplikácii k systémovým zdrojom. • Je súčasťou bežiaceho JVM a riadi prístup k vonkajším zdrojom. • Definuje vonkajšie hranice sandboxu a pretože je nastaviteľný, definuje aj rôznu bezpečnostnú politiku pre aplikáciu. • Java API podporuje rôznu bezpečnostnú politiku tým, že požiada security manager o povolenie ešte pred tým, než sa vykoná nejaká akcia. Toto požiadanie vykonávajú check- metódy, napr. checkWrite(). • Pred Java verziou 1.2 bol java.lang.SecurityMangerabstraktnou triedou a musel byť implementovaný. To bola veľmi náročná práca a obsahovala mnoho citlivých miest, ktoré mohli viesť k vzniku dier • Verzia 1.2 predstavila konkrétnu implementáciu triedy a dovolila definovať vlastnú bezpečnostnú politiku v ASCI súbore, nie v kóde programu. • Namiesto check-metód uviedla jednu metódu checkPermission().

11. Security Manager • Vo všeobecnosti aplikácia nemá pridelený security manager. To znamená, že JVM nevytvorí automaticky security manager pre každú Java aplikáciu a teda aplikácia môže vykonávať ľubovoľné operácie bez nejakých bezpečnostných obmedzení. • V aplikácii môžeme získať aktuálny security manager použitím triedy System: SecurityManager appsm = System.getSecurityManager(); if (security != null) { security.checkExit(status); }

12. Security Manager

13. Security Manager

14. Policy file • Policy file je ASCI textový súbor, ktorý môže byť vytvorený textovým editorom alebo pomocou grafického nástroja Policy Tool • Obsahuje bezpečnostné pravidlá pre security manager • Je to vlastne zoznam povolený pre jednotlivé kódy • Policy Tool sa nachádza v adresári JRE/bin/policytool.exe • Štandardný súbor sa nachádza v JRE/lib/security/java.policy

15. Štandardný súbor java.policy /* AUTOMATICALLY GENERATED ON Wed Apr 07 09:13:40 CEST 2004*/ /* DO NOT EDIT */ grant codeBase "file:${java.home}/lib/ext/*" { permission java.security.AllPermission; }; grant { permission java.lang.RuntimePermission "stopThread"; permission java.net.SocketPermission "localhost:1024-", "listen"; permission java.util.PropertyPermission "java.version", "read"; permission java.util.PropertyPermission "java.vendor", "read"; permission java.util.PropertyPermission "java.vendor.url", "read"; permission java.util.PropertyPermission "java.class.version", "read"; permission java.util.PropertyPermission "os.name", "read"; permission java.util.PropertyPermission "os.version", "read"; permission java.util.PropertyPermission "os.arch", "read"; permission java.util.PropertyPermission "file.separator", "read"; permission java.util.PropertyPermission "path.separator", "read"; permission java.util.PropertyPermission "line.separator", "read"; permission java.util.PropertyPermission "java.specification.version", "read"; permission java.util.PropertyPermission "java.specification.vendor", "read"; permission java.util.PropertyPermission "java.specification.name", "read"; permission java.util.PropertyPermission "java.vm.specification.version", "read"; permission java.util.PropertyPermission "java.vm.specification.vendor", "read"; permission java.util.PropertyPermission "java.vm.specification.name", "read"; permission java.util.PropertyPermission "java.vm.version", "read"; permission java.util.PropertyPermission "java.vm.vendor", "read"; permission java.util.PropertyPermission "java.vm.name", "read"; };

16. Všetky existujúce povolenia • java.security.AllPermission • java.secuity.BasicPermission • javax.sound.sampled.AudioPermission • javax.security.auth.AuthPermission • java.awt.AWTPermission • javax.security.auth.kerberos.DelegationPermission • java.util.logging.LoggingPermission • java.net.NetPermission • java.util.PropertyPermission • java.lang.reflect.ReflectPermission • java.lang.RuntimePermission • java.security.SecurityPermission • java.io.SerializablePermission • java.sql.SQLPermission • javax.net.ssl.SSLPermission • java.io.FilePermission javax.security.auth.kerberos.ServicePermission • java.security.UnresolvedPermission • javax.security.auth.PrivateCredentialPermission • java.net.SocketPermission

17. Skúmanie obmedzení apletu • Prehliadače pred spustením apletu inštalujú security manager, teda aplety bežia pod kontrolou tohto manažéra. Apletu nie je umožnené pristopovať k zdrojom, pokiaľ nemá explicitne definované oprávnenie. • Majme Aplet, ktorý sa snaží vykonať tieto akcie: • Získať user.home • Vytvoriť, resp. otvoriť súbor „writetest“ a zapísať doň niečo • Otvoriť dialógové okno pre tlač • Aplet nájdete na stránke www.intrak.sk/~bolibruch/BIS/priklad1

18. Skúmanie obmedzení apletu

19. Pridanie práv apletu • získanie user.home - aby sme mohli získať túto Property, je nutné pridať PropertyPermission pre náš aplet • postup: • spustíme  JRE/bin/policytool.exe • otvoríme java.policy súbor, ktorý sa nachádza v JRE/lib/security • klikneme na AddPolicyEntry • CodeBase – reprezentuje URL, pre ktorú sú určené dané povolenia • codeBase = http://w3.intrak.tuke.sk/~bolibruch/BIS/priklad1/ • Ak chceme, aby povolenia boli aj pre podadresáre, zadáme http://w3.intrak.tuke.sk/~bolibruch/BIS/- • stlačte AddPermission • vyberte PropertyPermission • do políčka target name napíšeme „user.home“ ako názov Property • z políčka Actions vyberieme read • Uložíme súbor a apletu sme umožnili získať user.home

20. Pridanie práv apletu

21. Pridanie práv apletu • pre zápis do súboru nastavíme FilePermission pre súbor writetest a pridelíme právo write • pre tlačenie – RuntimePermission, queuePrintJob

22. Pridanie práv apletu

23. Pridanie práv podpisom kódu Ukážeme si použitie týchto bezpečnostných nástrojov: • keytool • jarsigner • Policytool a samozrejme nástroj na vytvorenie jar súboru, aby sme mohli podpísať tento jar súbor.

24. Postup pre odosielateľa kódu

25. Postup pre odosielateľa kódu Odosielateľ kódu musí vykonať tieto kroky: • Vytvorenie aplikácie. • Vytvorenie JAR súboru pomocou nástroja jartool. • Generovanie kľúčov (ak neexistujú) pomocou keytool –genkey príkazu. • Voliteľný krok: Generovanie CSR (Certificate signing request) pre certifikát verejného kľúča a importovať odpoveď certifikačnej autority. • Podpísanie JAR súboru pomocou jarsigner a privátneho kľúča. • Exportovanie certifikátu verejného kľúča pomocou keytool – export príkazu

26. Vytvorenie aplikácie • import java.io.*; • public class Count { • public static void countChars(InputStream in) throws IOException • { • int count = 0; • while (in.read() != -1) • count++; • System.out.println("Counted " + count + " chars."); • } • public static void main(String[] args) throws Exception • { • if (args.length >= 1) • countChars(new FileInputStream(args[0])); • else • System.err.println("Usage: Count filename"); • } • }

27. Vytvorenie JAR súboru JAR súbor, ktorý bude obsahovať Count.class súbor vytvoríme takto: jar cvf Count.jar Count.class

28. Generovanie kľúčov • Ak ešte nemáme vhodný privátny kľúč na podpísanie kódu, musíme ho vygenerovať spolu s odpovedajúcim verejným kľúčom, ktorý sa použije na overenie podpisu. • Vytvoríme súbor pre uloženie kľúčov s názvom BIS. keytool -genkey -alias signFiles -keypass kpi135 -keystore BIS -storepass ab987c

29. Generovanie kľúčov • Príkaz na generovanie kľúča je -genkey • Časť –alias signFiles indikuje alias, ktorý sa použije na odkázanie sa na miesto obsahujúce kľúče • Časť –keypass kpi135 špecifikuje heslo pre generovaný privátny kľúč. Je vždy potrebné pre prístup ku kľúču • Časť –keystore BIS indikuje miesto, kde sa majú uložiť kľúče • Časť –storepass ab987c určuje heslo miesta uloženia kľúčov

30. Generovanie kľúčov

31. Podpísanie JAR súboru • Teraz môžeme podpísať JAR súbor. Na podpísanie JAR súboru Count.jar použijeme privátny kľúč, ku ktorému pristúpime pomocou aliasu signFile. Výsledkom bude podpísaný JAR súbor sCount.jar. jarsigner -keystore susanstore -signedjar sCount.jar Count.jar signFiles • Musíme zadať aj heslo uloženia (ab987c) a heslo privátneho kľúča (kpi135). • Nástroj jarsigner získa certifikát z miesta, ktorého alias je signFiles a priloží ho ku generovanému podpisu podpísaného JAR súboru.

32. Export certifikátu verejného kľúča • Runtime systém príjemcu kódu musí autentifikovať podpis pri snahe aplikácie podpísanom JAR súbore o čítanie súboru. • Aby sme autentifikovali podpis, potrebujeme mať verejný kľúč, ktorý tvorí pár s privátnym kľúčom použitým na generovanie podpisu. Príjemcovi pošleme kópiu certifikátu, ktorý autentifikuje verejný kľúč. Certifikát z miesta uloženia (BIS) skopírujeme do súboru BIS.cer takto: keytool -export -keystore BIS -alias signFiles -file BIS.cer • Vyžiada si to heslo pre prístup k miestu uloženia (ab987c).

33. Kroky príjemcu kódu

34. Kroky príjemcu Teraz je úloha na príjemcovi, ktorý prijal podpísaný JAR súbor a certifikát. My vykonáme tieto kroky: • Vyskúšanie obmedzení • Importovať certifikát ako dôveryhodný, pomocou nástroja keytool -import • Nastaviť súbor s bezpečnostnou politikou, aby mali podpísané triedy právo čítať daný súbor • Overiť výsledok zmeny bezpečnosti

35. Vyskúšanie obmedzení aplikácie Aplikáciu spustíme spolu so manažérom bezpečnosti. java -cp sCount.jar Count data.txt Tento príkaz vráti takúto výnimku Exception in thread "main" java.security.AccessControlException:access denied (java.io.FilePermission C:\TestData\data read) at java.security.AccessControlContext.checkPermission(Compiled Code) at java.security.AccessController.checkPermission(Compiled Code) at java.lang.SecurityManager.checkPermission(Compiled Code) at java.lang.SecurityManager.checkRead(Compiled Code) at java.io.FileInputStream.(Compiled Code) at Count.main(Compiled Code)

36. Importovanie certifikátu Predtým, než povolíte podpísanému kódu čítať špecifikovaný súbor, potrebujeme importovať certifikát BIS ako dôveryhodný certifikát do priestoru kľúčov. Choďte do adresára, ktorý obsahuje certifikát BIS.cer a vykonjte takýto príkaz: keytool -import -alias susan -file SusanJones.cer –keystore raystore Ak si chceme overiť platnosť tohto certifikátu, zadajte: • keytool -printcert -file SusanJones.cer

37. Nastavenie súboru s bezpečnosťou Po otvorení súboru s bezpečnosťou pomocou nástroja policytool musíme špecifikovať tzv. keystore, miesto, kde sa nachádza kľúč. Aby sme ho definovali, vyberme príkaz Change Keystore z menu Edit. Miesto raystore v adresári c:/Test určíme pomocou URL takto file:/C:/Test/raystore Teraz pridáme práva pre takto podpísaný kód už známym spôsobom s tým, že do kolonky SignedBy uvedieme susan (alias pre importovaný certifíkát).

38. Bezpečnosť J2EE aplikácii • J2EE architektúra • Úvod do bezpečnosti • Autentifikácia • Autorizácia • J2EE Security pattern

39. Čo je to J2EE ? • Java 2 Enterprise Edition (J2EE) je viacvrstvová architektúra pre implementovanie enterprise aplikácii a web aplikácii • J2EE je platforma pre vývoj distribuovaných enterprise aplikácii • Hlavným cieľom J2EE technológie je vytvoriť jednoduchý vývojový model pre enterprise aplikácie pomocou aplikačného modelu založeného na komponentach. Tieto komponenty využívajú služby poskytované kontajnerom

40. Komponenty J2EE • Aplikačné komponenty • Aplet • Java Servlet a JavaServer Pages • Enterprise JavaBeans

41. Štandardné služby J2EE • Java Database Connectivity (JDBC) • Java Transaction API (JTA) • Java Transaction Service (JTS) • Java Messaging Service (JMS) • Java Naming and Directory Interface (JNDI) • Java Activation Framework (JAF) • Remote Method Invocation (RMI) • JavaMail API (JMA) • Java Interface Definition Language (JavaIDL)

42. N-vrstvová J2EE architektúra

43. Architektúra J2EE

44. Vrstvy J2EE architektúry • Klientská vrstva (Client tier)- HTML klient, aplet, Java aplikácia • Web vrstva (Web tier) – Java servlets, Java Server Page (umiestnenie - web kontajner) • Obchodná vrstva (business tier) – Java Entity Beans • Niekedy sa tu pridáva tzv. Integračná vrstva (Integration tier) • EIS vrstva (Enterprise Information System (EIS) tier) – databázy, zdroje...

45. Úvod do bezpečnosti • J2EE aplikácie a Web services aplikácie sú vytvárané z komponentov, ktoré môžu byť umiestnené v rôznych kontajneroch. Tieto komponenty sú používané na budovanie viacvrstvovej obchodnej aplikácie. Bezpečnosť komponentov zabezpečuje kontajner, ktorý ponúka dva druhy bezpečnosti : • Deklataračná – vyjadruje bezpečnostnú štruktúru aplikácii, obsahuje bezpečnostné role, kontrola prístupu, požiadavky autentifikácia – vo forme externej vzhľadom na aplikáciu (definuje sa v deployment descriptor-e komponentu.) • Programová – je vložená do aplikácie a používa sa na rozhodovanie o bezpečnosti. Je vhodná, ak deklaračná bezpečnosť nie je dostačujúca na vyjadrenie bezpečnostného modelu aplikácie.

46. Úvod do bezpečnosti • J2EE aplikácia sa skladá z komponentov, ktoré obsahujú chránené a nechránené zdroje. Často je potrebné chrániť zdroje a zabezpečiť, aby k nim mali prístup iba autorizovaný používatelia. Kontrola prístupu zahrňuje dva kroky: • Autentifikácia – musí preukázať svoju identitu pomocou autentifikácie. Obvykle sa to vykonáva poskytnutím autentifikačných údajov (ako napr. meno a heslo). Entita, ktokrá môže byť autentifikovaná, sa nazýva principal. Principal môže byť používateľ ale aj program. Používatelia sa zvyčajne autentifikujú pomocou prihlásenia. • Autorizácia - Ak sa autentifikovaný principal snaží pristúpiť k zdrojom, system rozhodne, či tento principal je autorizovaný tak spraviť. • Autorizácia poskytuje kontrolu prístupu k chráneným zdrojom. Je založená na identifikácii a autentifikácii. Identifikácia je process, ktorý umožní rozpoznanie každej entity systému a autentifikácia je process, ktorí overí identitu užívateľa, zariadenia alebo inej entity systému. • Authorizácia a autentifikácia sa nevyžadujú k prístupu k nechráneným zdrojom. Prístup k zdrojom bez autentifikácie sa označuje ako anonymný (anonymous access, unauthenticated access).

47. Oblasti, používatelia, skupiny a role Autentifikačná služba J2EE servra zahŕňa a spolupracuje s týmito komponentami: • Oblasť (Realm): Súbor užívateľov a skupín, ktoré sú kontrolované tým istým autentifikačným spôsobom • Používateľ (User): Individuálna identita (alebo aplikačný program), ktorá bola definovaná v Sun Java System Application Server Platform Edition 8.0. Môže byť pridelený do skupiny. • Skupina (Group): Množina autentifikovaných používateľov, ktorých spájajú spoločné znaky • Rola (Role):Abstraktné meno pre povolenie prístupu k jednotlivým množinám zdrojov v aplikácii. Rola môže byť prirovnaná ku kľúču, ktorým sa otvorí zámok. Mnoho ľudí môže mať kópiu tohto kľúča a zámok sa nestará o to, kto ste, iba o to, či máte správny kľúč

48. Oblasti, používatelia, skupiny a role

49. Login autentifikácia J2EE platforma dovoľuje tvorcovi aplikačných komponentov vybrať si spôsob autentifikácie. Ak sa snažíme pristúpiť ku chráneným Web zdrojom, Web kontajner aktivuje autentifikačný mechanizmus. Môžeme špecifikovať tieto autentifikačné mechanizmy: • HTTP základná autentifikácia • Login autentifikácia založená na formulári • Autentifikácia certifikátom klienta • Obojstranná (vzájomná) autentifikácia • Zjednodušená autentifikácia (digest authentification)

50. Použitie HTTP základnej autentifikácie • Vykonajú sa tieto kroky: • Klient požiada o prístup k chráneným zdrojom. • Web server vráti dialógové okno, ktoré žiada meno a heslo používateľa. • Klient zadá a odošle meno a heslo servru. • Server overí platnosť došlých údajov a ak sú správne, vráti zdroj.