データレイクにおける権限制御 実践LakeFormation

2020 AWS データレイク事例祭りの登壇資料

Transcript

1. freee 株式会社
 データレイクにおける権限制御 実践LakeFormation 
 2020.11.18
2. 2019年5月 データエンジニアとして freeeに入社
 
 
 • 以前はAWS上のサーバ構築・保守を トータル5年
 ◦ いわゆるインフラ屋
 • 好きな言葉
 ◦ 大規模　安定稼働　ノーメンテ
 • データエンジニアのお仕事
 ◦ ETL処理の追加・保守
 ◦ データ利用・活用を推進する基盤づくり
 
 • 好きなAWSサービス
 S3
 
 
 Hisatoshi Imaoka 今岡 久敏
 freee株式会社 データエンジニア
 2
3. 3
 スモールビジネスを、
 世界の主役に。
 MISSION
 生産年齢人口が劇的に減少し、慢性的な人手不足となる日本で 労働生産性向上は緊急の課題となっています freeeは「人工知能」と「統合基幹業務システム」をクラウド技術を 活用し、業務効率化のサポートを続けることで、中堅中小企業の バックオフィス業務効率化を目指しています
4. スモールビジネス向けに統合型クラウドERPを提供
 
 * 2017年8月より、クラウド給与計算ソフト freeeは、機能を強化し、「人事労務 freee」というサービス名に変更しました。
 2013.3リリース
 2014.5リリース
 2015.6リリース
 中小企業の経理業務を効率化。帳 簿や決算書作成、請求業務に対 応。
 給与計算や年末調整、入社手続き から勤怠管理まで労務管理を大幅 に効率化。
 会社設立に必要な書類を5分で作 成できる無料サービス。
 2015.9リリース 低コストでマイナンバーの収集、管理、破 棄までクラウド上で完結。
 2020.4リリース プロジェクト型ビジネス向けに、作業工 数の入力が素早く簡単に行え、プロ ジェクトの収支管理ができるサービス
 2016.10リリース 2020.8リリース 2020.6リリース(β版) 2017.1リリース 個人事業の開業手続きが無料、簡単、最 速で完了する。
 税務申告書作成業務を効率化。法人 税・消費税・法定調書・申請届出や電 子申告にも対応。
 Webで申し込みでき、最短4営業日で発行。創業 時でも本人確認書類だけで審査可能。
 中小企業と個人事業主を対象とした利用可能性の高 い資金調達手段を検索・比較して申込ができるオンラ イン資金調達プラットフォーム。
 福利厚生制度の導入に係るバックオフィス業務を 効率化。
 2020年8月の第一弾では 「借り上げ社宅運営サー ビス」β版を提供開始。

5. 5 本日お話する内容
 freee版データレイクの歴史
 • Glue Data Catalogの活用
 • データレイク運用後の新たな課題
 
 LakeFormationによるアクセス権限制御の手法
 • LakeFormationで実装できるアクセス権限制御とその利点
 
 LakeFormation実践と移行作業
 • freeeにおける導入までのシナリオ
 
 マルチアカウントとLakeFormation
 
 

6. 01 freee版データレイクの歴史
 6 Section
7. 7 freee版 データレイクの歴史 (Gen 1)
 いわゆるバッチサーバ + Redshift のみのシンプルな構成

8. 8 freee版 データレイクの歴史 (Gen 2)
 Gen1 に加えて Athena向け ETL処理を追加

9. 9 freee版 データレイクの歴史 (Gen 3)
 Glue による ETL データパイプライン + Redshift Spectrum が主役に
 データレイクの受け皿となるS3に、全データをParquetファイルで保存

10. 10 Glue DataCatalog と データレイク
 Glue DataCatalog の利点
 Athena / Redshift Spectrum を利用する = Glue DataCatalog を使っている
 ⇒ だけだどモッタイナイ
 
 Glue Crawler によるスキーマ変更の自動追従
 freee では 大部分のGlue ETL処理 でデータソースのスキーマをそのまま出力する
 ⇒ スキーマ変更が頻繁に起こる 
 ⇒ DataCatalog (Schema)を頻繁に書き換える必要がある ⇒ クローラで楽する
 ただし、スキーマ変更が発生しないものは、Add Partition 文を発行で使い分け
 
 EMRからも利用出来る
 EMR(Presto) から Glue DataCatalogを参照出来る
 ⇒ Athenaの不満(処理の安定性)を Presto等で解消
 ⇒ hadoopつよつよの人も満足
 
 LakeFormationによるアクセス権限の制御

11. 11 データレイク データ格納方式
 S3上にHIVE_Partition + Parquet 形式でファイルを格納する
 • 圧縮効率 & 実行速度ともにバランスよし
 • 対応しているエコシステム・プラットフォームが多い
 ◦ ファイルフォーマットはORCでもOK
 ◦ S3 select が Parquet 対応
 

12. 12 おすすめのファイルレイアウト
 s3://[s3_bucket名]/[DB名]/[Table名]/[(partition key=val)]/*parquet
 s3://[s3bucket名]/[DB名]/ をターゲットにしてクローラを回すと、全テーブルを登録・更新 可能
 
 [注意] DB以下にTableが2つ以上ある状態でクローラを回すこと 下図のような状態でクローラ を回して、狙い通りの結果にならない場合は、Table_B を追加する
 

13. 13 データレイクの成長と新たな課題
 Glue ETLパイプラインの高速化のおかげで
 今までとは比べ物にならない多種多様なデータがGlue DataCatalogに登録された
 データを集めてカタログに格納するという第一段階には到達した
 
 しかし
 データ種類が増えたため、今まで以上にデータへのアクセス権限の制御が多様化し管理コス トが増大
 利用者のロールも・各ロールが必要とするテーブルもさまざま、しかもテーブルは増え続ける

14. 14 従来型のアクセス権限制御の問題点
 巨大なデータレイク上のデータの中で「だれが・どの」テーブルにアクセス出来るかを制御す る方法が直感的でなく、ルールが複雑・肥大化する
 
 Athena上のデータアクセス制御するには2つ方法がある
 
 • S3の GetObject を IAM Role(User)ごとに絞り込む
 • Glue DataCatalog の GetTable(s) / GetPartition(s) に対するリソース制限(テーブルレベ ル) を IAM Role(User)ごとに絞り込む
 
 これを IAM Policy で表現するとなると...
 
 ルールが複雑化し、PolicyDocumentが肥大化、メンテナンスは非現実的
 • ユーザーのIAM Roleは Athena以外の権限も付与することがほとんど
 • 1管理Policy 当たりの文字数制限あり 6144文字
 • データのアクセス許可は IAM Policyから分離したい
 ◦ Athenaに限ると 対S3は calledvia conditions 設定で簡素化できるが。。

15. 15 データレイクの成長と新たな課題
 データが増えれば、利用するユーザーも増える
 これからはよりスケールを意識した設計を

16. 02 LakeFormationによるアクセス権限 制御の手法
 16 Section
17. 17 LakeFormationとは？
 データレイク構築のための一連タスクをまとめた BluePrint
 Crawler / ETL / Data Catalog は Glueの機能
 　=> freeeでは ETL処理 & データカタログに格納するまですでに構築済みだったので、 Securty settings / Access control の部分のみを導入

18. 18 導入のメリット
 利用者視点
 • 利用者側からは何の変更もない
 ◦ SQLの書き換え等不要
 • 参照権限のあるテーブル・カラムのみDescribe出来る
 
 管理者視点
 • RDBMSの Grant/Revokeとほぼ同じ感覚でアクセス権限管理
 ◦ カラムレベルでアクセス許可
 • AWS APIで制御できる
 ◦ コード化、CI/CD化しやすい
 • 監査ログ
 ◦ AthenaはSQLログ
 ◦ LakeFormationはSQLログではなく、どのGlueCatalog上のテーブルへのアクセスかを記 録する

19. 19 利用者視点での挙動
 ユーザーロール毎に参照できるテーブル・カラムが異なる
 API GetTable(s) を Callした時点で、そのユーザーが参照可能なものだけリターン
 ⇒ API Callを Hook(横取り) したような挙動
 ユーザーロールにはS3へのアクセス権限付与は不要
 S3へのアクセスは LakeFormationServiceRoleにて実行される
 
 IdPと紐付いた IAM Role
 Principal = IAM Role ごとに
 カラムレベルまでの詳細なアクセ ス許可設定が可能

20. 20 カラムレベルでの制限のメリット
 LakeFormation無しで真面目に実装しようとすると
 
 全カラムのTable_A と カラムを絞った Table_A’ をパイプラインで生成
 別のチーム向けのカラム制限が必要になったら Table_A’’ を作成
 また別のチーム向け … Table_A’’’ を作成
 
 それらにアクセスを付与する IAM Policyを追加・修正
 ⇒ 普通は辛すぎてやりません
 
 LakeFormationならアクセス許可設定を書き換えるだけで実現出来る
 データエンジニアとしてはこの点が一番のモチベーション

21. 03 LakeFormation実践と移行作業
 21 Section
22. 22 LakeFormation導入前の構成
 • S3 bucket単位でアクセス制限をかけていた
 • S3上のテーブルが少ないときはそれで十分だった
 • Glue化によるデータパイプライン高速化で対象バケットのテーブルが爆増
 • 増えたはいいが、ほとんどは使わないデータ
 ⇒ 権限過剰な状態

23. 23 LakeFormation導入後の構成
 データアクセスの許可設定は LakeFormationのアクセス許可設定(DataPermissions)へ移動
 ⇒ 権限過剰の解消 + カラムレベルでのアクセス許可も可能に
 

24. 24 LakeFormationへの移行ステップ
 1. 監査ログを元にLakeFormationアクセス許可設定を作成する
 全TableアクセスNGでは業務が止まる
 参照したいテーブル教えては現実味ないので実績から作成
 2. 設定ファイルのコード化ツールの作成
 テーブルが増える・ユーザーも増える・設定ファイルも太る
 3. 社内の承認フロー整備
 秘匿性の高いデータをLakeFormationで管理するため
 4. 移行作業実施
 実際のAWS上のシステム的な作業

25. 25 監査ログを元にアクセス許可設定を作成する
 CloudTrailの監査ログ(glue + athena)を参照して、各ロールのユーザーがどのテーブル・カラ ムを参照しているかを調査し、それを元にアクセス許可設定を作成する。
 GlueのGetTables API Callを追いかけるのがおすすめ

26. 26 設定ファイルのコード化ツールの作成
 設定ファイルをコード化したい = 設定内容及び変更履歴をトレース可能にする
 誰が・どのテーブル・カラムを参照できるのか？
 それが反映されたのはいつ？
 
 AWS APIとしても 現状の設定に応じて Grant/Revokeする対象を出し分ける必要がある
 常に Grant Permissionsで設定上書きとならない
 現状ではterraform非対応
 CFnは対応しているので、CFnで良いかも?(ただしfreeeでは未検証)
 
 CI/CDで設定反映出来るようにする
 GitHub Flowで 設定反映まで出来るように
 

27. 27 社内の承認フロー整備
 LakeFormation 設定ファイルの変更PRを作成 CIがまわり、現行設定との差分を表示 (terraform plan 同等) データエンジニアによるレビュー カラムの有無など技術的なチェック PR作成者のマネージャ(上長)によるレビュー 申請理由とリスクの妥当性をチェック 設定変更の反映 (terraform apply 同等) セキュリティー・監査チーム 運用が適切であるかを巡回チェック
28. 28 LakeFormationへの移行作業
 詳細手順は割愛します
 https://docs.aws.amazon.com/ja_jp/lake-formation/latest/dg/upgrade-glue-lake-formatio n.html 設定の状態確認と、注意点のみ説明します
 
 IAMによる制限をそのままLakeFromationへマイグレーションを想定して書かれている点は異 なります

29. 29 対象テーブルがLakeFormationの管轄か否か
 対象テーブルがLakeFormation管轄とするには
 Glue Catalog 上の Location (s3 path) を DataLakeLocationに登録する
 Glue GetTableの戻りに "IsRegisteredWithLakeFormation": true がある
 ⇒ LakeFormation専用のカタログが Glueカタログとは別にあるわけではない
 　 ⇒ アクセス許可設定 誰(=principal) が 何(=db/table/column) に どう(select/update等) で きるかをLakeFormationが持っている = LakeFormationのアクセス許可
 
 
 
 $ aws glue get-table --database-name world --name city { "Table": { "Name": "city", "DatabaseName": "world", ….. "CreatedBy": "arn:aws:sts::1111111111:assumed-rol/exxxxxx", "IsRegisteredWithLakeFormation": true } } 

30. 30 IAMAllowedPrincipals
 既存のGlueカタログ上の各データベース/テーブルには 互換性のための IAMAllowedPrincipalsが予め登録されている
 ⇒ 従来型の IAM Policyによる制限はこれで実現されている
 デフォルトで IAMAllowdPrincipalsをつける・つけないをの設定変更可能
 ⇒ 今後作成されるDB/テーブルのLakeFormationアクセス許可に追加される
 
 
 今後作成されるDBにはすべて IAMAllowdPrincipalsが付く 
 今後作成されるテーブルにはすべて IAMAllowdPrincipalsが付く 
 今後作成されるこのDBのテーブルにはすべて IAMAllowdPrincipalsが付く 
 上記の LakeFormation全体設定と矛盾していてもOK、DB個別で設定可能 

31. 31 IAMとLakeFormationの関係
 https://docs.aws.amazon.com/lake-formation/latest/dg/access-control-fine-grained.html
 LakeFormation使うなら IAM は荒く設定し、LakeFormationで細かく設定する
 　⇒ IAM側では GetTable等をリソース縛りしないがよい
 
 IAMで GetTable(s) でリソース(テーブルA)のみに限定した状態
 • LakeFormation側で別リソース(テーブルB)を許可しても無視される
 ⇒ ユーザー側からみたらGetTable(s)のAPI Callは変わらない、IAMの時点でテーブルAの みに制限されているから、テーブルBへはIAMの時点で蹴られる
 • LakeFormation側で同リソース(テーブルA)にカラム制限をした場合はカラム制限が効く(狙 い通り)
 • テーブルAに対してLakeFormationでカラム制限 + IAMAllowdPrincipals 両方が設定されて いる場合は、テーブルAにアクセスできるがカラム制限は無視される

32. 32 IAMAllowdPrincipalsの作用
 LakeFormation管轄がNo (1,2) ならばLakeFormationのアクセス許可は無視される
 LakeFormation管轄がNo + IAMAllowdPrincipalsもNo (1) ならば 誰もアクセスできない
 LakeFormation管轄がYes + IAMAllowdPrincipalsもYes + LakeFormationのアクセス許可も Yes (6) なら ば IAMAllowdPrincipalsが勝つ
 ID
 LakeFormation管轄 
 IAMAllowdPrincipals 
 LakeFormationのアクセス許可 
 影響
 1
 No
 No
 Any
 誰もアクセスできなくなる
 2
 No
 Yes
 Any
 LakeFormation利用前の デフォルトの状態
 IAM による制御
 3
 Yes
 No
 No
 誰もアクセスできなくなる
 4
 Yes
 No
 Yes
 LakeFormationアクセス許可が有効
 5
 Yes
 Yes
 No
 Glue Catalog は IAM による制御
 S3 は LakeFormationServiceRoleでアクセス
 6
 Yes
 Yes
 Yes
 Glue Catalog は IAM による制御
 S3 は LakeFormationServiceRoleでアクセス
 *IAMAllowdPrincipals=No とは、LakeFormationアクセス許可にエントリが無いという意味

33. 33 移行手順とアクセス可否の状態
 初期状態 (2)
 LakeFormation管轄にしただけの状態 (5) 
 LakeFormationのアクセス許可設定を各Principalに追加して (6) の状態となる
 ⇒この時点ではまだ IAMによる制御から変わっていない
 LakeFormation管轄の 各DB/テーブルから IAMAllowedPrincipalを削除 (4)
 ⇒ LakeFormationアクセス許可のみが有効になり、移行完了
 
 ID
 LakeFormation管轄 
 IAMAllowdPrincipals 
 LakeFormationのアクセス許可 
 影響
 1
 No
 No
 Any
 誰もアクセスできなくなる
 2
 No
 Yes
 Any
 LakeFormation利用前の デフォルトの状態
 IAM による制御
 3
 Yes
 No
 No
 誰もアクセスできなくなる
 4
 Yes
 No
 Yes
 LakeFormationアクセス許可が有効
 5
 Yes
 Yes
 No
 Glue Catalog は IAM による制御
 S3 は LakeFormationServiceRoleでアクセス
 6
 Yes
 Yes
 Yes
 Glue Catalog は IAM による制御
 S3 は LakeFormationServiceRoleでアクセス

34. 34 切り戻しとアクセス可否の状態
 移行完了後の状態 (4)
 IAMAllowdPrincipalsを復元 (6)
 LakeFormation管轄をやめる (2) LakeFormationのアクセス許可は残してもOK
 
 IAMAllowdPrincipalsを各テーブル毎につけたり外したりはToolで
 https://github.com/aws-samples/aws-glue-samples/tree/master/utilities/use_only_IAM_access_controls 
 
 
 ID
 LakeFormation管轄 
 IAMAllowdPrincipals 
 LakeFormationのアクセス許可 
 影響
 1
 No
 No
 Any
 誰もアクセスできなくなる
 2
 No
 Yes
 Any
 LakeFormation利用前の デフォルトの状態
 IAM による制御
 3
 Yes
 No
 No
 誰もアクセスできなくなる
 4
 Yes
 No
 Yes
 LakeFormationアクセス許可が有効
 5
 Yes
 Yes
 No
 Glue Catalog は IAM による制御
 S3 は LakeFormationServiceRoleでアクセス
 6
 Yes
 Yes
 Yes
 Glue Catalog は IAM による制御
 S3 は LakeFormationServiceRoleでアクセス

35. 35 導入に向けて tips
 すでにデータレイクに無数のデータがある場合は、少しずつLakeFormation管轄にしていく
 アクセス許可設定ファイルの管理が大変です、場合によっては生成ツールが必要
 
 まず監査ログ / CloudTrailを有効にする
 万が一設定ミスしても、監査ログがないと異常検知/追跡ができない
 いきなりガチガチのアクセス許可設定は非現実的、ユーザーの利便性も下がる
 監査ログによるアクセス実績に基づき設定ファイルを作る
 
 設定ファイルのコード化をする
 ManagementConsoleによる設定はデータベース・テーブル数が増えるとすぐに破綻
 何時でもリストア出来るように
 LakeFormation自体の進化が早いので、目的が果たせるならば自作ToolよりもCFn

36. 04 マルチアカウントとLakeFormation
 36 Section
37. 37 マルチアカウントとLakeFormation
 • 分析したいデータが複数AWSアカウントにまたがっている
 
 • アカウントAとアカウントBのデータをJOINしたい
 ◦ かつアクセス許可設定も適切に管理したい
 
 • LakeFormationの設定ファイルをアカウント毎に準備するの辛い
 
 • カタログをアカウント間で共有し、共有したカタログに対してLakeFormation
 

38. 38 カタログ統合 & アクセス1本化 パターン
 LakeFormation アクセス許可設定は一箇所に統合
 DataCatalogも一箇所に統合 クロスアカウントアクセスで クローラで登録
 ユーザーロールも1アカウントで集中管理
 

39. 39 カタログシェア パターン (最近のUpdate)
 別アカウントのカタログを共有・参照する事が可能
 データレイクアカウント側からクローラを回す必要がない
 DataCatalogの二重管理がなくなる

40. 40 マルチアカウント運用時のtips
 利便性と社内セキュリティーポリシーのすり合わせ必須
 マルチアカウントにおけるLakeFormation導入はユーザー利便性を向上させるが
 アカウント分割を選択したセキュリティーポリシーと乖離がないか確認が必要
 ⇒ データの分離がアカウント分割の目的であれば、NGとなるかも
 
 アクセス許可の管理は1アカウントで行うのが理想
 アカウント毎に管理すると、全容を把握するのが難しくなる
 ⇒ 二重管理の可能性 (アカウント A/B 両方に同じクロスアカウントアクセス可能な Role がある等)
 
 採用する機能を理解・取捨選択し、将来の拡張性を見越しておく
 利便性向上・管理コスト低下という利点と、相対的なセキュリティー低下のバランス
 ⇒ 監査ログ(SQLやAssumeRole履歴)が取れていればOKなど

41. スモールビジネスを、
 世界の主役に。