サーバーレスDTLS

DTLSリスナー

DTLSリスナーは、UDPアプリケーション向けのマネージドエッジゲートウェイを提供し、従来のHTTP APIゲートウェイの利便性とスケーラビリティをデータグラムプロトコルにもたらします。クライアントは、リスナーに割り当てられたドメインとポートに直接DTLS 1.2またはDTLS 1.3セッションを確立します。Proxylityはエッジでセッションを終端し、認証されたアプリケーションデータを復号し、プレーンテキストのペイロードをイベント駆動型のクラウドアーキテクチャ（AWS Lambda、SQS、AppSyncなど）にシームレスにルーティングします。これらはすべて、常時稼働するサーバーインフラストラクチャをプロビジョニングまたは維持する必要なしに行われます。バックエンドからの応答は、同じDTLSセッションを通じて再暗号化されて返送されます。

アーキテクチャとセキュリティモデル

Proxylityで設計する際は、セキュリティと運用上の要件に合ったリスナーを選択することが重要です。

エッジ終端（DTLSリスナー）

このモデルは、HTTPSを終端する標準的なWeb CDNまたはAPIゲートウェイ（CloudflareやAWS API Gatewayなど）と全く同じように動作します。DTLSリスナーは、エッジでサーバー証明書、ハンドシェイク、復号を管理します。

メリット: 運用上の利便性が最大化されます。リスナーノードのフリートを実行することなく、完全にサーバーレスでイベント駆動型のUDPアプリケーションを構築できます。

トレードオフ: ゲートウェイが接続を終端してイベントをルーティングするため、ペイロードは設定されたインテグレーションに渡される前にエッジのメモリ内で可視化されます。

エンドツーエンド暗号化（プレーンUDPリスナー）

セキュリティ体制として、ペイロードが中間者から完全に不可視である厳格なエンドツーエンド暗号化（e-to-e）を必要とする場合は、マネージドDTLSリスナーを使用しないでください。

メリット: 完全なデータプライバシー。Proxylityは厳密にトランスポートネットワークとして機能します。

使用方法: 代わりにプレーンUDPリスナーをプロビジョニングしてください。クライアントは暗号化されたDTLSパケットをゲートウェイ経由で送信し、DTLS終端と証明書管理はご自身のアプリケーション環境内で直接処理します。

マネージドDTLSリスナーを使用するタイミング

厳格なエンドツーエンドのペイロードの不可視性よりも運用上の利便性とサーバーレスのスケーラビリティが優先され、クライアントがネイティブでDTLSをサポートしている場合は、マネージドDTLSリスナーを選択してください。

一般的な例としては、RADIUS認証、リアルタイムIoTテレメトリ、ストリーム指向のTLS接続を使用できないカスタムリクエスト/レスポンスプロトコルが挙げられますが、これらはサーバーレスコンピューティングに直接ルーティングされることでメリットが得られます。

DTLSは、ProxylityのWebRTCデータチャネルへのロードマップにおける最初のトランスポートレイヤーでもあります。DTLSリスナーはネイティブDTLSクライアント向けに本日利用可能ですが、SCTPとWebRTCシグナリングは別レイヤーであり、DTLSリスナーでは提供されません。

DTLS、UDP、およびWireGuard

認証オプション

サーバー証明書

各DTLSリスナーは、Proxylityによって管理されるサーバー証明書と秘密鍵を受け取ります。証明書はリスナーの割り当て済みエンドポイントを識別し、DtlsServerCertificate CloudFormation属性を通じて返されます。クライアントアプリケーションの信頼モデルに従って、その証明書またはそのトラストアンカーを配布してください。

CloudFormationが新しいリスナー証明書を生成する必要がある場合は、CertRefreshTokenを変更してください。証明書のローテーションはクライアントが見る証明書を変更するため、本番環境のエンドポイントをローテーションする前に信頼の更新を調整してください。

事前共有鍵（PSK）

DTLS-PSKを使用するクライアントの場合、Psksマップを設定します。各マップキーはハンドシェイク中に送信されるクライアントIDであり、各値は対応するBase64エンコードされたキーです。PSK値は、テンプレートにコミットするのではなく、AWS Secrets Managerまたはその他の保護されたソースに保存してください。

Cookie保護

リスナーが完全なハンドシェイクを実行する前にDTLS Cookie交換を要求するには、RequireCookiesをtrueに設定します。Cookieは、クライアントが主張したソースアドレスでパケットを受信できることを確認するのに役立ち、増幅攻撃やリソース枯渇のリスクを軽減します。Cookieを有効にすると、新しいセッションに1回の往復が追加されます。パブリックエンドポイントに推奨されます。

セッション再開と0-RTT

DTLS 1.3クライアントは、ハンドシェイク完了後に暗号化されたセッションチケットを受け取ります。クライアントは、後続の接続でそのチケットを提示することで、より少ないハンドシェイクメッセージでセッションを再開できます。チケットの暗号化キーはリスナーごとに管理され、CloudFormationを通じて公開されることはありません。

再開されたDTLS 1.3クライアントが最初のフライトでアプリケーションデータを送信できるようにするには、AllowEarlyDataを"true"に設定します。早期データはレイテンシを削減しますが、Proxylityが共有のアンチリプレイフィルターを適用しても、アプリケーションはそれを再生可能として扱う必要があります。冪等な操作（テレメトリ更新など）にのみ有効にし、安全に繰り返せない1回限りのコマンド、金融取引、その他のアクションには0-RTTを使用しないでください。

EarlyDataWindowSecondsは、チケットの有効期間とリプレイフィルターウィンドウの両方を制御します。デフォルトは3600秒で、1秒から604800秒（7日間）までの値を指定できます。DTLS 1.2クライアントはセッションチケットや0-RTTを使用しません。

DTLS 1.2 コネクションID

コネクションID（CID）をサポートするDTLS 1.2クライアントは、クライアントのIPアドレスとUDPポートとは独立して確立されたセッションを識別できます。これにより、セッションはNATリバインディング、ソースポートの変更、アクセスネットワーク間の遷移を、新しいハンドシェイクを実行することなく継続できます。

CIDは、特に低電力IoTデバイスにとって価値があります。確立されたセッションを再利用することで、デバイスがスリープから復帰したり、ネットワークを変更したり、新しいNATマッピングを取得したりした後の追加の無線時間、暗号化処理、およびハンドシェイクレイテンシを回避できます。CIDをネゴシエートしないクライアントは、ネットワークエンドポイントによって識別される標準的なDTLS 1.2セッションを引き続き使用します。

CIDサポートは、クライアントのDTLS実装に存在し、ハンドシェイク中にネゴシエートされる必要があります。openssl s_clientのような基本的な接続ツールは、DTLS 1.2 CIDをネゴシエートしない場合があります。

CloudFormationの設定

Custom::ProxylityUdpGatewayListenerを使用してDTLSリスナーを作成し、Protocolsをdtlsに設定します。DTLSは、同じリスナー上でUDPまたはWireGuardと組み合わせることはできません。

RadiusDtlsListener:
  Type: Custom::ProxylityUdpGatewayListener
  Properties:
    ServiceToken: !FindInMap [ProxylityConfig, !Ref "AWS::Region", ServiceToken]
    ApiKey: !FindInMap [ProxylityConfig, Account, ApiKey]
    Name: radius-dtls
    Description: Encrypted RADIUS authentication endpoint
    Protocols:
      - dtls
    RequireCookies: "true"
    AllowEarlyData: "true"
    EarlyDataWindowSeconds: "3600"
    ClientRestrictions:
      Networks:
        - 203.0.113.0/24
    Destinations:
      - Name: radius-auth
        DestinationArn: !GetAtt RadiusAuthFunction.Arn
        Role:
          Arn: !GetAtt ProxylityDestinationRole.Arn

Outputs:
  DtlsEndpoint:
    Value: !Sub "${RadiusDtlsListener.Domain}:${RadiusDtlsListener.Port}"
  DtlsServerCertificate:
    Value: !GetAtt RadiusDtlsListener.DtlsServerCertificate

PSK設定

DeviceDtlsListener:
  Type: Custom::ProxylityUdpGatewayListener
  Properties:
    ServiceToken: !FindInMap [ProxylityConfig, !Ref "AWS::Region", ServiceToken]
    ApiKey: !FindInMap [ProxylityConfig, Account, ApiKey]
    Protocols:
      - dtls
    RequireCookies: "true"
    Psks:
      sensor-fleet: !Sub "{{resolve:secretsmanager:${DtlsPskSecret}:SecretString}}"
    ClientRestrictions:
      Networks:
        - 198.51.100.0/24
    Destinations:
      - Name: telemetry
        DestinationArn: !GetAtt TelemetryFunction.Arn
        Role:
          Arn: !GetAtt ProxylityDestinationRole.Arn

プロパティ

完全なリソース定義と戻り値については、リスナーCloudFormationリファレンスを参照してください。

セッションチケットサポートが有効になる前に作成されたDTLSリスナーは、再開チケットを発行できるようになる前に、一度CloudFormationスタックアップデートを受け取る必要があります。

リスナーのテスト

OpenSSLを使用して、証明書ベースのDTLS 1.2接続を確認できます。

openssl s_client -dtls1_2 -connect YOUR_DOMAIN:YOUR_PORT

ハンドシェイクが成功すると、リスナー証明書とネゴシエートされた暗号が表示されます。アプリケーションプロトコルは、ハンドシェイク後に有効なペイロードを送信する必要があります。OpenSSL接続が完了しただけでは、デスティネーションはテストされません。

例：サーバーレスRADIUS

公開されているサーバーレスRADIUSの例では、UDP、WireGuard、またはDTLSを介した認証トランスポートをデプロイできます。これは、同じAWSアプリケーションバックエンドが、RADIUSサーバーホストを運用することなく、DTLSリスナーを介して暗号化されたRADIUSトラフィックを受け入れられる方法を示しています。