Collegare Perplexity a Snowflake

​

Informazioni sul connettore Snowflake

Snowflake Connector ti consente di eseguire query sui dati nel tuo data warehouse Snowflake direttamente da Perplexity. Puoi cercare e combinare informazioni nei database Snowflake, nelle altre app connesse e sul Web, senza scrivere SQL manualmente o passare alla console Snowflake.

È disponibile su Perplexity Pro, Perplexity Max, Enterprise Pro e Enterprise Max. La connessione di Snowflake viene effettuata per utente: nessun altro nella tua organizzazione può eseguire query sui tuoi dati a meno che non li sincronizzi con un progetto condiviso.

Questa guida illustra il funzionamento del connettore, come scegliere un metodo di autenticazione, come configurare i ruoli e l’accesso in sola lettura e una configurazione passo passo. Se desideri solo il percorso più veloce: la maggior parte delle organizzazioni dovrebbe utilizzare User OAuth - vai a Guida alla configurazione.

​

A cosa può accedere il connettore

Una volta abilitato, il connettore si connette in modo sicuro al tuo account Snowflake e ti consente di effettuare ricerche nei database, negli schemi, nelle tabelle e nelle visualizzazioni che sei autorizzato a visualizzare. Quando i dati Snowflake cambiano, il connettore riflette automaticamente tali modifiche nella query successiva.

Oggetti dati supportati:

• Tabelle

• Viste e viste materializzate

• Schemi

• Database

• Dati strutturati (tabelle CSV, JSON e con supporto Parquet)

I dati non strutturati (immagini, audio e video archiviati nelle fasi Snowflake) non sono supportati.

​

Scelta di un metodo di autenticazione

L’autenticazione Snowflake ha due dimensioni indipendenti: chi esegue le query (l’identità) e come quell’identità si dimostra (la credenziale). Perplexity fornisce due connettori nella directory, ciascuno abbinato a una combinazione consigliata:

• Snowflake (User OAuth) — ogni utente Perplexity accede con il proprio account Snowflake (TYPE = PERSON) tramite OAuth. Consigliato per la maggior parte delle organizzazioni.

• Snowflake — tutti gli utenti Perplexity eseguono query tramite un unico account di servizio condiviso (TYPE = SERVICE) utilizzando una coppia di chiavi. Utilizzalo quando i tuoi utenti finali non dispongono di account Snowflake individuali.

​

Consigliato: User OAuth

Con User OAuth, ogni persona si autentica con le proprie credenziali, le query vengono eseguite con le autorizzazioni native di Snowflake e ottieni un chiaro audit trail per utente: nessun account di servizio condiviso e nessuna necessità di ricreare il controllo degli accessi basato sui ruoli (RBAC) all’interno di Perplexity. Ciò corrisponde anche alla direzione di Snowflake: il suo server MCP gestito supporta solo OAuth 2.0 oggi.

Nota: Con OAuth, il token di accesso è vincolato a un unico ruolo primario al momento dell’accesso: quello dell’utente DEFAULT_ROLE. Per essere sicuri che gli utenti possano raggiungere tutto ciò che è loro stato concesso, configurare i ruoli secondari (vedi Configurazione del ruolo OAuth dell’utente).

​

Alternativa: account di servizio (coppia di chiavi)

Un account di servizio condiviso (TYPE = SERVICE + coppia di chiavi) è appropriato quando:

• I tuoi utenti finali non dispongono di account Snowflake individuali (ad esempio, gli utenti aziendali che eseguono query tramite Perplexity ma non hanno accesso diretto a Snowflake).

• Desideri che tutte le query Perplexity vengano eseguite con un’unica identità condivisa per un controllo più semplice.

• Stai configurando un ambiente interno o di test in cui non è richiesta l’identità per utente.

Configura l’account di servizio con un ruolo dedicato e con ambito ristretto: vedi Configurazione del ruolo dell’account di servizio.

Una nota sui token di accesso programmatico (PAT): Snowflake supporta anche le credenziali PAT e il connettore le accetta. Non consigliamo PAT per le nuove configurazioni: i token scadono con una pianificazione breve e sono vincolati a un singolo ruolo al momento della creazione, quindi utilizziamo una coppia di chiavi negli esempi di questa guida. Se è necessario utilizzare un PAT, impostare ROLE_RESTRICTION sul tuo ruolo dedicato a Perplexity al momento della creazione.

​

Configurazione di ruoli e accessi

​

Configurazione del ruolo OAuth dell’utente

Una sessione OAuth si apre con il DEFAULT_ROLE dell’utente come ruolo primario; il cambio di ruolo all’interno di una sessione non è supportato e Perplexity non mostra un selettore di ruolo. Quindi qualunque cosa ciascun utente abbia impostato per DEFAULT_ROLE e DEFAULT_SECONDARY_ROLES è esattamente ciò che utilizza la loro sessione Perplexity.

Impostalo una volta, a livello di integrazione della sicurezza:

OAUTH_USE_SECONDARY_ROLES = IMPLICIT

Il valore predefinito di Snowflake per questo parametro è NONE, il che significa che le sessioni OAuth si aprono con solo il ruolo primario attivo. Impostandolo su IMPLICIT dice a Snowflake di attivare automaticamente anche i DEFAULT_SECONDARY_ROLES di ciascun utente. Senza di esso, gli utenti vedono solo i dati raggiungibili tramite il loro DEFAULT_ROLE - raramente quello che vuoi.

Quindi gestisci uno dei due casi:

Caso A: gli utenti dispongono già di ruoli predefiniti. Se i DEFAULT_ROLE e DEFAULT_SECONDARY_ROLES dei tuoi utenti sono già impostati come desideri, non fare nient’altro. L’impostazione IMPLICIT è sufficiente: le impostazioni predefinite esistenti di ciascun utente sono ciò che utilizza la sessione Perplexity.

Caso B: gli utenti non hanno ancora i ruoli predefiniti. Assegna a ciascuna sessione l’unione di tutti i ruoli concessi a quell’utente tramite l’impostazione di DEFAULT_ROLE a PUBLIC e DEFAULT_SECONDARY_ROLES a ALL:

ALTER USER <username> SET DEFAULT_ROLE = PUBLIC, DEFAULT_SECONDARY_ROLES = (‘ALL’);

Nota: Dal cambiamento di Snowflake dell’agosto 2024, DEFAULT_SECONDARY_ROLES = (‘ALL’) è l’impostazione predefinita per gli utenti appena creati, quindi molte organizzazioni hanno già questa impostazione. Esegui DESC USER <username> per controllare prima di cambiare qualcosa.

​

Configurazione del ruolo dell’account di servizio

Un account di servizio è un singolo utente dedicato che viene eseguito con un ruolo specifico, in genere PERPLEXITY_ROLE. Il modello PUBLIC + (‘ALL’) utilizzato per OAuth non si applica qui. Imposta invece il DEFAULT_ROLE dell’utente del servizio sul tuo ruolo dedicato e concedi a quel ruolo solo i privilegi di cui Perplexity ha bisogno. Questo segue le best practice per gli account di servizio di Snowflake.

L’SQL completo per la creazione di questo utente è nella Guida alla configurazione sotto.

​

(Facoltativo) Limitazione dei ruoli che possono essere utilizzati tramite OAuth

Per limitare i ruoli Snowflake in cui gli utenti possono autenticarsi tramite l’integrazione Perplexity OAuth, definisci l’ambito a livello di integrazione della sicurezza:

• PRE_AUTHORIZED_ROLES_LIST — un elenco consentito di ruoli consentiti tramite questa integrazione.

• BLOCKED_ROLES_LIST — un elenco negato di ruoli bloccati da questa integrazione.

ALTER SECURITY INTEGRATION PERPLEXITY_OAUTH
  SET PRE_AUTHORIZED_ROLES_LIST = (‘ANALYST_ROLE’, ‘READ_ONLY_ROLE’);

Usalo per mantenere i ruoli sensibili (ad esempio ACCOUNTADMIN) completamente fuori dal flusso OAuth.

​

Controllare cosa può fare Perplexity

Il connettore esegue SQL attraverso una superficie dello strumento (proveniente dal connettore Snowflake di Merge). Il connettore Snowflake (User OAuth) espone strumenti granulari e denominati, incluso uno strumento di query di sola lettura dedicato (execute_sql_readonly) che accetta solo SELECT, WITH, SHOW, DESCRIBE, EXPLAIN, VALUES e LIST, e rifiuta DDL/DML e input con più istruzioni. Il connettore Snowflake con account di servizio espone uno strumento generale execute_sql che accetta SQL arbitrario, inclusi DDL e DML.

Il controllo autorevole è Snowflake RBAC. Indipendentemente dallo strumento richiamato, le query vengono eseguite con il ruolo consentito dalla configurazione, quindi l’applicazione della sola lettura a livello di ruolo Snowflake è il backstop affidabile ed è l’unico limite di applicazione sul connettore dell’account di servizio.

Modello consigliato: applica la sola lettura con un ruolo dedicato. Fornire un ruolo come PERPLEXITY_READ_ONLY che concede solo USAGE e SELECT sui database, schemi e tabelle su cui vuoi che Perplexity interroghi, e non concede INSERT, UPDATE, DELETE, CREATE, DROP, OWNERSHIP o warehouse MODIFY. Quindi assicurati che gli utenti si autentichino in quel ruolo:

• Impostalo come DEFAULT_ROLE dell’utente, o

• Limita l’ambito dell’integrazione OAuth con PRE_AUTHORIZED_ROLES_LIST e/o escludi i ruoli con capacità di scrittura con BLOCKED_ROLES_LIST (vedere Limitazione dei ruoli che possono essere utilizzati tramite OAuth).

Con RBAC configurato in questo modo, Snowflake rifiuta qualsiasi tentativo di scrittura Perplexity, indipendentemente dallo strumento chiamato.

Nota: Le impostazioni del connettore includono un pannello Autorizzazioni degli strumenti che elenca gli strumenti disponibili. Sul connettore Snowflake (User OAuth) puoi restringere gli strumenti esposti: per una configurazione di sola lettura, abilita solo gli strumenti di lettura (ad esempio execute_sql_readonly, list_*, describe_*, get_*) per mantenere gli strumenti di scrittura/DDL lontani dalla superficie. Trattalo come una difesa in profondità, non come un confine autorevole: Snowflake RBAC (sopra) è ciò che impone in modo affidabile l’accesso.

​

Privacy e sicurezza dei dati

Una volta connesso, Snowflake Connector può eseguire le seguenti azioni per tuo conto:

• Esegui query SQL sui tuoi dati Snowflake

• Esegui query su Cortex Search e Cortex Analyst

• Esegui UDF personalizzate e procedure memorizzate

Se revochi l’accesso o rimuovi un ruolo in Snowflake, tali dati saranno immediatamente inaccessibili da Perplexity. Se disconnetti Snowflake in Perplexity, puoi scegliere se conservare o eliminare i dati memorizzati nella cache.

​

Sicurezza e controllo di livello aziendale

Per le organizzazioni aziendali, Perplexity offre la certificazione SOC 2 Tipo II, crittografia end-to-end, rigorose misure di privacy dei dati e controlli granulari sull’accesso degli utenti. I tuoi dati Snowflake non vengono mai utilizzati per l’addestramento dell’IA.

La connessione di Snowflake viene effettuata per utente: nessun altro nella tua organizzazione può eseguire query sui tuoi dati. Tuttavia, se sincronizzi i dati con un progetto condiviso, chiunque abbia accesso a quel progetto può cercarlo.

Gli amministratori dell’organizzazione possono abilitare o disabilitare il connettore per tutti gli utenti dalla schermata Autorizzazioni in Impostazioni organizzazione. L’applicazione di lettura/scrittura viene gestita a livello di ruolo Snowflake (vedi Controllare cosa può fare Perplexity).

​

Guida alla configurazione

Scegli il percorso che corrisponde al tuo metodo di autenticazione:

• OAuth utente (consigliato): Un amministratore dell’organizzazione configura l’app OAuth una volta, quindi gli utenti accedono individualmente. Vai direttamente a Collega Snowflake a Perplexity — l’SQL nei passaggi da 1 a 6 è solo per le configurazioni dell’account di servizio.

• Account di servizio (coppia di chiavi): Esegui la configurazione SQL nei passaggi da 1 a 6, quindi connettiti nel passaggio 7.

​

Prerequisiti

• ACCOUNTADMIN ruolo (o un ruolo con CREATE USER e GRANT privilegi)

• OpenSSL installato localmente (preinstallato su macOS): solo configurazioni di account di servizio

​

Passaggio 1: generare una coppia di chiavi (account di servizio)

Dal tuo terminale, genera una chiave privata RSA:

openssl genrsa 2048 | openssl pkcs8 -topk8 -inform PEM -out snowflake_computer_key.p8 -nocrypt

Quindi genera la chiave pubblica corrispondente:

openssl rsa -in snowflake_computer_key.p8 -pubout -out snowflake_computer_key.pub

​

Passaggio 2: creare un ruolo e un magazzino

USE ROLE ACCOUNTADMIN;

— Create a dedicated role
CREATE ROLE IF NOT EXISTS PERPLEXITY_ROLE
  COMMENT = ‘Role for Perplexity service account’;

— Create a warehouse (or use an existing one)
CREATE WAREHOUSE IF NOT EXISTS PERPLEXITY_WAREHOUSE
  WAREHOUSE_SIZE = ‘XSMALL’
  AUTO_SUSPEND = 60
  AUTO_RESUME = TRUE
  COMMENT = ‘Warehouse for Perplexity queries’;

— Grant warehouse usage to the role
GRANT USAGE ON WAREHOUSE PERPLEXITY_WAREHOUSE TO ROLE PERPLEXITY_ROLE;

​

Passaggio 3: crea l’utente dell’account di servizio

Esegui questo come ACCOUNTADMIN. Sostituisci il valore RSA_PUBLIC_KEY con il contenuto del tuo file snowflake_computer_key.pub (senza le righe di intestazione e piè di pagina).

USE ROLE ACCOUNTADMIN;

CREATE USER PERPLEXITY_USER
  TYPE = SERVICE
  DEFAULT_ROLE = PERPLEXITY_ROLE
  DEFAULT_WAREHOUSE = PERPLEXITY_WAREHOUSE
  COMMENT = ‘Service account for Perplexity’
  RSA_PUBLIC_KEY = ‘MIIBIjANBgkqhki…your_public_key_here…IDAQAB’;

— Grant the dedicated role to the service account
GRANT ROLE PERPLEXITY_ROLE TO USER PERPLEXITY_USER;

Nota: TYPE = SERVICE contrassegna questo come account non umano: non impostare una password. DEFAULT_ROLE = PERPLEXITY_ROLE lo assegna a un ruolo dedicato con solo i privilegi necessari a Perplexity.

​

Passaggio 4: concedi l’accesso ai tuoi dati

— Grant access to a specific database
GRANT USAGE ON DATABASE MY_DATABASE TO ROLE PERPLEXITY_ROLE;

— Grant access to all schemas in a database (current and future)
GRANT USAGE ON ALL SCHEMAS IN DATABASE MY_DATABASE TO ROLE PERPLEXITY_ROLE;
GRANT USAGE ON FUTURE SCHEMAS IN DATABASE MY_DATABASE TO ROLE PERPLEXITY_ROLE;

— Grant read access to all tables and views (current and future)
GRANT SELECT ON ALL TABLES IN DATABASE MY_DATABASE TO ROLE PERPLEXITY_ROLE;
GRANT SELECT ON FUTURE TABLES IN DATABASE MY_DATABASE TO ROLE PERPLEXITY_ROLE;
GRANT SELECT ON ALL VIEWS IN DATABASE MY_DATABASE TO ROLE PERPLEXITY_ROLE;
GRANT SELECT ON FUTURE VIEWS IN DATABASE MY_DATABASE TO ROLE PERPLEXITY_ROLE;

Per un accesso più selettivo, vedere la Documentazione di GRANT Snowflake.

​

Passaggio 5: concedi l’accesso alla cronologia delle query e alla cronologia degli accessi

Perplexity utilizza due viste nello schema SNOWFLAKE.ACCOUNT_USAGE per creare una mappa dati per la generazione accurata di query:

Visualizzazione	Scopo
QUERY_HISTORY	Esegui query su metadati, prestazioni e modelli di utilizzo
ACCESS_HISTORY	Audit trail a livello di oggetto (solo Enterprise Edition)

USE ROLE ACCOUNTADMIN;
GRANT IMPORTED PRIVILEGES ON DATABASE SNOWFLAKE TO ROLE PERPLEXITY_ROLE;

Nota: ACCESS_HISTORY è disponibile solo su Snowflake Enterprise Edition o versione successiva; Perplexity ricorre automaticamente a QUERY_HISTORY sulla Standard Edition. Saltare questo passaggio riduce la precisione della query. Per come Perplexity utilizza queste visualizzazioni, vedere Comprendere la mappa dei dati.

​

Verifica l’accesso

USE ROLE ACCOUNTADMIN;
GRANT ROLE PERPLEXITY_ROLE TO USER <your_username>;
USE ROLE PERPLEXITY_ROLE;
USE WAREHOUSE PERPLEXITY_WAREHOUSE;
SELECT * FROM SNOWFLAKE.ACCOUNT_USAGE.QUERY_HISTORY LIMIT 5;
SELECT * FROM SNOWFLAKE.ACCOUNT_USAGE.ACCESS_HISTORY LIMIT 5;

​

Passaggio 6: (facoltativo) inserire nella lista consentita gli indirizzi IP

Se il tuo account Snowflake limita le connessioni in entrata in base all’IP, consenti gli IP da questa pagina:

USE ROLE ACCOUNTADMIN;
CREATE NETWORK POLICY PERPLEXITY_COMPUTER_POLICY
  ALLOWED_IP_LIST = (…US IPs from the link above…);
ALTER USER PERPLEXITY_USER SET NETWORK_POLICY = PERPLEXITY_COMPUTER_POLICY;

​

Passaggio 7: collega Snowflake a Perplexity

​

Per l’utente OAuth: prima la configurazione dell’amministratore

Se la tua organizzazione utilizza OAuth, un amministratore dell’organizzazione configura il connettore Snowflake (User OAuth) una volta prima che i singoli utenti possano autenticarsi. In Organization Settings → Connectors → Snowflake (User OAuth), l’amministratore visualizza un riquadro in tre passaggi:

Nel passaggio 1, crea l’integrazione di sicurezza sul lato Snowflake. Esegui questo come ACCOUNTADMIN:

USE ROLE ACCOUNTADMIN;
CREATE SECURITY INTEGRATION PERPLEXITY_OAUTH
  TYPE = OAUTH
  ENABLED = TRUE
  OAUTH_CLIENT = CUSTOM
  OAUTH_CLIENT_TYPE = ‘CONFIDENTIAL’
  OAUTH_REDIRECT_URI = ‘https://ah.merge.dev/oauth/callback’
  OAUTH_ISSUE_REFRESH_TOKENS = TRUE
  OAUTH_REFRESH_TOKEN_VALIDITY = 7776000
  OAUTH_USE_SECONDARY_ROLES = IMPLICIT
  COMMENT = ‘OAuth security integration for Perplexity’;

Recupera l’ID client e il segreto client per incollarli nuovamente in Perplexity:

SELECT SYSTEM$SHOW_OAUTH_CLIENT_SECRETS(‘PERPLEXITY_OAUTH’);

Una volta completata la configurazione dell’amministratore, i singoli utenti possono connettersi utilizzando i passaggi seguenti.

​

Connetti (tutti gli utenti)

Gli utenti vedono solo il metodo di autenticazione corrispondente al connettore configurato dall’amministratore.

Autenticazione tramite coppia di chiavi (connettore Snowflake). Inserisci l’identificatore del tuo account Snowflake, il nome utente e la chiave privata (snowflake_computer_key.p8).

OAuth (connettore Snowflake (utente OAuth)). Verrai reindirizzato a Snowflake per accedere. Non esiste un selettore di ruoli: la tua sessione utilizza il tuo DEFAULT_ROLE come ruolo principale, con il tuo DEFAULT_SECONDARY_ROLES attivato tramite OAUTH_USE_SECONDARY_ROLES = IMPLICIT. Se le impostazioni predefinite del tuo ruolo sono già configurate, non è necessaria alcuna azione.

Se nella tua sessione mancano i dati che ti aspetti di vedere, chiedi al tuo amministratore Snowflake di verificare i tuoi DEFAULT_ROLE e DEFAULT_SECONDARY_ROLES (vedere Configurazione del ruolo OAuth dell’utente).

​

Utilizzando i dati di Snowflake

Una volta connesso, fai riferimento ai tuoi dati Snowflake nei compiti Computer. Menziona database, schemi o tabelle e Perplexity li interrogherà come parte di flussi di lavoro in più fasi, il tutto in modo asincrono in una sandbox cloud sicura. Prova domande come:

• “Riassumi le tendenze dei ricavi dalla tabella delle vendite del quarto trimestre ed evidenzia i parametri chiave”

• “Trova tutti i record dei clienti aggiornati negli ultimi 30 giorni”

• “Quali sono i prodotti con le migliori prestazioni in base allo schema di analisi?"

• "Confronta i dati della pipeline di questo trimestre con quelli del trimestre precedente”

​

Risoluzione dei problemi

​

Snowflake non è abilitato per la tua organizzazione

Se fai parte di un’organizzazione Enterprise e non riesci ad abilitare il connettore, un amministratore potrebbe averlo disabilitato. Contatta l’amministratore della tua organizzazione o contatta il supporto di Perplexity.

​

Problemi di connessione e autenticazione

• Verifica che gli indirizzi IP di Perplexity siano inclusi nella lista consentita nella policy di rete Snowflake.

• Conferma che il ruolo ha USAGE privilegi sui warehouse, i database e gli schemi richiesti.

• Chiedi agli utenti di riconnettersi al connettore dopo eventuali modifiche ai criteri.

​

Errore “Chiave privata non valida”.

Assicurati di incollare la chiave privata (snowflake_computer_key.p8), non la chiave pubblica. Il file dovrebbe iniziare con -----BEGIN PRIVATE KEY-----.

​

Autenticazione rifiutata dalla politica di autenticazione corrente

Esegui SHOW AUTHENTICATION POLICIES come ACCOUNTADMIN e assicurati che PERPLEXITY_USER sia coperto da una politica che comprende KEYPAIR. Se necessario:

CREATE AUTHENTICATION POLICY PERPLEXITY_AUTH_POLICY
  AUTHENTICATION_METHODS = (‘KEYPAIR’)
  CLIENT_TYPES = (‘DRIVERS’);
ALTER USER PERPLEXITY_USER SET AUTHENTICATION POLICY PERPLEXITY_AUTH_POLICY;

​

OAuth: l’utente vede dati limitati dopo la connessione

La sessione OAuth utilizza il DEFAULT_ROLE dell’utente come ruolo primario, con ruoli secondari attivati tramite OAUTH_USE_SECONDARY_ROLES = IMPLICIT. Se un utente non dispone dell’accesso previsto:

• Confermare che l’integrazione della sicurezza abbia OAUTH_USE_SECONDARY_ROLES = IMPLICIT.

• Esegui DESC USER <username> e controlla DEFAULT_ROLE e DEFAULT_SECONDARY_ROLES — la sessione utilizza esattamente ciò che è configurato lì.

• Se l’utente non ha una configurazione del ruolo per utente e desideri che acceda a tutto ciò che gli è stato concesso, imposta DEFAULT_ROLE = PUBLIC e DEFAULT_SECONDARY_ROLES = (‘ALL’).

• Chiedi loro di disconnettersi e ricollegarsi al connettore per emettere un nuovo token dopo aver modificato una di queste impostazioni.

​

La vista ACCESS_HISTORY restituisce un errore

Verifica che il tuo account Snowflake sia Enterprise Edition o superiore.

​

Privilegi insufficienti sulle visualizzazioni ACCOUNT_USAGE

Verificare che GRANT IMPORTED PRIVILEGES sia stato eseguito come ACCOUNTADMIN e che PERPLEXITY_ROLE sia concesso all’utente.

​

L’autenticazione della coppia di chiavi non riesce

Rieseguire DESC USER PERPLEXITY_USER per confermare che l’impronta digitale della chiave pubblica sia popolata.

Se i problemi persistono dopo aver aggiornato queste impostazioni, contatta il supporto di Perplexity per assistenza.