Σχεδίαση και υλοποίηση Certification Authorities σε περιβάλλον Windows Server

Το μεγαλύτερο βάρος σε ένα έργο ΡΚΙ πρέπει να δοθεί στο σωστό σχεδιασμό, ακολουθούμενο από τη σωστή εγκατάσταση και παραμετροποίηση.

Στο άρθρο που δημοσιεύτηκε στο προηγούμενο τεύχος με τίτλο «Ισχυρή ασφάλεια για ασύρματα και ενσύρματα δίκτυα στις επιχειρήσεις», είδαμε πώς μπορούμε να εκμεταλλευτούμε μία υπάρχουσα υποδομή ΡΚΙ προκειμένου να στήσουμε ένα περιβάλλον ασφαλούς ασύρματης δικτύωσης σε ένα Οργανισμό. Στο άρθρο αυτό, το οποίο μπορούμε να πούμε πως αποτελεί φυσική συνέχεια του προηγούμενου, θα δούμε αναλυτικά τον τρόπο με τον οποίο θα στήσουμε αυτή την υποδομή με τη χρήση Windows Server 2008R2, κάτι που είναι προϋπόθεση για τη λειτουργία της συνολικής περιγραφόμενης λύσης.

Ιστορική αναδρομή
Η διαδεδομένη χρήση τεχνολογιών ΡΚΙ ξεκίνησε από τα μέσα της δεκαετίας του ’90, οπότε και οι σχετικές τεχνολογίες έγιναν ευρύτερα γνωστές και διαθέσιμες στο χώρο του ΙΤ. Εκείνη την εποχή πρωτοπορούσαν εταιρείες όπως η VeriSign (το πρώτο Certification Authority) και η Netscape (δημιουργός του SSL). Το 1997 η Microsoft για πρώτη φορά προσέφερε δωρεάν λογισμικό δημιουργίας ενδοεταιρικού Certification Authority (CA), περιλαμβάνοντας τα Certificate Services ως κομμάτι του Windows NT 4.0 Option Pack. Ένα από τα ελάχιστα βιβλία της εποχής για ΡΚΙ (Digital Certificates, Feghhi/Fegghi/Williams) αφιέρωνε ένα σημαντικό μέρος στο στήσιμο και την παραμετροποίηση της υπηρεσίας αυτής, δίνοντας έτσι μια επιπλέον ώθηση στη χρήση της. Από τότε έχουν περάσει 15 χρόνια και τα Active Directory Certificate Services (AD CS), όπως είναι πλέον η επίσημη ονομασία τους στα Windows Server 2008R2, συνεχίζουν να αποτελούν μέρος των Windows Server και ίσως την πιο διαδεδομένη πλατφόρμα ενδοεταιρικών Certification Authorities (CAs). Η επιτυχία τους πηγάζει τόσο από τον ιδιαίτερα φιλικό τρόπο εγκατάστασης, όσο και από τη μη ύπαρξη επιπλέον χρεώσεων, πλην της άδειας του λειτουργικού – το οποίο ούτως ή άλλως οι περισσότεροι μικρομεσαίοι και μεγάλοι Οργανισμοί ήδη διαθέτουν.

Σχεδιασμός και προϋποθέσεις μιας υλοποίησης Windows Server 2008R2 AD CS
Μια πληθώρα από ρόλους που μπορούν να ενεργοποιηθούν στα Windows φαίνονται φαινομενικά απλοί και άμεσοι στην υλοποίησή τους (το γνωστό στήσιμο “Next-Next-Finish”) και το ΡΚΙ δεν θα μπορούσε να αποτελέσει εξαίρεση. Ωστόσο, αν δεν έχει προϋπάρξει σωστή σχεδίαση και προσεκτική υλοποίηση ενός τέτοιου περιβάλλοντος, η προσπάθεια μπορεί εύκολα να αποτύχει. Κρίνοντας από την κρισιμότητα των παρεχόμενων υπηρεσιών (κρυπτογράφηση, κ.λπ.) της εγκατάστασης μιας υποδομής ΡΚΙ, η εκ των υστέρων αποτυχία της μπορεί να δημιουργήσει τεράστια προβλήματα σε ένα Οργανισμό. Μια αποτυχία π.χ. στην ανάκτηση ιδιωτικών κλειδιών των εκδιδόμενων πιστοποιητικών, μπορεί να οδηγήσει σε μη αναγνώσιμα έγγραφα ή e-mails ή στην αποτυχία κρυπτογράφησης ενός ασφαλούς καναλιού. Κατά συνέπεια το μεγαλύτερο βάρος σε ένα έργο ΡΚΙ πρέπει να δοθεί στο σωστό σχεδιασμό, ακολουθούμενο από τη σωστή εγκατάσταση και παραμετροποίηση. Λόγω του περιορισμένου χώρου του παρόντος άρθρου δεν θα αναφερθούμε αναλυτικά στο σχεδιασμό, αλλά θα αρκεστούμε να αναφέρουμε ότι προ της εγκατάστασης θα πρέπει να αποφασιστούν κατ’ ελάχιστο τα εξής: α) Αν θα υπάρχουν πολλαπλές βαθμίδες στην ιεραρχία του CA, κάτι που περιορίζει τον κίνδυνο στην περίπτωση επίθεσης και ακύρωσής του, β) το μήκος του ιδιωτικού κλειδιού των πιστοποιητικών των CA και η διάρκεια ζωής τους, ανάλογα με το βαθμό ασφάλειας που θα αποφασίσουμε, γ) η χρήση διαδικασιών δημιουργίας ασφαλών αντιγράφων των ιδιωτικών κλειδιών που θα εκδίδονται, καθώς και πολλά άλλα.
Όσον αφορά στις προϋποθέσεις για την εγκατάσταση ενός ή περισσότερων CA σε ένα Οργανισμό, αυτές δεν είναι πολλές και σίγουρα υπάρχουν ήδη στην πλειοψηφία των μικρομεσαίων και μεγάλων Οργανισμών: θα χρειαστεί η ύπαρξη ενός υπάρχοντος Active Directory και ενός (ή δύο, ανάλογα με την επιλογή της ιεραρχίας) servers ή virtual machines με εγκατεστημένα Windows 2008R2 (στη συνέχεια του άρθρου θα ασχοληθούμε και με το θέμα των εκδόσεων του λειτουργικού που απαιτούνται). Αξίζει να αναφέρουμε ότι αν και δεν προτείνεται, υποστηρίζεται η εγκατάσταση του Issuing CA και σε ένα ήδη υπάρχοντα server που επιτελεί και άλλες λειτουργίες, αφού η χρήση της υπηρεσίας δεν επιβαρύνει παρά ελάχιστα το λειτουργικό σύστημα και τους πόρους του hardware.

Σχεδιασμός της χρήσης Certificate Revocations Lists (CRLs)
Είναι πολύ σημαντικό να κάνουμε ειδική μνεία στο σχεδιασμό μιας ιδιαίτερα ευαίσθητης υπηρεσίας, αυτής των Certificate Revocation Lists (CRLs – λίστες ανακληθέντων πιστοποιητικών). Οι λίστες αυτές περιλαμβάνουν τα (πιθανά) ανακληθέντα πιστοποιητικά, όπως αυτά έχουν εκδοθεί από τα Issuing CAs που έχουν εγκατασταθεί. Δύο πράγματα πρέπει να τονιστούν για αυτές τις λίστες: α) είναι πολύ σημαντικό να είναι συνεχώς διαθέσιμες, γιατί οι υπηρεσίες ή οι συσκευές που θα τις συμβουλευτούν θα πρέπει να ξέρουν αν ένα πιστοποιητικό έχει ανακληθεί (και κατά συνέπεια δεν είναι αξιόπιστο για τη δημιουργία ασφαλούς καναλιού επικοινωνίας) και β) σε περίπτωση ενδοεταιρικών υλοποιήσεων CA (όπως αυτές που αναλύουμε στο παρόν άρθρο) θα πρέπει να προαποφασίσουμε αν θέλουμε να είναι διαθέσιμες εκτός του εσωτερικού μας δικτύου. Η απόφαση για κάτι τέτοιο εξαρτάται από το αν τα πιστοποιητικά που θα εκδοθούν θα χρησιμοποιηθούν και από υπηρεσίες ή συσκευές που δεν ανήκουν στο εσωτερικό μας δίκτυο.

Αν δεν μας ενδιαφέρει η διάθεση της CRL στο internet, τα πράγματα τόσο για την υψηλή της διαθεσιμότητα όσο και για την ευκολία πρόσβασης προς αυτήν, είναι εύκολα. Και οι δύο προϋποθέσεις (υψηλή διαθεσιμότητα και διάθεση εκτός δικτύου) επιτυγχάνονται ως μέρος της αντίστοιχης διαδικασίας των domain controllers (DCs) – μέσω του Active Directory replication, δηλαδή (σε αυτό το σημείο γίνεται κατανοητή και η ευκολία που παρέχει το Active Directory στο συγκεκριμένο θέμα). Στη δεύτερη περίπτωση η υλοποίηση γίνεται περισσότερο περίπλοκη, αφού δεν επιθυμούμε να εκθέσουμε την εσωτερική διαδικασία του DC replication σε μη ασφαλή δίκτυα και κατά συνέπεια θα πρέπει να δημιουργήσουμε ένα ξεχωριστό σύστημα πρόσβασης και υψηλής διαθεσιμότητας της CRL. Αυτό επιτυγχάνεται με τη μη αυτόματη διάθεσή της μέσω web services (χρήση του ρόλου IIS των Windows Server 2008R2), μια διαδικασία η οποία προϋποθέτει την ύπαρξη ενός scheduled task αντιγραφής της CRL από το CA προς τουλάχιστον δύο IIS servers για την επίτευξη υψηλής διαθεσιμότητας, αλλά και τo «publishing» (διάθεση) αυτών προς το internet, ούτως ώστε να είναι διαθέσιμοι σε οποιονδήποτε εκτός δικτύου επιθυμεί να ελέγξει την κατάσταση ενός πιστοποιητικού που έχει εκδοθεί από δικά μας CAs. To τελευταίο σημείο εμπλέκει και το διαχειριστή του δικτύου, αφού θα πρέπει να δώσει πρόσβαση στους εσωτερικούς IIS μέσω (συνήθως) του firewall.
Στο παρόν άρθρο θα αρκεστούμε στο πρώτο σενάριο όσον αφορά στη CRL του CA που θα εκδίδει certificates, όχι γιατί είναι το πιο εύκολο, αλλά γιατί στη δική μας περίπτωση η ασφάλιση των ασύρματων συσκευών μας δεν ξεφεύγει από τα όρια του εσωτερικού μας δικτύου. Αντίθετα, στην περίπτωση του Offline Root CA, επειδή δεν διατίθεται αυτή η διαδικασία θα πρέπει με μη αυτόματο τρόπο να την εισάγουμε στο Active Directory, κάτι που θα δούμε παρακάτω.

Εγκατάσταση ενός Windows Server 2008R2 AD CS
Στο παρόν άρθρο θα αναφερθούμε στην εγκατάσταση μιας ιεραρχίας δύο βαθμίδων (two-tier hierarchy) σε ένα υποθετικό ενδοεταιρικό CA – θα ξεκινήσουμε με το λεγόμενο Offline Root CA (ας το ονομάσουμε «ORCA») και θα συνεχίσουμε με το Online Enterprise Issuing Subordinate CA (ας το ονομάσουμε «OEISCA»). Θα χρειαστούμε δύο εγκαταστάσεις Windows 2008R2 – για το μεν ORCA αρκεί η Standard έκδοση του λειτουργικού, για το δε OEISCA είναι προτιμότερη η χρήση της Enterprise έκδοσης, για να εκμεταλλευτούμε τη δυνατότητα μιας υπηρεσίας που θα δούμε αργότερα και που ονομάζεται Key Archival.
Ξεκινώντας από τον ORCA αξίζει να αναφέρουμε ότι μετά την εγκατάστασή του, για λόγους ασφαλείας θα πρέπει να εκδώσει ένα μόνο πιστοποιητικό στον OEISCA. Μετά αυτό θα πρέπει να κλείσει (εξ ου και το “offline”) και να τοποθετηθεί σε ένα φυσικά ασφαλές και φυλασσόμενο σημείο. Κατ’ επέκταση, το λειτουργικό στο οποίο θα στηθεί δεν θα πρέπει να γίνει join σε Active Directory domain. Κατά τα άλλα η εγκατάσταση δεν περιλαμβάνει δύσκολα βήματα – σημαντικές επιλογές που πρέπει να γίνουν είναι το στήσιμο ως “standalone” & “root CA”. O χρόνος διάρκειας είναι συνήθως 5-20 χρόνια, αφού θεωρητικά είναι ιδιαίτερα ασφαλής (από τις δικές μας ενέργειες θα κριθεί τελικά ο βαθμός ασφαλείας του). Αφού στηθεί θα πρέπει να ενεργοποιηθεί το auditing, να εκδώσουμε μία CRL και να εξαχθεί το CA certificate και η CRL, έτσι ώστε και τα δύο αυτά να εισαχθούν στο Active Directory προκειμένου να τα «εμπιστεύονται» όλοι οι χρήστες και υπολογιστές του domain. Επιπλέον, πρέπει εκ των υστέρων να εκδώσει και να παράσχει στο subordinate CA το πιστοποιητικό του, όταν γίνει το σχετικό request κατά τη διάρκεια του στησίματος του τελευταίου. Μετά από αυτά μπορεί να κλείσει και να ανοίξει ξανά μόνο όταν έρθει η ώρα να εκδοθεί νέα CRL (η συχνότητα έκδοσης ρυθμίζεται με σχετική εντολή κατά το στήσιμο) και περιοδικά (ελάχιστες φορές το χρόνο) προκειμένου να πάρει security updates για το λειτουργικό. Αξίζει να σημειωθεί ότι λόγω της φύσης του, ο ORCA είναι εξαιρετικός candidate για να στηθεί σε virtual machine, αλλά λόγω της σημαντικότητάς του, θα πρέπει να προσεχθεί ιδιαίτερα η φυσική πρόσβαση στο virtualization server και στο ίδιο το virtual machine.

Συνεχίζοντας με τον OEISCA θα πρέπει να έχουμε φροντίσει το computer object να έχει γίνει join στο Active Directory domain και να επιλέξουμε να εγκατασταθεί το CA ως Enterprise & Subordinate. Μόλις στηθεί θα δημιουργηθεί ένα certificate request το οποίο πρέπει να «ταξιδέψει» μέχρι τον ORCA, αυτός να το εκδώσει και το τελικό εκδοθέν πιστοποιητικό να εγκατασταθεί στον EISCA. Στη συνέχεια θα πρέπει να εκδώσουμε και εδώ τη CRL του συγκεκριμένου CA και – αν όλα έχουν πάει καλά – είμαστε έτοιμοι να εκδώσουμε το πρώτο μας πιστοποιητικό.
Certificate Templates
Η έκδοση πιστοποιητικών για συγκεκριμένο σκοπό διευκολύνεται ιδιαίτερα από την ύπαρξη templates με τις κατάλληλες προεπιλογές, έτσι ώστε να μπορούμε σε πολύ μικρό χρονικό διάστημα να εκδώσουμε ένα πιστοποιητικό για τον κατάλληλο σκοπό, με τις κατάλληλες ρυθμίσεις, εύκολα και χωρίς να χρειάζεται να ξέρουμε πολλά πράγματα εκτός από τη χρήση για την οποία εκδίδεται. Για τη χρήση τους σε συσκευές όπως οι υπολογιστές (όπως αναφέρθηκε και στο πρώτο μέρος του άρθρου) μπορούμε να χρησιμοποιήσουμε το workstation template και δίνοντάς του δικαιώματα για τους υπολογιστές που μας ενδιαφέρουν, να εκδώσουμε πολύ γρήγορα πιστοποιητικά. Επιπλέον, με τη χρήση μιας δυνατότητας η οποία ονομάζεται Autoenrollment μπορούμε να διανείμουμε πιστοποιητικά κατά χιλιάδες μέσα σε λίγες ώρες, σε χρήστες και υπολογιστές που είναι joined στο domain.

Ένα CA δεν αρκεί να εκδίδει πιστοποιητικά – θα πρέπει να έχει και την κατάλληλη υποδομή για να τα υποστηρίξει. Έτσι λοιπόν στα Windows Server 2008R2 διατίθεται ένα πολύ ελκυστικό και ιδιαίτερα εύκολο περιβάλλον χρήσης και παραμετροποίησης, ενώ έχουμε τη δυνατότητα ανάκτησης των πιστοποιητικών (μαζί με τα ιδιωτικά κλειδιά τους) αν ενεργοποιήσουμε την υπηρεσία Key Archival. Για χρήστες οι οποίοι μετακινούνται συνεχώς από PC σε PC ή notebook, μπορούμε να εγκαταστήσουμε και την υπηρεσία Credential Roaming, η οποία αναλαμβάνει να μας διαθέσει τα ίδια (ήδη εκδοθέντα) πιστοποιητικά σε πολλαπλές συσκευές στις οποίες κάνει logon ο ίδιος χρήστης. Διατίθενται επίσης οι δυνατότητες έκδοσης και διανομής για φορητές συσκευές που υποστηρίζουν το πρωτόκολλο SCEP (όπως π.χ. συσκευές με iOS 5.x) καθώς και για συσκευές που δεν ανήκουν στο εταιρικό domain.
Συμπεράσματα
Με τη χρήση των Windows Server 2008R2 η εγκατάσταση και η λειτουργία ενός Certification Authority γίνεται εύκολα και χωρίς ιδιαίτερα προαπαιτούμενα. Θα πρέπει ωστόσο να δοθεί μεγάλο βάρος στο σωστό σχεδιασμό, ώστε η υλοποίηση να συνάδει με τους επιχειρηματικούς σκοπούς για τους οποίους στήνεται το CA, αλλά και να αποτελεί παράδειγμα ασφαλούς υπηρεσίας στο ενδοεταιρικό μας περιβάλλον. Θα πρέπει να προσεχθεί ιδιαίτερα η σωστή υλοποίηση των CRLs και ο ενδελεχής έλεγχος της εγκατάστασης, ώστε αυτή να παράσχει τα επιθυμητά αποτελέσματα.
—
Σημείωση: το παρόν άρθρο αποτελεί μια απλή (και απλοποιημένη) αναφορά σε υπηρεσίες Windows ΡΚΙ – σε καμία περίπτωση δεν πρέπει να χρησιμοποιηθεί αυτούσιο ως οδηγός για τη δημιουργία τέτοιων εγκαταστάσεων σε παραγωγικό περιβάλλον. Υπάρχουν διάφορα best practices τα οποία είτε δεν έχουν αναφερθεί για λόγους συντομίας είτε έχουν παραβλεφθεί για λόγους απλοποίησης. Αν επιθυμείτε περισσότερες πληροφορίες, προτείνεται η χρήση των υπαρχουσών πηγών της Microsoft στο TechNet (http://technet.microsoft.com).

Το θέμα του συγκεκριμένου άρθρου αποτέλεσε παρουσίαση των : Δημήτρη Παπίτση και Γιώργου Σπηλιώτη στα πλαίσια του ITPro|Dev Connections 2011 που διεξήχθη στις 26-27 Νοεμβρίου 2010

Ο Δημήτρης Παπίτσης είναι κάτοχος B.Sc. in Business Administration – Computer Information Systems και πολλών πιστοποιήσεων της Microsoft, όπως Microsoft Certified IT Professional και Microsoft Certified Trainer, ενώ δραστηριοποιείται στο χώρο του IT από το 1998. Εργάζεται ως Premier Field Engineer στη Microsoft Hellas, ενώ ειδικεύεται στους τομείς e-mail and collaboration και ασφαλείας. Είναι, επίσης ιδρυτικό μέλος της Κοινότητας Επαγγελματιών Πληροφορικής autoexec.gr.

Του Δημήτρη Παπίτση *
Microsoft MVP – Enterprise Security
MCSE, MCT