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

Imposto pelo banco de dados, não pelo código do aplicativo.

A separação é implementada como segurança em nível de linha no PostgreSQL. Cada consulta é filtrada por locatário no banco de dados, portanto, um erro no código do aplicativo não pode retornar linhas de outro locatário — o limite não depende de cada desenvolvedor se lembrar de adicionar uma cláusula WHERE.

FORÇAR, não apenas HABILITAR

A segurança em nível de linha está habilitada E imposta nas tabelas do locatário. Impor essa segurança significa que o proprietário da tabela também está sujeito à política, o que elimina a brecha usual em que a própria função de banco de dados do aplicativo pode ignorar as regras.

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

Quando o contexto do locatário está ausente, a política nega a solicitação em vez de retornar tudo. Uma variável de sessão não definida não retorna nada, o que representa uma falha segura e é o oposto do que acontece com uma cláusula WHERE quando um filtro é esquecido.

A conformidade também não foi concluída.

O mesmo princípio se aplica às chamadas: se o serviço de conformidade não puder ser contatado, as chamadas são bloqueadas em vez de serem permitidas sem verificação. Um sistema que disca quando não consegue verificar o consentimento é pior do que um que simplesmente para.

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

Os recursos de identificação de chamadas, conhecimento e recuperação de dados, gravações, relatórios e identidades de remetentes de mensagens são todos definidos no escopo do locatário, portanto, nada ultrapassa os limites nas extremidades — o que é fundamental quando você gerencia marcas de terceiros.