Arquitetura de dados para múltiplos inquilinos

Introdução

A Confiança, ou a falta dela, é a principal razão para a não adoção do Software como Serviço (Software as a service - SaaS). Os dados são os bem mais importantes de qualquer negócio - dados sobre produtos, clientes, empregados, fornecedores e etc. Esses dados, é claro, são o coração do SaaS. Aplicações SaaS oferecem aos clientes um acesso centralizado às informações, por um custo muito menor se comparado a uma aplicação executando localmente. Mas, desde que se queira tirar vantagem de todos os benefícios do SaaS, uma organização precisa adaptar seus próprios dados a um determinado nível de controle e confiar no fornecedor de soluções de SaaS - para se manter segura e longe de olhos curiosos.
Para se adquirir essa confiança, uma das mais altas prioridades para o futuro da Arquitetura SaaS é a criação de uma arquitetura de dados que seja robusta e segura o bastante para satisfazer parceiros e clientes - preocupados com um eficiente controle dos dados empresariais (vitais para terceiros), ao mesmo tempo em que estes possuam uma boa relação de custo / benefício no gerenciamento e administração.
Este é o segundo artigo de nossa série sobre a criação de aplicações para múltiplos inquilinos. O primeiro artigo, Estratégias arquitetônicas para capturar a longa cauda, introduziu o modelo SaaS a um nível mais elevado e discutiu seus desafios e benefícios - está disponível no MSDN. Outros artigos desta série focarão em tópicos como workflow e criação de interface de inquilino, segurança, etc.
Neste artigo, focaremos na extensão entre um modelo isolado e um modelo compartilhado de dados, e identificaremos três abordagens distintas para criação de arquiteturas de dados - designadas para diferentes situações durante essa extensão. Depois, exploraremos alguns dos fatores técnicos e de negócios que devem ser considerados antes de se decidir sobre qual das abordagens usar. Finalmente, apresentaremos padrões de criação para garantir a segurança, a criação de modelos de dados extensíveis e a infra-estrutura de dados escaláveis.

Inicio da pagina

Três Abordagens para o Gerenciamento de dados com Múltiplos inquilinos

A distinção entre dados compartilhados e isolados não é binária. Além disso, há mais extensibilidade, com muitas variações possíveis entre dois extremos.

A arquitetura de Dados é uma área na qual o nível de otimização de isolamento para uma aplicação SaaS, pode variar significativamente - dependendo das considerações técnicas e de negócios. Arquitetos de dados mais experientes estão acostumados a considerar uma grande variedade de opções ao criar uma arquitetura para resolução de um caso específico, e o SaaS não é exceção. Devemos examinar três amplas abordagens, cada qual com diferentes posicionamentos sobre a extensão de um modelo isolado para um modelo compartilhado.

Banco de dados Separados
Armazenar dados de inquilinos em banco de dados separados é o modo mais simples de se obter um modelo de dados isolado.

Figura 1. Esta abordagem usa um banco de dados distinto para cada Inquilino (Tenant)
Os recursos da máquina (e da aplicação) são geralmente compartilhados entre todos os inquilinos de um mesmo servidor, mas cada inquilino tem suas próprias informações, que permanecem isoladas - de maneira lógica - dos dados pertencentes a outros inquilinos. Os Metadados fazem a associação de cada um dos bancos de dados com o inquilino correto, e a segurança desse banco de dados evita que qualquer inquilino, acidentalmente ou não, acesse os dados de outro inquilino.
Atribuir um banco de dados para cada inquilino torna fácil a extensão do modelo de dados de uma aplicação (discutido posteriormente) para o atendimento às necessidades individuais desse próprio inquilino. Além disso, restaurar os dados de um inquilino, em caso de falhas, é um procedimento relativamente simples. Infelizmente, essa abordagem gera custos mais altos no gerenciamento do equipamento e backup dos dados. Os custos de hardware também são elevados - se comparados a abordagens alternativas - na medida em que houver um aumento no número de inquilinos hospedados nesse servidor - e este possuir alguma limitação no número de banco de dados suportados. (Utilizando o autoclose para descarregar um banco de dados da memória - quando não houver conexões ativas - pode fazer com que uma aplicação tenha mais performance, por incrementar o número de banco de dados que cada servidor pode suportar).
Separar os dados de cada inquilino em banco de dados individuais é uma abordagem recomendada, e os requerimentos e custos relativos a hardware e gerenciamento o tornam apropriado aos clientes que estejam dispostos a pagar por mais segurança e customização. Por exemplo, clientes que atuem com o gerenciamento de registros bancários - ou, outro exemplo, registros médicos - necessitam proteger suas informações e nem podem considerar uma aplicação que não utilize um banco de dados separado para cada inquilino.
Banco de dados compartilhado, Esquemas Separados.
Outra abordagem envolve o armazenamento das informações de múltiplos inquilinos num mesmo banco de dados - cada inquilino com o seu próprio conjunto de tabelas, agrupadas em um esquema criado especificamente para o inquilino.

Figura 2. Nesta abordagem, cada inquilino (Tenant) possui seu próprio conjunto de tabelas numa mesma base de dados. (Tenant)
Quando um cliente inscreve-se pela primeira vez num serviço, o sistema de provisionamento cria um discreto conjunto de tabelas para o inquilino e o associa ao seu próprio esquema. Você pode usar o comando SQL CREATE para criar um esquema e autorizar uma conta de inquilino para acessá-lo. Por exemplo, no Microsoft SQL Server 2005:

CREATE SCHEMA ContosoSchema AUTHORIZATION Contoso
 

A aplicação pode então, criar e acessar tabelas com o esquema do inquilino usando a convenção SchemaName.TableName:

CREATE TABLE ContosoSchema.Resumes (EmployeeID int identity primary key, Resume nvarchar(MAX))
 

Após a criação do esquema, ele se torna definido como padrão para a conta do inquilino:

ALTER USER Contoso WITH DEFAULT_SCHEMA = ContosoSchema 
 

Uma conta de inquilino pode acessar tabelas especificando apenas, através do esquema padrão, o nome da tabela - ao invés de usar a convenção SchemaName.TableName. Dessa maneira, uma simples instrução SQL pode ser criada para todos os inquilinos, através da qual cada um deles pode acessar suas próprias informações:

SELECT * FROM Resumes
 

Da mesma forma que o método de isolamento, essa separação de esquemas é relativamente fácil de ser implementada, e os inquilinos podem, facilmente, estender o modelo de dados. (Tabelas são criadas de um conjunto de padrões, porém, uma vez criadas elas não necessitam mais estar em conformidade com esse conjunto de padrões, e os inquilinos podem adicionar ou modificar colunas e, até mesmo, tabelas, da forma que desejarem.) Essa abordagem oferece um grau moderado da lógica de isolamento de dados e da segurança para os inquilinos, apesar de não ser igual ao modelo de isolamento total, e pode suportar um grande número de inquilinos por base de dados.
Um ponto fraco no esquema separado é que os dados do inquilino são mais difíceis de serem restaurados no caso de uma falha. Se cada inquilino possuir sua própria base de dados, restaurar uma única base de dados significa simplesmente, restaurar o banco de dados através do backup mais recente. Com uma aplicação utilizando-se de um esquema separado, restaurar por completo um banco de dados pode significar a sobreposição dos dados de cada um dos inquilinos numa mesma base de dados com os dados do backup - sem levar em consideração se houveram, ou não, perdas. Além disso, para restaurar uma simples informação de um consumidor, o administrador do banco talvez tenha que restaurar a base de dados para um servidor temporário e depois importar as tabelas do cliente para um servidor de produção - uma tarefa potencialmente perigosa e demorada.
A abordagem através da separação de esquemas é apropriada para aplicações que usem um relativo (e pequeno) número de tabelas de banco de dados, na ordem de 100 tabelas por inquilino - ou menos. Essa abordagem pode acomodar mais inquilinos por servidor em relação a uma abordagem de banco de dados separados, assim pode-se oferecer uma aplicação a um custo menor, enquanto seus clientes aceitarem ter seus dados co-alocados com os de outros inquilinos.
Banco de dados compartilhado, Esquema compartilhado.
Uma terceira abordagem envolve o uso de um mesmo banco de dados e conjunto de tabelas para a hospedagem de múltiplas informações, de múltiplos inquilinos. Uma determinada tabela pode incluir registros vindos de múltiplos inquilinos, armazenados em qualquer ordem; e uma coluna com o ID de cada inquilino associa cada registro com o inquilino apropriado.

Figura 3. Nesta abordagem, todos os inquilinos (Tenant) compartilham um mesmo conjunto de tabelas, e um ID para cada inquilino associa-o aos seus próprios registros.
Das três abordagens aqui apresentadas, a que se utiliza de um esquema compartilhado possui o menor custo de hardware e backup - por permitir a você servir o maior número de inquilinos por servidor. Entretanto, por causa desse compartilhamento, essa abordagem pode propiciar um esforço adicional de desenvolvimento na área de segurança - para garantir que inquilinos nunca possam se associar a dados de outros inquilinos, mesmo com a ocorrência de ataques ou bugs inesperados.
O procedimento para restauração de dados é similar à abordagem que utiliza o esquema compartilhado, com uma complicação adicional; as linhas individuais dentro de um banco de dados de produção precisarão ser apagadas e então re-inseridas no banco de dados temporário. Se houver um grande número de linhas nas tabelas afetadas, isso pode causar uma significativa queda de desempenho a todos os inquilinos que se utilizam desse banco de dados.
A abordagem com esquema compartilhado é apropriada quando se é importante que a aplicação seja capaz de servir um grande número de inquilinos com um pequeno número de servidores, e que possíveis clientes estejam dispostos a mudar de um modelo com isolamento de dados, em troca de menores custos - decorrentes da adoção desta abordagem.

Inicio da pagina

Escolhendo uma Abordagem

Cada uma das três abordagens descritas anteriormente, oferece seus próprios conjuntos de benefícios e regras de troca que as tornam um modelo apropriado para se seguir, ou não, em alguns casos, a serem determinados pelo número de considerações técnicas e de negócios. Algumas dessas considerações são listadas abaixo:
Considerações Econômicas
Aplicações otimizadas por uma abordagem de compartilhamento, requerem um grande esforço de desenvolvimento - em relação a aplicações criadas por uma abordagem de isolamento - (por causa da relativa complexidade do desenvolvimento em uma arquitetura compartilhada), resultando em custos iniciais maiores. Por causa de sua capacidade em suportar mais inquilinos por servidor, entretanto, o andamento dos custos operacionais tende a ser mais baixo.

Figura 4. Custo sobre o tempo para um hipotético par de aplicações SaaS; uma utiliza uma abordagem de isolamento, enquanto a outra utiliza uma abordagem mais compartilhada.
Os esforços de desenvolvimento podem sofrer pressão de fatores econômicos e empresariais, influenciando na escolha da abordagem. O esquema com compartilhamento pode gerar uma grande economia financeira ao final de um grande projeto, mas requer um grande esforço inicial na fase de desenvolvimento, antes que esta possa gerar rendimentos. Se você não está disposto a empregar tanto capital na fase inicial de desenvolvimento, ou se precisa levar sua aplicação ao mercado o mais rápido possível, você pode considerar uma abordagem mais isolada.
Considerações de Segurança
Na medida em que sua aplicação armazenar dados sigilosos dos inquilinos, estes terão grandes expectativas no que diz respeito à segurança, e o seu SLAs (Service Level Agreements - Acordo de Níveis de Serviços) necessitará prover garantias de segurança a esses dados. Uma concepção errada, e comum, baseia-se na idéia de que apenas um isolamento físico pode prover um nível de segurança apropriado. Dados armazenados através de uma abordagem com compartilhamento também podem contar com um forte esquema de segurança, mas requerem o uso de padrões mais sofisticados de design.
Considerações sobre inquilinos
O número, a natureza e as necessidades dos inquilinos que você espera servir, afetarão a decisão sobre a concepção da arquitetura de dados de diferentes maneiras. Algumas das seguintes questões talvez lhe influenciem a uma abordagem com mais isolamento, enquanto outras talvez o levem a uma abordagem mais compartilhada.

• Quantos inquilinos você espera ter? Talvez as estimativas em relação à utilização de sua aplicação não estejam nem perto de uma futura demanda. Mas pense em termos de magnitude: você está construindo uma aplicação para centenas de inquilinos? Milhares? Milhões? Mais? Quanto maior a expectativa em relação à base de inquilinos, maior a probabilidade de se considerar um modelo com compartilhamento.
  
• Quanto espaço de armazenamento será ocupado, em média, pelos dados dos inquilinos? Se você espera que algum dos inquilinos tenha uma enorme quantidade de dados, uma abordagem com uma separação dos dados talvez seja melhor. (De fato, os requerimentos de armazenamento podem forçá-lo a adotar um modelo de banco de dados separado. Se for o caso, será muito mais fácil criar a aplicação de uma determinada maneira no começo e, posteriormente, mudá-la para a abordagem que separa o banco de dados).
  
• Quantos inquilinos finais, em média, serão suportados? Quanto maior o número, mais apropriado será o uso de uma abordagem com isolamento, para suprir a necessidade dos inquilinos.
  
• Você pretende oferecer algum serviço agregado por inquilino, como backup e restore? Tais serviços são fáceis de serem oferecidos através de uma abordagem com isolamento.
  

Figura 5. Fatores relacionados a inquilinos e como eles afetam as decisões de arquitetura de dados "isolados versus compartilhados".
Considerações de Reparo
Companhias, organizações e governos estão sujeitos às mudanças na lei que podem afetar as necessidades de segurança e armazenamento. Esteja a par dessas mudanças, que ocorrem no ambiente de seus clientes, o qual você pretende alcançar, e determine quando estas podem apresentar mudanças as quais tenham o poder de afetar sua decisão.
Considerações sobre o conjunto de habilidades
Criar uma única instância ou uma arquitetura para múltiplos inquilinos continua sendo uma habilidade relativamente nova, de modo que é difícil para um profissional alcançar uma experiência significativa. Se os seus arquitetos e sua equipe de suporte não possuem um grande nível de experiência na construção de aplicações SaaS, será necessário adquirir o conhecimento para tal - ou você terá que contratar pessoas com experiência no assunto. Em alguns casos, uma abordagem com mais isolamento, pode permitir à sua equipe um avanço nas habilidades de desenvolvimento tradicional de software em relação a uma abordagem com compartilhamento.
Concretizando a Arquitetura de Dados para múltiplos inquilinos
O restante deste artigo detalha alguns padrões que podem ajudar no planejamento e na construção de uma aplicação SaaS. Conforme discutido em nosso artigo inicial, uma aplicação SaaS bem planejada distingui-se em três qualidades: escalabilidade, configurabilidade e eficiência para múltiplos inquilinos. A tabela abaixo lista os padrões apropriados para cada uma dessas três abordagens, divididas em seções que representam essas três qualidades.
A otimização para uma maior eficiência num ambiente de compartilhamento não pode comprometer o nível de segurança e proteção no acesso aos dados. Os padrões de segurança listados abaixo demonstram como você pode criar uma aplicação com "isolamento virtual" através de mecanismos como permissões, views do SQL e criptografia.
A configurabilidade permite aos inquilinos do SaaS a alteração da maneira que a aplicação aparece e se comporta, sem requerer uma instância de aplicação separada para cada inquilino. Os padrões de extensibilidade descrevem possíveis alternativas para a implementação de um modelo de dados que pode ser estendido pelos inquilinos e configurados individualmente para atender suas necessidades.
A abordagem escolhida para arquitetura de dados de sua aplicação SaaS afetará as opções disponíveis para que você a torne escalável, de modo a acomodar mais inquilinos ou ter uma performance maior. Os padrões de escalabilidade endereçam diferentes desafios propostos pelo aumento dos bancos de dados compartilhados e dedicados.
Tabela 1. Padrões apropriados para uma Aplicação SaaS.

Abordagem	Padrões de Segurança	Padrões de Extensibilidade	Padrões de Escalabilidade
Banco de dados separados	Conexões confiáveis a Banco de Dados Tabelas Seguras de Banco de Dados Criptografia de Dados do Inquilino	Colunas Customizadas	Aumento estrutural para um único Inquilino
Banco de dados Compartilhado, Esquemas separados	Conexões confiáveis a Banco de Dados Tabelas Seguras de Banco de Dados Criptografia Dados do Inquilino	Colunas Customizadas	Particionamento Horizontal baseado no Inquilino
Banco de Dados Compartilhado, Esquemas compartilhados	Conexões confiáveis a Banco de Dados Filtro de visualização do inquilino Criptografia de Dados do Inquilino	Campos pré-alocados Pares de Nome-Valores	Particionamento Horizontal baseado no Inquilino

Padrões de Segurança
Construir um mecanismo de segurança adequado para cada aspecto de uma aplicação é uma tarefa enorme o bastante para qualquer Arquiteto de SaaS. Promover o SaaS significa, basicamente, pedir a clientes em potencial que abram mão de algum controle sobre seus dados. Dependendo da aplicação, isso inclui informações extremamente sigilosas sobre finanças, estratégias de negócios, dados sobre funcionários e etc. Uma aplicação SaaS confiável oferece um alto nível de segurança, através da utilização de vários níveis de defesa, que se complementam uns aos outros, para proteger os dados de diferentes maneiras, sob diferentes circunstâncias e contra problemas internos e externos.
A segurança em uma aplicação SaaS consiste na análise de diferentes maneiras de se pensar sobre os locais com incidência de riscos e como endereçá-los. Os padrões de segurança discutidos nesta seção contam com três padrões, utilizados como base para oferecer tipos apropriados de segurança:
Filtragem: Utilize uma camada intermediária entre o inquilino e a base de dados, para servir como um selecionador (peneira), fazendo com que os dados apareçam ao inquilino como se fossem os únicos na base de dados.
Permissões: Usando o ACL (listas para controle de acesso) para determinar quem pode acessar dados na aplicação e o que esta pessoa pode fazer com eles.
Criptografia: Obscurece todos os dados sigilosos do inquilino, de forma que estes permaneçam inacessíveis a grupos não-autorizados - mesmo que estes tenham acesso a esses dados.
Mantenha esses padrões em mente enquanto lê o restante desta seção.
Conexões de Banco de Dados confiáveis
Num ambiente de aplicação com múltiplas camadas, os arquitetos tradicionalmente se utilizam de dois métodos para garantir o acesso seguro aos dados armazenados: personificação, e um sub-sistema de contas seguras.
Com o método de acesso personificado, o banco de dados é configurado para permitir que inquilinos distintos acessem diferentes tabelas, views, consultas, stored procedures e outros objetos do banco de dados. Quando o inquilino final realiza uma ação que, direta ou indiretamente, requer uma chamada à base de dados, a aplicação "se apresenta" para o banco de dados como o inquilino, literalmente personificando-o com o propósito de acessar a base de dados. (Em termos técnicos, a aplicação emprega o contexto de segurança do inquilino). Um mecanismo como o Kerberos pode ser usado para permitir que o processo da aplicação conecte-se ao banco de dados em nome do inquilino.

Figura 6. Uma aplicação conecta-se a um Banco de dados utilizando a personificação
Com o método de acesso do sub-sistema, a aplicação sempre se conecta a base de dados utilizando seu próprio processo de identificação, independente da identidade do usuário; o servidor então garante o acesso da aplicação aos objetos do banco de dados que podem ser lidos e manipulados pela mesma. Qualquer segurança adicional deverá ser implementada com a aplicação em si para prevenir que usuários finais acessem quaisquer objetos de banco de dados que não devam ser expostos a ele. Essa abordagem facilita o gerenciamento da segurança, eliminando a necessidade de se configurar o acesso à base de dados baseando-se no usuário - porém, isso significa delegar a segurança do banco de dados aos inquilinos.

Figura 7. Uma aplicação conecta-se a um banco de dados através de um sub-sistema confiável.
Em uma aplicação SaaS, o conceito de "usuários" é um pouco mais complexo em relação às aplicações tradicionais, por causa da distinção entre um inquilino e um usuário final. O inquilino é uma organização que se utiliza da aplicação para acessar seu próprio depósito de dados (logicamente isolado de outros depósitos de dados, pertencentes a outros inquilinos). Cada inquilino garante acesso à aplicação para um ou mais usuários finais, permitindo que estes acessem uma parte dos dados do inquilino através da conta de usuário final - que é controlada pelo próprio inquilino.
Nesse cenário, você pode utilizar uma abordagem híbrida para o acesso a dados, que combina ambos os aspectos da personificação e dos métodos de acesso confiável através de sub-sistemas. Isto permite a você tirar vantagem do mecanismo de segurança nativa que fortalece o isolamento lógico dos dados do inquilino, sem que se crie um complexo e improdutivo modelo de segurança.

Figura 8. Uma aplicação SaaS conecta-se a um banco de dados usando uma combinação de personificação e do acesso confiável através de sub-sistemas.
Essa abordagem envolve a criação de uma conta para acesso a um banco de dados de cada inquilino, e o uso do ACLs (Access Control List - Lista de Controle de Acesso) para garantir que cada uma dessas contas tenha acesso aos objetos num banco de dados onde esse inquilino tenha permissão de uso. Quando um usuário final realiza uma ação que, direta ou indiretamente, requer uma chamada ao banco de dados, a aplicação utiliza as credenciais associadas com a conta do inquilino, ao invés de usar uma associação com a conta do usuário final. (Uma maneira da aplicação obter credenciais apropriadas é através da personificação, em conjunto com sistema de credenciamento como o Kerberos. Uma segunda maneira é o uso de um token de segurança que retorne um conjunto atualizado de credenciais de login criptografado e estabelecido pelo inquilino, e que possa ser submetido ao banco de dados pelo processo da aplicação). O servidor de banco de dados não faz distinção entre solicitações originadas de diferentes usuários finais, associados a um mesmo inquilino, garantindo acesso de todas essas solicitações aos dados. Em conjunto com a aplicação, um código de segurança previne que usuários finais recebam e modifiquem quaisquer informações nos quais ele não tenha acesso.
Por exemplo, considere o usuário final de um CRM, que execute uma operação de consulta a uma base de dados para a gravação de registros de clientes que combinem com certa string. A aplicação submete a consulta ao banco de dados usando o contexto de segurança do inquilino, então, ao invés de retornar todos os registros que atendem a essa solicitação, a consulta retorna apenas os resultados coinscidentes das tabelas que o inquilino pode acessar. Até aí tudo bem, mas suponha que a regra para usuários finais permita apenas o acesso a registros de clientes locados em uma determinada região. (para maiores informações sobre regras, veja a seção "Autorização" em Estratégias arquitetônicas para capturar a longa cauda - o primeiro artigo dessa série). A aplicação precisa capturar os resultados da consulta e somente apresentá-los ao usuário que tenha o direito de acesso a essas informações.
Tabela de Banco de dados Segura
Para tornar segura uma tabela (ou qualquer outro objeto) de um banco de dados, utilize o comando SQL's GRANT para garantir o acesso pela conta do inquilino:

GRANT SELECT, UPDATE, INSERT, DELETE ON [TableName] FOR [UserName]
 

Isso adiciona a tabela ACL à conta do inquilino. Se você utiliza uma abordagem híbrida para o acesso à base de dados (conforme mencionado anteriormente), no qual os usuários finais estão associados ao contexto de segurança de seus respectivos inquilinos, isso só terá de ser feito uma única vez, durante o provisionamento do processo do inquilino; qualquer conta de usuários finais criadas pelo inquilino estarão aptas a acessar a tabela.
Esse padrão é apropriado para o uso com um banco de dados e esquemas com separação. Na abordagem por banco de dados separados, podem-se isolar os dados simplesmente restringindo o acesso ao nível de banco de dados, associado ao inquilino, ainda que se possa, também, usar esse padrão numa tabela para a criação de outra camada de segurança.
Filtro de Visualização do Inquilino
As views do SQL podem ser utilizadas para garantir acesso individual para alguns dos registros de uma determinada tabela, ao mesmo tempo em que restringe o acesso a outros registros.
No SQL, uma view é uma tabela virtual, definida pelos resultados de uma consulta realizada com um SELECT. Essa view pode, então, ser consultada e utilizada em uma stored procedure como se fosse uma tabela de um banco de dados. Por exemplo, a seguinte instrução SQL cria uma view baseada em uma consulta à tabela Employees, que foi filtrada de modo que apenas os registros pertencentes a um único inquilino estão visíveis:

CREATE VIEW TenantEmployees AS 
SELECT * FROM Employees WHERE TenantID = SUSER_SID ()
 

Essa instrução obtém o SID (Secure Identifier - Identificador de Segurança) de uma conta de inquilino acessando o banco de dados (que, conforme explicado anteriormente, é uma conta de inquilino - e não de usuário final) e o utiliza para determinar quais linhas deverão ser incluídas na view. (O exemplo assume que o número ID do inquilino é único e idêntico ao seu SID. Se esse não for o caso, mais um passo adicional será requerido para associar cada inquilino ao registro correto.) Cada conta individual de acesso aos dados do inquilino terá permissão garantida para o uso da view TenantEmployees, mas não terá permissões na tabela Employees. Você pode construir consultas e procedures compartilhadas para tirar vantagem das views, que fornecem aos inquilinos o aspecto de isolamento de dados, mesmo em uma base de dados com múltiplos inquilinos.
Esse padrão é um pouco mais complexo em relação ao utilizado para a segurança de tabelas, mas é uma maneira mais apropriada para assegurar os dados dos inquilinos em uma aplicação utilizando um esquema de compartilhamento, no qual múltiplos inquilinos compartilham um mesmo conjunto de tabelas.
Criptografia de dados dos inquilinos.
Uma maneira de proteger por completo os dados dos inquilinos é através da criptografia dos mesmos, de forma que estes permaneçam seguros, mesmo caindo em mãos erradas.
Métodos de criptografia são categorizados como simétricos ou assimétricos. Na criptografia simétrica, uma chave é gerada para criptografar e descriptografar dados. Dados criptografados com uma chave simétrica podem ser descriptografados através do uso dessa mesma chave. Na criptogradia assimétrica (também chamada de criptografia de chave pública), duas chaves são utilizadas e designadas como chave pública e chave privada. Os dados que são criptografados com chave pública podem apenas ser descriptografados com a chave privada correspondente, e vice-versa. Geralmente, chaves públicas são distribuídas para qualquer (ou todos) grupo interessado em se comunicar com o detentor da chave, enquanto as chaves privadas são mantidas em segurança. Por exemplo, se Wagner desejar mandar uma mensagem criptografada para Giuliano, ela obtém a chave pública de Giuliano através de algum acordo, e a utiliza para criptografar a mensagem. A mensagem criptografada, ou cyphertext, apenas pode ser descriptografada por alguém que possua a chave privada de Giuliano (na prática, apenas o próprio Giuliano). Dessa forma, Giuliano jamais teria que compartilhar sua chave privada com Wagner. Para mandar uma mensagem para Giuliano utilizando criptografia simétrica, Wagner teria que mandar a chave simétrica separadamente - correndo o risco de que a chave seja interceptada por terceiros durante a transmissão.
A criptografia de chave pública requer um poder de processamento mais significativo em relação à criptografia simétrica; um forte par de chaves pode demorar muitíssimo tempo para criptografar e descriptografar dados como uma chave simétrica de qualidade similar. Para aplicações SaaS na qual cada pedaço de dado armazenado é criptografado, esse processamento elevado pode inviabilizar toda a solução. Uma abordagem mais recomendada é a utilização de um sistema de key wrapping que combine as vantagens de ambos os sistemas.
Com essa abordagem, três chaves são criadas para cada inquilino como parte do processo de provisionamento: uma chave simétrica e um par de chaves assimétrico, consistindo numa chave pública e em outra privada. A chave simétrica (mais eficiente) é usada na criptografia dos dados armazenados pertencentes ao inquilino. Para adicionar uma nova camada de segurança, um par de chaves pública/privada é utilizado para criptografar e descriptografar a chave simétrica, para mantê-la segura e à prova de instrusos.
Quando um usuário final efetua o logon, a aplicação utiliza a personificação para prover o acesso ao banco de dados (pelo contexto de segurança do inquilino, que garante o acesso da aplicação à chave privada do inquilino). A aplicação (ainda personificando o inquilino, é claro) pode então utilizar a chave privada do inquilino para descriptografar a chave simétrica e utilizá-la para ler e escrever informações.
Este é um outro exemplo de uma ação de defesa. A exposição acidental ou maliciosa dos dados de um inquilino para outro inquilino - um cenário de pesadelo para o provedor de segurança do SaaS - é evitada em múltiplos níveis. A primeira linha de defesa, no banco de dados, previne usuários finais de acessar dados de outros inquilinos. Se um bug ou um vírus no servidor de banco de dados criarem um registro incorreto para ser entregue ao inquilino, o conteúdo criptografado desse registro seria inútil sem o acesso à chave privada do inquilino.
A importância da criptografia aumenta a semelhança de uma aplicação SaaS com o resultado final de uma extensão de um modelo compartilhado para um modelo isolado/compartilhado. A criptografia é especialmente importante em situações que envolvem dados de valor ou sigilosos, ou ainda quando múltiplos inquilinos compartilham um mesmo conjunto de tabelas num banco de dados.
Em razão da impossibilidade de se indexar colunas criptografadas, deve-se selecionar quais colunas de determinadas tabelas devem ser criptografadas, o que envolve a criação de um mecanismo de troca entre a segurança dos dados e desempenho. Pense sobre a utilização e a importância dos vários tipos de dados e em seu modelo de dados quando tomar decisões sobre criptografia.
Padrões de Extensibilidade
Conforme o planejado, sua aplicação irá, naturalmente, incluir uma instalação padrão de banco de dados, com tabelas padrão, campos, consultas e relações apropriadas à natureza da sua solução. Mas diferentes tipos de organizações possuem diferentes tipos de necessidades, que não conseguirão ser atendidas através de um modelo rígido e não-extensível de dados. Por exemplo, um cliente de um sistema de job-tracking de um SaaS necessita armazenar uma code string (string de código) de classificação, gerada externamente, em cada um dos registros - para que haja uma total integração entre o sistema e seus processos. Um cliente diferente pode ter a necessidade por um campo para classificação, mas talvez necessite de suporte para rastrear o ID da categoria - um integer (inteiro). Além disso, em muitos casos você terá que desenvolver e implementar um método com o qual os clientes possam estender seu modelo padrão de dados para suprir suas necessidades, sem afetar o modelo de dados utilizados por outros clientes.
Campos Pré-alocados
Uma maneira de fazer com que o seu modelo de dados seja extensível é através da criação prévia de um determinado número de campos padrão, em cada uma das tabelas a serem estendidas pelos inquilinos.

Figura 9. Uma tabela com uma coleção (prévia) de campo padrão, que vão do C1 ao C3.
Na figura anterior, registros de diferentes clientes são misturados em uma mesma tabela; o campo contendo um ID para cada inquilino associa os registros individualmente. Além disso, nesse conjunto de campos padrão, um número de campos customizados são disponibilizados, e cada cliente pode escolher quais deles serão utilizados e como as informações serão coletadas para eles.
E sobre os tipos de dados? Você pode simplesmente escolher um tipo de dado comum para cada campo customizado que criar, mas os clientes talvez achem essa abordagem desnecessariamente restritiva, se um cliente tiver a necessidade de três campos string adicionais, mas só dispor de apenas um campo string, outro inteiro e outro booleano? Uma maneira de oferecer esse tipo de flexibilidade é utilizar o tipo de dado string para cada campo customizado, e utilizar metadados para rastrear o tipo de dado "real" desejado pelo inquilino.

Figura 10. Um campo customizado em uma página Web, definido pela entrada de uma tabela de metadados.
No exemplo anterior, um inquilino utilizou-se da extensibilidade da aplicação para acrescentar uma caixa de texto chamada "Originating ZIP Code" em uma tela para entrada de dados, e mapeou essa caixa de texto para um campo customizado chamado "C1". Ao criar essa caixa de texto, o inquilino utilizou uma validação lógica (não demonstrada) para requerer que essa caixa de texto contenha um inteiro. Depois de implementado, esse campo customizado é definido por um registro na tabela de metadados, que inclui o número ID do inquilino (1017), a classificação escolhida pelo inquilino para o campo "Originating ZIP Code" e o tipo de dado que o inquilino necessita utilizar para esse mesmo campo "int".
Você pode verificar as definições de todos os campos customizados de uma aplicação em uma única tabela de metadados, ou utilizar uma tabela separada para cada campo customizado; por exemplo, uma tabela "C1" definiria os campos customizados "C1" para cada inquilino que fosse utilizá-lo, uma tabela "C2" faria o mesmo pelo campo customizado "C2", e assim por diante.

Figura 11. Definições de armazenamento contidas em uma única tabela de metadados e em tabelas separadas para cada campo customizado
A principal vantagem do uso de tabelas separadas é que cada campo específico na tabela contém apenas os registros para os inquilinos que utilizam aquele campo, o que economiza espaço no banco de dados. (com o uso de uma única tabela, cada inquilino que se utiliza de pelo menos, um campo customizado obtém um registro da tabela combinada, com campos nulos representando campos customizáveis disponíveis e não utilizados pelo inquilino). O ponto fraco de se utilizar tabelas separadas é o aumento na complexidade das operações em campos customizados, o que requer o uso da instrução JOIN do SQL, para pesquisar todas as definições do campo customizado para um único inquilino.
Quando um usuário final digita a quantidade no campo e salva o registro, a aplicação lança o valor que origina o código postal (ZIP Code) para uma string, antes de criar ou atualizar o registro no banco de dados. Sempre que a aplicação devolver o registro, ela checará a tabela de metadado para o tipo de dado a ser utilizado e lançará o valor no campo customizado com o seu tipo original.
Pares de Valores Nomes
Os padrões dos campos pré-alocados explicados na seção anterior é um modo simples de oferecer um mecanismo para que os inquilinos estendam e customizem o modelo de dados da aplicação. Entretanto, essa abordagem possui certas limitações. Decidir quantos campos customizados será usado em uma determinada tabela envolve a criação de uma regra de negócios. Com poucos campos customizados, os inquilinos se sentirão restringidos e limitados pela aplicação; com muitos desses campos, o banco de dados se tornará esparso e dissipado, com muitos campos sem uso. Em casos extremos, ambas as situações podem acontecer, com alguns inquilinos sub-utilizando alguns campos e outros os sobrecarregando.
Uma maneira de evitar essas limitações é permitir que os clientes estendam o modelo de dados arbitrariamente, armazenando dados customizados em uma tabela separada e utilizando metadados para definir rótulos e tipos de dados para cada campo customizado do inquilino.

Figura 12. Uma tabela de extensão garante que cada inquilino defina arbitrariamente o número de campos customizados.
Aqui, uma tabela de metadados armazena informações importantes sobre cada campo customizado, definido por cada inquilino, o que inclui o nome do campo (rótulo) e o tipo de dado. Quando um usuário final grava um registro em um campo customizado, duas coisas ocorrem. Primeiro, o registro em si é criado ou atualizado na tabela primária; valores são salvos para todos os campos pré-definidos, mas não para os campos customizados. Ao invés disso, a aplicação cria um único identificador para o registro e salva no campo ID do mesmo. Segundo, uma nova linha é criada na tabela de extensão que contém os seguintes trechos de informação:

• O ID do registro associado na tabela de dados primária;
  
• O ID de extensão associado com a correta definição do campo customizado;
  
• O valor do campo customizado no registro que foi salvo, lançado em uma string.
  

Essa abordagem permite que a cada inquilino crie quantos campos customizados forem necessários para suprir suas necessidades de negócios. Quando a aplicação retorna um registro customizado, ela executa uma procura na tabela de extensão, seleciona todas as linhas correspondentes ao ID do registro e retorna um valor para cada campo customizado. Para associar esses valores com o correto campo customizado e lançá-los com o tipo correto de dados, a aplicação procura por informações desse campo nos metadados, utilizando a ID de extensão associada com cada valor da tabela de extensão.
Essa abordagem faz com que o modelo de dados seja arbitrariamente extensível, enquanto retém o custo/benefício do uso de um banco de dados compartilhado. A principal desvantagem dessa abordagem é que ela adiciona um grau de complexidade às funções do banco de dados, como a indexação, consulta e atualização de registros. Esta é, tipicamente, a melhor abordagem a se adotar caso você deseje utilizar um banco de dados compartilhado, mas também tenha antecipado a necessidade de seus clientes por mais flexibilidade para estender o modelo de dados padrão.
Colunas Customizadas
A maneira mais simples de estender um modelo de dados é aquela em que as colunas podem ser acrescentadas às tabelas do inquilino diretamente.

Figura 13. Linhas customizadas podem ser adicionadas a tabelas dedicadas sem que haja alteração no modelo de dados de outros inquilinos.
Esse padrão é apropriado para aplicações com bancos e esquemas com separação, pois cada inquilino tem seu próprio conjunto de tabelas, que pode ser modificada independentemente das pertencentes a quaisquer outros clientes. Do ponto de vista do modelo de dados, este é o mais simples dos três padrões de extensibilidade, por não requerer o rastreamento de extensões de dados em separado. Do lado da arquitetura da aplicação, entretanto, esse padrão pode ser mais difícil de se implementar, porque permite que inquilinos variem o número de colunas em uma tabela. Até mesmo o padrão de colunas customizadas está disponível a você, para considerar o uso de uma variação nos campos pré-alocados ou o padrão de pares de Valores/Nomes na redução no processo de desenvolvimento, permitindo que se escrevam códigos para aplicação capazes de assumir um conhecido e inalterável número de campos em uma tabela.
Utilizando as extensões do modelo de dados
Qualquer método por você criado para a extensão do modelo de dados precisa ser compatível com um mecanismo de integração de campos adicionais às funcionalidades de uma aplicação. Quaisquer implementações de campos customizados irão requerer uma modificação correspondente na lógica do negócio (para que a aplicação possa utilizar dados customizados), a lógica de apresentação (para que os inquilinos tenham uma maneira de inserir o dado customizado como um input (entrada) e recebê-lo como output (saída)), ou ambos. A interface de configuração que você apresenta ao cliente deve, inclusive, prover meios de modificar todos os três, preferencialmente de uma maneira integrada. (Provendo mecanismos através dos quais os clientes possam modificar a lógica de negócios e a interface do inquilino, que será abordada num artigo futuro).
Padrões de Escalabilidade
Softwares empresariais de larga escala são concebidos para uso simultâneo por milhares de pessoas. Se você possui experiência na construção de aplicações como esta, se sabe, primeiramente, quais os desafios de criar uma arquitetura escalável. Para uma aplicação SaaS, a escalabilidade é ainda mais importante, porque deve suportar dados pertencentes a TODOS os clientes. Para os desenvolvedores de Software (ISVs) acostumados com a construção de softwares empresariais, suportar esse tipo de base de inquilinos pode ser como subir da segunda para a primeira divisão: as regras podem ser familiares, mas o jogo é jogado num nível totalmente diferente. Ao invés de largamente distribuídas, essas aplicações corporativas críticas serão construídas no sistema de escala da internet, o qual necessita suportar, simultaneamente, milhões de usuários.
Os bancos de dados podem ser aumentados (movendo-os para um servidor maior, com processadores melhores e mais poderosos, mais memória e discos rígidos mais velozes) e adaptados (ao particionar um banco de dados em múltiplos servidores). Diferentes estratégias são apropriadas na adaptação de um banco de dados compartilhado em relação a um banco de dados dedicado. (Quando estiver desenvolvendo uma estratégia para adaptação, é importante distinguir entre adaptar sua aplicação, aumentando o espaço de trabalho total que a aplicação acomoda e adaptar seus dados, aumentando sua capacidade de selecionar e trabalhar com dados. Este artigo foca na adaptação de dados, especificamente).
Técnicas de adaptação
As duas principais ferramentas a se utilizar em uma modificação no banco de dados é a replicação e o particionamento. A Replicação envolve a cópia de toda uma parte do banco de dados para outra localidade, e então mantém uma cópia (ou cópias) sincronizada com a original. Numa única replicação, neste caso, apenas a original (ou a replicação principal) pode ser escrita para gerenciar uma replicação com o esquema múltiplo-mestre - no quais algumas, ou todas, as cópias podem ser escritas para um tipo de mecanismo de sincronização, utilizado para atualizar mudanças entre as diferentes versões desses dados.
O particionamento envolve a divisão dos dados em sub-sistemas de banco de dados e a mudança desses dados particionados para outras tabelas, particionadas num mesmo banco de dados. Você pode particionar um banco de dados re-alocando todas as tabelas ou separando uma ou mais tabelas em tabelas menores horizontal ou verticalmente. O particionamento Horizontal significa que o banco de dados será dividido em dois bancos de dados menores (usando o mesmo esquema e estrutura), mas com poucas linhas em cada tabela. O particionamento vertical significa se uma ou mais tabelas individuais estão divididas em tabelas menores, com um mesmo número de linhas. Cada tabela contém um sub-sistema de colunas, vindas do original. A Replicação e o particionamento também serão usados quando houver mudanças no banco de dados.
Particionamento Horizontal baseado no inquilino
Um banco de dados compartilhado deve ser alterado quando este não mais atender as métricas básicas de desempenho, ou quando muitos inquilinos tentam acessar o banco de dados simultaneamente, ou ainda, quando o tamanho do banco de dados esteja causando lentidão na execução de consultas e atualizações e quando o gerenciamento operacional afete a disponibilidade dos dados.
A maneira mais simples para se alterar um banco de dados compartilhado é através do particionamento horizontal (baseado nos registros) pelo ID do inquilino. Banco de dados compartilhados SaaS adapta-se facilmente ao particionamento horizontal pelo fato de cada inquilino possuir seu próprio conjunto de dados, de modo a poder, facilmente, focar nos dados individuais de cada inquilino e movê-los.
Entretanto não assuma que, se você tiver mais de 100 inquilinos e precisar particionar o banco de dados de 5 maneiras, pode-se simplesmente contar 20 inquilinos por vez e movê-los. Diferentes tipos de inquilinos podem possuir diferentes e distintas necessidades, sendo importante planejar cuidadosamente para que se possa evitar a criação de pequenas (mas sobrecarregadas) partições, enquanto outras partições permanecem sub-utilizadas.
Se você estiver passando por problemas de desempenho por causa do número de usuários acessando o banco de dados simultaneamente, considere particionar o banco de dados de modo à equalizar o número total de contas de usuários finais ativos em cada servidor. Por exemplo, se o seu banco de dados existente serve os inquilinos A e B, com 600 usuários ativos cada, e os inquilinos C, D, e E com 400 usuários ativos cada, você pode particionar o banco de dados movendo os inquilinos C, D e E para um novo servidor; ambos os banco de dados então serviriam 1200 usuários cada.
Se você estiver passando por problemas relacionados ao tamanho do banco de dados (como um longo tempo para execução de consultas), um método de particionamento mais efetivo pode resolver essa situação, determinando inquilinos a um banco de dados para equalizar o montante de dados em cada um deles.
O método de particionamento escolhido pode ter um impacto significativo no desenvolvimento de aplicações. Qualquer que seja o método escolhido, é importante que você possa pesquisar minuciosamente e reportar para quaisquer métricas desejadas para tomar decisões relacionadas ao particionamento. Construir um suporte para monitorar dentro de sua aplicação ajudará você a obter uma visão apurada dos padrões utilizados por seus inquilinos e suas necessidades. Além disso, é provável que você necessite reparticionar seus dados periodicamente, à medida que seus inquilinos evoluam e mudem a maneira de trabalhar. A escolha de uma estratégia de particionamento sem dúvidas afetam os sistemas de produção.
Ocasionalmente, um inquilino pode ter inquilinos o suficiente ou usar dados suficientes para justificar sua mudança para um servidor de banco de dados dedicado. Veja a próxima seção "Mudança Individual de Inquilino", para maiores informações sobre mudanças.
O particionamento horizontal baseado no inquilino é apropriado para o uso com o esquema compartilhado de aplicações, que impõe obstáculos incomuns a tarefas familiares de mudança de banco de dados. Ela fornece uma maneira de mudar um banco de dados compartilhado enquanto evita ações que quebrem a aplicação e prejudiquem a performance (como, por exemplo, dividir dados de inquilinos indevidamente em 2 ou mais servidores desnecessariamente).
Mudança Individual de Inquilino
Se alguns ou todos os inquilinos armazenam e usam uma grande quantidade de informações, os bancos de dados dos mesmos talvez cresçam o suficiente para justificar a adoção de um servidor inteiro para servi-lo exclusivamente. Os desafios da escalabilidade nesse cenário são similares àqueles enfrentados por arquitetos de aplicações para um único inquilino. Com um grande banco de dados em um servidor dedicado, essas mudanças são a maneira mais fácil de acomodar e continuar o processo de crescimento.
Se o banco de dados continuarem a crescer, eventualmente este não terá mais uma relação custo/benefício para mudança para um servidor mais poderoso, e você terá que particionar o banco de dados em um ou mais servidores adicionais. Mudar um servidor de banco de dados dedicado é diferente de mudar um compartilhado. Como servidor de banco de dados compartilhado, o método mais efetivo de mudança envolve mover conjuntos inteiros de dados do inquilino de um banco de dados para um outro, assim a natureza do modelo de dados que você utiliza não é relevante na prática. Quando mudar um banco de dados dedicado para um único inquilino, torna-se necessária a análise de tipos de dados que estejam sendo armazenados para determinar uma melhor abordagem.
O artigo Aumentado à estrutura do SQL Server 2005 contém guias e sugestões adicionais a respeito da análise de dados para o aumento de estrutura. O artigo explica o referenciamento, ativação e recursos de dados em detalhes, oferece alguns direcionamentos para replicação e particionamento de dados e explica alguns fatores adicionais que afetam o aumento de estrutura. Alguns desses direcionamentos para o aumento de estrutura a serem considerados:

• Utilização de replicação para criação de cópias (apenas para leitura) dos dados que não são alterados com frequência. Alguns tipos de dados raramente (ou nunca) mudam após serem inseridos, como, por exemplo, números de documentos e/ou datas de nascimento. Outros tipos de dados estão sujeitos a mudanças constantes durante um determinado período, e depois são arquivados (como ordens de pagamento). Esses tipos de dados são candidatos ideais para uma única replicação para qualquer banco de dados que tenham sido referenciados.
  
• Localização, localização, localização. Mantenha os dados próximos a outros dados que os referenciam. ("Perto" nesse caso geralmente significa proximidade lógica ao invés de física, apesar de proximidade lógica poder implicar em proximidade física também.) Considere as relações entre diferentes tipos de dados quando decidir onde separá-los, e utilize a replicação para distribuir cópias de leitura para referência em diferentes bancos de dados, quando apropriado.
  

Por exemplo, se o ato de retornar um registro do cliente rotineiramente envolve a seleção de informações sobre compra desse mesmo cliente de uma tabela diferente, tente manter as duas tabelas no mesmo banco de dados, ou utilize a replicação para criar cópias dos tipos apropriados de dados. Procure achar divisões naturais nesses dados que minimizem o montante de comunicação entre banco de dados. Por exemplo, dados associados com um determinado tipo de informação podem ser particionados geograficamente.

• Identifiquem dados que não devem ser particionados. Fonte de dados, como datas warehouses, não costumam ser considerados num processo de replicação ou particionamento. Use as técnicas de aumento de estrutura para mover outros dados do servidor, aumente o espaço livre para suportar o aumento de sua fonte de dados. Se você tiver movido todos os dados possíveis e ainda estiver enfrentando problemas, considere aumentar a estrutura do banco de dados para um servidor com mais recursos.
  
• Utilize, sempre que possível, a replicação single-master. Sincronizar mudanças para múltiplas cópias de um mesmo dado é difícil, evite usar múltiplas replicações mestre tanto quanto puder. Quando dados replicados necessitam ser alterados, apenas permita que alterações sejam escritas à cópia principal.
  

Esse padrão pode ser aplicado a todas as três abordagens, mas só entram em ação quando dados de um determinado inquilino necessitam ser acomodados num único servidor. Com a abordagem do banco de dados separado, se a necessidade do armazenamento desses dados for modesta, cada servidor deverá armazenar dúzias de banco de dados; nesse caso, aumentar a estrutura de um determinado servidor envolverá simplesmente a mudança de um ou mais banco de dados para um novo servidor e a modificação dos metadados da aplicação para refletir a nova localidade dos dados.
Para informações gerais sobre aumentos estruturais de banco de dados, veja o artigo Performance & Scalability publicado pela Microsoft patterns & practices.

Inicio da pagina

Conclusão

A abordagem de design e padrões aqui discutidos devem ajudar a criar uma camada base de confiança, que é vital para o sucesso de sua aplicação SaaS. Criar uma arquitetura SaaS que reconcilie benefícios competitivos e demandas de compartilhamento e isolamento não é uma tarefa trivial, mas essas abordagens e padrões podem ajudar a identificar e resolver muitas das questões críticas que você enfrentará. As idéias e recomendações aqui apresentadas diferem em detalhes, mas todas o ajudam a elevar os princípios de configurabilidade, escalabilidade e eficiência de múltiplos inquilinos para criar uma arquitetura segura e extensível para uma aplicação SaaS.
Este artigo não é a última palavra sobre o tema de arquiteturas de dados de múltiplos inquilinos. Futuramente, veremos maneiras para ajudar inquilinos a colocarem suas extensões de modelos de dados para um bom uso através da apresentação e customização do workflow.

Fonte: http://msdn.microsoft.com/pt-br/library/aa479086.aspx