Amazon Transcribeで顧客管理KMSキーを利用可能に
Amazon Transcribeで、カスタム語彙、カスタム語彙フィルター、カスタム言語モデルを、利用者が所有・管理するAWS KMSキーで保存時暗号化できるようになりました。
これまでは、これらのカスタムリソースはAWS所有キーで暗号化されていました。今回の機能により、リソースの作成または更新時に、アカウント内の顧客管理KMSキーを指定できます。
キーを指定しない場合は、従来どおりAWS所有キーが使用されます。そのため、既存環境は原則として変更なしで継続できます。一方、規制対応や厳格なアクセス制御が必要な環境では、暗号鍵を自社の管理下に置けることが重要な選択肢になります。
AWS所有キーと顧客管理キーの違い
両者の主な違いは、暗号化の有無ではなく、鍵に対する管理権限と監査可能性です。
| 項目 | AWS所有キー | 顧客管理KMSキー |
|---|---|---|
| 鍵の管理主体 | AWS | 利用者のAWSアカウント |
| 鍵ポリシーの詳細制御 | 利用者による直接管理は限定的 | IAMやキーポリシーで設計可能 |
| キー利用の監査 | 顧客管理キーほどの管理粒度ではない | CloudTrailで利用状況を追跡可能 |
| 鍵の無効化 | 利用者が任意に制御するものではない | 利用者が無効化や変更を管理可能 |
| 導入時の運用負荷 | 小さい | 権限設計、監視、ライフサイクル管理が必要 |
顧客管理キーを使うと、誰がどのサービスや操作経由でキーを利用できるかを、組織のポリシーに合わせて設計できます。その反面、KMSキーの設定ミスや無効化によって、Transcribeのカスタムリソースを利用できなくなるリスクも生じます。
保護対象となるカスタムリソース
今回の対象は、音声認識処理で利用する次のカスタムリソースです。
- カスタム語彙
- カスタム語彙フィルター
- カスタム言語モデル
これらは、標準の認識モデルだけでは対応しにくい専門用語、固有名詞、社内用語、特定分野の表現などを扱う際に利用されます。医療、金融、製造、コンタクトセンターなど、業務固有の語彙を含む音声認識基盤では、音声データだけでなく、こうしたモデル関連の成果物も保護対象として扱う必要があります。
重要なのは、カスタムリソースの暗号化と、音声ファイルや文字起こし結果の保護は別の論点だという点です。音声データをAmazon S3などに保存している場合は、S3側の暗号化、バケットポリシー、保存期間、アクセスログも別途設計する必要があります。
導入時に考えるべきKMS設計
顧客管理キーを導入する場合、単にキーを作成して指定するだけでは不十分です。少なくとも次の観点を整理します。
1. 専用キーか共用キーか
Transcribe専用のKMSキーを用意するか、複数のAWSサービスで共用するかを決めます。
専用キーには、次のような利点があります。
- キー利用者をTranscribe関連の主体に絞りやすい
- CloudTrailの利用履歴をサービス単位で確認しやすい
- 障害や権限変更の影響範囲を限定しやすい
- コンプライアンス上の説明がしやすい
一方、キーを増やすほど、権限管理やローテーション、廃止手順の運用負荷は高くなります。アカウント構成やデータ分類に応じて、専用化と運用コストのバランスを取ることが重要です。
2. IAMポリシーとキーポリシーの整合性
AWS KMSでは、IAMポリシーだけでなく、KMSキーのキーポリシーもアクセス制御に関係します。Transcribeのリソースを作成・更新・利用する実行ロールや運用担当者について、次の点を整理します。
- KMSキーを利用できるIAMロール
- Transcribeのカスタムリソースを操作できる主体
- 暗号化や復号に関係するサービスアクセス
- 管理者と利用者で分離すべき権限
- 本番環境と開発環境のキー境界
特に、KMSキーの管理権限と暗号化データを利用する権限は分離するのが基本です。アプリケーション実行ロールにキー管理権限まで与えるのではなく、鍵の管理者、デプロイ用ロール、実行用ロールを分けると、権限侵害時の影響を抑えやすくなります。
Transcribeがキーを利用するために必要なサービス側の権限も、過度に広くせず、対象キーや対象リソースを限定する設計が適しています。実際のアクション名やプリンシパルは利用するAPI、リージョン、構成によって異なるため、導入時はAmazon TranscribeとAWS KMSの公式ドキュメントに沿ってポリシーを構成します。
CloudTrailでキー利用を監査する
顧客管理KMSキーの利用はAWS CloudTrailで記録されます。これにより、キーがいつ、どの主体から利用されたかを監査できます。
監査・運用では、次のような観点でログを確認します。
- 想定したAWSサービスやIAMロールだけがキーを利用しているか
- 本番用キーが開発環境から利用されていないか
- 通常と異なる時間帯や頻度でキーが利用されていないか
- 権限変更後に想定外の利用が発生していないか
- キーの無効化や設定変更が適切な承認を経ているか
CloudTrailのログをCloudWatch LogsやSIEMに集約すれば、KMS利用の異常検知やセキュリティ監視にもつなげられます。単にログを保存するだけでなく、誰が確認し、どの条件で通知するかまで決めておくと、監査証跡が実運用で役立ちます。
キーを無効化した場合の注意点
顧客管理キーを利用する最大のメリットの一つは、利用者自身がキーを無効化できることです。インシデント対応や契約終了時のアクセス遮断などに有効ですが、影響を理解せずに無効化すると、Transcribeのカスタムリソースを利用する処理が失敗する可能性があります。
キーを無効化する前に、次の事項を確認します。
- 対象キーを利用しているTranscribeリソース
- 本番ジョブやバッチ処理への影響
- 障害時にキーを再有効化する担当者と手順
- 代替キーへの移行計画
- 無効化の実施日時と承認記録
今回の機能では、リソースを別のキーへ移行する運用も可能です。ただし、キーの切り替えは権限変更やアプリケーションの実行状況と合わせて計画し、いきなり旧キーを無効化するのではなく、段階的に切り替えるのが安全です。
実務での導入手順
導入は次のような順序で進めると、既存システムへの影響を抑えられます。
- カスタム語彙、語彙フィルター、カスタム言語モデルの保護要件を分類する
- 対象リージョンとアカウントを決める
- 顧客管理の対称KMSキーを用意する
- キー管理者、デプロイ担当、実行ロールの責任範囲を分ける
- KMSキーポリシーとIAMポリシーを最小権限で設計する
- 非本番環境でカスタムリソースの作成、更新、利用を検証する
- CloudTrailでキー利用イベントを確認する
- 本番リソースを作成または更新し、監視と復旧手順を整備する
- キー無効化や切り替えを想定した訓練を行う
既存リソースについては、キーを指定しない限り従来のAWS所有キーによる暗号化が継続します。そのため、全環境を一度に変更するのではなく、規制対象のワークロードや新規作成分から段階的に適用する方法も取れます。
導入を優先すべきケース
次のような環境では、顧客管理KMSキーの導入効果が大きいと考えられます。
- 暗号鍵を自社アカウントで管理することが求められる
- 金融、医療、公共などの規制要件に対応する必要がある
- カスタム語彙やモデルに機密性の高い業務知識が含まれる
- キー利用の監査証跡を提出する必要がある
- 退職者や委託先などのアクセスを迅速に遮断したい
- 開発、本番、部門ごとに暗号化境界を分けたい
反対に、暗号鍵の個別管理が要件になっておらず、運用負荷を最小化したい場合は、AWS所有キーを使い続ける選択も合理的です。顧客管理キーは導入すれば必ず安全性が高まるというものではなく、正しい権限管理と運用監視が前提になります。
まとめ
Amazon Transcribeの今回の機能追加は、カスタム語彙やカスタム言語モデルなど、音声認識の品質を支えるリソースにも、利用者主体の鍵管理を適用できるようにするものです。
実務上のポイントは次のとおりです。
- 顧客管理KMSキーを指定した場合、鍵の権限とライフサイクルを自社で管理できる
- CloudTrailによりキー利用の監査証跡を取得できる
- キーを指定しなければ、既存どおりAWS所有キーが利用される
- キーの無効化や設定ミスは、Transcribeのリソース利用に影響する可能性がある
- IAM、KMSキーポリシー、CloudTrail、復旧手順を一体で設計する必要がある
まずは規制対象や機密性の高いカスタムリソースを対象に、専用キーと最小権限のポリシーを検証するのが現実的です。暗号化方式の変更だけで終わらせず、監査、鍵の切り替え、障害復旧まで含めて運用設計に組み込むことが、今回の機能を有効活用する鍵になります。
出典： AWS What’s New