IAM カスタムロールを使用して BigQuery データ ウェアハウスへのアクセスを管理する

※この投稿は米国時間 2020 年 7 月 18 日に、Google Cloud blog に投稿されたものの抄訳です。

データ ウェアハウスを BigQuery に移行する場合、最も重要なタスクの一つは、既存のユーザー権限を同等の Google Cloud Identity and Access Management（Cloud IAM）権限とロールにマッピングすることです。これは特に Teradata などの大規模なエンタープライズ データ ウェアハウスから BigQuery への移行の場合に当てはまります。通常、既存の Teradata データベースには、アクセス許可を組み合わせ、一般的なデータ アクセス パターンに対応する、複数のユーザー定義ロールが含まれています。この Teradata のロールを BigQuery IAM の事前定義ロールまたはカスタムロールにマッピングするには、組織の一般的なデータ アクセス パターンをより深く理解する必要があります。

そこで Google は、お客様の BigQuery への移行を支援した経験に基づき、お客様が Teradata 環境でのロールとして定義する一般的なデータ アクセス パターンをいくつか特定しました。この投稿では、Teradata の一般的なユーザー定義ロールを BigQuery IAM カスタムロールにマッピングする方法を説明していきます。こうしたロールは、Teradata から移行するユーザーだけでなく、BigQuery でデータ ウェアハウスを管理するデータ管理者にも役立つ場合があります。移行の前にこの概念を理解しておくと、時間を節約して、プロセス全体でユーザーとデータを確実に保護できます。

Teradata のアクセス権コードとユーザー定義ロール

Teradata では、アクセス権コードは、特定のデータベース、テーブル、列に対するユーザーのアクセス権を表します。ユーザーが Teradata オブジェクトに対して実行できる一般的なアクションを表現する、一般的なアクセス権コードの組み合わせがいくつかあります。たとえば、あるユーザーがメタデータの読み取りと変更のみを行い、別のユーザーがデータの読み取りを行い、さらに別のユーザーがそのデータの読み取りと変更を行います。  

アクセス権コードの一般的な組み合わせと、それらに対応するロールの名前と説明は次のとおりです。

Teradata と BigQuery の両方でビューまたはストアド プロシージャを作成するには、スキーマ エディタまたは開発者のロールに加え、そのビューまたはプロシージャで参照されるオブジェクトへのアクセス権がユーザーに必要です。

対応する Cloud IAM の権限

Cloud IAM での制御は、セキュリティを最も重視するお客様に利用されており、Teradata で使用されている多くの概念を Google Cloud にマッピングできます。ユーザー、グループ、サービス アカウントにロールを付与することで、BigQuery へのアクセス権限を付与できます。Cloud IAM には、次の 3 種類のロールがあります。

• 事前定義ロールは、Google Cloud によって管理され、一般的なユースケースをサポートすることを目的としています。
• カスタムロールは、ユーザーが指定した権限のリストです。これを活用して BigQuery IAM を Teradata のユーザー定義ロールにマッピングします。
• 基本ロールは Cloud IAM の導入前から存在していたものです。

上記のどのロールでも、データセットの作成や、他のユーザーへの権限付与を行える権限を、ユーザーに付与することはありません。こうしたアクションを最適に行えるのは、BigQuery が Cloud IAM の事前定義ロール「roles/bigquery.admin」を指定するデータ ウェアハウス管理者です。

Cloud IAM ロールの作成と割り当て

次のステップは、上記の権限を備えた、対応する Cloud IAM カスタムロールを作成することです。ロールに複数の権限を割り当てる最速の方法は、ドキュメントで説明されているように gcloud コマンドを使用することです。

Google Cloud では、プロジェクトまたは組織レベルでカスタムロールを作成できます。組織レベルでロールを作成する場合は、resourcemanager.projects.get 権限と resourcemanager.projects.list 権限をスキーマ リーダー ロールとスキーマ エディタ ロールに追加することを検討してください。この追加の権限により、組織内のプロジェクトに関する情報を表示する権限がユーザーに付与され、クラウド環境のオープン性と透明性が促進されます。

カスタムロールを定義したら、次のステップは、そのロールを Google グループにバインドすることです（グループはユーザーにロールを割り当てる便利な方法です）。ロールとグループのバインディングはポリシーを形成し、組織全体のリソース階層の任意のレベルで Google Cloud リソースにこのポリシーをアタッチできます（下の画像を参照）。この方法でポリシーをアタッチすると、データ共有の手段としてデータを複製する必要性を制限し、最適なリソース共有を行えるようになります。

たとえば、組織のエンジニアが、「データ開発」プロジェクトに格納されているデータを読み取るストアド プロシージャを「BI 開発」プロジェクトに作成できるとします。また、請求書内のプロジェクト レベルの合計額を使用してエンジニアリング費用を簡単に測定できるようにするために、エンジニアは BigQuery のジョブを「課金済み開発」プロジェクトから実行できるとします。これを Google Cloud に実装するには、エンジニアリング グループに次のロールを付与します。 

• BI 開発における BigQuery データセットに対する開発者ロール
• データ開発における BigQuery データセット、テーブル、ビューに対するデータ リーダー ロール
• 課金済み開発プロジェクトにおける、事前定義された BigQuery の roles/ bigquery.jobUser ロール、または、少なくとも bigquery.jobs.create 権限  

お試しください

ここで説明したロールを試すことに加えて、データ ウェアハウス ユーザーの管理に役立つ BigQuery の事前定義ロールの使用を検討してください。

権限のマッピングを確認し、このコンテンツに関する貴重なフィードバックを提供してくれた Daryus Medora に感謝します。

-戦略的クラウド エンジニア Anna Epishova、Daniel De Leo