Comment DoorDash sécurise le transfert de données entre les centres de données en nuage et sur site

Au fur et à mesure que les activités de DoorDash se développent, les ingénieurs s'efforcent d'améliorer l'infrastructure du réseau afin de garantir que davantage de services tiers puissent être intégrés dans notre système tout en assurant la transmission sécurisée des données. Pour des raisons de sécurité et de conformité, certains fournisseurs traitant des données sensibles ne peuvent pas exposer leurs services à l'Internet public et hébergent donc leurs propres centres de données sur site. Pour intégrer ces fournisseurs, l'équipe DoorDash core-infra devait améliorer les couches de réseau existantes et trouver une solution pour relier les microservices DoorDash et les centres de données sur site.

Dans ce billet, nous expliquerons comment nous avons établi une connexion réseau privée sécurisée, stable et résiliente entre les microservices DoorDash et les centres de données sur site de notre fournisseur en exploitant les installations réseau de notre fournisseur de services en nuage, Amazon Web Services (AWS).

Étude de cas : ajout de processeurs de paiement supplémentaires 

Le service de paiement DoorDash joue un rôle essentiel dans notre logique commerciale puisqu'il implique les clients, les Dashers (notre nom pour les livreurs) et les services marchands. Le transfert de données entre DoorDash et les processeurs de paiement doit être crypté pour protéger la vie privée et les données sensibles des clients. Il doit également être fiable afin que DoorDash puisse toujours traiter les commandes des clients, ce qui est une nécessité pour le fonctionnement de notre entreprise.

À l'origine, DoorDash ne prenait en charge qu'un seul processeur de paiement, ce qui devenait un point de défaillance unique dans notre flux de paiement. Toute panne inattendue de ce seul processeur de paiement pouvait empêcher DoorDash d'honorer les commandes. Pour atténuer cette vulnérabilité, l'équipe du service de paiement a voulu introduire une redondance dans le traitement des paiements en ajoutant des fournisseurs de traitement des paiements supplémentaires. 

Le problème de la redondance des paiements est que notre infrastructure ne prend en charge qu'un sous-ensemble de fournisseurs qui peuvent desservir le trafic public. Pour les autres fournisseurs hébergeant des services dans des centres de données sur site, il n'existait aucune solution de connexion. Les sections suivantes expliquent comment notre équipe a établi des connexions réseau avec ces fournisseurs.

Trouver la bonne approche pour établir des connexions de réseau

L'infrastructure de DoorDash est principalement basée sur AWS, ce qui signifie que nous devons faire le lien entre l'infrastructure et les centres de données sur site des fournisseurs. Comme nous l'avons vu dans la section précédente, nos fournisseurs de traitement des paiements tournés vers l'avenir ont déployé leurs serveurs dans des centres de données sur site, plutôt que dans le nuage, afin de s'assurer qu'ils ont un contrôle total sur le stockage et le transfert des données. Pour adopter un nouveau processeur de paiement avec ces fournisseurs, nous avons besoin d'une connexion réseau sécurisée entre le nuage AWS de DoorDash et les centres de données sur site de nos fournisseurs de traitement des paiements.

Nous avons examiné deux approches courantes pour relier les centres de données sur site au nuage AWS : Site-to-Site VPN et Direct Connect. Notre équipe s'est engagée à développer une infrastructure de haute qualité en mettant l'accent sur la sécurité, la stabilité et la résilience, et nous utilisons les mêmes principes pour déterminer la meilleure approche pour établir cette connexion.

Choisir la meilleure connexion réseau

Le VPN site à site est une sorte de connexion entre plusieurs réseaux qui communiquent et partagent des ressources. Sous le capot, le VPN site à site crée deux tunnels de sécurité IPsec, où les données peuvent être cryptées et transmises sur l'internet public.

L'autre option, Direct Connect, établit un réseau privé dédié qui relie le nuage AWS et les centres de données sur site, ce qui garantit un faible délai de transmission et une communication stable. En outre, le trafic sur Direct Connect n'est pas visible depuis l'internet public.

Nous avons finalement opté pour Direct Connect plutôt que pour la mise en œuvre d'un VPN de site à site parce que Direct Connect fournit une liaison par fibre optique dédiée au transfert de données, qui dissimule nos demandes et les réponses du fournisseur à l'Internet public. En même temps, il garantit une connexion cohérente avec une faible latence. Dans la prochaine partie de l'article, nous verrons comment nous avons mis en œuvre cette connexion et quels ont été les obstacles rencontrés.

Établir des connexions privées à l'aide de Direct Connect

Une fois que nous avons compris les exigences et choisi le réseau utilisé pour établir la connexion entre notre microservice de paiement et le processeur de paiement tiers, l'étape suivante consiste à étendre notre infrastructure réseau actuelle et à mettre en œuvre la solution Direct Connect.

Le lien réseau Direct Connect est basé sur des câbles Ethernet à fibre optique dédiés au lieu de l'Internet public. L'établissement d'une connexion privée utilisant Direct Connect entre DoorDash et notre fournisseur de traitement des paiements implique trois composants principaux : 

• Comptes DoorDash AWS : un groupe de comptes AWS qui hébergent les ressources Doordash AWS telles que les unités de calcul et les installations réseau. Le service de paiement DoorDash utilise Elastic Compute Cloud (EC2) comme plateforme de calcul. Les instances EC2 sont déployées dans une section isolée du réseau virtuel appelée Virtual Private Cloud (VPC). Le trafic à l'intérieur du VPC est transmis à une passerelle de connexion directe (DXG).
• Les centres de données sur site du vendeur : l'entrepôt du vendeur qui sert les demandes de traitement de paiement de DoorDash. Les centres de données du vendeur ont des liens privés vers leurs propres routeurs qui sont configurés dans les emplacements AWS Direct Connect.
• Emplacement de connexion directe : un centre d'échange de trafic de réseau AWS à haut débit qui contient à la fois des routeurs AWS Direct Connect et des routeurs du fournisseur. Les routeurs AWS Direct Connect acceptent le trafic de DoorDash via DXG, et transmettent le trafic aux routeurs du fournisseur souhaité.

Comme le montre la figure 1, la connexion entre le centre de données sur site du fournisseur et l'emplacement AWS Direct Connect existe déjà par le biais d'un système de connexion croisée physique. Notre objectif principal ici est d'établir la communication entre les comptes DoorDash AWS et le centre de données sur site du fournisseur, ce qui peut être réalisé en deux étapes :

• Configurer les routes à l'intérieur du VPC et exposer le trafic à DXG
• Jumeler les routeurs DXG à AWS Direct Connect à l'intérieur de l'emplacement Direct Connect

Configurer des routes à l'intérieur de VPC et exposer le trafic à DXG

Le trafic en provenance d'EC2 doit passer par une passerelle privée virtuelle (VGW), puis être acheminé vers DXG via une interface virtuelle privée (Private VIF).

Nous avons d'abord créé une table de routage dans le sous-réseau privé d'EC2 et dirigé tout le trafic destiné à l'IP des services de traitement des paiements du fournisseur vers un VGW. Le VGW est un routeur de bordure de VPC permettant d'exposer le trafic interne.

# Hashicorp Terraform
# Create a route forwarding traffic to payment processing service via a VPN gateway
resource "aws_route" "doordash_to_payment_processing_service" {
 route_table_id         = "<route_table_id_in_private_subnet>"
 destination_cidr_block = "<ip_address_of_payment_processing_service>"
 gateway_id             = aws_vpn_gateway.doordash_vgw_of_payment_service_vpc.id
}

Ensuite, nous avons associé le VGW de notre VPN au DXG de notre compte AWS, et nous avons provisionné un Private VIF qui est une interface réseau utilisée pour faire le pont entre le VGW et le DXG.

# Hashicorp Terraform
# Associate the VGW in our VPN to the DXG
resource "aws_dx_gateway_association" "vgw_to_dxg" {
 dx_gateway_id               = aws_dx_gateway.doordash_dxg.id
 associated_gateway_id       = aws_vpn_gateway.doordash_vgw_of_payment_service_vpc.id
}

Associer DXG aux routeurs AWS Direct Connect

AWS Direct Connect Location utilise un numéro de système autonome (ASN) privé configurable pour identifier le DXG. Par conséquent, nous devions lier un DXG à un ASN attribué par notre compte DoorDash AWS.

# Hashicorp Terraform
# Bind a DXG to a AWS ASN
resource "aws_dx_gateway" "doordash_dxg" {
 name            = "<direct_connect_gateway_name>"
 amazon_side_asn = "<aws_asn_will_be_allocated_to_the_dxg>"
}

L'ASN seul n'est pas suffisant pour identifier les connexions puisque le DXG peut contenir plusieurs Private VIF, nous devons également spécifier quel Private VIF est l'accepteur de trafic désiré. 

# Hashicorp Terraform
# Specify DXG id and private VIF id to accept connection from AWS Direct Connect Location
resource "aws_dx_hosted_private_virtual_interface_accepter" "private_vif_to_dxg" {
 virtual_interface_id = "<private_virtual_interface_id>"
 dx_gateway_id        = aws_dx_gateway.doordash_dxg.id
}

Une fois la connexion établie, le nuage DoorDash pourra envoyer des demandes à un lieu de connexion directe via DXG, tandis que le centre de données sur site de notre fournisseur pourra recevoir des demandes du même lieu de connexion directe.

Publicité des adresses IP publiques via l'interface VIF privée

Comme indiqué ci-dessus, nous avons construit le chemin réseau entre nos microservices et l'emplacement de connexion directe, et les demandes ont été échangées vers le centre de données sur site. L'étape suivante consiste à tester si les demandes peuvent effectivement atteindre les services de traitement des paiements de notre fournisseur. Cependant, lorsque nous avons lancé les premières requêtes vers les adresses IP de destination, toutes nos requêtes ont été interrompues.

Les ingénieurs réseau de notre fournisseur nous ont informés que la demande était bloquée par leur pare-feu. Comme le montre la figure 2, le centre de données sur site du fournisseur active quelques règles de pare-feu réseau. L'une de ces règles rejette tous les paquets provenant de la plage CIDR (Classless Inter-Domain Routing) privée, de 10.0.0.0 à 10.255. 255.255 (classe A), 172.16.0.0 à 172.31. 255.255 (classe B) ou 192.168.0.0 à 192.168. 255.255 (classe C). Cette règle garantit que la demande reçue dans le centre de données sur site du fournisseur provient de sources externes. Cela s'explique également par le fait que les systèmes des fournisseurs sont multi-locataires et doivent permettre à plusieurs organisations de se connecter à leur environnement à l'aide d'adresses IP uniques et publiques.

Comme le montre la figure 3, pour résoudre ce problème, notre première tentative consiste à créer une passerelle NAT dans un sous-réseau public, afin de convertir nos demandes sortantes en une adresse IP Elastic publique. Cependant, lorsque notre trafic passe par l'interface VIF privée, son adresse IP source est convertie de manière inattendue en une adresse IP interne dans un CIDR privé de classe A. Cela signifie que le paquet ne passe toujours pas la barrière de l'adresse IP Elastic. Cela signifie que le paquet ne respecte toujours pas les règles du pare-feu.

La cause première de ce problème est que le Private VIF dans VGW n'a pas capturé l'adresse Elastic IP de la passerelle NAT, ce qui fait que tout notre trafic sortant provient d'une plage CIDR privée. Étant donné que le pare-feu du fournisseur n'accepte que le trafic provenant d'adresses IP publiques, il refuse toujours toutes nos demandes.

Après avoir discuté avec les architectes d'AWS, nous avons découvert que les VPC peuvent avoir un bloc CIDR secondaire dans lequel nous pouvons configurer un CIDR public, bien qu'il ne soit pas annoncé publiquement et alloué pour une utilisation au sein du VPC. Nous pouvons alors avoir un sous-réseau privé avec le bloc CIDR public assigné et il peut héberger une passerelle NAT privée qui utilise alors une adresse IP publique pour effectuer la traduction d'adresse réseau. Cela signifie que le trafic sortant envoyé par cette passerelle NAT privée peut s'attacher à une plage CIDR publique. Il peut alors traverser le pare-feu du fournisseur avec une adresse IP publique.

Nous avons rapidement modifié notre infrastructure, comme le montre la figure 4, en déployant une passerelle NAT privée dans un sous-réseau privé distinct au sein du même VPC. Le nouveau sous-réseau privé associera une IP à une plage CIDR publique, ce qui permettra à la passerelle NAT privée de traduire l'IP source du paquet en une IP interne publique à laquelle la passerelle NAT est assignée.

# Hashicorp Terraform
# Create a private subnet with a public IP cidr range
resource "aws_subnet" "private_subnet_with_public_cidr" {
 vpc_id            = "<id_of_vpc_that_the_subnet_will_be_created_in>"
 cidr_block        = "<public_cidr_block>"
 availability_zone = "<availability_zone>"
}
 
# Create a private NAT gateway inside private subnet
# Outbound traffic uses one of the IPs in <public_cidr_block> as source address
resource "aws_nat_gateway" "private_nat_gateway" {
 connectivity_type = "private"
 subnet_id         = aws_subnet.private_subnet_with_public_cidr.id
}

Maintenant que nous avons réussi à lier nos requêtes sortantes à une IP publique autorisée par le pare-feu de notre fournisseur, nous voulons étendre le VPC et la configuration DGX à la production. Nous voulons étendre la configuration VPC et DGX à la production.

Prise en charge des connexions à partir d'environnements multiples

Chez DoorDash, nous gérons nos environnements d'essai et de production dans deux comptes AWS différents, l'un pour l'essai et l'autre pour la production. L'un des obstacles à la mise en place de cette route réseau dans l'environnement de production est que le fournisseur de notre processeur de paiement ne peut gérer qu'une seule connexion pour DoorDash. Cela signifie que nous devons trouver un moyen pour que nos comptes staging et production partagent le même Direct Connect.

Pour prendre en charge le partage Direct Connect, notre équipe a collaboré avec l'équipe de sécurité pour examiner notre configuration et a décidé d'intégrer cette infrastructure dans notre compte de production. Comme le montre la figure 5, pour faciliter la gestion du routage du réseau, nous avons décidé de combiner la passerelle Direct Connect avec notre compte de réseau central et d'utiliser AWS Transit Gateway pour l'interconnexion du trafic entre les comptes.

Nous avons déployé une passerelle Transit Gateway dans notre compte de connexion central et l'avons attachée à nos comptes de production et d'essai. En outre, nous avons mis en place une liste de contrôle d'accès au réseau (NACL) dans notre VPC central. Une liste de contrôle d'accès au réseau autorise ou refuse un trafic entrant ou sortant spécifique au niveau du sous-réseau. Elle garantit que seules les demandes et les réponses des adresses IP de nos fournisseurs peuvent passer par Direct Connect.

Suivant le modèle de la figure 5, les connexions sécurisées entre le nuage DoorDash et le service de traitement des paiements sur site du fournisseur peuvent s'étendre sur des environnements de préparation et de production.

Conclusion

En utilisant des composants réseau tels que Direct Connect et NAT Gateway, nous avons réussi à relier les ressources cloud de DoorDash au centre de données sur site de notre fournisseur. Nous comprenons les limites de la passerelle NAT publique d'AWS. Elle ne peut pas traduire une IP interne en une IP élastique lorsque le trafic passe par un VIF privé.

Pour permettre cette traduction, nous avons créé un sous-réseau privé avec une plage CIDR publique et y avons déployé une passerelle NAT privée. Ce sous-réseau privé garantit que la passerelle NAT est assignée à une IP interne publique et que le trafic qui passe par elle a pour adresse source une plage CIDR publique.

Cette solution montre comment notre équipe et la sécurité construisent un chemin de réseau de données privé entre nos ressources en nuage et un centre de données sur site.

Les services web sont soumis à des lois et à des règles de conformité, telles que le règlement général sur la protection des données (RGPD) et SOC 2, qui poussent les entreprises à utiliser des mécanismes plus sûrs pour conserver les données sensibles de leurs clients. Comme elles adhèrent à une conformité plus stricte en matière de confidentialité des données, de plus en plus d'entreprises peuvent déplacer les services existants vers des centres de données sur site afin de garantir une occupation unique, d'effectuer des audits complets de l'accès aux données et d'introduire du matériel personnalisé pour améliorer la sécurité des données.

Cette étude de cas est conçue pour aider les entreprises de taille moyenne qui s'intègrent avec des fournisseurs tiers, tels que des systèmes bancaires et des bourses dans des centres de données sur site, en leur donnant un exemple pour les guider dans le processus de configuration du réseau.

Remerciements

Merci à Lin Du, Luke Christopherson et Jay Wallace pour leurs conseils et leur contribution à ce projet. Merci à Saso Matejina et Sebastian Yates pour avoir initié ce projet et fourni un retour d'information dans ce billet de blog. Un grand merci à tous les membres de l'équipe infra-sec, à Anand Gaitonde, architecte de solutions AWS, et à Ameet Naik, gestionnaire de comptes techniques AWS. Enfin, Ezra Berger a relu plusieurs itérations de ce billet de blog et nous a fait part de ses commentaires précieux en permanence.

Si vous êtes intéressé par de tels défis et que vous souhaitez évoluer au sein de l'infrastructure de DoorDash, veuillez consulter la page de carrière de core-infra.

Référence

• Qu'est-ce que AWS Direct Connect : https://docs.aws.amazon.com/directconnect/latest/UserGuide/Welcome.html#overview-components
• Travailler avec des interfaces virtuelles :
  https://docs.aws.amazon.com/directconnect/latest/UserGuide/WorkingWithVirtualInterfaces.html
• VIF privé et VIF public :
  https://aws.amazon.com/premiumsupport/knowledge-center/public-private-interface-dx/
• Politiques de routage :
  https://docs.aws.amazon.com/directconnect/latest/UserGuide/routing-and-bgp.html#routing-policies
• Passerelle Direct Connect :
  https://docs.aws.amazon.com/directconnect/latest/UserGuide/direct-connect-gateways-intro.html