Amélioration de la sécurité des données à l'aide de SQL Server 2005 Résumé PRÉPARATION CLIENT. Cette présentation de 36 diapositives, basée sur une étude de cas technique de 39 pages publiée en octobre 2005, explique comment Microsoft IT a amélioré la sécurité des données dans l'espace des applications métier. Elle décrit la stratégie de consolidation des données, ainsi que le cryptage des données sensibles avec Microsoft SQL Server. Introduction Microsoft, comme beaucoup de grandes entreprises, analyse soigneusement les infrastructures de sécurité de base de données existantes afin de s'assurer que les infrastructures de sécurité sont conformes aux récentes exigences réglementaires du gouvernement. 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. Microsoft IT a ainsi 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 et dans le but de réduire ou de supprimer la duplication des données dans les applications métier de Microsoft IT. 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. 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. Cette présentation 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. Cette présentation 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 cette présentation 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. Date de publication : octobre 2005 Utilisation du cryptage SQL Server 2005 pour protéger les données

Vue d'ensemble de la solution Situation Microsoft IT a réévalué les infrastructures de sécurité des bases de données. Solution SQL Server 2005 Avantages Infrastructure de gestion des clés robuste et facile à utiliser. Cryptage des données sensibles dans les applications. Décryptage des données dans une vue. Cryptage simplifié des données. Vue d'ensemble de la solution 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 gestion des clés et de cryptage au niveau colonne de Microsoft SQL Server ont permis à Microsoft IT de développer différentes stratégies de cryptage pour améliorer la sécurité des données sensibles dans l'espace des applications métier de Microsoft IT. 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 SQL Server 2005 Produits et technologies SQL Server 2005

Vue d'ensemble des exigences réglementaires Les infrastructure de sécurité de Microsoft doivent se conformer aux lois fédérales, nationales et internationales relatives au stockage des informations personnelles. Les exigences affectent différentes opérations de base de données. 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éesLes 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 La barrière de sécurité ultime pour les données sensibles est généralement le cryptage. Le cryptage augmente la charge processeur et consomme de l'espace de stockage. Le cryptage nécessite la gestion des clés. Cryptage symétrique : Rapide Utilise une seule clé N'offre pas la non-répudiation 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. 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. 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. 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)

Vue d'ensemble du cryptage des données Cryptage asymétrique : Utilise une paire de clés Plus lent que le cryptage symétrique Permet la confidentialité et la non-répudiation Cryptage hybride : Tire parti de la vitesse du cryptage dynamique et de la sécurité renforcée du cryptage asymétrique Vue d'ensemble du cryptage des données (suite) 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. 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. 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.

Environnement de l'application Microsoft IT met à niveau vers SQL Server 2005 toutes ses applications métier liées aux bases de données Les analyses des solutions de stockage de base de données répondaient aux exigences de sécurité informatiques et gouvernementales. Les analyses concernaient trois systèmes de base de données. 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 ITDans 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 Inclut de nombreuses fonctionnalités de sécurité Prend en charge trois types de cryptage, chacun avec des clés différentes et plusieurs algorithmes de cryptage 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. 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.

Solution : le cryptage SQL Server 2005 Solution : le cryptage SQL Server 2005 (suite) 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é dans la figure de cette diapositive. Dans cette hiérarchie, chaque couche crypte les couches situées en dessous. 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. 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. 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.

Solution : le cryptage SQL Server 2005 Le processus de cryptage et de décryptage nécessite : Un certificat est un moyen d'utiliser le cryptage asymétrique. Une clé asymétrique Une clé symétrique, qui doit être ouverte dans l'ordre approprié dans une hiérarchie de cryptage Solution : le cryptage SQL Server 2005 (suite) 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 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 de cette diapositive illustre le flux de données entre les applications 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.

FeedStore FeedStore (suite) 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 de cette diapositive illustre ce processus d'autorisation.

Stratégie FeedStore Les données sensibles étaient dupliquées et stockées dans plusieurs emplacements. Le cryptage des données dans chaque emplacement de stockage serait trop coûteux. La consolidation et le cryptage des données dans une banque distincte constituait la meilleure stratégie. 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.

Stratégie FeedStore Stratégie FeedStore (suite) 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 de cette diapositive 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.

Stratégie FeedStore Reconfigurer le flux afin de supprimer les données sensibles des applications qui ne nécessitent pas d'accès Reconfigurer certaines applications afin d'obtenir les données sensibles à partir d'une banque cryptée distincte Conserver les données sensibles disponibles Stratégie FeedStore (suite) Suppression des 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 Création d'une banque cryptée centralisée à l'aide de SQL Server 2005 Création d'exigences métier et d'objectifs métier Classification des informations actuelles Planification et surveillance afin de préserver la disponibilité des données sensibles pour les applications 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.

Pilote Digital Asset Store Plusieurs actions effectuées sur des données sensibles et des informations personnelles dans l'espace des applications métier concernant FeedStore Éditeurs configurés pour envoyer les données sensibles vers Digital Asset Store Pilote Digital Asset Store (suite) Implémentation 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. 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. 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. 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.

Pilote Digital Asset Store Pilote Digital Asset Store (suite) Implémentation (suite) 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 de cette diapositive illustre l'emplacement du fichier plat dans la structure actuelle de flux de données FeedStore.

Pilote Digital Asset Store Pilote Digital Asset Store (suite) Implémentation (suite) 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 de cette diapositive affiche la structure de flux de données Digital Asset Store proposée.

Pilote Digital Asset Store Pilote Digital Asset Store (suite) Implémentation (suite) 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 de cette diapositive illustre ce transfert de données. Dans cette méthode de transfert de données, 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éesRemarque : 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).

Pilote Digital Asset Store Conversion en ligne : Insère les données sensibles dans un flux de données lors de l'exécution 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 Utilise une banque cryptée distincte pour les données sensibles Pilote Digital Asset Store (suite) Implémentation (suite) Dans la méthode de transfert de données recommandée, 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.

Pilote Digital Asset Store Pilote Digital Asset Store (suite) 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 de cette diapositive illustre le processus de cryptage Digital Asset Store tel que Enterprise Data Services prévoit de l'implémenter.

Pilote Digital Asset Store Pilote Digital Asset Store (suite) Processus de cryptage Digital Asset Store (suite) 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 de cette diapositive illustre le processus de décryptage Digital Asset Store tel que Enterprise Data Services prévoit de l'implémenter.

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 de cette diapositive illustre le flux de données via le PCRS.

Application PCRS (Payroll Controls Reporting System) Application PCRS modifiée pour utiliser le cryptage SQL Server 2005 Cryptage implémenté dans la base de données PCRS locale Prototype de base de données implémenté pour tester la sauvegarde, la maintenance et la restauration des clés de cryptage Application PCRS (suite) 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.

Application PCRS (Payroll Controls Reporting System) Application PCRS (suite) 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 de cette diapositive illustre cette architecture de base de données.

Application PCRS (Payroll Controls Reporting System) Procédure pour créer une hiérarchie de clés de cryptage SQL Server 2005 simple et robuste Procédure pour modifier le schéma de base de données afin de crypter les données sensibles de la table Procédure pour mettre à jour les procédures stockées afin d'utiliser des fonctions pour accéder aux données cryptées Application PCRS (suite) Pilote PCRS (suite) Pour implémenter et tester la configuration de base de données PCRS_Encryption, 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 : 1. Ouvrez 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.

Application PCRS (Payroll Controls Reporting System) Configuration des autorisations sur les rôles SQL Server Sauvegarde de la clé principale de la base de données, du certificat SQL Server 2005 et de la clé symétrique Sauvegarde de la base de données Test de la base de données dans des scénarios réels Application PCRS (suite) Pilote PCRS (suite) Après la procédure de la diapositive 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.

Metropolis L'application est constituée d'un outil front-end, d'un deuxième niveau basé sur XML et d'un troisième niveau basé sur SQL Server 2005. DPAPI peut jouer le rôle d'un mécanisme de sécurité pour les données sensibles chez Microsoft. Services IT a créé une base de données administrative pour les données sensibles de Metropolis. 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. 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.

Metropolis Metropolis (suite) 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 de cette diapositive.

Metropolis L'utilisation de DPAPI pour crypter la clé principale du service est conforme aux exigences de sécurité. L'infrastructure de cryptage utilise un certificat pour signer numériquement la procédure stockée qui crypte les données. Le certificat permet la configuration d'une infrastructure d'autorisations. Metropolis (suite) 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 La gestion des clés est essentielle dans une infrastructure de cryptage. Génération des clés Utilisation des clés Sauvegarde des clés Régénération des clés Méthodes recommandées 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. 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.

Méthodes recommandées Limitez l'utilisation du cryptage aux données sensibles. Tenez compte de l'impact du cryptage sur les performances. Déterminez si une source externe nécessite l'accès à des données cryptées. Tenez compte de l'augmentation de la taille des données cryptées. Méthodes recommandées (suite) 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 L'infrastructure de sécurité a été réévaluée dans l'espace des applications métier de Microsoft IT. L'infrastructure de cryptage et le pilote Digital Asset Store ont accru la sécurité de FeedStore. Les mécanismes de gestion des clés et le cryptage de niveau colonne dans SQL Server 2005 ont renforcé la sécurité des données chez Microsoft. 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 Vous trouverez davantage d'informations sur les déploiements et méthodes recommandées de Microsoft sur http://www.microsoft.com Microsoft TechNet http://www.microsoft.com/technet/itshowcase Ressources d'études de cas Microsoft http://www.microsoft.com/resources/casestudies Pour plus d'informations Vous trouverez davantage d'informations sur les déploiements et méthodes recommandées de Microsoft IT sur http://www.microsoft.com. TechNet : http://www.microsoft.com/technet/itshowcase Ressources d'études de cas : http://www.microsoft.com/resources/casestudies À propos de Microsoft IT Showcase Microsoft IT Showcase est un ensemble d'applications métier, de stratégies de déploiement, d'expériences d'adopteurs précoces, de méthodes recommandées et d'initiatives de l'organisation Microsoft IT. IT Showcase propose des études de cas, des livres blancs, des présentations et des présentations multimédias qui illustrent les applications métier internes, les expériences de déploiement des produits et d'autres initiatives informatiques implémentées chez Microsoft. Expérience de Microsoft IT Adopteur précoce : Microsoft IT est souvent le premier à implémenter les nouveaux produits Microsoft dans un environnement de production—et à développer des applications métier basées sur les technologies Microsoft. La connaissance des défis auxquels nous avons été confrontés et de la façon dont nous y avons fait face peut vous aider dans la planification et l'exécution de projets similaires. Déploiements à grande échelle : Microsoft IT supervise les déploiements à travers le monde, à la fois des produits Microsoft et de ceux des autres fournisseurs. Les problèmes auxquels nous sommes confrontés et les leçons tirées peuvent vous aider lorsque vous planifiez vos propres déploiements à grande échelle.

Ce document est fourni à titre d'information uniquement. © 2005 Microsoft Corporation. Tous droits réservés. Cette présentation est fournie à titre d'information uniquement. MICROSOFT N'OFFRE AUCUNE GARANTIE, EXPRESSE OU IMPLICITE, CONCERNANT CE DOCUMENT. Microsoft, Excel, Win32 et Windows sont soit des marques de Microsoft Corporation, soit des marques déposées de Microsoft Corporation, aux États-Unis et/ou dans d'autres pays. Les noms de produits et de sociétés réels mentionnés dans la présente documentation sont des marques de leurs propriétaires respectifs. Ce document est fourni à titre d'information uniquement. MICROSOFT N'OFFRE AUCUNE GARANTIE, EXPRESSE OU IMPLICITE, CONCERNANT CE DOCUMENT. © 2005 Microsoft Corporation. Tous droits réservés. Cette présentation est fournie à titre d'information uniquement. MICROSOFT N'OFFRE AUCUNE GARANTIE, EXPRESSE OU IMPLICITE, CONCERNANT CE DOCUMENT. Microsoft, Excel, Win32 et Windows sont soit des marques de Microsoft Corporation, soit des marques déposées de Microsoft Corporation, aux États-Unis et/ou dans d'autres pays. Les noms de produits et de sociétés réels mentionnés dans la présente documentation sont des marques de leurs propriétaires respectifs.