Contrôles de sécurité des politiques d’accès

Les groupes d'accès organisent les nœuds Zero Trust et ressources réseau pour les politiques, routes et autres configurations. Une politique décrit les sources et destinations autorisées ou refusées, ainsi que le protocole, la direction et les ports. Créer un groupe n'accorde pas de droits en soi. Enregistrer une politique ne prouve pas sa réception par tous les nœuds ni l'accessibilité du service cible.

Ce chapitre explique comment créer des contrôles de sécurité et les ajouter à une stratégie d’accès. Résultat du contrôle, correspondance avec la stratégie et accès réel sont des étapes distinctes à vérifier séparément.

Préparation

• Utilisez un compte autorisé à gérer les groupes et politiques Zero Trust. Vérifiez que les nœuds participants sont connectés et que les ressources réseau nécessaires sont prêtes.
• Définissez sources, destinations, protocoles et ports à autoriser ou limiter, ainsi que le besoin d'accès inverse. Privilégiez le périmètre minimal nécessaire et préparez des objets de test autorisés et non autorisés.
• Examinez les politiques, routes et utilisations des groupes existantes. Plusieurs configurations peuvent agir sur un chemin ; une nouvelle politique seule ne prouve pas le résultat final.
• Pour un service interne, vérifiez l'accès et le transfert depuis le nœud de routage, le service cible, le pare-feu et le chemin de retour. Voir Configurer les routes réseau Zero Trust.

Limite de configuration des ports : une règle peut contenir plusieurs ports individuels ou une ou plusieurs plages, mais ne mélangez pas les deux dans la même règle. Par exemple, ne saisissez pas à la fois 443 et 8000-8080 dans une règle : l’enregistrement peut échouer même si l’interface accepte la saisie. Si les deux sont nécessaires, envisagez des stratégies distinctes, vérifiez chaque source, destination, action et contrôle de sécurité, puis testez leur effet combiné en pilote. Ne combinez pas * avec d’autres ports.

Créer une politique d'accès

1. Vérifiez les nœuds sources pilotes inscrits, les nœuds ou ressources réseau cibles, ainsi que les protocoles et ports nécessaires. Contrôlez les droits de gestion et les politiques existantes susceptibles d’influencer l’accès.
2. Créez ou sélectionnez une politique d’accès applicable et définissez la source, la cible, le sens, l’action et les ports selon le besoin. Après un changement de protocole ou de type d’objet, vérifiez à nouveau les choix pour éviter d’étendre involontairement l’accès.
3. Enregistrez, vérifiez que la politique est activée et attendez sa réception par les nœuds concernés. La création de la politique et l’application du contrôle de sécurité sont des étapes distinctes. Consultez Politique d’accès pour les restrictions de ports, les changements d’options et la vérification complète.

Ajouter un contrôle de sécurité à une politique d’accès

Les contrôles ajoutent des conditions pour les terminaux sources. Pour cet exemple de pare-feu, configurez d’abord les terminaux pilotes selon les procédures internes et préparez des sources contrôlées avec pare-feu activé et désactivé. Le contrôle ne configure pas le pare-feu et son nom ne prouve pas un blocage.

1. Avec le droit de gestion des contrôles de sécurité de la gestion des terminaux, ouvrez Security Checks et choisissez Create Security Check si la liste chargée est vide, ou Create Check si des contrôles existent déjà. Choisissez Firewall Enabled, puis parcourez Check type, Check settings et Review. Aucun paramètre supplémentaire n’est requis. Nommez et enregistrez ; si un contrôle identique existe, vérifiez-le et réutilisez-le.
2. Vérifiez nom, type et activation dans la liste. Le terminal doit remonter son état et l’évaluation doit être effectuée ; des données ou résultats valides absents ne signifient pas une réussite.
3. Dans la politique d’accès Zero Trust, configurez source, destination, action, protocole et ports comme ci-dessus, sélectionnez le contrôle activé sous Security Checks et enregistrez. Un contrôle créé mais non ajouté n’est pas une condition de la politique.
4. Après mise à jour des données et de la politique, testez depuis des sources satisfaisant et ne satisfaisant pas la condition. Vérifiez groupe source, autres politiques, routes et pare-feu de destination. Un résultat échoué, inconnu, expiré ou indisponible ne constitue pas une réussite valide pour cette politique, sans garantir le blocage des autres chemins.
5. Avant modification ou désactivation, examinez les références et impacts ; un contrôle référencé ne peut pas être supprimé directement. Étendez le déploiement après vérification et approbation interne.

Limite importante des politiques de refus : un contrôle de sécurité est une condition de correspondance de la source, pas un interrupteur qui refuse en cas d’échec. Ajouté à une politique de refus, il peut empêcher l’application de la règle si la source ne possède pas de réussite valide ; d’autres politiques d’autorisation ou routes peuvent encore influencer l’accès. Ne supposez pas que cette combinaison bloque tout terminal non conforme. Testez séparément réussite, échec et données absentes.

Stratégies bidirectionnelles et contrôles de sécurité : Pour une stratégie bidirectionnelle entre nœuds, les contrôles concernent la source définie dans la stratégie ; ils ne prouvent pas que la destination les a réussis. Si la source réussit mais pas la destination, la règle bidirectionnelle peut néanmoins permettre à la destination d’initier un accès vers la source, selon les autres règles et les conditions réseau. Si les deux côtés doivent satisfaire aux contrôles, envisagez deux stratégies unidirectionnelles avec des contrôles pour chaque source et testez les deux sens avec des résultats réussis, échoués et manquants.

Utiliser les contrôles DLP ou de logiciel requis

Outre le pare-feu, créez les contrôles suivants dans leurs produits respectifs. L’autorisation du produit et le droit de gestion des contrôles sont nécessaires. Chaque contrôle sélectionne un objet ; vérifiez et réutilisez un contrôle du même type déjà associé à cet objet.

1. Prévention des fuites de données : configurez et activez d’abord la politique DLP requise et vérifiez son périmètre pilote. Dans Security Checks du produit, créez Data Loss Prevention Policy Applied, sélectionnez une politique activée et effective, nommez, vérifiez et enregistrez. Le contrôle évalue l’applicabilité de la politique ; il ne prouve pas à lui seul sa réception ni son application effective sur le terminal. Vérifiez le résultat selon le guide de la fonction.
2. Logiciel requis : préparez et activez un objet logiciel identifiant la cible et vérifiez la remontée des actifs des terminaux pilotes. Dans Software > Security Checks, créez Required Software Installed, choisissez l’objet, nommez, vérifiez et enregistrez. Le résultat utilise l’inventaire enregistré et ne prouve ni l’exécution ni la conformité de version. Vérifiez séparément sur le terminal si nécessaire.
3. Dans la politique d’accès Zero Trust, sélectionnez les contrôles activés et disponibles sous Security Checks et enregistrez. Si plusieurs sont sélectionnés, tous doivent avoir un résultat valide de réussite pour satisfaire cette condition. Après mise à jour, testez des sources contrôlées conformes et non conformes et examinez les autres politiques et routes.
4. Ne supposez pas la réussite si une référence est désactivée ou indisponible, ou si un résultat manque ou a expiré. Évaluez les références et impacts avant modification ; un contrôle référencé par une politique ne peut pas être supprimé directement.

• Politiques d’accès