Accueil Library Formation Code Téléchargements Support Evénements Communautés Forums
Ce sujet n'a pas encore été évalué - Évaluez ce sujet

Création de composants de service sécurisés

Dernière mise à jour le 31 août 2004
Sur cette page

Dans ce module Dans ce module
Objectifs Objectifs
S'applique à S'applique à
Présentation Présentation
Menaces et contre-mesures Menaces et contre-mesures
Problèmes de conception Problèmes de conception
Authentification Authentification
Autorisation Autorisation
Gestion de la configuration Gestion de la configuration
Données sensibles Données sensibles
Audit et journalisation Audit et journalisation
Création d'un composant de service sécurisé Création d'un composant de service sécurisé
Problèmes de sécurité d'accès au code Problèmes de sécurité d'accès au code
Problèmes de déploiement Problèmes de déploiement
Résumé Résumé
Informations complémentaires Informations complémentaires

Dans ce module

Les composants de service sont des services d'infrastructure COM+, également connus sous le nom de services d'entreprise. Ils sont accessibles par du code géré et comportent une ou plusieurs classes dérivées de System.EnterpriseServices.ServicedComponent.

Ce module explique comment la sécurité des services d'entreprise COM+ s'appuie sur le mécanisme Windows pour authentifier et autoriser les appelants ; il décrit aussi la robustesse des techniques de codage et montre qu'une configuration appropriée du catalogue peut assurer un déploiement sécurisé de vos composants de service.

Ce module, destiné en particulier aux développeurs, contient des exemples de création de composants de service sécurisés.

Objectifs

Ce module vous permettra :

  • de déterminer ce qu'il convient d'examiner avant de concevoir et de déployer des services d'infrastructure COM+ (composants de service) ;

  • de protéger les données sensibles ;

  • d'autoriser les appelants à utiliser des rôles de services d'entreprise (COM+) ;

  • d'utiliser les comptes « Exécuter en tant que » avec un minimum de privilèges ;

  • de sécuriser des éléments secrets dans des chaînes de constructeur d'objet ;

  • de procéder à un audit des composants de service de niveau intermédiaire ;

  • de déterminer la procédure à suivre en cas de confiance partielle puisque les composants de service exigent, pour leur part, une confiance totale ;

  • connaître les contre-mesures à appliquer pour gérer les menaces courantes pesant sur les services d'entreprise, notamment l'écoute clandestine du réseau, les accès non autorisés, la délégation non contrainte, la divulgation des données de configuration et la répudiation.

S'applique à

Ce module s'applique aux produits et technologies suivants :

  • Microsoft® Windows® 2000 Server et Microsoft Windows Server? 2003

  • Microsoft .NET Framework 1.1 et ASP.NET 1.1

Présentation

L'infrastructure COM+, également appelée services d'entreprise, est accessible par du code géré. Les applications de services d'entreprise comportent un ou plusieurs composants de service qui sont des classes gérées dérivées de System.EnterpriseServices.ServicedComponent.

Les composants de service servent habituellement à encapsuler la logique d'accès aux données et la logique métier d'une application ; ils sont utilisés lorsque des services d'infrastructure tels que des transactions distribuées, des pools d'objets, des composants en file d'attente et autres sont nécessaires dans le niveau intermédiaire de l'application. Les applications de services d'entreprise résident souvent sur des serveurs d'applications de niveau intermédiaire, comme le montre la figure 11.1.

Composants de service d'une application de services d'entreprise de niveau intermédiaire

Figure 11.1
Composants de service d'une application de services d'entreprise de niveau intermédiaire

Menaces et contre-mesures

Les principales menaces dont vous devez tenir compte lorsque vous créez des composants de services sont les suivantes :

  • Écoute clandestine du réseau

  • Accès non autorisé

  • Délégation non contrainte

  • Divulgation des données de configuration

  • Répudiation

La figure 11.2 met en évidence des menaces ainsi que les vulnérabilités courantes des composants de service.

Menaces liées aux services d'entreprise

Figure 11.2
Menaces contre les services d'entreprise

Écoute clandestine du réseau

Les applications de services d'entreprise s'exécutent souvent sur des serveurs d'applications de niveau intermédiaire, distants du serveur Web. Par conséquent, les données sensibles doivent être protégées contre l'écoute clandestine. Vous pouvez utiliser un canal crypté IPSec (Internet Protocol Security) entre le serveur d'applications et le serveur Web. Cette solution est couramment adoptée dans les centres de données Internet. Les composants de service prennent aussi en charge l'authentification au niveau paquet des procédures RPC, ce qui permet un cryptage sur la base des paquets. Cette méthode est le plus souvent employée pour sécuriser les communications vers et depuis des clients de type ordinateur de bureau.

Accès non autorisé

En activant l'autorisation à base de rôles COM+ (celle-ci est désactivée par défaut dans Microsoft Windows 2000), vous pouvez éviter un accès anonyme et mettre en place un mécanisme d'autorisation à base de rôles pour contrôler l'accès aux opérations restreintes exposées par vos composants de service.

Délégation non contrainte

Si vous activez la délégation non restreinte sur Windows 2000 afin de permettre à un serveur distant d'accéder aux ressources du réseau en utilisant le jeton d'emprunt d'identité du client, la délégation est dite « non contrainte ». En clair, le nombre de sauts réseau qu'il est possible de faire n'est pas limité. En revanche, Microsoft Windows Server 2003 introduit la délégation contrainte.

Divulgation des données de configuration

Bon nombre d'applications stockent des données sensibles telles que les chaînes de connexion à la base de données dans le catalogue COM+ en utilisant des chaînes de constructeur d'objet. Ces chaînes sont récupérées et passées à un objet par COM+ lorsque l'objet est créé. Les données sensibles de configuration doivent donc être cryptées avant d'être stockées dans le catalogue.

Répudiation

La menace de répudiation apparaît lorsqu'un utilisateur conteste l'exécution d'une opération ou d'une transaction et que vous n'avez pas suffisamment de preuves pour établir qu'il est dans son tort. Un audit doit être réalisé à tous les niveaux de l'application. Les composants de service doivent consigner les activités des utilisateurs dans le niveau intermédiaire. Ils ont généralement accès à l'identité de l'appelant d'origine du fait que les applications Web frontales activent le plus souvent l'emprunt d'identité dans les contextes de services d'entreprise.

Problèmes de conception

Avant de commencer à écrire le code, vous devez prendre en compte un certain nombre de points relatifs à la conception. Les principaux sont les suivants :

  • Autorisation basée sur les rôles

  • Protection des données sensibles

  • Exigences d'audit

  • Type d'activation d'application

  • Transactions

  • Sécurité d'accès au code

Autorisation basée sur les rôles

Pour mettre en place un mécanisme efficace d'autorisation basée sur des rôles COM+, vérifiez que le contexte de sécurité de l'appelant initial est celui qui a servi lors de l'appel au composant de service. Ce faisant, vous pouvez définir un système minutieux d'autorisation à base de rôles en fonction de l'appartenance de l'appelant à un groupe. Si une application Web ASP.NET appelle vos composants de service, c'est qu'elle a besoin d'un emprunt d'identité pour ses appelants avant de contacter votre composant.

Protection des données sensibles

Si vos composants de service gèrent des données sensibles comme des informations sur les employés, des transactions financières ou des données liées à la santé, étudiez le moyen de les protéger lorsqu'elles circulent sur le réseau. Si votre application ne s'exécute pas dans un environnement IDC (Internet Data Center) sécurisé avec IPSec pour un cryptage au niveau transport, vous pouvez utiliser à la place le cryptage RPC. Dans ce cas, vous devez utiliser le niveau d'authentification Packet Privacy. Pour plus d'informations, reportez-vous à la section « Données sensibles » plus loin dans ce module.

Exigences d'audit

Pour contrer la menace de répudiation, il convient de consigner les transactions sensibles effectuées par les composants du service d'entreprise. Au moment de la conception, examinez le type d'opérations à auditer ainsi que les détails à consigner dans un journal. Au minimum, ces données doivent inclure l'identité sous laquelle la transaction a été lancée et celle sous laquelle elle est exécutée, qui peuvent être identiques ou différentes.

Type d'activation d'application

Lors de la conception, choisissez la manière dont le composant de service sera activé. Vous pouvez les activer en utilisant une instance du processus Dllhost.exe ou les exécuter à l'intérieur du processus client. Les applications serveur s'exécutent hors processus dans une instance de Dllhost.exe. Les applications de bibliothèque s'exécutent dans l'espace d'adressage du processus du client. Ces dernières se révèlent plus efficaces en raison de l'absence de communication entre les processus. Cependant, elles sont moins configurables et ne sont pas protégées par l'isolement au niveau du processus. De nombreux paramètres de sécurité, comme les niveaux d'authentification et d'emprunt d'identité, sont hérités du processus client.

Transactions

Si vous envisagez d'utiliser des transactions distribuées, considérez à quel endroit la transaction est déclenchée et étudiez les effets dus à l'exécution de transactions entre des composants et des gestionnaires de ressources séparés par des pare-feu. Dans ce scénario, le pare-feu doit être configuré de façon à gérer le trafic DTC (Distributed Transaction Coordinator) de Microsoft.

Si votre architecture de déploiement physique inclut un serveur d'applications de niveau intermédiaire, il est préférable d'initier les transactions depuis l'application des services d'entreprise sur le serveur d'applications et non depuis l'application Web frontale.

Sécurité d'accès au code

Habituellement, les applications qui utilisent des composants de service sont totalement fiables et, par conséquent, la sécurité d'accès au code n'est pas fréquemment sollicitée pour autoriser un code appelant. Cependant, les services d'entreprise exigent que le code appelant possède l'autorisation nécessaire pour appeler du code non géré. De ce fait, vous ne pourrez pas appeler directement une application des services d'entreprise depuis une application Web disposant d'une confiance partielle. Les niveaux de confiance partielle ASP.NET (Élevé, Moyen, Faible et Minime) n'accordent pas d'autorisation sur le code non géré. Si vous devez appeler un composant de service à partir d'une application à confiance partielle, le code privilégié qui appelle votre composant doit être mis en « sandbox ». Pour plus d'informations, reportez-vous à la section « Problèmes de sécurité d'accès au code » ultérieurement dans ce module.

Authentification

Les applications de services d'entreprise utilisent l'authentification Windows. Il s'agit d'une authentification NTLM ou Kerberos, selon le système d'exploitation du serveur et de client. Dans les environnements Windows 2000 ou Windows Serveur 2003, l'authentification utilisée est Kerberos.

Le principal point à considérer lorsque vous créez des composants de service est de vous assurer que tous les appels sont authentifiés afin d'éviter que des utilisateurs anonymes n'accèdent aux fonctionnalités de vos composants.

Utilisation de l'authentification au niveau appel (au minimum)

Pour rejeter les accès anonymes, utilisez au moins l'authentification au niveau appel. Configurez ce paramètre en ajoutant l'attribut suivant dans l'assembly de votre composant de service :

[assembly: ApplicationAccessControl(
                Authentication = AuthenticationOption.Call)]

Remarque : ce paramétrage équivaut à définir le Niveau d'authentification pour les appels à Call dans l'onglet Sécurité de la boîte de dialogue Propriétés de l'application dans l'outil Services de composants.

Autorisation

Les services d'entreprise utilisent des rôles COM+ pour l'autorisation. Vous pouvez contrôler la granularité des autorisations accordées aux applications, aux composants, aux interfaces et aux méthodes. Pour éviter que des utilisateurs n'exécutent des opérations limitées exposées par les composants de service de votre application :

  • activez la sécurité basée sur les rôles ;

  • activez les vérifications d'accès au niveau composant.

  • appliquez des vérifications d'accès au niveau composant ;

Activation de la sécurité basée sur les rôles

Par défaut, la sécurité basée sur les rôles est désactivée dans Windows 2000. C'est le contraire dans Windows Server 2003. Pour garantir que ce type de sécurité est automatiquement activé lors de l'enregistrement de votre composant (généralement à l'aide de Regsvcs.exe), ajoutez l'attribut suivant dans l'assembly de votre composant de service.

[assembly: ApplicationAccessControl(true)]

Remarque : l'utilisation de cet attribut équivaut à sélectionner Appliquer les vérifications d'accès pour cette application dans l'onglet Sécurité de la boîte de dialogue Propriétés de l'application dans l'outil Services de composants.

Activation des vérifications d'accès au niveau composant

Il est nécessaire d'activer des vérifications d'accès au niveau composant pour permettre le contrôle des rôles au niveau des composants, des interfaces ou des méthodes. Pour garantir que ces vérifications sont automatiquement activées lors de l'enregistrement de votre composant, ajoutez l'attribut suivant dans l'assembly de votre composant de service.

[assembly: ApplicationAccessControl(AccessChecksLevel=
               AccessChecksLevelOption.ApplicationComponent)]

Remarque : l'utilisation de cet attribut équivaut à sélectionner Effectuer les vérifications d'accès au niveau du processus et des composants dans l'onglet Sécurité de la boîte de dialogue Propriétés de l'application dans l'outil Services de composants.

Application des vérifications d'accès au niveau composant

Pour que des composants individuels puissent vérifier les accès, vous devez appliquer les vérifications d'accès au niveau composant. Ce paramètre n'est effectif que si le niveau de sécurité à l'échelle de l'application est défini pour les niveaux processus et composants, comme indiqué plus haut. Pour garantir que ces vérifications sont automatiquement activées lors de l'enregistrement de votre composant, ajoutez l'attribut suivant dans les classes de votre composant de service.

[ComponentAccessControl(true)]
public class YourServicedComponent : ServicedComponent
{
}

Remarque : l'utilisation de cet attribut équivaut à sélectionner Appliquer les vérifications d'accès au niveau du composant dans l'onglet Sécurité de la boîte de dialogue Propriétés du composant dans l'outil Services de composants.

Gestion de la configuration

Parallèlement aux paramètres configurables proposés par COM+ aux administrateurs par le biais de l'outil Services de composants, les développeurs définissent souvent dans le code des fonctions relatives à la configuration. Ainsi, des fonctions peuvent extraire des chaînes de construction d'objet stockées dans le catalogue COM+. Lorsque vous choisissez de gérer la configuration avec les services d'entreprise, vous devez essentiellement :

  • utiliser des comptes « Exécuter en tant que » disposant du minimum de privilèges ;

  • éviter de stocker des éléments secrets dans des chaînes de constructeur d'objet ;

  • éviter la délégation non contrainte.

Utilisation de comptes « Exécuter en tant que » disposant du minimum de privilèges

Lors du développement, exécutez et testez vos composants de service en utilisant un compte local avec un minimum de privilèges au lieu du compte utilisateur interactif. Configurez-le afin qu'il soit le plus proche possible du compte « Exécuter en tant que » que l'administrateur utilisera probablement dans l'environnement de production.

Pas de stockage d'éléments secrets dans des chaînes de constructeur d'objet

Si vous stockez des éléments secrets tels que des chaînes de connexion à la base de données ou des mots de passe dans des chaînes de constructeur d'objet du catalogue COM+, n'importe quel membre du groupe des administrateurs locaux pourra les visualiser en clair. Essayez de ne pas stocker de données secrètes. Si vous devez toutefois le faire, cryptez-les. L'interface DPAPI est une option de mise en œuvre adaptée qui peut vous épargner les problèmes associés à la gestion des clés.

Au moment de l'exécution, récupérez la chaîne de construction d'objet et utilisez DPAPI pour décrypter les données. Pour plus d'informations sur l'utilisation de DPAPI à partir de code géré, reportez-vous à la section « How to create a DPAPI library » dans l'article MSDN « Building Secure ASP.NET Applications » à l'adresse http://msdn.microsoft.com/library/en-us/dnnetsec/html/secnetlpMSDN.asp.

[ConstructionEnabled(Default="")]
public class YourServicedComponent : ServicedComponent, ISomeInterface
{
  // Le constructeur d'objet est appelé en premier.
  public YourServicedComponent() {}
  // Puis la chaîne de construction d'objet est passée à la méthode Construct.
  protected override void Construct(string constructString)
  {
    // Utiliser DPAPI pour décrypter les données de configuration.
  }
}

Pas de délégation non contrainte

Les clients des composants de service sont authentifiés par l'authentification NTLM ou Kerberos, selon l'environnement. Kerberos, dans Windows 2000, prend en charge la délégation non contrainte : cela signifie, le nombre de sauts réseau qu'il est possible d'exécuter avec les données d'identification du client n'est pas limité.

Si ASP.NET est le client, vous pouvez définir l'attribut comImpersonation en fonction de l'élément <processModel> dans le fichier Machine.config afin de configurer le niveau d'emprunt d'identité :

comImpersonationLevel="[Default|Anonymous|Identify|Impersonate|Delegate]"

Le niveau d'emprunt d'identité défini pour une application serveur de services d'entreprise détermine les possibilités d'emprunt d'identité des serveurs distants avec lesquels les composants de service communiquent. Dans ce cas, les composants de service sont les clients. Vous pouvez spécifier le niveau d'emprunt d'identité pour un composant de service, applicable lorsque le composant est un client, au moyen de l'attribut suivant :

[assembly: ApplicationAccessControl(
                ImpersonationLevel=ImpersonationLevelOption.Identify)]

Remarque : l'utilisation de cet attribut équivaut à définir la valeur Niveau d'emprunt d'identité dans la page Sécurité de la boîte de dialogue Propriétés de l'application dans l'outil Services de composants.

Le tableau suivant décrit l'impact de chacun de ces niveaux.

Tableau 11.1 : Niveaux d'emprunt d'identité

Niveau d'emprunt d'identité

Description

Anonyme

Le serveur ne peut pas identifier le client.

Identifier

Permet au serveur d'identifier le client et d'effectuer des vérifications d'accès à l'aide du jeton d'accès du client.

Emprunter l'identité

Permet au serveur d'accéder à des ressources locales en utilisant les données d'identification du client.

Déléguer

Permet au serveur d'accéder à des ressources distantes en utilisant les données d'identification du client (exige Kerberos et une configuration de compte spécifique).

Pour plus d'informations, reportez-vous à la section « Emprunt d'identité » dans le module 17, « Sécurisation de votre serveur d'applications » et à « How to Enable Kerberos Delegation in Windows 2000 » dans la section Références de l'article MSDN « Building Secure ASP.NET Applications », à l'adresse http://msdn.microsoft.com/library/en-us/dnnetsec/html/secnetlpMSDN.asp.

Données sensibles

Si votre application transmet des données sensibles depuis et vers un composant de service via un réseau, vous devez les crypter afin de vous prémunir contre la menace d'écoute clandestine et garantir leur confidentialité ainsi que leur intégrité. Vous pouvez utiliser une protection au niveau transport avec IPSec, ou au niveau de votre application de services d'entreprise en lui associant le niveau d'authentification RPC Packet Privacy. De la sorte, vous permettez le cryptage de tous les paquets de données acheminés depuis ou vers le composant de service afin d'assurer leur confidentialité et leur intégrité.

Pour configurer l'authentification par confidentialité des paquets, utilisez l'outil Services de composants ou ajoutez l'attribut suivant dans l'assembly de votre composant de service :

[assembly: ApplicationAccessControl(
                   Authentication = AuthenticationOption.Privacy)]

Pour plus d'informations sur l'utilisation d'IPSec pour crypter toutes les données échangées entre deux ordinateurs, reportez-vous à la section « How To: Use IPSec to Provide Secure Communication Between Two Servers » dans la section « How To » de patterns & practicesVolume I, Building Secure ASP.NET Web Applications: Authentication, Authorization, and Secure Communication » à l'adresse http://msdn.microsoft.com/library/default.asp?url=/library/en-us/dnnetsec/html/SecNetHT00.asp.

Audit et journalisation

L'audit et la journalisation doivent être réalisés à tous les niveaux de l'application afin d'éviter tout risque de répudiation, qui consistent, pour l'utilisateur, à nier avoir exécuté certaines transactions ou opérations.

Audit des transactions des utilisateurs

Si votre application ou votre service Web est configuré pour l'emprunt d'identité, l'identité de l'appelant d'origine est automatiquement transmise à l'application des services d'entreprise ; elle est donc disponible via l'élément SecurityCallContext.OriginalCaller. Ceci s'avère utile pour réaliser un audit du niveau intermédiaire. Le code suivant montre comment accéder à ces informations :

[ComponentAccessControl]
public class YourServicedComponent : ServicedComponent
{
  public void ShowCallers()
  {
    SecurityCallers callers = SecurityCallContext.CurrentCall.Callers;
    foreach(SecurityIdentity id in callers)
    {
      LogEvent(id.AccountName);
    }
  }
  private void LogEvent(string message)
  {
    try
    {
      if (!EventLog.SourceExists(appName))
      {
        EventLog.CreateEventSource(appName, eventLog);
      }
      EventLog.WriteEntry(appName, message, EventLogEntryType.Information );
    }
    catch (SecurityException secex)
    {
      throw new SecurityException(
            "La source de l'événement n'existe pas et ne peut pas être créée.", secex);
    }
  }
}

Pour qu'il y ait écriture dans le journal des événements, il doit exister une source d'événement qui associe l'application des services d'entreprise à un journal d'événements spécifique. Le code ci-dessus crée la source d'événement au moment de l'exécution, ce qui signifie que le compte de processus du composant de service doit posséder les autorisations adéquates dans le registre.

  • Comment permettre à l'identité du processus du composant de service de créer des sources d'événement

    • Utilisez regedit32.exe pour mettre à jour les autorisations de la clé de registre suivante afin d'accorder l'accès au compte de processus du composant de service :

      HKLM\SYSTEM\CurrentControlSet\Services\Eventlog

      Le ou les comptes doivent posséder les autorisations minimales suivantes :

      • Interroger une valeur de clé

      • Définir une valeur de clé

      • Créer une sous-clé

      • Énumérer des sous-clés

      • Notifier

      • Lire

Une autre stratégie consiste à utiliser une classe Installer et à créer la source d'événement pour l'application au moment de l'installation, lorsque des privilèges d'administrateur sont disponibles. Pour plus d'informations à ce sujet, reportez-vous à la section « Audit et journalisation » dans le module 10, « Création de pages et de contrôles ASP.NET sécurisés ».

Création d'un composant de service sécurisé

Jusque-là, nous avons vu les menaces et les contre-mesures applicables aux composants de service et aux services d'entreprise ; nous allons à présent voir au travers des fragments de code suivants quelles sont les principales caractéristiques d'un composant de service sécurisé pour l'implémentation très simple d'une classe Customer. Pour plus de clarté, les détails de mise en œuvre de la méthode ont été laissés de côté.

Mise en œuvre de l'assembly

Le code suivant, extrait de assemblyinfo.cs, montre les métadonnées du niveau assembly utilisées pour configurer le catalogue COM+ lorsque l'assembly du composant de service est inscrit avec les services d'entreprise au moyen de regsvcs.exe.

// (1) L'assembly a un nom fort.
[assembly: AssemblyKeyFile(@"..\..\Customer.snk")]

// Configuration des services d'entreprise
[assembly: ApplicationName("CustomerService")]
[assembly: Description("Customer Services Application")]
// (2) Application serveur - s'exécute dans l'instance du processus dllhost.exe.
[assembly: ApplicationActivation(ActivationOption.Server)]
// (3) Activer les vérifications d'accès au niveau composant.
// (4) Spécifier l'authentification au niveau de l'appel.
// (5) Spécifier le niveau d'emprunt d'identité Identifier pour les appels en aval.
[assembly: ApplicationAccessControl(
              AccessChecksLevel=AccessChecksLevelOption.ApplicationComponent,
              Authentication=AuthenticationOption.Call,
              ImpersonationLevel=ImpersonationLevelOption.Identify)]

Le code ci-avant présente les caractéristiques de sécurité suivantes (identifiées par les numéros sur les lignes de commentaires).

  1. L'assembly a un nom fort. Il s'agit d'une condition obligatoire pour les composants de service. L'avantage supplémentaire, du point de vue de la sécurité, est que l'assembly est signé numériquement. Ainsi, toute modification éventuelle par un pirate sera détectée et l'assembly ne se chargera pas.

  2. L'application est configurée pour s'exécuter en tant qu'application serveur dans une instance dédiée de dllhost.exe. Ceci vous permet de spécifier une identité « Exécuter en tant que » dotée d'un minimum de privilèges au moment du déploiement.

  3. L'application est configurée pour prendre en charge les vérifications d'accès au niveau composant. Il est ainsi possible d'autoriser les appelants sur la base de leur appartenance à un rôle aux niveaux classe, interface et méthode.

  4. L'authentification est demandée au niveau de l'appel. Par conséquent, chaque appel de méthode provenant d'un client est authentifié.

  5. Le niveau d'emprunt d'identité pour les appels sortants du composant de service vers d'autres composants résidant sur des serveurs distants est défini à Identifier. Ainsi, le composant en aval peut identifier l'appelant mais ne peut pas emprunter d'identité.

    Remarque : le niveau d'emprunt d'identité pour un service Web client ou une application Web ASP.NET qui appelle est spécifié dans l'élément <processModel> du fichier Machine.config sur le serveur Web client.

Mise en œuvre d'une classe pour le composant de service

L'extrait de code suivant montre la configuration de sécurité d'une classe Customer partiellement implémentée.

namespace busCustomer
{
  // (1) Définition d'interface explicite pour gérer l'autorisation au niveau méthode
  public interface ICustomerAdmin
  {
    void CreditAccountBalance(string customerID, double amount);
  }
  // (2) Appliquer les vérifications d'accès au niveau composant.
  [ComponentAccessControl]
  public sealed class Customer : ServicedComponent, ICustomerAdmin
  {
    private string appName = "Customer";
    private string eventLog = "Application";
    // Implémentation de ICustomer
    // (3) L'accès à CreditAccountBalance est limité aux membres
    //     du rôle Manager et Senior Manager.
    [SecurityRole("Manager")]
    [SecurityRole("Senior Manager")]
    public void CreditAccountBalance(string customerID, double amount)
    {
      // (4) Gestion structurée des exceptions pour protéger l'implémentation.
      try
      {
        // (5) Vérifier que la sécurité est activée.
        if (ContextUtil.IsSecurityEnabled)
        {
          // Seuls les responsables peuvent créditer des comptes
          // avec des sommes supérieures à 1.000 dollars.
          if (amount > 1000) {
            // (6) Contrôle du rôle à l'aide d'un programme pour autoriser l'opération de crédit
            if (ContextUtil.IsCallerInRole("Senior Manager")) {
              // Appeler le composant d'accès aux données pour mettre à jour la base de données.
              . . .
              // (7) Auditer la transaction.
              AuditTransaction(customerID, amount);
            }
            else {
              throw new SecurityException("Appelant non autorisé");
            }
          }
        } 
        else {
          throw new SecurityException("La sécurité n'est pas activée");
        }
      }
      catch (Exception ex)
      {
        // Consigner les détails de l'exception.
        throw new Exception("Echec pour créditer le solde du client: " +
                             customerID, ex);
      }
    }
    private void AuditTransaction(string customerID, double amount)
    {
      // (8) L'identité de l'appelant d'origine est obtenue à partir du contexte d'appel
      //     à des fins de journalisation.
      SecurityIdentity caller = SecurityCallContext.CurrentCall.OriginalCaller;
      try
      {
        if (!EventLog.SourceExists(appName))
        {
          EventLog.CreateEventSource(appName,eventLog);
        }
        StringBuilder logmessage = new StringBuilder();
        logmessage.AppendFormat("{0}Utilisateur {1} a exécuté la transaction suivante" 
                               + "{2} Solde pour le client {3} "
                               + "crédité de {4}",
                                Environment.NewLine, caller.AccountName, 
                                Environment.NewLine, customerID, amount);
        EventLog.WriteEntry(appName, logmessage.ToString(), 
                            EventLogEntryType.Information);
      }
      catch (SecurityException secex)
      {
        throw new SecurityException(
                   "La source de l'événement n'existe pas et ne peut pas être créée", secex);
      }
    }
  }
}

Le code ci-avant présente les caractéristiques de sécurité suivantes (identifiées par les numéros sur les lignes de commentaires).

  1. Une interface est définie et mise en œuvre explicitement pour gérer l'autorisation aux niveaux interface et méthode avec des rôles COM+.

  2. Les vérifications d'accès au niveau composant sont activées pour la classe à l'aide de l'attribut [ComponentAccessControl] au niveau de la classe.

  3. L'attribut [SecurityRole] est utilisé avec la méthode CreditAccountBalance pour limiter l'accès aux membres qui ont le rôle Manager ou Senior Manager.

  4. Une gestion structurée des exceptions est mise en place pour protéger l'implémentation. Les exceptions sont interceptées, consignées et une exception appropriée est transmise à l'appelant.

  5. Le code vérifie si la sécurité est activée ou non avant de procéder à la vérification explicite des rôles. Il s'agit d'une stratégie d'atténuation des risques qui garantit que les transactions ne sont pas exécutables si un administrateur désactive, par inattention ou intentionnellement, la configuration de sécurité de l'application.

    Remarque : la méthode IsCallerInRole renvoie toujours la valeur « true » lorsque la sécurité est désactivée.

  6. Les appelants doivent être membres du rôle Manager ou Senior Manager en raison de la sécurité déclarative utilisée sur la méthode. Pour une autorisation minutieuse, l'appartenance au rôle de l'appelant est explicitement contrôlée dans le code.

  7. La transaction fait l'objet d'un audit.

  8. L'implémentation de l'audit obtient l'identité de l'appelant d'origine en se servant de l'objet SecurityCallContext.

Problèmes de sécurité d'accès au code

Habituellement, les applications qui utilisent des composants de service sont totalement fiables et, par conséquent, la sécurité d'accès au code n'est pas fréquemment sollicitée pour autoriser un code appelant. Toutefois, le code appelant doit examiner les points suivants :

  • L'autorisation de code non géré est requise pour activer et exécuter des appels inter-contextes à des composants de service.

  • Si le client d'un composant de service est une application Web ASP.NET, son niveau de confiance doit être défini à « Complet » (Full), comme indiqué ci-dessous.

    <trust level="Full" />

    Si votre application Web est configurée avec un autre niveau de confiance, elle ne possède pas d'autorisation sur le code non géré. Dans ce cas, vous devez créer un assembly wrapper en sandbox afin d'encapsuler la communication avec le composant de service. Puis, vous devez définir la stratégie de sécurité d'accès au code afin d'accorder à cet assembly wrapper l'autorisation sur le code non géré. Pour plus d'informations sur la technique de mise en sandbox employée pour encapsuler du code hautement privilégié, reportez-vous au module 9, « Utilisation de la sécurité d'accès au code avec ASP.NET ».

  • Si une référence à un composant de service est transmise à du code non sécurisé, les méthodes définies dans ce composant ne peuvent pas être appelées à partir du code non sécurisé. Il existe toutefois une exception à cette règle, pour les méthodes qui n'exigent pas de services de changement ou d'interception de contexte et qui n'appellent pas des membres de System.EnterpriseServices. Ces méthodes peuvent être appelées par du code non sécurisé.

Problèmes de déploiement

Les applications de services d'entreprise sont en général installées sur le serveur Web ou sur un serveur d'applications distant. La figure 11.3 montre les deux scénarios de déploiement classiques pour les services d'entreprise. Du point de vue de la sécurité, la différence notable avec un déploiement distant est que les données transmises depuis et vers le composant de service sont acheminées sur le réseau, souvent par le biais d'un pare-feu interne qui sépare le réseau interne et le périmètre.

Configuration de déploiement classiques des services d'entreprise

Figure 11.3.
Configuration de déploiement classiques des services d'entreprise

Les développeurs et les administrateurs doivent garder à l'esprit des problèmes de déploiement suivants :

  • Limites du pare-feu, y compris les conditions d'utilisation des ports pour DCOM et DTC

  • Configuration du compte « Exécuter en tant que »

  • Stockage d'éléments secrets dans des chaînes de constructeur d'objet

Pour plus d'informations sur l'application d'une configuration sécurisée au moment du déploiement, reportez-vous au module 17, « Sécurisation de votre serveur d'applications ».

Limites du pare-feu

Si le client et l'application des services d'entreprise sont séparés par un pare-feu interne, les ports appropriés qui gèrent DCOM et éventuellement le DTC (si votre application utilise des transactions distribuées) doivent être ouverts.

Par défaut, DCOM utilise l'allocation dynamique de ports RPC, qui sélectionne de manière aléatoire les numéros de port au-delà de 1024. De plus, le port 135 est utilisé par le service de mappage de point final RPC. Limitez les ports nécessaires pour prendre en charge DCOM sur le pare-feu interne de deux façons:

  • En définissant les plages de ports.

    Vous pouvez ainsi contrôler les ports affectés dynamiquement par RPC.

  • En utilisant le mappage de points finals statiques.

    Windows 2000 SP3 (ou QFE 18.1 et versions suivantes) ou Windows Server 2003 vous permet de configurer les applications Enterprise Services pour qu'elles utilisent un point final statique. Avec le mappage de points finaux statiques, vous n'avez qu'à ouvrir deux ports sur le pare-feu. Ainsi, ouvrez le port 135 pour RPC et un port sélectionné pour votre application de services d'entreprise.

Pour plus d'informations sur la définition des plages de ports et le mappage des points finals statiques, reportez-vous à la section « Problèmes de pare-feu » dans le module 17, « Sécurisation de votre serveur d'applications ».

Utilisation de services Web

Si l'ouverture des ports sur le pare-feu interne n'est pas possible, vous pouvez introduire une couche de façade de services Web devant les composants de service du serveur d'application. Il suffit d'ouvrir le port 80 pour le trafic HTTP et en particulier pour que les messages SOAP (Simple Object Access Protocol) circulent dans les deux directions, comme le montre la figure 11.4.

Utilisation d'une couche de façade de services Web pour communiquer avec les services d'entreprises via HTTP

Figure 11.4.
Utilisation d'une couche de façade de services Web pour communiquer avec les services d'entreprises avec HTTP

Cette approche ne vous autorise pas à faire circuler le contexte de transaction du client au serveur, bien que dans de nombreux cas où votre architecture de déploiement inclut un serveur d'application de niveau intermédiaire, il soit préférable d'initier les transactions dans le composant de service distant, sur le serveur d'application.

Pour plus d'informations sur les besoins en matière de déploiement physique pour les agents de service et les interfaces de service, tels que la couche de façade de services Web, consultez le chapitre « Déploiement physique et exigences opérationnelles » dans la section de référence de l'article MSDN intitulé « Architecture d'applications pour .NET : conception d'applications et de services ».

Impératifs concernant DTC

Si votre application emploie les transactions distribuées COM+ et si celles-ci sont utilisées sur différents serveurs distants séparés par un pare-feu interne, ce dernier doit ouvrir les ports requis pour prendre en charge le trafic DTC.

Si votre architecture de déploiement comprend un niveau d'application distant, les transactions y sont normalement lancées au sein de l'application de services d'entreprise, et sont propagées au serveur de bases de données. En l'absence de serveur d'application, l'application de services d'entreprise sur le serveur Web lance la transaction et la propage vers le gestionnaire de ressources SQL Server.

Pour plus d'informations sur la configuration de pare-feu pour gérer le trafic DTC, reportez-vous au module 18, « Sécurisation de votre serveur de base de données ».

Résumé

La sécurité des services d'entreprise (COM+) repose sur celle de Windows pour authentifier et autoriser les appelants. L'autorisation est configurée et contrôlée par le biais de rôles COM+ qui contiennent des comptes d'utilisateurs ou de groupes Windows. La plupart des menaces qui pèsent sur les applications de services d'entreprise et sur les composants de service sont gérées à l'aide de techniques de codage robustes et en définissant une configuration appropriée du catalogue.

Le développeur doit employer des attributs déclaratifs pour définir la configuration de sécurité du composant de service. Ces attributs déterminent la manière dont l'application est configurée lorsqu'elle est initialement inscrite avec les services d'entreprise (généralement au moyen de Regsvcs.exe).

Cependant, tous les paramètres de configuration de la sécurité ne peuvent pas être définis avec des attributs. Ainsi, l'administrateur doit spécifier une identité « Exécuter en tant que » pour une application serveur. Il doit aussi, au moment du déploiement, constituer des rôles avec des comptes d'utilisateurs ou de groupes Windows.

Lorsque vous développez des composants de service ou que vous évaluez la sécurité de votre solution de sécurité d'entreprise, consultez la « Liste de contrôle : sécurisation des services Web » dans la section « Listes de contrôle » de ce guide.

Informations complémentaires

Pour plus d'informations, reportez-vous aux ressources suivantes :

Cela vous a-t-il été utile ?
(1500 caractères restants)
© 2013 Microsoft. Tous droits réservés.