Autoriser les applications Win32 métier sur les appareils en mode S gérés par Intune
Remarque
Certaines fonctionnalités de Windows Defender Contrôle d’application (WDAC) ne sont disponibles que sur des versions spécifiques de Windows. Pour plus d’informations, consultez Windows Defender disponibilité des fonctionnalités de contrôle d’application.
Vous pouvez utiliser Microsoft Intune pour déployer et exécuter des applications Win32 critiques et des composants Windows normalement bloqués en mode S sur vos Windows 10 gérées par Intune sur des appareils en mode S. Par exemple, PowerShell.exe.
Avec Intune, vous pouvez configurer des appareils en mode S managé à l’aide d’une stratégie supplémentaire de contrôle d’application Windows Defender (WDAC) qui étend la stratégie de base du mode S pour autoriser les applications que votre organization utilise. Cette fonctionnalité change la posture de sécurité du mode S de « Microsoft a vérifié chaque application » en « Microsoft ou votre organization a vérifié chaque application ».
Pour une vue d’ensemble et une brève démonstration de cette fonctionnalité, consultez cette vidéo :
Processus d’autorisation de stratégie
Les étapes générales pour développer la stratégie de base en mode S sur vos Windows 10 gérés par Intune dans les appareils en mode S sont de générer une stratégie supplémentaire, de signer cette stratégie, de charger la stratégie signée dans Intune et de l’affecter à des groupes d’utilisateurs ou d’appareils. Étant donné que vous avez besoin d’accéder aux applets de commande PowerShell pour générer votre stratégie supplémentaire, vous devez créer et gérer vos stratégies sur un appareil en mode non-S. Une fois que la stratégie a été chargée dans Intune, avant de déployer la stratégie plus largement, affectez-la à un seul Windows 10 de test sur un appareil en mode S pour vérifier le fonctionnement attendu.
Générez une stratégie supplémentaire avec les outils WDAC.
Cette stratégie étend la stratégie de base du mode S pour autoriser d’autres applications. Tout ce qui est autorisé par la stratégie de base du mode S ou par votre stratégie supplémentaire est autorisé à s’exécuter. Vos stratégies supplémentaires peuvent spécifier des règles de chemin de fichier, des éditeurs approuvés, etc.
Pour plus d’informations sur la création de stratégies supplémentaires, consultez Déployer plusieurs stratégies WDAC. Pour plus d’informations sur le type de règles à créer pour votre stratégie, consultez Déployer des règles de stratégie WDAC et des règles de fichier.
Les instructions suivantes sont un ensemble de base pour la création d’une stratégie supplémentaire en mode S :
Créez une stratégie de base à l’aide de New-CIPolicy.
New-CIPolicy -MultiplePolicyFormat -ScanPath <path> -UserPEs -FilePath "<path>\SupplementalPolicy.xml" -Level FilePublisher -Fallback SignedVersion,Publisher,HashRemplacez-la par une stratégie supplémentaire à l’aide de Set-CIPolicyIdInfo.
Set-CIPolicyIdInfo -SupplementsBasePolicyID 5951A96A-E0B5-4D3D-8FB8-3E5B61030784 -FilePath "<path>\SupplementalPolicy.xml"Pour les stratégies qui complètent la stratégie de base en mode S, utilisez
-SupplementsBasePolicyID 5951A96A-E0B5-4D3D-8FB8-3E5B61030784. Cet ID est l’ID de stratégie du mode S.Placez la stratégie en mode d’application à l’aide de Set-RuleOption.
Set-RuleOption -FilePath "<path>\SupplementalPolicy.xml>" -Option 3 -DeleteCette commande supprime le qualificateur « mode audit ».
Étant donné que vous signez votre stratégie, vous devez autoriser le certificat de signature que vous utilisez pour signer la stratégie. Si vous le souhaitez, autorisez également un ou plusieurs signataires supplémentaires qui peuvent être utilisés pour signer les mises à jour de la stratégie à l’avenir. L’étape suivante du processus global, Signer la stratégie, la décrit plus en détail.
Pour ajouter le certificat de signature à la stratégie WDAC, utilisez Add-SignerRule.
Add-SignerRule -FilePath <policypath> -CertificatePath <certpath> -User -UpdateConvertissez en
.binà l’aide de ConvertFrom-CIPolicy.ConvertFrom-CIPolicy -XmlFilePath "<path>\SupplementalPolicy.xml" -BinaryFilePath "<path>\SupplementalPolicy.bin>
Signez la stratégie.
Les stratégies supplémentaires du mode S doivent être signées numériquement. Pour signer votre stratégie, utilisez l’infrastructure à clé publique (PKI) personnalisée de votre organization. Pour plus d’informations sur la signature à l’aide d’une autorité de certification interne, consultez Créer un certificat de signature de code pour WDAC.
Astuce
Pour plus d’informations, consultez Signature de code Azure, démocratisation de la confiance pour les développeurs et les consommateurs.
Une fois que vous l’avez signé, renommez votre stratégie en
{PolicyID}.p7b. Obtenez le PolicyID à partir du code XML de stratégie supplémentaire.Déployez la stratégie supplémentaire signée à l’aide de Microsoft Intune.
Accédez au portail Microsoft Intune, accédez à la page Applications clientes, puis sélectionnez Stratégies supplémentaires en mode S. Chargez la stratégie signée dans Intune et affectez-la à des groupes d’utilisateurs ou d’appareils. Intune génère des jetons d’autorisation pour le locataire et des appareils spécifiques. Intune déploie ensuite le jeton d’autorisation et la stratégie supplémentaires correspondants sur chaque appareil du groupe affecté. Ensemble, ces jetons et stratégies étendent la stratégie de base du mode S sur l’appareil.
Remarque
Lorsque vous mettez à jour votre stratégie supplémentaire, assurez-vous que le numéro de nouvelle version est strictement supérieur à la précédente. Intune n’autorise pas l’utilisation du même numéro de version. Pour plus d’informations sur la définition du numéro de version, consultez Set-CIPolicyVersion.
Processus standard de déploiement d’applications via Intune
Pour plus d’informations sur la procédure existante d’empaquetage de catalogues signés et de déploiement d’applications, consultez Gestion des applications Win32 dans Microsoft Intune.
Facultatif : Processus de déploiement d’applications à l’aide de catalogues
Votre stratégie supplémentaire peut être utilisée pour assouplir considérablement la stratégie de base du mode S, mais il existe des compromis de sécurité que vous devez prendre en compte pour ce faire. Par exemple, vous pouvez utiliser une règle de signataire pour approuver un signataire externe, mais qui autorise toutes les applications signées par ce certificat, ce qui peut inclure également des applications que vous ne souhaitez pas autoriser.
Au lieu d’autoriser des signataires externes à votre organization, Intune dispose de fonctionnalités permettant d’autoriser plus facilement les applications existantes à l’aide de catalogues signés. Cette fonctionnalité ne nécessite pas de repackaging ou d’accès au code source. Il fonctionne pour les applications qui peuvent être non signées ou même signées lorsque vous ne souhaitez pas approuver toutes les applications qui peuvent partager le même certificat de signature.
Le processus de base consiste à générer un fichier catalogue pour chaque application à l’aide de l’inspecteur de package, puis à signer les fichiers catalogue à l’aide d’une infrastructure À clé publique personnalisée. Pour autoriser le certificat de signature de catalogue dans la stratégie supplémentaire, utilisez l’applet de commande PowerShell Add-SignerRule , comme indiqué précédemment à l’étape 1 du processus d’autorisation de stratégie. Après cela, utilisez le processus Standard pour déployer des applications via Intune décrit précédemment. Pour plus d’informations sur la génération de catalogues, consultez Déployer des fichiers catalogue pour prendre en charge WDAC.
Remarque
Chaque fois qu’une application est mise à jour, vous devez déployer un catalogue mis à jour. Essayez d’éviter d’utiliser des fichiers catalogue pour les applications qui se mettent à jour automatiquement et d’indiquer aux utilisateurs de ne pas mettre à jour les applications par eux-mêmes.
Exemple de stratégie
La stratégie suivante est un exemple qui autorise les débogueurs de noyau, PowerShell ISE et le Registre Rédacteur. Il montre également comment spécifier les certificats de signature de code et de signature de stratégie de votre organization.
<?xml version="1.0" encoding="utf-8"?>
<SiPolicy xmlns="urn:schemas-microsoft-com:sipolicy" PolicyType="Supplemental Policy">
<VersionEx>10.0.0.0</VersionEx>
<PlatformID>{2E07F7E4-194C-4D20-B7C9-6F44A6C5A234}</PlatformID>
<!--Standard S mode GUID-->
<BasePolicyID>{5951A96A-E0B5-4D3D-8FB8-3E5B61030784}</BasePolicyID>
<!--Unique policy GUID-->
<PolicyID>{52671094-ACC6-43CF-AAF1-096DC69C1345}</PolicyID>
<!--EKUS-->
<EKUs />
<!--File Rules-->
<FileRules>
<!--Allow kernel debuggers-->
<Allow ID="ID_ALLOW_CBD_0" FriendlyName="cdb.exe" FileName="CDB.Exe" />
<Allow ID="ID_ALLOW_KD_0" FriendlyName="kd.exe" FileName="kd.Exe" />
<Allow ID="ID_ALLOW_WINDBG_0" FriendlyName="windbg.exe" FileName="windbg.Exe" />
<Allow ID="ID_ALLOW_MSBUILD_0" FriendlyName="MSBuild.exe" FileName="MSBuild.Exe" />
<Allow ID="ID_ALLOW_NTSD_0" FriendlyName="ntsd.exe" FileName="ntsd.Exe" />
<!--Allow PowerShell ISE and Registry Editor-->
<Allow ID="ID_ALLOW_POWERSHELLISE_0" FriendlyName="powershell_ise.exe" FileName="powershell_ise.exe" />
<Allow ID="ID_ALLOW_REGEDIT_0" FriendlyName="regedit.exe" FileName="regedit.exe" />
</FileRules>
<!--Signers-->
<Signers>
<!--info of the certificate you will use to do any code/catalog signing-->
<Signer ID="EXAMPLE_ID_SIGNER_CODE" Name="Example Code Signing Certificate Friendly Name">
<CertRoot Type="TBS" Value="<value>" />
</Signer>
<!--info of the certificate you will use to sign your policy-->
<Signer ID="EXAMPLE_ID_SIGNER_POLICY" Name="Example Policy Signing Certificate Friendly Name">
<CertRoot Type="TBS" Value="<value>" />
</Signer>
</Signers>
<!--Driver Signing Scenarios-->
<SigningScenarios>
<SigningScenario Value="131" ID="ID_SIGNINGSCENARIO_KMCI" FriendlyName="Example Name">
<ProductSigners />
</SigningScenario>
<SigningScenario Value="12" ID="ID_SIGNINGSCENARIO_UMCI" FriendlyName="Example Name">
<ProductSigners>
<AllowedSigners>
<AllowedSigner SignerId="EXAMPLE_ID_SIGNER_CODE" />
</AllowedSigners>
<FileRulesRef>
<FileRuleRef RuleID="ID_ALLOW_CBD_0" />
<FileRuleRef RuleID="ID_ALLOW_KD_0" />
<FileRuleRef RuleID="ID_ALLOW_WINDBG_0" />
<FileRuleRef RuleID="ID_ALLOW_MSBUILD_0" />
<FileRuleRef RuleID="ID_ALLOW_NTSD_0" />
<FileRuleRef RuleID="ID_ALLOW_POWERSHELLISE_0" />
<FileRuleRef RuleID="ID_ALLOW_REGEDIT_0" />
</FileRulesRef>
</ProductSigners>
</SigningScenario>
</SigningScenarios>
<!--Specify one or more certificates that can be used to sign updated policy-->
<UpdatePolicySigners>
<UpdatePolicySigner SignerId="EXAMPLE_ID_SIGNER_POLICY" />
</UpdatePolicySigners>
<!--Specify one or more codesigning certificates to trust-->
<CiSigners>
<CiSigner SignerId="EXAMPLE_ID_SIGNER_CODE" />
</CiSigners>
<!-- example remove core isolation a.k.a. Hypervisor Enforced Code Integrity (HVCI) options, consider enabling if your system supports it-->
<HvciOptions>0</HvciOptions>
<Settings>
<Setting Provider="PolicyInfo" Key="Information" ValueName="Name">
<Value>
<String>Example Policy Name</String>
</Value>
</Setting>
<Setting Provider="PolicyInfo" Key="Information" ValueName="Id">
<Value>
<String>Example-Policy-10.0.0.0</String>
</Value>
</Setting>
</Settings>
</SiPolicy>
Suppression de stratégie
Pour rétablir une stratégie de mode S non modifiée, supprimez un ou plusieurs utilisateurs du groupe Intune ciblé qui a reçu la stratégie. Cette action déclenche la suppression de la stratégie et du jeton d’autorisation de l’appareil.
Vous pouvez également supprimer une stratégie supplémentaire via Intune.
<?xml version="1.0" encoding="utf-8"?>
<SiPolicy xmlns="urn:schemas-microsoft-com:sipolicy" PolicyType="Supplemental Policy">
<VersionEx>10.0.0.1</VersionEx>
<PlatformID>{2E07F7E4-194C-4D20-B7C9-6F44A6C5A234}</PlatformID>
<BasePolicyID>{5951A96A-E0B5-4D3D-8FB8-3E5B61030784}</BasePolicyID>
<PolicyID>{52671094-ACC6-43CF-AAF1-096DC69C1345}</PolicyID>
<Rules>
</Rules>
<!--EKUS-->
<EKUs />
<!--File Rules-->
<!--Signers-->
<Signers>
<!--info of the certificate you will use to sign your policy-->
<Signer ID="EXAMPLE_ID_SIGNER_POLICY" Name="Example Policy Signing Certificate Friendly Name">
<CertRoot Type="TBS" Value="<value>" />
</Signer>
</Signers>
<!--Driver Signing Scenarios-->
<SigningScenarios>
<SigningScenario Value="131" ID="ID_SIGNINGSCENARIO_KMCI" FriendlyName="KMCI">
<ProductSigners>
</ProductSigners>
</SigningScenario>
<SigningScenario Value="12" ID="ID_SIGNINGSCENARIO_UMCI" FriendlyName="UMCI">
<ProductSigners>
</ProductSigners>
</SigningScenario>
</SigningScenarios>
<UpdatePolicySigners>
<UpdatePolicySigner SignerId="EXAMPLE_ID_SIGNER_POLICY" />
</UpdatePolicySigners>
<!-- example remove core isolation a.k.a. Hypervisor Enforced Code Integrity (HVCI) options, consider enabling if your system is supported-->
<HvciOptions>0</HvciOptions>
<Settings>
<Setting Provider="PolicyInfo" Key="Information" ValueName="Name">
<Value>
<String>Example Policy Name - Empty</String>
</Value>
</Setting>
<Setting Provider="PolicyInfo" Key="Information" ValueName="Id">
<Value>
<String>Example-Policy-Empty-10.0.0.1</String>
</Value>
</Setting>
</Settings>
</SiPolicy>
Errata
Si un Windows 10 dans un appareil en mode S avec un jeton d’autorisation de stratégie et une stratégie supplémentaire est restauré à partir de la mise à jour 1909 vers la build 1903, il ne revient pas au mode S verrouillé avant la prochaine actualisation de la stratégie. Pour obtenir une modification immédiate de l’état du mode S verrouillé, les professionnels de l’informatique doivent supprimer tous les jetons dans %SystemRoot%\System32\CI\Tokens\Active.
Commentaires
Bientôt disponible : Tout au long de 2024, nous allons supprimer progressivement GitHub Issues comme mécanisme de commentaires pour le contenu et le remplacer par un nouveau système de commentaires. Pour plus d’informations, consultez https://aka.ms/ContentUserFeedback.
Envoyer et afficher des commentaires pour