Kada upravljamo PKI-jem, odgovorni smo za iznajmljivanje i ukidanje digitalnih sertifikata, upravljanje šablonima digitalnih sertifikata, objavljivanjem CRLs, i upravljanjem dostupnosti CDP-a i AIA. Ako ne upravljamo Certification Authority-jem na pravi način, kao rezultat se pojavljuju različiti oblici sigurnosnih ranjivosti, uključujući:
  • Aplikacije nisu u mogućnosti da provere lanac sertifikata.
  • Sigurnosnim subjektima (principals) se dodeljuje više sertifikata nego što im je potrebno.
  • Sigurnosnim subjektima nisu dodeljeni odgovarajući sertifikati.
  • Sertifikati su slučajno oduzeti (ukinuti) ili nisu ukinuti kada je to potrebno.
  • CRLs nisu dostupni da bi proveravali sertifikate.

U lekciji su opisani neki od administrativnih zadataka koje možemo da odradimo na CA i time smanjimo ove sigurnosne ranjivosti.



PKI alatke

Windows Server 2003 nudi različite PKI alatke koje nam pomažu da administriramo i rešavamo PKI probleme. Ove alatke uključuju MMC snap-in-ove, i upravljačke alatke za upravljanje PKI-jem koje su uključene u Windows Server 2003 Respurce Kit. Kao dodatak, Windows Server 2003 takođe nudi programirane alatke.

MMC snap-ins: Windows Server 2003 nudi tri MMC snap-ina za upravljanje PKI-jem
  • Certificate Templates snap-in: Ovaj snap-in dozvoljava kreiranje, modifikaciju i upravljanje šablonima sertifikata unutar Windows Server 2003 šume. Ovo je primarna alatka i koriste je CA administratori.
  • Certification Authority snap-in: Ovaj snap-in dozvoljava administratoru da upravlja CAs i sertifikatima koje je dodelio CA. CA konzola nam omogućava da modifikujemo CA konfiguraciju, da upravljamo dodeljenim sertifikatima i da objavljujemo CRLs.
  • Certicates snap-in: Certificates Snap-in nam dozvoljava da upravljamo lokalnim mestom gde su smešteni sertifikati za korisnike, kompjutere i servise. Možemo da napravimo zahtev, da obrišemo i upravljamo sertifikatima koji su dodeljeni korisničkom ili kompjuterskom nalogu. Ovu alatku koriste i administratori i krajnji korisnici. Na primer, korisnik zahteva sertifikat kompjutera od Enterprise CA učitavanjem kompjuterskog čvora ovog MMC snap-ina.

Alatke za komandnu liniju (Command Line tools): Windows Server 2003 nudi sledeće alatke koje možemo koristiti na komandnoj liniji za upravljanje CAs i za zahtevanje iznajmljivanja sertifikata od CA:
  • Certutil.exe: Dozvoljava nam da kreiramo skripte za CA i upravljačke zadatke, uključujući upravljanje CA, objavljivanje CRL i CA sertifikata, oduzimanje sertifikata, i oporavljanje arhiviranih privatnih ključeva. Na primer, ako ukucamo certutil.exe –dump će izlistitati sertifikate i CRLs u sa lokalne lokacije na kojoj se nalaze sertifikati.
  • Certreq.exe: Dozvoljava nam da kreiramo skriptove za zahtevanje sertifikata od CA i za generisanje Cross Certification Authority zahteve za sertifikatima. Na primer, možemo da iskoristimo certreq.exe – submit MyRequest.req da generišemo offline zahtev za Enterprise CA.


Resouce Kit Tools: Windows Server 2003 Resources Kit uključuje sledeće alatke za upravljanje PKI:
  • Key Recovery Tool (Krt.exe): Možemo da iskoristimo Key Recovery Alatku da odredimo Key Recovery agenta i oporavimo arhivirane privatne ključeve iz CA baze podataka.
  • PKI Health tool (Pkiview.msc): PKI Health alatka dozvoljava nam da proverimo CDP i AIA URL-ove za svaki CA u našoj organizacijskoj CA hijerarhiji.

Programmatic Tools: Microsoft nudi dva različita Application Programming interfejsa (APIs) da bi omogućio aplikacijama da koriste kriptografske karakteristike Windows Server 2003. Dva API-ja su:
  • CryptoAPI: API sa setom funkcija koje dozvoljavaju aplikacijama da enkriptuju (šifruju) ili digitalno potpisuju podatke.
  • CAPICOM: Ograničeni set API-ja koji omogućava aplikacijama da šifruju ili digitalno potpisuju podatke sa mnogo manjim kodom nego kod CryptoAPI-ja.


Šta je to Certificate Revocation Lista (CRL)

Nakon što Certificate Manager poništi (revoke) sertifikate, CA objavljuje informaciju o poništavanju u Certificate Revocation listi (CRL). Često objavljivanje CRL znatno povećava mrežni saobraćaj iz razloga što kompjuteri tada češće preuzimaju ažuriranu listu sertifikata (CRL). Manje ćesto objavljivanje CA smanjuje mrežni saobraćaj, ali povećava kašnjenje jer kompjuter dok ne preuzme ažuriranu CRL,ne zna da je sertifikat poništen.

Windows Server 2003 nudi dva tipa CRLs: Osnovni CRLs i Delta CRLs. Ova dva tipa rade zajedno da bi izbalansirali najnoviju CRL informaciju i probleme sa kašnjenjem u distribuciji CRLs.

Base CRLs (Osnovni CRL): Ovaj CRL sadrži serijske brojeve svih sertifikata koji su poništeni na CA i razloge njihovog poništavanja. Finalna objavljenja lokacija osnovnog CRL-a mora biti pristupačna sa URL koji se nalazi na sertifikatu. Ako CA poništi veliki broj sertifikata, veličina osnovnog CRL-a može da premaši 1 MB.

Delta CRL: Kada poraste broj iznamljenih sertifikata, takođe će se povećati i broj poništenih sertifikata. Poništeni sertifikati se dodaju u CRL kao kolekcija serijskih brojeva. Da bi smanjili veličinu CRL i da bi podesili češće ažuriranje CRL-a, CRL Delta  čuva samo one sertifikate koji su poništeni nakon poslednjeg objavljivanja osnovne CRL liste.

Samo kompjuteri koji rade na Windows XP Professional & Windows Server 2003 mogu da proveravaju validnost sertifikata čitanjem Delta CRL-a. Ako naša mreža ne koristi ove operativne sisteme, ne bi trebalo da implementiramo Delta CRLs.


Kada koristimo Delta CRLs trebalo bi obratiti pažnju na sledeće:
  • Potrebno je koristiti Delta CRLs sa Issuing CAs kad god je to moguće.
  • Ne treba koristiti Delta CRLs na offline CA jer je broj CA sertifikata uvek mali.
  • Ne treba objavljivati često Delta CRLs u Aktivnom Direktorijumu ako je Replikacija zakazana (scheduled). U tim slučajevima na replikaciju može da se čeka 8 sati do sinhronizacije baze podataka Aktivnog direktorijuma u WAN okruženju.


Kako Certificate Services objavljuje CRLs

Kada klijentski kompjuter preuzme osnovni CRL, osnovni CRL ostaje u CryptoAPI kešu sve dok ne istekne. Iz tog razloga, ako se koristi samo osnovni CRL kao što je slučaj u Windows 2000, klijentski kompjuteri koji imaju validnu CRL u svom kešu neće prepoznati nijednu ručnu promenu u CRL-u.

CRL proces objavljivanja: Svaki CA je konfigurisan sa CRL postavkama objavljivanja (bulication settings) ili CRL periodom objavljivanja. CRL period objavljivanja definiše kada će CA automatski objaviti ažuriranu CRL. Kada je prvi put instaliran CA, period objavljivanja je podešen na nedelju dana (one week), ali možemo ručno da promenimo konfiguraciju.

CRL je objavljena u sledečim sekvencama:
  1. Inicijalna baza CRL (CRL#1) je objavljena sa jednim poništenim sertifikatom.
  2. Ubrzo nakon toga, Cert5 je poništen.
  3. Kada je Delta CRL (CRL#2) objavljen, Delta CRL uključuje Cert5.
  4. Drugi sertifikat Cert7 je poništen.
  5. Kada je ažurirana Delta CRL (CRL#3) objavljena, delta CRL sada sadrži Cert5 i Cert7.
  6. Konačno, kada je osnovna CRL obavljena, osnovna CRL (CRL#4) uključuje Cert5 i Cert7.

Svaka nova delta CRL će sada uključivati samo sertfikate koji su bili poništeni nakon kreiranja osnovne CLR#4.



Kriterijumi za planiranje CRL intervala objavljivanja (Publication Intervals)

Određivanje intervala sa objavljivanje CRLs zahteva određeno planiranje koje treba da obavi CA administrator, koji će morati da definiše CRL interval objavljivanja balansiranjem osnovne CRL i delta CRL intervala.

Potrebno je koristiti sledeće kriterijume kada planiramo CRL intervale objavljivanja:
  • Client Operating Systems (klijentski operativni sistemi): Ako naši klijentski kompjuteri u kompaniji rade na Windows 2000 ili ranijim operativnim sistemima, oni neće moći da koriste Delta CRL. Moramo da definišemo kraće intervale objavljivanja za osnovnu CRL tako da svi kompjuteri imaju ažurirane informacije.
  • CRL retrival network load: U slučaju konfiguracije čestog intervala objavljivanja osnovne CRL, češće će svi klijenti preuzimati ažuriranu osnovnu CRL. Ako je veličina osnovne CRL velika, klijentski kompjuteri će generisati veći mrežni saobraćaj prilikom preuzimanja CRL.
  • Delta CRL size (veličina Delta CRL): Objavljivanje osnovne CRL nakon dugih intervala rezultuje sa velikom Delta CRL. Potrebno je koristiti delta CRL da bi se smanjila veličina danlodovane CRL.
  • CRL Revocation Freqvecy: Broj sertifikata koji su poništeni u određenom periodu umnogome utiče na interval objavljivanja za obe osnove i delta CRL. Potrebno je objaviti CRLs u određenim vremenskim intervalima tako da svi poništeni sertifikati budu na vreme prepoznati. Treba izbalansirati interval objavljivanja sa mrežnim opterećenjem koje nestaje usled CRL preuzimanja saobraćaja.



Gde se objavljuju AIAs & CDPs

Nakon instalacije Root CA, moramo da konfigurišemo dva X.509 version 3 polja poznata pod imenom AIA i CDP extenzije. Ove ekstenzije se postavljalju na svim sertifikatima koje je dodelio Root CA. Ove ekstenzije definišu gde klijentske aplikacije mogu da pronađu validne AIA i CDP informacije za Root CA.

Formatiranje i objavljivanje AIA i CDP URL-ova su generalno isti za Root CA, Policy CA i Issuing CA. Razlika između offline CAs i Online CAs je u tome što offline CAs zahteva ručne sertifikate i CRL objavljivanje u direktorijumu ili na Web serveru.

Možemo da objavimo Root CA servetifikat i CRL na sledećim lokacijama:
  • Aktivnom direktorijumu
  • Web serveru
  • FTP serveru
  • File serveru

Tačke objavljivanja: Da bi osigurali pristupačnost na svim kompjuterima u šumi, potrebno je da objavimo offline Root CA sertifikat i offline Root CA`s CRL u aktivnom direktorijumu koristeći certutil komandu. Ova komanda smešta root CA sertifikat i CRL u configuration-naming kontekstu, koji aktivni direktorijum replicira ka svim domenskim kontrolerima u šumi. Na primer, sledeća komanda će objaviti Root CA sertifikat koji je instaliran na Casrv1 u aktivnom direktorijumu.

Certutil –dispublish –f CAsrv1.linkgroup.com_CAsrv1.crt RootCA

Dodaj komentar Sviđa mi se - (0) Ne sviđa mi se - (0)    

  • Upravljanje CA 1
  • Upravljanje CA 2
  • Upravljanje CA 3
  • Upravljanje CA 4
  • Upravljanje CA 5