Face Liveness の責任共有モデル - Amazon Rekognition

Face Liveness の責任共有モデル

セキュリティとコンプライアンスは AWS とお客様との間で共有される責任です。AWS 責任共有モデルの詳細については、こちらをご覧ください。

  1. AWS サービスへの呼び出し (クライアントアプリケーションまたはお客様のバックエンドを経由) はすべて AWS Auth (AWS 認証) で認証および承認されます。この認証作業は、Face Liveness のサービスオーナーの責任です。

  2. (クライアントアプリケーションからの) お客様のバックエンドへの呼び出しはすべて、お客様を介して認証および承認されます。この責任はお客様にあります。お客様は、クライアントアプリケーションからの呼び出しが認証され、何らかの方法で操作されていないことを確認する必要があります。

  3. お客様のバックエンドは、Face Liveness チャレンジを実行しているエンドユーザーを特定する必要があります。エンドユーザーを Face Liveness セッションに結び付けるのはお客様の責任です。Face Liveness サービスはエンドユーザーを区別しません。識別できるのは発信元の AWS アイデンティティ (お客様によって処理される) のみです。

  4. AWS では、ユースケースの要件とセキュリティ体制に沿った Face Liveness に加えて、位置情報 (IP に基づくなど）、ワンタイムパスコード (OTPs) などの追加の検証チェックを適用することを推奨しています。

FaceMovementAndLightChallenge」設定は、ユーザーが顔を画面に向かって移動し、一連の点滅するライトを動かさないようにすることで、Rekognition Liveness に最高の精度を提供します。このデフォルト設定を使用することをお勧めします。または、「FaceMovementChallenge」設定を有効にすると、点滅するライトがなくなるため、チェック時間が数秒短縮されます。「FaceMovementAndLightChallenge」は精度を最大化するための最適な設定のままですが、「FaceMovementChallenge」を使用すると、お客様はより高速なライブネスチェックを優先できます。これらの設定から選択するときは、予想される攻撃タイプ、希望する誤承認率、誤拒否率などのユースケース要件を検討し、位置情報 (IP に基づくなど）、ワンタイムパスコード (OTPs) などの追加のチェックを実装する必要があります。お客様は、ユースケースに応じてさまざまな信頼スコアのしきい値で Liveness のパフォーマンスをテストした後に、この決定を行う必要があります。お客様は、動画の送信元のデバイスを保護するためのコントロールを実装する責任があります。

次のフロー図は、どの呼び出しが AWS のサービスまたはお客様によって認証されるかを示しています。

ライブネス検出フロー図。顔の安全なライブネスチェックセッションのための、クライアントアプリケーション、顔のライブネス検出コンポーネント、顧客のバックエンド、Rekognition サービス、および Rekognition ストリーミングサービス間のやり取りが示されている。

Amazon Rekognition Face Liveness サービスへのすべての呼び出しは、AWS 認証 (AWS 署名メカニズムを使用) によって保護されます。これには以下の呼び出しが含まれます。

お客様のバックエンドへのすべての呼び出しには、認証と認可のメカニズムが必要です。お客様は、使用されているサードパーティーのコード/ライブラリなどがアクティブに保守および開発されていることを確認する必要があります。また、お客様は、正しいエンドユーザーが正しい Face Liveness セッションを呼び出していることを確認する必要があります。お客様は以下のフローを認証して認可する必要があります。

  • [2] Face Liveness セッションの作成 (クライアントアプリケーションから)

  • [10] Face Liveness セッションの結果の取得 (クライアントアプリケーションから)

お客様は STRIDE セキュリティモデルに従って API コールが保護されていることを確認できます。

タイプ 説明 セキュリティコントロール
Spoofing Threat action aimed at accessing and use of another user’s credentials, such as username and password. Authentication
Tampering Threat action intending to maliciously change or modify persistent data. Examples include records in a database, and the alteration of data in transit between two computers over an open network, such as the internet. Integrity
Repudiation Threat action aimed at performing prohibited operations in a system that lacks the ability to trace the operations. Non-Repudiation
Information disclosure Threat action intending to read a file that one was not granted access to, or to read data in transit. Confidentiality
Denial of service Threat action attempting to deny access to valid users, such as by making a web server temporarily unavailable or unusable. Availability
Elevation of privilege Threat action intending to gain privileged access to resources in order to gain unauthorized access to information or to compromise a system. Authorization

AWS は次の方法で接続を保護します。

  1. リクエストの署名を計算し、サービス側で署名を検証します。リクエストはこの署名を使用して認証されます。

  2. AWS のお客様は、特定のアクション/オペレーションを承認するための適切な IAM ロールをセットアップ必要があります。これらの IAM ロールは AWS のサービスへの呼び出しを行うために必要なものです。

  3. AWS のサービスへのリクエストは HTTPS のみが許可されます。リクエストは TLS を使用してオープンネットワークで暗号化されます。これにより、リクエストの機密性が保護され、リクエストの完全性が維持されます。

  4. AWS のサービスは、お客様からの呼び出しを識別するのに十分なデータをログに記録します。これにより、否認攻撃を防げます。

  5. AWS のサービスは十分な可用性を維持しています。

お客様は、以下の方法でサービスと API コールを保護する責任があります。

  1. お客様は、適切な認証メカニズムに従っていることを確認する必要があります。リクエストの認証には、さまざまな認証メカニズムを使用できます。お客様は、ダイジェストベースの認証、OAuth、OpenID 接続、その他のメカニズムを利用できます。

  2. お客様は、サービス API コールを行うための適切な暗号化チャンネル (TLS/HTTPS など) をサービスがサポートしていることを確認する必要があります。

  3. お客様は、API コールと発信者を一意に識別するのに必要なデータをログに記録する必要があります。定義されたパラメータと呼び出し時刻を使用して、API を呼び出しているクライアントを識別できるようにする必要があります。

  4. お客様は、システムが利用可能であることと、DDoS 攻撃から保護されていることを確認する必要があります。DDoS 攻撃に対する防御技術の例をいくつか紹介します。

お客様は、アプリケーションを最新の状態に維持する責任があります。詳細については、「Face Liveness の更新に関するガイドライン」を参照してください。