Upload
rosangela-colombo
View
223
Download
0
Embed Size (px)
Citation preview
Certification Authority
Overview
Requisiti di progettazione di una gerarchia di CA
Progettazione di una gerarchia di CA
Creazione di una CA Root Offline
Validazione dei Certificati
Pianificazione della pubblicazioni della CRL
Installazione di una CA Subordinata
Identificare i requisiti per progettare una gerarchia di CA
Scope del Progetto
Applicazioni che usano una PKI
Quali Account usano applicazioni PKI-Enabled?
Come identificare i requisiti tecnici
Come identificare i requisiti di Business
SoftwareCode Signing
SoftwareCode Signing
EncryptingFile SystemEncryptingFile System
Smart CardLogon
Smart CardLogon
802.1x802.1x IP SecurityIP Security
InternetAuthentication
InternetAuthentication
SecureE-mailSecureE-mail
Applicazioni che usano una PKI
Windows 2003Certificate Services
Windows 2003Certificate Services
SoftwareRestriction Policy
SoftwareRestriction Policy
DigitalSignatures
DigitalSignatures
Quali Account Usano applicazioni PKI-Enabled?
UtentiUtenti
ComputerComputer
ServiziServizi
Come Identificare i requisiti Tecnici
Per Chiedere
Requisiti di sicurezza
Quali sono le policy di sicurezza dell’azienda?Avete dei Business Partner? Dovete rispettare standard industriali ogovernativi?
Requisiti Amministrativi
Chi gestirà le CA?Chi gestirà i certificati?
Requisiti di Disponibilità
Quante CA richiede l’azienda?Come vengono distribuiti i certificati tra le CA?
Come Identificare i requisiti di Business
Per Chiedere
Requisiti di Accesso dell’Esterno
Verranno rilasciati certificati a utenti esterni?I certificati verranno validati da reti esterne?
Requisiti di disponibilità
Verranno richiesti certificati a qualunque ora?Verranno richiesti servizi in ogni sede?
Requisiti Legali
Quali sono le politiche di sicurezza aziendali?Qual è la responsabilità dell’organizzazione?
Progettazione della gerarchia delle CA: Location
LocationLocation
IndiaIndia CanadaCanada United StatesUnited States
RootRoot
PolicyPolicy
Si usa una gerarchia di CA basata sulla location per:
Rispettare i requisiti legali locali (gestione)
Rispettare i requisiti di Business per la disponibiltà della CA
Passi per progettare i Requisiti Legali
SecurityPolicy
SecurityPolicy
11
Sviluppare la security policySviluppare la security policy11
Root CA
Policy CA
Issuing CA
44
Pubblicare il CPS sulla policy CAPubblicare il CPS sulla policy CA44
Creare la certificate policyCreare la certificate policy22
CertificatePolicy
CertificatePolicy
22
Creare il Certificate Practice Statement (CPS)Creare il Certificate Practice Statement (CPS)33
CertificatePractice
Statement
CertificatePractice
Statement
33
Security Policy
Definisce le classi di dati da proteggere e le misure da adottare: tra queste i certificati
Tra l’altro stabilisce:
Quali dati/applicazioni/servizi devono essere protetti con i certificati digitali
Quali misure adottare per proteggere le chiavi private associate ai certificati (smart card, token, Hardware Security Module, ...)
Quali misure usare per verificare l’identità di chi richiede un certificato
Certificate Policy
Descrive le procedure adottate per validare l’identità di chi richiede un certificato prima della sua emissione
È la policy di emissione del certificato che determina se ci si può fidare del certificato stesso
Dovrebbe contenere le seguenti informazioni:Com’è verificata l’identità del richiedente
L’uso dei certificati rilasciati dalla CA
Il device in cui le chiavi private devono essere conservate
La responsabilità del subject nel caso la chiave privata sia compromessa o persa
Le policy di revoca, le procedure e le responsabilità
Certification Practice Statement
Definisce le misure usate per rendere sicure le operazioni della CA e la gestione dei certificati
È un documento pubblico che deve essere accessibile a tutte le entità che usano i certificati rilasciati dalla CA
Deve contenere le seguenti informazioni:Come la CA applica le misure per la verifica delle identità prima del rilascio dei certificati
La responsabilità dell’organizzazione in caso di frode verso un servizio protetto dal certificato nel caso in cui si dimostri il problema essere nel certificato
Le circostanze che possono portare ad una revoca preventiva dei certificati
Quando il CPS è inserito nel certificato di una CA si applica alla CA stessa e a tutte le subordinate
Come soddisfare i Requisiti di Sicurezza
Requisiti Azioni consigliate
Mettere in sicurezza la root e la policy CA
Rimuovere la root e la policy CA dalla reteConservare le CA offline in un luogo sicuro
Mettere in sicurezza l’issuing CA
Controllare l’accesso alla sala serverRimuovere i servizi non usati sulla issuing CA
Proteggere le chiavi private
Usare Software CSPUsare smart cards o PC card token con PINUsare Hardware Security Module
Fornire requisiti di rilascio differenti
Implementare CA separate per supportare template di certificate diversi per ogni tipo di requisito di rilascio
Come supportare i requisiti di Accesso Esterno
Requisiti Azioni consigliate
Abilitare i client esterni a riconoscere i certificati
Usare una CA commercialeImplementare cross certificationImplementare qualified subordinationPubblicare le informazioni di CRL e AIA esternamente
Gestire i certificati rilasciati agli utenti esterni
Rilasciare certificati da una gerarchia di CA privata
Trustare i certificati rilasciati da un’altra organizzazione
Implementare la certificate trust lists
Implementare cross certification o qualified subordination
Come supportare i Requisiti delle Applicazioni
Requisiti Azioni consigliate
Minimizzare il numero di certificati rilasciati
Implementare certificati con uso multiplo
Minimizzare il numero di CA
Pubblicare più certificate da una CA
Gestire le CA basandosi sulle applicazioni
Pubblicare ogni template di certificato da una CA dedicata
Progettazione di una struttura di CA gerarchiche
Profondità raccomandata di una Gerarchia di CA
Livelli di Sicurezza di una Gerarchia di CA
Considerazioni nella scelta di una tipologia di CA
Gestione della CA utilizzando la separazione dei Ruoli
Linee Guida per la progettazione di una Gerarchia di CA
Profondità Raccomandata di una Gerarchia di CA
Requisiti Profondità Raccomandata
Bassa Sicurezza
(1 livello)
Root CA singola
Poche richieste di certificati
Bassi requisiti di sicurezza per la Sicurezza della CA
Media Sicurezza
(2 livelli)
Root offline e subordinata online
Una singola CA offline (disconnessa dalla rete)
Una Issuing CA online
Due o più CA per rilasciare ogni modello di certificato
Alta Sicurezza
(3-4 livelli)
Offline root e offline policy
Più issuing CA subordinate online
Massimizzare la sicurezza
Organizzazione grandi e geograficamente distribuite o a alta sicurezza
Livelli di sicurezza nella Gerarchia di CA
Sicurezza per la root CA:
Richiede i più alti livelli di sicurezza
Richiede accesso minimo
All’aumentare della distanza dalla root CA:
Diminuisce la Sicurezza
Aumenta l’accesso alle issuing CA
Root CA
Policy CA
Issuing CA
Maggiore
Minore
Minore
Maggiore
Facilità di accessoFacilità di accesso
SicurezzaSicurezza
Considerazioni per la scelta di un tipo di CA
Decision point
Standalone Enterprise
Quando usarla CA Offline Issuing CA
Active Directory
Non richiede Active Directory
Richiede Active Directory
Tipo di Certificate
Fornisce supporto per tipi di certificati standard
Implementa i modelli di certificato
Gestione della richiesta del Certificato
Rilasciato o negato da un certificate manager
Rilasciato o negato basandosi sulle permission del modello di certificato
Creazione di una gerarchia di CA
Creazione di una CA Root Offline
Validazione dei Certificati
Pianificazione della pubblicazioni della CRL
Installazione di una CA Subordinata
Creazione di una CA Root Offline: file CAPolicy.inf
Il file CAPolicy.inf file definisce la configurazione dei Certificate Service
Il file CAPolicy.inf definisce il:
Certificate Practice Statement (CPS)
Intervallo di pubblicazione della CRL
Le impostazioni di rinnovo dei certificati
La dimensione della chiave
Il periodo di validità del certificato
I percorsi CrlDP, AIA
Definire le impostazioni per una CA Root Offline
OfflineRoot CAOffline
Root CA
StandaloneCA Policy
StandaloneCA Policy
Validity PeriodValidity Period
Key LengthKey Length
Database andLog Settings
Database andLog Settings
CryptographicService ProviderCryptographic
Service Provider
CA NameCA Name
Computer NameComputer Name
Mettere in sicurezza una CA Offline con un HSM
Un Hardware Security Module (HSM) fornisce:
Key Storage e backup sicuro (HW)
Accelerazione delle operazioni di crittografia
Protezione e gestione delle chiavi private
Load Balancing e failover tramite moduli HW
Linee Guida per distribuire una CA Root Offline
Per distribuire una CA Root Offline:
Non collegare la CA alla rete
Implementare CDP e AIA extension vuote
Implementare un CSP HW o un HSM
Scegliere una lunghezza di chiave supportate da tutti i protocolli e le applicazioni
Usate un unico distinguished name per la CA
Impelementate un periodo di validità lungo (10-20 anni)
Come le applicazioni verificano lo stato dei Certificati
Processo Azione
Certificate discovery
1.Raccolgono i certificati delle CA dalla cache (CryptoAPI), Group Policy, applicazioni, AIA URL
Path validation
2.Validano i certificati con le chiavi pubbliche e i certificati che li rilasciano
Revocation checking
3.Verificano che nessun certificato sia revocato
Il Certificate Chaining Engine
Root CA
Issuing CA
Policy CA
Computer or User Certificate
L’applicazione che riceve il certificato chiama il Certificate Chaining Engine per la verifica dei certificati
Il Certificate Chaining Engine verifica:
- il certificato presentato all’applicazione
- il certificato della CA che lo ha rilasciato: l’Issuing CA
- il certificato della CA che ha autorizzato l’Issuing CA
- e così via fino a raggiungere una Root CA
I certificati sono raccolti da
- Cache delle CryptoAPI
- Group Policy (NIENTE SCORCIATOIE !!!)
- Authority Information Access (AIA) presente nei diversi certitificati
In Parallelo si verificano le CRL (W2k3/win XP/W2k)
Test di validazione dei Certificati
Test Criterio
Time validityLa data corrente cade tra la data di partenza e di scadenza del certificato
Certificate recognition
Il certificato usa un formato X.509 valido
Certificate contents Tutti i campi richiesti sono completati
Signature checkIl contenuto del certificato non è stato modificato
Revocation check Il certificato non è stato revocato
Root checkIl Certificato è concatenato a una trusted root CA
Policy validation Il Certificato deve contenere le certificate o application policy richieste dall’applicazione
Critical extensionsL’applicazione riconosce le estensioni critiche
Tipi di CRL
Caratteristiche CRL Base CRL Delta
CertificatiContiene tutti i certificati revocati
Contiene solo i certificati revocati dall’ultima CRL base
Intervallo di Pubblicazione
Pubblicata meno frequentemente
Pubblicata più frequentemente
Dimensione Grande Piccola
Computer Client
Riconosciuta da qualunque versione di Windows
Riconosciuta da Windows XP o Windows Server 2003
Come vengono pubblicate le CRL
Time
RevokeCert5
RevokeCert7
BaseCRL #4Base
CRL #4
Cert3Cert5Cert7
Delta CRL #2Delta CRL #2
Delta CRL #3Delta CRL #3Cert5 Cert5
Cert7
BaseCRL #1Base
CRL #1
Cert3
Dove creare i Publication Point
OfflineRoot CAOffline
Root CA
Active Directory
Active Directory
External Web Server
External Web Server
Internal Web
Server
Internal Web
Server
Internet
Firewall
FTP ServerFTP
Server
File Server
File Server
Active DirectoryWeb serversFTP serversFile servers
Active DirectoryWeb serversFTP serversFile servers
Firewall
Pubblicare il certificato
della root CA e la CRL in:
CA Subordinata: preparare l’Issuing CA
Per preparare l’Issuing CA a rilasciare un certificato di CA subordinata
Verificare che le estensioni AIA e CDP siano valide
Configurate il periodo di validità massimo per tutti i certificati rilasciati
Confgurate il periodo di validità per il modello di certificato della CA Subordinata
Passi per installare una CA Enterprise Subordinata
Per installare una CA Enterprise Subordinata
Determinate la tipologia della parent CA
Installate i Certificate Services
Sottoponete la richiesta di certificato della CA Subordinata alla CA immediatamente superiore nella gerarchia di CA
Installate il certificato della CA Subordinata
Considerazioni per configurare le estensioni AIA e CDP
Utenti Strategia
Esterni
•Pubblicate CRL e AIA esternamente
•Configurate il DNS perche faccia riferimento all’indirizzo IP esterno di pubblicazione della CRL
Interni
•Non modificate la pubblicazione di default:– Active Directory– Il Web server della CA enterprise