Resumo: Este artigo apresenta principalmente os tipos de modelos de segurança para aplicações WEB ASP.NET, compara suas vantagens e desvantagens e propõe um mecanismo de seleção.
Palavras-chave: modelo de segurança, submodelo confiável, simulação/submodelo de delegação, aplicativo ASP.NET WEB
1.Prefácio
Os aplicativos WEB ASP.NET geralmente pertencem a uma arquitetura multicamadas. Geralmente, a estrutura lógica pode ser dividida em camada de apresentação, camada de lógica de negócios e camada de acesso a dados. Para acessar os recursos do aplicativo, a autenticação e autorização de identidade do cliente devem abranger várias camadas. nível. Este artigo discute principalmente o modelo de segurança de acesso a recursos de aplicativos SP.NET
2. Identificação de acesso a recursos
Os recursos típicos fornecidos externamente por aplicativos WEB aos clientes incluem:
Recursos do servidor Web, como páginas da Web, serviços da Web e recursos estáticos (páginas e imagens HTML).
Recursos de banco de dados, como dados por usuário ou dados em nível de aplicativo.
Recursos de rede, como recursos do sistema de arquivos remoto, etc.
Recursos do sistema, como registro, logs de eventos e arquivos de configuração, etc.
Os clientes acessam esses recursos através de camadas de aplicação, com uma identidade fluindo através de cada camada. Esta identidade utilizada para acesso a recursos consiste em:
A identidade do chamador original A identidade do chamador original é obtida e subsequentemente flui através de cada camada do sistema.
ID do processo O acesso ao recurso local e as chamadas downstream são feitas usando o ID do processo atual. A viabilidade desta abordagem depende da fronteira a ser ultrapassada, uma vez que a identidade do processo deve ser reconhecida pelo sistema alvo. Isso precisa ser chamado de duas maneiras:
Cruze domínios de segurança do Windows dentro do mesmo domínio de segurança do Windows - use relações de confiança e contas de domínio ou use nomes de usuário e senhas duplicados onde não existe relação de confiança.
Conta de serviço Esta abordagem utiliza uma conta de serviço (fixa). Por exemplo, para acesso ao banco de dados, a conta de serviço pode ser representada por um nome de usuário SQL fixo e uma senha por um componente conectado ao banco de dados.
Quando uma identidade fixa do Windows for necessária, o aplicativo de servidor Enterprise Services deverá ser usado.
Identidade Personalizada Quando nenhuma conta do Windows estiver disponível, você poderá usar Iprincipal e Iidentity para construir sua própria identidade, que pode incluir detalhes sobre o contexto de segurança.
3. Modelo de acesso a recursos
3.1 Modelo de subsistema confiável
Conforme mostrado na Figura 1, neste modelo, o contexto de segurança do chamador original não flui através do serviço no nível do sistema operacional, mas uma identidade fixa é usada na camada de serviço intermediária para acessar serviços e recursos downstream. O modelo de subsistema confiável recebe esse nome porque um serviço downstream (talvez um banco de dados) confia em um serviço upstream para autorizar seus chamadores. No exemplo da Figura 1, o banco de dados confia na autorização do chamador pela camada intermediária e só permite que chamadores autorizados acessem o banco de dados usando identidades confiáveis.
3.1.1 Modo de acesso a recursos
No modelo de subsistema confiável, o modelo de acesso a recursos é o seguinte:
Autenticar usuários Mapear usuários para funções Autorizar com base na associação de função Usar uma identidade confiável fixa para acessar recursos downstream
3.1.2 Identificação fixa
Uma identidade fixa usada para acessar sistemas downstream e gerenciadores de recursos, que pode ser fornecida usando uma identidade de processo ou uma conta de serviço predefinida do Windows. Para o SQL Server Explorer, isso significa autenticação do Windows para SQL Server.
Ao usar a identidade do processo, você geralmente usa a identidade do processo ASP.NET (o padrão é a conta ASPNET). Em aplicações práticas, muitas vezes é necessário alterar a conta ASPNET para uma senha mais segura e criar uma conta do Windows no computador SQL Server que corresponda à conta do processo ASP.NET. O método específico é o seguinte:
Edite o arquivo Machine.config localizado no diretório %windr%Microsoft.NETFrameworkv1.1.4322CONFIG e reconfigure o atributo de senha no elemento <processModel> para seu valor padrão <!-UserName="machine" password = "AutoGenerate" -->Mude para <!-UserName="machine" password="NewPassword" --> ou use a ferramenta ASPNET_setreg.exe para salvar o nome de usuário e senha no registro e altere a configuração para: < !- enable="true" UserName="Registro:HKLMSOFTWAREYourAPPprocesssModelASPNET_SETREG,userName" senha=" Registro:HKLMSOFTWAREYourAPPprocesssModelASPNET_SETREG,senha " -->
Outros aplicativos usam uma conta SQL designada (especificada pelo nome de usuário e senha na cadeia de conexão) para acessar o SQL Server. Neste caso, o banco de dados deve estar configurado para autenticação SQL. A cadeia de conexão salva no arquivo de configuração precisa ser protegida por criptografia.
3.2 Modelo de Simulação/Delegação
Conforme mostrado na Figura 2, ao usar o modelo de representação/exclusão, um serviço ou componente (geralmente localizado na camada lógica de serviços de negócios) usa recursos de representação do sistema operacional para representar a identidade do cliente antes de acessar o próximo serviço downstream. Se o serviço estiver na mesma máquina, basta usar representação, se o serviço downstream estiver em uma máquina remota você também precisará usar delegação, o contexto de segurança do acesso ao recurso downstream é o contexto do cliente.
3.3 Selecione o modelo de acesso a recursos
A comparação dos dois modelos de acesso a recursos é mostrada na Tabela 1.
O back-end da função de simulação de modelo de subsistema confiável/auditoria de modelo delegada confia nos serviços da camada superior. Se a camada intermediária estiver comprometida, os recursos de back-end ficarão vulneráveis a ataques. O serviço back-end pode autenticar e autorizar cada chamador com boa segurança.
A escalabilidade oferece suporte ao pool de conexões e tem boa escalabilidade. Não oferece suporte ao pool de conexões e tem baixa escalabilidade.
Gerenciamento de ACL de back-end A ACL é configurada para uma única entidade, exigindo menos trabalho de gerenciamento. Cada usuário deve receber o nível de acesso correspondente. Quando o número de recursos e usuários de back-end aumenta, o trabalho de gerenciamento se torna complicado.
Não há necessidade de delegar questões técnicas. A delegação é necessária. A maioria dos provedores de serviços de segurança não oferece suporte à delegação.
O modelo de subsistema confiável é usado na maioria dos aplicativos de Internet, bem como em grandes aplicativos de intranet, principalmente porque esse modelo pode suportar bem a escalabilidade. O modelo de simulação/delegado tende a ser usado em sistemas menores. Para estas aplicações, a escalabilidade não é a principal consideração; a principal consideração é a auditoria.