Livre blanc du chiffrement

Dernière mise à jour le 21 octobre 2019

Introduction

Pourquoi les entreprises adoptent-elles le cloud ? C'est généralement parce que les environnements de cloud sont évolutifs, fiables et hautement disponibles. Cependant, ce ne sont pas les seuls éléments à prendre en compte : la sécurité peut remettre en question les autres avantages du cloud.

C'est la raison pour laquelle les fournisseurs de cloud doivent disposer d'une stratégie de sécurité complète. La stratégie de Zoho en matière de sécurité englobe plusieurs dimensions, dont le chiffrement est une composante essentielle.

Cette page vous dira tout ce que vous avez envie de savoir sur la stratégie de Zoho en matière de chiffrement et la façon dont nous l'utilisons pour assurer la sécurité de vos données.

Qu'est-ce que le chiffrement ?

Au départ, le chiffrement était utilisé pour protéger le contenu d'un message afin que seul le destinataire prévu puisse le lire. Pour ce faire, le contenu était remplacé par des données non reconnaissables que seul le destinataire prévu pouvait comprendre. C'est ainsi que le chiffrement est devenu une méthode de protection des données contre les individus désireux de les dérober.

Le chiffrement consiste à modifier les données à l'aide d'un processus de codage spécial afin qu'elles ne soient plus reconnaissables (chiffrées). Un processus de décodage spécial est ensuite appliqué pour récupérer les données d'origine (déchiffrées). Le fait de garder secret le processus de décodage empêche toute autre personne que le destinataire de récupérer les données d'origine à partir des données chiffrées.

Le processus de codage suit un algorithme de chiffrement tel qu'AES 256, qui est public. Toutefois, le processus lui-même dépend de la clé utilisée pour chiffrer les données, puis les déchiffrer afin de récupérer les données d'origine.

La clé est gardée secrète. Sans la clé, toute personne ayant réussi à accéder aux données verra uniquement un « texte chiffré » qui n'aura pas de signification réelle. Les données sont ainsi protégées.

Pourquoi nous chiffrons vos données

La dernière couche de protection : bien qu'une stratégie de sécurité complète permette à une entreprise de protéger ses données contre les pirates, le chiffrement est le dernier rempart contre les tentatives de vol de vos données. Il complète la protection des données en garantissant qu'elles ne pourront être ni endommagées ni volées si une violation de sécurité devait malheureusement se produire.

Confidentialité : le chiffrement est une garantie de confidentialité sur Internet. Le chiffrement contribue à protéger la confidentialité en transformant les informations personnelles en données « à votre seule attention », destinées uniquement aux parties qui en ont besoin. Lorsque vous interagissez avec nous et stockez vos données sur nos serveurs, le chiffrement nous permet de vous garantir une confidentialité absolue.

Ce que nous entendons par « données »

Nous traitons deux types de données :

  1. Données client : données que vous stockez avec nous via les services Zoho. Généralement, ces données sont gérées par un service Zoho via un compte client qui peut être identifié dans notre base de données IAM (Identity and Access Management).

    En fonction de la sensibilité des données et des exigences de l'utilisateur, certaines données client sont chiffrées alors que d'autres ne le sont pas. Les données sensibles sont les données dont la divulgation est susceptible de nuire aux personnes ou organisations concernées.

  2. Données dérivées : données qui ne sont pas directement fournies par vos soins, mais qui sont dérivées de vos données. Par exemple, les jetons d'authentification, les ID uniques, les URL, les rapports, etc. sont stockés avec nous.

    En fonction de la sensibilité des données, certaines données dérivées sont chiffrées alors que d'autres ne le sont pas.

Dans les sections suivantes, le terme « données » fait référence aux données chiffrées.

Chiffrement en transit

Lorsque vous utilisez Zoho Services, vos données parcourent Internet depuis votre navigateur vers notre centre de données ou d'autres infrastructures tierces (tout en utilisant des intégrations tierces). Le chiffrement des données en transit protège vos données contre les attaques dites de l'homme du milieu (ou man-in-the-middle attacks).

Il existe deux scénarios dans lesquels les données en transit sont chiffrées :

  • Lorsque les données transitent de votre navigateur vers nos serveurs.
  • Lorsque les données transitent de notre serveur vers des serveurs non Zoho (tiers)

Entre vous et Zoho

Zoho a établi des règles strictes pour adapter le protocole TLS (Transport Layer Security) à toutes ses connexions. Le protocole TLS garantit une connexion sécurisée entre vous et les serveurs Zoho en autorisant l'authentification des deux parties impliquées dans la connexion et en chiffrant les données à transférer. Il garantit qu'aucun tiers ne puisse intercepter ou parasiter une communication entre vous et Zoho.

Nous appliquons la dernière version du protocole TLS 1.2/1.3 et utilisons les certificats émis par SHA 256 et des algorithmes de chiffrement (clés AES_CBC/AES_GCM 256 bits/128 bits pour le chiffrement, fonction de hachage SHA2 pour l'authentification des messages et mécanisme d'échange de clés ECDHE_RSA). Nous appliquons également les mécanismes Perfect Forward Secrecy et HTTPS Strict Transport Security (HSTS) sur tous les sites.

Entre Zoho et les tiers

Nous suivons le protocole https dans nos communications avec des tiers. Pour les transactions impliquant des cas d'utilisation ou des données sensibles, nous employons le chiffrement asymétrique, qui utilise un système de clés publiques et privées pour chiffrer et déchiffrer les données.

Pour cette méthode, nous générons une paire de clés publique et privée dans notre service de gestion des clés (Key Management Service - KMS), qui crée, stocke et gère les clés pour l'ensemble des services. Nous chiffrons ces paires de clés grâce à une master key (clé principale), les paires de clés chiffrées étant stockées dans le système KMS lui-même. La clé principale est stockée sur un serveur distinct.

Nous mettons les clés publiques à la disposition des tiers par le biais de certificats, tandis que nous stockons la clé privée dans le KMS. Après l'authentification, les données chiffrées sont déchiffrées dans le KMS.

Chiffrement au repos

Il existe deux principaux niveaux de chiffrement :

  1. Le chiffrement de la couche applicative
  2. Le chiffrement intégral du disque basé sur le matériel

La stratégie du chiffrement des données au niveau de l'application dépend du lieu et du mode de stockage des données.

  • Base de données (DB) : stockées sous forme de tables
  • Système de fichiers distribué (DFS) : stockées sous forme de fichiers
  • Chiffrement URL
  • Sauvegarde
  • Journaux
  • Cache

L'image ci-dessous présente une vue d'ensemble de notre stratégie de chiffrement :

stratégie de chiffrement

Niveau application

Tout service (ou toute application) Zoho que vous utilisez implique des données : les données que vous fournissez et les données que nous stockons en votre nom dans le cadre du service. Ces données peuvent être reçues sous forme de fichier ou de champs de données. Chacune de ces catégories est traitée différemment quant à la manière dont elle est chiffrée.

Cette section traite du chiffrement au repos au niveau application.

Chiffrement de la base de données

Lorsque vous utilisez des services tels que Zoho Creator ou Zoho Forms, les données que vous saisissez dans l'application, ou données de service, sont stockées dans notre base de données sous forme de tables.

Les données de ces tables sont chiffrées conformément à la norme AES 256 avec le mode AES/CBC/PKCS5Padding. Toutefois, le niveau de chiffrement varie en fonction de la sensibilité du champ de données, ainsi que des choix et exigences de l'utilisateur.

Il existe deux niveaux de chiffrement de base de données :

  1. Selon la sensibilité des données
  2. Selon la fonctionnalité de recherche

Remarque : ci-après, le terme « organisation » désigne un client ou une organisation qui utilise un service Zoho et a un nombre limité d'utilisateurs.

Selon la sensibilité des données

Niveau 1 : niveau de chiffrement par défaut que nous appliquons pour les données de toutes les organisations. À ce niveau, notre KMS attribue une clé à chaque organisation. Les données correspondant à cette organisation sont chiffrées à l'aide de cette clé. La clé est chiffrée avec une clé principale, et la clé chiffrée est stockée sur un serveur distinct.

Niveau 2 : nous appliquons ce niveau de chiffrement pour les informations sensibles et les informations personnellement identifiables (PII). Cette catégorie inclut les champs tels que les numéros de compte bancaire, les numéros d'identification et les données biométriques.

À ce niveau, le KMS génère une clé unique pour chaque colonne d'une table. Toutes les données d'une colonne particulière sont chiffrées à l'aide de la clé générée pour cette colonne. Ces clés sont à nouveau chiffrées à l'aide d'une clé principale et stockées sur un serveur distinct.

Selon la fonctionnalité de recherche

Un vecteur d'initialisation (Initialization Vector, IV) est une valeur aléatoire qui lance le processus de chiffrement. Cette valeur aléatoire garantit que chaque bloc/unité de données se chiffre différemment. Cela signifie également que chiffrer deux fois les mêmes données produit des textes chiffrés différents.

Pourquoi le vecteur d'initialisation est important

Si vous n'avez pas de vecteur d'initialisation et utilisez le mode Cipher Block Chaining (CBC) seulement avec votre clé, deux ensembles de données commençant par des données identiques produiront des premiers blocs identiques. Avec les vecteurs d'initialisation, il est peu probable que le chiffrement de deux données distinctes crée les mêmes paires entrée/sortie (au niveau de l'algorithme de chiffrement du bloc et à l'aide de la même clé), même si une donnée est liée à l'autre (y compris, mais sans limitation, en commençant par le même premier bloc).

Lorsque chaque demande de chiffrement active l'utilisation d'un vecteur d'initialisation aléatoire, le premier bloc est différent. L'attaquant ne peut pas déduire quoi que ce soit qui pourrait l'aider à décoder les données chiffrées.

Chiffrement à protection égale : il s'agit du niveau de chiffrement par défaut de toutes les tables. À ce niveau, la totalité d'une table de données reçoit un IV. Cela signifie que le bloc entier de texte chiffré peut être utilisé dans une requête de recherche au sein d'une table. L'IV étant identique pour toutes les données de la table, une recherche récupérera les données pour vous.

Chiffrement standard : à ce niveau, chaque entrée de données possède un IV unique. Même si vous chiffrez la table entière avec une seule clé, chaque entrée de données chiffrées produira un texte chiffré unique. En outre, étant donné que le vecteur d'initialisation est aléatoire et unique pour chaque donnée, une recherche ne récupérera pas les données pour vous. Il s'agit d'une option plus sûre que la variante « Protection égale ».

Choix d'une variante

La décision d'opter pour une variante particulière dépend généralement des besoins. Si les données doivent bénéficier du niveau de protection le plus élevé, nous optons pour le niveau 2 avec le chiffrement standard. Cependant, si seulement certains champs ont besoin de la protection maximale, la protection de niveau 2 avec la version standard suffit.

Toutefois, la protection n'est pas toujours le seul facteur de choix. Les utilisateurs pourront, par exemple, vouloir rechercher et récupérer un champ tel qu'un « ID de messagerie » pour répondre à leurs besoins. Dans ce cas, une option standard ne serait pas adaptée et nous choisirions la variante « Protection égale ».

Chiffrement niveau fichier ou DFS

Lorsque vous utilisez des services tels que Zoho Docs, vous créez des fichiers qui sont enregistrés dans notre système de fichiers distribué (DFS).

Le chiffrement est basé sur l'algorithme AES 256 standard, mais le mode de chiffrement est basé sur un compteur : mode CTR (CounTeR). Dans AES 256, le texte brut qui doit être chiffré est divisé en paquets de données ou blocs. Étant donné que nous chiffrons le contenu de fichiers ici, l'algorithme doit s'assurer que le chiffrement de chaque bloc est indépendant des autres, afin qu'un attaquant n'obtienne aucune information sur le fichier, même si le chiffrement d'un bloc est compromis. Le mode CTR répond parfaitement à cette exigence.

Comme pour les bases de données, il existe deux niveaux de chiffrement des fichiers :

Niveau 1 : à ce niveau, chaque organisation est dotée d'une clé. Chaque fichier d'une organisation est chiffré à l'aide de cette clé, mais avec un vecteur d'initialisation aléatoire unique qui est stocké avec le fichier lui-même. Cette clé est elle-même chiffrée à l'aide d'une clé principale et stockée dans KMS.

Niveau 2 : à ce niveau, chaque fichier reçoit une clé unique et est chiffré à l'aide de cette clé. Chaque clé utilisée pour chiffrer un fichier est à nouveau chiffrée à l'aide d'une clé principale, et la clé chiffrée est stockée avec le fichier dans le DFS. La clé principale est unique pour le service ou l'application. Elle est stockée et gérée dans le système KMS.

Chiffrement URL

Les liens d'invitation ou toute autre communication entre nous peuvent impliquer la transmission de données sensibles dans les URL. Pour sécuriser la communication, certaines parties de l'URL sont chiffrées. Si l'URL contient un élément identifiable, comme l'ID d'un document, cette partie est chiffrée.

Le chiffrement comporte deux niveaux : une clé par organisation ou une clé par URL. Là encore, le niveau est choisi en fonction de la sensibilité des données dans l'URL.

Chiffrement de sauvegarde

Nous créons des sauvegardes sur la base de deux programmes : quotidiens et hebdomadaires. Les serveurs de sauvegarde sont équipés du même niveau de protection que les serveurs principaux. Toutes les données retenues comme sauvegarde sont chiffrées au repos. Nous utilisons l'algorithme AES 256 pour le chiffrement et stockons les clés sur un serveur distinct. Nous disposons également de centres de données (DC) redondants qui garantissent une haute disponibilité. Ces centres de données ont également une copie de vos données chiffrées et font l'objet de sauvegardes, comme le centre de données principal.

Chiffrement des journaux

Zoho Logs utilise Hadoop Distributed File System (HDFS) pour stocker et gérer les journaux. Nous employons la technologie de chiffrement de Hadoop Inc. pour chiffrer les données tandis que la gestion des clés est réalisée par notre KMS.

Chiffrement du cache

Nous utilisons le logiciel open source Redis pour stocker et gérer les données de cache. Le cache contient les données qui sont utilisées à plusieurs reprises dans le cadre du fonctionnement du service et doivent être stockées pendant un certain laps de temps. Vos données peuvent parfois être mises en cache pour améliorer le service ou pour le dépannage. Si des données contiennent des informations personnelles sensibles, nous choisissons de les chiffrer.

Gestion des clés

Notre service interne de gestion des clés (KMS) crée, stocke et gère les clés de l'ensemble des services. Nous possédons les clés et nous les gérons à l'aide du KMS. Actuellement, nous n'avons pas la possibilité de chiffrer des données avec des clés appartenant au client.

Différents types de clés sont utilisés à différentes étapes du chiffrement :

Clé de chiffrement des données (DEK) : clé utilisée pour convertir les données depuis un texte brut vers un texte chiffré, ou clé utilisée pour chiffrer les données.

Clé de chiffrement de clé (KEK) : clé utilisée pour chiffrer la clé DEK. Cette clé est spécifique au service. Elle offre une couche de sécurité supplémentaire.

Clé principale : clé utilisée pour chiffrer la KEK. Cette clé est stockée sur un serveur isolé pour des raisons de sécurité.

Mode de fonctionnement du KMS

Tous les types de chiffrement sont conformes à l'algorithme AES 256. Selon cet algorithme, les données sont traitées en tant que « blocs » qui doivent être chiffrés. Qu'il s'agisse d'un champ dans la base de données ou d'un fichier dans le système DFS, le chiffrement commence lorsqu'un bloc de données est chiffré à l'aide d'une clé DEK.

Cette clé DEK est elle-même chiffrée à l'aide d'une clé KEK. La clé KEK est à nouveau chiffrée à l'aide d'une clé principale qui est stockée sur un serveur distinct. Voici les éléments à gérer :

  • Données chiffrées
  • Clés DEK
  • Clés DEK chiffrées
  • Clés KEK
  • Clés KEK chiffrées
  • Clé principale

Le KMS gère ces éléments de la manière suivante :

kms1

1
Lancer des demandes

Utilisateur authentifié auprès du service Zoho et qui demande des données

2
Chiffrement en transit

Chiffrement TLS

3
Application frontale

Dirige le trafic vers les serveurs d'applications

4
Serveur d'applications

Lance le processus de chiffrement

5
Service de gestion des clés (KMS)

Génère/récupère la clé de chiffrement des données (DEK)

6
Serveur principal

Génère/récupère le chiffrement de clé (KEK)

7
Base de données KMS

Stocke la clé DEK chiffrée

8
Service de gestion des clés (KMS)

Renvoie la clé DEK pour le chiffrement

9
Agent de chiffrement

Chiffre les données à l'aide de la clé DEK

10
Stockage

Stocke les données chiffrées

Comment les clés sont-elles générées ?

KMS génère des clés de 256 bits conformes au protocole AES 256, ainsi qu'un vecteur d'initialisation (IV). Le vecteur d'initialisation, comme nous l'avons déjà évoqué, garantit que le premier bloc de données chiffrées est aléatoire. C'est pourquoi le même texte brut est chiffré dans différents textes chiffrés, à l'aide de vecteurs d'initialisation.

KMS génère ces clés et le vecteur d'initialisation à l'aide d'une bibliothèque Java sécurisée et d'un générateur de nombres aléatoires sécurisé. 

Où sont stockées les clés ?

Les clés DEK générées dans KMS sont chiffrées à l'aide d'une clé KEK. Cela offre une couche de sécurité supplémentaire. Les clés DEK chiffrées sont stockées dans la base de données KMS.

couches-sécurité

Nous séparons physiquement les clés (nous les stockons dans différents emplacements) afin qu'un pirate qui se procurait une clé ne puisse pas obtenir d'autres clés associées. Nous chiffrons la clé KEK à l'aide d'une clé principale et la stockons sur un serveur distinct.

Concernant Zoho Docs, nous offrons une couche de sécurité supplémentaire pour les documents stockés au repos.

couches-sécurité1

Un attaquant ne pourra pas compromettre les données en ciblant simplement le KMS seul.

Quel est le niveau de sécurité des clés ?

Séparation physique : comme nous l'avons vu précédemment, la clé principale reste dans un serveur physiquement distinct et sécurisé. Il est donc difficile pour un attaquant de compromettre à la fois les clés DEK et les clés KEK.

Contrôle d'accès : le contrôle d'accès nous permet d'éviter toute mauvaise utilisation et un accès sans précédent aux clés. Une liste de contrôle d'accès (ACL) permet uniquement à des services sélectionnés d'accéder à des clés sélectionnées. Chaque accès à une clé passe par l'authentification, et le processus est consigné. Des audits réguliers des journaux permettent de surveiller le processus.

L'accès aux serveurs de gestion des clés est limité par défaut et réservé à un personnel spécifique de Zohocorp. Tout autre accès fait l'objet d'un ticket et est autorisé uniquement après l'approbation de la direction. 

Rotation des clés : nous utilisons un système de rotation des clés dans lequel nous modifions périodiquement la clé principale racine, ce qui assure une sécurité supplémentaire. Lorsqu'une nouvelle clé principale et un vecteur d'initialisation sont générés, cela signifie que les clés de la base de données doivent également être renouvelées. Par conséquent, toutes les clés de la base de données sont d'abord récupérées et déchiffrées à l'aide de l'ancienne clé principale, puis chiffrées à nouveau avec la nouvelle clé principale et mises à jour dans la base de données.

Il est possible de déclencher manuellement la rotation des clés afin de gérer des situations critiques susceptibles de se présenter.

Disponibilité des clés : en cas de défaillance du stockage principal des disques d'un centre de données (DC), il existe un esclave et un esclave secondaire pour la sauvegarde, qui contiennent les mêmes données que le centre de données principal. L'esclave et l'esclave secondaire possèdent tous deux des clés DEK chiffrées, comme le maître.

Quelles données chiffrons-nous dans nos services ?

Les données qui sont chiffrées au repos varient en fonction des services que vous choisissez. Les options et niveaux de chiffrement d'une entrée de données particulière sont déterminés par vous ou par nous, ou d'un commun accord.

Le tableau suivant décrit les données chiffrées par différents services Zoho :

ServiceChamps chiffrés
CRMChamps personnalisés contenant des informations personnelles, tous les fichiers
DocsTous les fichiers
CreatorChamps personnalisés
CampaignsChamps contenant des informations personnelles, fichiers chargés par l'utilisateur
CliqChatTranscript et informations personnelles
PeopleChamps personnalisés, tous les fichiers
ConnectTitre, URL et contenu des flux, publications du blog, articles, discussions ouvertes, groupes, annonces, tâches et leurs commentaires, fichiers vidéo et pièces jointes
DeskContenu du fil des tickets, pièces jointes et jetons
FinanceCoordonnées bancaires, champs personnalisés contenant des informations personnelles, renseignements sur les employés comportant des informations personnelles, documents de voyage, relevés bancaires, pièces jointes
ProjectsPièces jointes, champs contenant des informations personnelles, jetons
NotebookFiche de notes et pièces jointes
SignDocuments, images de signature et jetons
ReportsChamps personnalisés, fichiers chargés par les utilisateurs, requêtes personnalisées
MailTout le contenu du courrier, pièces jointes et champs contenant des informations personnelles
RecruitChamps personnalisés, documents importés par l'utilisateur
SocialJetons, champs contenant des informations personnelles

Chiffrement intégral du disque

Nous utilisons des disques Self-Encrypting Drives (SED) pour prendre en charge le chiffrement intégral du disque basé sur le matériel.

Un SED est un disque dur HDD ou SSD doté d'un circuit de chiffrement intégré au disque. Le chiffrement automatique signifie simplement que toutes les données écrites sur le support de stockage sont chiffrées par le lecteur de disque avant d'être écrites, puis déchiffrées par le lecteur de disque lors de leur lecture.

Les disques SED sont conformes à la norme FIPS 140-2 ou à TCG. L'algorithme de chiffrement configuré pour les disques SED est AES. La clé utilisée pour le chiffrement et le déchiffrement comporte 256 caractères.

Deux types de clés sont utilisés dans les disques SED : la clé de chiffrement des données (DEK) et la clé d'authentification (AK).

Clé de chiffrement des données : cette clé est utilisée pour chiffrer/déchiffrer les données dans le lecteur. Cette clé est générée par un fournisseur au cours du processus de fabrication. Lorsque nous recevons de nouveaux serveurs avec des disques SED, nous régénérons la clé pour des raisons de sécurité.

Clé d'authentification : cette clé chiffre la clé DEK et est utilisée pour verrouiller et déverrouiller le lecteur. Les clés d'authentification sont générées grâce à une stratégie solide et stockées dans notre système de gestion des clés (KMS). La même clé est transférée de manière sécurisée à chaque serveur lorsque nous activons le chiffrement dans les serveurs. Nous utilisons la gestion des clés locale (LKM) pour gérer la clé d'authentification.

Remarque : actuellement, le chiffrement intégral du disque basé sur le matériel s'applique uniquement aux centres de données en Inde (IN).

Conclusion

Nous chiffrons les données sensibles des clients lorsqu'elles sont stockées, lorsqu'elles sont en transit sur Internet et lorsqu'elles circulent entre nos centres de données. Cependant, le chiffrement n'est qu'un élément de notre stratégie de sécurité. Nous innovons constamment et nous nous efforçons d'améliorer la protection des données en appliquant les protocoles et technologies les plus récents. Pour en savoir plus sur notre stratégie de sécurité complète, rendez-vous sur https://www.zoho.com/security.html.