Decidindo onde reforçar a segurança
As compensações são inerentes ao reforço da segurança. Um banco de dados pode ser um lugar natural para colocar lógica de segurança, dado que, em última análise, esses dados são a coisa mais importante a proteger. No entanto, isso tem implicações significativas no desempenho. Impor segurança no banco de dados pode ser muito caro, dimensionado mal e é inflexível.
Impondo a segurança na camada intermediária
A regra geral a ser seguida com aplicativos multicamadas escalonáveis usando COM+ é que, sempre que possível, você deve impor segurança detalhada no aplicativo COM+ na camada intermediária. Isso permite que você aproveite totalmente os serviços escalonáveis fornecidos pelo COM+. Aplique a autenticação no banco de dados somente quando for absolutamente necessário e pese totalmente as implicações de desempenho de fazê-lo.
A situação ideal é ser capaz de proteger tabelas de banco de dados para que o aplicativo COM+ seja capaz de acessá-las sob sua própria identidade. O banco de dados deve apenas autenticar o aplicativo COM+ e confiar nele para autenticar e autorizar corretamente os clientes que acessarão os dados. Os benefícios dessa abordagem são os seguintes:
- Ele permite o pool de conexões entre todos os clientes, pois as conexões são completamente genéricas.
- Ele geralmente otimiza o acesso aos dados, geralmente um ponto de estrangulamento problemático ao dimensionar aplicativos.
- Ele pode minimizar a sobrecarga lógica para impor segurança, especialmente se a segurança declarativa baseada em função puder ser usada.
- Ele pode fornecer grande flexibilidade em uma política de segurança. Você pode configurá-lo e reconfigurá-lo facilmente, conforme descrito em Administração de Segurança Baseada em Função.
Mas, conforme discutido em Projetando funções de forma eficaz, embora as funções possam ser aplicadas de forma fácil e eficaz a alguns relacionamentos de dados do usuário, elas não são uma solução universal para decisões de acesso de segurança.
Impondo segurança no banco de dados
Apesar da preferência de impor a segurança na camada intermediária, há vários motivos para impor a segurança no banco de dados, como os seguintes:
- Você não tem escolha, talvez por razões de legado ou talvez porque a decisão simplesmente não está em suas mãos.
- O banco de dados é acessado por uma ampla variedade de aplicativos, e sua segurança não pode ser configurada com base em um único aplicativo.
- Um banco de dados pode ser protegido previsivelmente. Se você mantiver dados críticos para a empresa em um banco de dados, poderá desenhar um vagão apertado em torno deles e ajudar a controlar quem pode vê-los.
- A autenticação de clientes originais no banco de dados permite o registro detalhado de quem fez o quê no banco de dados.
- Alguns dados são vinculados inatamente a usuários específicos, e a lógica de tomar decisões de acesso extremamente refinadas pode ser realizada com mais eficiência no próprio banco de dados, próximo aos dados.
Quando você se dá ao luxo de projetar a segurança do banco de dados e do aplicativo COM+ em conjunto, a maioria dessas questões diz respeito às características dos próprios dados e sua relação com os usuários que os acessam. Com dados que podem ser acessados por categorias previsíveis de usuários, é eficiente controlar o acesso na camada intermediária usando funções. Com dados que estão intrinsecamente ligados a classes muito pequenas de usuários, essas relações geralmente devem ser expressas com os próprios dados e, portanto, você deve impor alguma segurança no banco de dados.
Implicações de desempenho da imposição de segurança no banco de dados
Se você autenticar ou autorizar usuários no banco de dados, a identidade do usuário precisará ser propagada para o banco de dados para oferecer suporte a isso. Se o banco de dados confiar no aplicativo de camada intermediária para fazer isso, é possível passar informações de segurança do usuário em parâmetros. Caso contrário, a chamada para o banco de dados deve ser feita sob a identidade do usuário, o que significa que o aplicativo do servidor deve representar o cliente. Isso pode ter implicações de desempenho, como as seguintes:
- Representar o cliente pode ser muito mais lento do que fazer a chamada diretamente sob a identidade do aplicativo. Para obter mais detalhes, consulte Representação e delegação de cliente.
- Uma conexão de banco de dados feita sob uma identidade de usuário específica não pode ser agrupada.
- Adicionar lógica no próprio banco de dados corre o risco de criar um afunilamento de escala.
Tópicos relacionados