翻訳は機械翻訳により提供されています。提供された翻訳内容と英語版の間で齟齬、不一致または矛盾がある場合、英語版が優先します。

# SPEKE に必要な認証
<a name="authentication"></a>

SPEKE では、オンプレミス製品と、AWS クラウドで実行されるサービスおよび機能に対して認証が必要です。

**Topics**
+ [AWS クラウド実装の認証](#aws-authentication)
+ [オンプレミス製品の認証](#authentication-on-prem)

## AWS クラウド実装の認証
<a name="aws-authentication"></a>

SPEKE では、エンクリプタで使用する IAM ロールによる AWS 認証が必要です。IAM ロールは、DRM プロバイダー、または AWS アカウント内の DRM エンドポイントを所有するオペレーターによって作成されます。各ロールには Amazon リソースネーム (ARN) が割り当てられ、AWS Elemental サービスオペレーターは、暗号化を要求するときにサービスコンソールで提供します。ロールのポリシーアクセス権限は、キープロバイダー API へアクセス権限を付与し、他の AWS リソースへのアクセス権限を付与しないように設定する必要があります。エンクリプタが DRM キープロバイダーに接続すると、ロール ARN を使用してキープロバイダーアカウント所有者の役割が引き継がれます。これにより、エンクリプタがキープロバイダーにアクセスするための一時的な認証情報が返されます。

一般的な実装の 1 つは、オペレーターまたは DRM プラットフォームベンダーがキープロバイダーの前で Amazon API Gateway を使用し、次に API Gateway リソースで AWS Identity and Access Management (AWS IAM) 認可を有効にすることです。次のポリシー定義の例を使用し、新しいロールにアタッチして、適切なリソースにアクセス権限を与えることができます。この場合、アクセス許可はすべての API Gateway リソースに適用されます。

```
{
    "Version": "2012-10-17",		 	 	 
    "Statement": [
        {
            "Effect": "Allow",
            "Action": [
                "execute-api:Invoke"
            ],
            "Resource": [
                "arn:aws:execute-api:us-west-2:*:*/*/GET/*"
            ]
        }
    ]
}
```

最後に、ロールには信頼関係を追加する必要があり、オペレータはサービスを選択できる必要があります

次の例は、DRM キープロバイダーにアクセスするために作成されるロール ARN を示しています。

```
arn:aws:iam::2949266363526:role/DRMKeyServer
```

ロールの作成の詳細については、 「[AWS AssumeRole](https://docs.aws.amazon.com/STS/latest/APIReference/API_AssumeRole.html)」 を参照してください。リクエストの署名については、「[AWS Sigv4](https://docs.aws.amazon.com/general/latest/gr/sigv4_signing.html)」を参照してください。

## オンプレミス製品の認証
<a name="authentication-on-prem"></a>

オンプレミス製品では、セキュリティを最大限に高めるために SSL/TLS とダイジェスト認証を使用することをお勧めしますが、少なくとも HTTPS 経由の基本認証を使用する必要があります。

どちらのタイプの認証でも、HTTP リクエストでは `Authorization` Clusters ヘッダーを使用します。
+  **ダイジェスト認証** – 認可ヘッダーは、識別子の`Digest`後にリクエストを認証する一連の値が続きます。具体的には、レスポンスの値は、パスワードが安全に移動することを保証するために使用されるサーバーからのユニークな 1 回限りの nonce を含む一連の MD5 ハッシュ関数によって生成されます。
+  **基本認証** – 認可ヘッダーは、識別子の`Basic`後にユーザー名とパスワードを表す base-64 でエンコードされた文字列が続き、コロンで区切られます。

ヘッダーに関する詳細情報を含む基本およびダイジェスト認証の情報については、Internet Engineering Task Force (IETF) 仕様「[RFC 2617 - HTTP 認証: 基本およびダイジェストアクセス認証](https://tools.ietf.org/html/rfc2617)」を参照してください。