Constructeur de liste d’autorisation

Le Constructeur d'allowlist convertit une liste d'adresses IP individuelles en l'ensemble minimal de blocs CIDR couvrant exactement ces adresses. Saisissez des adresses comme 192.168.1.0, 192.168.1.1, 192.168.1.2, 192.168.1.3 et obtenez un seul 192.168.1.0/30 -- moins de règles de firewall, un traitement plus rapide et des configurations plus faciles à maintenir.

Comprendre les allowlists IP et l'agrégation CIDR

Si vous administrez des firewalls, des security groups ou des contrôles d'accès de serveurs web, vous avez presque certainement maintenu une allowlist à un moment donné. Une allowlist est un ensemble d'adresses IP explicitement autorisées à accéder à une ressource -- tout le reste est refusé. La difficulté survient lorsque cette liste passe d'une poignée d'adresses à des centaines ou des milliers. Chaque adresse IP individuelle constitue une règle distincte dans votre firewall, et chaque règle coûte du temps de traitement sur chaque paquet qui la traverse.

L'agrégation CIDR résout ce problème en combinant les adresses adjacentes en blocs compacts. Au lieu de lister 256 adresses individuelles de 172.16.0.0 à 172.16.0.255, vous écrivez un seul 172.16.0.0/24. Le firewall évalue une règle au lieu de 256, ce qui compte lorsque vous traitez des millions de paquets par seconde sur un équipement de bordure chargé. Les plateformes cloud imposent des limites strictes sur le nombre de règles -- les security groups AWS autorisent 60 règles par groupe par défaut, et les NSG Azure plafonnent à 1000 -- l'utilisation efficace de la notation CIDR n'est donc pas seulement une optimisation de performance, c'est souvent une nécessité.

La distinction essentielle entre l'agrégation CIDR générique et la construction d'allowlist réside dans la précision. Un outil d'agrégation classique pourrait combiner 192.168.1.0 et 192.168.1.3 en 192.168.1.0/30, mais ce bloc inclut aussi .1 et .2, qui ne sont peut-être pas autorisées. Pour une allowlist, inclure des adresses non autorisées constitue une faille de sécurité. Ce constructeur garantit que la sortie ne couvre jamais une adresse absente de l'entrée originale -- il privilégie toujours la précision par rapport à la compression.

Comment construire une allowlist CIDR minimale

1. Saisissez votre liste d'adresses IP -- une par ligne, séparées par des virgules ou mélangées avec de la notation CIDR existante.
2. Le constructeur analyse les possibilités d'adjacence et de regroupement sur l'ensemble des adresses.
3. Les adresses adjacentes sont agrégées en blocs CIDR uniquement lorsque cela n'inclut aucune IP non autorisée.
4. Consultez la sortie montrant chaque bloc CIDR et le nombre d'adresses originales qu'il couvre.
5. Copiez l'allowlist optimisée pour l'utiliser dans votre configuration de firewall, security group ou ACL.

Exemples d'agrégation d'allowlist

Taux de compression

Une liste de 256 adresses consécutives commençant à une limite /24 se compresse en un seul bloc CIDR -- une réduction de 256:1. Les listes réelles atteignent typiquement une compression de 5:1 à 20:1 selon le degré de regroupement des adresses.

Quand utiliser le constructeur d'allowlist

• Limites de règles de firewall -- les security groups cloud (AWS limite à 60 règles par SG, Azure limite à 1000 par NSG) nécessitent des allowlists compactes pour rester dans les quotas.
• Consolidation de logs d'accès -- convertir des semaines d'adresses IP autorisées issues des logs d'accès en une allowlist maintenable.
• Planification de migration -- combiner les allowlists de plusieurs firewalls legacy en un ensemble unique optimisé.
• Optimisation des performances -- moins de règles CIDR signifie un filtrage de paquets plus rapide sur les firewalls à haut débit.
• Configuration de passerelle API -- les services comme Cloudflare ou AWS API Gateway bénéficient de listes CIDR minimales pour le contrôle d'accès par IP.

Fonctionnement de l'agrégation CIDR pour les allowlists

L'agrégation CIDR combine les adresses IP en blocs en identifiant les préfixes réseau partagés en représentation binaire. Deux adresses ne peuvent être fusionnées en un bloc plus grand que lorsque :

1. Elles sont numériquement adjacentes -- 10.0.0.4 et 10.0.0.5 sont adjacentes ; 10.0.0.4 et 10.0.0.6 ne le sont pas.
2. Elles sont alignées sur une limite en puissance de deux -- 10.0.0.0/31 est valide (couvre .0 et .1), mais on ne peut pas commencer un /31 à une adresse impaire.
3. Il n'y a pas de trous -- si 10.0.0.1 est absent d'une liste contenant 10.0.0.0 et 10.0.0.2, ils ne peuvent pas être combinés en /30 car cela inclurait l'adresse non autorisée .1.

Agrégation sure vs non sure

Sure :     192.168.1.0 + 192.168.1.1 → 192.168.1.0/31
           (les deux adresses sont dans la liste d'entrée)

Non sure : 192.168.1.0 + 192.168.1.3 → 192.168.1.0/30
           (inclurait .1 et .2, qui NE SONT PAS dans la liste)

Le constructeur d'allowlist privilégie toujours la précision par rapport à la compression -- il ne produira jamais un bloc CIDR incluant des adresses IP absentes de votre liste originale.

L'algorithme d'agrégation

Le constructeur fonctionne de bas en haut. Il commence par convertir chaque adresse en entrée en un /32 (hôte unique). Il tente ensuite d'associer les entrées /32 adjacentes en blocs /31, les blocs /31 adjacents en blocs /30, et ainsi de suite. A chaque étape, il vérifie si le bloc résultant inclurait une adresse absente de l'entrée originale. Si c'est le cas, la fusion est ignorée et les blocs plus petits sont conservés. Cette approche gloutonne garantit le nombre minimal de blocs CIDR tout en ne couvrant jamais d'adresses en trop.

Entrée : 10.0.0.0, 10.0.0.1, 10.0.0.2, 10.0.0.3, 10.0.0.4

Etape 1 : 10.0.0.0/32, 10.0.0.1/32, 10.0.0.2/32, 10.0.0.3/32, 10.0.0.4/32
Etape 2 : 10.0.0.0/31, 10.0.0.2/31, 10.0.0.4/32
Etape 3 : 10.0.0.0/30, 10.0.0.4/32  (fusion .0/.1 et .2/.3 en /30)
Etape 4 : Impossible de fusionner /30 + /32 (il faudrait 10.0.0.5-7 pour compléter un /29)

Résultat : 10.0.0.0/30, 10.0.0.4/32  (2 entrées au lieu de 5)

Conseils pratiques pour la construction d'allowlists

La principale source de problèmes avec les allowlists IP est la présence d'entrées obsolètes. Les adresses sont ajoutées lorsqu'un nouveau partenaire ou bureau est mis en service, mais personne ne les retire lorsque la relation partenaire prend fin ou que le bureau change de plage IP. Avec le temps, l'allowlist devient un ensemble tentaculaire auquel personne ne fait confiance et que personne ne veut toucher. Prenez l'habitude d'associer une date d'expiration ou un numéro de ticket à chaque entrée, et révisez la liste trimestriellement. Si vous ne pouvez pas identifier pourquoi une adresse y figure, elle ne devrait probablement pas y être.

Lorsque vous construisez des allowlists à partir de logs d'accès, faites attention à la fenêtre temporelle utilisée. Une seule journée de logs risque de manquer des adresses légitimes qui ne se connectent que de façon hebdomadaire (systèmes de monitoring, tâches batch, générateurs de rapports mensuels). Extraites au moins 30 jours de logs pour capturer le trafic légitime mais peu fréquent. En revanche, n'ajoutez pas aveuglément toutes les adresses qui se sont connectées -- vérifiez que le trafic était effectivement autorisé, et pas simplement réussi. Un attaquant qui s'est introduit une fois ne devrait pas être ajouté de façon permanente à l'allowlist.

Si vous atteignez les limites de nombre de règles sur une plateforme cloud, demandez-vous si vous avez vraiment besoin d'une allowlist par IP individuelle ou si un bloc CIDR plus large serait acceptable. Si tous les serveurs d'un partenaire se trouvent dans 203.0.113.0/24, autoriser l'intégralité du /24 est plus simple et plus résistant aux changements d'infrastructure qu'un suivi des IP serveur par serveur. C'est un choix qui dépend du degré de confiance envers le propriétaire du réseau, mais cela réduit considérablement votre nombre de règles.

Questions fréquentes

Quels formats d'entrée le constructeur d'allowlist accepte-t-il ? Le constructeur accepte les adresses IP une par ligne, séparées par des virgules, par des espaces, ou mélangées avec de la notation CIDR existante. Vous pouvez coller directement depuis des tableurs, des fichiers de logs ou des configurations de firewall existantes. Les adresses IPv4 et IPv6 sont prises en charge.

Le constructeur peut-il inclure des IP que je n'ai pas spécifiées ? Non. Le constructeur privilégie la précision par rapport à la compression. Si la fusion de deux adresses en un bloc CIDR incluait ne serait-ce qu'une adresse absente de votre liste originale, il les conserve en entrées /32 (IPv4) ou /128 (IPv6) séparées. Cette garantie est essentielle pour les allowlists de sécurité.

Quelle est la différence avec l'agrégation CIDR classique ? L'agrégation CIDR classique suppose que vous disposez déjà de blocs CIDR et cherche à les fusionner. Le constructeur d'allowlist part d'adresses IP individuelles et trouve la représentation CIDR optimale. Il est spécifiquement conçu pour construire des allowlists de firewall où l'inclusion d'adresses supplémentaires est inacceptable.

Puis-je utiliser la sortie directement dans mon firewall ? La sortie est une liste de blocs CIDR en texte brut. Pour la syntaxe spécifique à votre plateforme, utilisez la sortie avec un générateur de snippets comme le CIDR Allow/Deny Snippet Generator (nginx) ou le Apache Require ip Snippet Generator pour produire une configuration prête au déploiement.

Quel taux de compression puis-je espérer ? Cela dépend entièrement du regroupement de vos adresses. Une liste de 256 adresses consécutives sur une limite /24 se compresse en un seul bloc (256:1). Une liste de 100 adresses dispersées sur différents sous-réseaux ne se compressera peut-être qu'en 80 blocs (1,25:1). En pratique, la plupart des logs d'accès réels produisent des ratios entre 5:1 et 20:1.

Puis-je mélanger des adresses IPv4 et IPv6 dans la même entrée ? Oui. Le constructeur traite les adresses IPv4 et IPv6 séparément et produit des listes de blocs CIDR indépendantes pour chaque famille d'adresses. Cela correspond à la manière dont la plupart des firewalls gèrent les règles en dual-stack.

Outils associés

• Blocklist Builder - Construire une blocklist CIDR minimale à partir d'une liste d'IP
• IP:Port Allowlist Validator - Valider des entrées IP:port en masse avant le déploiement
• CIDR Allow/Deny Snippet Generator (nginx) - Générer des directives allow/deny nginx à partir d'une liste CIDR
• Rule Conflict Finder - Trouver les règles de firewall dupliquées, masquées ou en conflit
• Apache Require ip Snippet Generator - Générer des directives Apache Require ip