Sécurisation des services de bureau à distance dans Windows Server 2008 R2 – Bien choisir son serveur d impression

introduction

Les services de bureau à distance (RDS) sur Windows Server 2008 R2 ont plus qu’un nouveau nom; ce ne sont pas les services terminaux de votre père. Avec de nouvelles fonctionnalités (certaines introduites dans Windows Server 2008) telles que RemoteApp, passerelle RD et hôte de virtualisation RD, ce rôle Windows Server vous offre désormais la possibilité de déployer des applications individuelles ou des bureaux complets via RDS ou une solution VDI – dans de nombreux cas sans avoir besoin de Citrix ou d’autres add-ons tiers.

Mais qu'en est-il de la sécurité? Toutes ces complexités ajoutées se traduisent également par de nouveaux défis en matière de sécurité. Dans cet article, nous examinerons les mécanismes de sécurité intégrés à RDS, comment utiliser les paramètres de configuration et la stratégie de groupe pour améliorer la sécurité, ainsi que les meilleures pratiques de sécurité pour un déploiement RDS.

Quoi de neuf dans R2

Si vous accédez à RDS à partir des services Terminal Server Windows Server 2008, vous ne verrez pas autant de changements radicaux que si vous aviez mis à niveau à partir de Windows Server 2003. WS 2008 a apporté d'importantes améliorations aux services Terminal Server, notamment l'accès Web TS. navigateur, la passerelle TS pour les utilisateurs se connectant sur Internet, RemoteApp pour la fourniture d'applications individuelles aux utilisateurs via le protocole RDP (Remote Desktop Protocol) et Session Broker, qui incluait une fonction d'équilibrage de la charge.

WS 2008 R2 a ajouté encore plus de bonté:

• Virtualisation de postes de travail distants pour une solution VDI
• RDS Provider for PowerShell afin que les administrateurs puissent modifier la configuration et effectuer des tâches en ligne de commande et via des scripts
• Virtualisation IP du Bureau à distance, qui permet d'attribuer des adresses IP à des connexions par session ou par programme
• Une nouvelle version de RDP et du client Connexion Bureau à distance (RDC), v. 7.0
• La planification du processeur équitable permet de répartir de manière dynamique le temps de traitement entre les sessions en fonction du nombre de sessions actives.
• Compatibilité Windows Installer pour faciliter l'installation de programmes nécessitant une configuration par utilisateur.
• Véritable prise en charge de plusieurs moniteurs pour un maximum de 16 moniteurs, les programmes fonctionnent comme s'ils fonctionnaient sur l'ordinateur client.

Des améliorations ont également été apportées à l'audio / vidéo et à la prise en charge de Windows Aero dans une session Bureau à distance (notez toutefois que la composition du bureau, qui active Aero, n'est pas prise en charge dans une session avec plusieurs moniteurs).

Implications et mécanismes de sécurité

De toute évidence, les problèmes de sécurité potentiels dépendent de la manière dont vous déployez RDS. Si votre configuration est plus complexe et que les utilisateurs se connectent via Internet et / ou via un navigateur Web, vous aurez plus de problèmes de sécurité à résoudre que si vous avez un déploiement simple dans lequel les utilisateurs se connectent uniquement via le client RDC via le réseau local.

RDS inclut un certain nombre de mécanismes de sécurité pour vous aider à sécuriser davantage les connexions RD.

Authentification au niveau du réseau

Pour une sécurité optimale, vous devez exiger une authentification au niveau du réseau (NLA) pour toutes les connexions. L'autorité de modification requiert que l'utilisateur soit authentifié auprès du serveur hôte de session Bureau à distance avant la création d'une session. Cela permet de protéger l'ordinateur distant contre les utilisateurs malveillants et les logiciels malveillants. Pour utiliser NLA, l'ordinateur client doit utiliser un système d'exploitation qui prend en charge les protocoles CredSSP (Credential Security Support Provider), ce qui signifie Windows XP SP3 ou version ultérieure, et le client RDC 6.0 ou version ultérieure.

NLA est configuré sur le serveur hôte de session Bureau à distance via Outils d'administration | Services de bureau à distance | Configuration de l'hôte de session de bureau. Pour configurer une connexion pour utiliser NLA, procédez comme suit:

1. Clic droit sur la connexion
2. Sélectionnez Propriétés
3. Cliquez sur l'onglet Général
4. Cochez la case "Autoriser les connexions uniquement à partir d'ordinateurs exécutant Remote Desktop avec l'authentification au niveau du réseau", comme illustré à la figure 1.
5. Cliquez sur OK.

Figure 1

Sécurité de la couche de transport (TLS)

Une session RDS peut utiliser l'une des trois couches de sécurité pour protéger les communications entre le client et le serveur hôte de session RDS:

• Couche de sécurité RDP – utilise le cryptage RDP natif et est le moins sécurisé. Le serveur hôte de session Bureau à distance n'est pas authentifié.
• Négocier – Le chiffrement TLS 1.0 (SSL) sera utilisé si le client le prend en charge. Sinon, la session reviendra à la sécurité RDP.
• Le cryptage SSL – TLS 1.0 sera utilisé pour l'authentification du serveur et le cryptage des données envoyées entre le client et le serveur hôte de session. C'est l'option la plus sûre.

Pour des pratiques de sécurité optimales, vous pouvez exiger le cryptage SSL / TLS. Vous aurez besoin d'un certificat numérique, qui peut être délivré par une autorité de certification (de préférence) ou auto-signé.

En plus de sélectionner la couche de sécurité, vous pouvez sélectionner le niveau de cryptage pour la connexion. Vos choix ici sont:

• Bas – utilise un cryptage 56 bits pour les données envoyées du client au serveur. Ne crypte pas les données envoyées du serveur au client.
• Compatible avec le client – c'est la valeur par défaut. Il crypte les données envoyées dans les deux sens entre le client et le serveur avec la force de clé maximale prise en charge par le client.
• Élevé: cette option chiffre les données envoyées dans les deux sens entre le client et le serveur avec un cryptage à 128 bits.
• Conforme à la norme FIPS: cette option chiffre les données envoyées dans les deux sens entre le client et le serveur avec un chiffrement validé FIPS 140-1.

Notez que si vous sélectionnez un niveau élevé ou conforme à FIPS, tous les clients qui ne prennent pas en charge ces niveaux ne pourront pas se connecter.

Voici comment configurer les paramètres d'authentification et de chiffrement du serveur:

1. Sur l'hôte de session Bureau à distance, ouvrez Configuration de l'hôte de session Bureau à distance et la boîte de dialogue Propriétés de la connexion, comme décrit ci-dessus.
2. Dans l'onglet Général, choisissez la couche de sécurité et le niveau de cryptage appropriés dans les listes déroulantes, comme illustré à la figure 2.
3. Cliquez sur OK.

Figure 2

Vous pouvez également utiliser la stratégie de groupe pour contrôler ces paramètres d'authentification et de chiffrement, ainsi que d'autres aspects de RDS.

Stratégie de groupe

Il existe un certain nombre de paramètres de stratégie de groupe pour RDS dans Windows Server 2008 R2. Ceux-ci se trouvent sous Configuration ordinateur Stratégies Modèles d'administration Composants Windows Services Bureau à distance dans la console de gestion des stratégies de groupe de votre domaine, comme illustré à la figure 3.

figure 3

Comme vous pouvez le constater, il existe des stratégies pour les licences, le client RDC et l'hôte de session RD. Les stratégies liées à la sécurité pour l'hôte de session Bureau à distance incluent:

• Modèle de certificat d'authentification serveur: Utilisez cette stratégie pour spécifier le nom du modèle de certificat qui détermine le certificat sélectionné automatiquement pour authentifier un serveur hôte de session Bureau à distance. Si vous activez cette stratégie, seuls les certificats créés à l'aide du modèle spécifié seront pris en compte lors de la sélection d'un certificat pour authentifier le serveur hôte de session Bureau à distance.
• Définir le niveau de cryptage de la connexion client: Cette stratégie est utilisée pour contrôler si l'utilisation d'un niveau de cryptage spécifique est requise. Lorsque vous activez la stratégie, toutes les communications doivent utiliser le niveau de cryptage spécifié. Le niveau de cryptage par défaut est Elevé.
• Toujours demander le mot de passe lors de la connexion: Vous pouvez utiliser cette stratégie pour forcer RDS à toujours demander le mot de passe de l'utilisateur lors de la connexion à une session Bureau à distance, même si le mot de passe est saisi dans le client du CDR. Par défaut, les utilisateurs peuvent se connecter automatiquement si le mot de passe est saisi dans le client RDC.
• Exiger une communication RPC sécurisée: L'activation de cette stratégie signifie que seules les demandes authentifiées et chiffrées des clients seront autorisées. Les communications avec des clients non approuvés ne seront pas autorisées.
• Utilisation obligatoire de connexions RDP (Security Layer) spécifiques: Si vous activez cette stratégie, toutes les communications entre les clients et les serveurs d’hôte de session doivent utiliser la couche de sécurité spécifiée ici (RDP, Negotiate ou SSL / TLS).
• Ne pas autoriser les administrateurs locaux à personnaliser les autorisations: Cette stratégie désactive les droits d'administrateur pour personnaliser les autorisations de sécurité dans l'outil de configuration d'hôte de session Bureau à distance, afin d'empêcher les administrateurs locaux de modifier les groupes d'utilisateurs dans l'onglet Autorisations de l'outil de configuration.
• Exiger une authentification utilisateur pour les connexions distantes à l'aide de l'authentification au niveau du réseau: Avec cette stratégie, vous pouvez exiger une NLA pour toutes les connexions distantes au serveur hôte de session Bureau à distance. Seuls les clients prenant en charge NLA pourront se connecter.

Remarque:
Voici comment déterminer si un ordinateur client prend en charge l’authentification au niveau du réseau: Ouvrez le client RDC, cliquez sur l’icône située dans le coin supérieur gauche, puis sélectionnez "sur". Si NLA est pris en charge, vous verrez" Authentification au niveau du réseau prise en charge ".

Les autres paramètres de stratégie de groupe qui méritent d'être vérifiés relèvent du nœud client de connexion RD. Ceux-ci inclus:

• Ne laissez pas les mots de passe être sauvegardés: L'activation de cette stratégie désactive la case à cocher pour enregistrer le mot de passe dans la boîte de dialogue du client RDC. Si un utilisateur ouvre un fichier RDP et enregistre ses paramètres, les mots de passe précédemment enregistrés seront supprimés. Cela oblige l'utilisateur à entrer son mot de passe chaque fois qu'il se connecte.
• Spécifiez les empreintes SHA1 des certificats représentant la confiance .éditeurs RDP: Avec cette stratégie, vous pouvez spécifier une liste d'empreintes digitales de certificats SHA1. Lorsqu'un certificat correspond à une empreinte numérique de la liste, il est sécurisé.
• Demander des informations d'identification sur l'ordinateur client: Cette stratégie entraîne la demande d'informations d'identification aux utilisateurs sur l'ordinateur client plutôt que sur l'hôte de session Bureau à distance.
• Configurer l'authentification du serveur pour le client: Avec cette stratégie, vous pouvez déterminer si un client peut établir une connexion à l'hôte de session Bureau à distance lorsqu'il ne peut pas authentifier le serveur hôte de session Bureau à distance. Le paramètre de sécurité le plus élevé est "Ne pas se connecter si l'authentification échoue".

Vous pouvez également utiliser la stratégie de groupe pour configurer la conformité FIPS, mais vous ne trouverez pas cette stratégie ici avec les autres stratégies de sécurité RDS. Au lieu de cela, il se trouve dans Configuration ordinateur Paramètres Windows Paramètres de sécurité Stratégies locales Options de sécurité. Dans le volet de droite, faites défiler jusqu'à: "Cryptographie système: utilisez des algorithmes conformes à FIPS pour le cryptage, le hachage et la signature". Lorsque vous activez cette stratégie, elle ne prend en charge que l'algorithme de cryptage Triple DES (3DES) pour les communications RDS.

Accès Web RD

Pour les ordinateurs clients sur lesquels le logiciel client RDC n'est pas installé, les utilisateurs peuvent accéder aux applications publiées auxquelles ils ont accès à l'aide du navigateur Web. L'utilisateur accède à l'URL sur laquelle les ressources RDS sont publiées. Le serveur d'accès Web du RD est un serveur distinct de l'hôte de session du RD. Vous définissez quels serveurs d’accès Web RD peuvent se connecter à quels serveurs d’hôte de session Bureau à distance.

L'interface Web est configurée avec SSL et l'utilisateur doit être authentifié avec ses informations d'identification. L'utilisateur authentifié ne pourra voir que les programmes RemoteApp que son compte est autorisé à utiliser, car les programmes publiés sont "découpés", à l'aide d'une liste de contrôle d'accès.

Le serveur d'accès Web utilise un certificat X.509 pour assurer le cryptage. Par défaut, un certificat auto-signé est utilisé. Pour une meilleure sécurité, vous devez obtenir un certificat auprès d'une autorité de certification publique ou de l'infrastructure à clé publique de votre entreprise.

Passerelle RD

La passerelle RD (RDG) est utilisée pour donner accès aux ressources RD aux utilisateurs via Internet. Le serveur de passerelle est situé sur le bord et filtre les demandes RDS entrantes en fonction d'un serveur NPS (Network Policy Server). Le NPS utilise deux stratégies: la stratégie d'autorisation de connexion (CAP), qui répertorie les utilisateurs pouvant accéder au RDG, et la stratégie d'autorisation de ressources (RAP), qui spécifie les périphériques auxquels l'utilisateur CAP peut se connecter via le RDG.

Résumé

Les services de bureau à distance dans Windows Server 2008 R2 étendent considérablement les fonctionnalités de son prédécesseur, les services Terminal Server, mais présentent également de nouveaux problèmes de sécurité qui doivent être résolus. Suivre les meilleures pratiques de sécurité pour la configuration des composants de votre déploiement RDS (hôte de session Bureau à distance, serveur d'accès Web au Bureau à distance, passerelle des services Bureau à distance et le client) et utiliser la stratégie de groupe pour contrôler la configuration vous aideront à maintenir un environnement sécurisé tout en en tirant parti. RDS d’applications et de postes de travail complets à vos utilisateurs.

Publier des vues:
7 753

signaler cette annonce