Sécurisez vos applications à l'aide de Microsoft .NET Framework MGB 2003 Sécurisez vos applications à l'aide de Microsoft .NET Framework Eric Mittelette & Eric Vernié & Pascal Belaud Relation Technique Développeurs Microsoft France © 2004 Microsoft Corporation. All rights reserved. This presentation is for informational purposes only. Microsoft makes no warranties, express or implied, in this summary.

Ce que nous allons étudier MGB 2003 Ce que nous allons étudier Fonctionnalités de sécurité du .NET Framework En quoi une code .NET est plus sécurisé par défaut qu’un code natif Sécurité basée sur les rôles (Role Based) Gestion de rôles applicatifs basés ou non sur le log-on Windows Sécurité d'accès au code (CAS) Vérification de « qui fait quoi » dans le code Cryptographie En quoi le .NET Framework simplifie t il les codes nécessitant de la cryptographie. SQL Server 2005 : quoi de neuf ? Dans cette section, nous allons présenter la sécurité des applications à l'aide de Microsoft® .NET Framework. En particulier, nous allons traiter des sujets suivants : Fonctionnalités de sécurité de .NET Framework Sécurité d'accès au code Sécurité basée sur les rôles Cryptographie Sécurisation des applications Web Microsoft ASP.NET Sécurisation des services Web ASP.NET © 2004 Microsoft Corporation. All rights reserved. This presentation is for informational purposes only. Microsoft makes no warranties, express or implied, in this summary.

Programme Fonctionnalités de sécurité de .NET Framework MGB 2003 Programme Fonctionnalités de sécurité de .NET Framework Sécurité basée sur les rôles Sécurité d'accès au code Cryptographie Dans cette section, nous allons présenter les fonctionnalités de sécurité de .NET Framework. En particulier, nous allons traiter des sujets suivants : Exécution managée .NET Système de type sécurisé Protection contre le débordement de mémoire tampon Interception des erreurs arithmétiques Assemblys avec nom fort Stockage isolé © 2004 Microsoft Corporation. All rights reserved. This presentation is for informational purposes only. Microsoft makes no warranties, express or implied, in this summary.

Sécurité de l'exécution managée .NET MGB 2003 Sécurité de l'exécution managée .NET Les fonctionnalités de sécurité de .NET Vous aident à développer des applications sûres Comprennent de nombreux composants, dont : Vérification de type Gestionnaire d'exceptions Moteur de sécurité Complètent sans la remplacer la sécurité de Windows Le Common Language Runtime .NET contrôle l'exécution du code .NET. Le système de sécurité de .NET Framework fait partie du Common Language Runtime. .NET Framework comprend de nombreuses fonctionnalités qui seront abordées dans cette présentation, comme la vérification des types pour une conversion des types en toute sécurité, une gestion des exceptions sûre et un contrôle de la sécurité d'accès au code. La sécurité de .NET Framework est conçue pour compléter celle de Microsoft Windows®. Elle ne remplace pas la sécurité de Windows. Par exemple, si une liste de contrôle d'accès (ACL, Access Control List) restreint l'accès à un fichier, .NET Framework ne remplace pas cette mesure de sécurité. © 2004 Microsoft Corporation. All rights reserved. This presentation is for informational purposes only. Microsoft makes no warranties, express or implied, in this summary.

Système de type sécurisé MGB 2003 Système de type sécurisé Un code de type sécurisé : Empêche le débordement de mémoire tampon Limite l'accès à des emplacements de mémoire autorisés Permet à plusieurs assemblage de s'exécuter dans le même processus Les domaines d'application permettent : AppDomain : Notion de sous processus… De meilleures performances Une plus grande sécurité du code par isolation La vérification du type est la pierre angulaire de la sécurité de .NET, car elle empêche l'accès à des emplacements de mémoire non autorisés. Cela vous permet de mettre en œuvre une stratégie de sécurité de façon cohérente. Par exemple, un code ne peut pas saturer un tampon et provoquer le saut de l'exécution vers un emplacement arbitraire de la mémoire. La vérification du type permet au Common Language Runtime d'exécuter plusieurs assemblys de type sécurisé dans le même processus. Ces sous-processus sont appelés domaines d'application. Les domaines d'application sont particulièrement utiles dans des scénarios de serveurs dans lesquels l'utilisation de nombreux processus peut ralentir les performances système. Par le passé, l'utilisation de composants à base de bibliothèques de liens dynamiques (DLL, Dynamic-Link Library) était privilégiée pour des raisons d'efficacité, car les composants EXE étaient perçus comme étant plus sûrs et plus fiables (en raison de l'architecture d'espace d'adressage virtuel Microsoft Win32®). Toutefois, .NET prend en charge le concept de domaine d'application. Un domaine d'application peut être imaginé comme un processus dans un processus, ce qui fournit de bonnes performances (comme un composant à base de DLL), une excellente sécurité et une grande fiabilité. © 2004 Microsoft Corporation. All rights reserved. This presentation is for informational purposes only. Microsoft makes no warranties, express or implied, in this summary.

Protection contre le débordement de mémoire tampon MGB 2003 Protection contre le débordement de mémoire tampon La vérification du type empêche les remplacements arbitraires dans la mémoire Les objets de classe System.String .NET sont immuables La classe System.Text.StringBuilder .NET vérifie les limites du tampon void CopyString (string src) { stringDest = src; } Le code managé ne traite généralement pas les pointeurs bruts (comme le caractère *). Le runtime .NET utilise à la place des classes telles que System.String et System.Text.StringBuilder, qui sont managées par des contrôles de vérification du type. Une chaîne est un objet immuable qui atténue considérablement le problème de débordement de mémoire tampon. Considérez le code suivant : void CopyString (string src) { stringDest = src; } Lorsque le code s'exécute, un nouvel objet chaîne résultant est créé et la référence stringDest est modifiée de façon à faire référence à cette chaîne. Un débordement de mémoire tampon est par conséquent impossible. .NET Framework comprend aussi une classe de chaîne StringBuilder. StringBuilder est également une classe robuste qui lève une exception en cas de tentative de remplacement de son tampon interne. © 2004 Microsoft Corporation. All rights reserved. This presentation is for informational purposes only. Microsoft makes no warranties, express or implied, in this summary.

Interception des erreurs arithmétiques MGB 2003 Interception des erreurs arithmétiques L'interception des erreurs arithmétiques est activée en utilisant : Le mot clé checked Les paramètres du projet byte b=0; while (true) { Console.WriteLine (b); checked b++; } } Intercepter des erreurs arithmétiques dans du code non managé (par exemple, Visual C++) est très difficile. La détection des erreurs d'exécution arithmétiques avec du code managé est toutefois plus aisée. Par exemple, le compilateur Visual C# permet de vérifier automatiquement les dépassements de capacité arithmétiques positifs et négatifs. Par défaut, la fonctionnalité d'interception des erreurs arithmétiques est désactivée (pour des raisons d'optimisation). Vous pouvez toutefois facilement activer cette fonctionnalité, à partir des propriétés du projet ou en utilisant le mot clé checked dans votre code. Si vous avez activé la vérification arithmétique au niveau du projet, vous pouvez remplacer ces paramètres en utilisant le mot clé unchecked dans votre code. Cela est particulièrement utile lorsque vous êtes certain que des erreurs arithmétiques ne peuvent pas se produire dans des blocs de code spécifiques et que vous voulez optimiser ces blocs au moment de la compilation de votre code. © 2004 Microsoft Corporation. All rights reserved. This presentation is for informational purposes only. Microsoft makes no warranties, express or implied, in this summary.

Vérification du code Possibilité de vérifier son code : MGB 2003 Vérification du code Possibilité de vérifier son code : Option du compilateur : Csc / checked[+;-] Instruction checked/unchecked Opérateur checked(….) Pas de levée d’exception Checked=Leve une exception OverflowException A noter que pour l’instruction checked on a pu simplifier le code avec l’opérateur += © 2004 Microsoft Corporation. All rights reserved. This presentation is for informational purposes only. Microsoft makes no warranties, express or implied, in this summary.

Architecture simplifiée de la démo Saisie infos Comment éviter la saisie du mot de passe en clair ? Fabrique de Classe Comment éviter que n’importe qui appel ma fabrique de classe ? Comment faire confiance aux dlls chargées dynamiquement ? Validation mot de passe BD Sous quelle forme dois-je stocker le mot de passe ? Chargement des rôles Sous quelle forme dois-je stocker la chaîne de connexion ? Affecter les politiques de sécurité en fonction des rôles Qu’est-ce qui peut me garantir la sécurité d’accès de mes objets de base de données ?

MGB 2003 Démonstration 1 Sécurité des types Buffer overrun vs .NET Gestion des secrets vs string Dans cette démonstration, vous allez apprendre : Comment fonctionne la sécurité du type de données .NET. Comment utiliser le mot clé checked. © 2004 Microsoft Corporation. All rights reserved. This presentation is for informational purposes only. Microsoft makes no warranties, express or implied, in this summary.

Assemblages avec nom fort MGB 2003 Assemblages avec nom fort Les noms forts sont Des identificateurs uniques (contenant une clé publique) Utilisés pour signer numériquement des assemblys Les assemblages avec nom fort Empêchent la falsification Confirment l'identité de l'éditeur de l'assembly Autorisent les composants côte à côte sn –k Ma_Clé_Complète.snk Les noms forts sont des identificateurs uniques pour vos assemblys. Vous pouvez générer des noms forts, puis les utiliser pour signer numériquement vos assemblys. L'affectation de noms forts permet de résoudre les problèmes (tels que ceux liés au contrôle de version et à la compatibilité descendante) qui peuvent se présenter lorsque des composants sont partagés par plusieurs applications. Dans le fond, les noms forts associent à l'application cliente une génération distincte d'un assembly de composant. Une génération distincte est identifiable à la combinaison d'un numéro de version et d'une valeur spéciale, appelée publicKeyToken. Vous pouvez générer une paire clé publique/clé privée pour signer votre assembly à l'aide de l'outil Strong Name (Sn.exe). Lorsque vous avez une clé privée, vous pouvez spécifier le fichier de clé et le numéro de version à assigner lorsque vous compilez l'assembly, en utilisant les attributs comme indiqué : [assembly: System.Reflection.AssemblyVersion("1.0.0.0")] [assembly: System.Reflection.AssemblyKeyFile("Clé_Org.snk")] Un assembly avec nom fort empêche des intrus de falsifier son code et permet de vérifier l'identité de son éditeur. Les assemblys avec nom fort permettent à des composants côte à côte de coexister, ce qui facilite le contrôle de version et la compatibilité descendante. © 2004 Microsoft Corporation. All rights reserved. This presentation is for informational purposes only. Microsoft makes no warranties, express or implied, in this summary.

Assemblies et Signature MGB 2003 Assemblies et Signature [assembly: AssemblyKeyFile(@"Cle.snk")] IL Valeur de hachage Signature Numérique RSA Metadonnées Fichier PE Haché Signé avec La clé privée Manifeste [assembly: AssemblyKeyFile(@"Cle.snk")] lorsque le compilateur trouve cette directive, Il ouvre le fichier cle.snk Signe l’assembly avec la clé privé Intègre la clé publique dans le manifeste Lorsque le fichier PE est compilé, son contenue est haché (SHA-1) La valeur de hachage est signée avec la clé privée de l’editeur La signature numerique RSA qui en résulte est stockée dans une section réservée (exclue du hachage) du fichier PE Clé publique En-Tête CLR Signature numérique RSA Intégré dans le fichier PE © 2004 Microsoft Corporation. All rights reserved. This presentation is for informational purposes only. Microsoft makes no warranties, express or implied, in this summary.

Le stockage isolé Fournit un système de fichiers virtuel MGB 2003 Le stockage isolé Fournit un système de fichiers virtuel Autorise les quotas Met en œuvre l'isolation du système de fichiers en fonction : De l'identité de l'application De l'identité de l'utilisateur Pour certaines applications, comme les applications Web téléchargées et le code pouvant provenir de sources non fiables, le système de fichiers de base ne fournit pas l'isolation et la sécurité requises. Le stockage isolé est un mécanisme de stockage des données qui fournit isolation et sécurité en définissant des façons normalisées d'associer du code à des données enregistrées. Les administrateurs peuvent utiliser des outils conçus pour manipuler le stockage isolé, pour configurer l'espace de stockage des fichiers et définir des stratégies de sécurité et pour supprimer les données inutilisées. Avec le stockage isolé, les développeurs n'ont plus besoin d'inventer des chemins uniques pour spécifier des emplacements sûrs dans le système de fichiers. Les développeurs peuvent désormais accéder à des emplacements sûrs en utilisant l'identité soit de l'application, soit de l'utilisateur. Le code de la diapositive donne un exemple d'accès au stockage isolé à l'aide de l'identité d'un utilisateur. IsolatedStorageFile isoStore = IsolatedStorageFile.GetUserStoreForAssembly(); © 2004 Microsoft Corporation. All rights reserved. This presentation is for informational purposes only. Microsoft makes no warranties, express or implied, in this summary.

Programme Fonctionnalités de sécurité de .NET Framework MGB 2003 Programme Fonctionnalités de sécurité de .NET Framework Sécurité basée sur les rôles Sécurité d'accès au code Cryptographie Dans cette section, nous allons présenter la sécurité basée sur les rôles. En particulier, nous allons traiter des sujets suivants : Authentification et autorisation. Identités et entités de sécurité. Création d'identités et d'entités de sécurité Windows. Création d'identités et d'entités de sécurité génériques. Réalisation de vérifications de sécurité. Vérifications de sécurité impératives et déclaratives. © 2004 Microsoft Corporation. All rights reserved. This presentation is for informational purposes only. Microsoft makes no warranties, express or implied, in this summary.

Authentification et Autorisation MGB 2003 Authentification et Autorisation L'authentification demande : « Qui êtes-vous ?» « Êtes-vous vraiment la personne que vous prétendez être ? » L'autorisation demande : « Êtes-vous autorisé à … ? » L'authentification est le processus d'obtention des informations d'identification, comme le nom et le mot de passe, d'un utilisateur, puis leur validation par rapport à une autorité, telle qu'une base de données. Si les informations d'identification sont valides, l'entité qui a soumis ces informations est considérée comme étant une identité authentifiée. Par exemple, tous les utilisateurs doivent fournir un nom d'utilisateur et un mot de passe chaque fois qu'ils se connectent à un réseau. Ces informations d'identification sont ensuite validées par rapport à une autorité, comme une base de données ou un serveur de domaine Windows. Lorsqu'une identité a été authentifiée, le processus d'autorisation détermine si l'identité en question a accès à une ressource spécifiée. Le processus d'autorisation limite les droits d'accès en accordant ou en refusant des autorisations spécifiques à une identité authentifiée. Par exemple, vous pouvez autoriser un utilisateur à accéder à l'imprimante couleur, mais refuser cet accès à un autre utilisateur. De même, vous pouvez n'autoriser que les utilisateurs d'un groupe à accéder à l'imprimante couleur et refuser cet accès aux autres utilisateurs. La sécurité basée sur les rôles dans .NET Framework implique essentiellement l'autorisation. © 2004 Microsoft Corporation. All rights reserved. This presentation is for informational purposes only. Microsoft makes no warranties, express or implied, in this summary.

Identités et entités de sécurité MGB 2003 Identités et entités de sécurité Une identité contient des informations sur un utilisateur, comme son nom de connexion Une entité de sécurité contient des informations de rôle sur un utilisateur ou un ordinateur .NET Framework propose : Les objets WindowsIdentity et WindowsPrincipal Les objets GenericIdentity et GenericPrincipal Une identité contient des informations sur l'identité de l'utilisateur, comme son nom de connexion, et indique si l'utilisateur est authentifié. Une entité de sécurité contient des informations sur l'appartenance à un rôle d'un utilisateur ou d'un ordinateur. .NET Framework implémente deux types principaux d'identités et d'entités de sécurité. Les objets WindowsIdentity et WindowsPrincipal fournissent les informations d'identification Windows d'un utilisateur. Les objets GenericIdentity et GenericPrincipal permettent au développeur d'implémenter sa propre technique d'authentification. Les diapositives suivantes montrent comment créer des entités de sécurité et des identités Windows et génériques, puis comment les utiliser pour effectuer des vérifications de sécurité basées sur les rôles. © 2004 Microsoft Corporation. All rights reserved. This presentation is for informational purposes only. Microsoft makes no warranties, express or implied, in this summary.

Création d'identités et d'entités de sécurité Windows MGB 2003 Création d'identités et d'entités de sécurité Windows Utiliser les objets WindowsIdentity et WindowsPrincipal pour : Une validation Plusieurs validations WindowsIdentity mon_Ident = WindowsIdentity.GetCurrent(); WindowsPrincipal mon_Ent = new WindowsPrincipal(mon_Ident); Vous pouvez créer des identités et des entités de sécurité Windows pour des utilisateurs à partir de leurs informations d'identification Windows. Vous pouvez pour ce faire utiliser l'une ou l'autre des approches présentées dans la diapositive, mais le premier exemple de code est plus efficace si l'entité de sécurité et l'identité sont extraites pour une seule vérification, tandis que le second convient mieux si plusieurs vérifications doivent intervenir. Après avoir créé les identités et entités de sécurité Windows, vous pouvez les utiliser pour effectuer des vérifications de sécurité. AppDomain.CurrentDomain.SetPrincipalPolicy(PrincipalPolicy.WindowsPrincipal); WindowsPrincipal mon_Ent = System.Threading.Thread.CurrentPrincipal; © 2004 Microsoft Corporation. All rights reserved. This presentation is for informational purposes only. Microsoft makes no warranties, express or implied, in this summary.

Création d'identités et d'entités de sécurité génériques MGB 2003 Création d'identités et d'entités de sécurité génériques Créer un objet GenericIdentity et un objet GenericPrincipal Attacher l'objet GenericPrincipal au thread actuel GenericIdentity mon_Ident = new GenericIdentity("Utilisateur1"); string[] roles = {"Directeur", "Caissier"}; GenericPrincipal mon_Ent = new GenericPrincipal(mon_Ident, roles); La création d'objets GenericIdentity et GenericPrincipal est utile lorsque vous voulez implémenter des techniques d'authentification personnalisées, pour, par exemple, rechercher des informations d'identification dans une base de données au lieu d'effectuer l'authentification en fonction des informations d'identification Windows d'un utilisateur. La diapositive présente un exemple de code qui permet de créer des identités et entités de sécurité génériques. Après avoir créé les identités et entités de sécurité génériques, vous pouvez les utiliser pour effectuer des vérifications de sécurité, comme nous allons le voir ensuite. System.Threading.Thread.CurrentPrincipal = mon_Ent; © 2004 Microsoft Corporation. All rights reserved. This presentation is for informational purposes only. Microsoft makes no warranties, express or implied, in this summary.

Réalisation de vérifications de sécurité MGB 2003 Réalisation de vérifications de sécurité Utiliser les membres identité et entité dans du code Par exemple, en utilisant la propriété Name de l'objet Identity pour vérifier le nom de connexion de l'utilisateur Par exemple, en utilisant la méthode IsInRole de l'objet Principal pour vérifier l'appartenance à un rôle if (String.Compare(mon_Ent.Identity.Name, "DOMAINE\\Fred", true)==0) { // Effectuer une action } Maintenant que vous avez vu comment créer des identités et des entités de sécurité, vous pouvez les utiliser pour effectuer des vérifications de sécurité dans votre code. La diapositive montre deux exemples. Le premier exemple de code effectue une comparaison de chaînes ne respectant pas la casse entre la propriété Name de l'identité actuelle et une chaîne codée de manière irréversible. Le second utilise la méthode IsInRole pour vérifier l'appartenance à un rôle. Dans cet exemple, le code vérifie si l'entité de sécurité est membre du groupe prédéfini Administrateurs. if (mon_Ent.IsInRole("BUILTIN\\Administrateurs")) { // Effectuer une action } © 2004 Microsoft Corporation. All rights reserved. This presentation is for informational purposes only. Microsoft makes no warranties, express or implied, in this summary.

Vérifications de sécurité impératives et déclaratives MGB 2003 Vérifications de sécurité impératives et déclaratives Utiliser des autorisations pour effectuer des vérifications de sécurité basées sur les rôles Vérifications impératives PrincipalPermission aut_Ent = new PrincipalPermission("Caissier", “Directeur”, true); try { aut_Ent.Demand(); //Les éléments ci-dessus correspondent-ils à ceux de l'entité de sécurité active ? } Vous pouvez également utiliser les approches impérative et déclarative pour les vérifications de sécurité basées sur des rôles. Le premier exemple de code de la diapositive est une vérification de sécurité impérative visant à déterminer si les autorisations de l'entité de sécurité active correspondent à celles de l'objet nouvellement créé aut_Ent. L'appel à la méthode Demand lèvera une exception de sécurité si les autorisations diffèrent. Cette approche est utile si vous souhaitez sécuriser des actions spécifiques dans votre code. Le second exemple de la diapositive utilise la sécurité déclarative. L'attribut représenté peut être appliqué à une classe ou à une méthode individuelle, de sorte qu'une vérification de la sécurité intervient lorsque la classe ou la méthode en question est utilisée. Le processus déclaratif permet d'effectuer les mêmes types de vérifications que l'approche impérative, mais facilite le passage en revue des autorisations requises pour une classe ou une méthode. Toutefois, comme les vérifications ne s'appliquent qu'à des classes ou à des méthodes, cette approche offre moins de souplesse que la vérification impérative. Vérifications déclaratives [PrincipalPermission(SecurityAction.Demand, Role="Caissier", Authenticated=true)] © 2004 Microsoft Corporation. All rights reserved. This presentation is for informational purposes only. Microsoft makes no warranties, express or implied, in this summary.

Démonstration 2 Sécurité basée sur les rôles MGB 2003 Démonstration 2 Sécurité basée sur les rôles Dans cette démonstration, vous allez apprendre comment : Utiliser la sécurité Windows basée sur les rôles dans votre code. Utiliser la sécurité générique basée sur les rôles dans votre code. © 2004 Microsoft Corporation. All rights reserved. This presentation is for informational purposes only. Microsoft makes no warranties, express or implied, in this summary.

Programme Fonctionnalités de sécurité de .NET Framework MGB 2003 Programme Fonctionnalités de sécurité de .NET Framework Sécurité basée sur les rôles Sécurité d'accès au code Cryptographie Dans cette section, nous allons présenter la sécurité d'accès au code. En particulier, nous allons traiter des sujets suivants : Sécurité basée sur les preuves. Stratégies de sécurité. Vérifications de sécurité. Utilisation des vérifications de sécurité. Demandes d'autorisations. Applications avec confiance partielle. Mise en sandbox de code privilégié. © 2004 Microsoft Corporation. All rights reserved. This presentation is for informational purposes only. Microsoft makes no warranties, express or implied, in this summary.

Sécurité basée sur les preuves MGB 2003 Sécurité basée sur les preuves Les preuves Sont évaluées au chargement d'un assembly Servent à déterminer les autorisations de l'assembly Peuvent comprendre les éléments suivants de l'assembly : Informations de nom fort URL Zone Signature Authenticode La sécurité Win32 fonctionne sur le principe de l'authentification et des autorisations des utilisateurs. Par exemple, si un utilisateur insère une disquette dans l'ordinateur, affiche la liste des répertoires et choisit d'exécuter le fichier fais_moi_confiance.exe, le système d'exploitation obtempérera et exécutera l'application dans le contexte de sécurité de l'utilisateur qui a ouvert la session. Par conséquent, l'application (qui peut être malveillante) disposera de tous les privilèges système accordés à l'utilisateur en question. .NET vous propose le concept de sécurité basée sur les preuves. Cette sécurité s'ajoute à celle de Win32 ; elle ne la remplace pas. Quel que soit l'utilisateur qui a ouvert la session, .NET Framework collecte des preuves sur un assembly et les présente au système de sécurité. Une fois les preuves rassemblées, le runtime décidera si le code sera ou non autorisé à exécuter toutes les tâches qu'il demande. Certaines preuves sont considérées comme étant plus fortes que d'autres par le runtime. Par exemple, les noms forts et les signatures Authenticode sont considérées comme étant plus fortes que les preuves d'URL ou de zone, car il est plus difficile pour un intrus de falsifier les valeurs de ces éléments. Les développeurs peuvent créer leurs propres preuves uniques. Par exemple, ils peuvent créer des preuves indiquant qu'un assembly a été développé en interne et revu par le service informatique pour vérifier l'absence de défauts de sécurité. © 2004 Microsoft Corporation. All rights reserved. This presentation is for informational purposes only. Microsoft makes no warranties, express or implied, in this summary.

Stratégies de sécurité MGB 2003 Stratégies de sécurité Entité de sécurité Description Stratégie Définie par les administrateurs Appliquée au moment de l'exécution Simplifie l'administration Contient des autorisations Contient des groupes de codes Groupe de codes Associe des composants similaires Basé sur les preuves Lié à un ou plusieurs jeux d'autorisations Jeu d'autorisations Est un ensemble d'autorisations accordées Contrairement à de nombreux systèmes de sécurité, la stratégie de sécurité de .NET Framework se base sur l'identité de l'assembly, et non sur celle de l'utilisateur. Les stratégies de sécurité mappent les preuves d'un assembly aux autorisations accordées pour cet assembly. Les stratégies de sécurité utilisent des groupes de codes et des niveaux de stratégie pour effectuer ce mappage. .NET Framework comprend plusieurs niveaux de configuration de stratégie, avec notamment des paramètres entreprise, ordinateur et utilisateur. Les développeurs peuvent utiliser une intersection de différents paramètres de stratégie pour déterminer des autorisations. Les groupes de codes et les niveaux de stratégie donnent aux administrateurs un contrôle plus précis sur la stratégie de sécurité. Les administrateurs peuvent configurer des stratégies afin d'accorder un ensemble d'autorisations pour l'assembly en fonction de diverses preuves. Les administrateurs peuvent utiliser Active Directory pour déployer plus facilement les stratégies de sécurité. © 2004 Microsoft Corporation. All rights reserved. This presentation is for informational purposes only. Microsoft makes no warranties, express or implied, in this summary.

Parcours de pile et vérification de la sécurité MGB 2003 Parcours de pile et vérification de la sécurité Pile des appels 1. Un assemblyA demande l'accès à une méthode de votre assembly 2. Votre assemblyB transmet la demande à un assembly .NET Framework 3. Le système de sécurité vérifie que les appelants de la pile disposent des autorisations requises 4. Le système de sécurité accorde l'accès ou lève une exception AssemblyA Accorder : Execute Appel à ReadFile Votre_AssemblyB Accorder : ReadFile Appel à ReadFile Lorsqu'un code qui accède à une ressource protégée demande une autorisation, un parcours de pile intervient. Le système de sécurité vérifie l'autorisation accordée à chaque appelant. Si l'appelant reçoit l'autorisation, la demande aboutit, sinon, une exception de sécurité est levée. Cette approche empêche un assembly dépourvu d'autorisations et utilisant vos assemblys de réaliser des actions non autorisées. Demande d'autorisation Système de sécurité Assembly .NET Framework Exception de sécurité Accès refusé Accorder l'accès ? Accorder : ReadFile © 2004 Microsoft Corporation. All rights reserved. This presentation is for informational purposes only. Microsoft makes no warranties, express or implied, in this summary.

Types de vérifications de sécurité MGB 2003 Types de vérifications de sécurité Les vérifications de sécurité impératives Créent des objets Permission Appellent des méthodes Permission Les vérifications de sécurité déclaratives Utilisent des attributs Permission S'appliquent à des méthodes ou à des classes Les vérifications de sécurité de substitution Utilisent la méthode Assert Empêchent le parcours de la pile Les vérifications de sécurité impératives impliquent la création d'instances d'objets Permission au moment de l'exécution et l'appel sur elles de méthodes telles que la méthode Demand. Par exemple, le développeur peut créer une instance de l'objet FileIOPermission et demander l'autorisation de lecture (Read) pour un fichier spécifique. Si l'appel à la méthode Demand aboutit, l'exécution se poursuit, sinon, une exception de sécurité est levée. Avec les vérifications de sécurité déclaratives, les autorisations sont spécifiées à l'aide d'attributs, et non par création d'objets Permission au moment de l'exécution. Au moment du design, les développeurs spécifient des autorisations (comme l'autorisation d'accès en lecture FileIOPermission pour un fichier spécifique) en incluant les attributs dans des définitions de classes ou des méthodes individuelles. Le processus déclaratif permet de gérer les mêmes types d'autorisations que l'approche impérative, mais facilite le passage en revue des autorisations requises pour une classe ou une méthode. Toutefois, comme les autorisations ne s'appliquent qu'à des classes ou à des méthodes, cette approche offre moins de souplesse que la vérification impérative. Lorsqu'il obtient les preuves pour les vérifications de sécurité impératives et déclaratives, le runtime parcourt la pile pour s'assurer qu'un code situé plus haut dans la pile et disposant de moins de privilèges ne tente pas d'exécuter du code pour lequel il n'a normalement pas d'autorisations. Toutefois, vous pouvez utiliser la méthode Assert pour modifier le comportement du parcours de pile. Lorsque la méthode dans laquelle vous appelez Assert est atteinte, le parcours de la pile s'arrête. Cela signifie que les autorisations des appelants de votre code ne sont pas vérifiées. La méthode Assert est particulièrement utile lorsque votre code doit accéder à une ressource protégée, mais qu'il ne donne pas à ses appelants l'accès à cette ressource. © 2004 Microsoft Corporation. All rights reserved. This presentation is for informational purposes only. Microsoft makes no warranties, express or implied, in this summary.

Demandes d'autorisations MGB 2003 Demandes d'autorisations Utilisées par les développeurs pour indiquer les autorisations requises Implémentées sous forme d'attributs Empêchent le chargement d'un assembly en cas d'absence des autorisations minimales Les développeurs utilisent des demandes d'autorisations pour déclarer les besoins en autorisations de leurs assemblys. Les demandes d'autorisations sont implémentées sous forme d'attributs d'assemblys. L'utilisation de demandes d'autorisations facilite l'exécution d'un code disposant de moins de privilèges. Si un assembly ne reçoit pas sa demande d'autorisations minimales au moment du chargement, il ne se charge pas, plutôt que d'attendre qu'une opération non autorisée soit tentée, puis échoue. Dans l'exemple de la diapositive, un assembly demande l'autorisation de code non managé. Si cette autorisation est refusée au moment du chargement, l'assembly ne continue pas. //Je ne m'exécuterai que si je peux appeler du code non managé [assembly:SecurityPermission (SecurityAction.RequestMinimum, UnmanagedCode=true)] © 2004 Microsoft Corporation. All rights reserved. This presentation is for informational purposes only. Microsoft makes no warranties, express or implied, in this summary.

MGB 2003 Démonstration 3 Sécurité d'accès au code Réalisation de vérifications de sécurité Demandes d'autorisations Dans cette démonstration, vous allez apprendre comment : Utiliser l'outil Configuration .NET Framework pour configurer des autorisations. Effectuer des vérifications de sécurité dans votre code. Demander des autorisations pour votre code. © 2004 Microsoft Corporation. All rights reserved. This presentation is for informational purposes only. Microsoft makes no warranties, express or implied, in this summary.

Programme Fonctionnalités de sécurité de .NET Framework MGB 2003 Programme Fonctionnalités de sécurité de .NET Framework Sécurité basée sur les rôles Sécurité d'accès au code Cryptographie Dans cette section, nous allons présenter la cryptographie. En particulier, nous allons traiter des sujets suivants : Rappels concernant la cryptographie. Cryptage symétrique. Cryptage asymétrique. Signature de données. © 2004 Microsoft Corporation. All rights reserved. This presentation is for informational purposes only. Microsoft makes no warranties, express or implied, in this summary.

Rappels concernant la cryptographie MGB 2003 Rappels concernant la cryptographie Terme de cryptographie Description Cryptage symétrique Cryptage et décryptage des données avec une clé secrète Cryptage asymétrique Cryptage et décryptage des données avec une paire clé publique/clé privée Hachage Mappage d'une longue chaîne de données à une chaîne de données courte, de taille fixe Signature numérique Hachage de données et cryptage de la valeur de hachage avec une clé privée Le cryptage symétrique vous permet de crypter et de décrypter des données en utilisant une clé secrète unique. Si la clé secrète est compromise, toutes les données cryptées à l'aide de cette clé peuvent être décryptées. Le cryptage asymétrique vous permet de crypter et de décrypter des données en utilisant une paire clé publique/clé privée. Vous pouvez distribuer librement la clé publique, mais la clé privée doit être gardée secrète. Les données cryptées avec la clé publique ne peuvent être décryptées qu'avec la clé privée et vice versa. Le hachage est le processus qui consiste à mapper une chaîne de données plus longue, comme un fichier, à une petite chaîne de données de taille fixe, comme une valeur de hachage 160 bits. La signature numérique est le processus qui consiste à crypter une valeur de hachage avec une clé privée et à distribuer cette signature avec les données. Lorsqu'un destinataire reçoit les données, il peut les décrypter avec la clé publique de l'expéditeur et effectuer la comparaison avec la valeur de hachage des données. Si les valeurs correspondent, l'intégrité des données est garantie. .NET Framework fournit des classes qui implémentent ces opérations © 2004 Microsoft Corporation. All rights reserved. This presentation is for informational purposes only. Microsoft makes no warranties, express or implied, in this summary.

Cryptographie et Framework.NET Plusieurs namespaces .NET consacrés à la cryptographie System.Security.Cryptography Fournis les services cryptographiques : Encodage/Décodage sécurisé des données hashing, random number, message authentication. … System.Security.Cryptography.X509Certificates Authenticode X.509 v.3 certificate. Le certificat est signé avec une  « private key » qui identifie explicitement et de manière unique le propriétaire du certificat. System.Security.Cryptography.Xml Réservé a données XML Permet de signer les « objets » XML avec une signature digitale

Cryptographie et Framework.NET Model objet du namespace Cryptography Algorithme Type : (abstract class) Algorithmes Symétrique et Hash Algorithme Class : (abstract class) RC2, SHA1… Implémentation des « Algorithmes Class » RC2CryptoServiceProvider, SHA1Managed… Grâce a ce « design pattern » il est possible de faire ses propres ajouts/implémentations aux algorithmes aux différents niveaux. Les algorithmes symétriques et de hash sont implémentés « stream-oriented » La Configuration Cryptographique Permet de résoudre les implémentations spécifiques de certains algorithmes

Utilisation d'algorithmes symétriques MGB 2003 Utilisation d'algorithmes symétriques Choisir un algorithme TripleDESCryptoServiceProvider RijndaelManaged Générer une clé secrète Utiliser la même clé secrète pour crypter et décrypter les données : FileStream MemoryStream NetworkStream Les étapes de base de l'utilisation d'algorithmes de cryptage symétrique sont : Choisir l'algorithme à utiliser. .NET Framework fournit des classes wrapper pour travailler avec le cryptage symétrique, comme les classes TripleDESCryptoServiceProvider et RijndaelManaged. Générer une clé secrète en utilisant la classe wrapper .NET que vous avez choisie. Les algorithmes symétriques ont besoin de cette clé pour crypter et décrypter des données. Le constructeur de classe peut créer ces valeurs, mais vous pouvez aussi fournir les vôtres. Utiliser la même clé pour crypter et décrypter les données. Vous pouvez crypter des données à l'aide de n'importe quelle classe dérivée de la classe Stream, notamment FileStream, MemoryStream et NetworkStream. © 2004 Microsoft Corporation. All rights reserved. This presentation is for informational purposes only. Microsoft makes no warranties, express or implied, in this summary.

Utilisation d'algorithmes asymétriques MGB 2003 Utilisation d'algorithmes asymétriques Choisir un algorithme RSACryptoServiceProvider DSACryptoServiceProvider Générer une paire clé privée/clé publique Crypter ou décrypter les données Les étapes de base de l'utilisation d'algorithmes de cryptage asymétrique sont : Choisir l'algorithme à utiliser. .NET Framework fournit des classes wrapper pour travailler avec le cryptage asymétrique, comme les classes RSACryptoServiceProvider et DSACryptoServiceProvider. Ces classes utilisent les algorithmes bien connus auxquels elles doivent leur nom Générer les clés publique et privée en utilisant la classe wrapper .NET que vous avez choisie. Les algorithmes asymétriques utilisent une clé publique et une clé privée pour effectuer les opérations cryptographiques. Certaines opérations, comme la création et le décryptage d'une signature, nécessitent une clé privée. D'autres opérations, comme la vérification et le cryptage d'une signature, nécessitent une clé publique. Utiliser la clé appropriée lors du cryptage ou du décryptage des données. Par exemple, utilisez la clé publique si vous cryptez des données, et la clé privée si vous décryptez des données. Vous pouvez crypter et décrypter des données à l'aide de n'importe quelle classe dérivée de la classe Stream, notamment FileStream, MemoryStream et NetworkStream. © 2004 Microsoft Corporation. All rights reserved. This presentation is for informational purposes only. Microsoft makes no warranties, express or implied, in this summary.

Signature de données et vérification de signatures MGB 2003 Signature de données et vérification de signatures Action Procédures Signature des données Hacher les données Crypter la valeur de hachage avec une clé privée Vérification de signatures Décrypter la signature en utilisant la clé publique de l'expéditeur Comparer la signature décryptée avec la valeur de hachage Signer des données empêche la falsification et affirme l'identité du signataire. Dans certains cas, vous serez amené à signer des données pour assurer d'autres personnes de votre identité, dans d'autres, vous souhaiterez vérifier une signature afin d'être certain que les données proviennent bien d'une source spécifique. La signature de données et la vérification de signatures impliquent les étapes suivantes : Signature de données. Hacher les données, puis utiliser un algorithme asymétrique pour créer une signature. Vérification de la signature. Décrypter la signature, hacher les données, puis utiliser un algorithme asymétrique pour vérifier la signature. © 2004 Microsoft Corporation. All rights reserved. This presentation is for informational purposes only. Microsoft makes no warranties, express or implied, in this summary.

DPAPI Data Protection API API Windows de cryptage décryptage Wrapper .NET 1.0 et 1.1 nécessaire Accessible dans la CLR 2.0 :

Crytography Application Block http://msdn.microsoft.com/library/default.asp?url=/library/en-us/dnpag2/html/crypto1.asp Cryptography Application Block : Réduit le temps de développement sur le code standard de cryptographie Aide à maintenir les bonnes pratiques en terme de cryptographie Apprentissage aisé car le modèle d’architecture est constant quelque soit les fonctionnalités. Fournis une implémentation standard de l’utilisation des techniques de cryptographie. Code extensible; supportant d’addinitionnelles implémentation et providers de cryptographie.

MGB 2003 Démonstration 4 Cryptage .NET Framework Cryptage des données PAG Security Dans cette démonstration, vous allez apprendre comment : Effectuer un cryptage symétrique sur des données. Signer des données par programme. © 2004 Microsoft Corporation. All rights reserved. This presentation is for informational purposes only. Microsoft makes no warranties, express or implied, in this summary.

Programme Fonctionnalités de sécurité de .NET Framework MGB 2003 Programme Fonctionnalités de sécurité de .NET Framework Sécurité basée sur les rôles Sécurité d'accès au code Cryptographie SQL Server 2005 : quoi de neuf ? Dans cette section, nous allons présenter la cryptographie. En particulier, nous allons traiter des sujets suivants : Rappels concernant la cryptographie. Cryptage symétrique. Cryptage asymétrique. Signature de données. © 2004 Microsoft Corporation. All rights reserved. This presentation is for informational purposes only. Microsoft makes no warranties, express or implied, in this summary.

SQL Server 2005 Conférence SQL DAYS 2005 Une journée gratuite Paris, le 9 juin 2005 Marseille, le 14 juin 2005 Toulouse, le 16 juin 2005 Une journée gratuite www.microsoft.com/france/sql/sqldays.aspx

MGB 2003 Démonstration 5 SQL Server 2005 Execution Context Encryption .NET Assemblies Dans cette démonstration, vous allez apprendre comment : Effectuer un cryptage symétrique sur des données. Signer des données par programme. © 2004 Microsoft Corporation. All rights reserved. This presentation is for informational purposes only. Microsoft makes no warranties, express or implied, in this summary.

Résumé de la session Fonctionnalités de sécurité de .NET Framework MGB 2003 Résumé de la session Fonctionnalités de sécurité de .NET Framework Sécurité d'accès au code Sécurité basée sur les rôles Cryptographie SQL Server 2005 © 2004 Microsoft Corporation. All rights reserved. This presentation is for informational purposes only. Microsoft makes no warranties, express or implied, in this summary.

Étapes suivantes Être informé sur la sécurité MGB 2003 Étapes suivantes Être informé sur la sécurité S'inscrire aux bulletins de sécurité : http://www.microsoft.com/security/security_bulletins/alerts2.asp (en anglais) Obtenir l'aide la plus récente de Microsoft sur la sécurité : http://www.microsoft.com/france/securite/default.asp Obtenir des activités de formation supplémentaires sur la sécurité Trouver des séminaires de formation : http://www.microsoft.com/france/events/default.asp Trouver un centre de formation local agréé Microsoft (CTEC) pour des cours pratiques : http://www.microsoft.com/france/formation/centres/recherche.asp Les étapes suivantes comprennent la visite du site Web de Microsoft pour : Obtenir les informations les plus récentes sur la sécurité. Obtenir des activités de formation supplémentaires sur la sécurité. © 2004 Microsoft Corporation. All rights reserved. This presentation is for informational purposes only. Microsoft makes no warranties, express or implied, in this summary.

Pour plus d'informations MGB 2003 Pour plus d'informations Site Microsoft sur la sécurité (tout public) http://www.microsoft.com/france/securite/default.asp Site MSDN sur la sécurité (développeurs) http://msdn.microsoft.com/security (en anglais) Site TechNet sur la sécurité (informaticiens) http://www.microsoft.com/france/technet/themes/ secur/default.asp Des informations techniques supplémentaires pour les informaticiens et les développeurs sont disponibles sur les sites Web suivants : Site Microsoft sur la sécurité (tout public) http://www.microsoft.com/france/securite/default.asp Site MSDN sur la sécurité (développeurs) http://msdn.microsoft.com/security (en anglais) Site TechNet sur la sécurité (informaticiens) http://www.microsoft.com/technet/security (en anglais) et http://www.microsoft.com/France/technet/default.asp © 2004 Microsoft Corporation. All rights reserved. This presentation is for informational purposes only. Microsoft makes no warranties, express or implied, in this summary.

Questions et réponses MGB 2003 © 2004 Microsoft Corporation. All rights reserved. This presentation is for informational purposes only. Microsoft makes no warranties, express or implied, in this summary.

MGB 2003 © 2004 Microsoft Corporation. All rights reserved. This presentation is for informational purposes only. Microsoft makes no warranties, express or implied, in this summary.

BD Saisie infos Fabrique de Classe Validation mot de passe Comment éviter la saisie du mot de passe en claire ? Saisie infos Comment faire confiance qui appel ma fabrique de classe ? Comment faire confiance dans les dlls chargées dynamiquement ? Fabrique de Classe Sous quelle forme dois-je stocker le mot de passe ? Validation mot de passe BD Sous quelle forme dois-je stocker la chaînes de connexion ? Chargement des rôles Affecter les politiques de sécurité