本人確認のセキュリティ強化：APIレート制限とスロットリング (JA)

不正利用からの保護レート制限とスロットリングは、機密性の高い本人確認APIに対するサービス拒否（DoS）攻撃、ブルートフォース攻撃、クレデンシャルスタッフィングに対する不可欠な防御策です。

システム安定性の確保これらのメカニズムは、リクエスト量を制御することでAPIの過負荷を防ぎ、正当なユーザーに対する一貫したパフォーマンスとリソースの可用性を保証します。

データ整合性の維持過剰なリクエストを防ぐことは、本人確認や生体認証などの本人確認プロセスの整合性と正確性を保護するのに役立ちます。

Diditの多層防御Diditは、包括的なグローバルおよびエンドポイント固有のレート制限と、明確なX-RateLimitヘッダーおよびクライアントガイダンスを実装し、その本人確認プラットフォームを効果的に保護しています。

本人確認におけるレート制限の重要な役割

今日のデジタル環境では、本人確認は信頼とセキュリティにとって最も重要です。企業はAPIを利用して、本人確認、生体検知、AMLスクリーニングなどの重要なチェックを実行しています。しかし、これらの強力なエンドポイントは、悪意のある攻撃者にとって格好の標的でもあります。適切な保護がなければ、データ盗難、詐欺、またはサービス拒否（DoS）攻撃によるサービスの中断に悪用される可能性があります。ここで、APIレート制限とスロットリングが不可欠になります。

レート制限は、クライアントが特定の時間枠内でAPIに対して行えるリクエストの数を制御する戦略です。関連する概念であるスロットリングは、システム容量または事前定義された制限に基づいてリクエストのレートを動的に調整することを含みます。これらが一体となって、本人確認インフラストラクチャが安定し、安全で、正当なユーザーが利用できるようにするための重要な防御線を形成します。攻撃者が盗まれた認証情報を使用して何百万もの本人確認をブルートフォースしようとするシナリオを想像してみてください。レート制限がなければ、これはシステムをすぐに過負荷にし、サービス停止や潜在的なデータ侵害につながる可能性があります。AIネイティブの本人確認プラットフォームであるDiditは、これらの課題を深く理解し、多層的なレート制限をそのアーキテクチャに直接組み込んでいます。

グローバルとエンドポイント固有の制限の理解

効果的なレート制限には、一般的なAPIの使用と影響の大きい操作とを区別する微妙なアプローチが必要です。一律の制限は、一般的な操作に対して厳しすぎるか、リソースを大量に消費する操作に対して緩すぎる可能性があります。したがって、堅牢なシステムは、グローバル制限とエンドポイント固有の制限の両方を使用します。

グローバル制限

グローバル制限は、APIリクエストの広範なカテゴリに適用されます。たとえば、Diditは、すべてのGETエンドポイントに対してアプリケーションあたり1分間に300リクエスト、すべての書き込み/削除エンドポイント（POST、PATCH、DELETE）に対しては別の1分間に300リクエストのグローバル制限を実装しています。これらの一般的な上限は、API全体の消費に対する基本的な保護層を提供し、全体的なAPI消費のガードレールとして機能します。これらは、通常の運用フローに不当な影響を与えることなく、広範な悪用を防ぐように設計されています。

エンドポイント固有の制限

グローバル制限を超えて、特定のAPI操作は本質的にリソースを大量に消費したり、機密性が高かったりするため、より厳格な制御が必要です。Diditのプラットフォームは、このような影響の大きい操作に対して、追加のより制限的なスコープを定義しています。たとえば、次のとおりです。

• session-v2-create (POST /v2/session/): 本人確認ワークフローを開始する上で重要なこのエンドポイントには、1分あたり600リクエストという専用の制限があります。これにより、セッション作成が頻繁に行われる場合でも、ワークフローオーケストレーションエンジンが過負荷にならないようにします。
• session-decision (GET /v2/session/<id>/decision/): セッション決定の取得は、1分あたり100リクエストにスロットリングされます。これにより、特に本人確認やAMLスクリーニングなどのプロセスからのリアルタイム結果にとって重要な、データベースリソースに負担をかける可能性のある過剰なポーリングを防ぎます。
• session-generate-pdf (GET /session/<id>/generate-pdf/): PDF生成はCPUバウンド操作であるため、計算コストを管理し、応答性を確保するために1分あたり100リクエストに制限されています。

この階層化されたアプローチにより、本人確認ライフサイクル全体でパフォーマンスとセキュリティを最適化するきめ細やかな制御が可能になります。

レート制限を処理するためのクライアント側のベストプラクティス

APIプロバイダーが堅牢なレート制限を実装する一方で、クライアントもこれらの制限を尊重し、回復力のあるアプリケーションを構築する上で重要な役割を果たします。APIが429 Too Many Requests応答を返す場合、それは失敗ではなく、リクエストパターンを調整する必要があることを示しています。たとえば、DiditのAPIは、クライアントをガイドするために429応答に重要なヘッダーを含んでいます。

• X-RateLimit-Limit: 現在のウィンドウで許可される最大リクエスト数。
• X-RateLimit-Remaining: 現在のウィンドウに残っているリクエスト数。
• X-RateLimit-Reset: 現在のレート制限ウィンドウがリセットされる時間（エポック秒）。
• Retry-After: 新しいリクエストを行う前に待機する時間を指定します。

堅牢な統合を構築するには、クライアントは次のことを行う必要があります。

1. レート制限ヘッダーを監視する: X-RateLimit-Remainingを積極的に監視し、特定のしきい値（例：X-RateLimit-Limitの15%）を下回った場合にリクエストのスロットリングを開始します。
2. 指数バックオフを実装する: 429応答の場合、すぐに再試行しないでください。代わりに、再試行間の遅延を増やす指数バックオフ戦略を実装します（例：5秒 → 10秒 → 20秒 → 40秒）。これにより、APIのさらなる過負荷を防ぎ、回復を可能にします。
3. ログとアラート: 429応答のインスタンスとトリガーされた再試行をログに記録します。これにより、持続的なバーストやアプリケーションのリクエストパターンにおける潜在的な問題を特定し、チームが調査して最適化することができます。

これらのプラクティスを遵守することで、さまざまな負荷条件下でも、アプリケーションが本人確認サービスとスムーズかつ確実に統合されます。

Diditが本人確認ワークフローを保護する方法

Diditは、セキュリティとスケーラビリティを念頭に置いてゼロから設計された、包括的なAIネイティブの本人確認プラットフォームを提供します。当社の多層レート制限は、お客様の運用と機密性の高いユーザーデータを保護する方法の一例にすぎません。Diditを利用することで、次のメリットが得られます。

• 堅牢なAPI保護: 当社のグローバルおよびエンドポイント固有のレート制限は、不正利用から保護し、本人確認、パッシブ＆アクティブ生体認証、1:1顔照合、AMLスクリーニング＆監視などの重要なサービスの安定性を確保します。
• オーケストレーションされたワークフロー: 当社のノーコードビジネスコンソールを使用すると、複雑な検証ジャーニーを設計でき、当社のバックエンドは、すべての制限を尊重しながら、基盤となるAPI呼び出しをインテリジェントに管理します。たとえば、検証リンクまたはユニリンクを生成する場合、システムはセッション作成とその後のチェックを効率的に処理します。
• 開発者ファーストのアプローチ: Diditは、クリーンなAPIと包括的なドキュメントを提供し、レート制限に関する詳細なガイダンスを含め、開発者が初日から回復力のある統合を構築できるようにします。当社のモジュール式アーキテクチャは、基盤となるインフラストラクチャを気にすることなく、本人確認をプラグアンドプレイできることを意味します。
• スケーラビリティと信頼性: APIトラフィックをプロアクティブに管理することで、Diditはピーク時でも高い可用性とパフォーマンスを保証します。当社のAIネイティブプラットフォームは、セキュリティや速度を損なうことなく、何百万もの検証を処理するためにグローバルにスケーリングするように構築されています。

Diditのセキュリティへの取り組みは、レート制限を超えて、無料のコアKYC、セットアップ費用なし、成功したチェックごとの支払いモデルなどの機能を含み、あらゆる規模の企業にとって堅牢な本人確認をアクセスしやすく効率的にします。

開始する準備はできましたか？

Diditの実演をご覧になりたいですか？ 今すぐ無料デモを入手してください。

Diditの無料プランで、無料で本人確認を開始してください。