こんにちは、データエンジニアの中村です。
新卒で入社してから、気づけば2年が経とうとしています。時間の流れは本当に早いものですね。
今回は、私がこれまで取り組んできたデータ基盤におけるアクセス制御に関する技術と取り組みについてお話ししようと思います。
昨日に引き続きデータ基盤関連の記事になりますが、ぜひ最後までご覧ください！
この記事はEnigmo Advent Calendar 2024 の20日目の記事です。
目次
背景
弊社のデータ基盤はBigQueryを利用しており、社内の個人ユーザーやサービスアカウント経由での各種サービスからアクセスがあります。
データの種類によってはユーザー・グループ毎にカラムレベルでアクセスを制御したいケースが発生することがありました。
以前は、通常のviewと特定のグループに見せたくないカラムをexceptしたviewの二つを作成し管理していました。
シンプルな構成で直感的に理解しやすいのでこのままでも良さそうでしたが、特定のカラムが閲覧不可のグループから要望があるたびにViewを用意する必要があるので、要望が多いと対応が大変になってしまいます。
その課題を解決するために、BigQueryのポリシータグという機能を利用してアクセス制御を行おうと考えました。
ポリシータグとは
ポリシータグは、BigQuery上のテーブルで、列レベルでのアクセス制御を可能にするタグ機能のことです。
以下はBigQuery上で実際にポリシータグを設定した時の画像です。アクセス制御したいカラムに対して、作成したポリシータグを紐づけることでカラム単位でのアクセス制御が可能となります。
ポリシータグの利用イメージ
イメージを以下に示しました。
ざっくり言うと
ポリシータグを作成→ポリシータグに対して権限周りの設定をゴニョゴニョ→アクセス制御したい列に対してポリシータグを設定→アクセス制御したい列の見え方がユーザーによって変わる
といった具合です。
ここで重要なのが、「同じテーブルを見ているのにユーザーによって見え方が変わる」ということです。
これまでは閲覧権限のないカラムをexceptしたviewを作って権限管理していましたが、ポリシータグによって１つのテーブルでそれぞれの閲覧権限に応じて閲覧可能なカラムのみ見せられるようになりました。
現時点ではまだ移行途中ですが、最終的には図1から図4へ完全移行を考えております。
それでは、どのようにして見え方を変えているのかを説明していこうと思います。
ポリシータグによるアクセス制御の仕組み
ポリシータグの挙動を理解する上で重要なのが以下のロールです。
1. roles/datacatalog.categoryFineGrainedReader (きめ細かい読み取り) 2. roles/bigquerydatapolicy.maskedReader (マスクされたデータの読み取り)
名前からある程度想像がつきますね。
1は「ポリシータグが付与されていても、データをそのまま見れる」ロールで、2は「ポリシータグが付与されている場合、データをマスクされた状態で閲覧できる」ロールです。
この二つのロールを利用してアクセス制御を行います。
ポリシータグを作成図3①して、ポリシータグをテーブルへ設定図3⑤するだけだと、どちらのグループも権限エラーでクエリすらできません。
まずは閲覧可能グループの場合ですが、1のロールを付与したIAMポリシーをポリシータグへbinding図3②します。そうすると、閲覧可能グループがクエリしてもポリシータグが付与されているカラムはそのままの状態で閲覧できる状態になります。
次に、閲覧不可グループの場合ですが、2のロールを付与したIAMポリシーをポリシータグへではなくデータポリシーにbinding図3④します。
データポリシーというのはポリシータグに紐づいているデータのマスキングルールを決定するリソースであり、それに対してポリシーbindingを行います。マスキングルールは複数あるので、ケースに応じて適切なルールを選ぶと良いでしょう。
ここまで行うと、閲覧不可グループがポリシータグを設定した列を含むクエリを実行した場合、ポリシータグを設定した列がマスキングルールに従った状態で返ってくる状態になります。
まとめると以下のような挙動になります。
③の状態になってしまうと、そもそもクエリが実行できなくなってしまうので、そうならないように全てのグループ・ユーザーが①or②の状態になることが理想です。
使ってみた感想
約1年半利用しましたが、正直なところ当初の課題であった「特定のカラムが閲覧不可のグループから要望があるたびにViewを用意する必要がある」というケースがあまり発生しなくなったので、利用前後でそこまで恩恵を感じておりません。
ですが、アクセス制御方法を移行することによって将来的に以下のメリットがあると思いました。
- 組織が拡大してさらに細かいアクセス制御が必要になった場合、ポリシータグの方が対応が容易
- セキュリティポリシーの一元管理が可能になり、管理コストが削減される
デメリットももちろんあり、以下のような状況に陥りました。
- テーブルへのポリシータグ付与をAirflowで行なっており、そこで利用しているAPIがタイムアウトになり連携処理が失敗・遅延してしまい後続処理へ影響が出てしまった。
- 新規で作成したSAが図5③の状況になり、各所からこれまで以上に権限付与依頼が届くようになった。
APIのタイムアウトの件は、暫定でリトライ回数を増やして対応しました。
権限付与依頼の増加は、デメリットというよりメリット寄りかもしれません。というのも新規ユーザーがデータ基盤にアクセスする場合はどのような権限を持つべきかを考えるべきだと考えているので、その状態が作れていることはプラスであると思います。 (あまりに多くなってきたらもっと良いやり方がないか考えます。。)
まとめ
現段階では総じてポリシータグによるアクセス制御への移行は個人的に微差でプラス寄りな気がします。
最終的に移行してよかったと思えるように日々運用方法は改善していこうと思います。
最後に
最後までご覧いただきありがとうございました！
明日は佐伯さんよりAppSheetに関する記事をお届けします。お楽しみに！
株式会社エニグモ すべての求人一覧
