Considérations de sécurité et meilleures pratiques
Remarque :
Votre organisation peut avoir besoin de respecter des normes de sécurité spécifiques pour satisfaire aux exigences réglementaires. Ce document ne couvre pas ce sujet, car ces normes de sécurité évoluent avec le temps. Pour des informations à jour sur les normes de sécurité et les produits Citrix, consultez http://www.citrix.com/security/.
Meilleures pratiques de sécurité
Maintenez toutes les machines de votre environnement à jour avec les correctifs de sécurité. Un avantage est que vous pouvez utiliser des clients légers comme terminaux, ce qui simplifie cette tâche.
Protégez toutes les machines de votre environnement avec un logiciel antivirus.
Envisagez d’utiliser un logiciel anti-malware spécifique à la plateforme.
Lors de l’installation de logiciels, installez-les dans les chemins par défaut fournis.
- Si vous installez un logiciel à un emplacement de fichier autre que le chemin par défaut fourni, envisagez d’ajouter des mesures de sécurité supplémentaires, telles que des autorisations restreintes, à votre emplacement de fichier.
Toutes les communications réseau doivent être sécurisées et chiffrées de manière appropriée pour correspondre à votre politique de sécurité. Vous pouvez sécuriser toutes les communications entre les ordinateurs Microsoft Windows à l’aide d’IPSec ; consultez la documentation de votre système d’exploitation pour savoir comment procéder. De plus, la communication entre les appareils utilisateur et les bureaux est sécurisée via Citrix SecureICA, qui est configuré par défaut avec un chiffrement de 128 bits. Vous pouvez configurer SecureICA lors de la création ou de la mise à jour d’un groupe de mise à disposition.
Remarque :
Citrix SecureICA fait partie du protocole ICA/HDX, mais ce n’est pas un protocole de sécurité réseau conforme aux normes comme Transport Layer Security (TLS). Vous pouvez également sécuriser les communications réseau entre les appareils utilisateur et les bureaux à l’aide de TLS. Pour configurer TLS, consultez Transport Layer Security (TLS).
Appliquez les meilleures pratiques Windows pour la gestion des comptes. Ne créez pas de compte sur un modèle ou une image avant qu’il ne soit dupliqué par Machine Creation Services ou Provisioning Services. Ne planifiez pas de tâches à l’aide de comptes de domaine privilégiés stockés. Ne créez pas manuellement de comptes machine Active Directory partagés. Ces pratiques aideront à empêcher une attaque de machine d’obtenir des mots de passe de compte locaux persistants et de les utiliser ensuite pour se connecter à des images partagées MCS/PVS appartenant à d’autres.
Pare-feu
Protégez toutes les machines de votre environnement avec des pare-feu périmétriques, y compris aux limites des enclaves, le cas échéant.
Toutes les machines de votre environnement doivent être protégées par un pare-feu personnel. Lorsque vous installez les composants principaux et les VDA, vous pouvez choisir d’ouvrir automatiquement les ports requis pour la communication des composants et des fonctionnalités si le service Pare-feu Windows est détecté (même si le pare-feu n’est pas activé). Vous pouvez également choisir de configurer manuellement ces ports de pare-feu. Si vous utilisez un pare-feu différent, vous devez le configurer manuellement.
Si vous migrez un environnement conventionnel vers cette version, vous devrez peut-être repositionner un pare-feu périmétrique existant ou ajouter de nouveaux pare-feu périmétriques. Par exemple, supposons qu’il existe un pare-feu périmétrique entre un client conventionnel et un serveur de base de données dans le centre de données. Lorsque cette version est utilisée, ce pare-feu périmétrique doit être placé de manière à ce que le bureau virtuel et le périphérique utilisateur se trouvent d’un côté, et les serveurs de base de données et les Delivery Controllers du centre de données de l’autre côté. Par conséquent, envisagez de créer une enclave au sein de votre centre de données pour contenir les serveurs de base de données et les contrôleurs. Envisagez également d’avoir une protection entre le périphérique utilisateur et le bureau virtuel.
Remarque :
Les ports TCP 1494 et 2598 sont utilisés pour ICA et CGP et sont donc susceptibles d’être ouverts au niveau des pare-feu afin que les utilisateurs extérieurs au centre de données puissent y accéder. Citrix vous recommande de ne pas utiliser ces ports pour autre chose, afin d’éviter la possibilité de laisser par inadvertance des interfaces administratives exposées aux attaques. Les ports 1494 et 2598 sont officiellement enregistrés auprès de l’Internet Assigned Number Authority (http://www.iana.org/).
Sécurité des applications
Pour empêcher les utilisateurs non-administrateurs d’effectuer des actions malveillantes, nous vous recommandons de configurer des règles AppLocker Windows pour les programmes d’installation, les applications, les exécutables et les scripts sur l’hôte VDA et sur le client Windows local.
Gérer les privilèges utilisateur
N’accordez aux utilisateurs que les capacités dont ils ont besoin. Les privilèges Microsoft Windows continuent d’être appliqués aux bureaux de la manière habituelle : configurez les privilèges via l’attribution des droits utilisateur et les appartenances aux groupes via la stratégie de groupe. Un avantage de cette version est qu’il est possible d’accorder à un utilisateur des droits administratifs sur un bureau sans lui accorder également le contrôle physique de l’ordinateur sur lequel le bureau est stocké.
Notez ce qui suit lors de la planification des privilèges de bureau :
- Par défaut, lorsque des utilisateurs non privilégiés se connectent à un bureau, ils voient le fuseau horaire du système exécutant le bureau au lieu du fuseau horaire de leur propre périphérique utilisateur. Pour plus d’informations sur la façon de permettre aux utilisateurs de voir leur heure locale lorsqu’ils utilisent des bureaux, consultez l’article Gérer les groupes de mise à disposition.
- Un utilisateur qui est administrateur sur un bureau a un contrôle total sur ce bureau. Si un bureau est un bureau en pool plutôt qu’un bureau dédié, l’utilisateur doit être digne de confiance vis-à-vis de tous les autres utilisateurs de ce bureau, y compris les futurs utilisateurs. Tous les utilisateurs du bureau doivent être conscients du risque permanent potentiel pour la sécurité de leurs données que représente cette situation. Cette considération ne s’applique pas aux bureaux dédiés, qui n’ont qu’un seul utilisateur ; cet utilisateur ne doit pas être administrateur sur un autre bureau.
- Un utilisateur qui est administrateur sur un bureau peut généralement installer des logiciels sur ce bureau, y compris des logiciels potentiellement malveillants. L’utilisateur peut également potentiellement surveiller ou contrôler le trafic sur tout réseau connecté au bureau.
Gérer les droits d’ouverture de session
Les droits d’ouverture de session sont requis pour les comptes d’utilisateur et les comptes d’ordinateur. Comme pour les privilèges Microsoft Windows, les droits d’ouverture de session continuent d’être appliqués aux bureaux de la manière habituelle : configurez les droits d’ouverture de session via l’attribution des droits utilisateur et les appartenances aux groupes via la stratégie de groupe.
Les droits d’ouverture de session Windows sont : ouvrir une session localement, ouvrir une session via les services Bureau à distance, ouvrir une session sur le réseau (accéder à cet ordinateur depuis le réseau), ouvrir une session en tant que tâche de traitement par lots et ouvrir une session en tant que service.
Pour les comptes d’ordinateur, accordez aux ordinateurs uniquement les droits d’ouverture de session dont ils ont besoin. Le droit d’ouverture de session « Accéder à cet ordinateur à partir du réseau » est requis :
- Sur les VDA, pour les comptes d’ordinateur des Delivery Controller
- Sur les Delivery Controller, pour les comptes d’ordinateur des VDA. Consultez Découverte de contrôleur basée sur l’unité d’organisation Active Directory.
- Sur les serveurs StoreFront™, pour les comptes d’ordinateur des autres serveurs du même groupe de serveurs StoreFront
Pour les comptes d’utilisateur, accordez aux utilisateurs uniquement les droits d’ouverture de session dont ils ont besoin.
Selon Microsoft, par défaut, le groupe Utilisateurs du Bureau à distance se voit accorder le droit d’ouverture de session « Autoriser l’ouverture de session via les services Bureau à distance » (sauf sur les contrôleurs de domaine).
La stratégie de sécurité de votre organisation peut stipuler explicitement que ce groupe doit être supprimé de ce droit d’ouverture de session. Considérez l’approche suivante :
- Le Virtual Delivery Agent (VDA) pour OS multi-session utilise les services Bureau à distance de Microsoft. Vous pouvez configurer le groupe Utilisateurs du Bureau à distance comme un groupe restreint et contrôler l’appartenance au groupe via les stratégies de groupe Active Directory. Reportez-vous à la documentation Microsoft pour plus d’informations.
- Pour les autres composants de Citrix Virtual Apps and Desktops™, y compris le VDA pour OS mono-session, le groupe Utilisateurs du Bureau à distance n’est pas requis. Ainsi, pour ces composants, le groupe Utilisateurs du Bureau à distance ne nécessite pas le droit d’ouverture de session « Autoriser l’ouverture de session via les services Bureau à distance » ; vous pouvez le supprimer. De plus :
- Si vous administrez ces ordinateurs via les services Bureau à distance, assurez-vous que tous ces administrateurs sont déjà membres du groupe Administrateurs.
- Si vous n’administrez pas ces ordinateurs via les services Bureau à distance, envisagez de désactiver les services Bureau à distance eux-mêmes sur ces ordinateurs.
Bien qu’il soit possible d’ajouter des utilisateurs et des groupes au droit d’ouverture de session « Refuser l’ouverture de session via les services Bureau à distance », l’utilisation des droits d’ouverture de session de refus n’est généralement pas recommandée. Reportez-vous à la documentation Microsoft pour plus d’informations.
Configurer les droits utilisateur
L’installation de Delivery Controller™ crée les services Windows suivants :
- Citrix AD Identity Service (NT SERVICE\CitrixADIdentityService) : Gère les comptes d’ordinateur Microsoft Active Directory pour les machines virtuelles.
- Citrix Analytics (NT SERVICE\CitrixAnalytics) : Collecte les informations d’utilisation de la configuration du site pour Citrix, si cette collecte a été approuvée par l’administrateur du site. Il soumet ensuite ces informations à Citrix, pour aider à améliorer le produit.
- Citrix App Library (NT SERVICE\CitrixAppLibrary) : Prend en charge la gestion et le provisionnement des AppDisks, l’intégration d’AppDNA et la gestion d’App-V.
- Citrix Broker Service (NT SERVICE\CitrixBrokerService) : Sélectionne les bureaux virtuels ou les applications disponibles pour les utilisateurs.
- Citrix Configuration Logging Service (NT SERVICE\CitrixConfigurationLogging) : Enregistre toutes les modifications de configuration et autres changements d’état effectués par les administrateurs sur le site.
- Citrix Configuration Service (NT SERVICE\CitrixConfigurationService) : Référentiel à l’échelle du site pour la configuration partagée.
- Citrix Delegated Administration Service (NT SERVICE\CitrixDelegatedAdmin) : Gère les autorisations accordées aux administrateurs.
- Citrix Environment Test Service (NT SERVICE\CitrixEnvTest) : Gère les auto-tests des autres services du Delivery Controller.
- Citrix Host Service (NT SERVICE\CitrixHostService) : Stocke les informations sur les infrastructures d’hyperviseur utilisées dans un déploiement Citrix Virtual Apps ou Citrix Virtual Desktops, et offre également des fonctionnalités utilisées par la console pour énumérer les ressources dans un pool d’hyperviseurs.
- Citrix Machine Creation Services (NT SERVICE\CitrixMachineCreationService) : Orchestre la création de machines virtuelles de bureau.
- Citrix Monitor Service (NT SERVICE\CitrixMonitor) : Collecte des métriques pour Citrix Virtual Apps ou Citrix Virtual Desktops, stocke les informations historiques et fournit une interface de requête pour les outils de dépannage et de création de rapports.
- Citrix Storefront Service (NT SERVICE\ CitrixStorefront) : Prend en charge la gestion de StoreFront. (Il ne fait pas partie du composant StoreFront lui-même.)
- Citrix Storefront Privileged Administration Service (NT SERVICE\CitrixPrivilegedService) : Prend en charge les opérations de gestion privilégiée de StoreFront. (Il ne fait pas partie du composant StoreFront lui-même.)
- Citrix Config Synchronizer Service (NT SERVICE\CitrixConfigSyncService) : Propage les données de configuration de la base de données principale du site vers le cache d’hôte local.
- Citrix High Availability Service (NT SERVICE\CitrixHighAvailabilityService) : Sélectionne les bureaux virtuels ou les applications disponibles pour les utilisateurs, lorsque la base de données principale du site est indisponible.
L’installation du Delivery Controller crée également les services Windows suivants. Ceux-ci sont également créés lors de l’installation avec d’autres composants Citrix :
- Citrix Diagnostic Facility COM Server (NT SERVICE\CdfSvc) : Prend en charge la collecte d’informations de diagnostic à utiliser par le support Citrix.
- Citrix Telemetry Service (NT SERVICE\CitrixTelemetryService) : Collecte des informations de diagnostic pour analyse par Citrix, afin que les résultats d’analyse et les recommandations puissent être consultés par les administrateurs pour aider à diagnostiquer les problèmes du site.
L’installation du Delivery Controller crée également le service Windows suivant. Il n’est pas utilisé actuellement. S’il a été activé, désactivez-le.
- Citrix Remote Broker Provider (NT SERVICE\XaXdCloudProxy)
L’installation du Delivery Controller crée également les services Windows suivants. Ceux-ci ne sont pas utilisés actuellement, mais doivent être activés. Ne les désactivez pas.
- Citrix Orchestration Service (NT SERVICE\CitrixOrchestration)
- Citrix Trust Service (NT SERVICE\CitrixTrust)
À l’exception du service d’administration privilégiée Citrix Storefront, ces services se voient accorder le droit d’ouverture de session « Ouvrir une session en tant que service » et les privilèges « Ajuster les quotas de mémoire pour un processus », « Générer des audits de sécurité » et « Remplacer un jeton de niveau processus ». Vous n’avez pas besoin de modifier ces droits d’utilisateur. Ces privilèges ne sont pas utilisés par le Delivery Controller et sont automatiquement désactivés.
Configurer les paramètres de service
À l’exception du service d’administration privilégiée Citrix Storefront et du service de télémétrie Citrix, les services Windows du Delivery Controller répertoriés ci-dessus dans la section (#configure-user-rights) sont configurés pour ouvrir une session en tant qu’identité SERVICE RÉSEAU. Ne modifiez pas ces paramètres de service.
Le service Citrix Config Synchronizer a besoin que le compte SERVICE RÉSEAU appartienne au groupe Administrateurs locaux sur le Delivery Controller. Cela permet au cache d’hôte local de fonctionner correctement.
Le service d’administration privilégiée Citrix Storefront est configuré pour ouvrir une session en tant que système local (NT AUTHORITY\SYSTEM). Ceci est requis pour les opérations StoreFront du Delivery Controller qui ne sont normalement pas disponibles pour les services (y compris la création de sites Microsoft IIS). Ne modifiez pas ses paramètres de service.
Le service de télémétrie Citrix est configuré pour ouvrir une session en tant que sa propre identité spécifique au service.
Vous pouvez désactiver le service de télémétrie Citrix. En dehors de ce service et des services déjà désactivés, ne désactivez aucun autre de ces services Windows du Delivery Controller.
Configurer les paramètres du Registre
Il n’est plus nécessaire d’activer la création de noms et de dossiers de fichiers 8.3 sur le système de fichiers VDA. La clé de registre NtfsDisable8dot3NameCreation peut être configurée pour désactiver la création de noms et de dossiers de fichiers 8.3. Vous pouvez également configurer cela à l’aide de la commande fsutil.exe behavior set disable8dot3.
Implications de sécurité du scénario de déploiement
Votre environnement utilisateur peut contenir des périphériques utilisateur non gérés par votre organisation et entièrement sous le contrôle de l’utilisateur, ou des périphériques utilisateur gérés et administrés par votre organisation. Les considérations de sécurité pour ces deux environnements sont généralement différentes.
Périphériques utilisateur gérés
Les périphériques utilisateur gérés sont sous contrôle administratif ; ils sont soit sous votre propre contrôle, soit sous le contrôle d’une autre organisation à laquelle vous faites confiance. Vous pouvez configurer et fournir des périphériques utilisateur directement aux utilisateurs ; alternativement, vous pouvez fournir des terminaux sur lesquels un seul bureau s’exécute en mode plein écran uniquement. Suivez les meilleures pratiques de sécurité générales décrites ci-dessus pour tous les périphériques utilisateur gérés. Cette version a l’avantage de nécessiter un minimum de logiciels sur un périphérique utilisateur.
Un périphérique utilisateur géré peut être configuré pour être utilisé en mode plein écran uniquement ou en mode fenêtre :
- Mode plein écran uniquement : les utilisateurs s’y connectent avec l’écran de connexion Windows habituel. Les mêmes informations d’identification utilisateur sont ensuite utilisées pour se connecter automatiquement à cette version.
- Les utilisateurs voient leur bureau dans une fenêtre : les utilisateurs se connectent d’abord au périphérique utilisateur, puis se connectent à cette version via un site Web fourni avec la version.
Périphériques utilisateur non gérés
Les périphériques utilisateur qui ne sont pas gérés et administrés par une organisation de confiance ne peuvent pas être considérés comme étant sous contrôle administratif. Par exemple, vous pouvez autoriser les utilisateurs à obtenir et à configurer leurs propres périphériques, mais les utilisateurs peuvent ne pas suivre les meilleures pratiques de sécurité générales décrites ci-dessus. Cette version a l’avantage de permettre de fournir des bureaux en toute sécurité aux périphériques utilisateur non gérés. Ces périphériques doivent toujours disposer d’une protection antivirus de base qui déjouera les attaques de type enregistreur de frappe et autres attaques d’entrée similaires.
Considérations relatives au stockage des données
Lorsque vous utilisez cette version, vous pouvez empêcher les utilisateurs de stocker des données sur des périphériques utilisateur qui sont sous leur contrôle physique. Cependant, vous devez toujours tenir compte des implications du stockage de données par les utilisateurs sur les bureaux. Il n’est pas recommandé aux utilisateurs de stocker des données sur les bureaux ; les données doivent être conservées sur des serveurs de fichiers, des serveurs de bases de données ou d’autres référentiels où elles peuvent être protégées de manière appropriée.
Votre environnement de bureau peut se composer de différents types de bureaux, tels que des bureaux en pool et des bureaux dédiés. Les utilisateurs ne doivent jamais stocker de données sur des bureaux partagés entre utilisateurs, tels que les bureaux en pool. Si les utilisateurs stockent des données sur des bureaux dédiés, ces données doivent être supprimées si le bureau est ensuite mis à la disposition d’autres utilisateurs.
Environnements de versions mixtes
Les environnements de versions mixtes sont inévitables lors de certaines mises à niveau. Suivez les meilleures pratiques et minimisez le temps pendant lequel les composants Citrix de différentes versions coexistent. Dans les environnements de versions mixtes, la politique de sécurité, par exemple, peut ne pas être appliquée uniformément.
Remarque :
Ceci est typique d’autres produits logiciels ; l’utilisation d’une version antérieure d’Active Directory n’applique que partiellement la stratégie de groupe avec les versions ultérieures de Windows.
Le scénario suivant décrit un problème de sécurité pouvant survenir dans un environnement Citrix spécifique à versions mixtes. Lorsque Citrix Receiver 1.7 est utilisé pour se connecter à un bureau virtuel exécutant le VDA dans XenApp et XenDesktop 7.6 Feature Pack 2, le paramètre de stratégie Autoriser le transfert de fichiers entre le bureau et le client est activé dans le Site mais ne peut pas être désactivé par un Delivery Controller exécutant XenApp et XenDesktop 7.1. Il ne reconnaît pas le paramètre de stratégie, qui a été publié dans une version ultérieure du produit. Ce paramètre de stratégie permet aux utilisateurs de télécharger et de téléverser des fichiers vers leur bureau virtuel, ce qui constitue le problème de sécurité. Pour contourner ce problème, mettez à niveau le Delivery Controller (ou une instance autonome de Studio) vers la version 7.6 Feature Pack 2, puis utilisez la stratégie de groupe pour désactiver le paramètre de stratégie. Vous pouvez également utiliser une stratégie locale sur tous les bureaux virtuels concernés.
Considérations de sécurité relatives à Remote PC Access
Remote PC Access implémente les fonctionnalités de sécurité suivantes :
- L’utilisation de cartes à puce est prise en charge.
- Lorsqu’une session à distance se connecte, l’écran du PC de bureau apparaît vide.
- Remote PC Access redirige toutes les entrées clavier et souris vers la session à distance, à l’exception de CTRL+ALT+SUPPR et des cartes à puce et périphériques biométriques compatibles USB.
- SmoothRoaming est pris en charge pour un seul utilisateur.
- Lorsqu’un utilisateur a une session à distance connectée à un PC de bureau, seul cet utilisateur peut reprendre l’accès local au PC de bureau. Pour reprendre l’accès local, l’utilisateur appuie sur Ctrl-Alt-Suppr sur le PC local, puis se connecte avec les mêmes informations d’identification que celles utilisées par la session à distance. L’utilisateur peut également reprendre l’accès local en insérant une carte à puce ou en utilisant la biométrie, si votre système dispose d’une intégration appropriée de fournisseur d’informations d’identification tiers. Ce comportement par défaut peut être remplacé en activant la commutation rapide d’utilisateur via les objets de stratégie de groupe (GPO) ou en modifiant le registre.
Remarque :
Citrix recommande de ne pas attribuer de privilèges d’administrateur VDA aux utilisateurs de session généraux.
Attributions automatiques
Par défaut, Remote PC Access prend en charge l’attribution automatique de plusieurs utilisateurs à un VDA. Dans XenDesktop 5.6 Feature Pack 1, les administrateurs pouvaient remplacer ce comportement à l’aide du script PowerShell RemotePCAccess.ps1. Cette version utilise une entrée de registre pour autoriser ou interdire plusieurs attributions automatiques de PC à distance ; ce paramètre s’applique à l’ensemble du Site.
Attention :
Toute modification incorrecte du registre peut entraîner de graves problèmes qui pourraient vous obliger à réinstaller votre système d’exploitation. Citrix ne peut garantir la résolution des problèmes résultant d’une utilisation incorrecte de l’Éditeur du Registre. Utilisez l’Éditeur du Registre à vos propres risques. Veillez à sauvegarder le registre avant de le modifier.
Pour restreindre les attributions automatiques à un seul utilisateur :
Sur chaque Controller du Site, définissez l’entrée de registre suivante :
HKEY\_LOCAL\_MACHINE\Software\Citrix|DesktopServer
Name: AllowMultipleRemotePCAssignments
Type: REG_DWORD
Data: 0 = Disable multiple user assignment, 1 = (Default) Enable multiple user assignment.
S’il existe des attributions d’utilisateurs, supprimez-les à l’aide des commandes SDK pour que le VDA puisse ensuite être éligible à une seule attribution automatique.
- Supprimez tous les utilisateurs attribués du VDA :
$machine.AssociatedUserNames | %{ Remove-BrokerUser-Name $_ -Machine $machine - Supprimez le VDA du groupe de mise à disposition :
$machine | Remove-BrokerMachine -DesktopGroup $desktopGroup
Redémarrez le PC physique du bureau.
Confiance XML
Le paramètre de confiance XML s’applique aux déploiements qui utilisent :
- Un StoreFront sur site.
- Une technologie d’authentification d’abonné (utilisateur) qui ne nécessite pas de mots de passe. Des exemples de ces technologies sont le pass-through de domaine, les cartes à puce, SAML et les solutions Veridium.
L’activation du paramètre de confiance XML permet aux utilisateurs de s’authentifier avec succès, puis de lancer des applications. Le Delivery Controller fait confiance aux informations d’identification envoyées par StoreFront. Activez ce paramètre uniquement lorsque vous avez sécurisé les communications entre vos Delivery Controllers et StoreFront (à l’aide de pare-feu, d’IPsec ou d’autres recommandations de sécurité).
Ce paramètre est désactivé par défaut.
Utilisez le SDK PowerShell de Citrix Virtual Apps and Desktops pour vérifier, activer ou désactiver le paramètre de confiance XML.
- Pour vérifier la valeur actuelle du paramètre de confiance XML, exécutez
Get-BrokerSiteet examinez la valeur deTrustRequestsSentToTheXMLServicePort. - Pour activer la confiance XML, exécutez
Set-BrokerSite -TrustRequestsSentToTheXmlServicePort $true. - Pour désactiver la confiance XML, exécutez
Set-BrokerSite -TrustRequestsSentToTheXmlServicePort $false.
Dans cet article
- Meilleures pratiques de sécurité
- Gérer les privilèges utilisateur
- Gérer les droits d’ouverture de session
- Configurer les droits utilisateur
- Configurer les paramètres de service
- Configurer les paramètres du Registre
- Implications de sécurité du scénario de déploiement
- Considérations de sécurité relatives à Remote PC Access
- Confiance XML