Exporter (0) Imprimer
Développer tout
3 sur 6 ont trouvé cela utile - Évaluez ce sujet

Amélioration de la sécurité des données à l'aide de SQL Server 2005

Paru le 01 octobre 2005

Procédures de Microsoft IT

Téléchargez
Download Étude de cas technique
817 ko
Microsoft Word file
Download Présentation PowerPoint
1,21 Mo
Microsoft PowerPoint file
Download IT Pro Webcast
Sur cette page

Résumé Résumé
Introduction Introduction
Environnement de l'application Environnement de l'application
Solution : le cryptage SQL Server 2005 Solution : le cryptage SQL Server 2005
FeedStore FeedStore
Application PCRS (Payroll Controls Reporting System) Application PCRS (Payroll Controls Reporting System)
Metropolis Metropolis
Méthodes recommandées Méthodes recommandées
Conclusion Conclusion
Pour plus d'informations Pour plus d'informations
Annexe : Scénarios d'utilisation du cryptage Annexe : Scénarios d'utilisation du cryptage

Situation

Les récentes lois fédérales et internationales, qui définissent les obligations de conformité réglementaire pour les entreprises qui stockent des informations personnelles identifiables, ont contraint Microsoft a rééavaluer les infrastructures de sécurité de base de données existantes.

Solution

  • Les fonctionnalités intégrées de cryptage au niveau colonne permettent de crypter les données sensibles des applications sans rencontrer les surcoûts liés au cryptage d'une base de données entière.


Avantages

  • La gestion des clés dans Microsoft SQL Server 2005 permet la création d'une infrastructure simple, robuste et facile à utiliser pour la gestion des clés de cryptage.

  • Les fonctionnalités intégrées de cryptage au niveau colonne permettent de crypter les données sensibles des applications sans tenir compte de la surcharge liée au cryptage d'une banque entière.

  • Les fonctionnalités de cryptage intégrées à SQL Server 2005 permettent le décryptage des données d'une vue et l'accès facile aux données cryptées.

  • La hiérarchie de gestion des clés de SQL Server 2005 permet de créer des procédures stockées signées numériquement afin de simplifier le cryptage des données.


Produits et technologies

Microsoft SQL Server 2005

Résumé

Microsoft, comme beaucoup d'autres entreprises, analyse soigneusement les infrastructures de sécurité de base de données existantes afin de s'assurer qu’elles sont conformes aux récentes exigences réglementaires, telles que le Sarbanes-Oxley Act de 2002. Ces exigences spécifient les conditions pour le stockage des informations personnellement identifiables. Ces exigences n'affectent pas uniquement les données lorsqu'elles sont stockées dans une base de données. Elles affectent également les mécanismes de transfert de données, les contrôles d'autorisation et d'accès à la base de données, ainsi que l'audit de base de données.

Via cette analyse de base de données, le département Microsoft IT (Microsoft Information Technology) a déterminé que des données sensibles étaient dupliquées dans l'espace des applications métier de Microsoft IT. Ces données étaient dupliquées lorsque des données étaient transférées et répliquées au cours des opérations quotidiennes de l'entreprise.

En réponse à cette analyse, Microsoft IT a développé des stratégies afin de limiter la duplication des données sensibles et d'améliorer la sécurité des informations personnellement identifiables dans l'espace des applications métier de Microsoft IT. Ces stratégies sont basées sur les nouvelles fonctionnalités de sécurité de Microsoft® SQL Server™ 2005.

Le groupe Enterprise Data Services de Microsoft IT a créé un référentiel d'informations central de 2 téraoctets, nommé FeedStore. Le groupe a développé un projet pilote afin d'améliorer la sécurité des informations personnellement identifiables transmises via FeedStore. Ce projet impliquait la création d'une banque cryptée centralisée, appelée Digital Asset Store, pour stocker les informations personnellement identifiables très sensibles. Enterprise Data Services a conçu Digital Asset Store pour utiliser les fonctionnalités de gestion des clés et de cryptage au niveau colonne de SQL Server 2005 pour crypter les données sensibles dans un emplacement central. Ce projet pilote présentait des objectifs métier et fonctionnels clairs dans le but de réduire ou de supprimer la duplication des données dans les applications métier de Microsoft IT.

Le département Financial IT de Microsoft IT a créé l'application PCRS (Payroll Controls Reporting System). Ce département a développé une infrastructure de sécurité afin de renforcer la sécurité des données via le cryptage des données sensibles stockées dans le data warehouse PCRS. En outre, le département Services IT de Microsoft IT a utilisé les fonctionnalités de gestion des clés et de cryptage au niveau colonne de SQL Server 2005 pour créer un mécanisme de cryptage robuste et fiable pour crypter les données de l'application Metropolis.

Ce document décrit l'expérience de Microsoft IT concernant ces stratégies de sécurité et les fonctionnalités de cryptage de SQL Server 2005. Dans la mesure où de nombreux projets pilote SQL Server 2005 sont actuellement en cours, Microsoft IT a tiré des leçons et méthodes recommandées liées à la consolidation et au cryptage des données dans l'espace des applications métier de Microsoft IT. Étant donné que les exigences de Microsoft IT sont parmi les plus contraignantes au monde, les stratégies développées par Microsoft IT et les leçons tirées par Microsoft IT au cours du déploiement de SQL Server 2005 doivent pouvoir servir de base aux entreprises qui souhaitent déployer une interface de cryptage et de gestion des clés basée sur SQL Server 2005.

Ce document s'adresse aux décideurs d'entreprise, aux décideurs techniques, aux architectes informatiques, aux développeurs de base de données et aux responsables de déploiement. Bien que ce document fournisse des recommandations basées sur l'expérience de Microsoft IT, il ne s'agit pas d'un guide procédural. Chaque environnement d'entreprise présente ses propres spécificités. Par conséquent, chaque organisation doit adapter ces informations à ses besoins spécifiques.

Remarque : Pour des raisons de sécurité, les exemples de noms de ressources internes, organisations et fichiers développés en interne sont fictifs et ne représentent pas les noms réels utilisés chez Microsoft et sont proposés à des fins d'illustration uniquement.

Introduction

Les décideurs d'entreprise demandent souvent des informations sur les expériences Microsoft d'utilisation des produits et technologies Microsoft. Les départements informatiques de Microsoft ne fournissent pas uniquement des services informatiques. Ces départements jouent également le rôle de premier client pour chaque nouvelle version des logiciels pour les serveurs et la productivité. Dans la mesure où les exigences de Microsoft IT sont parmi les plus contraignantes au monde, les méthodes utilisées par Microsoft IT pour déployer ces technologies, ainsi que l'expérience acquise par Microsoft IT suite à ces déploiements, constituent souvent des bases intéressantes pour les autres entreprises qui souhaitent déployer des produits Microsoft.

En outre, étant donné que Microsoft IT utilise les nouveaux produits Microsoft des versions bêta aux versions définitives (RTM, Release to Manufacturing), Microsoft IT fournit à Microsoft des commentaires précieux sur les fonctionnalités des produits. Ces commentaires améliorent les produits logiciels. Ils aident également les clients et partenaires Microsoft à déployer avec succès ces produits et technologies.

Vue d'ensemble des exigences réglementaires

Comme d'autres entreprises, Microsoft a réévalué les infrastructures de sécurité existantes afin de s'assurer qu'elles sont conformes aux récentes lois fédérales, nationales et internationales qui définissent les obligations réglementaires concernant les informations personnelles. Aux États-Unis, ces réglementations incluent les lois fédérales et nationales suivantes :

  • Sarbanes-Oxley Act de 2002

  • Gramm-Leach-Bliley Act (GLBA) de 1999

  • Health Insurance Portability and Accountability Act (HIPAA) de 1996

  • Family Educational Rights and Privacy Act (FERPA)

  • FDA Title 21 CFR Part 11

  • California Senate Bill 1386

  • Washington Senate Bill 6043

En outre, des réglementations internationales définissent des obligations pour les entreprises qui stockent des informations personnellement identifiables. Ces réglementations sont les suivantes :

  • PIPEDA (Canadian Personal Information Protection and Electronic Documents Act)

  • European Union Data Protection Directive

  • Basel Capital Accord, également connu sous le nom Basel II

Les organisations qui stockent des informations personnelles concernant les clients doivent tenir compte des implications de ces nouvelles réglementations. Ces exigences affectent les opérations de base de données suivantes :

  • Authentification de base de données, notamment les stratégies de mot de passe et les protocoles d'authentification

  • Autorisation de base de données et contrôles d'accès

  • Protection des données sensibles stockées dans une base de données

  • Protection des données sensibles transférées vers ou depuis une base de données

  • Audits des transactions de base de données afin de garantir la confidentialité et l'intégrité des données

Les entreprises doivent se conformer aux obligations réglementaires concernant les informations personnellement identifiables. Pour offrir une protection efficace et rentable des données, les départements informatiques des entreprises peuvent être amenés à reconsidérer la façon dont leurs organisations stockent et gèrent les informations sensibles.

Vue d'ensemble du cryptage des données

Au cours de l'évaluation d'une infrastructure de sécurité, les départements informatiques de l'entreprise peuvent être amenés à réévaluer la sécurité dans leurs organisations. Ces mesures de sécurité peuvent inclure les stratégies de mot de passe, les stratégies d'audit, l'isolation des serveurs de base de données, ainsi que les contrôles d'authentification et d'autorisation des applications. Cependant, la barrière de sécurité finale pour protéger les données sensibles est généralement le cryptage des données.

Le cryptage est un mécanisme qui aide à protéger les données. Le cryptage garantit la confidentialité des données via leur brouillage, de sorte que seules les personnes autorisées puissent y accéder et les lire. Les données sont cryptées lorsque les données originales, appelées texte brut, ainsi qu'une valeur appelée clé, sont passées par une ou plusieurs formules mathématiques. Cette procédure rend les données d'origine illisibles. Les données cryptées qui en résultent sont appelées texte crypté. Pour que les données soient de nouveau lisibles, le destinataire les décrypte en inversant le processus mathématique, avec la clé appropriée.

Ce type de protection des données présente cependant un coût en termes de temps de traitement processeur et d'exigences de stockage. Une clé de cryptage plus longue rend le texte crypté plus sûr que si une organisation utilise une clé de cryptage plus courte. Cependant, cette opération de cryptage/décryptage plus complexe coûte davantage en termes de temps de traitement qu'un cryptage qui utilise une clé de cryptage plus courte. En outre, le cryptage augmente la taille des données cible (cryptées).

Il existe deux grands types de cryptage :

  • Cryptage symétrique. Ce type de cryptage est également appelé cryptage à clé partagée.

  • Cryptage asymétrique. Ce type de cryptage est également appelé cryptage à deux parties ou cryptage à clé publique.


* Avec SQL Server 2005, nous pourrons renforcer la sécurité et crypter les attributs à protéger, tels que les numéros de sécurité sociale et autres informations sensibles. *

David Fahey
Technicien
Microsoft Corporation
Cryptage symétrique

Le cryptage symétrique utilise la même clé pour crypter et pour décrypter les données. Les algorithmes utilisés pour le cryptage symétrique sont plus simples que les algorithmes utilisés pour le cryptage asymétrique. En raison de ces algorithmes plus simples, et parce que la même clé est utilisée à la fois pour crypter et pour décrypter les données, le cryptage symétrique est beaucoup plus rapide que le cryptage asymétrique. Par conséquent, le cryptage symétrique est adapté pour crypter et décrypter une grande quantité de données. La figure 1 illustre le processus de cryptage symétrique.

Figure 1. Processus de cryptage symétrique

Figure 1. Processus de cryptage symétrique

L'un des principaux inconvénients du cryptage symétrique est qu'il utilise la même clé pour crypter et pour décrypter les données. Par conséquent, toutes les parties qui envoient et reçoivent les données doivent connaître la clé de cryptage ou y avoir accès. Cette exigence crée un problème de gestion de la sécurité et des problèmes de gestion des clés, dont l'organisation doit tenir compte dans son environnement. Un problème de gestion de la sécurité existe parce que l'organisation doit envoyer cette clé de cryptage à n'importe quelle partie nécessitant l'accès aux données cryptées. Les problèmes de gestion des clés dont une organisation doit tenir compte sont la génération, la distribution, la sauvegarde, la régénération et le cycle de vie des clés.

Le cryptage symétrique fournit l'autorisation pour les données cryptées. Par exemple, avec le cryptage symétrique, une organisation peut être à peu près sûre que seules les parties autorisées pouvant accéder à la clé de cryptage partagée pourront décrypter le texte. Cependant, le cryptage symétrique n'offre pas la non-répudiation. Par exemple, dans un scénario dans lequel de nombreuses parties peuvent accéder à la clé de cryptage partagée, le cryptage symétrique ne peut pas valider la partie qui envoie les données. Les algorithmes de cryptage utilisés pour le cryptage symétrique sont les suivants :

  • RC2 (128 bits)

  • 3DES (Triple Data Encryption Standard)

  • AES (Advanced Encryption Standard)

Cryptage asymétrique

Le cryptage asymétrique utilise deux clés de cryptage différentes, mais mathématiquement liées, pour crypter et décrypter les données. Ces clés sont appelées clé privée et clé publique. Ensemble, ces clés constituent une paire de clés. Le cryptage asymétrique est considéré comme plus sûr que le cryptage symétrique, car une clé différente est utilisée pour le cryptage des données et pour leur décryptage. Cependant, étant donné que le cryptage asymétrique utilise des algorithmes plus complexes que le cryptage symétrique, et étant donné que le cryptage asymétrique utilise une paire de clés, le processus de cryptage est plus lent lorsqu'une organisation utilise le cryptage asymétrique que lorsqu'elle utilise le cryptage symétrique. La figure 2 illustre le processus de cryptage asymétrique.

Figure 2. Processus de cryptage asymétrique

Figure 2. Processus de cryptage asymétrique

Avec le cryptage asymétrique, une seule partie détient la clé privée. Cette partie est appelée sujet. Toutes les autres parties peuvent accéder à la clé publique. Les données cryptées via la clé publique ne peuvent être décryptées que via la clé privée. À l'inverse, les données cryptées via la clé privée ne peuvent être décryptées que via la clé publique. Par conséquent, ce type de cryptage offre à la fois la confidentialité et la non-répudiation.

Une organisation peut utiliser ce type de cryptage pour offrir l'autorisation en utilisant la clé publique pour crypter les données. Cette clé est publiquement disponible. Par conséquent, n'importe qui peut crypter les données. Cependant, étant donné que seul le sujet détient la clé privée, l'organisation est à peu près sûre que seul le destinataire prévu pourra décrypter et afficher les données cryptées.

Une organisation peut utiliser ce type de cryptage pour offrir l'authentification en utilisant la clé privée pour crypter les données. Seul le sujet détient cette clé. Par conséquent, toute personne peut décrypter les données, car la clé publique qui décrypte ces données est disponible publiquement. Ainsi, si le destinataire peut décrypter ces données à l'aide de la clé publique, il est à peu près certain que seul le sujet a crypté les données. Les algorithmes de cryptage utilisés pour le cryptage asymétrique sont les suivants :

  • Contrat de clé Diffie-Hellman

  • RSA (Rivest-Shamir-Adleman)

  • DSA (Digital Signature Algorithm)

Cryptage hybride

Le cryptage hybride est un schéma de cryptage dans lequel le cryptage des données est effectué via une combinaison de cryptage symétrique et de cryptage asymétrique. Une méthode de cryptage hybride tire parti des atouts des deux types de cryptage afin de garantir que seul le destinataire prévu peut lire les données.

Dans un scénario de cryptage hybride, une organisation crypte les données en utilisant le cryptage symétrique avec une clé générée de manière alétoire. Cette étape tire parti de la vitesse du cryptage symétrique. Ensuite, l'organisation crypte la clé de cryptage symétrique en utilisant la clé publique d'une paire de clés asymétrique. Cette étape tire parti de la sécurité renforcée du cryptage asymétrique. Les données cryptées et la clé symétrique cryptée sont envoyées au destinataire. La figure 3 illustre le processus de cryptage hybride.

Figure 3. Processus de cryptage hybride

Figure 3. Processus de cryptage hybride

Pour décrypter les données, le destinataire commence par utiliser la clé privée de la paire de clés asymétrique pour décrypter la clé symétrique. Ensuite, le destinataire utilise la clé symétrique décryptée pour décrypter les données. La figure 4 illustre le processus de décryptage hybride.

Figure 4. Processus de décryptage hybride

Figure 4. Processus de décryptage hybride

Considérations relatives au cryptage

Lorsqu'une organisation décide de crypter ou non des données, elle doit tenir compte de l'augmentation de la charge processeur liée au cryptage et au décryptage. Elle doit également tenir compte de l'augmentation de l'espace de stockage pour les données cryptées. La quantité d'espace consommé par les données dépend de l'algorithme utilisé, de la taille de la clé, ainsi que de la taille du texte clair crypté par l'organisation.

Bien qu'une organisation doive tenir compte à la fois des problèmes de performance et des problèmes de stockage lors de l'implémentation du cryptage, le problème le plus important est la gestion des clés. Les clés de cryptage utilisées par une organisation pour crypter et pour décrypter les données sont une partie essentielle de l'infrastructure de sécurité des données. Pour garantir que seuls les utilisateurs autorisés peuvent afficher les données cryptées, l'organisation doit implémenter des mesures pour gérer, stocker, protéger et sauvegarder les clés de cryptage.

Environnement de l'application

Microsoft IT fournit à Microsoft des services informatiques globaux. Ces services incluent des services de support pour 57 000 employés, plus de 200 000 ordinateurs personnels et plus de 8 000 serveurs. Ces services vont des opérations serveur et réseau au déploiement de logiciels, en passant par le support technique pour les utilisateurs. En outre, Microsoft IT traite plus de 100 000 problèmes de sécurité chaque mois.

Microsoft IT compte plus de 300 applications métier qui gèrent des données sensibles pour les opérations quotidiennes de l'entreprise. L'objectif de Microsoft IT est d'améliorer la sécurité des données lors du stockage, de la transmission, du traitement ou de l'affichage des données dans des systèmes ou rapports, via les applications métier. Ainsi, Microsoft IT procède actuellement à la mise à niveau vers SQL Server 2005 de toutes ses applications métier utilisant des bases de données. Cette mise à niveau tire parti des nouvelles fonctionnalités de gestion, de sécurité et de performance de SQL Server 2005.

Microsoft IT a analysé (et continue d'analyser) ses solutions de stockage de base de données en réponse aux exigences suivantes :

  • Exigences réglementaires pour protéger la vie privée des employés, clients et partenaires

  • Exigences de sécurité des informations d'entreprise de Microsoft concernant les informations personnelles hautement sensibles, telles que les informations personnelles sur les employés et les partenaires

Ce document étudie les infrastructures de cryptage que Microsoft IT a développées et continue de développer pour les trois systèmes de base de données suivants inclus dans l'analyse :

  • Le référentiel d'informations central de 2 téraoctets, nommé FeedStore, dans le groupe Enterprise Data Services

  • Le data warehouse PCRS dans Financial IT

  • La base de données des outils de service et de support Metropolis dans Services IT

Dans la mesure où différentes quantités de données sont impliquées, où différentes applications sont impliquées et où les environnements de base de données particuliers diffèrent, les départements informatiques qui géraient ces systèmes de base de données chez Microsoft IT ont dû développer différentes stratégies de cryptage et différents processus d'implémentation au cours de leur analyse de l'environnement d'application particulier dont ils assuraient la gestion. Cependant, l'utilisation de SQL Server 2005 pour implémenter une hiérarchie de gestion des clés et le cryptage au niveau colonne était commune à ces stratégies.

Solution : le cryptage SQL Server 2005

SQL Server 2005 inclut de nombreuses fonctionnalités liées à la sécurité, qui contribuent à la protection des données d'une organisation. SQL Server 2005 inclut l'application de la stratégie de mot de passe, une fonctionnalité d'authentification renforcée et un modèle d'autorisation hiérarchique granulaire. SQL Server 2005 inclut également une fonctionnalité intégrée de cryptage de données. Cette fonctionnalité de cryptage au niveau colonne est améliorée par une infrastructure intégrée et hiérarchique de gestion des clés de cryptage. Les fonctions de cryptage et API (Application Programming Interfaces) intégrées facilitent la création d'un environnement de sécurité de cryptage par l'organisation.


* Avec le cryptage SQL Server 2005 intégré, vous n'avez pas à vous préoccuper du fonctionnement du processus en arrière-plan. Il vous suffit d'appeler la fonction de cryptage pour crypter les données. *

Devendra Tiwari
Architecte
Microsoft Corporation

Fonctionnalités de cryptage intégrées

La gestion des clés est l'élément le plus important d'une infrastructure de sécurité de cryptage. SQL Server 2005 prend en charge trois types de cryptage. Chaque type utilise un type de clé distinct, et chaque type présente plusieurs algorithmes de cryptage et niveaux de clé :

  • Cryptage symétrique : SQL Server 2005 prend en charge les familles d'algorithmes de cryptage RC4, RC2, DES et AES.

  • Cryptage asymétrique : SQL Server 2005 prend en charge l'algorithme de cryptage RSA avec les niveaux de clé 512 bits, 1 024 bits et 2 048 bits.

  • Certificats : L'utilisation des certificats est une autre forme de cryptage asymétrique. Cependant, une organisation peut utiliser un certificat pour associer un ensemble de clés publiques et privées à leur propriétaire, à l'aide d'une signature numérique. SQL Server 2005 prend en charge la spécification IETF (Internet Engineering Task Force) X.509 version 3 (X.509v3). Une organisation peut utiliser des certificats générés en externe avec SQL Server 2005, ou générer des certificats à l'aide de SQL Server 2005.

Hiérarchie des clés de cryptage

SQL Server 2005 implémente une infrastructure afin de contribuer à la protection des clés de cryptage à l'aide d'une hiérarchie de clés de cryptage, comme illustré figure 5. Dans cette hiérarchie, chaque couche crypte les couches situées en dessous.

Figure 5. Hiérarchie des clés de cryptage SQL Server 2005

Figure 5. Hiérarchie des clés de cryptage SQL Server 2005

DPAPI (Data Protection API) se situe au sommet de cette hiérarchie de clés de cryptage. DPAPI est une paire d'appels de fonction fournissant des services de protection de données de niveau système d'exploitation aux processus utilisateur et système. Dans la mesure où cette API fait partie du système d'exploitation Microsoft Windows®, les applications peuvent utiliser DPAPI pour crypter les données, mais n'ont pas besoin d'utiliser de code cryptographique autre que le code qui appelle les fonctions DPAPI. DPAPI est un service de protection des données basé sur les mots de passe. Par conséquent, DPAPI nécessite un mot de passe pour crypter les données.

Remarque : Le mot de passe utilisé ici est celui du compte qui appelle la fonctionnalité de cryptage. Par conséquent, un développeur qui implémente le cryptage n'a pas besoin de spécifier un mot de passe supplémentaire.

La clé principale du service SQL Server 2005 est une clé symétrique générée automatiquement par la fonction cryptGenKey lorsqu'un administrateur installe SQL Server 2005. DPAPI utilise le mot de passe du compte sous lequel SQL Server 2005 s'exécute pour générer une clé avec laquelle DPAPI crypte la clé principale du service. Par conséquent, si un administrateur change le compte de service sous lequel SQL Server 2005 s'exécute, il doit décrypter la clé principale du service en utilisant les informations d'identification d'origine. Il doit ensuite crypter la clé principale du service en utilisant les nouvelles informations d'identification. Nous recommandons vivement aux administrateurs de ne changer le compte de service sous lequel SQL Server 2005 s'exécute qu'avec l'outil Gestionnaire d'ordinateurs de SQL Server 2005. Cet outil effectue automatiquement la procédure requise pour décrypter la clé principale du service, puis pour la recrypter.

Remarque : Un administrateur n'a pas besoin d'effectuer ces actions s'il change uniquement le mot de passe du compte de service. Ces actions ne doivent être effectuées que si le compte de service réel sous lequel s'exécute SQL Server 2005 est changé.

La clé principale du service crypte la clé principale de la base de données. La clé principale de la base de données est requise dans chaque base de données où une organisation crypte des données. Cette clé offre les mêmes fonctionnalités que la clé principale du service. En revanche, la fonctionnalité est exécutée au niveau base de données plutôt qu'au niveau instance SQL Server 2005.

La clé principale de la base de données est une clé symétrique. Elle n'est pas créée automatiquement lorsqu'une nouvelle base de données SQL Server 2005 est créée. Par conséquent, le développeur doit créer cette clé explicitement pour implémenter le cryptage dans une base de données.

La clé principale de la base de données crypte les clés utilisateur créées par un développeur. Ces clés utilisateur incluent les certificats et les clés asymétriques. Les certificats et clés asymétriques cryptent à leur tour les clés symétriques créées par le développeur.

Remarque : Un développeur peut également utiliser des certificats et des clés asymétriques pour crypter directement les données. Cependant, les certificats et les clés asymétriques sont surtout adaptées au cryptage des petites quantités de données.

Un développeur peut utiliser des clés symétriques pour crypter d'autres clés symétriques qu'il crée, ou pour crypter des données Cette hiérarchie des clés de cryptage est particulièrement importante lorsque le développeur détermine le type de clé à utiliser pour crypter les clés nouvellement créées. L'infrastructure des clés de cryptage SQL Server 2005 offre au développeur une large flexibilité pour créer une hiérarchie simple ou complexe de clés de cryptage pour chaque base de données qu'il crée. Il est cependant recommandé que le développeur crée la structure de clé la plus simple possible autorisée par son organisation.

Remarque : Un développeur peut également crypter la clé privée d'un certificat ou une clé symétrique en spécifiant un mot de passe. Cependant, cette méthode est généralement mieux adaptée à un environnement dans lequel il est acceptable pour les applications ou les utilisateurs de connaître la méthode de cryptage utilisée, ainsi que les clés de cryptage utilisées. Cette méthode ne convient pas lorsque le processus de cryptage doit être transparent pour les utilisateurs.

Clés de cryptage

Le processus de cryptage et de décryptage nécessite les clés suivantes.

Certificat

Un certificat est un moyen d'utiliser le cryptage asymétrique. Un certificat est un objet de sécurité signé numériquement, qui lie la valeur de la clé publique à l'utilisateur, au périphérique ou au service détenant la clé privée correspondante. Une autorité de certification émet et signe les certificats. Les certificats créés par SQL Server 2005 sont conformes à la norme de certification IETF X.509v3. En général, un développeur utilise un certificat pour crypter d'autres types de clés de cryptage dans une base de données.

Clé asymétrique

Une clé asymétrique est constituée d'une clé privée et de la clé publique correspondante. Chacune de ces clés peut décrypter les données cryptées par l'autre clé. En général, un développeur utilise un cryptage asymétrique pour crypter une clé symétrique pour le stockage dans une base de données. Dans SQL Server 2005, les clés asymétriques sont des paires de clés publiques et privées. La clé publique ne présente pas de format particulier, comme un certificat, et le développeur ne peut pas l'exporter vers un fichier.

Dans SQL Server 2005, les certificats et les clés symétriques ont des rôles interchangeables. Un développeur peut crypter des clés asymétriques en utilisant les deux méthodes suivantes :

  • Une clé utilisateur dérivée d'un mot de passe fourni par l'utilisateur

  • La clé principale de la base de données

Clé symétrique

Une clé symétrique est une clé unique utilisée pour le cryptage et le décryptage. Les opérations de cryptage et de décryptage sont rapides avec le cryptage symétrique. Par conséquent, le cryptage symétrique est bien adapté au cryptage d'une grande quantité de données dans SQL Server 2005.

Dans SQL Server 2005, un développeur peut crypter une clé symétrique en utilisant une ou plusieurs des méthodes suivantes :

  • La clé publique d'un certificat

  • Un mot de passe fourni par l'utilisateur

  • Une autre clé symétrique

  • Une clé asymétrique

    Remarque : La clé symétrique n'est pas stockée dans la base de données. Seules les valeurs cryptées de la clé symétrique sont stockées dans la base de données. Par conséquent, les utilisateurs qui peuvent accéder à la base de données ne peuvent pas décrypter les données sans avoir au préalable décrypté la clé symétrique.

Si un développeur crypte les clés symétriques en utilisant d'autres clés symétriques, il doit ouvrir les clés dans l'ordre approprié. L'ordre correct est le suivant : des niveaux supérieurs de la hiérarchie de cryptage aux niveaux inférieurs, un niveau à la fois. Le développeur doit suivre l'ordre approprié, car il ne peut pas ouvrir et décrypter une clé symétrique sans d'abord ouvrir et décrypter la clé avec laquelle la clé particulière a été cryptée. Les développeurs doivent tenir compte de cet ordre lorsqu'ils conçoivent la hiérarchie des clés de cryptage dans la base de données.

FeedStore

FeedStore est une application interne créée par le groupe Enterprise Data Services. Cette application extrait des données de 39 sources internes et génère des données pour environ 500 applications abonnées à travers le monde. FeedStore reçoit les données via les méthodes suivantes :

  • Serveurs liés

  • Partenaires de réplication

  • Fichiers plats

FeedStore traite ces données afin de créer des jeux de données normalisés à envoyer aux serveurs de distribution. Ces informations sont transmises en tant que tables complètes ou partielles aux applications abonnées, par l'intermédiaire des méthodes suivantes :

  • Une application interne personnalisée dans le réseau d'entreprise de Microsoft

  • La réplication par émission SQL Server dans le réseau extranet Microsoft

Enterprise Data Services a constaté que des données sensibles étaient dupliquées dans l'espace des applications métier de Microsoft IT pendant l'activité. Par exemple, des données sont envoyées à FeedStore. FeedStore envoie ces données à environ 500 abonnés. Ensuite, les applications métier de Microsoft IT extraient les données de ces abonnés. En raison de ce processus, une copie des données sensibles réside dans FeedStore, et une autre copie réside dans l'abonné local. La figure 6 illustre le flux des données entre les applications au sein de Microsoft IT.

Figure 6. Flux des données entre les applications au sein de Microsoft IT

Figure 6. Flux des données entre les applications au sein de Microsoft IT

En outre, Enterprise Data Services a constaté que les données étaient dupliquées de la façon suivante : des données métier sont envoyées à SAP, FeedStore et d'autres bases de données. Ces bases de données consolident les données dans un autre data warehouse à partir duquel les données sont exportées vers FeedStore et vers d'autres bases de données. De nombreuses applications métier accèdent à ces données à partir de bases de données autres que FeedStore. De plus, FeedStore distribue ces données vers d'autres emplacements. Dans chacun de ces processus, les données sont stockées dans plusieurs emplacements, puis copiées vers plusieurs emplacements. Les données se déplacent entre les bases de données SQL Server, les fichiers plats et d'autres banques propriétaires. À partir de ces emplacements, les processus batch, applications et utilisateurs peuvent accéder à ces données.

Enterprise Data Services a constaté qu'une même donnée peut être utilisée par un groupe d'utilisateurs différent ou sous un ou plusieurs comptes utilisateur à un endroit donné du système. Par exemple, une application peut utiliser un sous-système approuvé pour accéder aux données. Dans ce scénario, une application peut autoriser un utilisateur à accéder à une donnée particulière. Cependant, une fois que l'utilisateur a été autorisé avec succès, l'application extrait les données appropriées en utilisant les informations d'identification du compte de service sous lequel cette application particulière s'exécute. La figure 7 illustre ce processus d'autorisation.

Figure 7. Exemple de processus d'autorisation

Figure 7. Exemple de processus d'autorisation

Stratégie FeedStore

Enterprise Data Services a constaté que, comme dans nombre d'autres environnements d'entreprise, les données sensibles étaient dupliquées et stockées dans plusieurs emplacements de l'espace des applications métier. Une réponse initiale à ce type de découverte peut être d'appliquer le cryptage à chaque emplacement qui héberge ces données sensibles. Cette action offre un niveau élevé de sécurité aux données sensibles. Cependant, le coût du cryptage de chaque bit de ces données dans chaque emplacement de stockage serait énorme.

Enterprise Data Services a déterminé que la consolidation et le cryptage des données sensibles dans une banque distincte serait la stratégie la meilleure et la plus efficace pour se mettre en conformité avec les exigences réglementaires et les exigences de sécurité informatique de Microsoft. Cette stratégie implique la consolidation et la suppression des données.

Consolidation des données

La consolidation des données sensibles dans une banque centrale contribue à réduire la duplication des données. En outre, le fait de disposer de toutes les données sensibles dans une banque unique facilite l'application d'une infrastructure de cryptage à ces données. Via l'utilisation d'une banque centrale pour les données sensibles, tous les problèmes liés à la sécurité, tels que la gestion des clés, l'autorisation, l'authentification et l'audit, sont gérés dans un emplacement central unique. Par conséquent, Microsoft IT n'a pas besoin d'apporter des changements de base de données majeurs à chaque application métier traitant des données sensibles pour crypter ces données localement. La figure 8 illustre le flux de données proposé par Enterprise Data Services pour protéger les données sensibles dans l'espace des applications métier de Microsoft IT.

Figure 8. Flux des données proposé entre les applications au sein de Microsoft IT

Figure 8. Flux des données proposé entre les applications au sein de Microsoft IT

Suppression de données

Microsoft IT examine les applications métier afin de déterminer si ces applications nécessitent l'accès à des données sensibles. Pour les applications qui ne nécessitent pas d'accès à des données sensibles, Microsoft IT reconfigure le flux afin de supprimer les données sensibles. Ce processus est non seulement moins coûteux que le cryptage des données, mais il applique également la stratégie de sécurité du moindre privilège, ce qui permet de garantir que l'accès aux données sensibles n'a lieu que si nécessaire. Le processus de modification de tout ou partie des applications métier de Microsoft IT pour supprimer tout ou partie des informations personnelles est déjà en cours au sein de Microsoft IT.

Pour les applications qui nécessitent l'accès à des données sensibles, Enterprise Data Services a constaté que le cryptage de ces données dans l'application locale serait plus coûteux que la reconfiguration de l'application pour obtenir les données sensibles à partir d'une banque cryptée distincte. Cependant, dans certains cas, l'application ne peut pas être reconfigurée pour obtenir les données sensibles à partir d'une banque distincte. Dans ce scénario, l'application métier doit être reconfigurée pour crypter localement les données sensibles.

Le défi d'une stratégie de consolidation des données consiste à préserver la disponibilité des données sensibles. Enterprise Data Services a dû relever les défis suivants :

  • Les départements BUIT (Business Unit IT) de Microsoft IT présentent des exigences spécifiques en termes de performances et de tolérance aux pannes. Une banque cryptée centralisée doit être suffisamment réactive et doit offrir une disponibilité élevée pour répondre à ces besoins.

  • La charge processeur accrue requise par le cryptage peut ralentir les processus au point qu'une banque cryptée centralisée devient inutilisable.

  • Les départements BUIT de Microsoft IT doivent modifier leurs applications afin d'obtenir les informations personnelles hautement sensibles à partir de la banque cryptée centralisée.

  • Il peut ne pas être possible de modifier chaque application métier afin d'utiliser une banque cryptée centralisée. Les applications métier peuvent exécuter certains processus dans lesquels des informations personnelles hautement sensibles sont stockées et copiées vers plusieurs emplacements en vue de leur traitement.

  • Une banque cryptée centralisée doit fournir des mécanismes de cryptage, de décryptage, d'authentification, d'autorisation, de conservation des données et de récupération de données.

Pilote Digital Asset Store

Comme point de départ pour améliorer la conformité aux réglementations et aux stratégies de sécurité de l'entreprise, Enterprise Data Services a développé un projet pilote afin de créer une banque cryptée centralisée en utilisant les nouvelles fonctionnalités de cryptage de SQL Server 2005. Enterprise Data Services a nommé cette banque centralisée Digital Asset Store. L'objectif du service Digital Asset Store est l'intégration à l'application FeedStore afin de faciliter la suppression des informations personnelles hautement sensibles de l'application FeedStore et de renforcer la sécurité des données sensibles dans l'espace des applications métier de Microsoft IT.

Enterprise Data Services a déterminé que même en version bêta, SQL Server 2005 était suffisamment robuste et offrait les fonctionnalités requises pour satisfaire aux exigences du service Digital Asset Store. Enterprise Data Services a constaté que les solutions de cryptage personnalisées existantes étaient trop coûteuses ; des millions de dollars étaient consacrés à des solutions personnalisées difficilement réutilisables. En outre, Enterprise Data Services a constaté que les solutions de cryptage tierces existantes étaient trop coûteuses, non seulement en termes financiers, mais également en termes d'intégration, de maintenance et de support.

Exigences métier

Avant que le groupe Enterprise Data Services n'implémente le pilote Digital Asset Store, le groupe a créé une série d'exigences métier. Ces exigences répertoriaient les objectifs du groupe Enterprise Data Services pour déterminer la réussite ou non du pilote Digital Asset Store. Enterprise Data Services avait les objectifs suivants pour le service Digital Asset Store :

  • Offrir des services de cryptage, de décryptage, d'authentification et d'autorisation, ainsi que des services de conservation des données et de récupération de données.

  • Offrir une méthode pour alimenter les champs lors des échanges de documents avec des données sensibles entre entreprises. Cette méthode est également appelée conversion en ligne.

  • Proposer un plan de migration pour le déplacement des données sensibles vers Digital Asset Store.

Enterprise Data Services a également défini les objectifs métier suivants pour Digital Asset Store :

  • Faire en sorte que les budgets Microsoft IT pour les applications métier incluent la migration des informations personnelles hautement sensibles vers Digital Asset Store.

  • Réduire le coût de la migration des informations personnelles hautement sensibles vers Digital Asset Store. En particulier, réduire ce coût à moins que le coût du cryptage local des données dans chaque application métier de Microsoft IT. Ainsi, Enterprise Data Services a fixé un objectif de coût d'environ 10 000 $ ou moins pour modifier chaque application métier afin qu'elle puisse utiliser Digital Asset Store.

Pour déterminer les informations à déplacer vers Digital Asset Store, Enterprise Data Services devait commencer par classer les informations actuelles dans un contexte lié à la sécurité. Étant donné les coûts liés au déplacement et au cryptage des données, Microsoft et les autres entreprises doivent déterminer soigneusement les informations suffisamment sensibles pour nécessiter un cryptage.

La création d'une banque cryptée distincte pour héberger les données sensibles nécessite une planification et une surveillance soigneuses pour garantir la disponibilité des données sensibles pour les applications qui en ont besoin. Les données sensibles doivent rester dans le data warehouse non crypté jusqu'à ce que les applications abonnées puissent être modifiées afin d'obtenir ces données à partir de la banque cryptée.

Remarque : Dans certains cas, une application métier particulière ne peut pas être reconfigurée pour obtenir les données sensibles à partir d'une banque cryptée. Dans ce scénario, l'application métier doit être reconfigurée pour utiliser des fonctionnalités telles que le cryptage de niveau colonne de SQL Server 2005 pour crypter localement les données sensibles.

Implémentation

Enterprise Data Services a constaté que les fonctionnalités de sécurité de SQL Server 2005 permettraient de garantir la réussite du projet pilote Digital Asset Store. Pour implémenter Digital Asset Store, Enterprise Data Services a déterminé que les actions suivantes seraient nécessaires dans l'espace des applications métier de Microsoft IT concernant FeedStore :

  • Identification des données sensibles présentes dans l'espace des applications métier.

  • Suppression des données sensibles à partir des applications métier qui ne nécessitent pas ces informations.

  • Déplacement des informations personnelles hautement sensibles vers Digital Asset Store.

  • Cryptage des informations personnelles hautement sensibles dans Digital Asset Store.

  • Protection des informations personnelles sensibles lors de leur déplacement entre les applications.

Pour implémenter le service Digital Asset Store, Enterprise Data Services a constaté que les éditeurs devraient être configurés pour envoyer des données sensibles à Digital Asset Store. Cependant, les éditeurs continuent d'envoyer des données non sensibles à FeedStore.

FeedStore reçoit les flux de données via la réplication, les opérations d'extraction SQL Server provenant des serveurs liés, ainsi que les opérations de sélection dans les emplacements de fichiers plats. Digital Asset Store permet le cryptage des données au repos (données qui ne font l'objet ni d'un transfert, ni d'un accès) dans Digital Asset Store. Cependant, les données sensibles sont également conservées dans un emplacement de fichier plat actuellement utilisé pour envoyer les données à Digital Asset Store. Enterprise Data Services a déterminé qu'un emplacement de fichier plat présente un lien inacceptable dans le transfert des données vers Digital Asset Store. La figure 9 illustre l'emplacement du fichier plat dans la structure actuelle de flux de données FeedStore.

Figure 9. Structure actuelle de flux de données FeedStore

Figure 9. Structure actuelle de flux de données FeedStore

Plutôt que de développer une méthode pour crypter les données des fichiers plats, Enterprise Data Services a décidé d'autoriser uniquement une méthode de transfert de données entre bases. Dans ce scénario, Digital Asset Store obtient les données via un mécanisme de transport de données permettant d'obtenir des données uniques plus petites, au lieu des grands jeux de données des transports vers FeedStore. La figure 10 illustre la structure de flux de données proposée pour Digital Asset Store.

Figure 10. Structure de flux de données proposée pour Digital Asset Store

Figure 10. Structure de flux de données proposée pour Digital Asset Store


* Les fonctionnalités de sécurité et de cryptage de SQL Server 2005 permettent à Microsoft IT d'implémenter facilement une infrastructure de cryptage sans avoir à se soucier de la gestion des clés de cryptage. *

Devendra Tiwari
Architecte
Microsoft Corporation

Les fonctionnalités de cryptage de SQL Server 2005 sont conçues pour crypter les données au repos. Les données stockées dans la banque Digital Asset Store sont cryptées. Les transferts de données entre les applications et Digital Asset Store sont effectués via le passage des données décryptées (texte clair) via un tunnel non crypté. Microsoft IT a constaté que cette approche est recommandée pour le transfert de données entre des bases de données. Dans cette approche, les clés de cryptage ne sont pas partagées entre les systèmes. En outre, les données au repos sont cryptées via l'infrastructure de cryptage présente dans chaque système. La figure 11 illustre ce transfert de données.

Figure 11. Méthode recommandée pour transférer les données sensibles

Figure 11. Méthode recommandée pour transférer les données sensibles

Dans la figure 11, les données en texte clair sont transférées via un canal crypté entre deux ordinateurs qui exécutent SQL Server 2005. Dans cette situation, les actions suivantes ont lieu :

  1. Les données stockées (données au repos) sur le Serveur 1 sont cryptées via la clé de cryptage 1.

  2. Ces données sont décryptées via la clé 1 avant que les données ne soient transférées via un canal crypté vers le serveur 2.

  3. Les données sont cryptées sur le serveur 2 via une clé de cryptage (clé 2) générée par le serveur 2.

Pour effectuer ces actions via un processus qui s'exécute sur le serveur 2, le processus particulier doit décrypter les données sur le serveur 1 en utilisant la clé 1, copier les données décryptées vers le serveur 2, puis crypter les données du serveur 2 avec la clé 2. Pour effectuer ces actions, le compte sous lequel s'exécute le processus doit disposer de tous les droits utilisateur suivants :

  • Afficher les définitions des clés pour crypter et décrypter les données

  • Afficher les définitions des certificats pour crypter et décrypter les données

  • Contrôler les autorisations sur le certificat pour décrypter les données

    Remarque : Le cryptage SQL Server 2005 est conçu pour crypter les données au repos. Par conséquent, si une organisation décide de transférer du texte crypté entre des ordinateurs qui exécutent SQL Server 2005, elle ne doit pas utiliser le cryptage SQL Server 2005 comme seule infrastructure de sécurité pour les données en transit. L'organisation doit également utiliser d'autres méthodes pour protéger ces données transmises, par exemple IPSec (Internet Protocol security) ou SSL (Secure Sockets Layer). Bien que SQL Server 2005 offre un cryptage robuste, les données en transit sont sujettes aux attaques, telles que les attaques d'analyse statistique, les attaques cryptoanalytiques ou les attaques de réponse. Par conséquent, nous recommandons aux organisations de crypter le canal de transport, même si les données transférées sont cryptées.

Les abonnés FeedStore doivent être modifiés pour obtenir des informations personnelles hautement sensibles à partir de Digital Asset Store. Pour limiter la duplication des données et pour suivre le principe de sécurité du moindre privilège, Enterprise Data Services a déterminé qu'il fallait implémenter une procédure très performante pour insérer les données sensibles dans un flux de données lors de l'exécution. Enterprise Data Services a donc développé une technique appelée conversion en ligne. Lors de la conversion en ligne, les actions suivantes ont lieu :

  1. Recherche de données, telles que les numéros de sécurité sociale, dans un flux entrant en fonction de clés telles que les numéros de personnel.

  2. Décryptage des données.

  3. Insertion de ces données dans le flux.

Par exemple, une application peut générer un flux de données contenant des numéros de sécurité sociale. Ce flux de données est envoyé à une institution financière tierce. Cependant, l'environnement qui génère ce flux de données peut ne pas nécessiter d'accès aux numéros de sécurité sociale. Dans ce cas, le numéro de sécurité sociale ne doit pas exister dans l'environnement qui génère le flux si le numéro peut être inséré dans le flux vers l'institution financière tierce. La conversion en ligne limite le nombre de cas dans lesquels des données sensibles peuvent faire l'objet d'un accès, être stockées et être transmises. En outre, la conversion en ligne utilise une banque cryptée distincte pour stocker les données sensibles.

Processus de cryptage Digital Asset Store

Enterprise Data Services a déterminé que Digital Asset Store utiliserait un mécanisme de cryptage hybride. Par conséquent, les données envoyées à Digital Asset Store seront cryptées via le cryptage intégré à SQL Server 2005 et une clé symétrique. Ensuite, SQL Server 2005 crypte cette clé symétrique avec le cryptage basé sur les certificats. La figure 12 illustre le processus de cryptage Digital Asset Store tel que Enterprise Data Services prévoit de l'implémenter.

Figure 12. Processus de cryptage Digital Asset Store

Figure 12. Processus de cryptage Digital Asset Store

Pour transférer les données de Digital Asset Store vers un abonné ou vers le traitement des abonnés, le processus de cryptage est inversé. SQL Server 2005 décrypte la clé symétrique en utilisant le cryptage basé sur les certificats. SQL Server 2005 décrypte ensuite les données avec la clé symétrique décryptée. Les données décryptées sont ensuite traitées par un processus abonné, puis supprimées, ou les données décryptées sont envoyées à un abonné via un canal crypté. L'abonné crypte ensuite ces données en utilisant le cryptage SQL Server 2005 intégré. La figure 13 illustre le processus de décryptage Digital Asset Store tel que Enterprise Data Services prévoit de l'implémenter.

Figure 13. Processus de décryptage Digital Asset Store

Figure 13. Processus de décryptage Digital Asset Store

L'implémentation du projet pilote Digital Asset Store a fourni à Microsoft IT des informations d'implémentation précieuses pour d'autres projets de cryptage et de consolidation de données dans l'espace des applications métier de Microsoft IT. SQL Server 2005 fournit à Microsoft IT des améliorations de protocole pour l'authentification, des autorisations granulaires améliorées, ainsi qu'un mécanisme de cryptage intégré pour préserver la confidentialité et l'intégrité des données sensibles.

Application PCRS (Payroll Controls Reporting System)

Les employés Microsoft basés aux États-Unis utilisent l'application PCRS pour générer la comptabilité des payes, les opérations de paye et les rapports liés aux bénéfices.

L'application PCRS est essentiellement un data warehouse de paye. Cette base de données contient 350 gigaoctets (Go) de données et contient les informations de paye de tous les employés Microsoft basés aux États-Unis. PCRS utilise quasi-quotidiennement des travaux batch pour obtenir des informations à partir de FeedStore et SAP. PCRS stocke ces informations dans une base de données, calcule des valeurs à partir de ces données, puis alimente la base de données de création de rapports PCRS en utilisant ces valeurs calculées. Une fois que les valeurs calculées ont été stockées dans la base de données des rapports, l'équipe Microsoft en charge de la comptabilité et des payes peut créer des rapports de paye à l'aide de programmes tels que Microsoft Access ou Microsoft Excel®. La figure 14 illustre le flux des données dans PCRS.

Figure 14. Flux de données de l'application PCRS (Payroll Controls Reporting System)

Figure 14. Flux de données de l'application PCRS (Payroll Controls Reporting System)

Stratégie PCRS (Payroll Controls Reporting System)

Pour garantir la conformité avec les nouvelles réglementations concernant les informations personnelles, et avec les exigences de sécurité de Microsoft, le département Financial IT a déterminé que l'application PCRS devrait être modifiée pour utiliser le cryptage SQL Server 2005 afin de protéger les données sensibles. En outre, étant donné que PCRS reçoit des données sensibles provenant de diverses sources, et dans la mesure où un traitement complémentaire doit être effectué sur ces données sensibles, Financial IT a déterminé que le cryptage devrait être implémenté dans la base de données PCRS plutôt que dans une banque cryptée distincte.

Seul un petit nombre de colonnes de la base de données PCRS nécessitait un cryptage. Cependant, la stratégie de cryptage de Financial IT impliquait également la création d'une structure SQL Server 2005 de gestion des clés, ainsi que la modification des procédures stockées pour accéder aux données cryptées dans PCRS. Financial IT ne pensait pas que la modification de l'application PCRS pour inclure le cryptage SQL Server 2005 de niveau colonne serait une procédure complexe. En revanche, Financial IT était préoccupé par la sauvegarde, la restauration et la maintenance permanente de la hiérarchie des clés de cryptage SQL Server 2005. Ainsi, avant d'implémenter cette stratégie dans un environnement de production, Financial IT a implémenté un prototype de base de données afin de tester et de garantir la réussite de la sauvegarde, de la maintenance et de la restauration des clés de cryptage SQL Server 2005. En outre, étant donné que l'indexation ne fonctionne pas sur les colonnes cryptées, Financial IT devait localiser et supprimer les index des colonnes nécessitant le cryptage.

Pilote PCRS (Payroll Controls Reporting System)

Le département Financial IT a fixé une date pour l'implémentation du cryptage SQL Server 2005 de niveau colonne dans l'application PCRS. Cependant, avant l'implémentation de cette solution de cryptage dans l'environnement de production, Financial IT a créé un prototype de base de données contenant des données cryptées, afin de s'assurer que la hiérarchie des clés de cryptage SQL Server 2005 pourrait être sauvegardée, restaurée et gérée dans l'environnement de production.

Financial IT a créé un exemple de base de données nommé PCRS_Encryption afin de tester la stratégie de cryptage de l'application PCRS. Cette base de données contenait des données sensibles, ainsi que des procédures stockées pour envoyer les données sensibles à la base et pour extraire les données sensibles de la base. L'accès à la base de données était basé sur la sécurité SQL Server 2005 basée sur les rôles. La figure 15 illustre cette architecture de base de données.

Figure 15. Base de données PCRS (Payroll Controls Reporting System)

Figure 15. Base de données PCRS (Payroll Controls Reporting System)

Pour implémenter et tester cette configuration de base de données, Financial IT a utilisé la procédure suivante pour créer une hiérarchie de clés de cryptage SQL Server 2005 simple mais robuste :

  1. Création de la clé principale de la base de données.

  2. Régénération de la clé principale du service. Cette étape constitue une mesure de sécurité supplémentaire, permettant de garantir que la clé principale du service n'a pas été compromise.

  3. Création d'un certificat SQL Server 2005 signé personnellement.

  4. Création d'une clé symétrique. Cryptage de cette clé à l'aide du certificat SQL Server 2005.

Ensuite, Financial IT a utilisé la procédure suivante pour modifier le schéma de base de données afin de crypter les données sensibles de la table :

  1. Création d'une nouvelle table avec la même structure que la table d'origine, à ceci près que la colonne contenant les données sensibles doit être de type varbinary.

  2. Ouverture de la clé symétrique.

  3. Exécution d'une requête SELECT INTO afin de copier les données de la table existante vers la table nouvellement créée, et pour crypter les données sensibles.

  4. Fermeture de la clé symétrique ouverte.

  5. Suppression de la table originale.

  6. Remplacement du nom de la table nouvellement créée par celui de la table d'origine.

  7. Suppression de tous les index des colonnes cryptées, le cas échéant.

Financial IT a ensuite mis à jour les procédures stockées afin qu'elles utilisent la fonction EncryptByKey() et la fonction DecryptByKey() pour accéder aux données cryptées. La mise à jour a impliqué les étapes suivantes :

Remarque : Pour plus d'informations sur ces fonctions, reportez-vous à « Annexe : Scénarios d'utilisation du cryptage », plus loin dans ce document.

  1. Ouverture de la clé symétrique.

  2. Utilisez la fonction EncryptByKey() ou la fonction DecryptByKey() pour crypter ou décrypter les données de la colonne contenant les données sensibles.

  3. Fermeture de la clé symétrique ouverte.

Après la procédure précédente, Financial IT a configuré les autorisations des rôles SQL Server afin d'accorder des autorisations à la clé symétrique pour le rôle nécessitant l'accès aux données cryptées, et pour refuser les autorisations à la clé symétrique pour le rôle ne devant pas avoir accès aux données cryptées.

Une fois que Financial IT a configuré avec succès la base de données afin de prendre en charge le cryptage des données sensibles, il a sauvegardé la clé principale de la base de données, le certificat SQL Server 2005 et la clé symétrique avec laquelle les données ont été cryptées. Dans la mesure où les données cryptées étaient ensuite stockées dans la base de données, Financial IT a déterminé qu'il devait utiliser la procédure suivante pour sauvegarder la base de données :

  1. Sauvegarde des clés de cryptage SQL Server 2005 avec les commandes SQL Server 2005 Transact-SQL correspondantes.

  2. Sauvegarde de la base de données SQL Server 2005 contenant les données cryptées.

  3. Enregistrement de la sauvegarde de clé de cryptage correspondant à la sauvegarde de base de données particulière.

Lorsqu'une organisation restaure une base de données contenant des données cryptées, elle doit disposer des clés de cryptage utilisées pour crypter les données stockées. Si une organisation change régulièrement les clés de cryptage afin de se conformer aux exigences de sécurité de l'entreprise, elle doit s'assurer de disposer des clés de cryptage permettant de décrypter les données d'une sauvegarde particulière.

Pour restaurer une base de données contenant des données cryptées, une organisation doit prendre des mesures supplémentaires afin de s'assurer que les données cryptées peuvent être décryptées. Une fois la base de données restaurée, l'organisation doit décrypter la clé principale de la base de données. Elle doit ensuite crypter la clé principale de la base de données à l'aide de la clé principale du service. Pour décrypter la clé principale de la base de données, l'organisation doit utiliser le mot de passe avec lequel elle a crypté la clé principale de la base de données lors de l'utilisation des commandes SQL Server 2005 Transact-SQL pour sauvegarder la clé.

Bien que l'objectif de Financial IT était de développer et d'implémenter une stratégie de cryptage pour l'application PCRS, le département a également un objectif plus large. Cet objectif était de créer une solution que les autres départements informatiques de Microsoft IT pourraient utiliser pour implémenter le cryptage dans les applications métier locales.

Même si Financial IT a utilisé uniquement les échantillons de données de la base PCRS_Encryption, l'application PCRS présente beaucoup de similitudes avec les autres applications métier de Microsoft IT. Par conséquent, Financial IT a testé la base de données PCRS_Encryption dans de nombreux scénarios réels, afin de déterminer si les procédures de sauvegarde et de restauration du cryptage fonctionneraient pour les départements informatiques autres que Financial IT. Ce dernier n'a rencontré aucun problème de performance avec le processus de cryptage ou de décryptage au cours de ces tests. Ce processus était transparent pour les employés Microsoft qui utilisaient cette base de données.


* SQL Server 2005 est un élément essentiel de la sécurité de l'application PCRS. *

Steven Devin
Responsable de programme de groupe
Microsoft Corporation

Metropolis

Metropolis est une application de service client et de support technique créée par le département Services IT. Cette application est constituée d'un outil front-end créé via l'API Microsoft Win32®, d'un deuxième niveau de services Web basé sur XML (Extensible Markup Language) et d'un troisième niveau basé sur SQL Server 2005.

Les professionnels du support Microsoft utilisent l'outil front-end pour diriger et prendre en charge les appels du support technique. Avec les autres fonctionnalités de support, telles que la création de demandes de service et les opérations de localisation des techniciens de support disponibles, cet outil permet au personnel de support d'accéder aux partages de fichiers et aux autres emplacements contenant des données sensibles, telles que des clés de produit et des mots de passe.


* L'approche du cryptage de données dans SQL Server 2005 permet à notre infrastructure d'offrir un point d'accès unique pour les données sensibles. Le stockage sécurisé des secrets dans une base de données rend l'utilisation des données sensibles aussi simple que l'utilisation des autres données pour nos développeurs d'applications, tout en offrant une technologie de cryptage performante pour la protection de nos ressources les plus précieuses. *

Brad Uhrich
Développeur d'applications senior
Microsoft Corporation

Lorsque le département Services IT a créé l'application Metropolis, ce département, comme beaucoup d'autres départements informatiques de l'entreprise, devait se conformer aux exigences de sécurité de l'entreprise, affectant le stockage des données sensibles, telles que les clés de produit et les mots de passe. En général, les données sensibles sont stockées dans un partage de fichiers crypté ou dans un emplacement partagé dans lequel des listes de contrôle d'accès sont configurées pour limiter l'accès des utilisateurs aux données sensibles. Le principal problème de cette approche tient au fait que lorsqu'une organisation protège les données sensibles via un mot de passe ou un secret, elle doit ensuite protéger ce mot de passe ou ce secret. Par exemple, elle peut crypter les informations avec une phrase secrète. L'organisation doit ensuite protéger cette phrase secrète avec un autre mot de passe ou secret. Cette approche peut entraîner une série de mots de passe ou de mécanismes de cryptage.

Les exigences de sécurité de Microsoft permettent l'utilisation de DPAPI comme mécanisme de sécurité pour les données sensibles. L'une des raisons de cette stratégie est que le compte qui utilise DPAPI doit être connecté à l'ordinateur local.

Le département Services IT a déterminé que la hiérarchie de gestion des clés intégrée à SQL Server 2005 satisfaisait non seulement aux exigences de sécurité de Microsoft, mais permettait également à Services IT de créer un mécanisme simple pour l'accès aux données sensibles de la base Metropolis. Par conséquent, Services IT a créé une base de données administrative pour les données sensibles. Cette base de données administrative est appelée base de données d'environnement. La base de données contient toutes les données sensibles requises pour gérer la base Metropolis, par exemple les noms des serveurs, les emplacements des partages de fichiers, les informations d'identification et les clés cryptographiques. Services IT a configuré le cryptage SQL Server 2005 de niveau colonne pour crypter toutes les données sensibles de cette base.

Services IT a déterminé que la base de données d'environnement Metropolis devait satisfaire aux conditions suivantes :

  • Les utilisateurs qui disposent d'autorisations de sécurité de bas niveau peuvent crypter des données dans la base d'environnement.

  • Seuls les utilisateurs disposant d'un niveau suffisamment élevé d'autorisations de sécurité peuvent décrypter les données dans la base d'environnement.

Le département Services IT a déterminé que les fonctionnalités de cryptage de SQL Server 2005 lui permettraient de créer une infrastructure de sécurité simple mais robuste pour satisfaire aux deux conditions précédentes. Pour créer cette infrastructure de sécurité de cryptage, Services IT a créé la hiérarchie de clés de cryptage SQL Server 2005 hybride, illustrée par la figure 16.

Figure 16. Hiérarchie de clés de cryptage Metropolis

Figure 16. Hiérarchie de clés de cryptage Metropolis

En utilisant DPAPI pour crypter la clé principale du service SQL Server 2005, Services IT a garanti que cette infrastructure de clé de cryptage serait conforme aux exigences de sécurité de Microsoft. En outre, en utilisant un schéma de cryptage hybride, Services IT a suivi les méthodes recommandées par Microsoft IT en termes de cryptage. Une clé symétrique est utilisée pour crypter les données, ce qui permet de tirer parti de la rapidité du cryptage symétrique. Une méthode de cryptage asymétrique est utilisée pour crypter la clé symétrique, ce qui lui permet de tirer parti de la sécurité renforcée du cryptage asymétrique par rapport au cryptage symétrique.

Cependant, l'aspect intéressant de l'infrastructure de cryptage de Systems IT est qu'elle utilise un certificat pour signer numériquement la procédure stockée qui crypte les données. Grâce à l'utilisation de la clé privée du certificat SQL Server 2005 pour signer numériquement la procédure stockée, un utilisateur qui ne dispose pas des autorisations sur le certificat peut utiliser la procédure stockée pour décrypter la clé symétrique, puis utiliser la clé symétrique pour crypter les données dans la base d'environnement. En revanche, un utilisateur qui souhaite décrypter la clé symétrique pour décrypter les données de la base d'environnement doit disposer des autorisations sur la clé principale.

En utilisant un certificat SQL Server pour crypter la clé symétrique, et en utilisant ce certificat pour signer numériquement la procédure stockée qui crypte les données dans la base de données d'environnement, Services IT a pu configurer une infrastructure d'autorisation dans laquelle n'importe quel utilisateur peut crypter les données de la base. Cependant, seuls certains utilisateurs peuvent alors décrypter ces données.

Services IT a implémenté avec succès l'infrastructure de cryptage Metropolis dans un environnement de production. Le processus de cryptage est transparent pour les professionnels qui utilisent ce système. En outre, Services IT prévoit d'étendre l'utilisation de cette infrastructure de cryptage afin d'inclure d'autres bases de données dans l'application métier Metropolis.

Méthodes recommandées

Microsoft IT a beaucoup de projets pilotes en cours, liés au cryptage SQL Server 2005, dans l'espace des applications métier de Microsoft IT. Par conséquent, Microsoft IT a acquis une expérience importante concernant les techniques de cryptage de la base de données SQL Server 2005. Cette expérience a permis de définir un certain nombre de méthodes recommandées. Les autres organisations peuvent utiliser ces méthodes recommandées pour simplifier la tâche de renforcement de la sécurité des bases de données, afin de satisfaire aux réglementations et aux exigences des départements sécurité de leur entreprise.

La gestion des clés est essentielle dans une infrastructure de cryptage

SQL Server 2005 inclut les fonctionnalités permettant de crypter et de décrypter les données sans avoir à se soucier des détails des algorithmes de cryptage. Cependant, l'un des principaux avantages du cryptage SQL Server 2005 est que SQL Server 2005 peut gérer les clés de cryptage.

Les recommandations de Microsoft IT pour la génération des clés sont les suivantes :

  • Créez toujours une sauvegarde en utilisant un mot de passe renforcé pour la clé principale du service.

  • Utilisez un mot de passe renforcé lors de la création de la clé principale de la base de données. Ce mot de passe doit être soumis à la stratégie locale de vérification de mot de passe, et SQL Server 2005 doit être configuré pour vérifier la puissance du mot de passe. En outre, cryptez ce mot de passe en utilisant des certificats ou des clés symétriques. Sauvegardez la clé principale de la base de données afin de pouvoir récupérer la clé si vous la perdez.

  • Utilisez l'algorithme de cryptage AES avec une longueur de 256 bits au cours de la création d'une clé symétrique. Cryptez les clés symétriques à l'aide de certificats SQL Server 2005. Accordez aux entités approuvées des autorisations sur les objets cryptographiques (tels que les certificats ou les clés). Si une entité avec approbation limitée doit utiliser une clé pour décrypter ou crypter des données, utilisez la clause EXECUTE AS dans des modules afin de changer la clé et les données, plutôt que d'accorder les autorisations directement au compte utilisateur limité.

  • Créez des certificats signés automatiquement. Les fonctions intégrées pour le cryptage et la signature ne vérifient pas les dates d'expiration des certificats. Par conséquent, testez l'expiration des certificats dans l'application en utilisant une procédure stockée ou une logique métier de niveau intermédiaire.

  • Procédez à l'audit régulier des tables de base de données contenant des données sensibles, ainsi que du catalogue des clés et certificats, afin de déterminer qui génère les certificats et les clés. Pour mener l'audit, surveillez ces tables avec un mécanisme de script et d'alerte SQL Server.

Les recommandations de Microsoft IT pour l'utilisation des clés sont les suivantes :

  • Ne distribuez pas les clés de cryptage entre les serveurs. Les données doivent être cryptées et décryptées sur le même ordinateur. Par conséquent, vous n'avez généralement pas besoin de transférer les clés de cryptage vers un autre ordinateur.

  • Lorsque vous ouvrez des clés de cryptage au cours d'une opération de cryptage ou de décryptage, fermez toujours ces clés dans la même session.

Les recommandations de Microsoft IT pour la sauvegarde des clés sont les suivantes :

  • Sauvegardez la clé privée du certificat, ainsi que le mot de passe utilisé pour crypter la clé privée du certificat.

  • Sauvegardez la clé principale de la base de données en utilisant l'instruction DUMP.

  • Déplacez la clé principale du service vers un fichier, puis sauvegardez le fichier.

Les recommandations de Microsoft IT pour la régénération des clés sont les suivantes :

  • Régénérez régulièrement la clé principale du service, car il s'agit d'une clé symétrique. Cette méthode permet d'éviter les fuites de clés et de données via les attaques par la force brute.

  • Envisagez l'utilisation de l'option FORCE REGENERATE. Utilisez l'option FORCE uniquement lorsqu'elle est nécessaire, c'est-à-dire si la régénération échoue régulièrement. L'option FORCE entraîne la poursuite du processus de régénération des clés, même si le processus ne peut pas extraire la clé principale actuelle ou ne peut pas décrypter toutes les clés privées.

Limitez l'utilisation du cryptage aux données sensibles

Avant d'implémenter le cryptage SQL Server 2005, une organisation doit étudier l'impact du cryptage sur les performances, déterminer si une source externe nécessite l'accès aux données cryptées, ainsi que déterminer l'augmentation de la taille des données suite au cryptage. Microsoft IT émet les recommandations suivantes pour l'utilisation du cryptage dans SQL Server 2005 :

  • Classez soigneusement les données. Ensuite, cryptez uniquement les données nécessitant la sécurité renforcée offerte par le cryptage.

  • Si les données ne seront cryptées que lors de leur stockage dans la base (au repos) et que vous pouvez enregistrer et extraire ces données en tant que texte brut, utilisez des clés symétriques pour crypter les données. Ne cryptez pas les clés symétriques avec des mots de passe si vous n'êtes pas en mesure de gérer correctement ces clés et ces mots de passe. Ne transférez pas les clés symétriques entre les utilisateurs et les applications.

  • Si vous souhaitez crypter une petite quantité de données, utilisez le cryptage asymétrique. Pour crypter une grande quantité de données, utilisez une approche de cryptage hybride.

Conclusion

Microsoft IT a commencé à migrer ses applications métier vers SQL Server 2005 afin de tirer parti des nouvelles fonctionnalités de performance et de sécurité offertes par la nouvelle version de SQL Server. Microsoft IT devait répondre à de nouvelles réglementations concernant les informations personnelles, ainsi qu'aux exigences de sécurité de Microsoft en termes de données sensibles. Ainsi, Microsoft IT a réévalué l'infrastructure de sécurité existante de l'espace des applications métier de Microsoft IT.

L'application FeedStore de Microsoft IT sert de référentiel de données central pour Microsoft. Dans la mesure où cette application traite des données pouvant contenir des informations personnelles, il existe déjà un schéma de sécurité renforcé pour protéger ces données. Cependant, Enterprise Data Services a décidé de faire progresser encore l'infrastructure de sécurité FeedStore en développant une infrastructure de cryptage et en implémentant le pilote Digital Asset Store. Ce pilote Digital Asset Store permet de supprimer les informations personnelles de FeedStore et de l'espace des applications métier de Microsoft IT.

Les départements Financial IT et Services IT étaient confrontés à un scénario dans lequel ils nécessitaient le cryptage dans leurs applications métier locales. Chaque département a utilisé SQL Server 2005 pour développer une infrastructure de cryptage robuste, mais facile à gérer.

En utilisant les mécanismes de gestion des clés et la fonctionnalité de cryptage de niveau colonne intégrés à SQL Server 2005, Microsoft IT a commencé à renforcer la sécurité des données dans l'espace des applications métier de Microsoft IT.

Pour plus d'informations

Pour plus d'informations sur les produits ou services Microsoft, appelez le Microsoft Sales Information Center au (800) 426-9400. Au Canada, appelez le Microsoft Canada information Centre au (800) 563-9048. En dehors des États-Unis et du Canada, veuillez contacter votre filiale Microsoft locale. Pour accéder à des informations via le Web, consultez les sites suivants :

http://www.microsoft.com/france

http://www.microsoft.com/itshowcase

http://www.microsoft.com/france/technet/itsolutions/msit/default.mspx

Si vous avez des questions, commentaires ou suggestions à propos de ce document, ou pour obtenir des informations complémentaires sur Microsoft IT Showcase, adressez un courrier électronique à :

showcase@microsoft.com

Annexe : Scénarios d'utilisation du cryptage

Cryptage des données au repos

Pour crypter les données au repos avec le cryptage symétrique SQL Server 2005, procédez de la façon suivante :

  1. Création de la clé principale de la base de données. SQL Server 2005 utilise la clé principale de la base de données pour crypter la clé privée du certificat créé à l'étape 2.

  2. Créez un certificat. SQL Server 2005 utilise des certificats pour crypter les données ou pour crypter les clés symétriques.

  3. Créez une clé symétrique pour crypter les données de destination. Cryptez cette clé symétrique en utilisant le certificat créé à l'étape 2, en utilisant une autre clé symétrique, ou en utilisant un mot de passe fourni par l'utilisateur.

  4. Ouvrez la clé symétrique afin de crypter ou de décrypter les données. Pour ouvrir cette clé, utilisez le mécanisme avec lequel vous avez crypté la clé.

  5. Cryptez les données avec la fonction EncryptByKey(), ou décryptez-les avec la fonction DecryptByKey(). Les données sont à présent stockées en tant qu'objet BLOB (Binary Large Object) dans la base de données, ou elles sont décryptées, en fonction de l'instruction Transact-SQL que vous avez utilisée.

  6. Fermez toutes les clés symétriques.

SQL Server 2005 offre un paramètre facultatif que vous pouvez utiliser avec la fonction EncryptByKey() et la fonction DecryptByKey() pour vérifier l'intégrité des colonnes. Utilisez ce paramètre si vous souhaitez vous assurer qu'un utilisateur disposant des autorisations nécessaires ne permute pas deux valeurs cryptées entre les lignes d'une base de données. Par exemple, vous pouvez avoir crypté les informations de salaire dans une table de base de données. Bien que le cryptage de niveau colonne empêche un utilisateur de lire le salaire crypté, le cryptage de niveau colonne n'empêche pas un utilisateur disposant des informations nécessaires d'échanger le salaire crypté d'un responsable avec celui d'un autre employé.

SQL Server 2005 favorise la protection contre ce scénario via un paramètre facultatif permettant de spécifier une valeur de hachage lors du cryptage. Au cours du processus de cryptage, vous pouvez spécifier la commande suivante.

          Insert into empTable values (emp1id, encryptbykey(Key1Guid, 50000,
          emp1id))
        

Au cours du processus de décryptage, vous pouvez spécifier la commande suivante.

          Select empID, decryptbykey(salary, empID) from empTable
        

Dans ces exemples, le cryptage est effectué sur la valeur en clair 50 000, laquelle est concaténée avec le hachage du troisième paramètre facultatif. Dans cet exemple, emp1id est le troisième paramètre. Lors du décryptage, SQL Server 2005 compare le hachage du troisième paramètre au hachage stocké dans le BLOB crypté. Si les deux hachages correspondent, SQL Server 2005 détermine que la valeur cryptée n'a pas été déplacée entre les lignes de la base de données.

Remarque : Nous recommandons l'utilisation de la clé primaire comme troisième paramètre de la fonction EncryptByKey().

Accès aux données cryptées à l'aide d'une vue

Il existe des scénarios au sein de Microsoft IT dans lesquels des vues et fonctions font référence à des colonnes cryptées. SQL Server 2005 offre la fonction DecryptByKeyAutoCert() afin de décrypter les données des vues. Dans un scénario dans lequel les données sont cryptées via une clé symétrique et où un certificat protège cette clé symétrique, cette fonction recherche la clé cryptée via le certificat que vous spécifiez. La fonction DecryptByKeyAutoCert() ouvre alors automatiquement la clé symétrique, décrypte les données, puis ferme la clé.

Remarque : Pour les vues et fonctions qui font référence à une colonne cryptée, vous devez modifier la vue ou la fonction afin d'inclure la logique de cryptage des données.

L'exemple de script suivant illustre comment accéder aux données cryptées à l'aide d'une vue dans SQL Server 2005.

          Create View testview
          as
          Select Convert(varchar(100),
          decryptbykeyautocert(cert_id('myCert1'), NULL, SSN, 0, Null)) as SSN
          From Customer
        

La fonction DecryptByKeyAutoCert() attend les arguments suivants :

  • Le certificat ou l'ID de la clé symétrique, par exemple myCert1.

  • Le mot de passe du certificat spécifié. Dans cet exemple, le certificat est crypté par l'intermédiaire de la clé principale de la base de données. Ainsi, le mot de passe du certificat spécifié est NULL.

  • Le flux à décrypter, par exemple la colonne SSN.

  • La présence ou non d'octets pour l'authenticité. Ce paramètre facultatif présente la valeur 0 ou 1.

  • Octets pour l'authenticité. La valeur par défaut de ce paramètre facultatif est NULL.

    Remarque : Lorsque vous utilisez la fonction DecryptByKeyAutoCert pour rechercher une clé symétrique cryptée par un certificat, et si ce certificat a été utilisé pour crypter d'autres clés symétriques, SQL Server 2005 utilise le certificat particulier pour examiner la structure BLOB cryptée afin de déterminer l'identificateur globalement unique (GUID, Globally Unique Identifier) de clé associé au BLOB. SQL Server 2005 ouvre ensuite uniquement la clé symétrique particulière utilisée pour crypter la colonne.

Insertion de données en masse

L'exemple de script suivant illustre comment insérer en masse des données d'un fichier dans une table, puis crypter ces données avec le cryptage SQL Server 2005.

Remarque : L'extrait de code suivant est affiché sur plusieurs lignes uniquement à des fins de lisibilité. Elles doivent être saisies sous forme de ligne unique.

          Create Procedure test_sp
          as
          CREATE TABLE #InsertTemp
          (
                PN int,
                SSN varchar(100)
          )
          BULK INSERT #InsertTemp
             FROM 'C:\test.txt'    
          TRUNCATE TABLE BulkInsertTbl

          OPEN SYMMETRIC KEY key1AES DECRYPTION BY CERTIFICATE myCert1

          INSERT INTO BulkInsertTbl (PersonnelNumber, SSN)
          SELECT Tmp.PN, EncryptByKey(Key_GUID('key1AES'),Tmp.NID)
          FROM #InsertTemp Tmp

          DROP TABLE #InsertTemp
          /* Note: The following code is not required. The DecryptByKey
          function call is not required. The function call appears here to
          test whether the inserted data is encrypted. */
          SELECT
                T.PersonnelNumber,
                convert(varchar(20), decryptbykey(T.SSN)) as SSN
          FROM BulkInsertTbl T
          CLOSE SYMMETRIC KEY key1AES
          go

          /* Script to create the BulkInsertTbl table */
          CREATE TABLE BulkInsertTest
          (
                PersonnelNumber int,
                SSN varbinary(100)     /* Note: The encrypted column data type
          is varbinary.) */
          )
          go
        

Dans cet exemple, la clé symétrique nommée key1AES est cryptée via le certificat nommé myCert1. Vous devez ouvrir la clé key1AES avant de procéder au cryptage des données. Vous devez ensuite fermer cette clé une fois le cryptage effectué. Dans cet exemple, la fonction DecryptByKey() n'est pas requise. La fonction permet de déterminer si les données insérées ont été cryptées.

Cryptage et décryptage de données à l'aide de certificats

Nous recommandons généralement de crypter les données avec une clé symétrique. Cette méthode tire parti de la vitesse du cryptage symétrique. Cependant, vous pouvez crypter les données avec un certificat plutôt qu'avec une clé symétrique. Dans la mesure où le cryptage asymétrique est plus sûr que le cryptage symétrique, l'utilisation d'un certificat pour crypter les données est utile lorsque vous souhaitez transférer des clés de cryptage entre des serveurs qui exécutent SQL Server 2005. L'exemple de script qui suit illustre comment crypter des données avec un certificat.

          CREATE MASTER KEY ENCRYPTION BY PASSWORD = 'Yukon900'
          go
          CREATE CERTIFICATE [cert_name] WITH SUBJECT = 'MyApp - Data
          encryption'
          go
          INSERT INTO TABLE VALUES (encryptbycert( cert_id(cert_name), data))
        

Pour décrypter ces données, utilisez la fonction DecryptByCert().


Cela vous a-t-il été utile ?
(1500 caractères restants)
Merci pour vos suggestions.
Afficher:
© 2014 Microsoft. Tous droits réservés.