No entanto, existem algumas empresas que temem que seus dados possam ser comprometidos, por isso estamos avaliando outras soluções.
Isso é lamentável, pois os clientes às vezes sofrem com o equívoco de que apenas o isolamento físico pode oferecer segurança suficiente.
Há um artigo interessante do MSDN, intitulado Multi-Tenant Data Architecture , que você pode querer verificar. É assim que os autores abordaram o equívoco em relação à abordagem compartilhada:
Um equívoco comum sustenta que apenas o isolamento físico pode fornecer um nível apropriado de segurança. De fato, os dados armazenados usando uma abordagem compartilhada também podem fornecer segurança de dados forte, mas requerem o uso de padrões de design mais sofisticados.
Quanto às considerações técnicas e de negócios, o artigo faz uma breve análise sobre onde uma determinada abordagem pode ser mais adequada do que outra:
O número, a natureza e as necessidades dos locatários que você espera atender afetam sua decisão de arquitetura de dados de maneiras diferentes. Algumas das perguntas a seguir podem induzi-lo a uma abordagem mais isolada, enquanto outras podem induzi-lo a uma abordagem mais compartilhada.
Quantos inquilinos em potencial você espera atingir? Você pode estar longe de ser capaz de estimar o uso potencial com autoridade, mas pense em termos de ordem de grandeza:você está criando um aplicativo para centenas de inquilinos? Milhares? Dezenas de milhares? Mais? Quanto maior você espera que sua base de inquilinos seja, maior a probabilidade de você querer considerar uma abordagem mais compartilhada.
Quanto espaço de armazenamento você espera que os dados do locatário médio ocupem? Se você espera que alguns ou todos os locatários armazenem grandes quantidades de dados, essa abordagem de banco de dados separado é provavelmente a melhor. (Na verdade, os requisitos de armazenamento de dados podem forçá-lo a adotar um modelo de banco de dados separado de qualquer maneira. Nesse caso, será muito mais fácil projetar o aplicativo dessa maneira desde o início do que mudar para uma abordagem de banco de dados separado posteriormente.)
Quantos usuários finais simultâneos você espera que o locatário médio dê suporte? Quanto maior o número, mais apropriada será uma abordagem mais isolada para atender aos requisitos do usuário final.
Você espera oferecer serviços de valor agregado por locatário, como backup por locatário e capacidade de restauração? Tais serviços são mais fáceis de oferecer por meio de uma abordagem mais isolada.
ATUALIZAÇÃO: Além disso, para atualizar sobre o número esperado de inquilinos.
Esse número esperado de locatários (10k) deve excluir a abordagem de vários bancos de dados, para a maioria, se não todos os cenários. Acho que você não vai gostar da ideia de manter 10.000 instâncias de banco de dados e ter que criar centenas de novas todos os dias.
A partir desse parâmetro sozinho, parece que a abordagem de esquema único de banco de dados compartilhado é a mais adequada. O fato de você armazenar apenas cerca de 50 Mb por locatário e de não haver complementos por locatário torna essa abordagem ainda mais apropriada.
O artigo do MSDN citado acima menciona três padrões de segurança que abordam as considerações de segurança para a abordagem de banco de dados compartilhado:
- Conexões de banco de dados confiáveis
- Filtro de visualização de locatário
- Criptografia de dados do locatário
Quando você estiver confiante com as medidas de segurança de dados do seu aplicativo, poderá oferecer a seus clientes um Acordo de nível de serviço que fornece fortes garantias de segurança de dados. Em seu SLA, além das garantias, você também pode descrever as medidas que você tomaria para garantir que os dados não sejam comprometidos.
ATUALIZAÇÃO 2: Aparentemente os caras da Microsoft mudaram/fizeram um novo artigo sobre esse assunto, o link original sumiu e esse é o novo:Padrões de locação de banco de dados SaaS multilocatário (parabéns a Shai Kerer)
