Best Practices für die Migration von der Ein-Faktor-Authentifizierung¶

Beispielabfragen für Listen riskanter Benutzer¶

Snowflake hat vor kurzem zwei neue Scanner eingeführt: einen für Benutzer und einen für Service-Benutzer. So können Kunden je nach Benutzertyp getrennte Listen von Benutzern führen, die sich mit einem Ein-Faktor-Kennwort anmelden.

Sie können eine Liste der riskanten Benutzer für jeden Typ zurückgeben.

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
;

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
;

Verteilung der Benutzer auf TYPE und die verwendete Authentifizierungsmethode¶

Zusätzlich zu der vorherigen Abfrage ist es von Vorteil, die Verteilung der Benutzer auf die verschiedenen Benutzertypen und die verwendeten Authentifizierungsmethoden aufzulisten. Dies hilft Kunden bei der strategischen Umstellung von Benutzern auf stärkere Authentifizierungsmethoden wie SAML und OAuth. Wenn zum Beispiel ein Benutzer als riskant angezeigt wird (weil er ein Kennwort in Snowflake hat), dieser Benutzer aber nur die SAML-Authentifizierung verwendet, ist es ratsam, dieses Kennwort so schnell wie möglich aus Snowflake zu entfernen.

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
;

Hinweise zur Migration¶

Im Folgenden finden Sie einige Überlegungen, die Sie bei der Planung Ihrer Migration beachten sollten:

• Legen Sie zunächst die Benutzertypen fest (dies kann über SCIM automatisiert werden).

• Zweitens: Prüfen Sie, welche Authentifizierungsmethoden Ihre Anwendungen unterstützen: Snowflake unterstützt eine Vielzahl von Authentifizierungsmethoden, wie OAuth, SAML, Schlüsselpaar, MFA, und so weiter. Allerdings muss die Anwendung, die eine Verbindung zu Snowflake herstellt, auch starke Authentifizierungsmethoden unterstützen. Es gibt zwei Anwendungsfälle:

  • Die App unterstützt bereits SAML und/oder OAuth. Wir empfehlen Ihnen, so bald wie möglich auf diese Authentifizierung umzusteigen.

  • Die App ist veraltet und unterstützt keine starken Authentifizierungsmethoden wie SAML oder OAuth; sie unterstützt nur Kennwörter. In diesem Fall ist es ratsam, Ihre alte Anwendung zu aktualisieren. In der Zwischenzeit können Sie Netzwerkrichtlinien, die Rotation von Kennwörtern und durchgesickerte Features zum Schutz vor geleakten Kennwörtern nutzen, bis Sie ihre Anwendung aktualisieren.

• Als Nächstes sollten Kunden für lokale Benutzer (die manuell in Snowflake erstellt wurden und nicht SAML- oder OAuth-fähig sind) Folgendes beachten:

  • Bei einer Anwendung, die SSO unterstützt, wechseln Sie den lokalen Benutzer zu SSO-fähigen Benutzern und berücksichtigen Sie die Ausfallzeit beim Benutzerwechsel.

  • Um lokale Benutzer auf SSO-fähig zu wechseln, stellen Sie sicher, dass solche Benutzer in Ihrem IdP existieren und dann in Snowflake manuell oder vorzugsweise automatisch über SCIM bereitgestellt werden.

  • Deaktivieren Sie nicht verwendete lokale Benutzer.

• Snowflake unterstützt Authentifizierungsrichtlinien, Netzwerkrichtlinien und Kennwortrichtlinien sowohl auf Benutzer- als auch auf Kontoebene. Berücksichtigen Sie zuerst die Richtlinien auf Benutzerebene, um sie schrittweise zu migrieren (Richtlinien auf Benutzerebene haben Vorrang vor Richtlinien auf Kontoebene):

  • Snowflake empfiehlt Netzwerkrichtlinien auf Benutzerebene für Anwendungen, die Service-Benutzer verwenden (TYPE = SERVICE oder LEGACY_SERVICE).

  • Für menschliche Benutzer (TYPE = PERSON oder NULL) können Sie mit Netzwerkrichtlinien auf Benutzerebene beginnen und dann Netzwerkrichtlinien auf Kontoebene anwenden, um alle Benutzerpopulationen zu schützen, für die es keine benutzerspezifischen Richtlinien gibt.

  • Das gleiche Konzept mit MFA-Richtlinien beginnt zunächst mit den Richtlinien auf Benutzerebene.

• Wenn Sie eine Legacy-Anwendung haben, die Single Sign-On nicht unterstützt, empfiehlt Snowflake die Nutzung von programmatische Zugriffstoken (PATs), die standardmäßig an bestimmte Rollen gebunden sind, eine Netzwerkrichtlinie erfordern und zeitlich gebunden sind.

Benutzertyp einstellen¶

Der erste Schritt in der Schutzphase besteht darin, die Benutzertypen automatisch über SCIM oder manuell einzustellen:

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

Außerdem können Sie jetzt den Typ des Benutzers festlegen, wenn dieser ein Konto erstellt:

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

Entfernen Sie lokale Kennwörter, wenn sie nicht benötigt werden¶

Nutzen Sie die Abfragen unter Verteilung der Benutzer auf TYPE und AuthN verwendete Methode und Liste riskanter Benutzer, basierend auf den Erkenntnissen des Trust Centers, um mit der Bereinigung aller Kennwörter in Snowflake für einen Benutzer zu beginnen, der bereits ausschließlich SAML, OAuth oder Schlüsselpaar verwendet.

Erstellen Sie Authentifizierungsrichtlinien für Benutzer von Diensten¶

Snowflake empfiehlt die Verwendung von OAuth für Benutzer von programmatischen Diensten, und Sie können dies mit Authentifizierungsrichtlinien erzwingen:

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;

Kunden können immer noch ein Schlüsselpaar für die Authentifizierung mit SERVICE-Benutzern verwenden, aber sie sollten dies mit Netzwerkrichtlinien kombinieren und ihre Schlüssel regelmäßig rotieren.

Erstellen Sie Authentifizierungsrichtlinien, um MFA für menschliche Benutzer zu erzwingen¶

Snowflake empfiehlt, dass Kunden ihre eigenen SAML-Identitätsanbieter (IdPs) mit jeder MFA-Lösung verwenden, die ihre IdP unterstützt. Das folgende Beispiel für eine Authentifizierungsrichtlinien hilft Kunden dabei:

• Snowflake-native MFA für alle menschlichen Benutzer durchzusetzen, die Snowflake-native Kennwörter verwenden.

• Sich auf die SAML IdP des Kunden zu verlassen, um MFA für Benutzer mit Single Sign-On durchzusetzen.

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';

Kunden sollten eine Break-Glass-Situation für den Fall in Betracht ziehen, dass das IdP des Kunden offline ist, sodass sich die Kontoadministratoren immer noch in ihre Snowflake-Konten einloggen können.

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

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';

Kennwortrichtlinie erstellen¶

Falls Sie ein Legacy-System oder eine Break-Glass-Situation haben, in der Sie die nativen Kennwörter von Snowflake verwenden müssen, nutzen Sie die Kennwortrichtlinien von Snowflake, um sie an die Kennwortrichtlinien Ihres Unternehmens anzupassen, falls diese von den Standardrichtlinien abweichen.

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>';

Sitzungsrichtlinie erstellen¶

Snowflake empfiehlt, dass Sie Sitzungsrichtlinien erstellen, um eine erneute Authentifizierung nach einer bestimmten Zeit der Inaktivität zu erzwingen. Dies ist nur ein Beispiel. Sie können die Richtlinien auf der Ebene des einzelnen Benutzers anpassen.

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>';

Erstellen Sie Netzwerkrichtlinien für Benutzer von Diensten¶

Im Allgemeinen sollten Benutzer, die auf Dienste oder Programme zugreifen, von autorisierten IP-Adressen kommen (oder VPCE ID, LinkID, und so weiter, im Falle einer privaten Konnektivität).

Snowflake empfiehlt die Erstellung von Netzwerkrichtlinien auf der Ebene der Dienst-Benutzer, um den Zugriff auf die Benutzer mit programmatischem Zugriff aus autorisierten und vertrauenswürdigen Quellen zu beschränken. Kunden sollten in Erwägung ziehen, Netzwerkregeln auch im internen Stagingbereich durchzusetzen.

Die Verbindungen können aus privaten oder öffentlichen Netzwerken stammen, je nachdem, ob der Kunde eine private Konnektivität nutzt oder nicht. Denken Sie daran, dass Sie sowohl öffentliche als auch private Konnektivität gleichzeitig zulassen können, indem Sie mehrere Netzwerkregeln hinzufügen, die die entsprechenden IPs- (öffentlich oder privat) und/oder CSP-Tags (wie VPCE ID, LinkIDs) enthalten.

-- 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' )
;

Erstellen Sie Netzwerkrichtlinien auf der Ebene des Kontos¶

Richtlinien auf Kontoebene dienen als Standardsicherheits-Netzwerkrichtlinien für Benutzer, auf die keine Netzwerkrichtlinien direkt angewendet werden. Am besten ist es, diese Richtlinien so restriktiv und kurz wie möglich zu halten und gleichzeitig Richtlinien auf Benutzerebene zu verwenden, um spezifische Bedürfnisse der Benutzer zu erfüllen.

Snowflake empfiehlt nicht, riesige Netzwerkrichtlinien auf Kontoebene zu erstellen, um alle Anforderungen des Unternehmens zu erfüllen, sondern ermöglicht stattdessen Richtlinien auf Benutzerebene, die eine genauere Kontrolle ermöglichen.

Ähnlich wie bei den Netzwerkrichtlinien auf Benutzerebene können die Verbindungen aus privaten oder öffentlichen Netzwerken stammen, je nachdem, ob der Kunde eine private Konnektivität nutzt. Denken Sie daran, dass Sie sowohl öffentliche als auch private Konnektivität gleichzeitig zulassen können, indem Sie mehrere Netzwerkregeln hinzufügen, die die entsprechenden IPs- (öffentlich oder privat) und/oder CSP-Tags (wie VPCE ID, LinkIDs) enthalten.

-- 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' )
;

Schutz von Service-Benutzern¶

Benutzer mit TYPE=SERVICE sind von den MFA-Durchsetzungsrichtlinien auf Kontoebene ausgenommen und verfügen über Einschränkungen, um die Sicherheit nicht-interaktiver Anwendungsfälle zu verbessern. Insbesondere können sich Benutzer des Typs SERVICE nicht mit einem Kennwort oder SAML SSO anmelden. Siehe Warnung unten.

-- 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;

Kennwort- und Sitzungsrichtlinien auf der Ebene des Kontos anwenden¶

Der Snowflake-Sicherheitsadministrator sollte grundlegende Kennwort- und Sitzungsrichtlinien auf der Ebene des Kontos anwenden und diese Richtlinien dann bei Bedarf durch Richtlinien auf Benutzerebene außer Kraft setzen.

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

Service-Benutzer testen¶

In diesem Stagingbereich gelten für das Konto Kennwort- und Sitzungsrichtlinien. Die programmatischen Benutzer des Dienstes sind von MFA ausgenommen, und sie haben ihre eigenen spezifischen Authentifizierungsrichtlinien und Netzwerkrichtlinien, die sicherstellen, dass die Verbindungen von vertrauenswürdigen Quellen hergestellt werden und die empfohlenen Authentifizierungsmethoden wie OAuth oder ein Schlüsselpaar verwenden.

Der Sicherheitsadministrator sollte einige Benutzer des Dienstes testen, um einen reibungslosen Betrieb zu gewährleisten und um zu bestätigen, dass die Verbindungen aus vertrauenswürdigen Quellen stammen und die richtigen Authentifizierungsmethoden verwenden. Administratoren sollten zusätzlich zum Trust Center LOGIN_HISTORY verwenden, um zu bestätigen, dass die Benutzer des Dienstes durch Netzwerkrichtlinien geschützt sind.

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

Schützen Sie Ihr Konto mit MFA-Durchsetzung¶

Um MFA für alle Benutzer, die nicht vom Typ SERVICE sind, durchzusetzen, wenden Sie die MFA-Durchsetzungsrichtlinie auf der Ebene des Kontos an.

Diese Richtlinien tragen dazu bei, dass alle menschlichen interaktiven Benutzer MFA entweder über ihre eigene IdP oder über die native Snowflake-MFA aktivieren.

ALTER ACCOUNT SET
AUTHENTICATION POLICY = HUMAN_ACCESS_ACCOUNT_ENFORCE_MFA;

Wenn Sie für Ihre hoch privilegierten Benutzer, wie z. B. Kontoadministratoren, eine doppelte MFA erzwingen möchten, erzwingen Sie MFA auf dieser Benutzerebene. Sie müssen jedoch ein Gleichgewicht zwischen den Break-Glass-Verfahren, falls Ihr IdP ausfällt, und Ihren Sicherheitsanforderungen finden.

ALTER USER SUPER_PROTECTED_ACCOUNTADMIN_1
AUTHENTICATION POLICY = ACCOUNTADMIN_DOUBLE_MFA;

Für eine Break-Glass-Situation:

ALTER USER BREAKGLASS_ACCOUNTADMIN_1
AUTHENTICATION POLICY = ACCOUNTADMIN_BREAKGLASS_MFA;

Netzwerkrichtlinien auf Kontoebene anwenden¶

Schließlich ist es an der Zeit, Netzwerkrichtlinien auf der Ebene des Kontos anzuwenden, um alle anderen Benutzer zu schützen, die nicht über explizite Netzwerkrichtlinien verfügen.

ALTER ACCOUNT SET
NETWORK_POLICY = ACCOUNT_LEVEL_NET_POLICY;

Ungenutzte Benutzer deaktivieren¶

Der Trust Center CIS-Scanner (1.8) überwacht Benutzer, die in den letzten 90 Tagen nicht aktiv waren. Wie in der folgenden Abbildung gezeigt, können Sie auf Open a Worksheet klicken, um die Abfrage anzuzeigen, die die inaktiven Benutzer auflistet:

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;

Snowflake empfiehlt Ihnen dringend, diese Benutzer zu deaktivieren.