Certification Authority
[email protected]
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
[email protected]
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
[email protected]
Applicazioni che usano una PKI
Digital
Signatures
Smart Card
Logon
Encrypting
File System
Secure
E-mail
Internet
Authentication
Windows 2003
Certificate Services
Software
Code Signing
Software
Restriction Policy
802.1x
[email protected]
IP Security
Quali Account Usano applicazioni PKI-Enabled?
Utenti
Computer
Servizi
[email protected]
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?
[email protected]
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?
[email protected]
Progettazione della gerarchia delle CA: Location
Location
Root
Policy
India
Canada
United States
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
[email protected]
Passi per progettare i Requisiti Legali
1
2
3
Root CA
Security
Policy
Certificate
Policy
Certificate
Practice
Statement
Policy CA
1
Sviluppare la security policy
2
Creare la certificate policy
3
Creare il Certificate Practice
Statement (CPS)
4
Pubblicare il CPS sulla policy CA
[email protected]
4
Issuing CA
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
[email protected]
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à
[email protected]
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
[email protected]
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 rete
Conservare le CA offline in un luogo sicuro
Mettere in
sicurezza
l’issuing CA
Controllare l’accesso alla sala server
Rimuovere i servizi non usati sulla issuing CA
Proteggere le
chiavi private
Usare Software CSP
Usare smart cards o PC card token con PIN
Usare Hardware Security Module
Fornire requisiti
di rilascio
differenti
Implementare CA separate per supportare template
di certificate diversi per ogni tipo di requisito di
rilascio
[email protected]
Come supportare i requisiti di Accesso Esterno
Requisiti
Azioni consigliate
Abilitare i client
esterni a riconoscere i
certificati
Usare una CA commerciale
Implementare cross certification
Implementare qualified subordination
Pubblicare 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
[email protected]
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
[email protected]
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
[email protected]
Profondità Raccomandata di una Gerarchia di CA
Requisiti
Bassa Sicurezza
(1 livello)
Media Sicurezza
(2 livelli)
Alta Sicurezza
(3-4 livelli)
Profondità Raccomandata
Root CA singola
Poche richieste di certificati
Bassi requisiti di sicurezza per la Sicurezza della CA
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
Offline root e offline policy
Più issuing CA subordinate online
Massimizzare la sicurezza
Organizzazione grandi e geograficamente
distribuite o a alta sicurezza
[email protected]
Livelli di sicurezza nella Gerarchia di CA
Sicurezza per la root CA:
Richiede i più alti livelli di
sicurezza
Minore
Maggiore
Root CA
Sicurezza
Richiede accesso minimo
Policy CA
All’aumentare della
distanza dalla root CA:
Facilità di accesso
Issuing CA
Diminuisce la Sicurezza
Aumenta l’accesso alle
issuing CA
[email protected]
Maggiore
Minore
Considerazioni per la scelta di un tipo di CA
Decision point
Quando usarla
Active Directory
Tipo di
Certificate
Gestione della
richiesta del
Certificato
Standalone
CA Offline
Enterprise
Issuing CA
Non richiede Active
Directory
Richiede Active
Directory
Fornisce supporto
per tipi di certificati
standard
Implementa i modelli
di certificato
Rilasciato o negato
da un certificate
manager
Rilasciato o negato
basandosi sulle
permission del modello
di certificato
[email protected]
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
[email protected]
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
[email protected]
LAB
Creazione del CAPolicy.inf
[email protected]
Definire le impostazioni per una CA Root Offline
Offline
Root CA
Database and
Log Settings
Standalone
CA Policy
Validity Period
Computer Name
Key Length
CA Name
[email protected]
Cryptographic
Service Provider
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
[email protected]
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 (1020 anni)
[email protected]
Lab
Installazione di una CA Root Offline
[email protected]
Come le applicazioni verificano lo stato dei Certificati
Processo
Azione
1.Raccolgono i certificati delle CA
dalla cache (CryptoAPI), Group
Policy, applicazioni, AIA URL
Certificate
discovery
2.Validano i certificati con le chiavi
pubbliche e i certificati che li
rilasciano
Path validation
3.Verificano che nessun certificato
Revocation
checking
[email protected]
sia revocato
Il Certificate Chaining Engine
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
Root 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
Policy CA
- Cache delle CryptoAPI
- Group Policy (NIENTE SCORCIATOIE !!!)
Issuing CA
- Authority Information Access (AIA) presente nei
diversi certitificati
In Parallelo si verificano le CRL (W2k3/win XP/W2k)
Computer or
User Certificate
[email protected]
Test di validazione dei Certificati
Test
Time validity
Criterio
La 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 check
Revocation check
Il contenuto del certificato non è stato
modificato
Il certificato non è stato revocato
Root check
Il Certificato è concatenato a una trusted root
CA
Policy validation
Il Certificato deve contenere le certificate o
application policy richieste dall’applicazione
Critical extensions
[email protected]
L’applicazione riconosce le estensioni critiche
Tipi di CRL
Caratteristiche
Certificati
Intervallo di
Pubblicazione
Dimensione
CRL Base
CRL Delta
Contiene tutti i
certificati revocati
Contiene solo i
certificati revocati
dall’ultima CRL base
Pubblicata meno
frequentemente
Pubblicata più
frequentemente
Grande
Riconosciuta da
Computer Client qualunque versione di
Windows
[email protected]
Piccola
Riconosciuta da
Windows XP o Windows
Server 2003
Come vengono pubblicate le CRL
Delta
CRL #2
Cert5
Revoke
Cert5
Revoke
Cert7
Cert5
Cert7
Delta
CRL #3
Time
Cert3
Cert3
Cert5
Cert7
Base
CRL #1
[email protected]
Base
CRL #4
Dove creare i Publication Point
External
Web Server
Active
Directory
FTP
Server
Internet
Firewall
Firewall
Internal
Web
Server
File
Server
Pubblicare il
certificato
della root CA
e la CRL in:
Active Directory
Web servers
FTP servers
File servers
[email protected]
Offline
Root CA
Lab
Modificare le extension CrlDP e AIA
[email protected]
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
[email protected]
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
[email protected]
Considerazioni per configurare le estensioni AIA e CDP
Utenti
Strategia
•Pubblicate CRL e AIA esternamente
•Configurate il DNS perche faccia
Esterni
riferimento all’indirizzo IP esterno
di pubblicazione della CRL
•Non modificate la pubblicazione di
default:
– Active Directory
Interni
– Il Web server della CA enterprise
[email protected]
Lab C:
Implementazione di una CA Enterprise Subordinata
[email protected]