Подключение Perplexity к Snowflake

​

О коннекторе Snowflake

Коннектор Snowflake позволяет запрашивать данные в вашем хранилище Snowflake прямо из Perplexity. Вы можете искать и объединять информацию по своим базам данных Snowflake, другим подключённым приложениям и веб‑источникам — без ручного написания SQL и без переключения в консоль Snowflake.

Он доступен на Perplexity Pro, Perplexity Max, Enterprise Pro и Enterprise Max. Snowflake подключается индивидуально каждым пользователем — никто другой в вашей организации не сможет запрашивать ваши данные, если только вы не синхронизируете их в общий Project.

В этом руководстве описано, как работает коннектор, как выбрать способ аутентификации, как настроить роли и доступ только для чтения, а также приведена пошаговая настройка. Если нужен самый короткий путь: большинству организаций стоит использовать User OAuth — переходите сразу к Руководству по настройке.

​

К чему коннектор имеет доступ

После включения коннектор безопасно подключается к вашему аккаунту Snowflake и позволяет искать по базам, схемам, таблицам и представлениям, к которым у вас есть доступ. Когда ваши данные Snowflake меняются, коннектор автоматически отражает эти изменения при следующем запросе.

Поддерживаемые объекты данных:

• Таблицы

• Представления и материализованные представления

• Схемы

• Базы данных

• Структурированные данные (таблицы на базе CSV, JSON и Parquet)

Неструктурированные данные (изображения, аудио и видео, хранящиеся в стейджах Snowflake) не поддерживаются.

​

Выбор способа аутентификации

Аутентификация Snowflake имеет два независимых измерения: кем выполняются запросы (идентификатор) и как этот идентификатор подтверждается (учётные данные). Perplexity предоставляет два коннектора в каталоге, каждый под свою рекомендуемую комбинацию:

• Snowflake (User OAuth) — каждый пользователь Perplexity входит со своей учётной записью Snowflake (TYPE = PERSON) через OAuth. Рекомендуется для большинства организаций.

• Snowflake — все пользователи Perplexity выполняют запросы через единый общий сервисный аккаунт (TYPE = SERVICE) с использованием пары ключей. Используйте, когда у конечных пользователей нет индивидуальных аккаунтов Snowflake.

​

Рекомендуется: User OAuth

С User OAuth каждый человек аутентифицируется собственными учётными данными, запросы выполняются с его штатными разрешениями Snowflake, и вы получаете чёткий журнал аудита по пользователям — без общего сервисного аккаунта и без необходимости заново воспроизводить ролевой контроль доступа (RBAC) внутри Perplexity. Это также соответствует направлению самой Snowflake: их управляемый MCP‑сервер сегодня поддерживает только OAuth 2.0.

Примечание: в OAuth токен доступа привязан к одной основной роли при входе — DEFAULT_ROLE пользователя. Чтобы пользователи могли обращаться ко всему, что им было выдано, настройте вторичные роли (см. Настройка ролей для User OAuth).

​

Резервный вариант: сервисный аккаунт (пара ключей)

Общий сервисный аккаунт (TYPE = SERVICE + пара ключей) подходит, когда:

• У конечных пользователей нет индивидуальных аккаунтов Snowflake (например, бизнес‑пользователи запрашивают данные через Perplexity, но не имеют прямого доступа к Snowflake).

• Вы хотите, чтобы все запросы Perplexity выполнялись под единой общей идентичностью для более простого аудита.

• Вы настраиваете внутреннюю или тестовую среду, где идентификация по пользователю не требуется.

Настройте сервисный аккаунт с выделенной, узко ограниченной ролью — см. Настройка роли сервисного аккаунта.

О Programmatic Access Tokens (PAT): Snowflake также поддерживает учётные данные PAT, и коннектор их принимает. Для новых установок PAT не рекомендуется — токены имеют короткий срок действия и жёстко привязаны к одной роли при создании; поэтому во всех примерах этого руководства мы используем пару ключей. Если вам всё же нужен PAT, установите ROLE_RESTRICTION в вашу выделенную роль Perplexity при создании.

​

Настройка ролей и доступа

​

Настройка ролей для User OAuth

Сессия OAuth открывается с DEFAULT_ROLE пользователя в качестве основной роли; переключение ролей внутри сессии не поддерживается, и Perplexity не показывает выбор роли. Поэтому что у каждого пользователя задано в DEFAULT_ROLE и DEFAULT_SECONDARY_ROLES, ровно то и использует его сессия Perplexity.

Установите это один раз на уровне security integration:

OAUTH_USE_SECONDARY_ROLES = IMPLICIT

По умолчанию Snowflake использует NONE, что означает, что сессии OAuth открываются только с активной основной ролью. Установка значения IMPLICIT говорит Snowflake также автоматически активировать DEFAULT_SECONDARY_ROLES каждого пользователя. Без этого пользователи видят только данные, доступные через DEFAULT_ROLE, — обычно это не то, что нужно.

Затем обработайте один из двух случаев:

Вариант A — у пользователей уже настроены значения ролей по умолчанию. Если у ваших пользователей DEFAULT_ROLE и DEFAULT_SECONDARY_ROLES уже настроены как нужно, делать больше ничего не требуется. Настройки IMPLICIT достаточно — сессия Perplexity каждого пользователя использует его текущие значения.

Вариант B — у пользователей ещё не заданы значения ролей по умолчанию. Дайте каждой сессии объединение всех выданных пользователю ролей, установив DEFAULT_ROLE в PUBLIC, а DEFAULT_SECONDARY_ROLES — в ALL:

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

Примечание: с августа 2024 года в Snowflake DEFAULT_SECONDARY_ROLES = (‘ALL’) — значение по умолчанию для вновь создаваемых пользователей, так что у многих организаций это уже установлено. Выполните DESC USER <username>, чтобы проверить перед изменением.

​

Настройка роли сервисного аккаунта

Сервисный аккаунт — это единичный выделенный пользователь, работающий под одной конкретной ролью, обычно PERPLEXITY_ROLE. Шаблон PUBLIC + (‘ALL’), используемый для OAuth, не применяется здесь. Вместо этого установите DEFAULT_ROLE сервисного пользователя в вашу выделенную роль и выдайте этой роли только те привилегии, которые нужны Perplexity. Это следует рекомендациям Snowflake по сервисным аккаунтам.

Полный SQL для создания такого пользователя приведён в Руководстве по настройке ниже.

​

(Опционально) ограничение ролей, доступных через OAuth

Чтобы ограничить, в какие роли Snowflake пользователи могут аутентифицироваться через интеграцию Perplexity OAuth, задайте это на уровне security integration:

• PRE_AUTHORIZED_ROLES_LIST — список разрешённых ролей для этой интеграции.

• BLOCKED_ROLES_LIST — список запрещённых ролей для этой интеграции.

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

Используйте это, чтобы полностью исключить чувствительные роли (например, ACCOUNTADMIN) из процесса OAuth.

​

Управление тем, что может делать Perplexity

Коннектор выполняет SQL через набор инструментов (взятый из коннектора Merge Snowflake). Коннектор Snowflake (User OAuth) предоставляет детализированные именованные инструменты, включая специальный инструмент только для чтения (execute_sql_readonly), который принимает только SELECT, WITH, SHOW, DESCRIBE, EXPLAIN, VALUES и LIST и отклоняет DDL/DML и ввод из нескольких операторов. Сервисно‑аккаунтный коннектор Snowflake предоставляет общий инструмент execute_sql, принимающий произвольный SQL, включая DDL и DML.

Авторитетный контроль — это Snowflake RBAC. Каким бы инструментом ни воспользовалась система, запросы выполняются под ролью, разрешённой вашей конфигурацией, поэтому обеспечение режима только для чтения на уровне роли Snowflake — надёжный запасной механизм; и это единственная граница обеспечения на сервисно‑аккаунтном коннекторе.

Рекомендуемый шаблон — обеспечьте только чтение выделенной ролью. Заведите роль вроде PERPLEXITY_READ_ONLY, которая выдаёт только USAGE и SELECT на базы данных, схемы и таблицы, к которым Perplexity должен обращаться, и не выдаёт INSERT, UPDATE, DELETE, CREATE, DROP, OWNERSHIP или MODIFY на warehouse. Затем убедитесь, что пользователи аутентифицируются именно в эту роль:

• Установите её как DEFAULT_ROLE пользователя, или

• Ограничьте интеграцию OAuth с помощью PRE_AUTHORIZED_ROLES_LIST и/или исключите роли с правом на запись через BLOCKED_ROLES_LIST (см. Ограничение ролей, доступных через OAuth).

При такой конфигурации RBAC Snowflake отклоняет любую попытку записи со стороны Perplexity, независимо от того, какой инструмент был вызван.

Примечание: в настройках коннектора есть панель Tool permissions со списком доступных инструментов. В коннекторе Snowflake (User OAuth) вы можете сузить набор доступных инструментов — для конфигурации только для чтения включите только инструменты чтения (например, execute_sql_readonly, list_*, describe_*, get_*), чтобы держать инструменты записи/DDL вне доступа. Рассматривайте это как эшелонированную защиту, а не авторитетную границу: Snowflake RBAC (см. выше) — это то, что надёжно обеспечивает доступ.

​

Конфиденциальность и безопасность данных

После подключения коннектор Snowflake может выполнять следующие действия от вашего имени:

• Выполнять SQL‑запросы к вашим данным Snowflake

• Обращаться к Cortex Search и Cortex Analyst

• Запускать пользовательские UDF и хранимые процедуры

Если вы отзываете доступ или удаляете роль в Snowflake, эти данные немедленно становятся недоступны из Perplexity. Если вы отключаете Snowflake в Perplexity, вы можете выбрать, сохранять или удалять кэшированные данные.

​

Безопасность и контроль корпоративного уровня

Для корпоративных организаций Perplexity предлагает сертификат SOC 2 Type II, сквозное шифрование, строгие меры конфиденциальности и детальные средства управления доступом пользователей. Ваши данные Snowflake никогда не используются для обучения ИИ.

Snowflake подключается индивидуально каждым пользователем — никто другой в вашей организации не сможет запрашивать ваши данные. Однако если вы синхронизируете данные в общий Project, любой, у кого есть доступ к этому Project, может выполнять по ним поиск.

Администраторы организации могут включить или отключить коннектор для всех пользователей на экране Permissions в Organization Settings. Обеспечение режимов чтения/записи выполняется на уровне роли Snowflake (см. Управление тем, что может делать Perplexity).

​

Руководство по настройке

Выберите путь, соответствующий вашему способу аутентификации:

• User OAuth (рекомендуется): админ организации один раз настраивает приложение OAuth, затем пользователи входят индивидуально. Переходите сразу к Подключение Snowflake к Perplexity — SQL в шагах 1–6 нужен только для сервисно‑аккаунтных установок.

• Сервисный аккаунт (пара ключей): выполните SQL‑настройку в шагах 1–6, затем подключитесь на шаге 7.

​

Предварительные требования

• Роль ACCOUNTADMIN (или роль с привилегиями CREATE USER и GRANT)

• Установленный локально OpenSSL (предустановлен на macOS) — только для сервисно‑аккаунтных установок

​

Шаг 1: сгенерируйте пару ключей (сервисный аккаунт)

В терминале сгенерируйте закрытый ключ RSA:

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

Затем сгенерируйте соответствующий открытый ключ:

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

​

Шаг 2: создайте роль и warehouse

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;

​

Шаг 3: создайте пользователя сервисного аккаунта

Выполните это под ACCOUNTADMIN. Замените значение RSA_PUBLIC_KEY содержимым вашего файла snowflake_computer_key.pub (без строк заголовка и завершения).

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;

Примечание: TYPE = SERVICE помечает аккаунт как нечеловеческий — не задавайте пароль. DEFAULT_ROLE = PERPLEXITY_ROLE ограничивает его одной выделенной ролью только с нужными Perplexity привилегиями.

​

Шаг 4: выдайте доступ к вашим данным

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

Для более выборочного доступа см. документацию Snowflake GRANT.

​

Шаг 5: выдайте доступ к query history и access history

Perplexity использует два представления в схеме SNOWFLAKE.ACCOUNT_USAGE для построения карты данных с целью точной генерации запросов:

Представление	Назначение
QUERY_HISTORY	Метаданные запросов, производительность и шаблоны использования
ACCESS_HISTORY	Аудит на уровне объектов (только Enterprise Edition)

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

Примечание: ACCESS_HISTORY доступен только в Snowflake Enterprise Edition и выше; на Standard Edition Perplexity автоматически возвращается к QUERY_HISTORY. Пропуск этого шага снижает точность запросов. О том, как Perplexity использует эти представления, см. Понимание карты данных.

​

Проверка доступа

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;

​

Шаг 6: (опционально) разрешите IP‑адреса

Если ваш аккаунт Snowflake ограничивает входящие соединения по IP, добавьте в белый список IP с этой страницы:

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;

​

Шаг 7: подключите Snowflake к Perplexity

​

Для User OAuth: сначала настройка админом

Если ваша организация использует OAuth, админ организации один раз настраивает коннектор Snowflake (User OAuth), прежде чем отдельные пользователи смогут аутентифицироваться. В Organization Settings → Connectors → Snowflake (User OAuth) админ видит панель из трёх шагов:

На шаге 1 создайте security integration на стороне Snowflake. Выполните это под 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’;

Получите Client ID и Client Secret, чтобы вставить обратно в Perplexity:

SELECT SYSTEM$SHOW_OAUTH_CLIENT_SECRETS(‘PERPLEXITY_OAUTH’);

После завершения настройки админом отдельные пользователи могут подключаться по шагам ниже.

​

Подключение (все пользователи)

Пользователи видят только тот метод аутентификации, который соответствует настроенному админом коннектору.

Аутентификация парой ключей (коннектор Snowflake). Введите идентификатор вашего аккаунта Snowflake, имя пользователя и закрытый ключ (snowflake_computer_key.p8).

OAuth (коннектор Snowflake (User OAuth)). Вас перенаправят на Snowflake для входа. Выбора роли нет — ваша сессия использует DEFAULT_ROLE как основную роль, а DEFAULT_SECONDARY_ROLES активируются через OAUTH_USE_SECONDARY_ROLES = IMPLICIT. Если значения по умолчанию для ролей уже настроены, действий не требуется.

Если в вашей сессии не хватает ожидаемых данных, попросите администратора Snowflake проверить ваши DEFAULT_ROLE и DEFAULT_SECONDARY_ROLES (см. Настройка ролей для User OAuth).

​

Использование ваших данных Snowflake

После подключения ссылайтесь на данные Snowflake в задачах Computer. Упоминайте базы, схемы или таблицы — Perplexity будет обращаться к ним в рамках многошаговых сценариев, всё асинхронно в защищённой облачной песочнице. Попробуйте запросы вроде:

• «Обобщи тенденции выручки из таблицы продаж за Q4 и подчеркни ключевые метрики»

• «Найди все записи клиентов, обновлённые за последние 30 дней»

• «Какие продукты показали лучшую динамику по данным аналитической схемы?»

• «Сравни данные пайплайна за этот квартал с показателями предыдущего»

​

Устранение неполадок

​

Snowflake не включён для вашей организации

Если вы в организации Enterprise и не можете включить коннектор, возможно, администратор его отключил. Обратитесь к администратору организации или в поддержку Perplexity.

​

Проблемы подключения и аутентификации

• Убедитесь, что IP‑адреса Perplexity разрешены в сетевой политике Snowflake.

• Убедитесь, что роль имеет привилегии USAGE на нужных warehouses, базах и схемах.

• Попросите пользователей переподключить коннектор после любых изменений политик.

​

Ошибка «Invalid private key»

Убедитесь, что вы вставляете закрытый ключ (snowflake_computer_key.p8), а не открытый. Файл должен начинаться с -----BEGIN PRIVATE KEY-----.

​

Аутентификация отклонена текущей политикой аутентификации

Выполните SHOW AUTHENTICATION POLICIES под ACCOUNTADMIN и убедитесь, что PERPLEXITY_USER покрыт политикой, включающей KEYPAIR. При необходимости:

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

​

OAuth: пользователь видит ограниченный набор данных после подключения

Сессия OAuth использует DEFAULT_ROLE пользователя как основную роль, а вторичные роли активируются через OAUTH_USE_SECONDARY_ROLES = IMPLICIT. Если пользователю недоступно ожидаемое:

• Убедитесь, что в security integration задано OAUTH_USE_SECONDARY_ROLES = IMPLICIT.

• Выполните DESC USER <username> и проверьте DEFAULT_ROLE и DEFAULT_SECONDARY_ROLES — сессия использует ровно то, что там настроено.

• Если у пользователя нет индивидуальной конфигурации ролей и вы хотите, чтобы он получал доступ ко всему, что ему выдано, установите DEFAULT_ROLE = PUBLIC и DEFAULT_SECONDARY_ROLES = (‘ALL’).

• Попросите пользователя отключить и заново подключить коннектор, чтобы получить свежий токен после изменения любых из этих настроек.

​

Представление ACCESS_HISTORY возвращает ошибку

Убедитесь, что ваш аккаунт Snowflake — Enterprise Edition или выше.

​

Недостаточно привилегий на представления ACCOUNT_USAGE

Убедитесь, что GRANT IMPORTED PRIVILEGES был выполнен под ACCOUNTADMIN и что PERPLEXITY_ROLE выдан пользователю.

​

Аутентификация парой ключей не проходит

Повторно выполните DESC USER PERPLEXITY_USER, чтобы убедиться, что отпечаток открытого ключа заполнен.

Если проблемы сохраняются после обновления этих настроек, обратитесь в поддержку Perplexity.