注：本記事は(2021年7月19日)に公開された(Row Access Policies Are Now Generally Available on Snowflake)を翻訳して公開したものです。
Snowflakeデータクラウドの導入が増える中、世界で最も要件の厳しい組織にもSnowflakeの輪は広がっており、データのサイロや障壁を解消し、高水準のコンプライアンスとガバナンスを維持しながら、データを活用しているようです。
データガバナンスの取り組みを加速するため、エンタープライズはクラウドや地域をまたいで多様なワークロードに一貫して適用できる、一連のアクセスコントロールを必要としています。特に、データガバナンスチームは、ユーザーがアクセスできるデータを、権限に応じて列および行単位で制限したいと考えています。
今年の初め、当社はSnowflakeデータクラウドの列単位のセキュリティを強化するDynamic Data Maskingの正規版リリースについて発表しましたが、引き続き本日、データクラウドの行単位のセキュリティを強化する行アクセスポリシー機能の正規版リリースを発表する運びとなりました。プレビュー期間中、金融サービス、テクノロジー、小売、ヘルスケアセクターのフォーチュン500企業各社で行アクセスポリシーをご利用いただいた結果、何千ものユーザーにとってデータが簡単にアクセスしやすいものになり、データアクセスへの障壁が解消され、新たなデータインサイトが加速されるようになりました。
「機密性の高いデータを行単位で細かくアクセス制御することにより、Capital Oneは厳しい規制要件を容易に遵守できるようになりました。しかし、これを多くのデータプラットフォームで試みることによりサイロが増え、同じデータの複数のビューを維持するための経費が増大しました。Snowflakeの新しい行アクセスポリシー機能は、複数のテーブルに適用可能な柔軟なポリシーにより、当社のガバナンスに関するニーズに対応します。この独自のアプローチにより当社は、自由度やイノベーションを犠牲にすることなく、大規模な規制環境に向けて、ガバナンスの規模を調整できます。」
–Salim Syed氏、データエンジニアリング部門シニアディレクター、Capital One社
行アクセスポリシーは、細かなコンテンツベースのアクセス制御を用いて企業のデータを保護します。これによりさまざまなグループのユーザーに向けてデータをサイロ化する必要がなくなり、データガバナンスがシンプル化され、セキュリティ体制が改善されます。
Snowflakeのアプローチでは、データを大規模に統制できます。行アクセスポリシーは、規模の大小を問わずあらゆる組織で簡単に管理できるよう基礎から設計されています。
- 単一のポリシーを複数のテーブルに適用できるため、ポリシー管理、変更管理、コンプライアンス報告が非常にシンプルなものになります。
- ユーザーが多く、権限ロジックが複雑な組織の場合でも、Snowflakeは権限をマッピングテーブルに保管できるデータドリブンなアプローチに対応しています。
- Snowflakeはハイブリッドなポリシー管理モデルに対応しているため、ポリシー管理者が中央でポリシーを定義し管理しながら、組織中のデータスチュワードがそれらのポリシーをデータに適用できます。
- 行アクセスポリシーはSnowgridを通じて安全にレプリケーション可能で、複数のアカウントやリージョンをまたいで適用できます。これにより、エンタープライズは世界規模で一貫したセキュリティ体制を簡単に実現できます。
さらに、行アクセスポリシーはSnowflakeデータクラウド全体でシームレスに統合可能です。Snowflake独自のレプリケーション機能により、Snowflakeアカウントのすべてに一貫してポリシーを適用して、リージョン、さらには異なるクラウドをまたいでガバナンスを徹底できます。さらに、コンシューマーアカウントにシェアされたデータ、外部テーブルに格納されたデータ、半構造化JSONデータ、または複数のストリームを介したデータパイプラインへの行アクセスを制限するなど、さまざまな使用事例やワークロードに対して、Snowflake内で行アクセスポリシーを実装できます。
行アクセスポリシーの仕組み
行アクセスポリシーの仕組みを理解するため、簡単な例を見てみましょう。地域のセールスデータへのアクセスを、その地域に住むユーザーのみに制限するとします。下の図のとおり、クライアント情報テーブル（client_info）には、複数の地域からの部外秘の情報（クライアントの氏名、電話番号、地域）が掲載されています。あなたは、クライアント情報へのアクセスを、同じ地域の営業担当者に制限する必要があります。セールスマネージャーであれば、複数の地域のクライアント情報にアクセスできます。
この場合、行アクセスポリシーを使用して簡単な3つの手順を実行するだけで、行レベルのセキュリティを実現できます。
- ポリシーを定義し、オプションでマッピングテーブルを定義します。
- ポリシーを1つまたは複数のテーブルに適用します。
- データをクエリします。
下の例のとおり、テーブルをクエリしているのがSALES_MANAGERロールの場合、すべての行へのアクセスを許可するポリシーを作成します。SALES_NAやSALES_EUロールの場合、許可されない行はフィルタされます。
次に、sales_regionalizationポリシーをclient_infoテーブルに適用します。
client_infoテーブルでの後続のすべてのデータアクセスは、行アクセスポリシーでの権限に基づいてフィルタされます。
Snowflakeのポリシーベースのアプローチ固有のメリットは、複数のテーブルに対して同じポリシーを適用して保護できる点です。例で示すとおり、部外秘の情報を含むパートナー情報テーブル（partner_info）があり、ある地域のパートナー情報へのアクセスを、同じ地域の営業担当者に限定したい場合、先ほど作成したsales_regionalizationポリシーを、下のとおりpartner_infoに適用できます。
その結果、partner_infoテーブルでのデータアクセスはすべて、ポリシーに基づいてフィルタされます。
これらは行アクセスポリシーの仕組みを説明するためのシンプルな例ですが、行アクセスポリシーは、行の表示をロール1つのみに許可するシンプルなものから、クエリ結果内の行へのアクセスを制限する際に必要となる複雑なものまであります。実際、すでにユーザーまたはロール、および個々の権限を、次に説明するマッピングテーブルのような形でマップ化している企業も多くあります。
例：マッピングテーブル
前の例では、ポリシーロジックがポリシー定義に組み込まれている、スタンドアロンの行アクセスポリシーについて取り上げました。一方、Snowflakeでは、いくつかのテクニックにより、より複雑なポリシー条件の管理も簡単に実行することができます。複雑なポリシーは「ヘルパー」UDFを使用して分解されてから、マッピングテーブルを参照します。下の例は、マッピングテーブルのアプローチを表しています。
マッピングテーブルは、ロール、ユーザー名、またはSnowflakeアカウント名などといったコンテキストが、アクセス可能なコンテンツの仕様にマッピングされます。下の例のマッピングテーブルでは、セールスロールが、それぞれアクセス可能なリージョンコードにマッピングされています。
マッピングテーブル：Region_Entitlement
この場合、下の例で示すとおり、行アクセスポリシーを作成することで、マッピングテーブルで定義された権限に基づき、許可されない行はフィルタされます。
結論
行アクセスポリシーの使用を今すぐ開始して、ご自身の使用事例におけるポリシーベースの行単位セキュリティのメリットを体感してください。行アクセスポリシーに関するさらなる詳細については、SnowflakeのドキュメンテーションおよびSnowflake Summitで行われたベストプラクティスセッションをご覧ください。フィードバックや改善点に関するリクエストは、Snowflakeコミュニティポータルへお寄せください。