AWS LambdaでDiditのセキュアなWebhookミドルウェアを構築する (JA)

セキュアなウェブフック取り込み HMAC-SHA256署名検証とタイムスタンプ検証を実装することは、Diditのウェブフックを改ざんやリプレイ攻撃から保護し、データの整合性と信頼性を確保するために不可欠です。

非同期処理アーキテクチャ AWS LambdaとSQSを活用することで、ウェブフックの取り込みと処理を分離し、スケーラビリティと信頼性を向上させ、リアルタイムの応答に影響を与えることなく複雑なダウンストリームロジックを可能にします。

リアルタイムの本人確認更新 Diditのウェブフックは、本人確認の結果に関する即時通知を提供し、アプリケーション内でユーザーの状態、詐欺アラート、コンプライアンス記録を即座に更新できます。

Diditの開発者ファーストアプローチ DiditはモジュラーアーキテクチャとクリーンなAPIを提供しており、リアルタイムの本人確認結果をシステムに簡単に統合できます。無料のコアKYCとセットアップ費用なしで、さらに強化されています。

セキュアなWebhook処理の重要性

今日の相互接続されたデジタル環境では、特に本人確認のような重要な機能において、リアルタイムのデータ交換が最も重要です。ウェブフックは、これらのリアルタイム通知の基盤として機能し、Diditのようなサービスが本人確認の結果、AMLスクリーニングの結果、または生体認証の状態についてアプリケーションに即座に通知できるようにします。しかし、単にデータを受信するだけでは不十分です。その信頼性、整合性、タイムリーな処理を確保することが不可欠です。安全でないウェブフックエンドポイントは、データ改ざん、リプレイ攻撃、またはサービス拒否攻撃を受けやすい重大な脆弱性となる可能性があります。ここで、特にDiditのウェブフック向けに、適切に設計されたAPI Gatewayミドルウェアが不可欠になります。

DiditがID検証、受動的および能動的生体認証チェック、1対1顔照合、またはAMLスクリーニングを完了すると、設定されたエンドポイントにウェブフックを送信します。この通知には、検証ステータスに関する重要な情報が含まれています。適切なセキュリティ対策がなければ、悪意のあるアクターがこれらの通知を偽造し、誤ったユーザーオンボーディングの決定や詐欺行為につながる可能性があります。例えば、偽造された「検証済み」ステータスは悪意のあるアクターにアクセスを許可する可能性があり、偽造された「失敗」ステータスは正当なユーザーがブロックされる可能性があります。したがって、安全で堅牢なウェブフック受信メカニズムを確立することは、単なる良い習慣ではなく、プラットフォームのセキュリティとコンプライアンスを維持するために不可欠です。

AWS Lambda & API Gatewayで堅牢なミドルウェアを構築する

Diditのウェブフックを効果的かつ安全に処理するために、AWS LambdaとAPI Gatewayの機能を活用してサーバーレスミドルウェアを作成できます。このアーキテクチャは、スケーラビリティ、コスト効率、高可用性を提供し、イベント駆動型データ処理に最適です。コアとなるアイデアは、API Gatewayをエントリーポイントとして機能させ、初期検証とセキュアな処理を担当するLambda関数にリクエストを転送することです。

ステップ1：エントリーポイントとしてのAPI Gatewayのセットアップ

AWS API Gatewayは、Diditがウェブフックを送信するパブリックエンドポイント（例: /api/webhooks/didit）を公開します。このエンドポイントをPOSTリクエストを受け入れるように設定し、Lambda関数と統合することが重要です。従来のセットアップとは異なり、API Gatewayは、署名検証にはDiditによって送信された正確な生ペイロードが必要となるため、生のリクエストボディをJSONパースせずに直接Lambdaに渡すように設定する必要があります。

ステップ2：AWS Lambdaでのセキュアな検証の実装

Lambda関数はミドルウェアの心臓部です。ウェブフックを受信すると、データを処理する前にいくつかの重要な検証ステップを実行する必要があります。

1. 生のリクエストボディの読み取り： Lambda関数は生のリクエストボディにアクセスする必要があります。これはHMAC-SHA256署名検証に不可欠です。
2. HMAC-SHA256署名の検証： Diditのウェブフックには、HMAC-SHA256署名を含むX-Signatureヘッダーが含まれています。Lambda関数は、ウェブフックのシークレット（アプリケーションとDiditの間で共有されている）を使用して、生のリクエストボディから独自の署名を計算します。計算された署名がX-Signatureヘッダーと一致しない場合、ウェブフックは無効であり、直ちに拒否する必要があります。これにより、データ改ざんから保護されます。
3. タイムスタンプの検証： DiditにはX-Timestampヘッダーも含まれています。Lambda関数は、このタイムスタンプが新しいこと、通常は現在の時刻から5分以内であることを検証する必要があります。これにより、攻撃者が古い正当なウェブフックイベントを再送信する可能性があるリプレイ攻撃を防ぎます。
4. JSONボディのパース： 署名とタイムスタンプの検証が成功した後にのみ、生のボディをJSONオブジェクトにパースする必要があります。

Lambda内での署名検証の概念的なPythonスニペットを次に示します。

import hmac
import hashlib
import time
import json

def verify_webhook_signature(body, headers, secret):
    signature_header = headers.get('X-Signature')
    timestamp_header = headers.get('X-Timestamp')

    if not signature_header or not timestamp_header:
        return False, "Missing signature or timestamp header"

    # Check timestamp for freshness (e.g., within 5 minutes)
    current_time = int(time.time())
    event_timestamp = int(timestamp_header)
    if abs(current_time - event_timestamp) > 300: # 300 seconds = 5 minutes
        return False, "Webhook timestamp too old or too far in future"

    # Reconstruct the signed payload
    signed_payload = f"v1:{timestamp_header}:{body}"

    # Compute HMAC signature
    expected_signature = hmac.new(
        secret.encode('utf-8'),
        signed_payload.encode('utf-8'),
        hashlib.sha256
    ).hexdigest()

    # Compare signatures in a secure way (constant time comparison)
    if hmac.compare_digest(signature_header, expected_signature):
        return True, "Signature valid"
    else:
        return False, "Signature mismatch"

# In your Lambda handler:
def lambda_handler(event, context):
    body = event['body'] # Raw request body
    headers = event['headers']
    webhook_secret = "YOUR_DIDIT_WEBHOOK_SECRET" # Store securely, e.g., in AWS Secrets Manager

    is_valid, message = verify_webhook_signature(body, headers, webhook_secret)

    if not is_valid:
        print(f"Webhook validation failed: {message}")
        return {
            'statusCode': 403,
            'body': json.dumps({'message': 'Unauthorized'})
        }

    # If valid, parse JSON and proceed with processing
    payload = json.loads(body)
    # ... process payload ...

    return {
        'statusCode': 200,
        'body': json.dumps({'message': 'Webhook received and processed'})
    }

スケーラビリティと信頼性のための非同期処理

ウェブフックを検証した後、一般的には取り込みプロセスを実際のビジネスロジックから分離することがベストプラクティスです。これは、検証後のLambda関数が複雑なデータベース操作や外部API呼び出しを直接実行すべきではないことを意味します。代わりに、検証済みのペイロードをAWS SQS（Simple Queue Service）などの非同期処理キューにプッシュするだけです。

このアーキテクチャにはいくつかの利点があります。

• スケーラビリティ： API Gatewayと初期のLambdaは、ダウンストリーム処理によってボトルネックになることなく、大量の着信ウェブフックを処理できます。
• 信頼性： ダウンストリームシステムが一時的に利用できない場合でも、メッセージはキューに残され、データ損失を防ぎます。
• 分離： 異なるLambda関数やサービスがSQSキューからのメッセージを処理できるため、ビジネスロジック（ユーザーレコードの更新、AMLアラートのトリガー、検証結果のログ記録など）のモジュール化された独立した開発とデプロイが可能になります。
• 高速応答： 初期ウェブフックエンドポイントは迅速に（例：200 OKで）応答できるため、Diditがウェブフックを不必要に再試行するのを防ぎます。

これにより、ID検証、eパスポートのNFC検証、またはコンプライアンスのための年齢推定のいずれを実行する場合でも、結果が効率的かつ確実に処理されます。

Diditの貢献

Diditは、モジュール性と統合の容易さを追求した、AIネイティブで開発者ファーストの本人確認プラットフォームです。当社のウェブフックは、この哲学の典型であり、本人確認ワークフローのステータスに関するリアルタイムでセキュアな通知を提供します。クリーンなAPIと包括的なドキュメントを提供することで、Diditは、上記のAWS LambdaとAPI Gatewayソリューションのようなカスタムミドルウェアにこれらのウェブフックを簡単にセットアップして統合できるようにします。

Diditのプラットフォームは、ID検証（OCR、MRZ、バーコード）、受動的および能動的生体認証、1対1顔照合＆顔検索、AMLスクリーニング＆モニタリング、住所証明、年齢推定、電話＆メール検証、NFC検証など、幅広い本人確認プリミティブをサポートしています。これらのチェックの結果は、セキュアなウェブフックを介して配信でき、応答性の高い自動化されたシステムを構築できます。さらに、Diditは無料のコアKYC、モジュラーアーキテクチャ、セットアップ費用なしを提供しており、信頼を自動化し、リスクを調整しようとするあらゆる規模のビジネスにとってアクセスしやすく強力な選択肢となっています。

今すぐ始めましょうか？

Diditの動作をご覧になりませんか？ 今すぐ無料デモを予約してください。

Diditの無料ティアで無料で本人確認を始めましょう。