GlobalSign Blog

Que sont les proxys de centres de données et quand les utiliser ?

Que sont les proxys de centres de données et quand les utiliser ?

Les proxys de centres de données sont essentiellement des proxys HTTP/S haute performance qui permettent d’intervenir sur le trafic entre votre application et Internet. Ils peuvent être utilisés pour modifier le trafic, déboguer des problèmes, renforcer la sécurité (en bloquant certains types de demandes, en masquant le lieu d’hébergement de votre application), mettre le contenu localement en cache, et bien d’autres raisons. Dans cet article, nous nous concentrerons sur les différents cas d’utilisation des proxys de centres de données.

Empêcher la divulgation accidentelle d’informations privées

Quand on travaille avec une API, personne en dehors de votre organisation/application ne doit pouvoir accéder à des données sans y être autorisé. Dans le meilleur des cas, vous essuyez à votre cœur défendant la colère d’utilisateurs qui découvrent subitement leur numéro de carte de crédit affiché en ligne ; dans le pire des cas, votre application web se fait pirater.

Pour éviter d’en arriver là, vous pouvez créer un proxy de centre de données, c’est-à-dire un intermédiaire entre votre application et l’API avec laquelle vous communiquez. Ce proxy est alors chargé de s’assurer que toute requête est sécurisée ou « assainie » avant d’atteindre l’API.

Cela peut passer par l’anonymisation ou le masquage d'informations, ainsi que la suppression de certaines données clés (ex. : numéros de carte de paiement). À moins qu’il ne s’agisse de vérifier que les données ne sont pas mises en cache sur le client – les techniques sont nombreuses. Vous avez développé vous-même une API ? L’approche peut vous aider à garantir que seuls les utilisateurs authentifiés ont accès à votre base de code en plaçant les informations d’authentification dans les en-têtes HTTP transmis par le proxy du centre de données.

Autre scénario courant, toujours dans le domaine des données privées : une API tierce modifie soudainement ses conditions de service/API et ne peut plus être utilisée sans intégrer votre mécanisme d’authentification. Dans ce cas, il pourra être utile de développer ou de modifier un proxy existant afin d’y ajouter votre propre logique métier personnalisée pour le traitement des informations privées.

Débogage

Avec un proxy de centre de données situé entre votre application et Internet, vous pouvez inspecter le trafic en différents points de votre infrastructure. Cet intermédiaire se révèlera fort utile pour débugger les problèmes réseau potentiels et s’assurer que les requêtes effectuées à partir de votre code base ne comportent aucun problème — surtout si ces requêtes atteignent une API tierce qui ne se comporte pas toujours comme prévu.

On peut couramment rencontrer un autre problème lorsqu’une application web est mise à disposition depuis un seul lieu. En effet, suivant la société qui fournit le service, les requêtes peuvent être bloquées ou limitées. Imaginons que votre application soit hébergée sur le service Elastic Container (ECS) d’Amazon. Vous ne pouvez pas imposer à tous les serveurs d’Amazon de rejeter les requêtes adressées à votre base de code, même si un élément arbitraire de données soumis par l’utilisateur pose problème.

Dans ce cas, l’ajout d’un proxy de centre de données entre Amazon ECS et votre application web vous donnera une visibilité sur toutes les erreurs renvoyées par l’infrastructure d’Amazon. Vous pourrez ainsi vous assurer qu’elles sont correctement traitées sur votre propre infrastructure/application via la journalisation, etc.

Sécurité

En plus d’empêcher la divulgation accidentelle d’informations privées comme évoqué plus haut, les proxys de centres de données peuvent servir d’outil de prévention contre l’injection de requêtes illégitimes par rebond (« cross-site request forgery »). En l’absence d’authentification intégrée à l’application, qui s’appuie alors sur une API tierce, ce cas d’utilisation prend tout son sens.

Lorsqu’un client effectue une demande par le biais de votre application vers une API tierce, il arrive que l’utilisateur puisse effectuer des demandes sans avoir été authentifié auprès du service tiers. Il pourrait alors faire des choses qu’il n’est pas censé pouvoir exécuter, comme changer son mot de passe ou annuler son paiement, etc.

Dans les cas où votre base de code n’intègre pas, ou du moins peu, d’infrastructure d’authentification, deux possibilités s’offrent à vous : vous ajoutez vous-même une couche de sécurité supplémentaire, ou bien vous utilisez un proxy de centre de données. Certes, vous pouvez gérer l’authentification vous-même si le cœur vous en dit, mais sachez que c’est une opération chronophage et sujette aux erreurs. L’autre solution consiste à utiliser l’un de ces proxys de centres de données pour assurer l’authentification pour vous. Ainsi, les demandes adressées à cette API tierce ne sont faites que par des utilisateurs authentifiés et dans le contexte approprié (par exemple, un utilisateur disposant des bonnes autorisations).

Geolocation

Selon le lieu où se trouvent vos utilisateurs, vous souhaitez peut-être que s’affiche une version différente de votre application web ? Si les utilisateurs visitent ou utilisent votre application dans l’Union européenne, vous pouvez, par exemple, ajouter des fonctionnalités supplémentaires, comme l’affichage des prix TTC pour les services proposés en Europe.

Dans la mesure du possible, mieux vaut éviter que les règles soient codées en dur dans votre base de code (« vues » dans Django, réponses des contrôleurs dans Rails, etc.) et ajouter cette logique dans le proxy de votre centre de données. Vous pourrez en effet passer d’un proxy à l’autre en fonction de l’emplacement de vos utilisateurs. Par exemple, si un utilisateur vient d’Europe, vous pouvez basculer vers un proxy spécifique à l’UE qui veillera à ce que les prix s’affichent comme prévu.

Conclusion

Les proxys de centres de données peuvent être utilisés pour diverses raisons. Ils présentent de nombreux avantages, notamment pour simplifier votre infrastructure et vous assurer que votre application web se comporte correctement. Et si vous tenez compte des points évoqués dans cet article, vous ne devriez pas tarder à ajouter l’un de ces proxys à votre infrastructure.

Share this Post

Blogs annexes