Liste d’autorisation IP : maîtriser les plages CIDR

Une demande d’exception arrive : « Autorisez cette IP pour que l’intégration fonctionne ». Le risque se trouve souvent dans le périmètre ajouté. Une seule adresse devient un bloc CIDR, puis une exception globale qui désactive davantage de contrôles que prévu.

Une liste d’autorisation IP doit décrire qui peut atteindre quel service, à travers quel contrôle et pour quelle durée. Voici comment transformer une demande imprécise en règle vérifiable, avec des tests qui détectent les erreurs de masque et les autorisations trop larges.

Définir exactement ce que l’exception contourne

Avant de choisir le préfixe, identifiez le contrôle concerné. Autoriser une connexion au pare-feu, ignorer une règle WAF et exclure un événement du SIEM sont trois décisions différentes. Une panne sur une route applicative ne justifie pas de supprimer toutes les alertes associées à l’adresse.

Consignez le service destinataire, le protocole, le port et, si le produit le permet, le chemin ou l’opération concernés. Ajoutez le propriétaire de l’intégration et la preuve du besoin : événement bloqué, configuration de sortie ou documentation technique du fournisseur.

Vérifiez aussi que l’IP correspond à la source réellement observée par le contrôle. Derrière un proxy, une adresse issue d’un en-tête non fiable peut faire perdre toute valeur à la liste. L’identité du demandeur et l’origine réseau doivent être contrôlées séparément.

Calculer le périmètre avant de l’accepter

La notation CIDR associe une adresse à une longueur de préfixe. Pour IPv4, un /32 représente une adresse et un /24 en représente 256. La RFC 4632 décrit ce modèle de préfixes et leur agrégation. Un préfixe plus court couvre davantage d’adresses.

Voici un cas fictif utilisant un bloc réservé à la documentation :

Ces plages ne sont pas interchangeables. Demandez ce qui justifie chaque adresse couverte. Une plage annoncée par un fournisseur peut héberger d’autres clients ; son appartenance à la même organisation n’implique pas que tous ses usages doivent accéder à votre service.

Pour IPv6, conservez la même discipline. Un /128 représente une adresse, tandis qu’un préfixe réseau peut couvrir un ensemble considérable. N’appliquez pas intuitivement une taille de masque IPv4 à une adresse IPv6.

Refuser les entrées ambiguës plutôt que les corriger en silence

Utilisez une bibliothèque d’adresses réseau pour valider les entrées et calculer les bornes. Une comparaison textuelle du type « commence par 192.0.2 » ne constitue pas un contrôle CIDR. Elle ne gère correctement ni les masques, ni les formats IPv6.

Le module Python ipaddress fournit des objets d’adresse et de réseau. Avec strict=True, il refuse notamment une définition de réseau dont les bits d’hôte sont encore positionnés. Ce comportement aide à repérer une demande mal formulée avant sa conversion en règle.

from ipaddress import ip_address, ip_network

# Plage fictive, réservée à la documentation.
network = ip_network("192.0.2.64/28", strict=True)
for candidate in ("192.0.2.63", "192.0.2.64", "192.0.2.79", "192.0.2.80"):
    print(candidate, ip_address(candidate) in network)

Le résultat attendu est False, True, True, False. Il vérifie l’appartenance mathématique au bloc, y compris ses bornes. Il ne décrit pas les adresses attribuables à des hôtes dans chaque architecture, ni le comportement exact de votre pare-feu.

Si quelqu’un fournit 192.0.2.70/28, ne remplacez pas discrètement cette entrée par 192.0.2.64/28. Présentez le réseau résultant et faites résoudre l’ambiguïté dans la demande. L’intention pouvait être une seule adresse.

Tester la règle dans le produit qui l’applique

Le calcul local est une première vérification. Testez ensuite la configuration réelle dans un environnement adapté : une source autorisée, une source juste hors plage et un chemin qui ne doit bénéficier d’aucune exception. Vérifiez également l’ordre des règles et l’action effectivement appliquée.

Incluez IPv6 si le service l’accepte. Une politique contrôlant seulement IPv4 peut laisser un chemin différent. Définissez aussi le traitement des adresses IPv4 représentées sous une forme IPv6 lorsque vos composants les produisent ; le parseur et le moteur de règles doivent partager cette convention.

Relevez un identifiant de règle dans les journaux. Un test réussi doit montrer pourquoi la requête a été autorisée. Sinon, une autre règle plus générale peut masquer un défaut de la nouvelle configuration et donner une impression trompeuse de validation.

Conserver les autres contrôles de sécurité

Une origine réseau attendue n’authentifie pas un compte et ne garantit pas le comportement d’une requête. Gardez les clés, signatures, certificats ou contrôles applicatifs prévus pour l’intégration. Limitez l’exception au motif qui bloquait réellement le trafic légitime.

Lorsqu’une adresse autorisée apparaît dans un renseignement de menace, ouvrez une réévaluation. La réputation et le contexte d’une IP de datacenter servent à comprendre l’observation, sans élargir automatiquement le blocage à tous les usages du fournisseur.

À l’inverse, une bonne réputation actuelle ne justifie pas une autorisation permanente. La demande doit reposer sur un besoin d’accès connu. Le score externe est une pièce du dossier, pas le propriétaire de la règle.

Prévoir le retrait dès la création

Ajoutez une date de révision, un responsable et une condition de suppression. Pour un prestataire qui publie des plages variables, définissez qui surveille les changements, comment leur origine est vérifiée et comment les différences sont testées avant application.

Conservez la version précédente pour permettre un retour contrôlé. Lorsqu’une intégration s’arrête, retirez son exception et vérifiez qu’aucun flux attendu n’en dépend encore. Les principes de réévaluation des règles fondées sur des IOC s’appliquent aussi à cette discipline de maintenance.

Le dossier final doit contenir la demande, le réseau exact, les tests aux bornes, les contrôles conservés et le propriétaire. Si une adresse publique mérite un examen complémentaire, consultez son rapport de réputation et datez cette observation. Une autorisation restera ainsi explicable même après un changement d’équipe ou de fournisseur.