Un transit chiffré n'ouvre pas l'accès à l'opérateur

Deux passerelles approuvées transportent le trafic d'un réseau moins fiable à travers un réseau de transport restreint. Chiffrer la charge utile la rend illisible pour les observateurs ordinaires du transit, et c'est la partie que l'on conçoit d'abord avant de cesser d'y penser. Ce que le chiffrement ne fait pas, c'est définir quelles ressources le côté moins fiable peut atteindre. La conception a besoin de deux frontières : une autour de la conversation transportée, et une autour de l'accès à l'opérateur lui-même.

Exécutez les étapes ci-dessous dans l'ordre, et traitez tout échec à n'importe quelle étape comme un changement de conception plutôt qu'un ajustement de configuration.

Définissez les deux frontières avant de toucher à une configuration

La première frontière est la conversation : quelles paires de passerelles peuvent établir un tunnel, et quel trafic interne est autorisé à le traverser. La seconde est l'opérateur : quelles adresses et quels services les hôtes moins fiables peuvent atteindre hors du tunnel. Les équipes construisent généralement la première et héritent de la seconde de tout routage qui existait déjà, et c'est ainsi qu'une conception contrainte devient discrètement une conception large. Cet héritage est la cause racine habituelle lorsqu'une revue découvre qu'un hôte moins fiable parle à quelque chose que personne n'a approuvé.

Écrivez les deux sous forme de listes d'adresses, de ports et de directions. Si une liste ne peut pas être écrite, la frontière n'est pas encore définie.

Étape 1 : contraindre le tunnel extérieur

Sur l'interface tournée vers l'opérateur, n'autorisez que ce dont le tunnel a besoin : IKE sur UDP 500 et 4500 entre les deux adresses de passerelle, et ESP là où la traversée NAT n'est pas utilisée. Refusez tout le reste qui arrive sur cette interface, y compris les protocoles de gestion. La spécification ESP couvre les services de protection ; elle ne dit rien sur les services propres de l'opérateur que les passerelles peuvent utiliser. Exprimez cela sous forme de liste d'autorisations explicite, afin qu'un service de l'opérateur récemment publié ne devienne pas accessible par défaut.

C'est l'ensemble de règles qui fait de la conception une conception de transit et non un accord de peering.

Vérifiez-le depuis le côté moins fiable, pas depuis la console de la passerelle. Un hôte là-bas devrait échouer à atteindre un serveur DNS de l'opérateur avant même que le tunnel ne soit monté.

Étape 2 : décider de ce que livre la passerelle distante

À l'extrémité distante, le trafic récupéré doit aller quelque part de précis. Définissez quels services internes sont autorisés, depuis quelles plages sources, et si les réponses sont censées être symétriques. Revoyez l'accès d'administration séparément, car la même passerelle expose souvent une interface administrative qui n'a jamais fait partie du plan de transit.

Un schéma qui s'arrête au déchiffrement réussi a sauté la décision qui compte le plus.

Étape 3 : conserver la propriété par couche

L'équipement de transit reçoit et transmet encore des paquets extérieurs, il a donc besoin de correctifs et de planification de capacité. Les extrémités du tunnel traitent le protocole protégé et exposent le trafic interne à leur chemin de transmission, elles ont donc besoin de leurs propres règles et de leur propre supervision. Les applications finales traitent la charge utile, et une charge opaque n'est pas la preuve qu'un téléchargement déchiffré est inoffensif.

Attribuez un propriétaire à chaque couche. Les couches sans propriétaire sont celles qui dérivent.

Étape 4 : vérifier, puis remettre à l'autorité

Vérifiez le chemin extérieur avec le tunnel monté et les règles de l'opérateur en place. Essayez ensuite chaque ressource que le côté moins fiable ne devrait pas atteindre et confirmez que l'échec est un refus et non un délai d'attente qui masque une route. Vérifiez aussi la disponibilité et les limites de ressources, car une liaison chiffrée peut encore être saturée.

Pour les environnements réglementés ou classifiés, portez la conception à l'autorité de sécurité responsable et utilisez son architecture de séparation approuvée. Une configuration VPN et une explication conceptuelle n'établissent pas une accréditation. Cette étape n'est pas de la paperasse ; elle décide si la conception est autorisée à exister.