A parede entre clientes fica na base de dados, não nas boas intenções
Num software partilhado, o isolamento de dados vale o sítio onde está aplicado. Como a Training App o aplica na base de dados e o testa a cada alteração.
Todo o software na cloud partilhado por vários clientes assenta numa promessa: os seus dados nunca aparecem a outra entidade. A promessa é universal — nenhum fornecedor promete o contrário — e por isso não distingue ninguém. O que distingue é a resposta a uma pergunta que quase nenhum comprador faz: onde, exatamente, está aplicada a separação?
A imagem certa é a de um edifício. Várias entidades formadoras trabalham no mesmo edifício, e há duas maneiras de as separar. Uma são os biombos de um open space: cada equipa vê o seu canto, e a separação existe enquanto todos se portarem bem — está nos ecrãs, nos menus, no que a aplicação decide mostrar. A outra são paredes estruturais: mesmo que alguém se engane no corredor, a porta do vizinho não abre, porque a parede faz parte do prédio e não da decoração. A diferença não se vê numa demonstração comercial. Vê-se no dia em que alguma coisa corre mal.
Na Training App, a separação é estrutural, e vale a pena descrevê-la sem jargão. Cada pedido que chega à plataforma passa por três verificações encadeadas: quem é esta pessoa — a identidade valida-se pela conta Microsoft, não por uma password guardada nossa; a que entidade pertence — quem não tem lugar numa entidade não entra nela, e quem pertence a várias tem de indicar em qual está a trabalhar; e, por fim, a camada que dá o título a este artigo: a própria base de dados só devolve os registos da entidade em causa. A regra de filtragem vive dentro do motor da base de dados, e a aplicação liga-se com um utilizador que não tem privilégios para a contornar. O que isto quer dizer, em termos práticos: mesmo que exista um erro no código da aplicação — e todo o software tem erros —, esse erro encontra a parede por baixo dele. Errar no corredor não abre a porta do vizinho.
Uma parede, porém, vale o que valer a sua manutenção — e a prática interessa mais do que a arquitetura. Cada alteração ao software da Training App passa por um teste automático que faz o papel de intruso: cria duas entidades fictícias, enche-as de dados e tenta, de todas as formas previstas, ver de uma o que pertence à outra. Se qualquer fresta aparecer, a alteração não entra em produção — o teste chumba-a antes de ela chegar a qualquer cliente. O isolamento, mais do que uma característica verificada uma vez no lançamento, é uma condição que cada versão nova tem de voltar a provar.
Convém dizer também o que este artigo não afirma. Nenhum sistema é invulnerável, e uma entidade formadora deve desconfiar de quem lhe prometa o contrário. O que se pode afirmar — e demonstrar — é em que camada a proteção está aplicada e com que frequência é posta à prova. São, aliás, as duas perguntas que recomendamos a qualquer comprador de software, seja a nós ou à concorrência: a separação entre clientes está na base de dados ou apenas naquilo que a aplicação mostra? E é testada a cada alteração, ou foi verificada uma vez e dada por adquirida? Um fornecedor sério responde às duas sem hesitar. As respostas custam pouco a dar — e dizem quase tudo sobre o que está por baixo dos ecrãs.
Trabalha em gestão de formação e automação de processos. Fundou a Training App para simplificar a forma como as entidades formadoras certificadas pela DGERT gerem a sua operação, e acompanha cada cliente desde a implementação até à evolução contínua da plataforma.
Veja a Training App a trabalhar.
30 minutos, com os seus cursos e o seu processo como ponto de partida.