Résumé

  • Le Cloud NAT n'est pas simplement un dispositif technique pour masquer les sous-réseaux privés. Sur les marchés cloud, il devient l'endroit où se rencontrent la rareté des IPv4 publiques, l'identité de sortie, la tarification, la garde des comptes, les listes blanches et le routage contrôlé par le fournisseur.
  • Les grandes plateformes transforment la capacité d'adresse rare en pouvoir d'adresse lorsque leurs pools d'IPv4 publiques, passerelles NAT, règles d'admission BYOIP, contrôles de compte et procédures de déprovisionnement déterminent si un opérateur Asie-Pacifique peut maintenir une identité publique stable en dehors de la plateforme.
  • APNIC est important dans cette chaîne car des enregistrements fiables, RDAP, Whois, preuves de transfert, RPKI/ROA et historiques d'adresses donnent aux détenteurs de ressources une option de sortie. Mais le rôle le plus fort du registre est une infrastructure de preuve étroite, pas une supervision de l'architecture cloud.
  • Le risque politique est subtil: si les preuves du registre sont lentes, peu claires, non portables, ou entravées par une approbation discrétionnaire, les adresses des fournisseurs cloud deviennent la couche d'identité par défaut. Cela déplace le pouvoir de négociation des réseaux qui détiennent le capital d'adresse vers les plateformes qui louent, mesurent et administrent l'utilisation des adresses.

Le moment de vérité dans une migration cloud arrive souvent dans un tableur qu'aucun client ne voit jamais. Une fintech singapourienne a déplacé son grand livre, son moteur de fraude et son service de notification client de deux salles de colocation vers une région cloud publique. Le plan de calcul est approuvé. Les clusters Kubernetes sont privés. L'équipe sécurité apprécie l'idée que les serveurs d'application n'aient plus d'adresses publiques. L'équipe finance apprécie l'empreinte plus petite du rack.

Puis l'équipe d'intégration bancaire pose une question prosaïque: quelles adresses IP sources doivent être envoyées aux banques, réseaux de paiement, fournisseurs anti-fraude, portails fiscaux et fournisseurs SMS qui autorisent le trafic sortant de l'entreprise?

La première réponse est architecturale. Les charges de travail seront placées dans des sous-réseaux privés. Le trafic sortant passera par des passerelles NAT gérées. Les passerelles NAT utiliseront un petit ensemble d'adresses IPv4 publiques. Ces adresses seront enregistrées dans les listes blanches des partenaires. Les journaux cartographieront l'identité de la charge de travail interne à l'adresse source externe et au port. La surveillance du fournisseur montrera les octets, les paquets, les connexions, les échecs et les frais. Sur le schéma, c'est propre. Privé à l'intérieur, public à l'extérieur, point d'étranglement contrôlé au milieu.

La deuxième réponse est économique. Ces adresses IPv4 publiques ne sont pas seulement des numéros. Ce sont des identifiants intégrés dans les mémoires opérationnelles des contreparties. Elles déterminent si une banque accepte un appel API, si un moteur anti-fraude traite une requête comme familière, si un fournisseur de messagerie voit une continuité, si un point de dépôt réglementaire évite une exception manuelle, et si un responsable d'incident peut séparer le trafic de l'entreprise de celui des autres locataires de la plateforme. Les changer n'est pas comme changer une étiquette de sous-réseau.

C'est plus proche de changer un passeport professionnel.

La troisième réponse est institutionnelle. Qui contrôle les adresses? Si la fintech utilise des adresses du fournisseur cloud, ce dernier fournit l'identité de sortie publique, la tarifie, l'attache au compte et peut modifier les règles de réservation, déplacement, suppression, gestion des abus, utilisation régionale et facturation. Si la fintech apporte sa propre plage IPv4 enregistrée auprès d'APNIC, elle peut préserver son identité externe, conserver sa réputation et réduire sa dépendance au pool du fournisseur.

Mais elle doit passer par le processus d'admission BYOIP du fournisseur, créer l'autorisation de routage appropriée, lier la plage au bon compte et à la bonne région, accepter les limites spécifiques à la plateforme et déprovisionner soigneusement avant de déplacer la même plage ailleurs.

Voilà le véritable sujet. Le Cloud NAT est souvent décrit comme une commodité pour les réseaux privés. C'est aussi un mécanisme par lequel les plateformes cloud transforment la rareté des adresses en pouvoir de plateforme. Ce pouvoir n'est pas grossier. Ce n'est pas un monopole visible sur les paquets. Il est réparti entre les paramètres par défaut des produits, les frais d'IPv4 publique, les frais de traitement NAT, l'éligibilité BYOIP, les contrôles de compte, l'autorisation de routage, la réputation d'abus, les listes blanches des partenaires et la douleur opérationnelle de partir.

En Asie-Pacifique, où l'adoption rapide du cloud côtoie des opérateurs historiques matures, des projets cloud nationaux, l'intégration fintech, les plateformes de jeux et des juridictions réglementaires fragmentées, le résultat est un changement discret dans la propriété du visage public d'un service.

Ce n'est pas un explicatif de produit cloud. Les passerelles NAT, les adresses IP élastiques, les préfixes personnalisés, les adresses externes, les préfixes publics annoncés et les services d'IP élastique diffèrent selon les fournisseurs. Les noms changent. L'économie sous-jacente est stable. Une plateforme disposant d'un grand inventaire d'IPv4 publiques peut vendre de la commodité. Un client disposant d'un capital d'adresse portable peut négocier. Un client sans capital d'adresse portable loue l'identité de la plateforme. Les enregistrements d'APNIC ne décident pas quelle architecture le client devrait choisir.

Ils décident si le client peut prouver suffisamment de contrôle sur ses propres ressources d'adresse pour rendre le choix significatif.

L'adresse publique est devenue le titre de sortie

La plupart des équipes applicatives découvrent l'économie des adresses à l'envers. Elles découvrent d'abord l'adressage privé car il est bon marché, abondant et facile à automatiser. Les modèles cloud créent des sous-réseaux privés. Les nœuds de conteneurs reçoivent des adresses privées. Les services sans serveur et gérés masquent les hôtes sources. Les groupes de sécurité, les tables de routage et les politiques d'identité semblent plus importants que la numérotation publique. L'IPv4 publique ressemble à l'ancien Internet: nécessaire à la périphérie, mais plus au centre de la conception.

Cette impression est en partie vraie à l'intérieur de la plateforme. Elle est fausse à la frontière. Le monde extérieur voit toujours les adresses sources. Les banques demandent toujours des plages de sortie statiques. Les passerelles gouvernementales demandent toujours aux fournisseurs de déclarer les points de terminaison publics. Les fournisseurs de fraude hérités notent toujours la réputation IP. Les fournisseurs SaaS appliquent toujours des limites de débit, des règles par pays et des historiques de locataires aux réseaux sources. Les systèmes de messagerie se souviennent toujours du comportement antérieur.

Les jeux et les plateformes publicitaires luttent toujours contre l'abus en combinant les signaux de compte et les signaux IP. Les centres d'opérations de sécurité écrivent toujours des exceptions autour des IP de sortie connues car les exceptions autour des identités cloud abstraites franchissent rarement les frontières organisationnelles.

Le résultat est une identité divisée. À l'intérieur du cloud, l'identité est le compte, le rôle, la charge de travail, le principal de service, la politique et l'étiquette. À l'extérieur du cloud, l'identité est toujours une adresse IP publique, un préfixe, un ASN, un modèle DNS inversé, un enregistrement de géolocalisation, un historique de réputation et un ensemble de listes blanches de partenaires. Le NAT est le traducteur entre les deux mondes.

Il compresse de nombreuses charges de travail privées en un plus petit nombre d'identités publiques, puis demande au reste d'Internet de faire confiance à ces identités comme si elles représentaient un opérateur cohérent.

La compression est utile. Elle réduit la consommation d'IPv4 publique. Elle rend la conception de sous-réseaux privés gérable. Elle limite le nombre d'adresses à placer dans les listes blanches des partenaires. Elle donne aux équipes sécurité un petit ensemble de points d'étranglement de sortie pour la journalisation et la politique. Mais la compression crée aussi une garde. Si l'adresse externe appartient à la plateforme, celle-ci ne vend pas seulement du calcul et du transit réseau. Elle loue le visage public du client.

Le loyer n'est pas seulement le prix horaire publié. Il inclut la dépendance intégrée dans chaque contrat et liste blanche. Une fintech qui a envoyé dix mille demandes de partenaires pour mettre sur liste blanche quatre adresses cloud a créé un coût de changement. Un opérateur de jeux qui utilise des adresses de sortie appartenant au fournisseur pour l'anti-triche, les paiements et le support client a créé une dépendance de réputation.

Un fournisseur du secteur public qui certifie un petit ensemble d'adresses NAT cloud pour la soumission de documents a intégré ces adresses dans les processus d'approvisionnement, d'audit et de réponse aux incidents. Le client peut posséder son code et ses données. La plateforme peut toujours posséder la mémoire d'adresse par laquelle le monde extérieur reconnaît le service.

C'est pourquoi le Cloud NAT appartient à l'économie de la rareté des IPv4. Le NAT étend la portée des adresses rares, mais l'extension passe par un intermédiaire institutionnel. Quand cet intermédiaire est un opérateur, le débat devient CGNAT, journalisation, demandes légales, attribution d'abus et coût de support. Quand l'intermédiaire est une plateforme cloud, le débat devient tarification de l'IP publique, autorité du compte, pools du fournisseur, admission BYOIP et friction de sortie du cloud. Les deux sont des réponses à la rareté. Elles allouent différentes formes de pouvoir.