Choix des options QOS de sécurité
Les options QOS de sécurité sont transmises dans le cadre du paramètre SecurityQOS donné à la fonction RpcBindingSetAuthInfoEx . Utilisez les meilleures pratiques suivantes.
Utiliser l’authentification mutuelle
L’authentification mutuelle véritable n’est disponible que pour certains fournisseurs de sécurité : Negotiate (quand il négocie Kerberos), Kerberos et Schannel. NTLM ne prend pas en charge l’authentification mutuelle. L’utilisation de l’authentification mutuelle nécessite qu’un nom de principal de serveur bien formé soit fourni. De nombreux développeurs utilisent la pratique de sécurité défectueuse suivante : le serveur est appelé pour demander son nom principal (RpcMgmtInqServerPrincName), puis ils demandent aveuglément une authentification mutuelle à l’aide de ce nom principal. Cette approche brise toute l’idée de l’authentification mutuelle ; l’idée de l’authentification mutuelle est que seuls certains serveurs sont appelés parce qu’ils sont approuvés pour analyser et gérer vos données. À l’aide de la pratique de sécurité défectueuse qui vient d’être décrite, les développeurs donnent leurs données à quiconque suffisamment intelligent pour retourner son nom.
Par exemple, si le logiciel client doit appeler uniquement un serveur s’exécutant sous les comptes de Joe, Pete ou Alice, la fonction RpcMgmtInqServerPrincName doit être appelée et le nom renvoyé doit être vérifié. S’il s’agit de Joe, Pete ou Alice, l’authentification mutuelle doit être demandée à l’aide de leur nom principal de serveur. Cela garantit que les deux moitiés de la conversation vont au même principal.
Si le logiciel client doit appeler un service exécuté sous le compte de Joe uniquement, composez directement le nom du serveur principal de Joe et effectuez l’appel. Si le serveur n’est pas Joe, l’appel échoue tout simplement.
Souvent, les services s’exécutent en tant que services système Windows, ce qui signifie qu’ils s’exécutent sous le compte d’ordinateur. L’authentification mutuelle et la création d’un nom principal de serveur sont toujours recommandées.
Utiliser le type d’emprunt d’identité le plus bas qui permet à l’appel de passer par
Cette bonne pratique est assez explicite. Même si l’authentification mutuelle est utilisée, ne donnez pas au serveur plus de droits que nécessaire ; un serveur légitime peut avoir été compromis, et même si les données que vous envoyez tombent entre de mauvaises mains dans ce cas, au moins le serveur ne sera pas en mesure d’accéder à d’autres données sur le réseau en votre nom. Certains serveurs rejettent un appel qui ne dispose pas d’informations suffisantes pour déterminer et éventuellement emprunter l’identité de l’appelant. Sachez également que certaines séquences de protocoles prennent en charge la sécurité au niveau du transport (ncacn_np et ncalrpc). Dans ce cas, le serveur peut toujours emprunter l’identité si vous spécifiez un niveau d’emprunt d’identité suffisamment élevé via le paramètre NetworkOptions lorsque vous créez le handle de liaison.
Enfin, certains fournisseurs ou transports de sécurité peuvent faire passer ImpersonationType à un niveau supérieur à celui spécifié. Lorsque vous développez un programme, veillez à essayer d’effectuer des appels avec impersonationType prévu et case activée si vous obtenez un ImpersonationType plus élevé sur le serveur.