Segurança, conformidade e práticas de dados no DialerBee

Garantido pelo banco de dados, não pelo código da aplicação

A separação é implementada como row-level security no PostgreSQL. Cada consulta é filtrada por tenant no banco de dados, então um erro no código da aplicação não consegue retornar linhas de outro tenant — a fronteira não depende de cada desenvolvedor se lembrar de adicionar uma cláusula WHERE.

FORCE, não apenas ENABLE

A row-level security está habilitada E forçada nas tabelas de tenant. Forçá-la significa que o próprio dono da tabela também está sujeito à política, o que fecha a brecha comum em que o perfil de banco de dados da própria aplicação consegue ler passando por cima das regras.

Negação por padrão, não permissão por padrão

Quando falta o contexto de tenant, a política nega em vez de retornar tudo como alternativa. Uma variável de sessão não definida não retorna nada, que é a falha segura e o oposto do que acontece na abordagem com cláusula WHERE quando alguém esquece um filtro.

A conformidade também falha de forma fechada

O mesmo princípio vale para as ligações: se o serviço de conformidade não puder ser acessado, as ligações são bloqueadas em vez de passarem sem verificação. Um sistema que disca quando não consegue verificar o consentimento é pior do que um que para.

A separação vai além do banco de dados

Pools de números de origem, base de conhecimento e recuperação, gravações, relatórios e identidades de remetente de mensagens são todos restritos ao tenant, então nada atravessa uma fronteira nem nas bordas — o que é essencial quando você opera marcas de terceiros.