Configuration des listes de contrôle d’accès SBC : concevoir des listes d’autorisation IP fiables en production

Tout Session Border Controller exposé à Internet reçoit du trafic SIP indésirable dans les minutes qui suivent sa mise en service. Une partie provient de balayages opportunistes, une autre de tentatives de force brute sur les enregistrements, et une autre encore du bruit de fond continu de paquets malformés émis par des hôtes compromis à la recherche d’un chemin vers un PBX. Une liste de contrôle d’accès est le premier instrument que le SBC utilise pour décider lesquels de ces paquets méritent un examen approfondi et lesquels sont rejetés avant de consommer des ressources CPU.

Ce guide porte sur la manière de configurer ces listes plutôt que sur ce contre quoi elles protègent. Il couvre la position réelle de l’évaluation ACL dans le SBC, les deux philosophies de conception qui gouvernent chaque règle que vous écrivez, la façon dont les portées interagissent aux niveaux global, interface et par trunk, les schémas de configuration pour les déploiements les plus fréquents chez TelcoBridges, et les pièges opérationnels qui interrompent silencieusement les appels des semaines après une installation propre.

Pourquoi le contrôle d’accès par IP est le socle, pas le plafond

Une ACL est la décision la moins coûteuse qu’un SBC puisse prendre. Le paquet n’a pas été analysé, la transaction SIP n’a pas été ouverte et aucun état de couche applicative n’a été alloué. Un rejet à cette couche ne coûte presque rien au SBC en CPU ou en mémoire, et c’est précisément pour cette raison qu’il doit être la première décision de la chaîne. Si un attaquant parvient à faire atteindre l’analyseur SIP au SBC avant d’être filtré, chaque paquet malformé devient une transaction qui entre en concurrence avec les appels légitimes pour les ressources.

Cet argument économique est aussi la raison pour laquelle les ACL ne peuvent pas être la seule défense. Le filtrage par IP ne sait rien de l’identité revendiquée par l’expéditeur, de la méthode qu’il invoque ou de la validité de ses identifiants. Une IP d’opérateur autorisée peut toujours émettre des messages malformés, des floods REGISTER ou des appels frauduleux si elle est elle-même compromise. Les ACL réduisent la surface d’attaque ; la pile de sécurité complète du SBC traite les menaces qui arrivent de l’intérieur du périmètre autorisé.

L’implication pratique est qu’une bonne configuration ACL n’est pas un exercice de durcissement ponctuel. C’est une discipline continue consistant à maintenir la liste d’autorisation suffisamment restreinte pour que le limiteur de débit, le validateur de protocole et le moteur de routage ne voient jamais que du trafic méritant d’être traité.

Où se situent les ACL dans le pipeline de traitement du SBC

Bien configurer une ACL exige de comprendre exactement quand elle est consultée. Un SBC traite chaque paquet entrant à travers une chaîne ordonnée de vérifications, et la position de l’ACL dans cette chaîne détermine ce qu’elle peut et ne peut pas protéger.

L’ordre des opérations

Le pipeline commence à l’interface réseau où un paquet UDP, TCP ou TLS arrive. Le noyau transmet le paquet au processus SBC, qui applique d’abord l’ACL globale. Les paquets correspondant à une règle d’autorisation avancent vers l’ACL spécifique à l’interface. Les paquets qui passent la vérification d’interface sont ensuite évalués par rapport à l’allow-list par NAP, qui est la portée la plus granulaire appliquée par le SBC. Dans le modèle de traitement de ProSBC, ce n’est qu’après que les trois couches ACL ont autorisé le paquet que le trafic avance vers le limiteur de débit, l’analyseur SIP et enfin le moteur de routage.

Chaque couche rejette les paquets à moindre coût. La vérification globale consomme le moins de cycles, puisqu’elle fait correspondre un petit ensemble de règles universelles. La vérification par NAP est la plus coûteuse des trois, mais elle s’exécute sur un ensemble de candidats déjà réduit, de sorte que le coût absolu reste faible. La logique économique est la même à chaque étape : les rejets peu coûteux d’abord, le traitement onéreux uniquement pour le trafic ayant franchi chaque porte moins coûteuse.

Pourquoi l’ordre compte pour la configuration

L’ordre compte parce que chaque couche ne peut appliquer que ce qu’elle voit. Une ACL globale qui bloque un /24 malveillant protège automatiquement chaque NAP. Une allow-list par NAP qui nomme une IP d’opérateur spécifique protège ce groupe de trunks indépendamment de ce qui se passe sur l’ACL globale. Mettre trop de règles dans la couche globale rend la maintenance pénible, car chaque modification impose une révision de tous les trunks. Mettre trop peu dans la couche globale signifie que chaque NAP doit réimplémenter des défenses qui auraient dû être universelles.

Les schémas de configuration présentés plus loin dans ce guide suivent une règle empirique cohérente : les règles universelles vivent dans la portée globale, les règles spécifiques aux pairs vivent dans la portée NAP, et la portée interface gère les cas intermédiaires (comme la séparation des interfaces de signalisation de celles de gestion).

Les deux philosophies de conception : Default Deny vs. Default Allow

Chaque ACL est gouvernée par l’une de deux positions de départ. Le choix entre les deux est la décision la plus lourde de conséquences dans la posture de sécurité d’un SBC, et il doit être fait délibérément pour chaque interface, sans présupposé.

Default Deny : la posture Allow-List

Default deny signifie que l’ACL rejette tout paquet ne correspondant pas à une règle d’autorisation explicite. L’opérateur énumère chaque source autorisée à envoyer du SIP à l’interface, et tout le reste est rejeté à la couche la plus précoce possible. C’est la posture appropriée pour toute interface de signalisation où l’ensemble des pairs légitimes est petit et connu : un trunk SIP face à un ou deux opérateurs, une interface Teams où les plages IP publiées par Microsoft sont la seule source légitime, ou un lien de peering entre deux fournisseurs de services.

Le bénéfice opérationnel est considérable. Le SBC reçoit du trafic de balayage en arrière-plan provenant d’hôtes compromis chaque minute de chaque jour, et une posture default-deny rejette tout cela sans jamais ouvrir de transaction. Le coût est la charge de maintenance liée au maintien de la liste d’autorisation synchronisée avec les IP sources réelles de l’opérateur ou du partenaire, qui changent occasionnellement et sans préavis.

Default Allow : la posture Deny-List

Default allow signifie que l’ACL accepte tout paquet ne correspondant pas à une règle de refus explicite. L’opérateur liste les sources malveillantes connues et fait confiance à tout le reste par défaut. Cette posture n’est appropriée que lorsque la population source légitime est trop vaste pour être énumérée, comme un déploiement de softphones résidentiels desservant des milliers de télétravailleurs dont les IP domestiques changent quotidiennement.

Même dans ces cas, le default allow sur l’ACL est associé à une authentification forte au niveau SIP, puisque le filtre IP ne peut pas réduire significativement la surface d’attaque. La deny-list est réservée au blocage d’acteurs malveillants spécifiques et identifiés, et le SBC s’appuie sur l’authentification des enregistrements, la limitation de débit et la liste noire dynamique pour gérer la longue traîne des abus opportunistes.

Choisir la bonne posture par interface

La plupart des SBC en production utilisent un mélange des deux. Les interfaces côté trunk utilisent presque toujours le default deny parce que les IP des opérateurs sont connues. Les interfaces côté utilisateur penchent vers le default allow parce que la population source est dynamique. Le point crucial est que la posture est choisie par interface plutôt que par SBC, et le choix doit être documenté aux côtés de la configuration afin que la justification survive au roulement des opérateurs.

Portées ACL : globale, par interface et par NAP

ProSBC applique la politique ACL à trois portées distinctes. Comprendre ce qui appartient à chacune fait la différence entre une ACL qui passe à l’échelle et une qui devient un enchevêtrement impossible à maintenir.

Portée globale

L’ACL globale s’applique à chaque paquet qui atteint le SBC, quelle que soit l’interface ou le trunk. C’est l’endroit approprié pour les règles qui doivent s’appliquer partout : bloquer les plages malveillantes connues provenant de flux de renseignement sur les menaces, rejeter les préfixes bogon et réservés, et autoriser le trafic de gestion depuis les sous-réseaux internes. Les règles globales sont évaluées en premier, de sorte qu’un rejet global économise du travail à chaque couche en aval.

La discipline au niveau global est la retenue. Tout ce qui s’applique à un trunk et pas à un autre appartient plus bas. Une ACL globale contenant des centaines d’entrées spécifiques à des opérateurs devient rapidement un fardeau de maintenance, car chaque modification nécessite de vérifier si la règle entre en conflit avec les besoins d’un autre trunk.

Portée interface

L’ACL d’interface s’applique aux paquets arrivant sur une interface réseau physique ou virtuelle spécifique. La plupart des déploiements utilisent cette portée pour séparer les plans de signalisation, de média et de gestion, de sorte qu’un paquet arrivant sur l’interface de gestion ne puisse pas atteindre la pile de signalisation et vice versa. Les règles d’interface sont également utiles pour répartir les trunks sur plusieurs chemins réseau dans les déploiements où les opérateurs se connectent via différents fournisseurs en amont.

Les règles d’interface se situent entre les règles globales et par NAP en termes de coût de maintenance. Elles sont modifiées moins souvent que les règles par NAP mais plus souvent que les globales, ce qui en fait un bon emplacement pour la politique de séparation des plans, stable mais non universelle.

Portée par NAP

L’ACL par NAP est l’endroit où réside la majeure partie de la politique spécifique aux pairs. Chaque NAP représente un groupe de trunks, une connexion opérateur ou un locataire client, et son ACL définit exactement quelles IP sources sont autorisées à envoyer des messages SIP via ce trunk. Le module BlackWhiteListing de ProSBC prend en charge la portée par NAP avec correspondance par préfixe le plus long, de sorte qu’un opérateur peut autoriser le /24 d’un opérateur de manière générale tout en bloquant un /32 spécifique dans cette plage si un seul hôte du réseau de l’opérateur a été compromis.

La portée par NAP est aussi l’endroit où la liste noire dynamique s’attache. Lorsque le SBC détecte un comportement anormal d’une source contre un NAP spécifique (enregistrements échoués depuis une IP spécifique, INVITE malformés à un débit élevé), il peut ajouter automatiquement une règle de refus à l’ACL de ce NAP. La configuration statique définit l’état stable ; les ajouts dynamiques gèrent la réponse en direct. Le même principe s’applique en sens inverse pour la liste grise, où ProSBC limitera un pourcentage configurable du trafic d’une source suspecte tout en laissant le reste du trunk intact.

Comment les trois portées se combinent

La façon la plus simple de concevoir les trois portées est comme des cercles concentriques. La portée globale est la plus externe. Un paquet qui échoue à la vérification globale n’atteint jamais la couche interface ou NAP. L’interface est l’anneau intermédiaire, limitant les règles au port physique ou virtuel. Le NAP est le plus interne, limitant les règles à un groupe de trunks spécifique. Un paquet doit passer les trois pour atteindre l’analyseur SIP, et chaque couche peut le rejeter indépendamment.

Schémas courants de configuration ACL

La plupart des déploiements SBC correspondent à l’un de quelques schémas récurrents. Chacun nécessite un mélange spécifique de portées et de postures, et les différences comptent à grande échelle.

Trunk SIP unique vers un seul opérateur

Le cas le plus simple. L’opérateur publie un petit ensemble d’IP sources qui envoient du SIP au SBC, et le rôle du SBC est de s’assurer que rien d’autre n’atteigne le trunk. Configurez le NAP côté opérateur avec une posture default-deny et autorisez uniquement les entrées /32 publiées par l’opérateur (ou un /29 ou /30 serré si l’opérateur utilise une petite plage contiguë). Ajoutez également le sous-réseau média de l’opérateur à l’ACL par NAP, puisque le RTP et le SIP proviennent souvent d’adresses différentes au sein du réseau de l’opérateur.

L’ACL globale ne devrait contenir que les règles de blocage de bogons et les sous-réseaux de gestion. Dans la plupart des déploiements, il y a peu de raisons pour que l’ACL globale contienne une politique spécifique à un opérateur ; cette politique appartient à la portée du NAP qui l’utilise.

Déploiement multi-opérateur

Un fournisseur de services avec deux ou trois opérateurs en amont et des dizaines de clients en aval a besoin de discipline de portée avant tout. Chaque opérateur obtient son propre NAP avec sa propre allow-list, limitée aux IP de cet opérateur uniquement. Chaque client obtient son propre NAP avec sa propre allow-list, limitée à l’IP de la passerelle du client. L’ACL globale ne gère que les règles universelles : blocage de bogons, refus de flux de menaces et autorisations de gestion.

Le bénéfice de cette discipline apparaît la première fois qu’un opérateur fait tourner ses IP sources. Le changement est local à un seul NAP, ne nécessite qu’une seule ligne de configuration et ne peut pas accidentellement affecter les autres opérateurs ou les trunks clients. Une ACL globale plate avec toutes les règles opérateur au même endroit nécessiterait un diff minutieux et risquerait des modifications involontaires sur des trunks non concernés.

Microsoft Teams Direct Routing

Les interfaces côté Teams présentent un problème d’allow-list spécifique parce que Microsoft publie les plages IP que Teams utilise pour la signalisation et le média, et ces plages s’étendent occasionnellement. Configurez le NAP côté Teams avec une posture default-deny et autorisez les plages IP Direct Routing publiées par Microsoft sous forme de blocs CIDR plutôt que d’entrées /32 individuelles, de sorte que des changements mineurs au sein d’une plage publiée ne nécessitent pas de mise à jour de la configuration.

Associez l’ACL au TLS mutuel afin qu’un attaquant qui parvient à émettre depuis une plage autorisée ne puisse pas compléter une poignée de main TLS sans un certificat de confiance. La combinaison d’une allow-list IP et d’une configuration correcte de TLS et SRTP est ce que Microsoft attend d’un déploiement Direct Routing en production.

Déploiement multi-locataire pour MSP

Un fournisseur de services gérés exploitant plusieurs locataires Teams ou PBX hébergés sur une seule instance SBC a besoin d’une isolation ACL entre les locataires. Chaque locataire obtient son propre NAP, et l’ACL de chaque NAP n’autorise que les points d’accès autorisés du locataire (qu’il s’agisse d’une frontière de locataire Teams, de l’IP du routeur de bureau d’un client ou des plages sources d’une plateforme CPaaS). Les ACL de locataires ne partagent pas de règles, de sorte qu’une mauvaise configuration chez le locataire A ne peut pas assouplir le périmètre du locataire B.

C’est aussi là que la portée par NAP prouve sa valeur opérationnelle. ProSBC prend en charge jusqu’à 1 024 NAP par instance, ce qui signifie que même un fournisseur de services avec des centaines de clients peut maintenir une politique ACL strictement limitée par locataire sans atteindre les limites de la plateforme.

Utilisateurs distants et en télétravail

Le schéma le plus difficile. Les utilisateurs de softphones distants utilisent des FAI résidentiels avec des adresses dynamiques, et énumérer leurs IP sources est impossible. L’ACL sur un NAP côté utilisateur fonctionne en default-allow avec une deny-list restrictive, et la charge de sécurité se déplace vers l’authentification SIP des enregistrements, la limitation de débit et la liste noire dynamique.

L’ACL statique fait toujours son travail. Bloquez les plages d’anonymiseurs connues, bloquez les plages de fournisseurs d’hébergement cloud d’où aucun utilisateur légitime ne devrait jamais émettre du SIP, et bloquez toute zone géographique que le déploiement ne dessert pas. La liste noire dynamique attrape le résidu : toute source qui échoue répétitivement à l’enregistrement, envoie des messages malformés ou recherche des utilisateurs valides est ajoutée automatiquement. La protection contre le balayage d’enregistrement SIP de ProSBC alimente cette deny-list dynamique, de sorte qu’un flood d’enregistrements est identifié et bloqué avant d’épuiser le registrar.

ACL statiques et listes noires dynamiques : un partenariat opérationnel

L’ACL statique exprime la politique, et la liste noire dynamique exprime la réponse en direct. Configurer l’une sans l’autre laisse le SBC soit trop rigide, soit trop réactif.

Ce que chacune fait le mieux

Les règles statiques encodent ce que vous savez à l’avance. Les IP d’opérateurs, les plages Teams de Microsoft, les adresses de passerelles clients, les blocages de bogons et les refus de flux de menaces appartiennent tous à la configuration statique. Ils changent lentement, le changement est délibéré, et ils forment la structure durable de la politique du SBC.

Les règles dynamiques encodent ce que le SBC découvre sur son environnement en temps réel. Une source qui envoie 50 enregistrements échoués en 10 secondes est presque certainement hostile, mais aucun opérateur ne peut inscrire cette source dans une ACL statique à l’avance parce que l’IP source était inconnue jusqu’au début de l’attaque. ProSBC surveille en continu le comportement des IP sources et ajoute une entrée de refus dynamique dès qu’un seuil configuré est franchi.

La liste grise entre autorisation et refus

L’autorisation ou le refus pur est parfois trop binaire. La liste grise basée sur un pourcentage de ProSBC se situe entre les deux : lorsqu’une source franchit un seuil souple, le SBC accepte une fraction configurable de son trafic et rejette le reste. Ce comportement est utile dans deux scénarios. Le premier est un opérateur avec un pic légitime mais inattendu, où un blocage total provoquerait une panne pour les appelants réels. Le second est un attaquant suspecté dont l’opérateur souhaite continuer à observer le trafic pour confirmer le verdict avant d’appliquer un blocage complet.

La liste grise est aussi l’outil approprié lorsque le blocage par IP source amplifierait l’impact de l’usurpation d’IP source. Rejeter 90 % du trafic d’une source suspecte oblige l’attaquant à dépenser plus de ressources pour maintenir le volume d’attaque tout en préservant suffisamment d’échantillons pour que l’analytique du SBC confirme la signature de l’attaque.

La question de l’horizon temporel

Les entrées dynamiques ne devraient pas être permanentes. Une IP qui était hostile mardi dernier peut appartenir à un hôte différent aujourd’hui, et un blocage perpétuel sur une IP résidentielle recyclée finit par refuser le service à un utilisateur légitime. Configurez les entrées de liste noire dynamique avec un intervalle d’expiration (généralement 24 heures, parfois plus pour les acteurs malveillants confirmés), et laissez le moteur dynamique réappliquer le blocage si le comportement se répète. Les blocages statiques d’infrastructure confirmée malveillante peuvent rester permanents ; les blocages dynamiques doivent expirer.

Pièges opérationnels qui interrompent silencieusement les appels

Les schémas ci-dessus décrivent comment les ACL devraient fonctionner. La liste ci-dessous couvre les modes de défaillance récurrents en production, généralement des semaines après un déploiement ayant réussi tous les tests initiaux.

Autorisations CIDR trop larges

L’erreur de configuration la plus courante est d’autoriser un bloc CIDR plus large que l’empreinte réelle de l’opérateur. Un opérateur publie des IP de signalisation dans 198.51.100.16/28, l’opérateur tape 198.51.100.0/24, et le SBC accepte désormais du SIP provenant de 240 adresses que l’opérateur ne contrôle pas. Un hôte compromis dans cette plage peut envoyer du SIP au SBC et l’ACL ne l’arrêtera pas. Autorisez toujours le préfixe le plus étroit spécifié par l’opérateur, même si cela implique d’écrire quelques lignes supplémentaires.

Oublier le plan média

La signalisation SIP et le média RTP proviennent souvent de plages IP différentes au sein du même réseau opérateur. Une ACL qui n’autorise que les adresses de signalisation acceptera les INVITE mais rejettera le RTP entrant, produisant un audio unidirectionnel incorrectement diagnostiqué comme un problème de codec ou de NAT. Lors de la configuration d’un NAP côté opérateur, demandez à l’opérateur les plages sources de signalisation et de média et ajoutez les deux à l’allow-list.

IPv6 manquant

De nombreux opérateurs, fournisseurs cloud et plages Microsoft Teams utilisent désormais des adresses IPv6. Un SBC avec une ACL IPv4 complète et une ACL IPv6 vide fonctionne effectivement en default-allow sur le plan IPv6, ce qui signifie qu’un attaquant atteignant le SBC via IPv6 passe outre chaque vérification prévue pour le périmètre IPv4. Reproduisez chaque règle IPv4 en IPv6 partout où la plage correspondante existe.

IP sources NATées depuis les réseaux clients

Lorsqu’un client se trouve derrière un NAT, chaque point d’accès au sein du réseau client présente la même IP publique source au SBC. Autoriser l’IP NAT fonctionne pour le trafic légitime mais ne permet pas de distinguer les points d’accès individuels, de sorte que toute compromission au sein du réseau client semble provenir d’une source autorisée. C’est une limitation à anticiper plutôt qu’un bug à corriger ; l’ACL doit être associée à une authentification SIP forte pour les clients derrière un NAT, et les limites de débit par IP source doivent être définies en sachant qu’une seule IP peut représenter de nombreux utilisateurs.

Mauvais ordonnancement des règles dans les moteurs top-down

Le module BlackWhiteListing de ProSBC utilise la correspondance par préfixe le plus long, de sorte que l’ordre des règles est indépendant de la priorité des règles. De nombreux autres SBC évaluent les règles ACL de haut en bas, où la première règle correspondante l’emporte. Sur ces plateformes, une autorisation large en haut de la liste annule silencieusement un refus étroit plus bas. Si vous migrez d’un moteur ACL top-down vers un moteur à préfixe le plus long, ou vice versa, auditez chaque règle pour les hypothèses d’ordonnancement avant de promouvoir la configuration en production.

Entrées dynamiques obsolètes

Les entrées de liste noire dynamique ajoutées il y a six mois pour des IP qui ont depuis changé de propriétaire sont une source de faux positifs à croissance lente. Le CDR du SBC ne montre rien d’anormal ; le client se plaint simplement que les appels d’un partenaire échouent. La revue périodique de la deny-list dynamique, avec attention aux entrées plus anciennes que l’expiration configurée, prévient cette catégorie d’incidents. La même dérive affecte les règles d’autorisation en sens inverse, et la combinaison de la revue des compteurs de hits ACL avec une supervision VoIP de routine détecte les deux formes de dégradation avant qu’elles ne se manifestent en plaintes clients.

Modifications ACL sans vérification des compteurs de hits

Ajouter une règle d’autorisation et supposer qu’elle fonctionne n’est pas la même chose que confirmer qu’elle fonctionne. Après toute modification ACL, surveillez le compteur de hits de la règle pour vérifier que le trafic légitime correspond effectivement à la nouvelle règle plutôt que d’être silencieusement rejeté par quelque chose de plus tôt dans la chaîne. Une modification qui semble correcte sur le papier mais n’enregistre jamais de hit est presque certainement masquée par une règle globale ou une règle au niveau de l’interface que l’opérateur a oubliée.

Maintenir les ACL en production

La configuration ACL d’un SBC dérive. Les opérateurs font tourner les IP, les clients déménagent, les partenaires sont acquis et les entrées de flux de menaces expirent. Traiter la maintenance ACL comme une activité opérationnelle périodique (plutôt que quelque chose qui ne se produit que lorsque les appels échouent) est ce qui distingue un SBC en production stable d’un autre qui avance d’incident en incident.

Cadence d’audit

Un audit trimestriel est suffisant pour la plupart des déploiements. La revue couvre chaque règle d’autorisation (la source existe-t-elle encore, le préfixe est-il encore correct, la règle est-elle encore nécessaire), chaque règle de refus (la source est-elle encore hostile, l’entrée du flux de menaces a-t-elle expiré) et chaque entrée dynamique qui a persisté plus longtemps que prévu. Le résultat est un petit ensemble de modifications qui est révisé et appliqué lors de la prochaine fenêtre de maintenance.

Les SBC à fort trafic bénéficient d’audits mensuels. Les déploiements plus petits desservant des ensembles de pairs stables peuvent s’étendre à un rythme semestriel. La bonne fréquence est déterminée par la fréquence réelle de changement de l’ensemble des pairs, pas par la fréquence à laquelle le calendrier rappelle à l’opérateur.

Fenêtres de changement et retour arrière

Les modifications ACL sont le type de changement qui devrait toujours avoir un retour arrière documenté. Une règle d’autorisation qui aurait dû laisser passer le trafic mais ne l’a pas fait est inoffensive une fois annulée ; une règle de refus qui coupe accidentellement un opérateur est une panne qui coûte des minutes par appel. Appliquez les modifications pendant une fenêtre de maintenance, surveillez les compteurs de hits en temps réel et revenez immédiatement en arrière si les schémas de trafic ne correspondent pas aux attentes.

Journalisation des événements sans correspondance

Un journal sans correspondance capture chaque paquet qui a été rejeté parce qu’aucune règle ne l’autorisait. Sur un SBC chargé, ce journal est volumineux et bruité, mais c’est le signal principal pour deux choses : un attaquant qui sonde le périmètre, et un pair légitime dont l’IP source a changé sans notification. L’échantillonnage périodique du journal sans correspondance (ou l’alerte lorsque le volume sans correspondance d’une source unique franchit un seuil) détecte les deux cas avant qu’ils ne deviennent des tickets.

Les compteurs de hits comme signal de santé

Une règle d’autorisation qui n’a pas enregistré de hit en 30 jours est soit obsolète, soit masquée. Dans les deux cas, la règle devrait être signalée pour révision. La plupart des SBC en production permettent de trier les règles par horodatage du dernier hit ; exécuter ce rapport mensuellement est un moyen peu coûteux d’empêcher l’ACL d’accumuler des règles mortes. Les règles obsolètes ne sont pas que de l’encombrement, elles sont de la surface d’attaque ; chaque règle existante est une exception potentielle qu’un attaquant pourrait exploiter.

Documentation aux côtés de la configuration

L’ACL sur un SBC en production est lue par le prochain opérateur longtemps après que l’auteur original est passé à autre chose. Chaque règle non évidente nécessite un commentaire qui enregistre pourquoi elle existe, qui l’a autorisée et quand elle devrait être révisée. L’interface web de ProSBC prend en charge les commentaires sur la plupart des types de règles ; le champ commentaire est l’une des fonctionnalités les plus sous-utilisées dans les opérations d’infrastructure vocale.

Questions fréquemment posées