Remarque
L’accès à cette page nécessite une autorisation. Vous pouvez essayer de vous connecter ou de modifier des répertoires.
L’accès à cette page nécessite une autorisation. Vous pouvez essayer de modifier des répertoires.
La sécurisation d’une application est un processus continu. Il n’y aura jamais de point où un développeur peut garantir qu’une application est sécurisée contre toutes les attaques, car il est impossible de prédire quels types d’attaques futures nouvelles technologies apporteront. À l'inverse, le simple fait que personne n'ait encore découvert (ou publié) de failles de sécurité dans un système ne signifie pas qu'il n'en existe pas ou qu'il ne pourrait pas en exister. Vous devez planifier la sécurité pendant la phase de conception du projet, ainsi que planifier la façon dont la sécurité sera maintenue pendant la durée de vie de l’application.
Conception pour la sécurité
L’un des problèmes les plus importants dans le développement d’applications sécurisées est que la sécurité est souvent une chose à implémenter après la fin du code d’un projet. Ne pas intégrer la sécurité dès la conception d'une application conduit à des applications peu sécurisées, car on n’a guère réfléchi à ce qui rend une application sécurisée.
L’implémentation de la sécurité de dernière minute entraîne davantage de bogues, car les logiciels s’interrompent sous les nouvelles restrictions ou doivent être réécrits pour prendre en charge les fonctionnalités inattendues. Chaque ligne de code révisé contient la possibilité d’introduire un nouveau bogue. Pour cette raison, vous devez envisager la sécurité dès le début du processus de développement afin qu’elle puisse continuer en tandem avec le développement de nouvelles fonctionnalités.
Modélisation des menaces
Vous ne pouvez pas protéger un système contre les attaques, sauf si vous comprenez toutes les attaques potentielles auxquelles elle est exposée. Le processus d’évaluation des menaces de sécurité, appelé modélisation des menaces, est nécessaire pour déterminer la probabilité et les ramifications des violations de sécurité dans votre application ADO.NET.
La modélisation des menaces se compose de trois étapes générales : comprendre la vue de l’adversaire, caractériser la sécurité du système et déterminer les menaces.
La modélisation des menaces est une approche itérative de l’évaluation des vulnérabilités dans votre application pour trouver celles qui sont les plus dangereuses, car elles exposent les données les plus sensibles. Une fois que vous avez identifié les vulnérabilités, vous les classez dans l’ordre de gravité et créez un ensemble hiérarchisé de contre-mesures pour contrer les menaces.
Pour plus d’informations, consultez les ressources suivantes :
| Ressource | Descriptif |
|---|---|
| Site de modélisation des menaces sur le portail d’ingénierie de sécurité | Les ressources de cette page vous aideront à comprendre le processus de modélisation des menaces et à créer des modèles de menace que vous pouvez utiliser pour sécuriser vos propres applications |
Le principe du privilège minimum
Lorsque vous concevez, générez et déployez votre application, vous devez supposer que votre application sera attaquée. Souvent, ces attaques proviennent de code malveillant qui s’exécute avec les autorisations de l’utilisateur exécutant le code. D’autres peuvent provenir de code bien intentionné qui a été exploité par un attaquant. Lors de la planification de la sécurité, supposons toujours que le pire scénario se produit.
Une contre-mesure que vous pouvez utiliser consiste à essayer d’ériger autant de murs autour de votre code que possible en exécutant avec le moins de privilèges. Le principe du privilège minimum indique que tout privilège donné doit être accordé au moins grand nombre de code nécessaire pour la durée la plus courte nécessaire à l’exécution du travail.
La meilleure pratique pour la création d’applications sécurisées consiste à commencer sans autorisations du tout, puis à ajouter les autorisations les plus étroites pour la tâche particulière en cours d’exécution. En revanche, commencer par accorder toutes les autorisations et ensuite refuser certaines permissions individuelles aboutit à des applications non sécurisées, difficiles à tester et à maintenir, car des failles de sécurité peuvent exister en raison de l'octroi involontaire de plus d'autorisations que nécessaire.
Pour plus d’informations sur la sécurisation de vos applications, consultez les ressources suivantes :
| Ressource | Descriptif |
|---|---|
| Sécurisation des applications | Contient des liens vers des rubriques de sécurité générales. Contient également des liens vers des rubriques permettant de sécuriser les applications distribuées, les applications web, les applications mobiles et les applications de bureau. |
Sécurité d'accès du code
La sécurité de l'accès au code (CAS) est un mécanisme qui aide à limiter l'accès que le code a aux ressources et opérations protégées. Dans .NET Framework, le service d’administration centrale exécute les fonctions suivantes :
Définit les autorisations et les jeux d’autorisations qui représentent le droit d’accéder à diverses ressources système.
Permet aux administrateurs de configurer la stratégie de sécurité en associant des ensembles d’autorisations à des groupes de code (groupes de codes).
Permet au code de demander les autorisations dont il a besoin pour s’exécuter, ainsi que les autorisations qui seraient utiles et spécifie les autorisations dont le code ne doit jamais disposer.
Accorde des autorisations à chaque assembly chargé, en fonction des autorisations demandées par le code et des opérations autorisées par la stratégie de sécurité.
Permet au code de demander que ses appelants disposent d’autorisations spécifiques.
Permet au code de demander que ses appelants possèdent une signature numérique, ce qui permet uniquement aux appelants d’une organisation ou d’un site particulier d’appeler le code protégé.
Applique des restrictions sur le code au moment de l’exécution en comparant les autorisations accordées à chaque appelant sur la pile des appels aux autorisations dont les appelants doivent disposer.
Pour réduire la quantité de dommages qui peuvent se produire si une attaque réussit, choisissez un contexte de sécurité pour votre code qui accorde l’accès uniquement aux ressources dont il a besoin pour effectuer son travail et pas plus.
Pour plus d’informations, consultez les ressources suivantes :
| Ressource | Descriptif |
|---|---|
| Sécurité de l’accès au code et ADO.NET | Décrit les interactions entre la sécurité d’accès au code, la sécurité basée sur les rôles et les environnements partiellement approuvés du point de vue d’une application ADO.NET. |
| Sécurité d’accès du code | Contient des liens vers des rubriques supplémentaires décrivant la Sécurité de l'accès au code (CAS) dans le .NET Framework. |
Sécurité de base de données
Le principe du privilège minimum s’applique également à votre source de données. Voici quelques instructions générales pour la sécurité de la base de données :
Créez des comptes avec les privilèges possibles les plus bas.
N’autorisez pas les utilisateurs à accéder aux comptes d’administration simplement pour obtenir du code opérationnel.
Ne retournez pas de messages d’erreur côté serveur aux applications clientes.
Validez toutes les entrées au niveau du client et du serveur.
Utilisez des commandes paramétrables et évitez les instructions SQL dynamiques.
Activez l’audit et la journalisation de la sécurité pour la base de données que vous utilisez afin que vous soyez averti de toute violation de sécurité.
Pour plus d’informations, consultez les ressources suivantes :
| Ressource | Descriptif |
|---|---|
| Sécurité SQL Server | Fournit une vue d’ensemble de la sécurité DE SQL Server avec des scénarios d’application qui fournissent des conseils pour la création d’applications sécurisées ADO.NET qui ciblent SQL Server. |
| Recommandations pour les stratégies d’accès aux données | Fournit des recommandations pour accéder aux données et effectuer des opérations de base de données. |
Stratégie de sécurité et administration
L’administration incorrecte de la stratégie de sécurité d’accès au code (CAS) peut potentiellement créer des faiblesses de sécurité. Une fois qu’une application est déployée, les techniques de surveillance de la sécurité doivent être utilisées et les risques évalués à mesure que de nouvelles menaces émergent.
Pour plus d’informations, consultez les ressources suivantes :
| Ressource | Descriptif |
|---|---|
| Gestion des stratégies de sécurité | Fournit des informations sur la création et l’administration de la stratégie de sécurité. |
| Meilleures pratiques en matière de stratégie de sécurité | Fournit des liens décrivant comment administrer la stratégie de sécurité. |