IT Security jegyzet. ELTE IK 2012/2013 I. félév. Zilahi Richard

Átírás

1 IT Security jegyzet ELTE IK 2012/2013 I. félév Zilahi Richard

2 Tartalom PreDeCo elv:... 3 Védelmi Kontrollok... 3 Adminisztratív védelem... 3 Fizikai védelem... 3 Technikai/Logikai védelem... 3 Lehetséges fenyegetések... 3 A fő elvek... 3 Feladatok szétválasztása (Separation of... 3 Duties)... 3 Legkevesebb jogosultság (Least Privilege)... 3 Hitelesítés... 4 Tudás alapú: Jelszavak... 4 Hozzáférés ellenőrzési modellek... 4 Fogalmak... 4 FTP (tcp/21)... 4 SSH (tcp/22)... 4 Telnet (tcp/23)... 4 SMTP (tcp/25)... 4 DNS (UDP/53, tcp/53)... 5 HTTP (tcp/80), HTTPS... 5 (TCP/443)... 5 MSSQL (TCP/1433)... 5 MYSQL (TCP/3306)... 5 Mit értünk hálózati határvédelem alatt?... 5 Tűzfalak funkcionalitása... 5 Hozzáférés vezérlési modellek... 5 Csomagszűrő routerek... 6 A házirend tárolása... 6 Csomagszűrő routerek értékelése... 6 Állapot tartó csomagszűrők... 6 Állapot tartó értékelése... 6 SOCKS tűzfalak... 6 SOCKS tűzfalak értékelése... 7 Bastion hostok értékelése... 7 Alkalmazásszintű tűzfalak... 7 Proxy tűzfalak értékelése... 7 Transzparencia... 7 Hálózati szintű transzparencia... 8 Alkalmazásszintű transzparencia... 8 Transzparens proxyk... 8 Moduláris proxyk... 8 Moduláris proxyk értékelése... 8 Címfordítás... 8 További határvédelmi funkcionalitások... 9 nids és IPS funkcionalitás tűzfalakon... 9 Tartalomszűrés... 9 Autentikáció... 9 Autentikáció tűzfalakon... 9 Naplózás... 9 VPN megvalósítás tűzfalon Reaktív vírusfeldolgozás Mi a teendő? reakcióidő csökkentése Banki jelszólopók Kártevőszám emelkedés Zeroaccess Vírusok által okozott kár Elektronikus aláírás Tanúsítványok osztályozása PKI építőelemek CA Certificate Authority CA működése RA Registration Authority Regisztráció... 12

3 Tanusítvány visszavinás...12 Online Certificate Status...13 Kulcs archiválás...14 Hardware Security Modul...14 Kulcsmenedzselés...14 Kártyamenedzsment feladatok...15 Gyakorlati alkalmazások...15 Open SSL alapismeretek...15 SSL/TSL protokoll...15 SSL/TLS tanúsítványok...16 Felépítése...16 Kockázatelemzés típusok...16 Kvantitatív (QN) kockázatelemzés főbb ismérvei...16

4 PreDeCo elv: Preventív intézkedések Pl.: biztonsági frissítések telepítése Detektív intézkedések Pl.: IDS rendszerek Korrektív intézkedések Pl.: backup/visszaállás Védelmi Kontrollok Adminisztratív kontrollok Policy-k, eljárások, oktatás Fizikai kontrollok Backup-ok, kábelezés, kontroll zónák Technikai/Logikai kontrollok Hálózati architektúra, tűzfalak, titkosítás, audit Adminisztratív védelem Törvények Szabványok, műszaki normák Ágazati végrehajtási utasítások Helyi szabályzatok Informatikai Szabályzat Dokumentumkezelési Szabályzat Katasztrófa-elhárítási terv Fizikai védelem Vagyonvédelmi megoldások (videó, beléptető, behatolás-jelző ) Tűzvédelem (tűzjelző és oltórendszer ) Üzemeltetés védelem (szünetmentes megoldások, redundancia ) Technikai/Logikai védelem Informatikai betörésvédelmi megoldások Mentési rendszerek, archiválás Vírusvédelem Jogosultságkezelés Titkosítás, kriptográfia Tűzfal Lehetséges fenyegetések Adat remanencia (data remanence): Akkor következik be, ha egy mágneses adattárolót felülírtak vagy töröltek, de továbbra is kinyerhető belőle információ. Átejtés (spoofing): Akkor következik be, amikor egy személy vagy egy alkalmazás másnak adja ki magát az adatok meghamisításával, így szerezve jogosulatlan hozzáférését. Pl. az IP spoofing során a támadó hamisított IP címmel megbízható hosztnak adja ki magát. A fő elvek Feladatok szétválasztása (Separation of Duties) Célja, hogy egy folyamat lépéseit különböző személyek végezzék el. Ehhez a folyamatot meg kell tervezni. Megakadályozza, hogy egy személy a teljes folyamatot ellenőrizze és manipulálja. Például egy könyvelési osztályon nem fogadhatja be ugyanaz a személy a számlákat, és nem kezdeményezheti ezek kifizetését. Legkevesebb jogosultság (Least Privilege) Az elv betartásával a rendszer a felhasználók és az alkalmazások erőforrásokhoz való hozzáférését csak a legszükségesebbekre korlátozza. Ehhez meg kell határozni a felhasználók

5 munkájához szükséges jogosultságok minimális halmazát. A felhasználók ehhez a halmazhoz kapnak csak hozzáférést, se többhöz, se kevesebbhez. Példa a Windows Vista User Account Control (UAC) megoldása Hitelesítés Tudás alapú Something you know Tulajdon alapú Something you have Tulajdonság alapú Something you are A jó hitelesítés során a háromból legalább kettőt, egymástól függetlenül kell használni! Ez az erős autentikáció vagy többlépcsős hitelesítés. Tudás alapú: Jelszavak Jelszó politika (pl. korlátozott élettartam) Jelszó menedzsment (ne legyen szótári alakú, kisnagy+szám+speckar, min8kar, ) Jelszó hashelés Jelmondatok Lehetséges támadások: Brute-force vagy szótár alapú támadás, lehallgatás, social engineering döntését security labels / sensitivity labels SELinux Fogalmak Black-box vizsgálat: semmilyen információ nem áll rendelkezésre Grey-box vizsgálat: bizonyos információk rendelkezésre állanak (pl. teszt felhasználók) White-box vizsgálat: minden információ rendelkezésre áll FTP (tcp/21) Titkosítatlan Anonymous login Bárki számára írható/olvasható könyvtárak Backdoor Buffer overflow Brute force Bounce attack SSH (tcp/22) PermitRootLogin SSHv1 támogatás Buffer overflow Brute force Hozzáférés ellenőrzési modellek Discretionary Access Control (DAC) Az objektum tulajdonosa mondja meg ki/mit tehet meg vele Linux filesystem jogosultság Windows ACL-ek Mandatory Access Control (MAC) Az AC mechanizmus felülbírálhatja a tulajdonos Telnet (tcp/23) Titkosítatlan Brute force Buffer overflow SMTP (tcp/25) Titkosítatlan Brute force

6 Buffer overflow User enum. (VRFY) relaying DNS (UDP/53, tcp/53) Titkosítatlan Anonymous zóna transzfer DNS cache poisoning Dan Kaminsky-féle hiba minskydns-vuln.html Buffer overflow HTTP (tcp/80), HTTPS (TCP/443) Titkosítatlan (HTTP) HTTP methods (TRACE, PUT, DELETE) Directory listing HTTP Parameter Splitting Buffer overflow WebDAV (cadaver) + Tomcat, Jboss, WebSphere, GlassFish, + Webes alkalmazások hibái! MSSQL (TCP/1433) Titkosítatlan (is lehet) Gyenge sa jelszó xp_cmdshell Az MSSQL SYSTEM felhasználó nevében fut MYSQL (TCP/3306) Titkosítatlan (is lehet) Engedélyezett root login Load_file, INSERT INTO OUTFILE Try Harder Phpmyadmin Mit értünk hálózati határvédelem alatt? Azon fizikai és logikai eszközök összessége, melyek az IT Biztonsági Szabályzat ( IBSZ ) hálózati határvédelemre vonatkozó követelményeit megvalósítják. Az az eszköz, ami két fizikai hálózat között csak az (IBSZ-ben) engedélyezett szabályok szerinti adatáramlást (CC: FDP_IFC és IFF) kényszeríti ki. A tűzfal funkcionalitása: Preventív és detektív kontroll intézkedéseket valósítanak meg Fizikai és logikai szeparáció technikai eszközökkel (protokoll elemzés) Tűzfalak funkcionalitása Preventív kontroll: Hálózatok fizikai szeparációja (fizikai); Protokoll értelmezés, elemzés (technikai); IPS funkcionalitás (technikai); Szűrés: vírus, spam, tartalom, URL stb. (technikai és adminisztratív); Felhasználók hitelesítése és jogosultságaik kezelése (technikai); Detektív kontroll: nids és IPS funkcionalitás (technikai); naplózás (technikai és adminisztratív); Hozzáférés vezérlési modellek Diszkrecionális hozzáférés vezérlés (kizárólagos) (DAC) Access Matrix Kötelező hozzáférés vezélés (MAC) Bell-LaPadula (Confidentiality model)

7 No read UP No write down BIBA (Integrity model) No read down No write down többcsatornás protokollok kezelése nem megvalósítható sok szabály szükséges (válasz packetek kezelése) Ismeretlen elemek kezelése: Az ismeretlen elemeket szűrés nélkül engedik át. Csomagszűrő routerek Működési elv: A bejövő csomagokat tulajdonságaik alapján elfogad (továbbít, routingot végez), elvet vagy eldob illetve naplóz Döntés alapja: A csomagok forrása és célja (port és IP), bizonyos flag-ek. Ezért a szabályok csak a csomagokra vonatkoznak (Packet Filter). Megvalósítás: Minta illesztés A házirend tárolása A házirend (policy vagy szabályrendszer) tárolására szolgáló leggyakoribb eszköz, a hozzáférési lista (ACL - Acces Control List): A mintra (pattern) feladata a cél (döntés) kiválasztása; A szabály (policy verdict) feladata az illeszkedő (packet) sorsának eldöntése: Engedélyezés vagy tiltás; Ugrás másik szabályra; Naplózás és ugrás másik szabályra; Az ACL-ek feldolgozása általában az első illeszkedésig tart, ezért a számít sorrend (specifikus szabályok előre, átfogók a lista végére). Csomagszűrő routerek értékelése Előnyök: gyors egyszerűen kezelhető szabályrendszer Hátrányok: az alkalmazás szintre nem lát Állapot tartó csomagszűrők Működési elv: A bejövő csomagokat tulajdonságaik alapján elfogad, továbbít vagy eldob. Döntés alapja: A teljes TCP és IP rétegek, (forrás, cél port és IP, seq és ack, csomagok sorrend illetve helye) tehát a kapcsolatok (Ezért állapot tartó Stateful Packet Filter - SPF). Megvalósítás mintaillesztéssel és elemzéssel. Megvalósítás: Mintaillesztés Többcsatornás protokollok kezelése: Valamilyen modul segítségével felismeri az alkalmazás szintből, hogy hová kell nyitni a további kapcsolatot, majd azt RELATED-nek jelöli. Állapot tartó értékelése Előnyök: gyors kevesebb szabály (nem kell kezelni a válaszokat) Hátrányok: alkalmazás szintre nem lát többcsatornás protokollok kezelése nehezen megvalósítható Ismeretlen elemek kezelése: Az ismeretlen elemeket szűrés nélkül engedik át. SOCKS tűzfalak Működési elv: Egy speciális, a kliensre telepített

8 alkalmazás elveszi a kapcsolatot az operációs rendszertől és a tűzfalnak adja át. Kicseréli az API hívásokat (beépül az alkalmazás és a TCP réteg közé, fixen a SOCKS szerverhez kapcsolódik) bár létezik olyan alkalmazás ami natívan beszéli a protokollt. Csak kliens védelemre alkalmas (a SOCKS proxy szerver oldalán csak 1 kapcsolat lehet, tehát nem tud sok klienst kiszolgálni. Döntés alapja: A csomagok forrása és célja (port és IP) illetve megvalósítás függően az alkalmazási réteget is elemezheti. SOCKS tűzfalak értékelése Előnyök: SOCKSv5-től felhasználói authentikáció megvalósítható (pl. Kerberos SSO) Hátrányok: A kliens alkalmazások általában nem támogatják a SOCKS protokollt. Az OS-re telepíteni kell a SOCKS klienst (API csere). Szerver nem védhető. Ismeretlen elemek kezelése: Megvalósítás függő, alapvetően nincs alkalmazás szintű védelem. Bastion hostok értékelése Előnyök: Felhasználói autentikáció általában van A kliens alkalmazás ellenőrizhető, kézben tartható Hátrányok: elavult nehezen karbantartható (pl. eltérő verziók felhasználónként) erőforrás igényes a felhasználó potenciális veszélyforrást jelent az alkalmazások sérülékenységei ellen nem nyújt védelmet Ismeretlen elemek kezelése: Nem értelmezhető Alkalmazásszintű tűzfalak Működési elv: A kliens a tűzfalon futó alkalmazással (proxy) tart kapcsolatot, az alkalmazás pedig a szerverrel. Fontos hogy ezek a proxyk gyorsítótár (cache) funkcióval nem rendelkeznek. Döntés alapja: Az alkalmazási réteg protokollja. Megvalósítás: Összetett. Mintaillesztés a hálózati rétegekben valamint mintaillesztés és értelmezés az alkalmazási rétegben. Az értelmezés mélysége függ a megvalósítástól. Proxy tűzfalak értékelése Előny: Alkalmazás szintű védelem Protokoll értelmezés, kifinomultabb szűrés Többcsatornás protokollok elemzése lehetővé válik Hátrány: Proxy használatára felkészített kliens szükséges illetve azt támogató protokoll Lassabb, bonyolultabb a konfigurálás Ismeretlen elemek kezelése: Megvalósítás függő, az ismeretlen elemek eldobása lehetséges Transzparencia Transzparens működés: A kliens és a szerver azt hiszi, hogy közvetlenül egymással kommunikálnak. Nem transzparens működés: A kliens a tűzfallal

9 kommunikál (eltérő protokoll használat lehetséges!). A transzparencia értelmezhető: Hálózati szinten (TCP/IP) Alkalmazási szinten Kliens vagy szerver oldalon Lehet szimmetrikus vagy asszimetrikus A hálózati és alkalmazásszintű transzparencia lazán kötődik Hálózati szintű transzparencia Kliens oldali: A kliensek a valódi célszervert IPjét címzik A kliensek a tűzfal IP-jét címzik Szerver oldali: A szerverek a valódi kliens IP-jéről vagy a tűzfal IP címéről látják a kapcsolatot alkalmazás szinten és az azt hordozó többi réteg (TCP/IP) Megvalósítás: Összetett. Mintaillesztés a hálózati rétegekben valamint mintaillesztés és értelmezés az alkalmazási rétegben. Az értelmezés mélysége függ a megvalósítástól. Moduláris proxyk Működési elv: A feladatokat modulokra osztják és a modulokat kapcsolják egymáshoz. Funkcionalitásban egyezik a transzparens proxykkal. Döntés alapja: A transzparens proxykkal egyező Megvalósítás: A transzparens proxykkal egyező Alkalmazásszintű transzparencia Szerver típusú kérés (protokoll) használata, pl.: GET / HTTP/1.0 Host: Connection: Keep-Alive Proxy típusú kérés (protokoll) használata, pl.: GET HTTP/1.0 Proxy-Connection: Keep-Alive Szimmetrikus vagy aszimmetrikus transzparencia: mindkét oldalon ugyanolyan, vagy különböző protokoll használat Transzparens proxyk Működési elv: A kapcsolatot valamilyen módon eltérítik eredeti céljától a proxyhoz (Ehhez gyakran csomagszűrőt használnak). A kliens és a szerver számára a kommunikáció transzparens. Döntés alapja: A kliens és a protokoll minden eleme Moduláris proxyk értékelése Előnyök: Összetett és többcsatornás protokollok elemzése lehetővé válik Nagyobb rugalmasság, stabilitás (KISS elv), mélyebb elemzés, skálázhatóság Hátrány: Nagyobb CPU igény Ismeretlen elemek kezelése: Megvalósítás függő, az ismeretlen elemek eldobása lehetséges Címfordítás Az a technológia, mely az eszközön (router vagy tűzfal) áthaladó csomagok forrás vagy cél címét megváltoztatja (NAT: Network Address Translation) Fajtái: Egy-egy NAT Sok-egy NAT

10 Forrás és cél NAT (SNAT vagy DNAT) PAT (Port Address Translation) További határvédelmi funkcionalitások nids és IPS funkcionalitás Tartalomszűrés Autentikáció Naplózás VPN végződtetés (terminálás) nids és IPS funkcionalitás tűzfalakon Működési elv: az eszközön áthaladó, engedélyezett forgalomban rossz szándékú aktivitás érzékelése és blokkolása Csomagszűrők esetében ez csak kiegészítő eszközzel (modullal) megvalósítható Proxyk esetében, amennyiben az ismeretlen protokollelemeket az tiltja, több IPS funkcionalitás megvalósítható Tartalomszűrés Vírusszűrés Vbuster Kraspersky Nod32 Clamav Spam szűrés: Spamassassin Commtouch Tartalom szűrés több modullal spamassassin html sed Autentikáció Célja a felhasználó identitásának pontos meghatározása, majd felhasználói jogok hozzárendelése. Az authentikációs rendszer: személyek megkülönböztető karakterisztikák (tudás, birtok, biometria) authentikációs mechanizmus (protokoll) hozzáférésvezérlési mechanizmus (DAC, MAC) Autentikáció tűzfalakon Protokollon belüli (inband): egyes protokollok (pl. ftp és http) támogatják a kliens autentikácóját a proxyn, tűzfalon. Protokollon kívüli (outband): valamilyen külső eszközzel, független csatornán azonosítjuk a klienst (így a protokoll nem befolyásolja az autentikációs mechanizmust). Naplózás Minden tűzfal megoldás az által értelmezett protokollelemekel kapcsolatos naplózási funkciókat képes megvalósítani. Csomagszűrők csak TCP/IP szinten naplóznak Proxyk esetében ez akár a teljes kapcsolat és minden protokoll elem naplózását is jelentheti (erőforrás igényes).

11 Accounting információk naplózása lehetséges. VPN megvalósítás tűzfalon A kikényszerített házirend a VPN csatornákon is érvényes. Rejtjelezett kapcsolatokban is lehetséges protokoll ellenőrzés, vírus és tartalom szűrés (melynek feltételeit az IBSZ-ben rögzíteni kell). VPN-ek autentikációja a központi PKI rendszerhez. Reaktív vírusfeldolgozás A vírus felbukkan valahol a nagyvilágban Felhasználó beküldi Víruslabor elemzi, feldolgozza Vírusadatbázis QA Elkészül az adatbázis frissítés (kb. 3 óra) Mi a teendő? reakcióidő csökkentése Víruslaborok közötti együttműködés Vírusadatbázis SOS frissítése Rendszergazdák informálása Frissítések azonnali szétterítése (cégen belül pull helyett push) Banki jelszólopók Keylogging Form data capture Screen capture Mini screen capture Video capture Phishing Kártevőszám emelkedés Kártevők száma duplázódik évente Az ismert kártevők fele az elmúlt 18 hónapban született Szerver oldali polimorfizmus Egyre kevesebb az idő a feldolgozásra, QA kritikus Vakriasztások száma megnövekedett (egységnyi feldolgozásra jutó szám kb. ugyanaz) A mennyiségi növekedés minőségi ugrást követel (memória használat, víruslabor létszám nem skálázható) Zeroaccess Kernel módú rootkit Terjesztés: Blackhole kiten keresztül v. social engineering 32 és 64 bites rendszereken is működőképes Felülír egy kiválasztott drivert Védelmi programokat önkivégzi RC4 titkosított volume-ra települ Pszeudo-random domain generálás P2P botnet További komponenseket tölt le (click fraud)

12 Vírusok által okozott kár Adatvesztés Adat kiáramlás Személyes adatok lopása, használata Kiesett munkaidő Szándékos rombolás Rendelkezésre nem állás Elektronikus aláírás Kapcsolódó eljárásokkal együtt alkalmas arra, hogy biztosítsa: az aláíró egyértelmű azonosíthatóságát, az aláírás tényének letagadhatatlanságát, továbbá azt, hogy az elektronikus irat tartalma nem változott meg az aláírás művelete óta. PKI építőelemek Hitelesítő központ (Certification Authority - CA) Regisztrációs központ (Registration Authority RA) Címtár szolgáltatás (vagy webes publikáció) Hardver biztonsági eszközök Szabályzatok PKI alkalmazások Biztonsági megoldások (pl. Tűzfal CA Certificate Authority Tanúsítvány előállítás Tanúsítvány kiadás és publikálás Tanúsítvány visszavonás Kulcs mentés és visszaállítás Kereszthitelesítés (Cross certification) Tanúsítványok osztályozása Tanúsítvány fajták Magánszemélyek Szervezeteket képviselő személyek Eszközök Tanúsítvány típusok Alap biztonságú Fokozott biztonságú CA működése Root CA, mint PKI infrastruktúra központja Root CA által hitelesített tanúsítványok Működtetésének alapelvei SubCA Kapcsolata a Root CA-val Működtetésének alapelvei Minősített biztonságú

13 RA Registration Authority Az RA fogadja: Beérkező remote regisztrációs és visszavonási kéréseket Regisztrációs operátor generálja a face-to-face regisztrációs kéréseket Az RA, mint regisztrációs központ felel a tanúsítvány hitelesítési kérelmek továbbításáért a CA felé Regisztrációs folyamat Adatgyűjtés Jogosultság ellenőrzés Regisztrációs döntés Opcionális kulcsgenerálás és kulcs és tanúsítvány disztribúció Visszavonás Regisztráció Regisztrációs modellek közös jellemzői: Azonosítani kell a felhasználót Fogadni kell a felhasználó adatait Le kell generálni a szükséges kulcsokat El kell készíteni a tanúsítvány kérelmet A CA elkészíti és hitelesíti a tanúsítványt A tanúsítvány terjesztés Face-to-face Az RA operátor személyesen találkozik a felhasználóval Kulcsgenerálást az operátor végzi tipikusan Remote Az RA operátor távolról kell ellenőrizze a felhasználó személyazonosságát Kulcsgenerálás a Operátor vagy a felhasználó választ PIN-t. A kulcs és a tanúsítvány továbbításra kerül a felhasználó gépére felhasználónál RA szoftver nem kontrollálja a kulcsgenerálást A privát kulcs nem hagyja el a felhasználó gépét Tanusítvány visszavinás Legelterjedtebb módja: CRL (Certificate Revocation List Tanúsítvány Visszavonási

14 Lista) CRL terjesztése a felhasználók közt elhelyezzük mindenki számára elérhető helyre zártkörű felhasználás CDP (CRL Distribution Point) - X.509 v3 certificate-ek tartalmazhatnak CDP bejegyzést, amely meghatározza a CRL helyét a rendszerben Minden CRL tartalmazza az alábbiakat: Verziószám (meghatározza a CRL formátumát) Aláírás Kibocsátó Utolsó frissítés időpontja Következő frissítés időpontja Visszavont tanúsítványok listája A visszavonási tanúsítványok listája tartalmazza az alábbiakat: A tanúsítvány sorszámát A visszavonás dátumát Opcionális kiegészítések melyek a visszavonás körülményeire vonatkozhatnak CRL lehet: Teljes (master) CRL - Minden visszavont tanúsítvány sorszámát tartalmazza Részleges CRL - Csak az adott feltételnek megfelelőkét ARL - Authority Revocation List Csak a visszavont CA-kat és RA-kat Online Certificate Status Protocol Revocation Checker ként működik a felhasználói alkalmazások számára Gyorsabb válaszidőt biztosít azáltal, hogy nem a CRL-t ellenőrzi, csak az adott certificate érvényességét Azonnal, on-line frissül az adatbázisa (!!!) Egyidejűleg több CA rendszert is ki tud szolgálni Az OCSP szerver az alábbi lehetséges válaszok valamelyikét adja lekérdezés esetén: Revoked A certificate visszavonásra került Not revoked A certificate érvényes Do not know Az adatbázisa nem tartalmazza a kért információt

15 Kulcs archiválás A tanúsítványok felhasználása: Aláírás Azonosítás Titkosítás Mi történik, ha megsemmisül a privát kulcs??? Digitális aláírás - későbbi hitelesítése OK Rejtjelezett állományok - nem lesznek elérhetőek A felhasználó privát kulcsáról készült másolatot tárol: A kulcsokat fel kell készíteni A távoli kéréskor generált kulcsokat tipikusan - nem lehet archiválni Gondok: Kulcs generálása nem központilag történik On-board kulcsgenerálás A kulcsokat a Kulcs Archiváló Szerver segítségével lehet helyreállítani különböző formátumokban: PKCS#12 PSE fájl formátum Hardware Security Modul Cél : kulcsok biztonságos tárolása és generálása - a privát kulcs nem hagyja el az eszközt A legtöbb rendszer támogatja a szabványos megoldásokat (PKCS#11) Lehet: PCI illetve hálózati felületen csatlakozó eszköz Kulcsmenedzselés A kulcsok teljes élettartamát végigkíséri Hogyan kell generálni, elosztani? Hol kell tárolni? Mikor, hogyan kell a kulcsot aktivizálni / deaktivizálni? Meddig érvényes egy kulcs? Hogyan kell a kulcsokat menteni? Eltérő célokra (pl. aláírás, titkosítás) más-más kulcsokat tanúsítványokat célszerű használni. Mert máshogyan használjuk és generáljuk őket: a titkosító kulcsot menteni kell! Bináris PKCS#1 privát kulcs

16 Kártyamenedzsment feladatok Kártyák/tokenek gyártása, kezelése, nyilvántartása Elektronikus (és vizuális) megszemélyesítés PKI rendszerek kezelése Adatforrások kezelése IDM Címtár Profilok, sablonok támogatása Kártyafolyamatok (csere, elvesztés, megújítás, letiltás) menedzselése Titkosító kulcsok visszaállítása, korábbi tanúsítványok törlése PIN feloldás Szoft-token támogatás Regisztrációs feladatok Szervezeti hierarchia, Felhasználó, Telephely, Címadatok, stb. Riport funkciók Mindezt biztonságosan! Gyakorlati alkalmazások Levelezés aláírása/titkosítás Elektronikus számlázás SSL elérés Elektronikus cégeljárás Open SSL alapismeretek Különböző matematikai algoritmusok segítségével a kriptográfia célja elsősorban a bizalmasság, sértetlenség, hitelesség biztosítása. A kriptográfiában (PKI részen) alkalmazott, matematikai értelemben vett nehéz problémák : IFP Integer Factorization Problem pl. RSA DLP Discrete Logarithm Problem pl. DSA ECDLP Elliptic Curve Discrete Logarithm Problem pl. ECDSA ITU-T X.509 tanúsítvány - Hozzárendeli a felhasználó személyes adataihoz (DN, megkülönböztetett név, CN, C, O, OU, E stb. névelemek) a nyilvános kulcsát. A kulcspár másik fele (titkos kulcs) biztonságos adathordozón (pl. smart card, HSM, USB token) vagy állományként (pl. PKCS#12.p12 vagy.pfx) tárolható. - A tanúsítvány alá van írva digitálisan a kibocsátó (CA) titkos kulcsával. - A protokollok szempontjából a subject, issuer, keyusage és extkeyusage bitek fontosak elsősorban a kriptiográfiai adatok mellett. SSL/TSL protokoll Az SSL/TLS protokoll a kliens internet böngészője és a web server közötti adatforgalmat rejtjelezi, a tanúsítványok (elsősorban web server) révén pedig a felek hitelességét is biztosítják. Az SSL/TLS protokoll a TCP/IP modell alkalmazás rétegében foglal helyet, de a szállítási réteghez közel (HTTP alatt, TCP felett ).

17 Eredetileg Netscape szabvány volt, majd átvette az IETF. IETF RFC 5246 The Transport Layer Security (TLS) Protocol Version 1.2 SSL/TLS tanúsítványok req: PKCS#10 certificate request (.csr) meghatározott adatok alapján (openssl.cnf) adatok megadása, kulcs létrehozása rsa: RSA kulcsokhoz kapcsolódó műveletek PIN kódos védelmet leveszi a kulcsról x509: X.509 tanúsítványhoz kapcsolódó műveletek kérelem és aláíró kulcs alapján tanúsítvány (-extfile a kiterjesztések hozzáadása miatt) pkcs12: PKCS#12 műveletek tanúsítvány összerendelése a titkos kulccsal Felépítése protokoll verziója (legmagasabb támogatott) kliens random: időadat + 28 byte (szervertől függetlenül) sessionid kriptográfiai algoritmusok tömörítési algoritmusok Kockázatelemzés típusok Kvalitatív jellegű kockázatelemzés, üzleti hatáselemzés (BIA) főbb ismérvei Számszerűen nem mérhető minőségi ismérveken alapszik (ezért kvalitatív). Az informatikai rendszer üzletmenetre gyakorolt hatását csak minőségi jellemzők alapján veszi figyelembe. A szervezeti működést modelláló képessége erősen korlátozott. A kimenetei összetettebb szervezet és rendszer esetén kevéssé megbízhatók. Gyorsan, relatíve kevés erőforrás felhasználásával elvégezhető. Kvantitatív (QN) kockázatelemzés főbb ismérvei Számszerű mérhető minőségi ismérveken alapszik (ezértm kvantitatív). Az informatikai rendszer üzletmenetre gyakorolt hatását elsődlegesen mennyiségi jellemzők alapján veszi figyelembe. A szubjektív jellemzők méréséhez elsődlegesen a szubjektív skálák módszerét alkalmazza. A szervezeti működést modelláló képessége kifejezetten erős. A kimenetei nagyobb összetett szervezet és rendszer esetén is megbízhatóak. Viszonylag sok erőforrást igényel.