データ基盤のセキュリティは、ファイアウォールと権限管理だけでは不十分です。同一テーブルの中で「見せる行と隠す行」を分ける行レベルセキュリティ(RLS)、個人情報だけを動的にマスキングする列レベルセキュリティ、そして格納時の暗号化――これらを組み合わせて初めて、プロダクション水準の安全性に到達します。本記事では、Snowflake・BigQueryを中心に、セキュリティ設計の6つのレイヤーとその実装例を解説します。

データ基盤セキュリティの全体像

データ基盤のセキュリティは複数のレイヤーを積み重ねる多層防御の発想で設計します。ネットワーク境界、認証認可、行レベル、列レベル、格納暗号化、そして監査ログ。どれか1つが欠けても全体が弱体化しますので、抜け漏れのないチェックリスト化が必要です。

【データ基盤セキュリティレイヤー】

[利用者]
   |
   v
1. ネットワーク境界    --> VPC/IP許可リスト/PrivateLink
   |
   v
2. 認証・認可          --> SSO/MFA/IAM
   |
   v
3. 行レベルセキュリティ --> RLSポリシー
   |
   v
4. 列レベルセキュリティ --> 動的マスキング
   |
   v
5. 格納時暗号化        --> KMS/CMK
   |
   v
6. 監査ログ            --> ACCESS_HISTORY/Cloud Audit Logs
   |
   v
[データ本体]

※ どの層も省略不可。多層防御でリスクを最小化

セキュリティの設計原則は「最小権限の原則」です。必要な人にだけ、必要なデータに、必要な期間だけアクセス権を付与する。これを徹底するために、認証・認可・RLS・列マスキング・暗号化・監査を連動させて設計します。関連する個人情報保護法やGDPRへの準拠要件も、設計初期から組み込むことが重要です。

認証・認可の設計

認証はSSO(シングルサインオン)+MFA(多要素認証)が基本です。認可はロールベース(RBAC)と属性ベース(ABAC)の2方式がありますが、多くの組織ではRBACをベースにABACを部分的に取り入れるのが現実的です。

観点RBAC(ロールベース)ABAC(属性ベース)
判定基準ユーザーの所属ロールユーザー/リソース/環境の属性
実装複雑度低〜中中〜高
柔軟性中(ロール定義に依存)高(細粒度の制御可)
スケールロール数が増えると管理困難属性設計次第で容易
推奨用途一般的な組織構造動的アクセス要件

ロール設計では「アクセスロール(データへの読書権)」と「機能ロール(業務上の役割)」を分離し、機能ロールがアクセスロールを継承する階層構造にすると、管理が大幅に楽になります。詳細は権限管理設計をご参照ください。

行レベルセキュリティ(RLS)

行レベルセキュリティは「同じテーブルでも、ユーザーによって見える行が変わる」仕組みです。営業部門は自部門の案件だけ、人事は人事担当範囲だけ、という制御を1つのテーブルで実現できます。SnowflakeとBigQueryでは実装方法が異なります。

-- Snowflake: Row Access Policyの作成
CREATE OR REPLACE ROW ACCESS POLICY sales_rls
  AS (region STRING) RETURNS BOOLEAN ->
  CASE
    WHEN CURRENT_ROLE() = 'ADMIN' THEN TRUE
    WHEN CURRENT_ROLE() = 'SALES_APAC' AND region = 'APAC' THEN TRUE
    WHEN CURRENT_ROLE() = 'SALES_EMEA' AND region = 'EMEA' THEN TRUE
    ELSE FALSE
  END;

ALTER TABLE fact_sales ADD ROW ACCESS POLICY sales_rls ON (region);

-- BigQuery: Row-level Security Policy
CREATE OR REPLACE ROW ACCESS POLICY sales_apac_policy
  ON `project.sales.fact_sales`
  GRANT TO ('group:sales-apac@example.com')
  FILTER USING (region = 'APAC');

CREATE OR REPLACE ROW ACCESS POLICY sales_emea_policy
  ON `project.sales.fact_sales`
  GRANT TO ('group:sales-emea@example.com')
  FILTER USING (region = 'EMEA');

RLSの設計では「ポリシーの粒度」が重要です。ロール単位なのか、ユーザーID単位なのか、組織階層なのか。粒度を間違えると、ポリシー数が爆発して管理不能になります。組織構造のマスターテーブルを用意し、それをJOINして動的に判定する設計がスケーラブルです。

列レベルセキュリティとデータマスキング

列レベルセキュリティは、カラム単位でアクセスを制御します。メールアドレス、電話番号、クレジットカード番号など、個人情報(PII)カラムへのアクセスを一般ユーザーから遮断しつつ、管理者だけ生データを見られるようにする用途が典型例です。動的データマスキング(Dynamic Data Masking)を使えば、クエリ実行時にユーザー権限に応じてマスキング処理を適用できます。

-- Snowflake: Masking Policyの作成
CREATE OR REPLACE MASKING POLICY email_mask AS (val STRING) RETURNS STRING ->
  CASE
    WHEN CURRENT_ROLE() IN ('PII_READER') THEN val
    ELSE REGEXP_REPLACE(val, '^([^@]+)(@.+)$', '***\\2')
  END;

ALTER TABLE dim_customers MODIFY COLUMN email
  SET MASKING POLICY email_mask;

実データは変更されないため、権限を後から付与するだけで即座に生データが見えるようになります。バックアップやリストア時の互換性が保たれるのもメリットです。BigQueryでも同様に、ポリシータグでカラム単位のアクセス制御が可能です。

暗号化と鍵管理

クラウドDWHは格納時暗号化(Encryption at Rest)がデフォルトで有効ですが、機密度によっては顧客管理鍵(CMK)を使う選択肢があります。CMKを使うことで、鍵のライフサイクル管理を自社側で握れるようになります。

暗号化レベル鍵管理運用負荷推奨用途
クラウドプロバイダ管理鍵自動低一般業務データ
顧客管理鍵(CMK)自社KMS中機密性の高い業務データ
顧客提供鍵(CSEK/BYOK)完全自社管理高規制対応・最高機密
Tokenizationアプリ層で処理高PCI DSS対応等

転送時暗号化(TLS/SSL)はもちろんデフォルトで有効ですが、オンプレからクラウドへの移行時にはPrivateLinkやInterconnectの利用も併せて検討してください。Terraform IaCで鍵管理設定を含めて構成管理すれば、本番環境の再現性と監査性が大幅に向上します。

監査ログの設計

監査ログは「誰が・いつ・何をしたか」を事後追跡するための不可欠な要素です。Snowflakeの ACCESS_HISTORY やBigQueryのCloud Audit Logsを使えば、クエリ単位でのアクセス履歴を記録できます。

監査ログで重要なのは「保持期間」と「アラート設計」です。保持期間はコンプライアンス要件に応じて最低1年、できれば3年を目安に設定します。アラート設計では「機密テーブルへの想定外アクセス」「短時間の大量データエクスポート」「権限昇格の試み」などを検知ルールとして定義しておくのが実務的です。監査ログを外部SIEMに転送し、既存のセキュリティ運用と統合するのも有効です。

まとめ

データ基盤のセキュリティ設計は、認証認可・RLS・列マスキング・暗号化・監査の6レイヤーを組み合わせる多層防御が基本です。SnowflakeとBigQueryはいずれも主要機能を備えており、RLSと動的マスキングを使えば、個人情報を含むテーブルでも安全に共有できます。個人情報保護法や規制対応と合わせて、設計初期から組み込んでいきましょう。

よくある質問(FAQ)

Q. 行レベルセキュリティとは何ですか?

ユーザーの権限に応じて同一テーブル内でアクセスできる行を制限する機能です。例えば営業部門は自部門の売上データのみ閲覧可能にするといった制御ができ、テーブル分割なしにマルチテナント的な分離を実現できます。

Q. 動的データマスキングとは?

クエリ実行時にユーザーの権限に応じてデータを自動的にマスキング(例: メールアドレスを***@example.comに変換)する機能です。データ自体は変更せず、表示時のみマスキングするため、権限付与で即座に生データ参照が可能になります。

Q. SnowflakeとBigQueryでセキュリティ機能に差はありますか?

いずれもRLS・列レベルセキュリティ・動的マスキングに対応しています。Snowflakeの方がマスキングポリシーの柔軟性が高く、BigQueryはGCP IAMとの統合がシームレスで、組織階層との親和性が高いという特徴があります。