Archives de catégorie : Sécurité

Pourquoi ADCS ne délivre des certificats que de deux ans maximum?

Lorsqu’on une installe une PKI même pour un usage purement technique, on a la tentation de réaliser l’installation via l’interface graphique, en se passant de fichiers CAPolicy.Inf et Policy.Inf. C’est ce que j’ai encore fait cette semaine et c’était une erreur. Dans mon cas, le besoin semblait simple, pourtant, je suis tombé sur un os : Pourquoi ma PKI refuse de me délivrer des certificats d’une durée de vie de plus de deux ans ? Il m’a fallu quelques minutes pour réaliser mon erreur. En l’absence de précision, une installation « Quick/Next/Finish » utilise les valeurs par défaut. Donc sans expression de besoin, il nous faut aller explorer la base de registre :

Get-ChildItem HKLM:\SYSTEM\CurrentControlSet\Services\CertSvc\Configuration

clip_image001

En creusant, la configuration, j’ai retrouvé les deux paramètres en relation avec mon problème :

  • ValidityPeriod
  • ValidityPeriodUnits

Le besoin exprimé étant de pouvoir délivrer des certificats d’une durée de vie de trois ans, une petite reconfiguration s’impose. Réalisé à l’ancienne, cela donne cela :

CertUtil.Exe -SetReg CA\ValidityPeriodUnits 3

CertUtil.Exe -GetReg CA\ValidityPeriodUnits

clip_image002

Après un redémarrage du service de l’autorité de certification, mon problème était corrigé. Conclusion, même pour une PKI à usage technique, il faut toujours préparer la mise en œuvre d’une autorité de certification.

BenoîtS – Simple and secure by design but Business compliant (with disruptive flag enabled)

C’est l’heure de la chasse au SHA1

La prochaine mise à jour de Windows 10 arrive à grand pas. C’est prévu à partir du 2 Aout 2016, tout le monde est au courant. C’est un process d’upgrade bien maîtrisé (on est tous passé par le programme Windows Insiders, …). Le problème, c’est qu’avec cette nouvelle Build, Microsoft a changé les règles pour les certificats. En même temps, ça devenait urgent. D’autres éditeurs comme Google ont déjà franchi le pas. SHA1 n’est plus considéré comme un algorithme de signature fiable. Le problème, c’est que cela ne concerne pas que Windows 10. Microsoft a mis le temps pour communiquer sur le sujet mais maintenant, c’est clair : An update to our SHA-1 deprecation roadmap. Le paragraphe ci-dessous est on ne peut plus clair :

This update will be delivered to Microsoft Edge on Windows 10 and Internet Explorer 11 on Windows 7, Windows 8.1 and Windows 10, and will only impact certificates that chain to a CA in the Microsoft Trusted Root Certificate program. Both Microsoft Edge and Internet Explorer 11 will provide additional details in the F12 Developer Tools console to assist site administrators and developers.

 

Une lecture de l’article Windows Enforcement of Authenticode Code Signing and Timestamping à la section Enforcement in general sera tout aussi claire :

clip_image001

 

Le véritable problème, ce seront Edge et Internet Explorer (pour toutes les versions de Windows supportées ) qui n’accepteront plus de reconnaître de certificats utilisant SHA1 comme sécurisés. Conclusion, je recommande vivement de partir à la chasse au SHA1. Le problème, c’est de les localiser le plus efficacement possible.

Pour vérifier si on a ce type de certificats, on va passer par PowerShell, c’est très simple. On commence par créer un objet contenant la liste des certificats contenus dans le magasin personnel de notre poste de travail de la manière suivante :

$Certs = Get-ChildItem cert:\LocalMachine\My

clip_image002

 

OK, on a quatre certificats dans le magasin personnel. Le problème, c’est que brut de fonderie, cela ne nous parle pas beaucoup.

clip_image003

 

Pour que cela nous parle, on a besoin de plus d’informations. Commençons par voir de quoi est composé un objet certificat dans PowerShell :

clip_image004

 

La liste contient des méthodes mais aussi des propriétés et il y en a deux qui nous intéressent.

clip_image005

 

La propriété « Subject » est ce qu’il y a de plus parlant pour désigner un certificat. Par contre brut de fonderie, le « SignatureAlgorithm » ne nous parlera pas beaucoup, à moins de savoir lire entre les lignes. Avec son « FriendlyName », c’est tout de suite plus compréhensible. Maintenant, on sait qu’on a un mauvais SHA à chasser.

clip_image006

 

Ne reste plus qu’à voir à quel certificat cela correspond.

clip_image007

 

C’est un auto-signé. Maintenant, avec un peu plus de détails on retrouvera peut être l’application concernée :

clip_image008

 

Le plus moche dans mon cas, c’est que ce certificat a été généré sur mon poste pour installer Visual Studio 2015. Donc même avec les dernières versions des outils Microsoft, on n’est pas à l’abris de ce type de surprise.

Si on est capable de réaliser l’opération localement, on doit pouvoir faire de même en PowerShell Remoting si on a pensé à activer et sécuriser correctement le protocole.

OK, donc avant de procéder à la mise à niveau vers Windows 10 update anniversary 2016, faudra commencer par traiter les applications qui utilisent toujours des certificats SHA1. Pour une approche plus industrielle de la recherche, je vous recommande ce script publié sur le Script Center : SHA1 Certificate Signature Check (Updated)

Si le certificat incriminé a été délivré par votre autorité de certification interne, c’est qu’il faudra envisager une migration vers SHA2. Je conseille alors la lecture d’un ancien billet : ADCS, quick and dirty et conséquences.

­

BenoîtS – Simple and secure by design but Business compliant (with disruptive flag enabled)

Découverte d’Azure Disk Encryption (Preview)

Le billet « Cacher les mots de passe en Powershell » ayant eu beaucoup de succès, j’ai décidé de passer un peu plus de temps sur Azure Key Vault. En creusant un peu, on comprend qu’elle permet de stocker un grand nombre de secrets, y compris les clés de chiffrement de Bitlocker, ce qui nous amène au service Azure Disk Encryption, encore en Preview au moment où je rédige cet article. Linux n’étant pas encore ma tasse de thé, ce sera donc à Windows que je vais consacrer mon billet.

Le couplage d’Azure Disk Encryption avec Azure Key Vault est une évidence : Remplacer le TPM que nous avions On- Premises pour y stocker notre secret. Azure Key Vault étant un service Cloud, il est capable de stocker bien plus qu’un secret avec un niveau de sécurité bien plus élevé. Pour information, les instances « Premium » du service Azure Key Vault sont hébergées sur des boitiers HSM Thales certifiés FIPS 140-2 Level 2. Pourquoi s’en priver?  La mise en place s’effectuera selon les étapes suivantes :

  • Mise en place des prérequis
  • Activation pour le disque OS de notre VM IaaS
  • Constats dans la machine virtuelle

 

Mise en place des prérequis

Azure Disk Enryption nécessite la version 1.1.0 du module Powershell Azure Active Directory. Une rapide commande « Get-Module Azure -ListAvailable » nous inique que j’ai bien la version minimale.

clip_image001

 

Ceci vérifié, on peut s’attaquer au grand classique de l’authentification avec Login-AzureRmAccount.

clip_image002

 

Et sélectionner la souscription que nous allons utiliser avec les commandes Get-AzureRMSubscription et Select-AzureRMSubscription.

clip_image003

 

Pour travailler, nous allons avoir besoin d’une machine virtuelle qui a été provisionnée dans le groupe de ressources AzureDiskEncrypt, ce que j’ai bien avec les commandes suivantes :

Get-AzureRMresourceGroup -Name AzureDiskEncrypt

Get-AzureRMVM -Resourcegroupname ‘AzureDiskEncrypt’ | Select ResourcegroupName, Name, Location, ProvisioningState

clip_image004

 

Dans mon dernier billet, j’avais mis en œuvre un Key Vault dans son édition standard. Cette fois, j’utilise l’édition Premium, juste pour bénéficier du stockage sur un HSM certifié FIPS 140-2 Level 2. Comme indiqué plus tôt, à ce tarif, ce serait criminel de ne pas l’utiliser. La commande suivante va nous permettre de créer mon coffre-fort numérique dans le même groupe de ressources pour raisons de simplicité. Donc allons y :

New-AzureRMKeyVault -VaultName ‘MyKeyVaultHSM’ -ResourceGroupName ‘AzureDiskEnrypt’ -Location ‘North Europe’ -SKU ‘Premium’.

clip_image005

 

Remarque: Une limite à connaitre, le Key vault que nous allons utiliser pour la fonctionnalité Azure Disk Encryption doit nécessairement dépendre de la même région Azure que les machines virtuelles sur lesquelles nous allons activer la prise en charge. Dans un sens c’est logique, ou alors on devrait accepter que les secrets sortent d’une région et donc d’un Datacenter.

Notre coffre à secrets est en place et accessible via une URL. Pour l’instant, je suis le seul à avoir tous les privilèges, ce qui est normal en tant que créateur. A ce stade, on peut constater que notre coffre-fort numérique n’est pas éligible aux fonctionnalités qui nous intéresse. Nous allons y remédier avec les commandes Powershell suivantes :

Set-AzureRmKeyVaultAccessPolicy -VaultName ‘MyKeyVaultHSM’ -ResourceGroupName ‘AzureDiskEncrypt’ -EnabledForDiskEncryption -EnabledForDeployment

Get-AzureRMKeyVault -VaultName ‘MyKeyVaultHSM’ -ResourceGroupName ‘AzureDiskEncrypt’

clip_image006

 

Je vois tout de suite qu’il y en a qui se demandent pourquoi l’option ‘-EnabledForTemplateDeployment’ n’a pas été utilisée. La réponse est venue de la documentation de la commande New-AzureRmKeyVault : « Note: This parameter is not currently implemented. ». On est bien en Preview.

 

On arrive bientôt à la fin des prérequis, plus que deux. Pour que nos machines virtuelles puissent utiliser notre coffre-fort numérique, il nous faut deux choses :

  • Une identité que nos machines virtuelles pourront utiliser pour accéder à notre coffre-fort numérique (plus précisément l’extension de machine virtuelle)
  • Une ressource à laquelle nous allons accorder des accès.

Il m’a fallu un peu de temps pour comprendre le modèle mais c’est logique. Pour piloter la mise en place de la fonctionnalité Azure Disk Encryption, nous allons injecter un agent dans la machine virtuelle. Du point de vue de Windows Azure Active Directory, notre machine virtuelle n’a pas d’identité, il faut donc l’aider en lui fournissant une identité, laquelle sera utilisée pour accéder au coffre-fort numérique.

Au moment où je rédige ce billet, Windows Azure Active Directory est encore disponible uniquement depuis l’ancien portail. C’est donc depuis celui-ci que nous allons déclarer une nouvelle application dans notre tenant Windows Azure Active Directory.

clip_image007

 

L’application référencée pointera directement sur l’URL de la ressource de notre coffre-fort numérique.

clip_image008

 

C’est là qu’intervient une subtilité. Pour configurer notre agent, il va avoir besoin de deux informations :

  • Un Client ID
  • Une clé.

clip_image009

 

C’est un peu comme un login & Mot de passe. Nous allons garder ces informations dans un coin. On va commencer par autoriser l’accès au coffre-fort numérique pour cette identité avec la commande Powershell suivante : Set-AzureRmKeyVaultAccessPolicy -VaultName ‘MyKeyVaultHSM’ -ServicePrincipalName ‘<ClientID>’ -PermissionsToKeys All -PermissionsToSecrets All

clip_image010

 

Pour vérifier que cela fonctionne, il suffit s’afficher les caractéristiques de notre coffre-fort numérique avec la commande Get-AzureRMKeyVault -VaultName ‘MyKeyVaultHSM’. On constate que le ClientID que nous avons fourni a été reconnu. Pour simplifier, j’ai volontairement simplifié la mise en œuvre. Dans un véritable déploiement, on limiterait l’accès à certains types de secrets, voire jusqu’à segmenter en plusieurs coffre-fort numériques en fonction des usages. Si ça vous intéresse, l’aide en ligne de la commande PowerShell Set-AzureRmKeyVaultAccessPolicy est un bon point de départ.

Activation pour le disque OS de notre VM IaaS

C’est maintenant que cela commence à devenir intéressant. Pour commencer on va personnaliser le portail pour faire apparaitre une nouvelle colonne. Pour l’instant, le service Azure Disk Encryption est bien désactivé.

clip_image011

 

On peut avoir le même résultat avec la commande Powershell suivante  : Get-AzureRMVMDiskEncryptionStatus -ResourceGroupName ‘AzureDiskEncrypt’ -VMName AzureVM01

clip_image012

 

L’information est ici plus précise puisqu’on sépare le statut du disque OS des éventuels disques de données. Dernière étape, l’activation de l’agent de chiffrement dans notre machine virtuelle. Pour commencer, on va mettre de côté quelques informations sur notre coffre-fort numérique avec la commande Powershell suivante : $Vault = Get-AzureRMKeyVault -Resourcegroupname ‘AzureDiskEncrypt’ -VaultName ‘MyKeyVaultHSM’

clip_image013

 

On a tout ce qu’il nous faut, on passe au tour de magie. L’installation de l’agent va nécessiter le redémarrage de notre machine virtuelle ainsi qu’un peu de temps pour activer Bitlocker. Voilà la formule magique :

Set-AzureRMVMDiskEncryptionExtension -ResourceGroupName ‘AzureDiskEncrypt’ -VMName ‘AZUREVM01’ -AadClientID ‘<Identifiant Client ID de l’application dans le portail>’ -AadClientencryptionKeyVaultURL $vault.VaultUri -DiskEncryptionKeyVaultID $Vault.ResourceId

clip_image014

 

Après quelques minutes et un redémarrage de la machine virtuelle, la commande Powershell rend la main en nous indiquant un succès. Un rapide Get-AzureRMVMDiskEncryptionStatus -ResourceGroupName ‘AzureDiskEncrypt’ -VMName AzureVM0’1 nous confirme que le chiffrement est bien activé, au moins pour le disque OS pour lequel on a maintenant un secret dans le coffre-fort numérique.

Logiquement, si on a activé la fonctionnalité Bitlocker, on devrait avoir des secrets dans notre coffre-fort numérique. Je dis bien des secrets car au minimum, une machine virtuelle est composée de deux disques dur :

  • Le disque OS
  • Le disque temporaire

C’est pour cela que la commande Get-AzureKeyvaultSecret -VaultName ‘MyKeyVaultHSM’ nous indique deux secrets.

clip_image015

 

Constats dans la machine virtuelle

On a passé assez de temps dans les nuages, allons constater que notre système d’exploitation a bien activé Bitlocker. Juste après l’authentification, un joli message nous indique que cela se présente bien :

clip_image016

 

Dans le détail, effectivement, ça se présente même très bien dans le panneau de configuration.

clip_image017

 

Pour finir, comme j’aime de moins en moins des interface graphiques, je repasse en Powershell avec la commande Get-BitlockerVolume :

clip_image018

 

Là, les résultats sont sans appel. On a bien deux volumes pour lesquels Bitlocker est activé (dont un en cours d’activation). Y a juste une subtilité qui m’échappe. Le KeyProtector indique ‘ExternalKey’. Elle est ou cette clé. Pour rappel, n’a pas de TPM. La réponse m’est apparue quelques minutes plus tard en regardant l’explorateur Windows.

clip_image019

 

Ce nom ne m’est pas inconnu, allons revoir les secrets dans notre coffre-fort numérique

Get-AzureKeyVaultSecret -Vaultname ‘MyKeyvaultHSM’ | Select Name

Get-AzureKeyVaultSecret -Vaultname ‘MyKeyvaultHSM’ -name ‘EBCAF0E6-3AAB-4234-9B64-AB84DCC1A0DA’

clip_image020

 

C’est la clé Bitlocker. La VM Extension utilise donc un disque additionnel pour y placer le secret qu’elle a extrait de mon coffre-fort numérique.

 

Conclusion

La fonctionnalité est encore en Preview mais vu que seul l’accès aux secrets est facturé 0,8433€ par secret par mois, ce sera une fonctionnalité obligatoire lorsqu’elle passera en General Availability. 1€ pour stocker des clés de chiffrement dans des boitiers HSM Thales certifiés FIPS 140-2 Level 2, ce serait criminel de s’en passer. Pour rappel dans le Cloud, la responsabilité de vos ressources et contenu de votre tenant est sous votre responsabilité. Microsoft fournit les moyens de sécuriser nos ressources, nous seuls sommes responsables en cas d’incident de sécurité.

BenoîtS – Simple and secure by design but Business compliant (with disruptive flag enabled)

Gabarit de certificat pour utiliser CMSMessage de Powershell 5.0

Honte à moi. Un certificat auto-signé dans mon dernier billet. J’avoue, je l’ai écrit sur mon canapé, et uniquement survolé la page Technet avant de me rendre compte de mon impardonnable erreur. Vu que le Technet ne donne pas les spécifications du gabarit de certificat à utiliser pour ADCS, je m’y colle en pénitence.

Comme base de travail, j’ai retenu le gabarit user. Pourquoi? Car je compte limiter ce type de certificats aux seuls comptes de services membres d’un groupe spécifique. Pas besoin que tous mes systèmes disposent de ce type de certificat. En plus avec ce choix, je vais limiter l’accès à ce certificat aux seuls comptes de service et non la totalité des comptes qui peuvent accéder au magasin personnel de l’ordinateur avec des privilèges administrateur ou supérieur.

Après, vu que pour utiliser la fonctionnalité CMSMessage, il faut PowerShell 5.0, j’ai choisi de limiter les systèmes éligibles en conséquences. Pour installer de Windows Management Framework 5.0, il faut au minimum un système d’exploitation de génération Windows 7 / Windows 2008 R2.

clip_image001

Dans l’onglet général, on nomme notre nouveau gabarit de certificat « CMS Message », pas grand-chose à dire sinon que ça ne sert à rien de publier le certificat dans l’Active Directory dans notre cas.

clip_image002

Dans l’onglet « Request Handeling », une seule chose compte, la capacité à exporter la clé privée. C’est grâce à elle qu’on sera en mesure de déchiffrer notre CMSMessage.

clip_image003

Pour la construction du Subject Name, il y a eu un peu de travail. Par défaut, le gabarit de certificat était prévu pour construire l’attribut en utilisant les informations issues de l’annuaire Active Directory. Bien, mais le problème, il est rare qu’un compte de service ou même un ordinateur se voit affecté une adresse de messagerie. Pour cela, j’ai dû procéder à quelques adaptations :

  • Ne pas inclure l’adresse de messagerie dans l’attribut Alternate Subject Name
  • Ne pas inclure l’attribut E-Mail
  • Ne pas inclure le DNS Name (pas de sens pour un utilisateur)
  • Mais bien inclure un UPN

clip_image004

C’est maintenant qu’il faut introduire la subtilité. Pour que la commande Protect-CMSMessage accepte d’utiliser notre certificat, il doit avoir un rôle bien particulier. Pas de bol, il est pas dans le gabarit de certificat que nous avons utilisé comme base de travail. Qu’à cela ne tienne, on va le personnaliser.

clip_image005

Pour être sûr que notre certificat ne soit pas détourné pour un autre usage, on va faire le ménage dans les EKU et ne positionner que « Document Encryption ».

clip_image006

Maintenant, c’est mieux.

clip_image007

On approche de la fin. Ne pas limiter la capacité d’enregistrement de certificat, c’est la porte ouverte à toutes les fenêtres, des certificats délivrés à gogo sans se soucier qu’un jour il faudra les renouveler, ce qui bien sûr arrive toujours au pire moment. En limitant la capacité d’enrôlement aux seuls membres d’un groupe, on saura déjà à qui on a délivré ces certificats.

clip_image008

Y a plus qu’à publier notre gabarit de certificat et Zou, à la signature.

clip_image009

Une fois la session ouverte avec notre compte de service, on peut réaliser la demande.

clip_image010

C’est fini. Pour s’assurer que cela fonctionne, une rapide commande Powershell « Get-ChildItem Cert:\CurrentUser\My -DocumentEncryptionCert » nous confirme que nous avons bien un certificat prévu pour cet usage dans le magasin. Vu que c’est le cas, y a plus qu’à chiffrer notre message :

$Cert = Get-ChildItem Cert:\CurrentUser\My -DocumentEncryptionCert

$CMSMessage = Protect-CMSMessage -Content « Ilachangé! » -To $Cert/Thumbprint

clip_image011

 

Aller, je retourne me punir, j’ai du python sur le feu. Je ne déconne pas

BenoîtS – Simple and secure by design but Business compliant (with disruptive flag enabled)

Patching out of band, cas concrêt

C’est quand on traite des sujets qui n’arrivent jamais que ça tombe. J’avais publié voilà quelques jours une série de billets sur le Patch Management d’une infrastructure de type cloud privé. Certaines personnes m’ont demandé pourquoi devait-on prévoir un processus pour les patchs out of band, … La réponse est tombée ces jours-ci : Microsoft Security Advisory 3108638.

L’alerte est d’importance car ça touche l’Hyperviseur. En lisant plus précisément le bulletin de sécurité, on découvre que la « faille » ne se trouve pas dans Hyper-V mais dans le processeur lui-même. Conséquence, c’est toutes les versions d’Hyper-V qui sont affectées :

  • Windows 2008
  • Windows 2008 R2
  • Windows 2012
  • Windows 2012 R2
  • Windows 8.1
  • Windows 10

C’est disponible dans Windows Update, donc pour action immédiate. Vu que c’est une problématique indépendante du logiciel, tous les Hyperviseurs sont donc affectés. Une recherche rapide sur Google Bing vous donnera les liens pour les autres hyperviseurs du marché :

Remarque : Il ne faut pas voir de mauvais esprit anti-VMWARE de ma part mais Google / bing n’a pas été mon ami pour trouver l’information chez eux sans accès à la Knowledge Base.

Alors convaincu qu’il est important d’avoir un process de patch management out of band dans votre infrastructure Cloud privé? Maintenant, vous avez deux choix :

  • Choix n°1 : Tester le déploiement en urgence à l’arrache sans concertation avec vos locataires avec un résultat attendu.

clip_image001

clip_image002

Alors, prêt à patcher?

­

BenoîtS – Simple and secure by design but Business compliant (with disruptive flag enabled)

Patch Management – Réflexions – Bonus : Les urgences

Jusqu’à maintenant, on a parlé de patching organisé. Cependant, on aura certainement un jour à traiter une urgence, avec un RSI qui nous impose le patching de notre infrastructure dans des délais beaucoup plus court que les cycles de maintenance que nous pouvons proposer. Que ce soit dans le contexte d’un cloud privé ou hybride, il faudra impliquer nos locataires. Il y a de grandes chances que le problématique rencontrée par l’hébergeur impacte aussi le locataire (cas Heartbleed). Il devra aussi prendre ses responsabilités. Si son application a bien été pensée pour la scalabilité et la résilience, alors cela devrait bien se passer. Netflix en a fait l’expérience, c’est un enseignement à méditer : Lessons Netflix Learned from the AWS Outage.

Le problème, c’est comment y faire face quand ça nous tombe dessus. Réagir implique d’organiser un cycle de maintenance dans l’urgence, donc communiquer auprès de nos locataires pour les informer des impacts sur leurs workloads. Le risque avec les cycles de maintenance exceptionnels, c’est que c’est une organisation lourde, organisée dans l’urgence, donc un fort risque d’avoir des problèmes. A côté de cela, on a déjà des cycles de maintenance en place. Donc, de mon point de vue les stratégies sont les suivantes :

  • Tenir jusqu’au prochain cycle de maintenance. Ce qui implique que les cycles de maintenances sont rapprochés et qu’on peut tenir jusqu’au prochain, genre chaque week-end. Ça peut permettre de patcher une partie de l’infrastructure en cumulant patching Microsoft et urgence au sein de la même plage de maintenance. Avec nos runbooks qui se ressemblent beaucoup, c’est juste une histoire d’intégration.
  • Improviser. Généralement, ça ressemble à du freestyle sans filet, on connait tous les résultats.
  • Appeler la terre entière pour demander à redémarrer la plateforme, ce qui va détruire nos SLA à 0 et ruiner la confiance de nos locataires

Ma préférence va à la première stratégie. Plus votre infrastructure est importante plus il devient difficile d’organiser des actions dans l’urgence. Les dépendances deviennent de plus en plus nombreuses. En ayant des cycles de maintenance courts, il est plus simple d’inscrire des actions urgentes dans ces cycles de maintenance plutôt que d’introduire des cycles de maintenance exceptionnels qu’il est complexe d’organiser sous contrainte de temps. C’est une solution envisageable uniquement si on est capable de mettre en place des mesures de mitigation pour parer aux risques encourus jusqu’à ce que l’infrastructure soit totalement patchée.

Etre en situation d’urgence sans préparation, c’est le mur assuré. Le problème, c’est qu’il faut bien apprendre. Pour cette raison, l’organisation de cycles de maintenance dans l’urgence ne doit pas être rejetée. Cela peut effectivement générer des problèmes mais on a beaucoup à apprendre de ces incidents si on en sort avec :

  • Un REX, ce qu’on en a appris, ce qu’il faut corriger
  • Un plan d’action pour prendre en compte les corrections
  • Des processus éprouvés et partagés

Après, il faut valider que nos corrections techniques / processus vont dans le bon sens. Pour cela rien de vaut de se remettre en situation de risque. Je ne dis pas qu’il faut planter tout son Cloud privé mais créer une situation de risque contrôlée

clip_image002

C’est là qu’un environnement de Prototypage un tant soit peu représentatif prend tout son intérêt!. Pour nous, c’est encore un sujet en cours de réflexion pour lequel on espère poser les bases prochainement.

L’idée générale serait d’organiser des campagnes de « Stress test » pour tester aussi bien l’infrastructure, que les processus et les équipes. Ce type de campagne devrait être organisé au moins deux fois par an. Plus, c’est qu’on a eu beaucoup trop d’urgences dans l’année écoulée. C’est possible mais mettre en place un environnement contrôlé prend du temps. Moins, c’est prendre le risque d’oublier ce qu’on veut qualifier. Quelques conseils pour organiser ces Stress tests :

  • Disposer d’un environnement de prototypage représentatif est l’idéal mais ce n’est pas toujours possible. Il faudra certainement isoler une partie de l’environnement de production
  • Procéder par itérations. On ne peut pas tout tester en un seul cycle annuel
  • Se fixer des objectifs réalistes

Pour conclure, la conception et la mise en place du Patch Management d’un cloud privé prend du temps, beaucoup de temps. Dans notre approche, nous avons tenu à observer quelques règles :

  1. Si le design ressemble à l’étoile de la mort, c’est pas bon
  2. Plus on complexifie les processus, plus on va jongler avec des briques
  3. Une brique qui tombe ça fait mal
  4. Toujours garder en mémoire les trois premiers points

Voilà pour le Patch Management d’une infrastructure cloud privé basée sur les produits System Center. Pour les locataires, c’est une autre histoire qui peut se résumer ainsi : Pets or Cattle. Nos locataires doivent t-ils être au petits soin pour leurs machines virtuelles ou les traiter comme du bétail? Ce sera un autre sujet de discussion.

BenoîtS – Simple and secure by design but Business compliant (with disruptive flag enabled)

Patch Management – Réflexions – n°5 : Les cycles de maintenance

C’est bien d’automatiser au maximum, encore faut-il planifier ces opérations. Doit-on planifier toutes ces opérations selon le même cycle de maintenance « long » (option big-bang au risque de se transformer en big-badaboum) ou des cycles « courts » (option « blind-test » pour la découverte des bugs / comportements non prévu)? La réponse est bien plus compliquée. Déjà, tous les types de Patching ne s’inscrivent pas dans le même cycle de maintenance. Raisonnons donc en fonction des différents domaines :

  • Mise à niveau Pilotes / Logiciels bas niveau des Hyper-V : Pour maintenir la stabilité de la plateforme et le support des éditeurs, on est obligé de suivre un rythme soutenu. Certes, on n’est pas obligé de suivre au jour le jour et de s’imposer des cycles courts mais on doit quand même suivre. On aura besoin d’un à deux cycles de maintenance par an. A mon sens, difficile de faire plus car il faudra du temps pour valider que les changements opérés produisent bien les effets escomptés et qu’on n’observe pas de régression pouvant affecter nos SLA et par extension les SLA de nos locataires.
  • Patch Management Microsoft : On est tous d’accord pour suivre le rythme mensuel imposé par Microsoft. C’est sportif mais pas impossible. En fonction de la taille de l’infrastructure, on devra découper en plusieurs phases. Par exemple, patcher un certain nombre de châssis par semaine sur un cycle d’un mois. A mon sens, c’est une approche à privilégier car avec Windows 10 et Windows Server 2016, la notion de « Ring » va changer les choses. Devra t’on passer sur le modèle Long-Term Branch? C’est une bonne question, pas encore assez de recul pour juger. Par contre le choix du mode d’installation Nano devrait nous faciliter grandement la tâche pour réduire drastiquement le nombre de correctifs à installer et le nombre de redémarrages nécessaires.
  • Patch Management « Out of band » : Là, c’est la criticité qui impose le cycle. La première option serait de travailler dans le mode urgence. Pas évident à organiser et le résultat risque d’être approximatif. On peut aussi prévoir de pré-réserver des créneaux pour réaliser ce type d’opération et les utiliser ou non. C’est l’option que je préfère. On évite l’organisation dans l’urgence et on inscrit cela dans un cycle régulier, plus facile à maîtriser. Après, on peut prévoir d’intégrer ce type de patching dans le cycle du Patch Management Microsoft. C’est envisageable si on a bien prévu un cycle de maintenance court. On profite du créneau horaire du premier pour intégrer le second.
  • Patch Management de la Fabric : Avec les solutions Cloud Privé / Hybride de Microsoft, c’est facile, les équipes System Center fournissent des Update Rollup tous les trimestres. Autant on n’a pas de problème ou presque à appliquer les correctifs Microsoft & Out of Band sur notre Fabric, autant les updates UR sont trop spécifiques et nécessitent trop de tests. Pour cette raison, choix a été fait de ne pas suivre le rythme de publication de Microsoft. Il a été décidé de sauter un UR sur deux sauf si l’UR en question nous corrige des problèmes nous impactant ou apportant des fonctionnalités requises par nos locataires. En plus chaque UR apporte son lot de nouvelles fonctionnalités à mettre en place / qualifier, …

clip_image001[4]

BenoîtS – Simple and secure by design but Business compliant (with disruptive flag enabled)

Patch Management – Réflexions – n°4 : Patch Management de la Fabric

Mon préféré. Le premier qui déploie des UR de System Center en automatique, il prend aussi le chemin du mur mais avec un Jetpack dans le dos. Pour bien comprendre le problème, faut découvrir ce qui se cache dans les Updates Rollup de la gamme System Center. Tous les trimestres, Microsoft livre une nouvelle fournée. A ce jour, le dernier disponible est l’UR8 : KB3096378 : Update Rollup 8 for System Center 2012 R2.

Les KB System Center, c’est aussi digeste que l’encyclopédie. Pour Rappel, la gamme System Center ça couvre :

  • App Controller (Un truc qui a dû servir une fois)
  • Data Protection Manager (on n’y échappe pas au saucissonneur de baies de disque)
  • Operations Manager (SCOM pour les intimes)
  • Orchestrator
  • Service Management Automation
  • Service Manager (SCSM mais SM pour les intimes, …)
  • Service Reporting (Le petit dernier de la génération 2012R2)
  • Virtual Machine Manager
  • Service Provider Foundation
  • Windows Azure Pack
  • Windows Azure Pack WebSites

C’est bon ou on en rajoute ? Subtilité supplémentaire, d’un point de vue support Microsoft indique que tous ces composants doivent nécessairement être au même niveau pour être supportés. Donc pas la peine d’envisager un déploiement progressif. Dans notre contexte, App Controller et Service Reporting n’étant pas déployés, c’est déjà cela de gagné. Maintenant essayons de voir l’étendue des problèmes qu’on va rencontrer :

  • Les agents  : Certains produits tel que DPM, SCOM et SCVMM reposent sur des agents installés qu’il faut aussi mettre à niveau (SIC). Qui dit installation implique redémarrage, c’est par exemple le cas de SCVMM.
  • Les dépendances entre les produits : Qui dit nouvelle version de Management Pack SCOM dit importation de celui-ci dans SCSM ainsi que dans son Data WareHouse.
  • Les actions pré/post installation : Y a quelques produits ici et là qui ont besoin d’actions pré-post installation en PowerShell. Le genre de d’opérations qu’on ne pourra pas automatiser en plus, …
  • L’ordre d’installation : SCSM est un excellent exemple puisque c’est :
  1. Data WareHouse Server
  2. Primary management Server
  3. Secondary Management Servers
  4. All analyst consoles
  5. Self-Service Portal

Je suis presque sûr que tout le monde aurait commencé par le Primary Server SCSM. Perdu, …

Pour toutes ces raisons, on s’est contenté d’un processus de mise à niveau qui est encore manuel / semi-automatique. L’opération étant très chronophage, on n’arrive pas encore à suivre le rythme imposé par Microsoft avec une fournée d’ Update Rollup par trimestre. Conséquence, on s’est limité à appliquer un Update Rollup sur deux, sauf si la stabilité de la plateforme nous impose d’aller plus vite. Ce choix n’est pas sens conséquence. Actuellement, nous sommes en cours de migration UR5 vers UR7, on est donc en retard. A première vue, c’est simple, il suffit de suivre les KB. Sauf que les KB ont été écrites pour upgrader depuis la version précédente, pas celle d’avant. Dans l’UR6, il y a des Management Pack SCOM qui ont été mis à jour, pas dans UR7. Encore faut-il relire la KB de l’UR6 pour le découvrir. Les Updates Rollup sont cumulatifs, pas les KB de déploiement associées. Jusqu’ici c’était simple. Bientôt, notre « machin », devra évoluer / muter et intégrer d’autres composants tel que :

  • Service Provider Foundation
  • Service Management Automation
  • Service Reporting
  • Windows Azure Pack
  • Windows Azure Pack WebSites

A ce moment on pourra dire que notre « machin » va muter en super étoile de la mort. Pour rappel, voilà à quoi ressemble une infrastructure Windows Azure Pack un tant soit peu disponible :

clip_image001

Et encore, je ne suis pas tout à fait d’accord avec le schéma ci-dessus. Pour moi le portail d’administration de Windows Azure Pack est nécessairement en haute disponibilité avec deux instances. Lorsqu’on va introduire Windows Azure Pack (yumi!!), on va devoir révolutionner nos méthodes. Windows Azure Pack repose sur des Web services opérant en « State-less » avec un Load Balancer devant. Notre processus devra intégrer ces Load Balancers dans le processus de Patching pour activer / désactiver les instances de Web Services publiés. Juste pour vous donner une idée, allez relire un billet publié cette année sur DirectAccess : Monitoring DirectAccess with Kemp. C’est exactement la même problématique mais appliqué à six ou sept Web Services accessibles via un Load Balancer mutualisé. Ça promet d’être très fun.

Si jamais on arrive à intégrer tout cela, on pourra s’attaquer au patching d’une infrastructure WebSites de Windows Azure Pack répartie entre plusieurs châssis répartis eux même entre deux datacenters. Si vous avez un trou de mémoire, y j’ai écrit quelques billets sur le sujet : Architecture Windows Azure Pack WebSites–Introduction. Comme une image vaut mille mots, je pense que là vous avez compris l’étendue du problème, encore des Web services et des Load-Balancers :

clip_image003

Ce qui nous sauve avec l’architecture WebSites, c’est qu’elle a été conçue pour supporter la défaillance d’une ou plusieurs instances de chaque rôle (il y a juste une exception). Il faut juste pas tenter de mettre à niveau toutes les instances d’un même rôle en même temps, sinon c’est big badaboum comme disait Leeloo.

Alors, toujours SCCM/Windows Update en mode, je déploie comme un goret ? C’est là qu’on commence à apprécier le moteur d’orchestration des mises à jour de Microsoft Cloud Platform System. Pour l’instant, impossible pour nous de le concurrencer. Respect, c’est un super boulot. En fait, il gère tous les aspects du Patch Management que nous avons abordés jusqu’à maintenant mais en mieux.

BenoîtS – Simple and secure by design but Business compliant (with disruptive flag enabled)

Patch Management – Réflexions – n°3 : Patch Management "Out of band"

De quoi parle-t-on ? Ben des correctifs qui ne sont pas dans Windows Update, pas disponibles nativement dans SCCM. Selon les organisations, organiser le déploiement de correctifs out-of band dans SCCM, c’est un processus qui peut s’avérer long. Le problème, c’est que bien souvent, les correctifs out-of band, quand on en a besoin, c’est pour la veille. Faudra donc développer un processus automatisé pour déployer ces correctifs quand on en a besoin, donc ASAP. Si vos processus internes permettent de publier ces correctifs dans SCCM rapidement, c’est parfait. Dans notre contexte, il nous faut un processus de déploiement « alternatif » en attendant que les correctifs soient disponibles dans SCCM.

Qu’est-ce qu’on entend par correctifs « Out of band» ? C’est par exemple ceux que le support Microsoft vous recommande d’installer uniquement si vous rencontrez le problème. Dans notre contexte, la liste était déjà très fournie :

Là encore, le couple Orchestrator / PowerShell fait des miracles ou presque. Ce processus est nécessaire aussi bien pour les Clusters Hyper-V que pour nos locataires. On a tous les mêmes problèmes. La tentation est grande de développer un processus commun mais ça irait à l’encontre d’une règle sacrée : l’indépendance entre le fournisseur de l’infrastructure et ses locataires. Chacun doit pouvoir déployer ses propres correctifs sur son périmètre. C’est encore un processus en cours de développement. Dans notre approche, on a retenu de proposer deux ensembles de Runbooks :

  • Le premier à destination de l’équipe en charge des clusters Hyper-V
  • Le second plus « générique » à destination de tous les locataires

Comme le déploiement de correctifs « out-of band » a été requis par l’hébergeur, on a donc commencé par lui. Pour faire simple, disons qu’il disposera des Runbooks suivants (actuellement en développement) :

  • Mise à disposition de correctifs au sein de son périmètre (clusters Hyper-V par exemple)
  • Installation des correctifs mis à disposition sans redémarrage
  • Installation des correctifs mis à disposition avec redémarrage
  • Vérification bonne installation des correctifs mis à disposition

C’est assez simple à réaliser, tout ce qu’on avait besoin, c’était un repository central (File Share) pour déposer les correctifs à déployer. Bref, ça ne casse pas trois pattes à un canard. Maintenant, la même chose mais pour les locataires. La ça pose plusieurs problèmes :

  • L’indépendance entre l’infrastructure et le contenu hébergé
  • Les contextes d’exécution qui sont nécessairement distincts
  • L’impossibilité de répondre à tous à tous les besoins de nos locataires
  • Offrir le choix de faire simple

Bref, toutes ces raisons qui font que c’est nécessairement une prise de tête. Voyons comment on compte traiter le sujet en reprenant les points un par un :

  • L’indépendance entre l’infrastructure et le contenu hébergé : La pas le choix, il faut trancher. On ne réutilisera pas les même Runbooks. Par contre, rien ne nous interdit d’en faire des copies et de permettre à nos locataires d’accéder à la console Orchestrator Web Access pour les exécuter. En plus, en plaçant les Runbooks dans des Folders distincts, on peut limiter les populations qui peuvent y accéder, bon point pour l’indépendance.
  • Les contextes d’exécution qui sont nécessairement distincts : Par défaut, tous les Runbooks Orchestrator utilisent le même contexte d’exécution, celui accordé au compte de service Orchestrator. Pas évident que nos locataires autorisent des accès extérieurs non maîtrisés. Par contre, il est possible d’exécuter un Runbook Orchestrator sous un autre contexte. C’est une option de l’activité « Invoke Runbook ». On a juste à référencer les contexte d’exécution sous la forme de variables. Bien entendu, pour le mot de passe, la variable ne sera pas stockée en clair.

clip_image002

Remarque : Au passage, il est aussi possible de limiter l’accès aux variables en utilisant le même mécanisme de Folders et de permissions, comme pour les Runbooks. De cette manière un locataire ne peut pas utiliser les contextes d’exécution des autres.

  • L’impossibilité de répondre à tous les besoins :  Installer des correctifs pour Hyper-V et pour SQL Server, ça n’a rien à voir. Chaque produit a ses propres spécificités. On ne veut pas développer d’usine à gaz. La logique nous a amené à proposer notre approche à nos locataires mais uniquement sous une forme « générique ». Charge à eux de l’implémenter tel que ou de l’adapter en fonction de leurs besoins.
  • Offrir le choix de faire simple : Jusque-là, on ne peut pas dire que j’ai fait simple. Certains de nos locataires pourraient penser que cela ressemble à une usine à gaz, surtout pour des périmètres applicatifs très limités en terme de nombre de machines virtuelles. Pour cette raison, notre « Machin Patching out-of band » n’est jamais imposé aux locataires, juste proposé. S’il estime qu’il est plus agile en patchant ses machines virtuelles manuellement, c’est son problème, ses SLA et son périmètre de sécurité dont il est responsable. Les Runbooks génériques ne font qu’exécuter les scripts présents au sein des machines virtuelles. On peut donc utiliser les même processus en exécutant directement les scripts PowerShell. Ça reste simple pour nos locataires.

BenoîtS – Simple and secure by design but Business compliant (with disruptive flag enabled)

Patch Management – Réflexions – n°1 : Mise à niveau Pilotes / Logiciels bas niveau des Hyper-V

On est au niveau matériel / logiciels bas niveau. Même si Microsoft est devenu beaucoup plus souple pour les clusters et le stockage, on n’est toujours pas fan d’avoir des adaptateurs HBA ou des interfaces réseau différentes dans nos clusters (beurk). Certaines mises à jour peuvent nous permettre d’activer certaines fonctionnalités qui vont nous être très utiles, ou tout simplement améliorer la stabilité de la plateforme. Y a pas à dire toutes les fonctionnalités qui permettent de décharger les CPU des tâches réseau, c’est obligatoire dès qu’on arrive au 10Gb sur les interfaces réseau. Alors avec le Teaming de cartes 10Gb, c’est plus obligatoire mais essentiel.

Pour ce périmètre, les fournisseurs nous livrent des outils qui nous autorisent la mise à niveau de tous ces composants. C’est plutôt bien fait mais, c’est conçu pour faire de l’unitaire. Quand on a plus d’une centaine d’hôtes Hyper-V faudra passer par la case industrialisation. Les outils proposés par les fournisseurs (HP, Cisco, …) sont prévus pour gérer aussi bien la mise à niveau des Firmware que des pilotes bas niveau (interface réseau, …). Le problème, c’est que ce n’est pas nécessairement prévu pour être industrialisé. Il faut un peu de travail. Dans notre cas, nous avions besoin de pouvoir mettre à niveau des châssis entiers avec un impact minimum sur les workloads de nos locataires. Objectif transparence vis-à-vis de nos locataires.

Ci-dessous la vue macro de notre système de Patching. C’est de L’Orchestrator / PowerShell pure et dur. Rentrons un peu dans le détail. Premier point, on travaille au niveau Châssis (Nous avons des blades). Dans notre infrastructure, le châssis c’est notre domaine de panne. Chaque Châssis héberge un certain nombre de clusters.

clip_image001

Ce choix est le fruit d’une longue réflexion qui sera certainement détaillée dans un futur billet. Donc, notre Runbook va traiter tous les clusters d’un même châssis et pour en extraire la liste des tous les nœuds. C’est là qu’intervient l’activité « Parallelize ». Le propre d’Orchestrator, c’est de paralléliser. Le problème, c’est que si on traite tous les nœuds d’un cluster en même temps, ça ne va pas le faire. Pour cette raison, le code PowerShell dans cette activité va s’assurer de traiter un certain nombre de nœuds en parallèle mais pas plus. Le niveau de parallélisation va dépendue uniquement des ressources à disposition pour réaliser les Live Migration des workloads. Pour cette raison, notre règle est de toujours avoir un nœud de libre dans chaque cluster : la réserve. C’est une règle de notre Capacity Planning. Après s’il y a plus d’un nœud de disponible, on peut traiter plus de nœuds du même cluster en même temps.

L’activité « Enter-Maintenance Mode » va juste demander à SCVMM de mettre en maintenance notre nœud de cluster et automatiquement basculer les workloads vers d’autres nœuds au sein du même cluster. L’algorithme de rating de SCVMM étant plutôt bien fait, on lui fait confiance.

Maintenant, on est prêt à patcher en lançant les outils de notre fournisseur matériel préféré (HP, Dell, Cisco, …). A la sortie du paching de la Blade, on collecte les journaux. Si tout s’est bien déroulé, le nœud est réintégré au cluster, sort du mode maintenance et se retrouve éligible pour héberger de nouveau des workloads.

On apprend ici quelques règles de l’industrialisation :

  • Le 100% de réussite, ça n’existe pas. Il y a toujours des erreurs
  • On ne peut pas traiter toutes les erreurs de manière industrielle

Ce n’est pas le type de patching que l’on développe en premier car aux débuts, notre infrastructure est de taille modeste. Au fur et à mesure que l’infrastructure va croitre, on va intégrer du matériel qui utilisera des versions de firmware différentes. C’est là qu’on aura besoin d’un processus industriel pour conserver une certaine homogénéité. Après, il faut relativiser quelques points :

  • Doit-on mettre à jour régulièrement ? Personnellement, tant qu’on en a pas besoin et que la mise à niveau n’apporte pas de fonctionnalité / correction qui me soit utile à moi ou mes locataires, je peux m’en passer.
  • Doit-on patcher ou simplement réinstaller notre cluster ? Avec le Storage Migration, c’est facile de libérer tout un cluster pour permettre sa réinstallation. Avec Windows Server 2012 R2 Core et maintenant Windows Server 2016 dans son installation Nano, faut vraiment se poser cette question.

BenoîtS – Simple and secure by design but Business compliant (with disruptive flag enabled)