Capabilities: controle o que o próprio banco pode fazer
Por Mauro Mequelussi · Curso gratuito SurrealDB do zero: fundamentos com um CRM · Português (PT-BR)
Resposta direta · O que esta aula resolve
A Aula 18 de 20 ("Capabilities: controle o que o próprio banco pode fazer"), parte do módulo "Segurança" do curso gratuito "SurrealDB do zero: fundamentos com um CRM" na Escola de Aplicativos (ministrado por Mauro Mequelussi), ensina na prática: o aluno descobre como configurar as capabilities do SurrealDB para limitar o que o próprio motor do banco pode executar. Veja na prática como restringir requisições de rede a provedores específicos, controlar o acesso anônimo a vitrines públicas e desativar funções perigosas com flags de linha de comando.
Crie sua conta grátis para assistir a esta videoaula em HD
O resumo técnico e os capítulos abaixo são abertos para consulta. Crie sua conta 100% gratuita em segundos para liberar todas as 20 videoaulas em HD, controle automático de progresso, Tutor IA e certificado gratuito verificável.
- R$ 0 · Sem cartão de crédito
- Tutor IA tira-dúvidas da aula
- Certificado gratuito incluso
O que você vai aprender
- O conceito de capabilities e por que o SurrealDB vem seguro por padrão.
- Como bloquear ou liberar chamadas de rede externas para proteger a rede local.
- Como permitir acesso de convidados anônimos sem comprometer tabelas restritas.
- A diferença entre receber erro explícito ou resultado vazio nas regras de permissão.
- Como criar listas de funções permitidas e negadas para ambientes de produção.
Pontos-chave da aula
- Em capabilities, a regra de negação sempre vence a regra de permissão.
- Nunca utilize allow-all em servidores de produção; prefira listas do que pode rodar.
- O acesso anônimo (allow-guests) ainda respeita rigorosamente a cláusula PERMISSIONS das tabelas.
- Sem permissão de leitura, consultas de convidados retornam vazias em vez de disparar erros.
Capítulos e roteiro técnico da aula
6 capítulos minutados- 00:00
O que são capabilities e por que importam
Entenda por que limitar as ações do próprio motor do banco é fundamental para a segurança da sua infraestrutura.
- 00:35
Regras de segurança e flags de inicialização
Conheça o princípio seguro por padrão do SurrealDB e veja por que negações sempre vencem permissões.
- 01:37
Controle de acesso à rede e chamadas HTTP
Veja como permitir chamadas de rede apenas para serviços específicos e evitar ataques a redes internas.
- 03:03
Acesso de convidados para dados públicos
Aprenda a liberar vitrines de produtos para visitantes sem login sem expor os contatos e vendas do sistema.
- 04:09
Restrição de funções nativas e personalizadas
Descubra como bloquear famílias inteiras de funções ou liberar apenas rotinas aprovadas pela equipe.
- 05:06
Configuração ideal do CRM e próximos passos
Recapitule a receita recomendada de segurança para produção e veja o que esperar do módulo de performance.
Momentos de destaque na prática
Por que limitar o acesso do banco à rede externa
Veja na prática como impedir que uma consulta maliciosa use o seu banco de dados para invadir serviços internos.
Como expor dados públicos com segurança usando convidados
Entenda como permitir visitantes anônimos na sua aplicação sem abrir brechas em tabelas confidenciais.
Notas de aula e guia de estudo
Além de definir quem acessa seus dados, é essencial controlar o que o próprio motor do banco tem permissão de executar dentro da sua infraestrutura. No SurrealDB, esse controle é feito por capabilities, definidas por meio de flags na inicialização do servidor. Nesta aula, você vai aprender a restringir chamadas externas de rede, liberar vitrines públicas com segurança e filtrar funções ativas.
O que você vai aprender
- O conceito de capabilities e por que o SurrealDB vem seguro por padrão.
- Como bloquear ou liberar chamadas de rede externas para proteger a rede local.
- Como permitir acesso de convidados anônimos sem comprometer tabelas restritas.
- A diferença entre receber erro explícito ou resultado vazio nas regras de permissão.
- Como criar listas de funções permitidas e negadas para ambientes de produção.
Pontos-chave
- Em capabilities, a regra de negação sempre vence a regra de permissão.
- Nunca utilize allow-all em servidores de produção; prefira listas do que pode rodar.
- O acesso anônimo (allow-guests) ainda respeita rigorosamente a cláusula PERMISSIONS das tabelas.
- Sem permissão de leitura, consultas de convidados retornam vazias em vez de disparar erros.