OAuth対応のBIプラットフォームでマルチテナントのダッシュボードを運用しており、特定のユーザーやグループ単位でテーブル行へのアクセスを制限したい場合、BigQueryの行レベルセキュリティ機能が役立ちます。
従来のやり方では、特定の行へのアクセス制限を行う際、アクセス権を識別するための列をテーブルに追加し、ユーザーやグループを格納した補助テーブルとJOINするのが一般的でした。例えば次のようなクエリです。
SELECT
t.*
FROM `project.dataset.table` AS t
JOIN `project.dataset.users` AS u ON t.access=u.name;
とてもシンプルですね。しかし、ユーザーを追加・削除するたびにこのテーブルをメンテナンスするのは余計な手間がかかります。そこで活用したいのが、BigQueryで利用できる 行レベルセキュリティ機能 です。 Googleグループに対して直接アクセス権を付与でき、管理プロセスを一本化できます。例えば次のように記述します。
CREATE OR REPLACE ROW ACCESS POLICY policy_<customer_id>
ON `project.dataset.table`
GRANT TO ('group:<customer_id>@<domain>')
FILTER USING (customer_id = '<customer_id>');
さらに、単一のサービスアカウントによる共通の認証情報を使う代わりに、OAuth経由でユーザー単位の認証を行うこともできます。これにより、よりきめ細かなアクセス制御（セキュリティと監査）、クォータ管理、利用状況の可視化が可能になり、得られたデータをプロダクト改善に活かせます。
確かな事実に基づいて意思決定されている皆さまの一助になれば幸いです。
課題
スケールアップの過程で顧客数が100を超えると、この方法は通用しません。BigQueryには厳しい上限があるからです（信じてください。Googleにこの上限の引き上げを依頼することに時間を費やすのは無駄です）。そもそも、1つのテーブルに100以上のルールを作成するというのも、少々違和感がありますよね。
さらに、すべてのデータにアクセスする必要があるユーザーで構成された管理者グループを設けたい場合はどうでしょう。このユースケースもなかなか厄介です。
この課題への対処法
以下のアプローチでは、ユーザーのドメイン名に基づいてアクセスを制御します。新しいグループを作成したりメンバーシップを管理したりする必要がない点が大きなメリットです。さらに、わずか2つの行レベルポリシーで、社内グループにはデータへの無制限アクセスを担保できます。
一方、明らかなデメリットもあります。この方式を機能させるには、クライアントが自社ドメインを利用している必要があります。gmail.com、yahoo.com、hotmail.comといった汎用ドメインには適しません。膨大な数のユーザーにアクセス権を付与してしまうことになるからです。
-- Create a table
CREATE TABLE test.my_table (
id INT,
name STRING,
domain STRING);
-- Insert some values
INSERT INTO test.my_table (id, name, domain) VALUES
(1, 'test1', 'example.com'),
(2, 'test2', 'domain.com');
-- Restrict access to the users based on their domain name
CREATE OR REPLACE ROW ACCESS POLICY restrict_per_domain
ON `test.my_table`
GRANT TO ('allAuthenticatedUsers')
FILTER USING (domain = SUBSTR(SESSION_USER(),STRPOS(SESSION_USER(),'@')+1));
-- Grant access to an internal DoiT group
CREATE OR REPLACE ROW ACCESS POLICY grant_internal_group
ON `test.my_table`
GRANT TO ('group:<internal_group>@<domain>')
FILTER USING (1=1);
結果は次のとおりです。
1. allAuthenticatedUsersグループに属する [email protected] は1行しか参照できません。一方、
2. [email protected] グループに属する [email protected] は、すべての行を参照できます。
要するに、許可的な行レベルポリシーは、より制限的なポリシーを上書きします（IAMの権限継承と同じ挙動です）。また、Googleの公式ドキュメントには明記されていないものの、allAuthenticatedUsers のようなグループも利用できます。
まとめると、OAuth対応のBIツールと組み合わせて行レベルセキュリティ機能を最大限に活用する方法をご紹介しました。誰が・いつ・何を実行できるのかをしっかりコントロールでき、しかも運用負荷を抑えて実現できます。ぜひ試してみてください。
最新情報は DoiT Engineering Blog 、 DoiT Linkedin Channel 、 DoiT Twitter Channel でお届けしています。採用情報は https://careers.doit-intl.com をご覧ください。