Construire et exécuter des applications sécurisées

• La qualité du certificat numérique: Nous distinguons deux axes de qualité sur lesquels nous travaillerons:

  • La qualité des caractéristiques techniques (Algorithme de génération des clés, algorithme de signature du certificat, utilisation du certificat, etc…)

  • La qualité des caractéristiques de confiance (Autorité de certificat émettrice, politique de certification, procédures de génération, …). Il s’agit des principales composantes de base de votre PKI.

• La durée de vie: En effet, chaque certificat a une durée de vie spécifique. A partir de la date de fin de validité, les services l’utilisant seront indisponibles afin de vous forcer à ne pas utiliser des certificats expirés. L’utilisation d’un certificat expiré expose le serveur ou l’utilisateur à une usurpation de son identité.

Par conséquence, afin de remédier à ces deux risques, il faut, tout d’abord, écrire une politique de conformité afin de définir le cadre de qualité. Ensuite, il s’agira de s’assurer que cette qualité soit maintenue dans le temps. Par exemple, en 2005, il était évident que tous les certificats devaient être émis avec un algorithme de hashage minimal “sha1”. Aujourd’hui, “sha1” est un algorithme obsolète et vulnérable. Les critères de conformités évoluent rapidement. C’est pour cette raison qu’il faut mettre en place une démarche de qualité continue, à titre d’exemple PDCA  (plan-do-check-act).

Au delà de la vulnérabilité des algorithmes et de l’obsolescence des critères d’émission, même lors du renouvellement, il faut maintenir un niveau de conformité.

Effectivement, initialement il est possible que vous générez votre certificat dans le bon cadre. Mais un an plus tard, lors d’un renouvellement de ce certificat, rein de garantit que votre équipe d’exploitation respecte les critères que vous aviez mis en place au départ. L’équipe ne suivra peut-être pas les procédures de renouvellement mises en place. Vous aurez ainsi un certificat non conforme installé sur votre plateforme.

Comment gérer cette problématique ?

Dans cet article, nous illustrons, concrètement, comment mettre en place une usine d’intégration et de déploiement continue, afin de livrer à vos clients des applications sécurisées et conformes à votre politique, grâce à BerryCert.

BerryCert vous apportera aussi le niveau de traçabilité et le workflow de validation. Ils sont nécessaires pour respecter votre politiques de sécurité des systèmes d’information (PSSI), et les référentiels plus exigeant comme ISO 27001 ou PCI-DSS.

La suite de cet article se déroule sous la forme d’un tutoriel guidé avec des échantillons de configurations des différents éléments. Afin d’illustrer la démarche, nous avons fait les choix suivants:

• Nous ne choisissons aucun orchestrateur DevOps, nous illustrons une démarche step-by-step sur un poste quelconque. Mais elle est tout à fait réalisable sur des outils comme Jenkins ou GitLabCI.

• Nous choisissons Docker comme format de livraison et de packaging. Vous pouvez également réaliser la démarche avec d’autres formats, comme des images de VM par exemple.

• Nous choisissons Apache HTTPD comme application cible. L’objectif est de montrer le déroulement sur une application supportant le protocole de communication https.

Nous supposons aussi que vous avez accès à un compte BerryCert, ayant les éléments suivants configurés:

• Une politique de conformité.

• L’accès à votre PKI.

• Une politique de conformité.

• Une politique d’émission.

• Un identifiant pour votre agent

Intégration lors du build

L’objectif de cette étape est de construire des images sécurisées avec le protocole https par défaut, utilisant des certificats conformes par défaut. Nous utiliserons la technique de multi-stages build, qui consiste à créer une image de build, effectuer le build dedans, récupérer le résultat et le copier sur l’image finale (de production). Nous créerons notre propre ‘stage’ de génération de certificat et nous copierons nos certificats dans l’image finale.

Déroulement 

Voici les étapes nécessaires à effectuer dans votre Dockerfile:

• Hériter de votre image de base: Dans l’image de base, nous supposons que vous avez déjà activé le mode https, avec des certificats quelconques (auto-signé par exemple). Cette image de base est disponible ici: my.repo.com/apache:2.4-insecure-alpine

• Télécharger l’agent BerryCert: L’agent BerryCert est un outil permettant de gérer une application cible, il peut être exécuté par BerryCert directement, ou bien en mode CLI manuellement. Le téléchargement est protégé par une authentification. Merci de demander vos identifiants à l’équipe de support de Digitalberry et de les placer ensuite dans la commande ci-dessous après l’argument -u de la commande curl.

N.B: Il existe plusieurs distribution de l’agent selon votre cible (Windows 32 et 64 bits, Linux 32 et 64 bits et Alpine 32 et 64 bits). Selon votre image de base, vous pouvez télécharger la distribution de votre choix.

• Exécuter l’agent BerryCert: En s’exécutant avec le paramètre –auto, l’agent BerryCert va effectuer les opérations suivantes:

  • Scan des certificats existants et transmission à BerryCert (pour des raisons de traçabilité)

  • Génération d’une nouvelle paire de clé dans l’image de build

  • Génération d’une CSR (Certificate Signing Request) à base de la nouvelle paire de clés générée

  • Transmission de la CSR à BerryCert

  • Attente de la signature de cette CSR (polling)

  • Déploiement du nouveau certificat émis

Voici la commande à ajouter dans votre Dockerfile

Voici le détail des arguments de l’agent BerryCert :

• Copier le répertoire généré dans l’image de base:
  • Copier les éléments générés dans un répertoire temporaire (copie de l’arborescence complète, et pas uniquement les fichiers)
  • Copier les éléments de la première image (–from=0) vers la deuxième

RUN mkdir -p /tmp/berrycert_ssl \
    && cat /tmp/paths | tar cvf - | tar xvf - -C /tmp/berrycert_ssl
FROM my.repo.com/apache:2.4-insecure-alpine
COPY --from=0 /tmp/berrycert_ssl /tmp/berrycert_ssl

RUN cp -r /tmp/berrycert_ssl / && rm -rf /tmp/berrycert_ssl

• Activer le SSH: Cette étape permettra à BerryCert de se connecter plus tard pour continuer à gérer le cycle de vie des certificats émis

RUN apt-get update && apt-get install openssh-server \
    && echo 'PermitRootLogin yes' >> /etc/ssh/sshd_config \
    && export USER_NAME=${USER_NAME-root}  \
    && export USER_PASSWORD=${USER_PASSWORD-BerryCert2020}  \
    && echo "${USER_NAME}:${USER_PASSWORD}" | chpasswd \
    && service ssh restart 

Nous recommandons d’ajouter un entrypoint.sh qui gère correctement le service SSH afin de mieux le sécuriser (clé ssh, etc…). Pour l’instant, nous l’activons pour pouvoir connecter BerryCert dans la phase 2 de la démarche. La sécurisation du protocole SSH ne fait pas partie des objectifs de cet article.

• Générer l’image sécurisée: Votre image est maintenant prête, vous pouvez la construire avec cette commande depuis votre terminal:

docker build . -t local/apache:2.4-secure-alpine

Votre image est maintenant disponible en local, vous pouvez la pousser sur votre repository de production, elle est sécurisée.

Il y a plusieurs stratégies de multi-stage building, nous avons choisi celle-ci à titre d’exemple, afin de faire abstraction d’une chaîne DevOps complète

Avantages

• Vous livrez des images docker avec des certificats conformes dès le démarrage
• Vous n’avez pas à installer des outils de cryptographie complexes sur vos images de production, surtout qu’ils ne seront pas utiles à l’exécution temps réel.
• Vous n’avez pas à écrire une procédure supplémentaire ou à ajouter des outils d’automatisation supplémentaires dans le but d’installer des certificats conformes au niveau de votre https. BerryCert le gère pour vous.
• Vous pouvez créer des jobs avec des paramètres afin de construire des images de développement (Snapshot ou RC) depuis la PKI de développement , et des images de Production, depuis la PKI de Production. Les développeurs peuvent donc avoir un environnement similaire à la production dès la phase de développement. Vous pouvez jouer sur le paramètre –usage-id de l’agent, afin d’émettre des certificats avec une politique ou une autre.

Limites

• A ce stade, nous ne gérons pas encore le renouvellement
• Dans certain système d’information, il est possible qu’au moment du build vous n’ayez pas accès à la PKI de production. Vous pouvez utiliser la démarche pour gérer des images de développement très proche de la production
• A ce stade, il est possible que vous n’ayez pas encore les informations du déploiement (nom du serveur, SAN, etc…)

Par ailleurs, nous allons proposer un stratégie complémentaire, permettant de gérer votre instance de serveur lors de la phase run en production.

Intégration après déploiement

Nous avons vu lors de l’étape précédente comment construire une image Docker avec certificats conformes. Maintenant, nous allons déployer cette image et gérer les certificats de cette instance via l’outil BerryCert. Le processus de déploiement n’est pas inclus dans le déroulement de cette étape, il faut déployer avec la mécanique de votre choix (connexion SSH, Ansible, etc…)

Déroulement

Une fois votre image déployée, nous allons inscrire le serveur auprès de BerryCert, en utilisant les API REST

• Authentification: Vous devez utiliser vos identifiants (en tant qu’administrateur de votre organisation) afin d’obtenir un token JWT. Voici le commande curl nécessaire:

curl 'https://berrycert.digitalberry.fr/api/v1/auth/' \
  -H 'Accept: application/json, text/plain, */*' \
  -H 'Content-Type: application/json' \
  --data-binary $'{"username":"john.smith@myorg.com","password":"password"}' 

Voici la réponse du serveur:

{
  "token": "eyJ0eXAiOiJKV1QiLCJhbGciOiJIUzI1NiJ9.eyJ1c2VyX2lkIjoxMiwidXNlcm5hbWUiOiJoYW1kaS56cmFyaUBnbWFpbC5jb20iLCJleHAiOjE2MjAxNjE2MjQsImVtYWlsIjoiaGFtZGkuenJhcmlAZ21haWwuY29tIn0.Vb0Kdy55MIqv6mFcu2ChtnJ6LDCIsqj0FCffAAOxBCs",
  "id_token": "eyJ0eXAiOiJKV1QiLCJhbGciOiJIUzI1NiJ9.eyJ1c2VyX2lkIjoxMiwidXNlcm5hbWUiOiJoYW1kaS56cmFyaUBnbWFpbC5jb20iLCJleHAiOjE2MjAxNjE2MjQsImVtYWlsIjoiaGFtZGkuenJhcmlAZ21haWwuY29tIn0.Vb0Kdy55MIqv6mFcu2ChtnJ6LDCIsqj0FCffAAOxBCs",
  "user": {
    "id": 12,
    "roles": [
      {
        "ROLE_DISABLED": {
          "child": [],
          "tenant": "__all__"
        }
      },
      {
        "ROLE_ADMIN": {
          "child": [],
          "tenant": "my_org1"
        }
      }
    ],
    "tenants": {
      "__all__": [
        "ROLE_DISABLED"
      ],
      "my_org1": [
        "ROLE_ADMIN"
      ]
    },
    "last_login": null,
    "is_superuser": false,
    "username": "john.smith@myorg.com",
    "first_name": "John",
    "last_name": "Smith",
    "email": "john.smith@myorg.com",
    "is_staff": false,
    "is_active": true,
    "date_joined": "2021-03-09T18:07:28.432286Z",
    "is_updated": false,
    "is_default": 3
  }
}

Votre token JWT est dans le champs id_token.

• Ajouter les identifiants SSH du serveur: Voici la commande curl nécessaire:

curl 'https://berrycert.digitalberry.fr/bcs-berryexchange/api/v1/credentials/' \
  -H 'Accept: application/json, text/plain, */*' \
  -H 'Authorization: Bearer eyJ0eXAiOiJKV1QiLCJhbGciOiJIUzI1NiJ9.eyJ1c2VyX2lkIjoxMiwidXNlcm5hbWUiOiJoYW1kaS56cmFyaUBnbWFpbC5jb20iLCJleHAiOjE2MjAxNjEzOTgsImVtYWlsIjoiaGFtZGkuenJhcmlAZ21haWwuY29tIn0.rVrds-LJfGhqLq8JDys_cUeEjey0A-uR_YpIdDR7oaw' \
  -H 'Content-Type: application/json; charset = UTF-8' \
  --data-binary '{"name":"Identifiants de test","content":{"auth_type":"SSH_PASSWORD","username":"root","password":"password"},"protocol":"SSH","tenant":"my_org1"}' 

Voici la réponse du serveur:

{
  "id": 67,
  "content": {
    "b64_value": "23wTcBRTn+S29KW44KyG7lHkSEzGPU9i6KROXm/3oUvosQ3r9NCinHTZmlqyB5jq3OOyDh+9hH+4rJDtOoCNmg9xhFALxIiCGh/a3rpPC8gAi5sthYwcWJPFcNgEYVmz"
  },
  "tenant": "my_org1",
  "name": "Identifiants de test",
  "description": "",
  "key_id": 1,
  "creation_date": "2021-05-03T21:12:23.512650Z",
  "created_by": "john.smith@myorg.com",
  "protocol": "SSH",
  "is_shared": false
}

Veuillez récupérer l’identifiant de l’objet créé (champs id), nous l’utiliserons dans l’étape suivante

• Déclarer le serveur auprès de BerryCert: Voici la commande curl nécessaire:

curl 'https://berrycert.digitalberry.fr/bcs-berrycertcore/api/v1/hosts/' \
  -H 'Accept: application/json, text/plain, */*' \
  -H 'Authorization: Bearer eyJ0eXAiOiJKV1QiLCJhbGciOiJIUzI1NiJ9.eyJ1c2VyX2lkIjoxMiwidXNlcm5hbWUiOiJoYW1kaS56cmFyaUBnbWFpbC5jb20iLCJleHAiOjE2MjAxNjEzOTgsImVtYWlsIjoiaGFtZGkuenJhcmlAZ21haWwuY29tIn0.rVrds-LJfGhqLq8JDys_cUeEjey0A-uR_YpIdDR7oaw' \
  -H 'Content-Type: application/json; charset = UTF-8' \
  --data-binary '{"name":"Mon serveur","fqdn":"server1.localdomain.infra","protocol":"SSH","port":22,"persisted":false,"credential_id":67,"tenant":"my_org1"}' 

Voici la réponse du serveur:

{
  "description": null,
  "created_by": "john.smith@myorg.com",
  "created_at": "2021-05-03T21:29:18.134449Z",
  "tenant": "my_org1",
  "updated_by": null,
  "updated_at": null,
  "is_shared": false,
  "id": 139,
  "fqdn": "server1.localdomain.infra",
  "name": "Mon serveur",
  "port": 22,
  "protocol": "SSH",
  "persisted": false,
  "credential_id": 67,
  "status": null,
  "unmanagement_reason": null,
  "agents": []
}

La gestion des serveurs est asynchrone. l’outil BerryCert fera une tentative de connexion quelques minutes après la requête.

Maintenant que votre serveur est géré par l’outil BerryCert, vous le verrez apparaître dans l’inventaire des serveurs. Le workflow que vous avez paramétré sur BerryCert s’appliquera. Si la gestion automatique est activée, les certificats de votre serveur seront renouvelés et déployés selon votre politique de conformité et leurs dates de validité. Afin de mieux paramétrer ces éléments, veuillez consulter notre FAQ ici (TODO).

Avantages

Cette phase vient donc compléter la première phase de build en ajoutant votre serveur à votre workflow BerryCert. BerryCert prendra la main ensuite. Un workflow 100% automatisé ressemblerait à:

• Lancer un scan périodique et planifié sur tous les serveurs enregistrés

• Lancer un renouvellement périodique et planifié des certificats

  • Ne respectant pas la politique de conformité définie

  • En expiration proche (<15j)

• Lancer un déploiement périodique et continu de tous les certificats renouvelés

Conclusion

Cet article détaillé vous explique, étape par étape, une intégration de l’outil BerryCert, dans le but de livrer des images docker sécurisées et de pouvoir continuer à les gérer une fois déployées. Nous avons pris Apache https et docker comme exemple. Mais notre Agent BerryCert et nos API nous permettent de nous adapter à tous types d’infrastructures et de s’y intégrer facilement. Si vous avez des questions n’hésitez pas à nous contacter, nous aurons le plaisir de vous accompagner dans l’intégration de BerryCert au sein de votre infrastructure.