Ce qu’une règle d’accès par nom d’hôte peut signifier à chaque couche réseau
Un nom de service peut être appliqué au niveau DNS, du navigateur, du proxy ou du pare-feu. Choisissez la couche qui voit l’identité que vous voulez gouverner.
Trois personnes demandent la même chose avec les mêmes mots : bloquer l’accès à un nom de service. L’une veut dire qu’un navigateur ne doit pas ouvrir le site, une autre qu’un client vocal de bureau ne doit pas atteindre son serveur, et la troisième qu’un groupe de sous-traitants ne doit pas utiliser une application interne particulière. La phrase est identique, et les mécanismes d’application n’ont presque rien en commun.
Choisissez la couche selon l’identifiant qu’elle peut réellement voir, puis selon les clients qu’elle couvre. Partir d’une commande de pare-feu que vous connaissez déjà est la façon dont les règles finissent par ne rien bloquer, ou par bloquer trop.
Un nom n’est pas une identité que chaque couche peut vérifier
Netfilter et les filtres de paquets similaires voient des adresses, des protocoles et des ports. Ils ne voient pas les noms d’hôte, et lorsqu’un paquet les atteint, le nom a déjà été résolu. Une règle écrite contre une adresse est une règle sur cette adresse, quel que soit le nom qu’un utilisateur a saisi pour l’atteindre.
La politique DNS se situe plus tôt dans le chemin et voit la requête, qui est un objet différent de la connexion qui suit. Elle gouverne les réponses qu’un résolveur contrôlé renvoie, pas les connexions déjà ouvertes, ni les clients configurés pour contourner ce résolveur. Une adresse résolue peut aussi changer entre la revue de la politique et la requête suivante, ce qui fait d’une réponse DNS une déclaration d’autorisation non durable.
Les couches supérieures voient plus de contexte et couvrent moins de clients. Cet échange est tout le sujet, et il explique pourquoi aucune ligne du tableau n’est jamais la bonne réponse. Choisissez la ligne qui voit l’identifiant dont votre politique traite réellement. Acceptez ensuite la couverture que cette ligne implique.
Ce que chaque couche peut identifier
Lisez le tableau depuis la colonne du milieu vers l’extérieur : l’identifiant qu’une couche peut voir dicte la politique qu’elle peut appliquer honnêtement.
| Layer | Identifier it sees | What it cannot see |
|---|---|---|
| Packet filter | address, protocol, port | the name, or which other services share that address |
| DNS policy | the queried name and the answer handed back | connections made by clients that ignore the resolver |
| Managed browser | supported URL patterns on managed profiles | non-browser clients, or unmanaged devices |
| CONNECT proxy | host and port for tunnelled requests | the path inside an encrypted request |
Une couche n’appartient à la politique que lorsque l’identifiant qu’elle voit correspond à l’identifiant que vous gouvernez. Le tableau explique aussi pourquoi une règle écrite à une couche se transpose rarement à une autre sans décider de nouveau ce qu’elle protège.
Là où la règle évidente échoue
Une règle d’adresse est exactement juste pour un service doté d’une adresse dédiée que vous contrôlez, et cette propriété devrait être écrite dans la politique. Elle est exactement fausse pour tout ce qui se trouve derrière une adresse partagée de distribution de contenu, où la même règle touche des services sans rapport et où une réponse DNS rafraîchie ne transforme pas la règle en autorisation par nom d’hôte.
Une politique de navigateur géré exprime une restriction web plus directement qu’une liste d’adresses copiée, mais elle s’applique aux navigateurs et profils que gouverne le système de gestion.
Cette règle de navigateur ne fait rien pour un client vocal qui envoie de l’UDP vers un autre hôte, et ses motifs sont définis par ce produit plutôt que par des conventions de jokers empruntées ailleurs. Un proxy CONNECT reçoit lui aussi un hôte et un port pour une requête tunnelisée, et ne peut pas lire le chemin à l’intérieur de la session chiffrée. Concevez la règle autour de ce que le protocole expose. Écrivez ensuite ce qu’elle laisse sans couverture, car cette lacune est d’où viendra la prochaine requête.
Choisissez par les clients, non par la commande
Demandez quels clients la politique doit couvrir et lesquels elle peut manquer. Une politique de navigateur géré couvre ce que le système de gestion atteint et s’arrête à la frontière du navigateur. Une politique de résolveur couvre tout ce qui utilise votre résolveur, un ensemble plus large, et elle échoue en ouvert pour quiconque ne le fait pas.
Pour un service que vous exploitez, l’autorisation dans l’application est plus forte que toute frontière réseau, car elle suit le compte plutôt que le chemin. Une route VPN est une accessibilité et rien de plus : pouvoir envoyer un paquet à un service n’est pas la permission de l’utiliser. Là où l’identifiant qui compte est un utilisateur ou une permission de canal, appliquez-le à cet endroit et traitez la règle réseau comme une seconde couche.
Écrivez la règle en termes de ressource
Une politique défendable nomme la ressource, les identités, les applications dans le périmètre et le chemin qui les transporte, y compris les deux familles d’adresses en usage. Elle indique aussi ce qui arrive à l’infrastructure partagée que la règle affectera incidemment.
Cette formulation produit une décision que quelqu’un pourra auditer plus tard. Une règle justifiée par l’adresse résolue du jour produit un incident la première fois que l’adresse change, et personne ne pourra expliquer pourquoi le blocage a jamais été correct.