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.
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.
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.
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).
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.
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 \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 \ per controllare prima di cambiare qualcosa.
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.
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.
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.
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.
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).
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.
ACCOUNTADMIN ruolo (o un ruolo con CREATE USER e GRANT privilegi)
OpenSSL installato localmente (preinstallato su macOS): solo configurazioni di 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
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;
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.
-- 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.
Perplexity utilizza due viste nello schema SNOWFLAKE.ACCOUNT\_USAGE per creare una mappa dati per la generazione accurata di query:
|
Visualizzazione |
Scopo |
|
|
Esegui query su metadati, prestazioni e modelli di utilizzo |
|
|
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.