Politiques d’accès

Dans Ping64, 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 configurer et vérifier les stratégies d’accès, notamment la source, la destination, le protocole, la direction et l’action. Avant une modification, évaluez les effets des autres stratégies et routes sur l’accès.

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. Dans le contrôle d’accès Zero Trust, ouvrez « Policies ». Si la liste contient des politiques, sélectionnez « Create » ; si elle est vide, sélectionnez « Create Policy ». Saisissez le nom de la politique et la description nécessaire.
2. Choisissez ALL, TCP, UDP ou ICMP, puis « Accept » ou « Drop » selon le besoin. Avant d'utiliser un contrôle de sécurité, vérifiez son contenu, ses objets concernés et les exigences de l'organisation.
3. Dans « Sources », sélectionnez des groupes d'accès ou un nœud précis ; dans « Destinations », sélectionnez des groupes, un nœud ou une ressource réseau. Précisez les objets selon les types choisis et vérifiez la source et la cible.
4. Vérifiez « Direction » : la page propose source vers destination ou bidirectionnel. Si la destination est une ressource réseau, le changement de direction n'est pas disponible. Suivez l'affichage et ne supposez pas que l'accès inverse est accordé.
5. Pour TCP ou UDP, configurez les ports nécessaires. Une sélection vide signifie tous les ports. Saisissez un port, une plage valide ou *, par exemple 443 ou 8000-8080, et validez la saisie selon l'invite. Les valeurs vont de 1 à 65535.
6. Enregistrez et vérifiez dans la liste nom, source, destination, protocole, direction, action et activation. Après réception par les nœuds, testez les objets attendus autorisés et non autorisés, et examinez les autres politiques applicables.

Exemple : ajoutez des nœuds pilotes de développement à leur groupe et préparez la ressource cible. Créez une politique avec ce groupe en source, la ressource en destination, TCP, le port 443 et « Accept ». Après enregistrement et activation, testez depuis un nœud pilote puis depuis un nœud hors de la source prévue. Ce n'est pas une politique par défaut ; autres politiques, routes, service et pare-feu influencent le résultat.

Vérifier après une modification : passer de TCP ou UDP à ALL ou ICMP efface les ports et plages saisis. Revenir à TCP ou UDP ne les restaure pas automatiquement ; un champ vide signifie tous les ports. Changer le type de source ou de destination efface également la sélection du côté concerné. Choisir une ressource réseau comme destination remet le sens de la source vers la destination ; ne supposez pas que l’ancien réglage bidirectionnel sera restauré en revenant à un autre type. Avant d’enregistrer, sélectionnez à nouveau les objets et vérifiez protocole, ports et sens pour éviter une modification ou extension involontaire de l’accès.

Chevauchement de politiques : une même source, cible, protocole et un même port peuvent correspondre à plusieurs politiques d’autorisation ou de refus. Par exemple, si un terminal appartient à la fois à un groupe autorisé et à un groupe restreint, vérifiez les deux appartenances, les directions, les ports et les contrôles de sécurité, puis testez de nouvelles connexions depuis ce terminal. Ne déduisez pas le résultat du seul ordre de la liste ou d’une seule règle ; réduisez si possible les chevauchements contradictoires et vérifiez également les routes et les contrôles côté cible.

Messages d’erreur réseau : certains traitements sur les terminaux peuvent autoriser des messages d’erreur ICMP particuliers, comme une destination inaccessible ou un délai dépassé, même si une politique d’accès pertinente refuse le trafic. Ne considérez pas qu’une politique de refus bloque tous les messages de contrôle réseau, ni qu’une telle réponse prouve l’accessibilité du service métier. Vérifiez séparément les connexions métier et les exigences de contrôle sur les plateformes réelles.

Utilisation avec les routes réseau

La politique contrôle le trafic correspondant et la route fournit le chemin. Pour un accès via un nœud de routage, vérifiez ensemble nœud, périmètre de route, source, destination, protocole et ports de la politique. La distribution d'une route ne remplace pas le test du contrôle d'accès.

Important : si « Policy Target Groups » est vide dans la route, une règle d'autorisation par défaut est générée ; vide ne signifie pas refus par défaut. Pour restreindre l'accès, sélectionnez les groupes cibles dans la route et vérifiez qu'une politique active choisit les mêmes groupes et sources prévues. Terminez les autres réglages de route et testez séparément des terminaux autorisés et non autorisés.

Effective Scope détermine les terminaux recevant la route, mais ne limite pas les sources de cette autorisation par défaut à ces terminaux. La règle par défaut ne restreint pas le trafic transféré correspondant par source, protocole ou port. L’accès réel dépend aussi de la connexion, des autres contrôles et du réseau cible. Ne vous fiez pas au seul périmètre de distribution pour isoler l’accès : choisissez les groupes cibles de politique et testez séparément les autres chemins.

Vérifier les connexions existantes : après durcissement d’une stratégie ou ajout d’une règle de refus, ne supposez pas que toutes les sessions existantes s’interrompent immédiatement, même après réception de la mise à jour par les nœuds. Certaines connexions établies peuvent continuer selon le chemin de connexion ou de routage ; le comportement dépend de la plateforme, de l’état de connexion et des autres contrôles. Évaluez les activités en cours avant la modification, puis testez séparément les sessions existantes et les nouvelles connexions dans un pilote autorisé. Si une interruption immédiate est nécessaire, prenez et vérifiez des mesures supplémentaires selon la procédure de réponse aux incidents, sans vous limiter à l’enregistrement de la stratégie.

Vérifier, modifier et dépanner

1. Vérifiez l'activation, l'existence des sources et destinations, les membres et la connexion et réception de configuration des nœuds. Enregistrement, distribution et application effective sont distincts.
2. Vérifiez protocole, ports et direction ; pour une ressource réseau, vérifiez aussi ressource, nœud de routage, réseau cible, service et retour.
3. Testez séparément sources autorisées et non autorisées. Un accès ou un enregistrement réussi ne démontre pas toute la frontière de sécurité.
4. En cas d'écart, examinez les autres politiques, l'autorisation par défaut de la route, les contrôles de sécurité sélectionnés et le pare-feu cible. Consignez objets, résultats et messages pour examen par un administrateur autorisé.
5. Avant de désactiver ou supprimer une politique ou modifier des membres, vérifiez références et impacts, consignez les réglages et appliquez la procédure de l'organisation. Revérifiez ensuite services et restrictions. Dans la liste, sélectionnez l’action « Edit » de la stratégie pour la modifier et l’enregistrer ; utilisez le commutateur d’état pour la désactiver ou la réactiver ; « Delete » demande une confirmation. Si une action est indisponible, vérifiez les droits et une éventuelle opération en cours. Une stratégie désactivée est exclue des calculs de configuration suivants : désactiver une autorisation ne garantit pas le blocage des autres chemins, et désactiver un refus peut élargir l’accès. Rechargez et vérifiez l’état, puis testez séparément sessions existantes et nouvelles connexions. Si les détails ne se chargent pas, ne considérez pas la stratégie comme vide et ne la supprimez pas sans enquête ; contactez un administrateur.

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