Vista geral da segurança
Proteger um aplicativo é um processo contínuo. Nunca haverá um ponto em que um desenvolvedor possa garantir que um aplicativo esteja seguro contra todos os ataques, porque é impossível prever que tipos de ataques futuros as novas tecnologias trarão. Por outro lado, só porque ninguém ainda descobriu (ou publicou) falhas de segurança em um sistema não significa que nenhuma exista ou possa existir. Você precisa planejar a segurança durante a fase de design do projeto, bem como planejar como a segurança será mantida ao longo da vida útil do aplicativo.
Design de Segurança
Um dos maiores problemas no desenvolvimento de aplicativos seguros é que a segurança é muitas vezes uma reflexão tardia, algo a ser implementado depois que um projeto é code-complete. Não criar segurança em um aplicativo no início leva a aplicativos inseguros porque pouca atenção foi dada ao que torna um aplicativo seguro.
A implementação de segurança de última hora leva a mais bugs, pois o software quebra sob as novas restrições ou tem que ser reescrito para acomodar funcionalidades imprevistas. Cada linha de código revisado contém a possibilidade de introduzir um novo bug. Por esse motivo, você deve considerar a segurança no início do processo de desenvolvimento para que ela possa prosseguir em conjunto com o desenvolvimento de novos recursos.
Modelação de Ameaças
Você não pode proteger um sistema contra ataques a menos que compreenda todos os ataques potenciais aos quais ele está exposto. O processo de avaliação de ameaças à segurança, chamado de modelagem de ameaças, é necessário para determinar a probabilidade e as ramificações de violações de segurança em seu aplicativo ADO.NET.
A modelagem de ameaças é composta por três etapas de alto nível: entender a visão do adversário, caracterizar a segurança do sistema e determinar ameaças.
A modelagem de ameaças é uma abordagem iterativa para avaliar vulnerabilidades em seu aplicativo para encontrar aquelas que são mais perigosas porque expõem os dados mais confidenciais. Depois de identificar as vulnerabilidades, classifique-as por ordem de gravidade e crie um conjunto priorizado de contramedidas para combater as ameaças.
Para obter mais informações, consulte os seguintes recursos:
| Recurso | Description |
|---|---|
| O site de modelagem de ameaças no Portal de Engenharia de Segurança | Os recursos nesta página ajudarão você a entender o processo de modelagem de ameaças e criar modelos de ameaças que você pode usar para proteger seus próprios aplicativos |
O Princípio do Menor Privilégio
Ao projetar, criar e implantar seu aplicativo, você deve assumir que seu aplicativo será atacado. Muitas vezes, esses ataques vêm de código malicioso que é executado com as permissões do usuário que executa o código. Outros podem ter origem em código bem-intencionado que foi explorado por um atacante. Ao planejar a segurança, sempre assuma que o pior cenário ocorrerá.
Uma contramedida que você pode empregar é tentar erguer o maior número possível de paredes em torno do seu código, executando com o mínimo de privilégio. O princípio do menor privilégio diz que qualquer privilégio deve ser concedido à menor quantidade de código necessária para o menor período de tempo necessário para realizar o trabalho.
A prática recomendada para criar aplicativos seguros é começar sem permissões e, em seguida, adicionar as permissões mais restritas para a tarefa específica que está sendo executada. Por outro lado, começar com todas as permissões e, em seguida, negar as individuais leva a aplicativos inseguros que são difíceis de testar e manter porque falhas de segurança podem existir ao conceder involuntariamente mais permissões do que o necessário.
Para obter mais informações sobre como proteger seus aplicativos, consulte os seguintes recursos:
| Recurso | Description |
|---|---|
| Protegendo aplicativos | Contém links para tópicos gerais de segurança. Também contém links para tópicos para proteger aplicativos distribuídos, aplicativos Web, aplicativos móveis e aplicativos de desktop. |
Segurança de acesso ao código (CAS)
A segurança de acesso ao código (CAS) é um mecanismo que ajuda a limitar o acesso que o código tem a recursos e operações protegidos. No .NET Framework, o CAS executa as seguintes funções:
Define permissões e conjuntos de permissões que representam o direito de acessar vários recursos do sistema.
Permite que os administradores configurem a diretiva de segurança associando conjuntos de permissões a grupos de código (grupos de código).
Permite que o código solicite as permissões necessárias para ser executado, bem como as permissões que seriam úteis ter, e especifica quais permissões o código nunca deve ter.
Concede permissões a cada assembly carregado, com base nas permissões solicitadas pelo código e nas operações permitidas pela diretiva de segurança.
Permite que o código exija que seus chamadores tenham permissões específicas.
Permite que o código exija que seus chamadores possuam uma assinatura digital, permitindo que apenas chamadores de uma determinada organização ou site chamem o código protegido.
Impõe restrições ao código em tempo de execução comparando as permissões concedidas de cada chamador na pilha de chamadas com as permissões que os chamadores devem ter.
Para minimizar a quantidade de danos que podem ocorrer se um ataque for bem-sucedido, escolha um contexto de segurança para seu código que conceda acesso apenas aos recursos necessários para realizar seu trabalho e não mais.
Para obter mais informações, consulte os seguintes recursos:
| Recurso | Description |
|---|---|
| Segurança e ADO.NET de Acesso ao Código | Descreve as interações entre segurança de acesso a código, segurança baseada em função e ambientes parcialmente confiáveis da perspetiva de um aplicativo ADO.NET. |
| Segurança de acesso ao código | Contém links para tópicos adicionais que descrevem o CAS no .NET Framework. |
Segurança da Base de Dados
O princípio do menor privilégio também se aplica à sua fonte de dados. Algumas diretrizes gerais para a segurança do banco de dados incluem:
Crie contas com os privilégios mais baixos possíveis.
Não permita que os usuários acessem contas administrativas apenas para que o código funcione.
Não retorne mensagens de erro do lado do servidor para aplicativos cliente.
Valide todas as entradas no cliente e no servidor.
Use comandos parametrizados e evite instruções SQL dinâmicas.
Habilite a auditoria de segurança e o registro em log para o banco de dados que você está usando para que você seja alertado sobre quaisquer violações de segurança.
Para obter mais informações, consulte os seguintes recursos:
| Recurso | Description |
|---|---|
| Segurança do SQL Server | Fornece uma visão geral da segurança do SQL Server com cenários de aplicativos que fornecem orientação para a criação de aplicativos ADO.NET seguros destinados ao SQL Server. |
| Recomendações para estratégias de acesso a dados | Fornece recomendações para acessar dados e executar operações de banco de dados. |
Política e Administração de Segurança
A administração incorreta da diretiva de segurança de acesso ao código (CAS) pode potencialmente criar falhas de segurança. Depois que um aplicativo é implantado, técnicas para monitorar a segurança devem ser usadas e os riscos avaliados à medida que novas ameaças surgem.
Para obter mais informações, consulte os seguintes recursos:
| Recurso | Description |
|---|---|
| Gestão de Políticas de Segurança | Fornece informações sobre como criar e administrar a diretiva de segurança. |
| Práticas recomendadas de política de segurança | Fornece links que descrevem como administrar a diretiva de segurança. |