IT – Security jegyzet

ELTE IK 2012/2013 I. félév

Zilahi Richard

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 ........... 10

Reaktív vírusfeldolgozás .............. 10

Mi a teendő? – reakcióidő

csökkentése ............................... 10

Banki jelszólopók ........................ 10

Kártevőszám emelkedés .............. 10

Zeroaccess ................................ 10

Vírusok által okozott kár .............. 11

Elektronikus aláírás ..................... 11

Tanúsítványok „osztályozása” ...... 11

PKI építőelemek ......................... 11

CA – Certificate Authority ............ 11

CA működése ............................. 11

RA – Registration Authority .......... 12

Regisztráció ............................... 12

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

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

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

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

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

Telnet (tcp/23)

• Titkosítatlan

• Brute force • Buffer overflow

SMTP (tcp/25)

• Titkosítatlan • Brute force

• Buffer overflow

• User enum. (VRFY) • E-mail relaying

DNS (UDP/53, tcp/53)

• Titkosítatlan

• Anonymous zóna transzfer • DNS cache poisoning

• Dan Kaminsky-féle hiba http://unixwiz.net/techtips/iguidekaminsky-

dns-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)

• No read UP

• No write down – BIBA (Integrity model)

• No read down • No write down

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

– 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.

Á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

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

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 IP-

jé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ásszintű transzparencia

• Szerver típusú kérés (protokoll) használata, pl.:

GET / HTTP/1.0 Host: www.balabit.hu Connection: Keep-Alive

• Proxy típusú kérés (protokoll) használata, pl.:

GET http://www.balabit.hu 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

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ő

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

– 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).

• 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)

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.

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ú

• Minősített biztonságú

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)

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

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

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

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

• Bináris PKCS#1 privát kulcs

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!

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”).

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.