Sécurisation de la vérification d'identité : Limites de débit et étranglement des API (FR)

Protection contre les abusLa limitation et l'étranglement du débit sont des défenses essentielles contre les attaques par déni de service (DoS), les tentatives de force brute et le "credential stuffing" sur les API sensibles de vérification d'identité.

Stabilité du systèmeEn contrôlant le volume des requêtes, ces mécanismes empêchent la surcharge des API, garantissant une performance constante et la disponibilité des ressources pour les utilisateurs légitimes.

Intégrité des donnéesLa prévention des requêtes excessives permet de protéger l'intégrité des données d'identité et la précision des processus de vérification, tels que ceux impliquant la vérification d'identité et les contrôles de vivacité.

La Défense Multicouche de DiditDidit met en œuvre des limites de débit globales et spécifiques aux points d'accès, ainsi que des en-têtes X-RateLimit clairs et des directives pour les clients, afin de sécuriser efficacement sa plateforme d'identité.

Le rôle crucial de la limitation de débit dans la vérification d'identité

Dans le paysage numérique actuel, la vérification d'identité est primordiale pour la confiance et la sécurité. Les entreprises s'appuient sur des API pour effectuer des contrôles critiques tels que la vérification d'identité, la détection de vivacité et le filtrage AML. Cependant, ces points d'accès puissants sont également des cibles privilégiées pour les acteurs malveillants. Sans mesures de protection appropriées, ils peuvent être exploités pour le vol de données, la fraude, ou simplement pour perturber les services par des attaques par déni de service (DoS). C'est là que la limitation de débit et l'étranglement des API deviennent indispensables.

La limitation de débit est une stratégie visant à contrôler le nombre de requêtes qu'un client peut adresser à une API dans un laps de temps donné. L'étranglement, concept connexe, consiste à ajuster dynamiquement le taux de requêtes en fonction de la capacité du système ou de limites prédéfinies. Ensemble, ils constituent une ligne de défense cruciale, garantissant que votre infrastructure de vérification d'identité reste stable, sécurisée et disponible pour les utilisateurs légitimes. Imaginez un scénario où un attaquant tente de forcer des millions de vérifications d'identité à l'aide d'identifiants volés ; sans limites de débit, cela pourrait rapidement submerger vos systèmes, entraînant des pannes de service et des violations de données potentielles. Didit, avec sa plateforme d'identité native de l'IA, comprend profondément ces défis et intègre des limitations de débit multicouches directement dans son architecture.

Comprendre les limites globales vs. les limites spécifiques aux points d'accès

Une limitation de débit efficace nécessite une approche nuancée, distinguant l'utilisation générale de l'API des opérations à fort impact. Une limite unique peut être trop restrictive pour les opérations courantes ou trop laxiste pour celles qui consomment beaucoup de ressources. Par conséquent, un système robuste utilise à la fois des limites globales et des limites spécifiques aux points d'accès.

Limites globales

Les limites globales s'appliquent à de larges catégories de requêtes API. Par exemple, Didit implémente des limites globales de 300 requêtes par minute par application pour tous les points d'accès GET et 300 autres requêtes par minute pour tous les points d'accès d'écriture/suppression (POST, PATCH, DELETE). Ces plafonds génériques fournissent une couche fondamentale de protection, agissant comme une barrière pour la consommation globale de l'API. Ils sont conçus pour prévenir les abus généralisés sans impacter indûment les flux opérationnels normaux.

Limites spécifiques aux points d'accès

Au-delà des limites globales, certaines opérations API sont intrinsèquement plus gourmandes en ressources ou plus sensibles, justifiant des contrôles plus stricts. La plateforme de Didit définit des portées supplémentaires et plus restrictives pour ces opérations à fort impact. Par exemple :

• session-v2-create (POST /v2/session/) : Ce point d'accès, crucial pour initier les flux de travail de vérification d'identité, a une limite dédiée de 600 requêtes par minute. Cela garantit que, bien que la création de sessions soit fréquente, elle ne submerge pas le moteur d'orchestration des flux de travail.
• session-decision (GET /v2/session/<id>/decision/) : La récupération des décisions de session est limitée à 100 requêtes par minute. Cela empêche un sondage excessif qui pourrait surcharger les ressources de la base de données, particulièrement important pour les résultats en temps réel des processus tels que la vérification d'identité et le filtrage AML.
• session-generate-pdf (GET /session/<id>/generate-pdf/) : La génération de PDF est une opération liée au CPU, et est donc limitée à 100 requêtes par minute pour gérer les coûts de calcul et assurer la réactivité.

Cette approche à plusieurs niveaux permet un contrôle granulaire, optimisant les performances et la sécurité tout au long du cycle de vie de la vérification d'identité.

Bonnes pratiques côté client pour gérer les limites de débit

Alors que les fournisseurs d'API mettent en œuvre une limitation de débit robuste, les clients jouent également un rôle crucial en respectant ces limites et en créant des applications résilientes. Lorsqu'une API renvoie une réponse "429 Too Many Requests", ce n'est pas un échec mais une indication d'ajuster votre modèle de requête. L'API de Didit, par exemple, inclut des en-têtes critiques dans les réponses 429 pour guider les clients :

• X-RateLimit-Limit : Le nombre maximum de requêtes autorisées dans la fenêtre actuelle.
• X-RateLimit-Remaining : Le nombre de requêtes restantes dans la fenêtre actuelle.
• X-RateLimit-Reset : L'heure (en secondes epoch) à laquelle la fenêtre de limite de débit actuelle se réinitialise.
• Retry-After : Spécifie le temps d'attente avant d'effectuer une nouvelle requête.

Pour créer une intégration robuste, les clients doivent :

1. Surveiller les en-têtes de limite de débit : Surveillez activement X-RateLimit-Remaining et commencez à limiter les requêtes lorsqu'il descend en dessous d'un certain seuil (par exemple, 15 % de X-RateLimit-Limit).
2. Implémenter un "backoff" exponentiel : Pour les réponses 429, ne réessayez pas immédiatement. Au lieu de cela, implémentez une stratégie de "backoff" exponentiel, augmentant le délai entre les tentatives (par exemple, 5s → 10s → 20s → 40s). Cela évite de submerger davantage l'API et lui permet de récupérer.
3. Journaliser et alerter : Journalisez les instances de réponses 429 et les tentatives de réessai déclenchées. Cela aide à identifier les rafales soutenues ou les problèmes potentiels dans les modèles de requête de votre application, permettant à votre équipe d'enquêter et d'optimiser.

Le respect de ces pratiques garantit que votre application s'intègre en douceur et de manière fiable aux services de vérification d'identité, même dans des conditions de charge variables.

Comment Didit aide à sécuriser vos flux de travail d'identité

Didit fournit une plateforme d'identité complète, native de l'IA, conçue dès le départ avec la sécurité et l'évolutivité à l'esprit. Notre limitation de débit multicouche n'est qu'un exemple de la façon dont nous protégeons vos opérations et vos données utilisateur sensibles. Avec Didit, vous bénéficiez de :

• Protection robuste des API : Nos limites de débit globales et spécifiques aux points d'accès protègent contre les abus, assurant la stabilité des services critiques comme la vérification d'identité, la vivacité passive et active, la correspondance faciale 1:1 et le filtrage et la surveillance AML.
• Flux de travail orchestrés : Notre "Business Console" sans code vous permet de concevoir des parcours de vérification complexes, et notre backend gère intelligemment les appels API sous-jacents, en respectant toutes les limites. Par exemple, lors de la génération de liens de vérification ou de Unilinks, le système gère efficacement la création de session et les contrôles ultérieurs.
• Approche axée sur les développeurs : Didit propose des API claires et une documentation complète, y compris des conseils détaillés sur la limitation de débit, permettant aux développeurs de créer des intégrations résilientes dès le premier jour. Notre architecture modulaire signifie que vous pouvez "plug-and-play" les contrôles d'identité sans vous soucier de l'infrastructure sous-jacente.
• Évolutivité et fiabilité : En gérant proactivement le trafic API, Didit assure une haute disponibilité et des performances, même pendant les périodes de pointe. Notre plateforme native de l'IA est conçue pour évoluer à l'échelle mondiale, gérant des millions de vérifications sans compromettre la sécurité ou la vitesse.

L'engagement de Didit en matière de sécurité s'étend au-delà de la limitation de débit, englobant des fonctionnalités telles que le KYC "Core" gratuit, l'absence de frais d'installation et un modèle de paiement à la vérification réussie, rendant la vérification d'identité robuste accessible et efficace pour les entreprises de toutes tailles.

Prêt à commencer ?

Prêt à voir Didit en action ? Obtenez une démo gratuite dès aujourd'hui.

Commencez à vérifier les identités gratuitement avec le niveau gratuit de Didit.