Sécurité IIS
Cette rubrique décrit la relation de Microsoft SQL Server Compact 3.5 avec les éléments suivants :
Authentification IIS
Autorisation IIS
Chiffrement IIS
Authentification IIS
Lorsque vous configurez l'Agent serveur SQL Server Compact 3.5, vous spécifiez si les clients doivent effectuer l'authentification Microsoft Internet Information Services (IIS) lorsqu'ils se connectent à l'Agent serveur SQL Server Compact 3.5. Il existe trois formes d'authentification IIS :
l'accès anonyme ;
l'authentification de base ;
Authentification Windows intégrée
En principe, la majorité des applications Internet utilisent l'authentification de base et le chiffrement SSL (Secure Sockets Layer).
Accès anonyme
Avec l'accès anonyme, IIS n'effectue pas l'authentification du client. Tout ce que l'Agent serveur SQL Server Compact 3.5 réalise pour le compte du client est effectué sous l'identité du Compte Invité Internet. Par défaut, le Compte Invité Internet est IUSR_nom_ordinateur, mais vous pouvez choisir un autre compte d'utilisateur Windows comme Compte Invité Internet.
Authentification de base
Avec l'authentification de base, le client SQL Server Compact 3.5 doit fournir un nom d'utilisateur et un mot de passe de compte Windows valides. IIS tente de se connecter à l'aide du mot de passe et du nom d'utilisateur fournis par le client. Si la tentative de connexion réussit, tout ce que fait l'Agent serveur SQL Server Compact 3.5 est effectué sous l'identité du compte d'utilisateur Windows spécifié. En revanche, si elle échoue, la demande du client est rejetée. L'authentification de base peut être utilisée pour les applications Internet et intranet. L'authentification de base requiert que chaque client dispose d'un compte Windows valide avec un nom d'utilisateur et un mot de passe correspondants.
Important
Par défaut, l'authentification de base envoie le nom d'utilisateur et le mot de passe encodés en base64 sur le réseau. Cela peut poser un problème de sécurité si quelqu'un écoute l'échange de mot de passe, car l'encodage base64 peut être facilement décodé. Pour protéger le mot de passe de l'utilisateur, le chiffrement SSL (Secure Sockets Layer) doit toujours être activé en cas d'utilisation de l'authentification de base. Pour plus d'informations, consultez Configuration du chiffrement SSL.
Authentification Windows intégrée
Le principe de l'authentification Windows intégrée est relativement similaire à celui de l'authentification de base. Le client SQL Server Compact 3.5 doit fournir un nom d'utilisateur et un mot de passe de compte Windows valides. IIS tente de se connecter à l'aide du mot de passe et du nom d'utilisateur. Si la tentative de connexion réussit, tout ce que fait l'Agent serveur SQL Server Compact 3.5 est effectué sous l'identité du compte d'utilisateur Windows spécifié. En revanche, si elle échoue, la demande de synchronisation du client est rejetée. L'Authentification Windows intégrée présente un avantage principal par rapport à l'authentification de base : contrairement à l'authentification de base, elle ne transmet pas sur le réseau le nom d'utilisateur et le mot de passe du client sous une forme non chiffrée. Cela évite tout risque d'interception du mot de passe. L'authentification Windows intégrée convient particulièrement aux applications intranet. Elle est rarement utilisée pour les applications Internet, car elle ne fonctionne pas via un serveur proxy ou un pare-feu.
Notes
Étant donné que Microsoft Windows CE 4.2 ne prend pas en charge l'authentification Digest, les solutions de connectivité SQL Server Compact 3.5 ne prennent pas en charge cette forme d'authentification.
Autorisation IIS
Une fois le client IIS authentifié, l'autorisation IIS détermine si le client peut appeler l'Agent serveur SQL Server Compact 3.5. Vous pouvez contrôler qui peut effectuer une connectivité SQL Server Compact 3.5 en contrôlant les clients autorisés à accéder à l'Agent serveur SQL Server Compact 3.5.
IIS fournit les mécanismes de contrôle d'accès suivants :
IIS compare d'abord l'adresse du client aux restrictions d'adresse IP configurées. Vous pouvez configurer le serveur Web pour empêcher des ordinateurs spécifiques, des groupes d'ordinateurs ou des réseaux entiers d'accéder à l'Agent serveur SQL Server Compact 3.5. Lorsqu'un client tente d'accéder à l'Agent serveur SQL Server Compact 3.5, IIS compare l'adresse IP de l'ordinateur client aux paramètres de restrictions d'adresse IP sur le serveur. Si l'adresse IP se voit refuser l'accès, la demande de synchronisation du client est rejetée avec le message : « 403 Accès interdit. ».
Si IIS est configuré pour exiger l'authentification, il vérifie si le client dispose d'un compte d'utilisateur Windows valide comme décrit à la section Authentification IIS de ce document. Si le compte d'utilisateur n'est pas valide, la demande de synchronisation du client est rejetée avec le message : « 403 Accès interdit. ».
IIS vérifie ensuite les autorisations Web. Ce contrôle de la sécurité IIS ne concerne pas les solutions de connectivité SQL Server Compact 3.5.
IIS vérifie ensuite les autorisations NTFS pour l'Agent serveur SQL Server Compact 3.5 afin de s'assurer que l'utilisateur qui tente de se connecter dispose des autorisations adéquates.
Notes
Bien que IIS puisse être également utilisé avec un système de fichiers FAT (File Allocation Table), il est vivement recommandé d'utiliser le système NTFS. Le système de fichiers NTFS permet d'utiliser des listes de contrôle d'accès pour accorder ou refuser l'accès à l'Agent serveur SQL Server Compact 3.5 ainsi que des fichiers de messages d'entrée et de sortie sur le système IIS.
Chiffrement IIS
Lorsque vous configurez l'Agent serveur SQL Server Compact 3.5, vous pouvez spécifier le chiffrement SSL. Lorsque vous spécifiez le chiffrement SSL, toutes les communications entre l'Agent client SQL Server Compact 3.5 et l'Agent serveur SQL Server Compact 3.5 sont chiffrées. Pour plus d'informations, consultez Configuration du chiffrement SSL.
Vous devez utiliser le chiffrement SSL dans les situations suivantes :
Si vous configurez IIS pour utiliser l'authentification de base.
Le chiffrement SSL est essentiel pour protéger le mot de passe Internet de l'utilisateur. Par défaut, l'authentification de base envoie le nom d'utilisateur et le mot de passe encodés en base64 sur le réseau . Cela peut poser un problème de sécurité si quelqu'un écoute l'échange de mot de passe, car l'encodage base64 peut être facilement décodé. Le chiffrement SSL (Secure Sockets Layer) doit toujours être activé en cas d'utilisation de l'authentification de base pour protéger le mot de passe de l'utilisateur.
Pour le service RDA uniquement : si l'application spécifie un paramètre OLEDBConnectionString qui contient un mot de passe.
Les méthodes RDA Pull, Push et SubmitSQL requièrent un paramètre OLEDBConnectionString. Cette chaîne de connexion est transmise via le réseau sous forme de texte clair. Cela peut présenter un risque de sécurité si quelqu'un écoute l'échange du mot de passe.
Pour la réplication uniquement : si le serveur de publication ou le serveur de distribution SQL Server repose sur l'authentification SQL Server.
Le serveur de distribution utilise l'authentification SQL Server si la propriété DistributorSecurityMode spécifie DB_AUTHENTICATION. Le serveur de publication utilise l'authentification SQL Server si la propriété PublisherSecurityMode spécifie DB_AUTHENTICATION. Lorsque l'authentification SQL Server est utilisée, les propriétés DistributorPassword et PublisherPassword sont transmises via le réseau sous forme de texte clair. Cela peut présenter un risque de sécurité si quelqu'un écoute l'échange du mot de passe. Pour préserver les propriétés DistributorPassword et PublisherPassword, le chiffrement SSL (Secure Sockets Layer) doit toujours être activé avec l'authentification SQL Server.