Observação
O acesso a essa página exige autorização. Você pode tentar entrar ou alterar diretórios.
O acesso a essa página exige autorização. Você pode tentar alterar os diretórios.
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, pois é impossível prever que tipos de ataques futuros novas tecnologias provocarão. Por outro lado, só porque ninguém descobriu (ou publicou) falhas de segurança em um sistema não significa que nenhuma existe ou poderia 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 do tempo de vida do aplicativo.
Design para Segurança
Um dos maiores problemas no desenvolvimento de aplicativos seguros é que a segurança geralmente é uma reflexão posterior, algo a ser implementado após a conclusão do código de um projeto. Não criar segurança em um aplicativo no início leva a aplicativos inseguros porque pouco se pensou no que torna um aplicativo seguro.
A implementação de segurança de última hora leva a mais bugs, pois o software falha sob as novas restrições ou precisa ser reescrito para acomodar funcionalidades não previstas. 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.
Modelagem de ameaças
Você não pode proteger um sistema contra ataques, a menos que entenda todos os possíveis ataques aos quais ele é 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 localizar aquelas que são as mais perigosas porque expõem os dados mais confidenciais. Depois de identificar as vulnerabilidades, você as classifica em ordem de gravidade e cria um conjunto priorizado de contramedidas para combater as ameaças.
Para obter mais informações, consulte os seguintes recursos:
| Recurso | Descrição |
|---|---|
| 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ça que você pode usar para proteger seus próprios aplicativos |
O princípio do privilégio mínimo
Ao projetar, compilar e implantar seu aplicativo, você deve assumir que seu aplicativo será atacado. Geralmente, esses ataques vêm de código mal-intencionado 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 invasor. Ao planejar a segurança, sempre suponha que o pior cenário ocorrerá.
Uma contramedida que você pode empregar é tentar erguer o máximo possível de paredes ao redor do código executando com menos privilégios. O princípio do privilégio mínimo diz que qualquer privilégio determinado deve ser concedido à menor quantidade de código necessária para a menor duração do tempo necessária para fazer o trabalho.
A melhor prática para criar aplicativos seguros é começar sem nenhuma permissão e, em seguida, adicionar as permissões mais estreitas para a tarefa específica que está sendo executada. Por outro lado, começar com todas as permissões e negar as individuais leva a aplicativos inseguros que são difíceis de testar e manter porque podem existir falhas de segurança de 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 | Descrição |
|---|---|
| Proteção de 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 da área de trabalho. |
CAS (segurança de acesso ao código)
A CAS (segurança de acesso ao código) é um mecanismo que ajuda a limitar o acesso que o código tem para 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 política de segurança associando conjuntos de permissões a grupos de código (grupos de códigos).
Permite que o código solicite as permissões necessárias para ser executado, bem como as permissões que seriam úteis para ter e especifica quais permissões o código nunca deve ter.
Concede permissões a cada assembly que é carregado, com base nas permissões solicitadas pelo código e nas operações permitidas pela política 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 somente chamadores de uma determinada organização ou site chamem o código protegido.
Impõe restrições ao código em runtime 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 que seu trabalho seja feito e não mais.
Para obter mais informações, consulte os seguintes recursos:
| Recurso | Descrição |
|---|---|
| Segurança de Acesso ao Código e ADO.NET | Descreve as interações entre segurança de acesso de código, segurança baseada em função e ambientes parcialmente confiáveis da perspectiva 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 do Banco de Dados
O princípio do privilégio mínimo 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 | Descrição |
|---|---|
| Segurança do SQL Server | Fornece uma visão geral da segurança do SQL Server com cenários de aplicativo que fornecem diretrizes para criar aplicativos ADO.NET seguros direcionados 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
Administrar incorretamente a política de CAS (segurança de acesso de código) pode potencialmente criar pontos fracos de segurança. Depois que um aplicativo é implantado, as técnicas de monitoramento de segurança devem ser usadas e os riscos são avaliados à medida que novas ameaças surgem.
Para obter mais informações, consulte os seguintes recursos:
| Recurso | Descrição |
|---|---|
| Gerenciamento de Política de Segurança | Fornece informações sobre como criar e administrar a política de segurança. |
| Práticas recomendadas da política de segurança | Fornece links que descrevem como administrar a política de segurança. |