Vue d’ensemble de la sécurité

l’infrastructure de sécurité de Windows API des Services Web (WWSAPI) fournit les éléments suivants :

  • Intégrité des messages, confidentialité, détection de relecture et authentification du serveur à l’aide de la sécurité de transport.
  • Authentification du client, telle que la validation des jetons de sécurité, les vérifications de l’approbation et de la révocation des certificats, etc., en utilisant la sécurité de message ou de transport SOAP.

Le modèle de programmation de sécurité

La sécurité est associée aux canaux de communication. La sécurisation d’un canal comprend les étapes suivantes.

  • Créez et initialisez une ou plusieurs liaisons de sécurité appropriées pour les exigences de sécurité de l’application.
  • Créez une Description de sécurité contenant ces liaisons de sécurité.
  • Créez un canal ou un proxy de service (côté client) ou créez un écouteur ou un hôte de service (côté serveur) en transmettant cette description de sécurité.
  • Effectuez les étapes de programmation normale des canaux de l’ouverture, de l’acceptation, de l’envoi, de la réception, de la fermeture, etc.

Les messages envoyés et reçus sur le canal sont sécurisés automatiquement par le runtime conformément à la description de sécurité fournie. Si vous le souhaitez, vous pouvez affiner ces étapes en spécifiant un ou plusieurs paramètres de sécurité à l' ensemble du canal dans les paramètres de sécurité de la description de la sécurité ou de la liaison dans une liaison de sécurité.

Toute autorisation requise des identités d’expéditeur doit être effectuée par l’application à l’aide des résultats de traitement de sécurité joints à chaque message reçu. Les étapes d’autorisation ne sont pas spécifiées dans la description de sécurité, et ne sont pas exécutées automatiquement par le Runtime.

Les erreurs dans la description de sécurité, telles que les liaisons non prises en charge, les propriétés/champs non applicables, l’absence de propriétés/champs requis ou les valeurs de propriété/champ non valides, entraînent l’échec de la création du canal ou de l’écouteur.

Sélection des liaisons de sécurité

Lors de la conception de la sécurité d’une application, la décision principale est la sélection des liaisons de sécurité à inclure dans la description de la sécurité. Voici quelques recommandations pour choisir des liaisons de sécurité adaptées au scénario de sécurité d’une application. une méthode heuristique utile consiste tout d’abord à comprendre quels types d’informations d’identification de sécurité (tels que les certificats X. 509, Windows nom d’utilisateur/mot de passe de domaine, nom d’utilisateur/mot de passe définis par l’application) seront disponibles pour l’application, puis choisissez une liaison de sécurité qui peut utiliser ce type d’informations d’identification.

Canaux et sécurité

Comme indiqué ci-dessus, la sécurité est limitée aux canaux. En outre, les opérations de canal correspondent aux étapes de sécurité de manière cohérente sur toutes les liaisons de sécurité.

  • Création de canal : le jeu de liaisons de sécurité spécifié dans la description de sécurité est validé et reste fixe pour le canal par la suite. La forme de la pile de canaux, y compris les canaux secondaires à utiliser pour les négociations WS-Trust, est également déterminée.
  • Canal ouvert : les informations d’identification fournies dans le cadre des liaisons de sécurité sont chargées, et les sessions de sécurité sont établies. En général, un canal ouvert contient un état de sécurité « en direct ». L’ouverture d’un canal client spécifie également l’adresse du point de terminaison du serveur par rapport à laquelle l’authentification du serveur sera effectuée par le Runtime.
  • Entre l’ouverture et la fermeture d’un canal : les messages peuvent être envoyés et reçus en toute sécurité au cours de cette phase.
  • Envoi de messages : les jetons de contexte de sécurité sont obtenus ou renouvelés selon les besoins et la sécurité est appliquée à chaque message transmis en fonction de la description de la sécurité. Les erreurs rencontrées lors de l’application de la sécurité sont retournées à l’application en tant qu’erreurs d’envoi.
  • Réception du message : la sécurité est vérifiée sur chaque message reçu conformément à la description de la sécurité. Toutes les erreurs de vérification de sécurité de message sont renvoyées à l’application en tant qu’erreurs de réception. Ces erreurs par message n’affectent pas l’état du canal ou les réceptions ultérieures. L’application peut ignorer une réception ayant échoué et redémarrer une réception pour un autre message.
  • Abandon du canal : le canal peut être abandonné à tout moment pour arrêter toutes les e/s sur le canal. Lors de l’abandon, le canal passe dans un état d’erreur et n’autorise plus d’envoi ou de réception. Toutefois, le canal peut toujours conserver un état de sécurité « réel », de sorte qu’une fermeture de canal suivante sera nécessaire pour supprimer tous les États correctement.
  • Fermeture du canal : l’état de sécurité créé à l’ouverture est supprimé et les sessions sont détruites. Les jetons de contexte de sécurité sont annulés. La pile de canaux est conservée, mais elle ne contient pas d’état de sécurité « actif » ou d’informations d’identification chargées.
  • Canal libre : la pile de canaux générée au moment de la création, ainsi que toutes les ressources de sécurité, sont libérées.

API Sécurité

La documentation de l’API pour la sécurité est regroupée dans les rubriques suivantes.

Sécurité

Lors de l’utilisation de l’API de sécurité WWSAPI, les applications font face à plusieurs risques de sécurité :

Configuration intempestive accidentelle

WWSAPI prend en charge une gamme d’options de configuration liées à la sécurité. Consultez par exemple _ ID de _ _ propriété _ de liaison WS Security. Certaines de ces options, telles que la _ propriété de liaison WS Security, _ _ _ autorisent les _ _ clients anonymes à permettre à l’application de réduire le niveau de sécurité par défaut fourni par les différentes liaisons de sécurité. L’utilisation de ces options doit être soigneusement évaluée pour s’assurer qu’il n’existe aucun vecteur d’attaque résultant.

En outre, comme décrit ci-dessus, WWSAPI permet à une application de désactiver délibérément certaines étapes requises pour sécuriser complètement un échange de messages, par exemple autoriser la désactivation du chiffrement, même si les informations d’identification de sécurité sont transmises. Cela est autorisé à activer certains scénarios spécifiques et ne doit pas être utilisé pour la communication générale. Le _ _ niveau de protection WS doit être réduit spécifiquement pour permettre ces scénarios, et les applications ne doivent pas modifier cette valeur sauf si cela est absolument nécessaire, ce qui entraîne la désactivation de nombreuses vérifications conçues pour garantir une configuration sécurisée.

Stockage des informations confidentielles en mémoire

Les informations confidentielles, telles que les mots de passe, qui sont stockées en mémoire sont susceptibles d’être extraites par un attaquant privilégié au moyen, par exemple, du fichier d’échange. WWSAPI effectue une copie des informations d’identification fournies et chiffre cette copie, en laissant les données d’origine non protégées. L’application est responsable de la protection de l’instance d’origine. En outre, la copie chiffrée est brièvement déchiffrée lors de son utilisation, ouvrant une fenêtre pour l’extraire.

Déni de service

Le traitement de la sécurité peut consommer des ressources importantes. Chaque liaison de sécurité supplémentaire augmente ces coûts. WWSAPI abandonne le traitement de la sécurité dès qu’un échec de vérification de sécurité se produit, mais certaines vérifications, telles que les décisions d’autorisation, peuvent ne pas avoir lieu tant que le travail important n’a pas été effectué.

Lors du traitement d’un message sur le serveur, l’état de sécurité est stocké sur le segment de mémoire du message. L’application peut limiter la consommation de mémoire pendant le traitement de la sécurité en réduisant la taille du segment de mémoire par le biais des _ Propriétés du segment de propriété de message WS _ _ _ . En outre, certaines liaisons de sécurité telles que la _ liaison de sécurité de message du contexte de sécurité WS _ _ _ _ peuvent entraîner l’allocation de ressources par le serveur pour le compte du client. Les limites de ces ressources peuvent être configurées par le biais des valeurs d' _ ID de propriété de _ liaison _ _ WS Security suivantes :

  • contexte de sécurité de la _ propriété de liaison WS sécurité- _ _ _ _ _ nombre maximal de _ _ contextes en attente
  • contexte de sécurité de la _ propriété de liaison WS Security- _ _ _ _ _ nombre maximal de _ _ contextes actifs
  • _intervalle de _ _ renouvellement du _ _ contexte de _ sécurité _ de la propriété de liaison WS Security
  • _intervalle de _ _ substitution du _ _ contexte de _ sécurité _ de la propriété de liaison WS Security

La définition de ces limites à des valeurs faibles réduit la consommation de mémoire maximale, mais peut entraîner le rejet des clients légitimes lorsque le quota est atteint.