Zenn
❄️

Snowflakeのアクセスポリシーをノーコードで自動化できる製品「ALTR」を触ってみた

2024/12/12に公開
Snowflake
tech

本記事はSnowflake Advent Calendar 2024シリーズ2の12日目のポストです。

ALTRとは

ALTR[1]はSnowflakeのデータアクセスポリシーの作成・管理等、Snowflake×セキュリティに特化したツールです。

もちろん、マスキングポリシーなどはSnowflake側のSQLで定義することが可能です。しかし規模が大きくなってくると、ポリシーを定義するCASE文、そのCASE文で記述するロール、ポリシーを適用するためのSQLなどが増えていき、どんどん複雑化していきます。そこで、ノーコードでマスキングポリシーを定義・管理できるALTRを使うことで、セキュリティ担当者の負荷が軽減されるということですね。
また、アクセスポリシーに限らず、外部トークン化や、監査ログ取得など、他のセキュリティ関連の機能も備えているようです。（ロール自体の定義や認証ポリシー、ネットワークポリシーなどは対応範囲に含まれていません）

↓公式HP
https://altr.com/

↓YouTubeデモ動画：
https://www.youtube.com/watch?v=o0TythHcN5c

今回はSnowflake Quickstartsのコンテンツ「ALTR Quickstart - Data Access Control」を題材にして、ALTRでどのようにアクセスポリシーを作成できるのかを試してみました！

サンプルデータベースの作成

まずはSnowflake側でサンプルのデータベースを作成します。
※マスキングポリシーを作成するため、エディションはEnterprise以上が必要です。

-- ACCOUNTADMINロールを使用
USE ROLE ACCOUNTADMIN;

-- サンプルデータベースを作成・使用
CREATE DATABASE ALTR_GETTING_STARTED_DB;
USE DATABASE  ALTR_GETTING_STARTED_DB;

-- SNOWFLAKE_SAMPLE_DATAを元にサンプルテーブルを作成
CREATE TABLE SAMPLE_CUSTOMER AS 
    SELECT 
        C_FIRST_NAME,
        C_LAST_NAME,
        C_EMAIL_ADDRESS,
        C_BIRTH_COUNTRY
    FROM SNOWFLAKE_SAMPLE_DATA.TPCDS_SF10TCL.CUSTOMER
    LIMIT 10000;


ALTRアカウント作成

※操作するSnowflakeユーザーのプロファイルで、「first name」「last name」「email address」の設定がされていることを事前に確認します。

SnowflakeのPartner Connectから「ALTR」を選択して、アカウントを作成します。


データベース、仮想ウェアハウス、ユーザー、ロールが自動で作成されます。ここはそのまま「Connect」をクリックします。


その後メールが届き、案内に従っていくつかのステップを踏むとアカウント作成が完了します。

※途中で、PC_ALTR_USERに対してACCOUNTADMINを付与する必要があるので注意してください。

アカウントの作成が完了し、無事にALTRにログインすることができました！


データ分類レポートの作成

ここからALTRの機能を具体的に見ていきます。
まずは、データベース内のどのデータに機密情報が含まれているのかを特定するため、分類レポート（Data Classification Report）と呼ばれるものを作成します。

ALTRのポータル画面の Data Configuration -> Data Sources ページから、「ALTR_GETTING_STARTED_DB」を選択します。事前に作成していたサンプルデータベースです。


「Tag data by classification」のチェックボックスを選び、Tag Typeは「Google DLP Classification」を選択します。


ちなみに、こちらのTag Typeは3種類から選べるようになっています。今回はサンプルデータであるため、Quickstartに従ってGoogle DLP Classificationを選択していますが、実際には分類対象となるデータのセキュリティレベルや、会社のポリシーに従って選択する必要があります。

  • Google Data Loss Prevention (DLP) Classification
    →ALTRが対象データのサンプリング結果をGoogle DLP APIに送信して、分類を実行する方式
  • Snowflake Classification and Object Tags
    →データをサンプリングしたり第三者に送信したりすることなく、
    　Snowflake側で分類を実行する方式
    　（基本はこちらを選択すべき？現時点では分からず）
  • Snowflake Object Tags
    →Snowflake側の既存のタグをそのまま利用する方式

分類方法に関する詳細は以下のドキュメントを参照してください。
https://docs.altr.com/en/sensitive-data-discovery.html#snowflake-classification-52-1761

変更を保存してしばらくすると、分類完了のメール通知が届き、Data Configuration -> Data Management ページから分類レポートを確認できるようになりました！（今回は1分ほどで完了しました）

Classification列の各値（PERSON_NAME、FEMALE_NAME、、、）は、先ほどのGoogle DLP Classificationの分類結果です。

特定列のフォロー・アクセス分析

次に、特定の列をALTRがフォローできるように設定します。
先ほどのData Configuration -> Data Management ページにて、今回はC_EMAIL_ADDRESS列で「Add Data」をクリックしてフォローします。

↓


フォローすると同じ画面の「Columns」タブに追加されます。


ここでフォローされた列に対するクエリを、ALTRが追跡できるようになります。
今回、対象列が1つのみだったので良い結果は得られなかったのですが、フォローした列に対するクエリについて、以下のようにロールごとのアクセス数をヒートマップとして見られるようになりました。（UTCタイムゾーンのAM3:00に更新ということで、翌日以降に確認）

PUBLICロールのみ若干アクセス数が少ない例

データアクセスポリシー（マスキングポリシーを題材に）

最後に、いよいよALTRの画面上でマスキングポリシーを作成していきます。

今回は列単位でのマスキングポリシーを作成します。
まずは Data Policy -> Locks ページにアクセスし、「Add New」をクリックします。


ここで「Lock」と呼ばれるものをいくつか定義していきます。
クエリするユーザーのロールが「SECURITYADMINのとき」「ACCOUNTADMINもしくはSYSADMINのとき」「PUBLICのとき」という、3パターンのユースケースに応じて定義をします。

SECURITYADMINでクエリするときはマスキング無しで見られる

まずは、SECURITYADMINロールでC_EMAIL_ADDRESS列をクエリする際には、マスキング無しで元データを見られるように、Lockを定義していきます。

  • Lock Name：Email Unmasked
  • User Groups：SECURITYADMIN
  • Policy：
    • Tag：EMAIL_ADDRESS
    • Masking Policy：No Mask

Tagは、先ほど分類した結果のタグが選べるようになっています。
（タグベースのマスキングポリシーを定義するイメージです）

Masking Policyには、以下のようにALTRですでに用意されているポリシー[2]を選択することができます。これは便利ですね！



以上の定義をしてLockが作成できました。


では実際にクエリを投げてみようと思います。
まずはSECURITYADMINロールでクエリしてみます。

→Lockの定義通り、C_EMAIL_ADDRESS列はマスキング無しで元データを参照できていることが分かります。

次に、SECURITYADMIN以外のロールでクエリしてみます。すると、NULLが返却されました。



このように、Lockで定義されていないロールでアクセスすると、対象列の値をnullで返すようになるみたいです。

また、ACCOUNTADMINロールでもnullになったので、Lockでの定義は「SECURITYADMIN以上のロール」ではなく、ピンポイントで「SECURITYADMINロール」が対象になっていたことが分かります。

ACCOUNTADMINかSYSADMINでクエリするときは部分マスキングする

次に、ACCOUNTADMINロール、もしくはSYSADMINロールでC_EMAIL_ADDRESS列をクエリする際には、部分マスキング（メールアドレスの@より前をマスキング）されるようにLockを定義していきます。

以下の定義でLockを作成します。

  • Lock Name：Email Partially Masked
  • User Groups：ACCOUNTADMIN, SYSADMIN
  • Policy：
    • Tag：EMAIL_ADDRESS
    • Masking Policy：E-mail

この状態でACCOUNTADMIN、SYSADMIN、PUBLICの各ロールでのクエリ結果を見てみます。

<ACCOUNTADMIN>：
Lockの定義通り、C_EMAIL_ADDRESS列は@より前で部分マスキングされました！


<SYSADMIN>：
こちらも先ほどのACCOUNTADMINと同様、部分マスキングが行われています。


<PUBLIC>：
PUBLICはnullのままです。次に定義するLockでフルマスキングの状態で返すようにします。


PUBLICでクエリするときはフルマスキングする

最後に、PUBLICロールでC_EMAIL_ADDRESS列をクエリする際にはフルマスキングをかけるように、Lockを定義していきます。

以下の定義でLockを作成します。

  • Lock Name：Email Fully Masked
  • User Groups：PUBLIC
  • Policy：
    • Tag：EMAIL_ADDRESS
    • Masking Policy：Full Mask

ちなみにここで選択した「Full Mask」は、全て「*」でマスクされますが、データの長さは分かります。また、文字列データ型でのみ使用できます。
※静的な値にマスキングするためには「Constant Mask」を選択する必要があります。こちらは試せていないですが文字列型以外にも対応しているようです。

以上の定義をしたうえで、実際にPUBLICロールでクエリをしてみると、フルマスキングされていることが確認できました！


また、今回定義したLockはALTRのポータル画面から一覧で表示できるため、マスキングポリシーが増えても管理はしやすそうです。


今回、ALTRでマスキングポリシーを作成する検証を行いましたが、念のため、Snowflake側でもマスキングポリシーが作成されているかを確認してみました。

すると、やはりマスキングポリシーは作成されていました！データソースとして指定したデータベース内に「ALTR_DSAAS」というスキーマが作成されるのですが、そのスキーマ内にポリシーが作成されるようです。
※上のキャプチャは、今回の検証とは別の列（おそらく正確にはタグ）を対象としたLockを作成した際のキャプチャです。

その他気になったこと

一点、どうしても気になってしまったのが、ALTRによって作成されるサービスユーザーのTYPEがLEGACY_SERVICEであるという点です。（2024年12月3日現在）

キーペア認証などができないか、念のためドキュメントの方も確認したのですが、やはりLEGACY_SERVICEでの対応になってしまうようでした。LEGACY_SERVICEは2025年に廃止される予定[3]なので、ここはどうかキーペア対応してほしいところです！

https://docs.altr.com/en/grant-privileges-3-4835-5459.html

まとめ

今回はSnowflakeのアクセスポリシーを簡単に定義・管理できる製品「ALTR」を触ってみました。今回のQuickstartではデータ分類とマスキングポリシーしか触れていませんが、カスタムデータマスキングや外部トークン化、フォーマット保持暗号化 (FPE) など、他にも色々とセキュリティ関連の機能が用意されているようなので、機会があればぜひほかの機能も試してみたいです！

脚注

  1. 発音は英単語の「alter」と同じです。 ↩︎

  2. ポリシーの種類については以下を参照
    https://docs.altr.com/en/column-access-policies.html#masking-strategies-for-column-access-policies ↩︎

  3. https://www.snowflake.com/en/blog/blocking-single-factor-password-authentification/ ↩︎

Discussion

ログインするとコメントできます