このガイドでは、2025 年 3 月 13 日にリリースされた新しい AWS Wickr 管理コンソールについて説明します。AWS Wickr 管理コンソールのクラシックバージョンのドキュメントについては、[「 Classic Administration Guide](https://docs.aws.amazon.com/wickr/latest/adminguide-classic/what-is-wickr.html)」を参照してください。
翻訳は機械翻訳により提供されています。提供された翻訳内容と英語版の間で齟齬、不一致または矛盾がある場合、英語版が優先します。
# 保管中の暗号化
AWS Wickr Data Retention Service は、デフォルトで保持されているすべてのメッセージとファイル添付ファイルを透過的に暗号化します。保管中のデータを確実に暗号化するために、追加の設定を実行する必要はありません。データ保持サービスは、Amazon S3 に保存されているすべての顧客データにサーバー側で暗号化を適用します。
データ保持サービスは、カスタマーマネージド KMS キー (CMK) を使用して保管中の顧客データを暗号化します。を通じてデータ保持サービスをデプロイすると AWS Service Catalog、アカウントに対称 CMK が自動的に作成され、すべての保持データのデフォルトの暗号化キーとして設定されます。使用状況の監査、キーのローテーション、アクセスの取り消しなど、このキーを完全に制御できます。
## データ保持のためのカスタマーマネージド KMS キーを使用した保管中のデータの暗号化
### データ保持サービスがカスタマーマネージド KMS キーを使用する方法
データ保持サービスがデプロイされると、対称カスタマーマネージド KMS キー (RetentionKey) が AWS アカウントに作成されます。このキーは、次のリソースを暗号化するために使用されます。
+ **保持されたメッセージ** — データ保持ボットによってキャプチャされたすべての Wickr メッセージ (テキスト、リアクションなど) は、S3 バケットに保存される前に CMK で暗号化されます。メッセージは Encryption SDK を使用して Nitro Enclave AWS 内で暗号化され、同じ CMK を使用して SSE-KMS を使用して Amazon S3 にアップロードされます。
+ **保持された添付ファイル** — メッセージに関連付けられた添付ファイルは、Nitro Enclave 内の Wickr end-to-end暗号化から復号され、CMK で再暗号化され、SSE-KMS を使用して Amazon S3 に保存されます。
+ **暗号化されたアカウントの状態** — データ保持ボットの暗号化プライベートキーとアカウントの状態は CMK で暗号化され、DynamoDB に保存されます。この状態を復号化するには、Nitro Enclave 認証が必要です。
+ **S3 バケットのデフォルトの暗号化** — 保持 S3 バケットは、CMK をデフォルトの暗号化キーとして使用して SSE-KMS で設定されます。バケットポリシーでは、すべてのオブジェクトを`aws:kms`サーバー側の暗号化でアップロードする必要があります。
+ **復号化された出力バケット** — 顧客が (Step Functions ステートマシンを介して) オンデマンド復号をトリガーすると、復号された出力は、同じ CMK で暗号化された別の S3 バケットにも保存されます。
**クロスアカウントロールアーキテクチャ**
データ保持サービスは Wickr が管理する AWS アカウントで動作し、クロスアカウント IAM ロール () を介してカスタマーリソースにアクセスします`DRSCustomerCrossAccountRole-{networkId}-{region}`。Wickr DRS Enclave ロールは、 AWS STS と外部 ID (`wickr-drs-{networkId}`) を使用して KMS および S3 オペレーションを実行するこのカスタマー側のロールを引き受けます。
**Nitro Enclave 認証**
直接`kms:Decrypt`呼び出し (S3 SSE-KMS 以外) には、Nitro Enclave 認証が必要です。KMS キーポリシーは`kms:RecipientAttestation:PCR0`、、`kms:RecipientAttestation:PCR1`、および `kms:RecipientAttestation:PCR2`条件が存在する必要があることを強制し、機密データ (アカウント状態、メッセージコンテンツ) の復号が検証済みのエンクレーブ内でのみ実行できるようにします。これにより、Wickr を含むすべてのオペレーターがエンクレーブ外で顧客データを復号できなくなります。
AWS Nitro Enclaves は、KMS キーを使用してメッセージを処理し、データ保持モジュールのプライベートキーを復号し、Wickr で暗号化されたメッセージコンテンツを復号し、S3 バケットに保存する前にメッセージごとに一意のデータキーで再暗号化します。
### Data Retention Service でのカスタマーマネージド KMS キーの設定
データ保持サービスは、キーの使用方法`ENCRYPT_DECRYPT`とキー仕様 を持つ対称 KMS キーをサポートします`SYMMETRIC_DEFAULT`。自動キーローテーションは、Service Catalog を介してキーが作成されると、デフォルトで有効になります。
さらに、パスワード復旧ワークフロー用に 2 番目の非対称 KMS キー (ECC\_NIST\_P384、KEY\_AGREEMENT) が作成されます。このキーは ECDH キー契約に使用され、一般的な暗号化/復号には使用できません。このキーは、データ保持ボットのドッカーベースのアーキテクチャから移行するお客様にオプションで使用されます。
**注記**
マルチリージョンキーは現在サポートされていません。KMS キーは、S3 バケットおよびデータ保持サービスのデプロイと同じリージョンにある必要があります。
#### カスタマーマネージド KMS キーを使用するためのアクセス許可の設定
次のキーポリシーは、Service Catalog 経由でデプロイするときに自動的に設定されます。キーを手動で設定する必要がある場合は、次の最小特権ポリシーを使用します。
```
{
"Version": "2012-10-17",
"Statement": [
{
"Sid": "YourExistingStatements",
"Effect": "...",
"...": "..."
},
{
"Sid": "EnclaveGenerateDataKey",
"Effect": "Allow",
"Principal": {
"AWS": "arn:aws:iam::{{{customer-account-id}}}:role/DRSCustomerCrossAccountRole-{{{networkId}}}-{{{region}}}"
},
"Action": "kms:GenerateDataKey",
"Resource": "*",
"Condition": {
"StringLike": {
"kms:RecipientAttestation:PCR0": "*",
"kms:RecipientAttestation:PCR1": "*",
"kms:RecipientAttestation:PCR2": "*"
},
"ForAnyValue:StringEquals": {
"kms:EncryptionContextKeys": [
"aws:wickr:network:id",
"aws:wickr:app:id"
]
}
}
},
{
"Sid": "EnclaveDescribeKey",
"Effect": "Allow",
"Principal": {
"AWS": "arn:aws:iam::{{{customer-account-id}}}:role/DRSCustomerCrossAccountRole-{{{networkId}}}-{{{region}}}"
},
"Action": "kms:DescribeKey",
"Resource": "*"
},
{
"Sid": "EnclaveDecryptWithAttestation",
"Effect": "Allow",
"Principal": {
"AWS": "arn:aws:iam::{{{customer-account-id}}}:role/DRSCustomerCrossAccountRole-{{{networkId}}}-{{{region}}}"
},
"Action": "kms:Decrypt",
"Resource": "*",
"Condition": {
"StringLike": {
"kms:RecipientAttestation:PCR0": "*",
"kms:RecipientAttestation:PCR1": "*",
"kms:RecipientAttestation:PCR2": "*"
},
"ForAnyValue:StringEquals": {
"kms:EncryptionContextKeys": "aws:wickr:app:id"
}
}
},
{
"Sid": "DRSDecryptionLambda",
"Effect": "Allow",
"Principal": {
"AWS": "arn:aws:iam::{{{customer-account-id}}}:role/{DecryptionLambdaRoleName}"
},
"Action": "kms:Decrypt",
"Resource": "*",
"Condition": {
"ForAnyValue:StringEquals": {
"kms:EncryptionContextKeys": "aws:wickr:network:id"
}
}
}
]
}
```
各ステートメントの目的:
EnableIAMPolicies
アカウントルートがキーを管理できるようにします。これは、標準のキー管理者ステートメントです。
EnclaveGenerateDataKey
`kms:GenerateDataKey` — Nitro Enclave によって に呼び出され、S3 に保存する前にメッセージの内容とアカウントの状態を暗号化するためのデータ暗号化キーを生成します。エンクレーブが有効な Nitro Enclave 認証ドキュメント (PCR0/1/2 条件) を提供し、aws:wickr:network:id または aws:wickr:app:id の暗号化コンテキストキーが存在する場合にのみ許可されます。
EnclaveDescribeKey
`kms:DescribeKey` — エンクレーブが初期化中の検証のためにキーメタデータ (キー仕様、使用状況、ステータス) を取得できるようにします。
EnclaveDecryptWithAttestation
`kms:Decrypt` — Wickr メッセージの復号に必要なアカウント状態 (プライベートキー) を復号するために Nitro Enclave によって呼び出されます。これは、エンクレーブが有効な Nitro Enclave 認証ドキュメント (PCR0/1/2 条件) を提供し、暗号化コンテキストキー aws:wickr:app:id が存在し、エンクレーブの外部で復号化を実行できない場合にのみ許可されます。
DRSDecryptionLambda
`kms:Decrypt` — 復号ステートマシンをトリガーするときに、保持されたメッセージを復号するためにオンデマンド復号 Lambda によって呼び出されます。このロールは Wickr サービスからはアクセスできず、暗号化された S3 バケットから独自のメッセージを復号するためにのみ存在します。
以前のデータ保持のインストールから移行が必要な場合は、サーバーレスデータ保持を有効にする前に、Docker-bot モジュールのパスワードを サービスに提供する必要があります。詳細については、[パスワード復旧手順](password-recovery-instruction.md) を参照してください。パスワード復旧キーに必要なポリシーの詳細については、「」を参照してください[データ保持サービスのカスタム KMS キー設定](custom-kms-key.md)。
KMS キーを手動で設定する必要がある場合は、キーの最小許容ポリシー[データ保持サービスのカスタム KMS キー設定](custom-kms-key.md)については、「」を参照してください。
#### カスタマーマネージド KMS キーを使用した新しいデータ保持デプロイの作成
データ保持サービスは を通じてデプロイされます AWS Service Catalog。`WickrDataRetentionProduct` 製品を起動すると、 CloudFormation テンプレートは自動的に次のようになります。
1. エイリアスを使用して対称 CMK を作成します `wickr-drs-{{{networkId}}}-{{{region}}}-{{{suffix}}}-key`
1. エイリアスを使用したパスワード復旧用の非対称 CMK (ECC P-384) を作成します。 `wickr-drs-{{{networkId}}}-{{{region}}}-{{{suffix}}}-password-recovery-key`
1. 対称 CMK を使用して SSE-KMS のデフォルト暗号化で S3 バケットを作成します
1. 適切な KMS アクセス許可`DRSCustomerCrossAccountRole`を持つ を作成します。
1. カスタムリソース Lambda を介して KMS キー ARN と S3 バケットを Wickr 管理 API に登録します
KMS キー ARN は、Wickr Admin SDK エンドポイントを介しても登録されます。
```
PUT /networks/{{{networkId}}}/serverless-resources
{
"s3BucketName": "wickr-drs-{{{networkId}}}-{{{region}}}-{{{suffix}}}",
"kmsKeyArn": "arn:aws:kms:{{{region}}}:{{{accountId}}}:key/{{{keyId}}}",
"passwordRecoveryKmsKeyArn": "arn:aws:kms:{{{region}}}:{{{accountId}}}:key/{{{keyId}}}"
}
```
`kmsKeyArn` パラメータは有効な KMS キー ARN である必要があります。API は ARN 形式を保存する前に検証します。
#### 既存のデプロイでの暗号化設定の変更
データ保持サービスは現在、デプロイ後の CMK の変更をサポートしていません。KMS キーは以下と緊密に結合されています。
+ S3 バケットのデフォルトの暗号化設定
+ DynamoDB に保存されている暗号化されたアカウントの状態
+ Nitro Enclave 認証条件を持つキーポリシー
暗号化キーを変更するには、以下を行う必要があります。
1. 新しい KMS キーを使用して新しい Data Retention Service インスタンスをデプロイします。
1. 古いキーで暗号化された以前に保持されていたメッセージは、元のキーでのみアクセスできます。
**重要**
暗号化されたメッセージが保持バケットに存在する間は、元の KMS キーを無効化または削除しないでください。これにより、これらのメッセージは永続的に回復できなくなります。
#### カスタマーマネージド KMS キーへのアクセスのスコープダウン
**Nitro Enclave 認証 (プライマリアクセスコントロール)**
CMK へのアクセス範囲を設定する主なメカニズムは、Nitro Enclave 認証です。キーポリシーでは`kms:RecipientAttestation:PCR0`、直接`kms:Decrypt`呼び出しに 、`PCR1`、および `PCR2`条件が必要です。これにより、以下が保証されます。
+ 機密データを復号できるのは、検証済みの Wickr DRS エンクレーブバイナリのみです。
+ クロスアカウントロールでも、エンクレーブの外部でデータを復号することはできません。
+ CloudTrail ログには、監査用の実際の PCR 値が含まれます。
**混乱した代理の保護**
クロスアカウントロールは、STS `AssumeRole`呼び出しで外部 ID (`wickr-drs-{networkId}`) を使用します。これにより、別のサービスが Wickr DRS エンクレーブロールを使用してリソースにアクセスしようとする混乱した代理攻撃を防ぐことができます。
**kms:ViaService 条件**
S3 SSE-KMS 復号オペレーションは、 `kms:ViaService`条件を使用してスコープされます。これにより、リクエストが S3-mediated復号が許可されます。 S3
**暗号化コンテキスト**
S3 SSE-KMS には、暗号化コンテキストとして S3 オブジェクト ARN が自動的に含まれます。キーポリシーは、この暗号化コンテキストを使用して、S3 復号アクセス許可を特定のプレフィックス (パスワードツールプレフィックスなど) にスコープします。
## とのデータ保持サービスのやり取りのモニタリング AWS KMS
CloudTrail を使用して、データ保持サービスによって行われたすべての KMS API コールをモニタリングできます。CloudTrail ログエントリを検索するには、CloudTrail コンソールまたは CloudTrail `LookupEvents`オペレーションを使用します。
次の CloudTrail イベントフィールドを使用して、データ保持サービスによる KMS 使用状況を監査できます。
| フィールド | 想定値 |
| --- | --- |
| eventName | Encrypt, Decrypt, GenerateDataKey |
| userIdentity.arn | arn:aws:sts::{{{customerAccountId}}}:assumed-role/DRSCustomerCrossAccountRole-{{{networkId}}}-{{{region}}} または drs-create-account または drs-password-recovery |
| requestParameters.keyId | CMK ARN (例: arn:aws:kms:{{{region}}}:{{{accountId}}}:key/{{{keyId}}}) |
| additionalEventData.recipient.attestationDocument | エンクレーブで認証された Decrypt 呼び出しに存在します (PCR 値を含む) |
| requestParameters.encryptionContext | S3 SSE-KMS の場合: {"aws:s3:arn": "arn:aws:s3:::{{{bucketName}}}/{{{objectKey}}}"} |
モニタリングする主なイベント:
+ **暗号化** — エンクレーブが S3/DynamoDB に保存する前にメッセージコンテンツまたはアカウントの状態を暗号化するときに発生します。
+ **GenerateDataKey** — オブジェクトのアップロード中に S3 が SSE-KMS エンベロープ暗号化用のデータキーを生成したときに発生します。
+ **復号** — エンクレーブがアカウント状態 (認証付き) を復号する場合、または S3 が読み取り時にオブジェクトを自動復号する場合に発生します。
+ **DeriveSharedSecret** — エンクレーブがパスワード復旧フロー中に ECDH キー契約を実行したときに、パスワード復旧キーで発生します。
+ **GetPublicKey** — `collect.py`スクリプトがローカル ECDH 暗号化用のパブリックキーを取得すると、パスワード復旧キーで発生します。
さらに、Service Catalog 製品は、KMS キーの成功メトリクス (Encrypt、GenerateDataKey、Decrypt オペレーション`WickrDataRetentionService-{{{networkId}}}`) のウィジェットを含む CloudWatch ダッシュボード () と、復号の失敗が検出されたときにトリガーされる復号エラーアラームを作成します。