IdentifiantMot de passe
Loading...
Mot de passe oublié ?Je m'inscris ! (gratuit)

Vous êtes nouveau sur Developpez.com ? Créez votre compte ou connectez-vous afin de pouvoir participer !

Vous devez avoir un compte Developpez.com et être connecté pour pouvoir participer aux discussions.

Vous n'avez pas encore de compte Developpez.com ? Créez-en un en quelques instants, c'est entièrement gratuit !

Si vous disposez déjà d'un compte et qu'il est bien activé, connectez-vous à l'aide du formulaire ci-dessous.

Identifiez-vous
Identifiant
Mot de passe
Mot de passe oublié ?
Créer un compte

L'inscription est gratuite et ne vous prendra que quelques instants !

Je m'inscris !

Google propose en bêta un service d'autorité de certification pour les clients de sa plateforme cloud
Se rapprochant un peu plus d'AWS dans ce domaine tandis que Microsoft Azure est à la traîne

Le , par Stéphane le calme

294PARTAGES

4  0 
Les certificats numériques sous-tendent l'identité et l'authentification pour de nombreux appareils et services en réseau. Google a présenté un service d'autorité de certification pour les clients de sa plateforme cloud. AWS a déjà un équivalent, mais pas le cloud Azure de Microsoft.

Google indique avoir récemment constaté un intérêt accru pour l'utilisation de l'infrastructure à clé publique (PKI) dans le DevOps et la gestion des appareils, en particulier pour les appareils IdO. Mais l’un des problèmes les plus fondamentaux avec les PKI : il est difficile de mettre en place des autorités de certification (CA), et encore plus de le faire de manière fiable à grande échelle.

Pour répondre à cette problématique, Google a présenté Certificate Authority Service (CAS), qui est disponible en version bêta, de Google Cloud, un service hautement évolutif et disponible qui simplifie et automatise la gestion et le déploiement des autorités de certification privées tout en répondant aux besoins des développeurs et des applications modernes.

Pour voir comment CAS peut vous aider, Anoosh Saboori, Product Manager Google Cloud, a donné des détails sur les difficultés liées à l’utilisation des certificats. Les certificats privés sont l'un des moyens les plus courants d'authentifier les utilisateurs, les machines ou les services sur les réseaux. Les certificats numériques aident à sécuriser de nombreuses interactions, notamment lorsqu'un utilisateur se connecte à un site Web d'entreprise via HTTPS, lorsqu'un ordinateur portable tente de se connecter à un point d'accès WiFi ou lorsqu'un utilisateur tente de se connecter à son compte de messagerie. Ces certificats sont normalement émis par une autorité de certification (CA) privée qui est hébergée sur site, et ils ont tendance à avoir une date d'expiration qui est dans un avenir lointain (en gros une date d'expiration sur une longue durée) avec un processus d'inscription au certificat spécifique à l'appareil / application.

Un scénario émergent d'utilisation de certificats privés est dans les environnements DevOps pour protéger les conteneurs, les microservices, les machines virtuelles et les comptes de service. Cependant, ces nouveaux cas d'utilisation de certificats privés ont des exigences radicalement différentes. En conséquence, les organisations disposant d'une autorité de certification privée sur site réalisent rapidement les limites de leurs autorités de certification privées existantes pour prendre en charge ces scénarios émergents:
  • Des nouveaux cas d'utilisation qui nécessitent des certificats de courte durée qui sont renouvelés fréquemment, qui à leur tour nécessitent une haute disponibilité et une évolutivité de la part de l'autorité de certification. Les solutions CA privées existantes sont insuffisantes. Par exemple, une entreprise peut devoir émettre 10 millions de certificats en un an contre 10 000 pour les appareils IdO.
  • Les processus d'inscription de certificats ne prennent pas en charge les API modernes attendues dans les applications modernes et les chaînes d'outils CI / CD, ce qui se traduit par un délai de mise sur le marché plus long et des retards d'adoption et de revenus.
  • Une incompatibilité avec les autorités de certification intégrées des fournisseurs de cloud, ce qui fait que les clients perdent un point unique pour la gestion et la surveillance des certificats.

De plus, les organisations qui ont délaissé la construction d'une infrastructure sur site et étaient natives du cloud dès le premier jour (c'est-à-dire qu'elles n'avaient jamais eu à configurer une autorité de certification privée) ont commencé à ressentir un besoin de certificats privés. Les autorités de certification privées sur site existantes ne sont pas compatibles avec les plateformes cloud et ne peuvent pas prendre en charge l'échelle associée aux entreprises et hyperscalers natifs du cloud. La seule option dont disposent ces organisations est de créer leur propre autorité de certification privée.

Ainsi, ils se rendent compte du coût élevé de la mise en place et de la gestion d'une autorité de certification privée (coûts d'infrastructure, de licence et d'exploitation) en plus de l'ensemble de compétences élevé requis pour gérer avec succès une autorité de certification privée, qui n'est pas liée à leur cœur de métier et ne fait qu'allonger leur calendrier de mise sur le marché. Souvent, il est plus facile et plus économique de confier cette tâche à un fournisseur de confiance, idéalement un fournisseur de cloud....
La fin de cet article est réservée aux abonnés. Soutenez le Club Developpez.com en prenant un abonnement pour que nous puissions continuer à vous proposer des publications.

Une erreur dans cette actualité ? Signalez-nous-la !