SnowVillageデタマネ会：TrustCenterを試す会

2024年8月28日 02:42

こんにちは！SnowVillageデータマネジメントグループ(通称デタマネ会)参加者のsakatokuです。
2024年8月12日に開催した「TrustCenterを試す会」のレポートをお送りします。

デタマネ会の進め方のおさらい

データマネジメントの領域でやりたいこと・相談したいことが多岐に渡るということで、今夏のデタマネ会は以下の2つのカテゴリ
・SnowflakeHorizon機能を触ってみるもくもく会
・もやもや課題について軽く喋る会
に絞って集中開催しています。
毎日毎日、学びになることが多かったです…！
活動計画は以下の記事をご一読ください。

Snowflake Trust Centerとは

Snowflake Trust CenterはSnowflakeアカウント内のセキュリティリスクを評価・監視することができるセキュリティダッシュボードです。
例えば
「Multi-Factor Authentication(MFA)が設定されていない」
「ACCOUNTADMINが他のロールに継承されている」
など、セキュリティ上の推奨設定に準拠していないところをチェックしてリストアップしてくれます。
2024年7月頭のアップデートでGeneral Availability(GA)になりました。

Snowflake Trust Centerを触ってみよう

使い方はあまり難しくないのでドキュメントを見ながら動かせると思いますが、2024年8月現在は日本語のドキュメントがないので、DevelopersIOの記事もオススメです。

Snowflake Trust Centerはスキャナーパッケージというものでどういう評価を行うかというチェック項目が定められています。リリース直後はCIS Benchmarksというスキャナーパッケージしか存在しなかったのですが、その後、Security Essentialsという無料かつ自動的に起動するスキャナーパッケージが追加されました。これはSnowflakeのセキュリティ強化の一環だと思われます。
実際の評価はスキャナーパッケージを有効化した直後、スケジュールで設定したタイミング、および手動実行を指示したタイミングで行われます。CIS Benchmarksの場合は評価が完了するまで1時間程度かかるようです。

活用に向けたポイントと感想

コスト

コストについては高価という訳ではないものの、ある程度考慮するべきでしょう。ほとんどユーザがいない、データベースやスキーマがない私の検証環境では1回あたり0.15クレジット程度でした。もう少ししっかり使っている環境で確認したところもうちょっと高めになっていた、という共有が試す会の中でありました。
例えば初期導入時や大きな設定変更を行うときには頻繁にチェックして、セキュリティリスクの棚卸がある程度完了したら1週間に1回の頻度に戻す、などの使い方もありうるかなと感じました。

対応するべき範囲

また、すべてのチェック項目をクリアするべきか、という点については試す会の中でディスカッションになりました。
実際にチェック項目を確認したところ、そもそも満たすのが難しいものもあるため、それぞれの組織の事情に合わせてセキュリティリスクがあることを理解した上で受容していくことが必要だろうという結論になりました。
ちょっとセキュリティ意識が低めの事例なのですが、例えば私の検証環境の場合、IPアドレスを制限するとロックアウトされてしまうケースがあるのでちょっと設定したくないなと考えています…こういうときはIPアドレスを制限しない危険性を理解した上で他のところでリスク軽減を図ることが大事だと考えられます。

そのユーザは人間かサービスか

なんらかのアプリケーションに対して払い出したユーザについてはMFAを設定することができません。そういった場合にどうするか、なんですがTYPEプロパティを設定するということになっています。
TYPEプロパティは2024年7月のアップデートで追加されたもので、CREATE USERおよびALTER USERするときに指定してあげることで、そのユーザが人間かサービスかをSnowflakeに対して宣言することができます。

PERSON：人間。MFAを設定することで保護することを想定している
SERVICE：サービス。キーペア認証のようなパスワード認証よりセキュアな方法で認証することを想定している
LEGACY_SERVICE：レガシーなサービス。パスワード認証にしか対応していないサービスに対して指定する

ということで、どうしてもパスワード認証させたいユーザについては
ALTER USER (ユーザ名) SET TYPE = LEGACY_SERVICE;
とすれば警告は解消されるはずだったのですが…自分の検証環境では上手くいきませんでした。何かまだ設定が足りないようなので今後試していきます…無念。

設定値が適正かどうかは一部自己責任！

Snowflake Trust Centerのドキュメントに記載されている通りなのですが、例えば
「ネットワークポリシーに記載されたIPアドレスが適切か」
「マスキングポリシーが機微なデータに正しくかかっているか」
などはSnowflakeでは判断できないため、何らかの設定が行われているかどうかを見ているようです。
上述の対応するべき範囲と合わせて、この点も考慮しながら運用する必要がありますね。

蛇足ですが、0.0.0.0/0からのアクセスを許可する(つまりすべてのIPアドレスからのアクセスを許可する)ネットワークポリシーを書けば、ネットワークポリシーが設定されていないという警告が解除されるのではと思って試してみたのですが、これはさすがにNGなようです。知ってた。

ALLOW_ALL_IPは0.0.0.0/0からのアクセスを許可するネットワークポリシー。
これをアカウントレベルで設定したんだけど…

Snowflakeへの要望

現時点でも充分に使えるツールではあるのですが、今後まだまだ改善の余地もあるなと感じられました。例えば…

自社のセキュリティルールに合わせてカスタムしたスキャナーパッケージを作成したい
受容すると決めたセキュリティリスクについては次の評価におけるスキャン対象から除外したい
社内監査のようなイベントに合わせて棚卸や設定変更を行うときには、より素早く評価を完了させられるオプションがあると嬉しい

まとめ

Snowflake Trust Centerは残念ながらこれ一つですべてのセキュリティリスクを防いでくれる魔法のツールではなく、飽くまでもSnowflakeの安全な運用をサポートするためのものだと感じました。
ただ、魔法のツールではないとしても、網羅的にセキュリティリスクを評価して一覧表示されたものを見ることでセキュリティをどうするか考えるきっかけになった、というコメントがありました。本当にその通りだと思います！
ぜひ皆さんもSnowflake Trust Centerを一度確認してみてください！