Visão 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, pois é impossível prever quais tipos de ataques futuros novas tecnologias ocorrerão. Por outro lado, só porque ninguém ainda 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 quebra sob as novas restrições ou precisa ser reescrito para acomodar a funcionalidade inesperada. 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 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: compreender 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 saber mais, consulte os recursos a seguir:

O princípio de privilégios mínimos

Ao criar, compilar e implantar seu aplicativo, você deve assumir que seu aplicativo será atacado. Geralmente, esses ataques vêm de um código mal-intencionado que é executado com as permissões do usuário que executa o código. Outros podem se originar com 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 maior número 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 duração mais curta 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:

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ódigo).

• Permite que o código solicite as permissões necessárias para execução, 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 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 somente aos recursos necessários para que o trabalho seja feito e não mais.

Para saber mais, consulte os recursos a seguir:

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 saber mais, consulte os recursos a seguir:

Política de segurança e administração

Administrar incorretamente a política de CAS (segurança de acesso ao código) pode potencialmente criar pontos fracos de segurança. Depois que um aplicativo é implantado, as técnicas para monitorar a segurança devem ser usadas e os riscos são avaliados à medida que novas ameaças surgem.

Para saber mais, consulte os recursos a seguir:

Confira também

• Protegendo aplicativos ADO.NET
• Segurança no .NET
• Segurança do SQL Server
• Visão geral do ADO.NET