BigQueryのセキュリティ対策
BigQueryを活用するときのセキュリティ対策やアクセス制御について
Table of contents
author: kwgc-t
はじめに
エンタープライズDWHの要であるBigQueryは、企業の様々なデータを一元管理する上で欠かせない存在です。しかし、その中には機密情報や特定部署のみがアクセス可能なデータも含まれるため、強固なセキュリティ対策とアクセス制御が求められます。重要なデータを扱うBigQueryだからこそ、セキュリティは最優先事項です。
当記事では、BigQueryの主要なセキュリティ対策とアクセス制御について、解説していきます。
※ 当記事では具体的な設定方法は扱いません。セキュリティ対策として取れる手段の解説をします。
BigQueryのセキュリティ対策
セキュリティ対策と一言で表現しても、その手法は非常に多岐にわたります。
BigQueryで実施できるセキュリティ対策として大きく以下5つで分類できます。
- IAMによるアクセス管理
- データアクセス制御
- ネットワークアクセス制御
- データの暗号化
- その他
これらの5つの主要なポイントを軸に解説していきます。
IAMによるアクセス管理
IAM
BigQueryのセキュリティ対策の第一歩は、IAM（Identity and Access Management）によるアクセス管理です。IAMとは、「誰がどのリソースにアクセスできるのか」をきめ細かく制御する仕組みです。Google Cloudでは、最小権限の原則という考え方が提唱されており、必要な権限だけを必要な人に付与することがセキュリティの基本となります。
IAMの適用レベル
BigQueryでは、以下の3つのレベルでIAMを付与ができます。
- プロジェクト
- プロジェクト内のすべてのデータセットとテーブルに適用されます。
- データセット
- 特定のデータセットとその中のテーブルやビューに適用されます。
- テーブル/ビュー
- 特定のテーブルまたはビューにのみ適用されます。
これらのレベルは階層構造になっており、上位レベルで権限を付与すると、下位レベルのリソースにも自動的にアクセス権限が付与されます。例えば、プロジェクトレベルで権限を付与すると、そのプロジェクト内のすべてのデータセットとテーブルにアクセスできるようになります。
IAMロール
BigQueryには、IAM事前定義ロールがあります。これは、一般的な役割に基づいて、あらかじめ必要な権限がセットになったものです。最小権限の原則の原則に従い、ユーザーには必要な権限だけを持つロールを割り当てることが重要です。例えば、データ分析をするアナリストにはデータ閲覧者ロール、データを編集する開発者にはデータ編集者ロールを割り当てるといった具合です。
様々なIAM事前定義ロールの中でも、セキュリティの観点から特に重要なものを以下に紹介します。
- BigQuery管理者
- 全てのBigQueryリソースに対する操作権限を持ちます。BigQueryの権限の中で最も強い権限を持ちます
- BigQueryデータオーナー
- データセットとそのコンテンツに対する操作権限を持ちます。データアクセス制御（後述）に関する操作権限を含みます。
- BigQueryデータ編集者
- データセットとデータコンテンツに対する操作権限を持ちます。データオーナーとは異なり、データアクセス制御に関する操作権限は含みません。
- BigQueryデータ閲覧者
- データセットとそのコンテンツを表示する権限を持ちます。表示のみで操作はできません。
さらに要求に応じて、IAM事前定義ロールよりも細かく制御をが必要な場合はカスタムロールができます。非常に細かく指定ができますが、管理が煩雑になる可能性もあります。
データアクセス制御
IAMによるアクセス制御はリソースレベルのアクセス制御です。データアクセス制御とは列レベルや行レベルでアクセス権限を設定し、文字通りにデータへのアクセスを制限します。
BigQueryは、以下の3つのデータアクセス制御機能を提供しています。
- 承認済ビュー
- 列レベルのデータアクセス制御
- 行レベルのデータアクセス制御
それぞれの使い方やユースケースについて説明いたします。
承認済ビュー
承認済ビューは、事前に定義されたSQLクエリに基づいて作成される仮想テーブルです。ユーザーは、このビューを通してデータにアクセスするため、基になるテーブル（元テーブル）への直接的なアクセス権限は必要ありません。ビュー定義にフィルター（WHERE句）を設定することで、機密情報や不要なデータへのアクセスを効果的にブロックできます。
図1.
元となるテーブルへのアクセス権限はなくても、ビューへのアクセス権限があればデータにアクセスできます。
ユースケースとしては一律に均一なデータを提供するケースに適しています。
また、シンプルなIAMの設定で管理できるため、管理コストも低くなります。
列レベルのデータアクセス制御
テーブル内の特定の列へのアクセスを制限する仕組みで、機密情報へのアクセスを必要最小限のユーザーに限定できます。
例えば、顧客情報テーブルがあり、その中に「クレジットカード番号」や「住所」といった機密情報が含まれている場合、これらの列へのアクセスを特定のユーザーや部署だけに制限することで、情報漏洩のリスクを低減できます。
ビューでは全てのユーザーに対して同じ列を提供するのに対し、列レベルのデータアクセス制御ではユーザー単位でアクセスを制御ができます。さらに、列レベルのデータアクセス制御ポリシーは階層構造で設定できるため、柔軟性と管理コストの抑制を両立できます。
図2.
employeeのデータへのデータアクセス制御ポリシーを employee_policy をトップレベルとし、その配下にsalary, divisionのデータアクセス制御ポリシーを作成します。
HR Divのメンバーにはemployee_policyを付与することでsalary,divisionの両方にアクセスできます。一方でDeveloper Divのメンバーにはdivisionを付与することでsalaryにはアクセスできませんが、divisionにはアクセスできるようになります。
ユースケースとしてはユーザー毎にアクセスの制御をしたいケースに適しています。
前述の通りに階層的にデータアクセス制御ポリシーを作成できるため、管理コストも低く抑えることができます。
行レベルのデータアクセス制御
RLSと呼ばれるデータアクセス制御機能です。特定の条件を満たす行のみへのアクセスを可能とし、データへのアクセスを必要最小限に抑えます。
例えば、特定の地域を担当する営業担当者には、その地域に関する顧客データのみへのアクセスを許可できます。
図3.
HR DivのメンバーはdivisionがHRのデータのみに、Developer DivのメンバーはDeveloperのデータのみにアクセスを限定できます。
ユースケースとしては非常に限定されると考えています。
- 2024年9月時点で行レベルのデータアクセス制御はDDLによる設定しか手段が提供されていないこと
- DDLでテーブルにアクセス可能なユーザーを設定するため、誰がアクセスできるのかという管理が煩雑になること
- 行レベルのデータアクセス制御が設定されると、全てのユーザーに対して適用されるため運用や管理が煩雑になること
筆者としては行レベルのデータアクセス制御はビューで実現する事を検討するのがよいかと考えています。理由は以下です。
- 同様の挙動はビューでほぼ実現が可能であること（後述の※1参照）
- 前述の通りにビューには承認済ビューの仕組みもあり、より柔軟な設定が可能であること
- 行レベルのデータアクセス制御は管理が煩雑であること
※1.内部的な動作ですが、行レベルのデータアクセス制御を作成するときにフィルター（WHERE句）を指定します。設定されたテーブルにSQLを発行するときに暗黙的にこのフィルターが適用される仕組みになっています。
ネットワークアクセス制御
BigQueryはネットワークレベルでもアクセス制御ができます。そのために活用されるのが、VPC Service Controlsです。
VPC Service Controlsとは論理的な境界を設けて境界外部からのGoogle Cloudのサービスへのアクセスを制限するサービスです。
VPC Service Controlsでは、アクセスを許可する条件を細かく設定ができます。
- 特定のIPアドレスからのアクセスのみを許可する
- 特定の管理対象デバイスからのアクセスのみを許可する
- 特定のユーザーからのアクセスのみを許可する
といった設定が可能です。これらの条件を組み合わせることで、より厳格なネットワークアクセス制御を実現できます。
図4.
BigQueryへのアクセスは社内ネットワークからのみに限定し、それ以外のネットワークからのアクセスはVPC Service Controlsによって拒否します。
データの暗号化
BigQueryでは、データの安全性を確保するために、強力な暗号化技術が標準で組み込まれています。
デフォルトでGoogleが管理する鍵を使用して、保存中のデータを自動的に暗号化します。そのため、ユーザーは特別な設定をすることなく、安心してデータをBigQueryに保存できます。
より高度なセキュリティ要件に対応するために、BigQueryでは顧客管理の鍵(CMEK)を使用した暗号化もサポートしています。CMEKを使用することで、鍵の管理をユーザー自身で行うことができ、セキュリティポリシーに合わせた柔軟な運用が可能になります。
図5.
デフォルトではGoogle管理の鍵で自動でデータは暗号化され、顧客管理の鍵を利用する場合はCloud Key Managementを利用して鍵を管理し、その鍵でデータを暗号化します。
その他
不正アクセスを防ぐだけでなく、万が一の事態に備えてリスクを最小限に抑えることも重要です。例えば不正アクセスを検知する、不正アクセスを試みようとした痕跡を検知する等です。
ここでは、不正アクセスの抑止に役立つその他のセキュリティ対策を紹介します。
監査ログ
データアクセス監査ログを出力するように設定することで、データへのアクセス履歴を記録ができます。
監査ログを定期的に確認することで、不正アクセスや不審な操作を早期に発見し、対応ができます。
例えば、特定のユーザーが大量のデータをダウンロードしていた場合、監査ログからその操作を検知し、必要に応じてアクセス権限の見直しやセキュリティ対策の強化ができます。
DLP（Data Loss Prevention）
DLP（Data Loss Prevention）という機能を使って、機密データの検出と保護ができます。DLPは、定義されたルールに基づいてデータをスキャンし、個人情報やクレジットカード番号などの機密情報が含まれているかどうかを自動的に検出します。
機密データが検出された場合、DLPは自動的にデータをマスクしたり、アクセスをブロックしたりするなどのアクションを実行ができます。これにより、機密データの漏洩リスクを大幅に低減できます。
終わりに
セキュリティ対策は、“多層防御”が鍵となります。1つの対策に頼るのではなく、複数の対策を組み合わせることで、より強固なセキュリティを実現しましょう。また、防御と抑止の両面からの対策も重要です。
セキュリティ対策は、常に最新の状態に保つことが重要です。BigQueryのセキュリティ機能やベストプラクティスに関する情報は、Google Cloudの公式ドキュメントやブログなどを定期的に確認するようにしましょう。
引用
※本記事は、ジーアイクラウド株式会社の見解を述べたものであり、必要な調査・検討は行っているものの必ずしもその正確性や真実性を保証するものではありません。
※リンクを利用する際には、必ず出典がGIC dryaki-blogであることを明記してください。
リンクの利用によりトラブルが発生した場合、リンクを設置した方ご自身の責任で対応してください。
ジーアイクラウド株式会社はユーザーによるリンクの利用につき、如何なる責任を負うものではありません。