単一要素による認証からの移行に関するベストプラクティス

このセクションでは、Snowflakeの機能を活用して強力な認証を実施し、認証情報盗難のリスクを軽減する方法について、顧客向けのベストプラクティスを紹介します。この情報は、パスワードのみの認証から脱却するための最新の Snowflake 戦略を紹介した 単一要素パスワードサインインの廃止計画 と併せてご利用ください。

本ガイドのサンプルクエリは、Snowflakeの顧客を支援するための例であり、本番環境に実装することを意図したものではありません。

概要

この記事 で述べたように、Snowflakeは3つのキーに重点を置いており、アカウントのセキュリティをより簡単に保つことができます。

  • プロンプト: セキュリティのベストプラクティスを使用していないユーザーに、そのベストプラクティスを採用するように促します(例えば、多要素認証 (MFA) を構成します)。

  • 強制: 管理者がデフォルトでセキュリティを強制しやすいようにします(例えば、すべての人間ユーザーが MFA を使うように要求します)。

  • 監視: セキュリティポリシーの遵守状況を可視化(例えば、どのユーザーが MFA を構成していないか監査)。

以下の情報は、主に Snowflake トラストセンター を使用した監視のベストプラクティス、および認証とネットワークポリシーを活用した強制施行の手順に重点を置いています。

Snowflake接続セッションのライフサイクル

Snowflake への接続は、次の図に示すように、ドライバー、コネクター、または Snowsight から開始します。

Snowflakeに安全に接続する方法

ユーザーまたはサービスがSnowflakeに接続すると、次のことが起こります。

  • 構成されている場合、 ネットワークポリシー が適用されます。ユーザーレベルのネットワークポリシーは、アカウントレベルのネットワークポリシーよりも優先されることを覚えておいてください。

  • 構成されている場合、 認証ポリシー が適用されます。ユーザーレベルの認証ポリシーは、アカウントレベルの認証ポリシーより優先されることに留意してください。

    ユーザーまたはサービスが Snowflake ネイティブパスワード認証を使用する場合、 パスワードポリシー が構成されていれば適用されます。

  • 上記のコントロールによってユーザーまたはサービスが許可および認可されている場合、 セッションポリシー が適用され、非アクティブ期間後のユーザーの再認証方法が制御されます。ユーザーレベルのセッションポリシーはアカウントレベルのセッションポリシーより優先されます。

ネットワークポリシーと認証: 一般的なガイドライン

すべてのケースにおいて、以下のガイドラインを考慮してください。詳細については、 フェーズ3:保護 をご参照ください。

Snowflakeでは、構成と適用を強く推奨しています。

  • PERSON(人間)、 SERVICE、LEGACY_SERVICE を区別するためのユーザー TYPE 属性。

    • PERSON: MFA が強制されるユーザーによるインタラクティブ認証。この記事を書いている時点では、デフォルトでは NULL となっており、 MFA 強制施行の観点からは PERSON として扱われます。

    • SERVICE: プログラムアクセスを使用するサービス間認証の場合。この場合、 MFA 強制施行は免除されますが、これらのユーザーはパスワード認証をサポートしなくなります。これらのユーザーは、 OAuth またはキーペアのみをサポートします。

    • LEGACY_SERVICE: パスワードのみの認証をサポートする唯一のユーザータイプです(MFA 強制施行の除外)。これはあくまで移行ツールであり、ユーザーはネットワークポリシーで保護し、 漏洩したパスワードの保護 機能で監視する必要があります。

      注釈

      LEGACY_SERVICE は移行ツールとして使用されるべきであり、 2025年11月に非推奨となります

  • SCIM 自動プロビジョニングおよび 顧客属性によるユーザータイプのセット用

  • 可能な限り、ユーザーやサービスが許可された信頼できるソースからのみ提供されていることを確認するためのネットワークポリシー。

  • OAuth や SAML のような短命な認証情報を活用する強力な認証方法を強制する認証ポリシー。

  • 組織のパスワードポリシーを強制するためのパスワードポリシー。

  • アイドルセッション時間を制限するセッションポリシー。

サービス・ユーザーには、 OAuth のような短命の認証情報を可能な限り使用することが奨励されています。 キーペア のような長期的な認証情報については、これらのキーを定期的にローテーションし、 可能な限りネットワークポリシーと組み合わせることを推奨します。

人間のインタラクティブユーザーについては、Snowflake アカウントを組織全体の ID プロバイダーと統合し、独自の SAML-フェデレート認証 を活用して、独自の ID プロバイダーと、独自の MFA と統合する必要があります。

ブレイクグラスのユースケースとネイティブパスワードを使用しているユーザーには、Snowflakeネイティブ MFA の使用を強くお勧めします。

顧客は、社内のセキュリティポリシーに従って、認証情報を定期的にローテーションする必要があります。

顧客は常に トラストセンター を使用してリスクのあるユーザーを監視し、Snowflake アカウントを組織のセキュリティオペレーションセンターと統合する必要があります。

認証強化のためのSnowflake North Star

2025年には、Snowflakeは顧客を支援するための追加機能をサポートする予定です。

2025年上半期

  • ネイティブの MFA サポートを改善し、 DUO だけにとどまらず、passkey および認証アプリをサポートします(2025 年 4 月末の一般提供をターゲットとしたプライベートプレビュー中)。

  • OAuth の構成と採用を簡素化するため、ドライバーとコネクターで OAuth をネイティブにサポートします。

  • トラストセンターの新機能など:

    • メール通知(プレビューは2025年4月末をターゲット)。

    • パートナーとの拡張機能およびカスタムスキャナーパッケージ(現在プライベートプレビュー中、2025年7月末頃の一般提供をターゲット)。

    • 顧客組織レベルのTrust Center(2025年4月末までのプライベートプレビュー中)。

2025年以降

  • 機械学習による異常検知を使用するために Trust Center を強化します。

  • Snowsight と SAML, OAuth でユーザーエクスペリエンスを向上。

  • ワークロードの ID と OIDC をサポートし、Azure 管理 ID、 AWS ロール、 GCP サービスアカウントなどのネイティブ CSP ID を使用して、認証情報なしでワークロードを Snowflake に簡単に接続できます。

  • mTLS をサポートする顧客のリソースに対して、Snowflake へのインバウンドと Snowflake からのアウトバウンドの両方向で mTLS をサポートします。

Snowflakeは、上記のリストおよびスケジュールを適宜更新、変更する権利を有します。詳細は後日発表されます。

認証とネットワークポリシーのベストプラクティス

Snowflakeでは、以下の4つのステップに従って、より強固な認証体制に移行することを推奨しています。

  1. 危険なユーザーを検出します。

  2. 混乱を最小限に抑えるために、移行を計画しましょう。

  3. Snowflakeでユーザーを保護しましょう。

  4. 危険なユーザーを継続的に監視します。

MFA への移行の4つの段階

フェーズ1: 検出

Snowflakeは主に2つの機能を導入しました。

  • Threat Intelligenceスキャナーパッケージ: このスキャナは、次の図のロジックに基づいてリスクのあるユーザーを識別します。このセクションには、リスクのあるユーザーをリストアップし、なぜそのユーザーがリスクがあるのかを説明するクエリのサンプルも含まれています。

  • 流出したパスワード保護: ダークウェブで発見されたユーザーパスワードを検証し、自動的に無効にします。これにより、流出したパスワードに対するビルトイン保護が提供され、データ流出の可能性を抑えることができます。侵害されたユーザーは、アカウント管理者に連絡し、パスワードをリセットすることができます。

顧客は脅威インテリジェンススキャナーをオンにし、スキャン頻度をカスタマイズしてください。通常、このスキャナーは週に1回実行され、現在のリスキーユーザーの状況を報告します。すべてのトラストスキャナーから得られた結果は、 SNOWFLAKE.TRUST_CENTER スキーマに保存されます。顧客は、Snowflakeネイティブアラートを活用して、セキュリティ管理者に自動的に通知したり、危険なユーザーが検出された場合にアクションを実行したりすることができます。

危険なユーザーリストのクエリサンプル

Snowflakeは最近、ユーザー用とサービスユーザー用の2台のスキャナーを追加しました。これにより、ユーザーは、ユーザーのタイプに応じて、1ファクタパスワードサインオンを使用するユーザーのリストを別々に持つことができます。

タイプごとにリスクのあるユーザーのリストを返すことができます。

危険なユーザーリスト
SELECT *
  FROM SNOWFLAKE.TRUST_CENTER.FINDINGS
  WHERE event_id =
    (SELECT event_id FROM SNOWFLAKE.TRUST_CENTER.FINDINGS
    WHERE scanner_id = 'THREAT_INTELLIGENCE_NON_MFA_PERSON_USERS'
    ORDER BY event_id DESC LIMIT 1) AND total_at_risk_count != 0
;
Copy
危険なサービスユーザーのリスト
SELECT *
  FROM SNOWFLAKE.TRUST_CENTER.FINDINGS
  WHERE event_id =
    (SELECT event_id FROM SNOWFLAKE.TRUST_CENTER.FINDINGS
    WHERE scanner_id = 'THREAT_INTELLIGENCE_PASSWORD_SERVICE_USERS'
    ORDER BY event_id DESC LIMIT 1 ) and total_at_risk_count != 0
;
Copy

TYPE のユーザー分布と使用される認証方法

前のクエリに加えて、ユーザータイプや使用された認証方法のユーザー分布をリストすることは有益です。これは、 SAML や OAuth のような、より強力な認証方法へのユーザー移行のストラテジー立案に役立ちます。例えば、あるユーザーが(Snowflakeにパスワードがあるため)危険であると表示されているが、そのユーザーは SAML 認証しか使用していない場合、できるだけ早くそのパスワードをSnowflakeから削除することをお勧めします。

WITH users AS (
  SELECT DISTINCT
       user_id
      , name
      , login_name
      , type
      , email
  FROM
      SNOWFLAKE.ACCOUNT_USAGE.USERS
  WHERE
      DELETED_ON IS NULL)
SELECT
    u.user_id
    , a.event_timestamp
    , a.user_name
    , u.type
    , a.reported_client_type
    , a.first_authentication_factor
    , a.second_authentication_factor
  FROM SNOWFLAKE.ACCOUNT_USAGE.LOGIN_HISTORY AS a
    JOIN USERS u ON a.user_name = u.name
;
Copy

フェーズ2:移行計画

移行計画は フェーズ1: 検出 から始まります。リスクのあるユーザーを特定したら、 ネットワークポリシーと認証: 一般的なガイドライン をフォローする計画を開始します。可能な限り、パスワードやキーペアのような静的な認証情報から脱却し、シングルサインオン(連携認証)を活用すべきです。例えば、対話型ユーザーには SAML を、プログラム型ユーザー (SERVICE) と対話型ユーザー (PERSON) の両方には OAuth を使用します。

レガシーアプリケーションをサポートするために、静的な認証情報(キーペアまたはパスワー ド)を使用せざるを得ない場合は、次のことを考慮して計画を立ててください:

  • 可能な限りネットワークポリシーを活用してください。

  • 組織のポリシーに基づいて、静的認証情報をローテーションします。

移行に関する考慮事項

移行を計画する際に留意すべき点をいくつかご紹介します。

  • まず、ユーザー タイプ をセットします(これは SCIM を使って自動化 できます)。

  • 次に、アプリケーションでサポートしている認証方法を確認してください。 Snowflake は、 OAuth、 SAML、キーペア、 MFA など、 さまざまな認証方法 をサポートしています。しかし、Snowflakeに接続するアプリケーションも強力な認証方法をサポートする必要があります。2つのユースケースがあります。

    • アプリはすでに SAML および/または OAuth をサポートしています。できるだけ早く認証に移行することをお勧めします。

    • このアプリはレガシーで、 SAML や OAuth のような強力な認証方法をサポートしていません。この場合、レガシーアプリケーションを更新することをお勧めします。その間、アプリケーションをアップデートするまでの間、ネットワークポリシー、パスワードローテーション、流出したパスワード保護機能を活用することができます。

  • 次に、ローカルユーザー(Snowflake で手動で作成したユーザーで、 SAML または OAuth が有効になっていないユーザー)については、次の点を考慮する必要があります。

    • SSO をサポートするアプリケーションでは、ローカルユーザーを SSO 対応ユーザーに切り替え、ユーザーを切り替える際のダウンタイムを考慮してください。

    • ローカルユーザーを SSO-enabledに切り替えるには、そのようなユーザーが IdP に存在することを確認し、Snowflakeに手動で、またはできれば自動的に、 SCIM を介してプロビジョニングします。

    • 未使用のローカルユーザーを無効にします。

  • Snowflakeは、ユーザーレベルとアカウントレベルの両方で、認証ポリシー、ネットワークポリシー、パスワードポリシーをサポートしています。ユーザーレベルのポリシーを最初に検討し、徐々に移行します(ユーザーレベルのポリシーはアカウントレベルのポリシーよりも優先されます)。

    • Snowflakeでは、サービスユーザー(TYPE = SERVICE または LEGACY_SERVICE)を使用するアプリケーションに対して、ユーザーレベルのネットワークポリシーを推奨しています。

    • ヒューマンユーザー(TYPE = PERSON または NULL)の場合、ユーザーレベルのネットワークポリシーから始めて、アカウントレベルでネットワークポリシーを適用することで、ユーザーレベル固有のポリシーを持っていないすべてのユーザー集団を保護することができます。

    • MFA ポリシーと同じ考え方で、まずユーザーレベルのポリシーから始めます。

  • シングルサインオンをサポートしていないレガシーアプリケーションがある場合、Snowflake では programmatic access tokens (PATs) を活用することを推奨しています。これは既定のロールに関連付けられ、ネットワークポリシーが必要で、期限付きです。

フェーズ3:保護

以下の図は、推奨される認証のベストプラクティスをナビゲートするのに役立ちます。お分かりのように、Snowflakeは常に連携認証と認可を最初に使用することを推奨しています。

認証のベストプラクティス

以下の手順に従って、Snowflakeアカウント漏洩のリスクを軽減してください。

  1. ユーザータイプのセット

  2. 不要なローカルパスワードは削除

  3. サービスユーザーの認証ポリシーの作成

  4. 認証ポリシーを作成し、 MFA を人間ユーザーに強制します。

  5. パスワードポリシーを作成する

  6. セッションポリシーを作成する

  7. サービスユーザー向けのネットワークポリシーの作成

  8. アカウントレベルでのネットワークポリシーの作成

  9. サービスユーザーの保護

  10. アカウントレベルでのパスワードポリシーとセッションポリシーの適用

  11. テストサービスユーザー

  12. MFA 強制施行でアカウントを保護する

  13. アカウントレベルのネットワークポリシーの適用

  14. 未使用ユーザーの無効化

ユーザータイプのセット

保護フェーズの最初のステップは、 SCIM を介して自動的に、または手動でユーザータイプをセットすることです。

ALTER USER svc_user1 SET TYPE = SERVICE;
ALTER USER user1@example.COM SET TYPE = PERSON;
-- LEGACY APPLICATION ONLY
Copy

また、アカウント作成時に管理者ユーザータイプをセットできるようになりました。

CREATE ACCOUNT <name> [ ADMIN_USER_TYPE = PERSON | SERVICE | LEGACY_SERVICE | NULL ];
Copy

Tip

多くの顧客は通常、サービスユーザー名に何らかのパターンを持っています(local_svc_user1 など)。この命名パターンを利用して、 SERVICE のタイプをスケールごとにセットすることができます。

不要なローカルパスワードは削除

トラストセンターの調査結果に基づき、 TYPE と AuthN の「使用されるユーザー分布」と「危険なユーザーのリスト」のクエリを活用し、 SAML、 OAuth、またはキーペアを既に排他的に使用しているユーザーの Snowflake のパスワードのクリーニングを開始します。

サービスユーザーの認証ポリシーの作成

Snowflake では、プログラムサービスのユーザーには OAuth を使用することを推奨しており、認証ポリシーでこれを強制することができます。

CREATE AUTHENTICATION POLICY PROGRAMMATIC_ACCESS_USER_AUTH
  CLIENT_TYPES = ('DRIVERS', 'SNOWSQL')
  AUTHENTICATION_METHODS = ('OAUTH')
  SECURITY_INTEGRATIONS = ('<OAUTH SECURITY INTEGRATIONS>');

ALTER USER <SERVICE_USER> SET AUTHENTICATION POLICY PROGRAMMATIC_ACCESS_USER_AUTH;
Copy

SERVICE ユーザーとの認証にキーペアを使用することは可能ですが、ネットワークポリシーと組み合わせ、定期的にキーをローテーションする必要があります。

注釈

レガシーシステムがキーペアまたは OAuth をサポートしておらず、認証にパスワードを使用する必要がある場合は、認証方法 PASSWORD で追加の認証ポリシーを作成し、その特定のプログラムユーザーに適用します。このアプローチと ネットワークポリシーと認証: 一般的なガイドライン を組み合わせます。

認証ポリシーを作成し、 MFA を人間ユーザーに強制します。

Snowflake では、 IdP がサポートする MFA ソリューションで、顧客独自の SAML IDプロバイダー(IdPs)を使用することを推奨しています。以下の認証ポリシー例は、顧客を以下で支援します。

  • Snowflake ネイティブパスワードを使用するすべてのヒューマンユーザーに対して、Snowflake ネイティブ MFA を強制します。

  • シングルサインオンユーザーに MFA を強制するために、顧客 SAML IdP に依存します。

CREATE AUTHENTICATION POLICY HUMAN_ACCESS_ACCOUNT_ENFORCE_MFA
  AUTHENTICATION_METHODS = ('SAML', 'PASSWORD')
  SECURITY_INTEGRATIONS = ('<SAML SECURITY INTEGRATIONS>')
  MFA_AUTHENTICATION_METHODS = ('PASSWORD'); -- enforce Snowflake MFA for native passwords only
  MFA_ENROLLMENT = 'REQUIRED';
Copy

顧客は、顧客のアカウント管理者がSnowflakeアカウントにログインできるように、顧客 IdP がオフラインになった場合に備えて、ブレイクグラスの状況を考慮する必要があります。

CREATE AUTHENTICATION POLICY ACCOUNTADMIN_BREAKGLASS_MFA
  AUTHENTICATION_METHODS = ('PASSWORD')
  MFA_AUTHENTICATION_METHODS = ('PASSWORD') -- enforce Snowflake MFA for native passwords only
  MFA_ENROLLMENT = 'REQUIRED';
Copy
SSO 上での MFA

注釈

より厳格なポリシーの場合、 MFA 強制施行ポリシーを追加作成し、ユーザーレベルで直接適用することができます。例えば、顧客 IdP が MFA をサポートしていない場合、 IdP レベルでの MFA 実施に関係なく、ユーザーに対して Snowflake MFA 強制施行を実施することができます。(顧客によっては、アカウント管理者のような高い権限を持つユーザーのダブル MFA のためにこのオプションを使用することができます)。

CREATE AUTHENTICATION POLICY ACCOUNTADMIN_DOUBLE_MFA
  AUTHENTICATION_METHODS = ('PASSWORD', 'SAML')
  SECURITY_INTEGRATIONS = ('<SAML SECURITY INTEGRATIONS>')
  MFA_AUTHENTICATION_METHODS = ('PASSWORD', 'SAML') -- double MFA
  MFA_ENROLLMENT = 'REQUIRED';
Copy

パスワードポリシーを作成する

レガシーシステム、またはSnowflakeネイティブパスワードを使用する必要があるブレイクグラス状況の場合、組織のパスワードポリシーがデフォルトのポリシーと異なる場合は、Snowflakeパスワードポリシーを活用してください。

CREATE PASSWORD POLICY password_policy_account
  PASSWORD_MIN_LENGTH = 32
  -- PASSWORD_MAX_LENGTH = <integer>
  PASSWORD_MIN_UPPER_CASE_CHARS = 6
  PASSWORD_MIN_LOWER_CASE_CHARS = 6
  PASSWORD_MIN_NUMERIC_CHARS = 4
  PASSWORD_MIN_SPECIAL_CHARS = 8
  PASSWORD_MIN_AGE_DAYS = 10
  PASSWORD_MAX_AGE_DAYS = 30
  PASSWORD_MAX_RETRIES = 3
  PASSWORD_LOCKOUT_TIME_MINS = 30
  PASSWORD_HISTORY = 24
  COMMENT = '<string_literal>';
Copy

セッションポリシーを作成する

Snowflakeでは、セッションポリシーを作成し、一定期間の非アクティブ後に再認証を強制することを推奨しています。これはほんの一例です。個々のユーザーレベルでポリシーをカスタマイズすることができます。

CREATE SESSION POLICY session_policy_account
  SESSION_IDLE_TIMEOUT_MINS = 240 -- Snowflake clients and programmatic clients
  SESSION_UI_IDLE_TIMEOUT_MINS = 20 -- For the Snowflake web interface
  COMMENT = '<string_literal>';
Copy

サービスユーザー向けのネットワークポリシーの作成

一般的に、サービスまたはプログラムアクセスのユーザーは、認可された IP アドレス(プライベート接続の場合は、 VPCE ID、 LinkID など)から来る必要があります。

Snowflakeでは、サービスユーザーレベルのネットワークポリシーを作成し、許可された信頼できるソースからのプログラムアクセスユーザーにアクセスを制限することを推奨しています。顧客は、内部ステージでもネットワーク・ルールを実施することを検討すべきです。

注釈

内部ステージのネットワークルールは、Snowflakeでは AWS リージョンでのみサポートされています。Azureの場合は、パブリックアクセスのブロックを検討することができます。 GCP サービス制御については、Snowflakeサポートに連絡してください。

クラウドの動的な性質のため、クラウドプロバイダによっては、Snowflakeネットワークポリシーにリストする IP アドレスの範囲を提供できないケースがあります。このようなシナリオについては、「ネットワークと認証ポリシーに関する一般的なガイドライン」に従ってください。また、ツールが対応している場合はプライベート接続も検討しましょう。

接続は、顧客がプライベート接続を使用しているかどうかに応じて、プライベートネットワークまたはパブリックネットワークから行うことができます。関連する IPs (パブリックまたはプライベート)および/または CSP タグ(VPCE ID、 LinkIDs など)を含む複数のネットワークルールを追加することで、パブリックとプライベートの両方の接続を同時に許可できることに留意してください。

-- ACCESS FROM PUBLIC IP ADDRESSES
CREATE NETWORK RULE PROGRAMMATIC_ACCESS_USER_NET_RULE_PUBLIC
  TYPE = IPV4
  VALUE_LIST = ( 'PUBLIC IP1' , 'XX.XX.XX.XX/24' [ , ... ] )
  MODE =  INGRESS
;
-- ACCESS FROM PRIVATE NETWORK
CREATE NETWORK RULE PROGRAMMATIC_ACCESS_USER_NET_RULE_PL
  TYPE = AWSVPCEID
  VALUE_LIST = ( 'VPCE-123ABC3420C1931' , 'VPCE-123ABC3420C1932' )
  MODE =  INGRESS
;
-- RESTRICT ACCESS TO INTERNAL STAGE USING VPCE ID
CREATE NETWORK RULE PROGRAMMATIC_ACCESS_USER_NET_RULE_INTERNAL_STAGE
  TYPE = AWSVPCEID
  VALUE_LIST = ( 'VPCE-123ABC3420C1933' )
  MODE =  INTERNAL_STAGE
;
CREATE NETWORK POLICY PROGRAMMATIC_ACCESS_USER_NET_POLICY
  ALLOWED_NETWORK_RULE_LIST =
    (
     'PROGRAMMATIC_ACCESS_USER_NET_RULE_PUBLIC',
     'PROGRAMMATIC_ACCESS_USER_NET_RULE_PL',
     'PROGRAMMATIC_ACCESS_USER_NET_RULE_INTERNAL_STAGE'
    )
  --BLOCKED_NETWORK_RULE_LIST = ( 'OPTIONAL BLOCKED LIST OF IPS' )
;
Copy

アカウントレベルでのネットワークポリシーの作成

アカウントレベルのポリシーは、ネットワークポリシーが直接適用されていないユーザーのデフォルトのセキュリティネットワークポリシーとして機能します。ベストプラクティスは、これらのポリシーをできるだけ制限的で短く保ちながら、ユーザーレベルのポリシーを使って特定のユーザーのニーズに対応することです。

Snowflakeでは、組織のすべてのニーズを満たすために巨大なアカウントレベルのネットワークポリシーを構築することは推奨していません。代わりに、ユーザーレベルのポリシーでよりきめ細かい制御を可能にします。

ユーザーレベルのネットワークポリシーと同様に、接続は、ユーザーがプライベート接続を使用しているかどうかに応じて、プライベートネットワークまたはパブリックネットワークから行うことができます。関連する IPs (パブリックまたはプライベート)および/または CSP タグ(VPCE ID、 LinkIDs など)を含む複数のネットワークルールを追加することで、パブリックとプライベートの両方の接続を同時に許可できることに留意してください。

-- ACCESS FROM PUBLIC IP ADDRESSES
CREATE NETWORK RULE HUMAN_ACCESS_ACCOUNT_NET_RULE_PUBLIC
  TYPE = IPV4
  VALUE_LIST = ( 'PUBLIC IP1' , 'XX.XX.XX.XX/24' [ , ... ] )
  MODE =  INGRESS
;
-- ACCESS FROM PRIVATE NETWORK
CREATE NETWORK RULE HUMAN_ACCESS_ACCOUNT_NET_RULE_PL
  TYPE = AWSVPCEID
  VALUE_LIST = ( 'VPCE-123ABC3420C1934' , 'VPCE-123ABC3420C1936' )
  MODE =  INGRESS
;
-- RESTRICT ACCESS TO INTERNAL STAGE USING VPCE ID
CREATE NETWORK RULE HUMAN_ACCESS_ACCOUNT_NET_RULE_INTERNAL_STAGE
  TYPE = AWSVPCEID
  VALUE_LIST = ( 'VPCE-123ABC3420C1937')
  MODE =  INTERNAL_STAGE
;
CREATE NETWORK POLICY ACCOUNT_LEVEL_NET_POLICY
  ALLOWED_NETWORK_RULE_LIST =
   (
    'HUMAN_ACCESS_ACCOUNT_NET_RULE_PUBLIC',
    'HUMAN_ACCESS_ACCOUNT_NET_RULE_PL',
    'HUMAN_ACCESS_ACCOUNT_NET_RULE_INTERNAL_STAGE'
   )
   --BLOCKED_NETWORK_RULE_LIST = ( 'OPTIONAL BLOCKED LIST OF IPS' )
;
Copy

サービスユーザーの保護

TYPE=SERVICE を持つユーザーは、アカウントレベルの MFA 強制ポリシーから免除され、非インタラクティブなユースケースのセキュリティ態勢を改善するための制限があります。注目すべきは、 SERVICE-タイプのユーザーは、パスワードや SAML SSO を使ってログオンできないこと。以下の注意を参照してください。

-- FOR EVERY SERVICE PROGRAMMATIC ACCESS USER
ALTER USER SERVICE_USER_1 SET
TYPE = SERVICE
NETWORK_POLICY = PROGRAMMATIC_ACCESS_USER_NET_POLICY
AUTHENTICATION POLICY = PROGRAMMATIC_ACCESS_USER_AUTH;
Copy
レガシーアプリケーションのサービスユーザー

OAuth をサポートしていないレガシー・アプリケーションがある場合は、 LEGACY_SERIVCE でパスワードを使う代わりに、 プログラム・アクセストークン (PATs) を使ってください。

PATs には、セキュリティを向上させるための多くの制限があります。 PAT を生成すると、特定のロールに関連付けられ、期限付きで、特定のユーザー(アカウントレベルまたはユーザーレベル)に適用されるネットワークポリシーに関連付けられます。

PAT をコピーして、レガシー・アプリケーションのパスワード・フィールドで使用することができます。このようなレガシー・アプリケーションでは、 LEGACY_SERVICE やパスワードのみの認証を使用する必要はありません。

注意

SERVICE タイプのユーザーは認証方法としてパスワードを使用できないため、より強力な認証をサポートしていないレガシーシステムでは、代わりに PAT を使用することをお勧めします。

注釈

LEGACY_SERVICE は2025年11月に廃止される予定です。

アカウントレベルでのパスワードポリシーとセッションポリシーの適用

Snowflake セキュリティ管理者は、アカウントレベルでベースラインのパスワードポリシーとセッションポリシーを適用し、必要に応じてユーザーレベルのポリシーでこれらのポリシーを上書きする必要があります。

ALTER ACCOUNT SET
SESSION POLICY = SESSION_POLICY_ACCOUNT;
PASSWORD POLICY = PASSWORD_POLICY_ACCOUNT;
Copy

テストサービスユーザー

このステージでは、アカウントにはパスワードポリシーとセッションポリシーが適用されています。サービスプログラムユーザーは MFA から除外され、接続が信頼できるソースから確立され、 OAuth やキーペアなどの推奨される認証方法を使用することを確認する、独自の認証ポリシーとネットワークポリシーを持っています。

セキュリティ管理者は、いくつかのサービスユーザーをテストして、円滑な運用を保証し、接続が信頼できるソースからのものであり、適切な認証方法を使用していることを確認する必要があります。管理者は、Trust Center に加えて、 LOGIN_HISTORY を使用して、サービスユーザーがネットワークポリシーで保護されていることを確認する必要があります。

SELECT *
  FROM TABLE(INFORMATION_SCHEMA.LOGIN_HISTORY(TIME_RANGE_START =>
    DATEADD('HOURS',-1,CURRENT_TIMESTAMP()),CURRENT_TIMESTAMP()))
  ORDER BY EVENT_TIMESTAMP;
Copy

MFA 強制施行でアカウントを保護する

SERVICE タイプ以外のすべてのユーザーに MFA を強制するには、アカウントレベルで MFA 強制ポリシーを適用します。

これらのポリシーは、すべての人間のインタラクティブユーザーが自身の IdP またはネイティブの Snowflake MFA から MFA を有効にすることを保証するのに役立ちます。

ALTER ACCOUNT SET
AUTHENTICATION POLICY = HUMAN_ACCESS_ACCOUNT_ENFORCE_MFA;
Copy

アカウント管理者のような権限の高いユーザーに二重の MFA を強制したい場合は、このユーザーレベルで MFA を強制します。しかし、 IdP がダウンした場合のブレイクグラス プロシージャと、セキュリティ要件のバランスを取る必要があります。

ALTER USER SUPER_PROTECTED_ACCOUNTADMIN_1
AUTHENTICATION POLICY = ACCOUNTADMIN_DOUBLE_MFA;
Copy

ブレイクグラスの状況用:

ALTER USER BREAKGLASS_ACCOUNTADMIN_1
AUTHENTICATION POLICY = ACCOUNTADMIN_BREAKGLASS_MFA;
Copy

アカウントレベルのネットワークポリシーの適用

最後に、明示的なネットワークポリシーを持っていない他のすべてのユーザーを保護するために、アカウントレベルでネットワークポリシーを適用します。

ALTER ACCOUNT SET
NETWORK_POLICY = ACCOUNT_LEVEL_NET_POLICY;
Copy

未使用ユーザーの無効化

Trust Center CIS スキャナー(1.8)は、過去 90 日間アクティビティを行っていないユーザーを監視します。以下の図に示すように、 Open a Worksheet をクリックすると、非アクティブ・ユーザーのリストを表示するクエリが表示されます。

SELECT
  F.VALUE:ENTITY_ID::VARCHAR AS ENTITY_ID,
  F.VALUE:ENTITY_NAME::VARCHAR AS ENTITY_NAME,
  F.VALUE:ENTITY_OBJECT_TYPE::VARCHAR AS ENTITY_OBJECT_TYPE,
  F.VALUE:ENTITY_DETAIL AS ENTITY_DETAIL
FROM
  SNOWFLAKE.TRUST_CENTER.FINDINGS,
  LATERAL FLATTEN(INPUT => AT_RISK_ENTITIES) AS F;
Copy

Snowflakeは、これらのユーザーを無効にすることを強く推奨します。

第4段階: 継続的モニタリング

Trust Center脅威インテリジェンススキャナーパッケージを活用して、 MFA とネットワークポリシーの実施を監視します。流出したパスワード保護機能により、Snowflakeは盗まれた認証情報をダークウェブで監視し、ダークウェブで発見されたものと一致するパスワードハッシュを持つユーザーを無効にします。また、Snowflakeネイティブアラートを活用し、カスタムのクエリで追加の衛生アラートを構築することもできます。

  • タイプを特にセットしていないユーザー

  • パスワードやキーペアなどの静的な認証情報を持つアプリケーション

  • LEGACY_SERVICE に、新しいユーザーが追加されました。

  • レガシーアプリケーションをより強固な認証にアップグレードするための定期的な働きかけ