Práticas recomendadas de segurança para o Cortex Code CLI¶

Práticas de segurança essenciais para o Cortex Code CLI incluem o uso de métodos de autenticação seguros, proteção de arquivos de configuração, gerenciamento adequado de funções e acesso, tratamento seguro do histórico de conversas, garantia de integridade do servidor MCP e adesão aos protocolos de segurança de produção.

Importante

Em ambientes gerenciados, sua organização pode implantar um arquivo de configurações gerenciadas em nível de sistema que aplica políticas (por exemplo, restringindo o acesso a ferramentas, limitando as contas permitidas ou desativando recursos de bypass). Para obter mais detalhes, consulte Configurações gerenciadas (política da organização).

Credenciais¶

[Recomendado] Use a autenticação baseada em navegador quando possível.

O método de autenticação padrão para o Cortex Code CLI é a autenticação baseada no navegador. Use authenticator = "externalbrowser" no arquivo connections.toml para definir esta opção manualmente.

Use tokens de acesso programático (PATs) ao tentar definir o escopo do acesso a uma função específica.

Geração de PATs dedicados no Snowsight (consulte Uso de tokens de acesso programático para autenticação). Defina a expiração para até 90 dias, use nomes descritivos e alterne regularmente.

Proteção de arquivos de configuração

Use o modo 600 com arquivos de configuração e 700 com diretórios para restringir o acesso apenas ao seu usuário.

chmod 600 ~/.snowflake/connections.toml
chmod 700 ~/.snowflake/cortex

Nunca confirme credenciais

Adicione arquivos de configuração confidenciais a .gitignore.

echo "~/.snowflake/connections.toml" >> ~/.gitignore

Use variáveis de ambiente para manter credenciais e tokens e incorporá-los em seus arquivos de configuração usando a sintaxe ${VARIABLE_NAME}.

Funções e acesso¶

Uso das funções apropriadas por ambiente

Por exemplo, use uma função somente leitura na produção e uma função mais abrangente no desenvolvimento.

[dev]
role = "DEVELOPER"

[prod_readonly]
role = "ANALYST"

Nunca use ACCOUNTADMIN para operações de rotina. Conceda menos privilégios.

Histórico de conversas¶

Conversations are stored in ~/.snowflake/cortex/conversations/. Use cortex --private when starting Cortex Code to disable session saving for sensitive work. Alternatively, use the /clear command to clear the current session before exiting Cortex Code CLI.

Use o modo 700 para restringir o acesso ao histórico de conversas somente ao seu usuário.

chmod 700 ~/.snowflake/cortex/conversations

Segurança MCP¶

Instale apenas os servidores MCP confiáveis

Verifique a fonte e a integridade dos servidores MCP antes de adicioná-los. Use os comandos a seguir para obter uma lista e remover quaisquer servidores não confiáveis:

cortex mcp list
cortex mcp remove <server>

Nunca codifique credenciais de MCP

Use variáveis de ambiente. Primeiro, defina em seu shell:

export GITHUB_TOKEN="your_token"

Em seguida, faça referência a eles na sua configuração de MCP:

{
   "mcpServers": {
      "github": {
         "env": { "GITHUB_TOKEN": "${GITHUB_TOKEN}" }
      }
   }
}

Segurança de produção¶

Ativação do modo de planejamento

Use o comando /plan para revisar as ações pretendidas antes da execução.

/plan
Drop and recreate the ANALYTICS schema

Caso seu token de acesso pessoal seja comprometido¶

Revogue o PAT no Snowsight imediatamente! Em seguida, gere um novo token e comece a usá-lo. Lembre-se de não usar o token nos arquivos de configuração; use variáveis de ambiente.

Review the query history to identify any suspicious activity using the QUERY_HISTORY view in the SNOWFLAKE.ACCOUNT_USAGE schema:

SELECT *
  FROM SNOWFLAKE.ACCOUNT_USAGE.QUERY_HISTORY
  WHERE USER_NAME = '<username>'
  ORDER BY START_TIME DESC;

Configurações gerenciadas (política corporativa)¶

Em algumas organizações, os administradores implantam configurações gerenciadas que aplicam políticas para o Cortex Code CLI. As configurações gerenciadas podem restringir ou substituir a configuração em nível de usuário (incluindo solicitações de permissão e comportamento de bypass).

Para obter mais informações, consulte Configurações gerenciadas (política da organização).

Permissões¶

O Cortex Code tem três modos operacionais:


Modo	Indicador	Comandos de barra	Descrição
Confirmação de ações	Azul ⏵⏵	Modo padrão	Prompts de permissão antes de ações potencialmente perigosas.
Plano	Laranja ⏸	`/plan`, `/plan-off`	Apresenta um plano antes de realizar qualquer ação.
Bypass	Vermelho >>	`/bypass`, `/bypass-off`	Todas as chamadas de ferramentas são aprovadas.

Pressione Shift-Tab no Cortex Code CLI para alternar entre esses modos.

Aviso

O modo bypass desabilita todos os prompts de confirmação. Use-o somente em ambientes confiáveis.

Tipos de permissão¶

Os seguintes níveis de permissão se aplicam às chamadas da ferramenta Cortex Code:


Tipo	Descrição
EXECUTE_COMMAND	Execução dos comandos bash/shell
FILE_READ	Ler conteúdo de arquivos
FILE_WRITE	Criar/modificar arquivos
FILE_EDIT	Editar arquivos existentes
WEB_ACCESS	Operações de pesquisa/busca na web

Modelo de confiança¶

O suporte para este recurso é experimental e pode estar sujeito a alterações. O Cortex Code faz uma tentativa de classificar comandos e operações por risco, conforme mostrado na seguinte tabela:


Nível	Exemplos	Comportamento
SAFE	`ls`, `cat`, `echo`, `grep`	Aprovado automaticamente
LOW	Criar novos arquivos (por exemplo, `touch file.txt`)	Costuma ser aprovado automaticamente
MEDIUM	Edição de arquivos (por exemplo, `nano file.txt`), bash moderado	Prompts no modo de confirmação
HIGH	`rm`, `curl`, `wget`, `sudo`	Sempre solicitado
CRITICAL	`rm -rf`, operações destrutivas	Confirmação extra

Consultas SQL¶

O SQL é categorizado por tipo de operação:


Categoria	Operações	Comportamento
READ_ONLY	SELECT, SHOW, DESCRIBE	Aprovado automaticamente
WRITE	INSERT, UPDATE, DELETE, CREATE	Prompts
USE_ROLE	USE ROLE, USE WAREHOUSE	Prompts

Sandbox¶

A Cortex Code CLI oferece suporte a sandbox para isolar a execução do comando. Para obter todos os detalhes de configuração e uso do sandbox, consulte Sandbox.

Integração de ganchos¶

Você pode personalizar a política de permissão usando ganchos. Aqui está um exemplo de gancho de pré-execução que aprova comandos bash automaticamente:

{
   "hooks": {
      "PreToolUse": [
         {
         "matcher": "Bash",
         "hooks": [
            {
               "type": "command",
               "command": "bash .claude/hooks/auto-approve.sh"
            }
         ]
         }
      ]
   }
}

Esse gancho pode retornar uma resposta JSON como a seguinte para aprovação automática de comandos bash.

{
   "hookSpecificOutput": {
      "hookEventName": "PreToolUse",
      "permissionDecision": "allow",
      "permissionDecisionReason": "Approved by policy"
   }
}

Prompts de permissão e cache¶

Quando o Cortex Code exige sua permissão para continuar uma operação, ele pede detalhes sobre a solicitação. Você pode optar por aprovar ou negar essa solicitação. Você também pode se lembrar da sua escolha para futuras solicitações semelhantes:

«Always allow (this session)» serve para lembrar a escolha até você sair do Cortex Code CLI.
“Always allow (persist)” serve para lembrar indefinidamente.

Essas respostas são armazenadas em cache e com escopo definido para o diretório do projeto, o tipo de ferramenta ou o padrão de comando, conforme apropriado.

As permissões persistentes são armazenadas em ~/.snowflake/cortex/permissions.json. A seguir é mostrado um exemplo de cache:

{
   "/path/to/project": {
      "Bash": {
         "npm test": "allow",
         "make build": "allow"
      },
      "Write": {
         "*": "allow"
      }
   }
}

Exclua este arquivo para redefinir todas as permissões persistentes. Para redefinir permissões para um projeto específico, exclua a entrada correspondente.

Para redefinir o cache da sessão, use o comando /new, que inicia uma nova sessão, ou saia e reinicie o Cortex Code CLI.

Configuração¶

Defina as variáveis de ambiente descritas abaixo para controlar o comportamento da permissão:


Variável	Descrição
`CORTEX_PERMISSION_CACHE_TTL_SECONDS`	Define o tempo limite padrão para o cache de permissões da sessão (em segundos).
`COCO_DANGEROUS_MODE_REQUIRE_SQL_WRITE_PERMISSION=true`	Se definido como `1`, sempre solicite operações de gravação SQL, mesmo no modo bypass

Lista de verificação de segurança¶

Use PATs que expiram em no máximo 90 dias
Defina as permissões de arquivo como 600/700
Nunca confirme credenciais para o git
Use funções de privilégio mínimo
Nunca use ACCOUNTADMIN para trabalhos de rotina
Habilite o modo de planejamento para produção e reserve o modo bypass para ambientes confiáveis
Instale apenas os servidores MCP confiáveis
Armazene credenciais em variáveis de ambiente
Use ganchos para aplicar políticas, automatizando verificações de segurança personalizadas
Faça uma auditoria periódica das permissões