この記事は公開されてから1年以上経過しています。情報が古い可能性がありますので、ご注意ください。
本ブログは2019年06月12〜14日に行われたAWS Summit Tokyo 2019のセッションレポートです。
『AWS環境におけるデータ保護の実装』のセッションを聴講したので内容をレポートしたいと思います。
AWS Summit Tokyo 2019 | 2019 年 6 月 12 (水) 〜14 (金) 幕張メッセで開催
セッション概要
当セッションの登壇者及び概要は以下の通りです。
アマゾン ウェブ サービス ジャパン株式会社 技術統括本部 ソリューションアーキテクト
能仁 信亮
アマゾン ウェブ サービス ジャパン株式会社 技術統括本部 ソリューションアーキテクト
保坂 匠
このセッションでは、AWS上で管理される重要データの保護を、AWSの各種サービスを活用して実現する方法を取り上げます。データストアの特性に応じたアクセス権限の管理、暗号化や暗号鍵の管理など、データ保護の個別の要素を取り上げるとともに、それらを組みあわせてデータ保護を実現する方法を具体例を交えてご紹介します。関連するサービスは、AWS IAM、AWS KMS, AWS CloudHSMなどです。
レポート
- セクション１
- AWS上のデータとリソースに対するアクセス権限
- セクション２
- AWS上における暗号化と鍵管理
- このセクションの目的：IDとアクセス管理
- データ保護に対する基本原則とアプローチを理解する
- 特にAWS上のデータとAWSリソースに対するアクセス管理の方法を理解する
- データ保護の基本原則とアプローチ
- 機密性、完全性、可用性
- データ保護の基本的なアプローチ
- データ特性の分析
- 脅威とリスクの分析
- データ保護の実装
- インフラセキュリティ
- IDとアクセス管理 ※今日話すこと
- データ暗号化 ※今日話すこと
- 不正なトラフィックの検出
- 統制のモニタリング
- AWSサービスを用いたデータ保護
- AWS Identity and Access Management(IAM)
- アイデンティティ（プリンシパル）
- AWS上で利用可能なアクターのアイデンティティ（ユーザー、ロール等）
- APIアクション
- プリンシパルがAWS APIコールによってリクエストしたアクション
- リソース
- APIアクションによって操作されるAWSサービスの対象
- コンディション
- 最小権限の原則
- 本当に必要な権限だけを定義する
- セキュリティのベストプラクティス
- IDと権限のライフサイクル管理
- データとAWSリソースに対するアクセス管理
- AWS CloudTrail: AWSリソースに対するアクティビティのロギング
- このIAMユーザーが
- この時刻に
- このAPIアクションを呼び出した
- このIPアドレスから
- このリソース名で
- ポリシーを用いたアクセス権限の実装例
- 典型的なデータアクセスパターン
- IAMポリシーによるアクセス制限の例
- どんな条件のときにどのS3APIアクションをそのIAMユーザー/ロールに許可するか？
- IAMの管理者がプリンシパルを中心に考えてアクセス権限を記述する
- ポリシー変数をタグ付けして利用しやすくする
- バケットポリシーによるアクセス制限の例
- どのIAMユーザー/ロールにそのS3バケットへのアクセスを許可するか？
- S3バケットの管理者がそのバケットを中心に考えてアクセス権限を記述する
- VPCeを用いたバケットポリシーによるアクセス制限の例
- VPCeポリシーによるアクセス制限の例
- そのVPCeを経由してきたとき、どのIAMユーザー/ロールに、どのS3バケットにアクセスを許可するか。
- データアクセスの権限を経路とポリシーで縛る + 暗号化
- クラウドでデータの統制を維持するために
- セクションのまとめ
- AWS IAMのポリシーを用いてデータアクセス権限の付与と条件を限定することができます
- データ及びデータを含むAWSリソースとでは認証と認可
- IDと権限のライフサイクル管理やAWSリソースに対するアクティビティ監視も重要なタスクです
- 暗号化と鍵管理： このセクションの目的
- AWSを利用する際の鍵管理の選択肢
- なぜ鍵管理が必要か
- 平文の鍵はどこかに存在し、管理が必要
- AWS環境で利用する暗号鍵の管理
- AWS KMS
- AWS CloudHSM
- オンプレミスのHSMなどの独自管理
- AWS環境での鍵管理の選択肢
- 構成
- KMS: マルチテナントのマネージドサービス
- CloudHSM: 排他的に制御できる専用のHSMをVPC内で直接利用
- AWSとの連携
- KMS: 50以上のサービスと連携
- CloudHSM: 限定的
- 鍵のアクセス管理方法
- KMS: AWS利用者が設定したAWSポリシー
- CloudHSM: HSMのアクセス管理機能
- AWS Key Management Service(AWS KMS)
- 暗号鍵の作成、管理、運用のためのサービス
- AWS KMSにおける暗号鍵のヒエラルキー
- 複数層の暗号鍵ヒエラルキー
- 個別のデータキーによるユーザーデータの暗号化
- AWS KMS マスター機によるデータキーの復号化
- Envelope Encryptionを利用
- AWS KMSのアーキテクチャ
- 暗号化キーのニーズに合わせて自動でスケール
- 複数のアベイラビリティゾーンによる高可用性
- CMKは高耐久、低レイテンシーのストレージに、暗号化された状態で保存し、99.999999999%の耐久性を実現
- 内部の通信はすべて暗号化されている
- 目的に応じたAWS KMSの構成や設定を知る
- 鍵のインポート - Bring Your Own Keys
- お客様所有のKMIで鍵を生成し、その鍵のコピーをAWS KMSにインポート
- インポートされた鍵は、AWS KMSで生成された
- BYOK利用時の考慮点
- インポートした鍵の自動ローテーションは不可。随時手動でローテーションする。
- インポート後はAWS KMS生成のCMKと同等の可用性であるが、耐久性は異なり、リージョン障害などの場合に自動復旧されない ｰ 有効期限が過ぎた鍵はKMSによって削除される。AWS KMS生成のCMKは７日〜３０日の待機時間があるのに対して、即時に削除。インポートの再実施で復旧可能。
- 上記の耐久性と削除（特にオペレーションミスの削除）の対応として、必ず保存しておく。
- AWS KMSカスタムキーストア
- Clients -> AWS KMS -> AWS CloudHSM
- KMSのCMKをCloudHSMで生成、保管可能に
- AWS KMSカスタムキーストアを利用するケース
- 前提： FIPS140-2検証済み暗号化モジュールによって保護されたデフォルトのAWS KMSキーストアで、多くの場合セキュリティ要求を満たす。
- カスタムキーストアの利用を検討するケース
- 鍵へのアクセス権限の管理
- AWSの各サービスのデータキーの利用方法
- EC2/EBSモデル
- KMSにより作成/複合されたリソースごとに一意なデータキーは、ハイパーバイザーの揮発性メモリにリソースがタッチされている限り保持される
- S3モデル
- KMSにより作成/複合されたデータキーは、APIトランザクションの間のみサービスの揮発性メモリに保持される
- AWS KMSの監査
- AWS CloudTrail: KMS APIアクセスの感作
- AWS KMSに対するAWS運用の例
- 平文のマスターキーには誰もアクセスできない
- このセクションのまとめ
- AWSを利用する際の鍵管理の選択肢とそれぞれの特徴を理解する
感想
AWSでは、データの保護はIAMを使って細かく制御、データ暗号化のための鍵はAWS KMSを使ってマネージドに管理することができることがよくわかりました。
他のセッションも聴講して引き続きセッションレポートを続けていきたいと思います。
0
