730 likes | 945 Views
Bezpe čnosť informačných systémov. Bezpečnosť Java a J2EE aplikácii. Obsah. Bezpečnosť Java 2 aplikácii Sandbox Security Manager Policy file Bezpe čnosť J2EE aplikácii Úvod Autentifikácia Autorizácia Security pattern. Bezpečnosť Java 2 aplikácie. Sandbox SecurityManager Policy File
E N D
Bezpečnosť informačných systémov Bezpečnosť Java a J2EE aplikácii
Obsah • Bezpečnosť Java 2 aplikácii • Sandbox • Security Manager • Policy file • Bezpečnosť J2EE aplikácii • Úvod • Autentifikácia • Autorizácia • Security pattern
Bezpečnosť Java 2 aplikácie • Sandbox • SecurityManager • Policy File • Príklad
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.
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.
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
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.
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
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.
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().
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); }
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
Š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"; };
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
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
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
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
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.
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
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"); • } • }
Vytvorenie JAR súboru JAR súbor, ktorý bude obsahovať Count.class súbor vytvoríme takto: jar cvf Count.jar Count.class
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
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
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.
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).
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
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)
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
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).
Bezpečnosť J2EE aplikácii • J2EE architektúra • Úvod do bezpečnosti • Autentifikácia • Autorizácia • J2EE Security pattern
Č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
Komponenty J2EE • Aplikačné komponenty • Aplet • Java Servlet a JavaServer Pages • Enterprise JavaBeans
Š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)
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...
Ú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.
Ú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).
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ľúč
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)
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.