この記事は公開されてから1年以上経過しています。情報が古い可能性がありますので、ご注意ください。
はじめに
ANT327 - Best Practices to Secure Data Lake on AWS のセッションのレポートとなります。データレイクのセキュリティに関して包括的にまとめられています。
セッション概要
As customers are looking to build Data lakes to AWS, managing security, catalog and data quality becomes a challenge. Once data is put on Amazon S3, there are multiple processing engines to access it. This could be either through a SQL interface, programmatic, or using API. Customers require federated access to their data with strong controls around Authentication, Authorization, Encryption, and Audit. In this session, we explore the major AWS analytics services and platforms that customers can use to access data in the data Lake and provide best practices on securing them.
顧客がAWSへのデータレイクを構築しようとしているので、セキュリティ、カタログ、データ品質の管理が課題になります。 データがAmazon S3に置かれると、それにアクセスする複数の処理エンジンがあります。 これは、SQLインターフェイス、プログラム、またはAPIを使用して行うことができます。 顧客は、認証、認可、暗号化、および監査に関する強力な制御を使用して、データへのフェデレーションアクセスを要求します。 このセッションでは、顧客がデータレイクのデータにアクセスしてそれらを保護するためのベストプラクティスを提供するために使用できる主要なAWS分析サービスとプラットフォームについて説明します。
スピーカー
このセッションで話すこと
- 誰もが知りたいAWSにおけるセキュアなデータレイクの構築
データレイクとは？
- スケールとコストを問わず、すべてのデータを収集・保存する
- データの検索、作成、セキュアを手助けします
- 組織内のデータへ誰もが利用可能なアクセスを提供する
- 迅速かつ容易に新しいタイプのデータ分析を実行する
データレイクの主なコンポーネント
現在のデータアーキテクチャの要件、データレイクの構成要素、データレイクアーキテクチャ（セキュリティを除く）
主なコンポーネントは、Storage, Metadata/Catalog, Computeの３つに分類します。
- ストレージ
- オブジェクトストレージ(S3, Glacier)
- ブロックストレージ(EBS)
- ファイルストレージ(EFS)
- インスタンスのストレージ(EC2, Redshift)
- Catalog/Metastore
- 自動的にデータをインデックスして、タグやビジネス要件に応じて簡単に検索できるようにする
- キュレーション（収集、整理、共有）と関連性スコアを割り当てる
- データセットの容易な圧縮・展開
- キャプチャデータの直列化
- Compute
- サーバーによる処理(EC2, EMR, Redshift)
- サーバレス(Lambda, Athena, API Gateway等)
- ハイブリッド(Redshift Spectrum)
※ Amazon KinesisやAmazon DynamoDBなどのサービスについても上記に加えるか、検討の余地があります。
AWSにおけるデータレイクの構築
AWSでは、セキュアで低コストなS3をハブストレージとしてデータレイクを構成します。
セキュアなデータレイクに何が必要か？
データレイクにおけるセキュリティの課題
- データの課題
- データへのアクセスの制御（データマスキング、行/列/セルレベル暗号化、鍵管理）
- データの損失/除外
- データの完全性の喪失
- データの出所
- コンプライアンス要件（GDPRなど）
- 経営課題
- 中央管理
- フェデレーション認証、通常はActive Directory
- 役割ベースのアクセス制御（RBAC）
- 集中監査
- エンドツーエンドのデータ保護（保管および転送中）
責任共有モデル
AWSと利用者が連携してセキュリティの維持向上に取り組む「責任共有モデル」がサービスの種類ごとに用意されています。
- インフラストラクチャサービス(EC2, EBS)
- コンテナサービス(EMR, RDS, Redshift)
- 抽象化サービス(S3, DynamoDB, Athena, Glue)
基礎から始めよう
AWSはセキュリティ保護に役立ちます
顧客は、データレイクを保護するために、複数のレベルのセキュリティー、IAM、暗号化、コンプライアンスに準拠する必要があります。
「粗い」所有権を優先する
- チームはAmazon S3のバケットとクラスタ全体を所有しています
- AWSアカウントによって分離された所有権
- セットアップと保守が容易なアクセスコントロール
- 自律型チームに適しています
安心してデータを暗号化する
Amazon S3オブジェクトの暗号化モードを選択する
コンプライアンス：すべてのAWSアクティビティのログと監査
- すべてのアカウントアクティビティとAPIコールをAmazon CloudTrailでログに記録し、継続的に監視する
- ユーザーとリソースのアクティビティの可視性を高める
- ログ管理とデータイベントを別々の監査に記録する
- ログを別のセキュリティアカウントに集中する
- IAMを使用してS3削除を無効にする
クラウド内のセキュリティ - 基本
- アカウント
- Active Directory /アイデンティティプロバイダとのフェデレーションアカウント
- 多要素認証（MFA）の設定する
- rootアカウントのクレデンシャルの使用を避ける
- IAMアクセスは最小限の特権にする
- ネットワーク
- プライベートVPCサブネット
- VPCエンドポイント/インターフェイスエンドポイント
- セキュリティグループは最小の権限を付与する
- ストレージ
- KMSを使用して暗号化する
データフロー
アナリスト、データエンジニア、データサイエンティスト、セキュリティ管理者、データキュレイター（データの保管・収集）など様々なタイプのロールが存在します。
- すべてのロールには、データワークフロー全体の各フェーズに対応するアクションと責任があります
- プロデューサーとカスタマーの要件でデータレイクを考える
2018年までに、データレイクの80％に効果的なメタデータ管理機能が含まれないため、効率的ではありません。
- ガートナー
そこで、AWSでは、新たに連携されたデータは、S3上のデータGlueでクロールして、データセット定義をデータカタログに登録できます。データカタログに登録されたデータセットは、Athena、Redshift（Spectrum）からクエリしたり、Quicksightによる可視化、SageMakerやDeep Learing AMIによって機械学習に利用できます。
セキュリティ管理
セキュリティ管理タスク
- セキュリティガードレールの用意
- プリエンプティブかつ検知コントロール
- チーム/環境間のデータアクセスを提供する
- データ分類に基づいてセキュリティ要件を検証する
- データオーナー/プロデューサがアクセスを許可していることを確認する
- 定期的な監査を実行する
Amazon S3 - プリエンプティブコントロール
- ビジネスドメインに基づいてバケットを作成する
- バケットポリシーを割り当てる
- VPC、HTTPS、IPフィルタ、KMSキーで制限する
- Tags/Conditionsを使用して制限する
- "Condition":{"StringEquals":{"S3:ResourceTag / HIPAA":"True"}
- "Condition":{"StringEquals":{"aws:UserAgent":"AWS Redshift / Spectrum"}
- 暗号化を有効にする/versioningを有効にする
- MFA delete
- バックアップを有効にする(アカウント/リージョン間)
- IAM permission boundary
- S3 public access setting [NEW!]
Amazon S3データ - 検出コントロール
- AWS Configを有効にして、S3バケットレベルの変更を検出する
- s3-bucket-public-read-prohibited、s3-bucket-public-write-prohibited、s3-bucket-ssl-requests-only
- CloudTrailを使用したS3データアクセス監査、CloudWatchログを分離するためのログ
- Kerberos対応のEMRクラスタを使用すると、ADユーザーを追跡できる
- Amazon GuardDutyを使用して、権限のない予期しない活動を検出する
- Amazon Macieが機密データを分類できるようにする
転送中の暗号化データ
Point "A"からPoint "B"にネットワークを介してデータ転送する際にデータがどのように暗号化されているかを示します。
セキュリティ認可の流れ
左から右に認可されてデータへアクセスします。AD認証したユーザーが所属するグループに対応付けられるIAM Roleによって、それぞれのAWSリソースにアクセスします。
カスタマシナリオの検討
テーブルの関連から利用者のタイプに分類して、利用者のタイプ別にアクセス要件を整理します。新しいデータの連携のワークフローは以下のとおりです。
ロールベースのタスクは、利用者のタイプごとにロールを割り当て、役割とアクセス要件を定義します。例えば、 データエンジニアのデータ/カタログアクセスの許可は以下のとおりです。
データパイプラインの構築
Amazon EMR
認証
- クラスタ認証用にKerberosを構成する
- HiveServer2、Hue、Presto、ZeppelinのLDAP
- Apache Knoxを使用した境界セキュリティ
ストレージ認証
- ユーザーのADグループに基づいてAmazon S3へのアクセスを制御する
- Amazon S3へのEMRFS要求に対して異なるIAMロールを使用する
- これらのIAMの役割は、Amazon S3のユーザー、グループ、またはデータの場所にマッピングできる
サービス認証
- Apache Rangerは、Hadoopクラスタサービスの認可・監査を提供する
- 例：Hiveテーブル、HDFSファイル、HBaseなど
- Hiveの列のマスキングと行フィルタリング
ベストプラクティス - Amazon EMR セキュリティ
Amazon Athena と Amazon Quicksight
データの準備
- キュレイター（保管・収集）
- ステージングカタログに登録されているデータを検証する
- 健全性チェックを実行する
- データセットを本番のカタログにコミッションする
- フィルタしたいビューを作成する
- セキュリティ管理者
- アナリストへのアクセスを有効にする
- 行レベルのセキュリティを設定する
- アナリスト
- ダッシュボードを作成して公開する
Amazon Athena のセキュアなデータフロー
ベストプラクティス - Amazon Athena セキュリティ
Amazon Quicksight のセキュアなデータフロー
パワーユーザーと作成者に管理するデータに対してセルフサービス分析を実行する柔軟性を提供する次のようなデータセットを作成します。
- 任意のユーザーと共有することができるようにする
- 自動リフレッシュ
- 行レベルのセキュリティを確保する
- ユーザーは変更できない
- 変更を動的に更新する
ベストプラクティス - Amazon Quicksight セキュリティ
Amazon Redshift
利用者はIDP経由で認証してRedshiftに接続することも可能です。Redshift Spectrumは、Redshiftに付与されたIAMロールでGlue利用したり、S3にアクセスします。
ベストプラクティス - Amazon Redshift セキュリティ
Amazon Sagemaker
予測モデルの構築では、SagemakerのnotebookがS3やデータカタログにアクセスします。同様に、notebookからEMR（のSpark）と連携してデータにアクセスすることも可能です。
ベストプラクティス - Amazon Sagemaker セキュリティ
Amazon.com によるデータレイクとアナリティクスの活用
- DynamoDBは Amazon.comトランザクションをすべてキャプチャする
- DynamoDB、RDS PostgreSQL、KinesisのすべてがAmazon S3データレイクに送られた
- AWS Glueはデータをカタログ化するために使用される
- Amazon RedshiftはすべてのSQLベースのクエリに使用され、Amazon EMRはすべての機械学習および大規模なデータ処理に使用される
- エンドユーザーはAmazon QuickSightを使用して視覚化する
サマリ
- フェデレーションアクセスを用いる
- 組織内の役割と責任マトリックスを設定する
- 集中型データカタログを活用する
- プリエンプティブコントロールと検知コントロールの両方を使用する
- 定期的な監査を実施する
- ストレージ、カタログ、および処理レイヤを保護する
- カタログにデータセットを登録する者を奨励する
- データプロデューサとデータコンシューマ間のプロセスを合理化する
最後に
これまでここまで包括的かつ簡潔にまとめられたドキュメントは見たことなく丸暗記しても良いレベルです。具体的な設定例やコードはにつきましては資料を御覧ください。現在のAWSサービスとエコシステムを活用することでデータレイクセキュリティを確保できますが、一方で「粗い」所有権を優先するとあるように、あとでセキュリティ要件をプラガブルに追加できるためにもシンプルであることが大切ではないかと考えています。本セッション最後のベストプラクティスに従い、セキュリティ要件に応じで認証・認可の仕組みを選択してください。
合わせて読みたい
ANT396 : [NEW LAUNCH!] AWS Lake Formation の紹介 – セキュアなデータレイクを構築する #reinvent
24
