Gestion efficace des certificats numériques par API

Une bonne API fait la différence entre une application software et une plateforme software . Sans API, un produit software est un outil à usage spécial pour un ensemble prédéfini d'opérations spécifiques. En revanche, avec une bonne API, il peut devenir une plateforme puissante et modulaire dont les capacités vont bien au-delà de ce que ses développeurs avaient imaginé à l'origine.

Les tâches qui nécessitent des milliers de clics et de frappes peuvent être réduites à une seule frappe pour lancer un script. Et les processus commerciaux qui nécessitent plusieurs applications software peuvent être intégrés de manière transparente, de sorte que les utilisateurs finaux n'ont même pas besoin de savoir quel software est utilisé. Tout cela est vrai pour CMS, et avec le lancement de CMS 5.0 et du SDK CMS PowerShell, les capacités de CMS basées sur l'API sont plus puissantes que jamais et plus faciles à utiliser !

Imaginez le scénario suivant : Une douzaine d'employés venant d'un autre site rejoignent votre équipe de développement. Ils disposent déjà de postes de travail, mais n'ont pas les certificats clients nécessaires pour accéder à votre dépôt de code source.

Est-ce que vous.. :

1. Demandez à votre administrateur système de faire le tour de chaque poste de travail, de s'inscrire pour obtenir un certificat et de l'installer.
2. Demander à tous les employés de se rendre sur le portail d'inscription du CMS et de demander un certificat, approuver les demandes et demander aux employés de les installer au bon endroit.
3. Exécutez un script PowerShell de 15 lignes qui recherche les ordinateurs des utilisateurs, obtient un certificat pour chacun d'eux et envoie automatiquement le certificat au magasin de machines approprié par l'intermédiaire de l'agent Windows CMS.

Dans les deux premiers cas, une coordination est nécessaire entre plus d'une douzaine de personnes. De plus, ces options ne sont d'aucune utilité pour la prochaine douzaine d'employés à recruter. En revanche, avec une solution basée sur une API, vous pouvez développer un processus automatisé et reproductible à l'aide d'un script PowerShell simple et court. Un script qui ne se soucie pas de savoir s'il s'agit d'émettre une douzaine de certificats pour les nouveaux employés ou dix mille certificats pour l'ensemble de l'organisation. Un tel script est présenté à la fin de ce billet sous le nom de "Script 1". En outre, si vous pouvez lancer le script à partir d'une autre partie de votre processus d'intégration et de provisionnement, vous disposez désormais d'une solution sans intervention pour émettre des certificats à chaque fois que vous en avez besoin.

Le CMS peut également aider dans le cas inverse. Supposons qu'un groupe d'employés quitte une division. Chacun d'entre eux disposait de certificats personnels, ainsi que de certificats sur leurs postes de travail et autres appareils, pour accéder à une série d'applications spécifiques au groupe. Vous souhaitez révoquer immédiatement tous les certificats auxquels ces employés ont accès.

Est-ce que vous.. :

1. Demandez à vos administrateurs système de rechercher les certificats installés sur leurs machines, de rechercher les certificats émis par les autorités de certification, de révoquer ces certificats et d'espérer que vous les avez tous trouvés.
2. Utilisez le portail de gestion CMS pour passer en revue les employés et les postes de travail, rechercher les certificats qui leur ont été délivrés ou qui sont présents sur leurs appareils et les révoquer manuellement.
3. Exécutez un script PowerShell de 15 lignes qui recherche dans votre inventaire de certificats tous les certificats délivrés à ces utilisateurs ou présents sur leur poste de travail, et qui les révoque tous automatiquement.

Une fois de plus, quelques lignes de script suffisent pour exécuter rapidement, de manière cohérente et exhaustive des opérations sensibles au facteur temps, sans se soucier du nombre d'utilisateurs et de machines concernés, ni du moment et de la fréquence d'exécution de ces opérations. Un exemple de script est également fourni à la fin, intitulé "Script 2".

Cette API n'est pas non plus limitée aux changements d'effectifs. Les scénarios dans lesquels des machines virtuelles sont lancées dynamiquement pour des tests sur software ou dans d'autres cas où un environnement de type "bac à sable" est nécessaire peuvent exploiter le SDK PowerShell au démarrage pour provisionner tous les certificats nécessaires aux applications. Les serveurs web dont les certificats expirent peuvent, sans aucune intervention du personnel, générer automatiquement une paire de clés publique/privée et l'utiliser pour demander un nouveau certificat avec le même contenu afin d'assurer la continuité du fonctionnement du serveur. Une migration des certificats d'algorithmes cryptographiques vieillissants (ou pire, d'une autorité de certification compromise) vers des algorithmes plus récents et plus sûrs (par exemple de SHA-1 à SHA-2) peut être facilement orchestrée à grande échelle.

Si le SDK PowerShell peut aider à résoudre de nombreux problèmes rencontrés dans l'administration des systèmes et les scénarios DevOps, il y a bien sûr des scénarios où le script PowerShell n'est pas le meilleur outil. Pour les développeurs de software qui cherchent à ajouter ou à améliorer l'utilisation des certificats dans leur application, ou pour les administrateurs qui travaillent dans un environnement où PowerShell n'est pas pris en charge, l'API Web du CMS peut être d'une grande utilité. Par exemple, une application web peut accéder à toutes les fonctionnalités fournies par le SDK PowerShell en effectuant des requêtes AJAX à partir de JavaScript. De même, les développeurs de software qui écrivent des applications en Java ou dans d'autres langages courants peuvent exploiter les mêmes API. Une application fonctionnant sous Linux peut accéder aux API par l'intermédiaire d'un script Python ou de tout autre système capable de générer des requêtes HTTP, de sorte que les serveurs Linux dont les certificats arrivent à expiration ou qui participent à une migration de SHA-1 vers SHA-2 peuvent encore obtenir de nouveaux certificats grâce à la génération de clés sur l'appareil. De même, les scripts PowerShell utilisant le SDK dans les scénarios précédents pourraient être mis en œuvre dans n'importe quel autre langage en utilisant l'API Web au lieu du SDK.

Les métadonnées des certificats constituent une autre caractéristique du CMS pour laquelle l'API Web et le SDK PowerShell étendent considérablement les autres capacités. Bien qu'un grand nombre d'informations puissent être introduites dans un certificat, il n'existe aucun moyen de modifier ces données une fois que le certificat est émis et signé cryptographiquement. Les certificats étiquetés avec des métadonnées peuvent répondre à des scénarios dans lesquels les données associées peuvent changer au cours de la durée de vie d'un certificat. Il peut s'agir d'informations décrivant la personne ou le groupe propriétaire du certificat, les applications qui en dépendent, la date à laquelle le certificat doit être renouvelé, les plans de migration futurs ou tout autre contenu susceptible d'être modifié ou inconnu au moment de l'émission. Ce système d'étiquetage des métadonnées peut également être utilisé pour activer et désactiver dynamiquement l'accès à d'autres applications en fonction du lieu, de l'heure ou d'autres critères. Un exemple de script python est fourni à la fin en tant que "Script 3", qui vérifie de manière programmatique si un certificat (fourni en encodage PEM base64) est activé.

En fait, avec nos outils comme le CMS VerdeTTo Access Valve, vous pouvez ajouter ces mécanismes d'authentification améliorés au niveau de la plateforme du serveur sans modifier le code de votre backend. Ainsi, dans le deuxième scénario ci-dessus, les certificats des employés qui partent pourraient être temporairement désactivés au lieu d'être carrément révoqués par la mise à jour d'une valeur de métadonnées. Cela signifie que, si la désactivation d'un certificat s'avère avoir un impact sur d'autres utilisateurs ou systèmes, ce certificat pourrait être temporairement réactivé au cas par cas jusqu'à ce qu'un certificat de remplacement puisse être émis. De plus, grâce à la méthode "Renew" de l'API Web ou à la cmdlet PowerShell correspondante, ces certificats peuvent être rapidement renouvelés et automatiquement installés à tous les endroits où ils sont encore nécessaires. Dans tous ces cas et dans bien d'autres, l'API Web CMS constitue le moyen le plus simple de mettre en œuvre des processus reproductibles et fiables tout en gagnant du temps et en minimisant les risques.

Script 1 : PowerShell pour l'enrôlement et l'installation automatiques de certificats sur les machines des utilisateurs cibles.

Param ([pscredential]$cred, [string]$UsersFile, [string]$APISecret) 

# CMS client general configuration
$APIApp = New-CMSEnrollmentContext -Key "607616a3fc0b7c749d27" - Secret $APISecret

# List the accounts of users who need certificates
$Users = Get-Content -Path ]$UsersFile 

# Get the list of machines in the environment
$Computers = Get-ADComputer -Filter {(enabled -eq "true")} 
$Computers = $Computers | Select-Object -ExpandProperty DnsHostName 

# Find the computers used by the employees who need certificates
ForEach($Computer in $Computers){
  $Profiles = Get-WmiObject -Class Win32_UserProfile -Computer $Computer
  ForEach($Profile in $Profiles){
    $profileSID = New-Object System.Security.Principal.SecurityIdentifier($Profile.sid)
    $username = $profileSID.Translate([System.Security.Principal.NTAccount]).value
    if($Users.Contains($username)){  # This is a machine that needs a new cert
        # Define a certificate store
        $store = Add-CMSCertificateStore -ClientMachine $Computer -CertificateStoreType 
            "IIS Personal" -StorePath "IIS Personal" -Password (ConvertTo-SecureString 
            "password" -AsPlainText -force) -AgentName Dev1.dev.cms -CMSUri 
            https://localhost/CMSAPI -Credential $cred
        # Request a certificate as a PFX
        $pfx = New-CMSPfxEnrollment -ApiEnrollmentContext $APIApp -TemplateName 
            "UserServer" -PfxPassword $password -SubjectName "CN=$username" -CMSUri 
            https://localhost/CMSAPI -Credential $cred
        # Schedule the new PFX to be added to the new store.
        Add-CMSCertificateStoreCert -CertificateStore $store -PFX $pfx.Pkcs12Blob 
            -PfxPassword $password -HasEntryPassword $FALSE -Overwrite $TRUE 
            -Alias "sourceControlCert" -CMSUri https://localhost/CMSAPI -Credential $cred
    }
  }
} 

Script 2 : PowerShell pour la révocation automatique des certificats pour les utilisateurs cibles et leurs machines.

Param ([pscredential]$cred, [string]$UsersFile, [string]$MachinesFile) 

# List the accounts of users with certificates to be revoked
$Users = Get-Content -Path $UsersFile

# Find certificates issued to any of these users and revoke them
ForEach($User in $Users){
    $certs = Search-CMSCertificate -Query ("CN -contains ""$User""") -CMSUri 
        https://localhost/CMSAPI -Credential $cred
    ForEach($cert in $certs){
        Revoke-CMSCertificate -Info $cert -Comment "Cessation of operation" -Reason 5 
            -CMSUri https://localhost/CMSAPI -Credential $cred
    }
}

# Get the list of machines (by hostname) used by these employees
$Machines = Get-Content -Path $MachinesFile 

# Find certificates present on any of these machines and revoke them
ForEach($Machine in $Machines){
    $stores = Show-CMSCertificateStores -CMSUri https://localhost/CMSAPI -Credential $cred 
        | Where-Object {$_.ClientMachine -eq $Machine}
    ForEach($store in $stores){
        $inventory = Get-CMSCertificateStoreInventory -CertificateStore $store -CMSUri 
            https://localhost/CMSAPI -Credential $cred
        $certIds = $inventory | Select-Object -ExpandProperty Certificates 
            | Select-Object -ExpandProperty CertificateId
        Foreach ($certId in $certIds){
            Revoke-CMSCertificate -CMSID $certId -Comment "Cessation of operation" 
                -Reason 5 -CMSUri https://localhost/CMSAPI -Credential $cred
        }
    

Script 3 : Python utilisant l'API Web du CMS pour déterminer, sur la base d'une valeur de métadonnées, si un certificat est activé.

<td”>

import base64       # For encoding credentials
import json         # For decoding http response
import urllib2      # For http request
from cryptography import x509
from cryptography.hazmat.backends import default_backend
from cryptography.hazmat.primitives import hashes

# Sends an HTTP request and returns the response
def getResponse(endpoint, data, credentials):
  request = urllib2.Request(endpoint)
  request.add_header("Authorization","Basic " + base64.b64encode(credentials))
  request.add_header("Content-Type", "application/json")
  request.add_data(data)
  return urllib2.urlopen(request).read()

# Returns whether or not the certificate is enabled via CMS Web API.
# Uses the certificate thumbprint to identify the cert to the metadata API.
def checkAccessEnabled(PEM_cert, credentials):
  certificate = x509.load_pem_x509_certificate(PEM_cert, default_backend())
  thumbprint = certificate.fingerprint(hashes.SHA1()).encode("hex")
  endpoint = "https://localhost/CMSAPI/Metadata/2/Compare"
  data = '{"Key" : "Thumbprint", "Thumbprint" : "'+thumbprint+'","metadatalist" : {"isEnabled" : "True"}}'
  return json.loads(getResponse(endpoint, data, credentials))