Garantir que os binários sejam obscurecidos se contiverem informações confidenciais
Title
Detalhes
Componente
Limite de confiança de máquina
Fase do SDL
Implantação
Tecnologias aplicáveis
Genérico
Atributos
N/D
Referências
N/D
Etapas
Garanta que os binários sejam obscurecidos se eles contiverem informações confidenciais, como segredos comerciais ou uma lógica de negócios confidenciais que não deve ser revertida. O objetivo é impedir a engenharia reversa de assemblies. Ferramentas como o CryptoObfuscator podem ser utilizadas para isso.
Considerar a utilização do sistema de arquivos criptografados (EFS) para proteger dados confidenciais específicos dos usuários
Title
Detalhes
Componente
Limite de confiança de máquina
Fase do SDL
Build
Tecnologias aplicáveis
Genérico
Atributos
N/D
Referências
N/D
Etapas
Considere utilizar o sistema de arquivos criptografados (EFS) para proteger dados confidenciais específicos dos usuários contra pessoas mal intencionadas que tenham acesso físico ao computador.
Garantir que os dados confidenciais armazenados pelo aplicativo no sistema de arquivos sejam criptografados
Title
Detalhes
Componente
Limite de confiança de máquina
Fase do SDL
Implantação
Tecnologias aplicáveis
Genérico
Atributos
N/D
Referências
N/D
Etapas
Garanta que os dados confidenciais armazenados pelo aplicativo no sistema de arquivos sejam criptografados (usando DPAPI, por exemplo), se o EFS não puder ser aplicado.
Garantir que conteúdos confidenciais não sejam armazenados em cache no navegador
Title
Detalhes
Componente
Aplicativo Web
Fase do SDL
Build
Tecnologias aplicáveis
Genérico, Formulários da Web, MVC5, MVC6
Atributos
N/D
Referências
N/D
Etapas
Os navegadores podem armazenar informações em seus caches e históricos. Esses arquivos armazenados em cache são salvos em uma pasta, como a pasta Arquivos de Internet Temporários no caso do Internet Explorer. Quando essas páginas são chamadas novamente, o navegador as exibe por meio do seu cache. Se informações confidenciais forem exibidas para o usuário (como endereço, detalhes do cartão de crédito, número do seguro social ou nome de usuário), elas poderão ser armazenadas no cache do navegador e, portanto, recuperadas em uma consulta ao cache do navegador ou simplesmente pressionando o botão "Voltar" do navegador. Defina o valor do cabeçalho de resposta cache-control como “no-store” para todas as páginas.
Também é possível fazer isso usando um filtro. O exemplo abaixo pode ser usado:
public override void OnActionExecuting(ActionExecutingContext filterContext)
{
if (filterContext == null || (filterContext.HttpContext != null && filterContext.HttpContext.Response != null && filterContext.HttpContext.Response.IsRequestBeingRedirected))
{
//// Since this is MVC pipeline, this should never be null.
return;
}
var attributes = filterContext.ActionDescriptor.GetCustomAttributes(typeof(System.Web.Mvc.OutputCacheAttribute), false);
if (attributes == null || **Attributes**.Count() == 0)
{
filterContext.HttpContext.Response.Cache.SetNoStore();
filterContext.HttpContext.Response.Cache.SetCacheability(HttpCacheability.NoCache);
filterContext.HttpContext.Response.Cache.SetExpires(DateTime.UtcNow.AddHours(-1));
if (!filterContext.IsChildAction)
{
filterContext.HttpContext.Response.AppendHeader("Pragma", "no-cache");
}
}
base.OnActionExecuting(filterContext);
}
Criptografar as seções dos arquivos de configuração do aplicativo Web que contêm dados confidenciais
Arquivos de configuração, tais como Web. config e appsettings.json geralmente são usados para armazenar informações confidenciais, incluindo nomes de usuários, senhas, cadeias de conexão de banco de dados e chaves de criptografia. Se você não proteger essas informações, o aplicativo ficará vulnerável a usuários mal-intencionados, que podem obter informações sigilosas, como nomes usuários e senhas de contas, nomes de bancos de dados e nomes de servidores. Com base no tipo de implantação (no Azure ou local), criptografe as seções confidenciais dos arquivos de configuração usando a DPAPI ou serviços, como o Azure Key Vault.
Desabilitar explicitamente o atributo HTML de preenchimento automático em formulários e entradas com informações confidenciais
O atributo de preenchimento automático especifica se o preenchimento automático estará ativado ou desativado em um formulário. Quando o preenchimento automático está ativado, o navegador preenche automaticamente o formulário com os valores inseridos pelo usuário em uma ocasião anterior. Por exemplo, quando um novo nome de usuário e senha são inseridos em um formulário e o formulário é enviado, o navegador pergunta se a senha deve ser salva. Da próxima vez que o formulário for exibido, o nome de usuário e a senha serão preenchidos automaticamente ou quando o nome de usuário for digitado. Um invasor com acesso local poderia obter o texto não criptografado da senha pelo cache do navegador. Por padrão, o preenchimento automático está habilitado e deve ser desabilitado explicitamente.
Garantir que os dados confidenciais exibidos na tela do usuário sejam mascarados
Title
Detalhes
Componente
Aplicativo Web
Fase do SDL
Build
Tecnologias aplicáveis
Genérico
Atributos
N/D
Referências
N/D
Etapas
Dados confidenciais, como senhas, números de cartão de crédito, CPF, etc., devem ser mascarados quando forem exibidos na tela. Isso impede que pessoas não autorizadas tenham acesso a esses dados (evitando, por exemplo, que senhas sejam visualizadas por terceiros e que o pessoal do suporte veja o CPF dos usuários). Garanta que esses elementos de dados não estejam visíveis em texto sem formatação e sejam mascarados adequadamente. É preciso ter cuidado ao aceitá-los como entrada (por exemplo, tipo de entrada="senha"), bem como exibi-los novamente na tela (por exemplo, exibir apenas os últimos quatro dígitos do número do cartão de crédito).
Implementar a máscara de dados dinâmicos para evitar a exposição de dados confidenciais a usuários sem privilégios
A finalidade do mascaramento de dados dinâmicos é limitar a exposição de dados confidenciais, impedindo que os usuários que não devem ter acesso a esses dados os visualizem. O mascaramento de dados dinâmicos não pretende impedir que usuários de banco de dados se conectem diretamente ao banco de dados e executem consultas abrangentes que exponham dados confidenciais. Ele é complementar aos outros recursos de segurança do SQL Server (auditoria, criptografia, segurança no nível da linha, etc.). É extremamente recomendável usar o mascaramento de dados dinâmicos junto com outros recursos para melhor proteger ainda mais os dados confidenciais presentes no banco de dados. Observe que esse recurso tem suporte apenas a partir do SQL Server 2016 e do Banco de Dados SQL do Azure.
Garantir que as senhas sejam armazenadas em um formato hash salgado
As senhas não devem ser armazenadas em bancos de dados de repositório de usuários personalizados. Os hashes de senha devem ser armazenados com valores de sal em vez disso. Garanta que o valor de sal do usuário seja sempre exclusivo e que você aplique b-crypt, s-crypt ou PBKDF2 antes de armazenar a senha, com uma iteração de fator de trabalho mínima de 150.000 loops para eliminar a possibilidade de forçamento bruto.
Garantir que os dados confidenciais nas colunas do banco de dados sejam criptografados
Dados confidenciais, como números de cartão de crédito, devem ser criptografados no banco de dados. Isso pode ser feito usando a criptografia no nível da coluna ou uma função de aplicativo que utilize as funções de criptografia.
Garantir que a criptografia no nível do banco de dados (TDE) esteja habilitada
O recurso Transparent Data Encryption do SQL Server ajuda a criptografar dados confidenciais em um banco de dados e protege as chaves usadas para criptografar os dados com um certificado. Isso impede que alguém sem as chaves use os dados. A TDE protege os dados “em repouso”, ou seja, os dados e arquivos de log. Fornece a capacidade de se adequar a muitas leis, regulamentos e diretrizes estabelecidos em vários setores.
Garantir que os backups de banco de dados estejam criptografados
O SQL Server tem a capacidade de criptografar os dados durante a criação de um backup. Especificar o algoritmo de criptografia e o criptografador (um certificado ou uma chave assimétrica) durante a criação de um backup permite criar um arquivo de backup criptografado.
Garantir que os dados confidenciais relevantes para a API Web não sejam salvos no armazenamento do navegador
Title
Detalhes
Componente
API Web
Fase do SDL
Build
Tecnologias aplicáveis
MVC 5, MVC 6
Atributos
Provedor de Identidade - ADFS, Provedor de Identidade - ID do Microsoft Entra
Referências
N/D
Etapas
Em determinadas implementações, os artefatos confidenciais relevantes para a autenticação da API Web são salvos no armazenamento local do navegador. Por exemplo, artefatos de autenticação do Microsoft Entra, como adal.idtoken, adal.nonce.idtoken, adal.access.token.key, adal.token.keys, adal.state.login, adal.session.state, adal.expiration.key, etc.
Todos esses artefatos estão disponíveis mesmo após sair ou depois que o navegador é fechado. Se um invasor obtiver acesso a esses artefatos, ele/ela poderá reutilizá-los para acessar os recursos protegidos (APIs). Garanta que os artefatos confidenciais referentes à API Web não sejam salvos no armazenamento do navegador. Quando o armazenamento no cliente for inevitável (como no caso dos aplicativos de página única (SPA), que aproveitam os fluxos do OpenIdConnect/OAuth implícitos e que precisam armazenar os tokens de acesso localmente), use opções de armazenamento sem persistência. Por exemplo, prefira SessionStorage a LocalStorage.
Exemplo
O snippet do JavaScript abaixo pertence a uma biblioteca de autenticação personalizada que salva os artefatos de autenticação no armazenamento local. Implementações desse tipo devem ser evitadas.
ns.AuthHelper.Authenticate = function () {
window.config = {
instance: 'https://login.microsoftonline.com/',
tenant: ns.Configurations.Tenant,
clientId: ns.Configurations.AADApplicationClientID,
postLogoutRedirectUri: window.location.origin,
cacheLocation: 'localStorage', // enable this for Internet Explorer, as sessionStorage does not work for localhost.
};
Criptografar dados confidenciais armazenados no Azure Cosmos DB
Title
Detalhes
Componente
Azure Document DB
Fase do SDL
Build
Tecnologias aplicáveis
Genérico
Atributos
N/D
Referências
N/D
Etapas
Criptografe dados confidenciais no nível do aplicativo antes de armazenar em um banco de dados do documento ou de armazenar quaisquer dados confidenciais em outras soluções de armazenamento, como o Armazenamento do Azure ou o SQL Azure.
Usar o Azure Disk Encryption para criptografar os discos utilizados por máquinas virtuais
O Azure Disk Encryption é um novo recurso que, atualmente, está na versão de visualização. Esse recurso permite criptografar os discos do sistema operacional e de dados usados por uma Máquina Virtual IaaS. No Windows, as unidades são criptografadas usando a tecnologia de criptografia BitLocker padrão do setor. No Linux, os discos são criptografados usando a tecnologia DM-Crypt. Esse recurso é integrado ao Cofre de Chaves do Azure para permitir que você controle e gerencie as chaves de criptografia de disco. A solução Azure Disk Encryption é compatível com os três cenários de criptografia do cliente a seguir:
Habilite a criptografia em novas VMs IaaS criadas de arquivos VHD criptografados pelo cliente e chaves de criptografia fornecidas pelo cliente, que são armazenados no Cofre de Chaves do Azure.
Habilite a criptografia em novas VMs IaaS criadas no Marketplace do Azure.
Habilite a criptografia em VMs IaaS existentes já em execução no Azure.
Criptografar segredos nos aplicativos do Service Fabric
Os segredos podem ser informações confidenciais, como cadeias de conexão de armazenamento, senhas ou outros valores que não devem ser tratados como texto sem formatação. Use o Azure Key Vault para gerenciar chaves e segredos em aplicativos do Service Fabric.
Execute a modelagem de segurança e use unidades de negócios/equipes onde for necessário.
Title
Detalhes
Componente
Dynamics CRM
Fase do SDL
Build
Tecnologias aplicáveis
Genérico
Atributos
N/D
Referências
N/D
Etapas
Execute a modelagem de segurança e use unidades de negócios/equipes onde for necessário.
Minimizar o acesso ao recurso de compartilhamento em entidades críticas
Title
Detalhes
Componente
Dynamics CRM
Fase do SDL
Implantação
Tecnologias aplicáveis
Genérico
Atributos
N/D
Referências
N/D
Etapas
Minimizar o acesso ao recurso de compartilhamento em entidades críticas
Instruir os usuários sobre os riscos associados ao recurso de compartilhamento do Dynamics CRM e as práticas recomendadas de segurança
Title
Detalhes
Componente
Dynamics CRM
Fase do SDL
Implantação
Tecnologias aplicáveis
Genérico
Atributos
N/D
Referências
N/D
Etapas
Instruir os usuários sobre os riscos associados ao recurso de compartilhamento do Dynamics CRM e as práticas recomendadas de segurança
Incluir uma regra de padrões de desenvolvimento que impeça a exibição dos detalhes de configuração do gerenciamento de exceções
Title
Detalhes
Componente
Dynamics CRM
Fase do SDL
Implantação
Tecnologias aplicáveis
Genérico
Atributos
N/D
Referências
N/D
Etapas
Inclua uma regra de padrões de desenvolvimento que impeça a exibição dos detalhes de configuração do gerenciamento de exceções. Teste isso como parte da inspeção periódica ou das revisões de código.
Usar o Azure Storage Service Encryption (SSE) para dados em repouso (visualização)
A SSE (Criptografia do Serviço de Armazenamento) do Azure para dados em repouso ajuda a proteger seus dados a fim de atender aos compromissos de conformidade e segurança da organização. Com esse recurso, o Armazenamento do Azure criptografa automaticamente seus dados antes de persistir no armazenamento e os descriptografa antes da recuperação. A criptografia, descriptografia e o gerenciamento de chaves é totalmente transparente para os usuários. A SSE se aplica somente aos blobs de blocos, aos blobs de páginas e aos blobs de acréscimo. Os outros tipos de dados, incluindo tabelas, filas e arquivos, não serão criptografados.
Fluxo de trabalho de criptografia e descriptografia:
O cliente habilita a criptografia na conta de armazenamento.
Quando o cliente grava os novos dados (PUT Blob, PUT Block, PUT Page etc.) no armazenamento de blobs, todas as gravações são criptografadas com a criptografia AES de 256 bits, uma das codificações de bloco mais fortes disponíveis.
Quando o cliente precisa acessar os dados (GET Blob etc.), esses dados são descriptografados automaticamente antes de serem retornados para o usuário.
Se a criptografia estiver desabilitada, as novas gravações não serão criptografadas, e os dados criptografados existentes permanecerão criptografados até que sejam regravados pelo usuário. Enquanto a criptografia estiver habilitada, as gravações no Armazenamento de Blobs serão criptografadas. O estado dos dados não muda quando o usuário habilita/desabilita a criptografia na conta de armazenamento.
Todas as chaves de criptografia são armazenadas, criptografadas e gerenciadas pela Microsoft.
No momento, as chaves usadas para criptografia são gerenciadas pela Microsoft. Podemos gerar as chaves originalmente e gerenciar o armazenamento seguro delas, bem como sua rotatividade regular, conforme definido pela política interna da Microsoft. No futuro, os usuários poderão gerenciar suas próprias chaves de criptografia e fornecer um caminho de migração de chaves gerenciadas pela Microsoft para as chaves gerenciadas pelos usuários.
Criptografar o cliente para armazenar dados confidenciais no Armazenamento do Azure
O pacote Nuget da Biblioteca de Clientes do Armazenamento do Azure para .NET dá suporte à criptografia de dados em aplicativos clientes antes do carregamento para o Armazenamento do Azure e à descriptografia de dados durante o download para o cliente. A biblioteca também dá suporte à integração com o Cofre de Chaves do Azure para o gerenciamento de chaves de contas de armazenamento. Aqui está uma breve descrição de como funciona a criptografia do lado do cliente:
O SDK do cliente do Armazenamento do Azure gera uma CEK (chave de criptografia de conteúdo), que é uma chave simétrica de uso único.
Os dados do cliente são criptografados com essa CEK
O CEK é empacotada (criptografada) usando o KEK (Chave de Criptografia de Chave). A KEK é identificada por um identificador de chave e pode ser um par de chaves assimétricas ou uma chave simétrica, podendo ser gerenciada localmente ou armazenada no Cofre da Chave do Azure. O cliente de Armazenamento, por si só, nunca tem acesso à KEK. Ele simplesmente chama o algoritmo de quebra de chave fornecido pelo Cofre da Chave. Os clientes podem escolher usar provedores personalizados para encapsular/desencapsular a chave, se desejado.
Os dados criptografados, em seguida, são carregados para o serviço de Armazenamento do Azure. Consulte os links na seção de referências para obter detalhes sobre a implementação de nível baixo.
Criptografar os dados confidenciais ou de informações de identificação pessoal (PII) gravados no armazenamento local de telefones
Se o aplicativo gravar informações confidenciais, como informações de identificação pessoal do usuário (email, número de telefone, nome, sobrenome, preferências etc.), no sistema de arquivos do dispositivo móvel, ele precisará ser criptografado antes de gravar dados no sistema de arquivos local. Se o aplicativo for um aplicativo empresarial, verifique a possibilidade de publicá-lo usando o Windows Intune.
Exemplo
O Intune pode ser configurado com as seguintes políticas de segurança para proteger dados confidenciais:
Require encryption on mobile device
Require encryption on storage cards
Allow screen capture
Exemplo
Se o aplicativo não for empresarial, use o armazenamento de chaves ou os conjuntos de chaves fornecidos pela plataforma para armazenar chaves de criptografia, com os quais a operação de criptografia pode ser executada no sistema de arquivos. O snippet de código a seguir mostra como acessar a chave do conjunto de chaves usando Xamarin:
protected static string EncryptionKey
{
get
{
if (String.IsNullOrEmpty(_Key))
{
var query = new SecRecord(SecKind.GenericPassword);
query.Service = NSBundle.MainBundle.BundleIdentifier;
query.Account = "UniqueID";
NSData uniqueId = SecKeyChain.QueryAsData(query);
if (uniqueId == null)
{
query.ValueData = NSData.FromString(System.Guid.NewGuid().ToString());
var err = SecKeyChain.Add(query);
_Key = query.ValueData.ToString();
}
else
{
_Key = uniqueId.ToString();
}
}
return _Key;
}
}
Obscurecer os binários gerados antes de distribuir os dispositivos para os usuários finais
Os binários gerados (assemblies no apk) devem ser ocultados para impedir a engenharia reversa de assemblies. Ferramentas como o CryptoObfuscator podem ser usadas para isso.
Definir clientCredentialType para o certificado ou o Windows
Usar o token UserName com um texto de senha sem formatação em um canal não criptografado expõe a senha para invasores que podem descobrir as mensagens do SOAP. Os provedores de serviços que usam o token UserName podem aceitar senhas enviadas em texto sem formatação. Enviar textos de senha sem formatação por um canal não criptografado pode expor a credencial para invasores que podem descobrir a mensagem do SOAP.
Exemplo
A configuração de provedor de serviço do WCF mostrada abaixo usa o token de nome de usuário:
Nenhuma segurança foi definida para transporte ou mensagens. Os aplicativos que transmitem mensagens sem segurança de transporte ou de mensagem não podem garantir a integridade ou a confidenciabilidade das mensagens. Quando uma associação de segurança do WCF é definida como None, as seguranças de transporte e de mensagem são desabilitadas.
Exemplo
A configuração mostrada abaixo define o modo de segurança como None.
Há cinco modos de segurança disponíveis para todas as associações de serviço, são eles:
Nenhum. desativa a segurança.
Transport: usa a segurança de transporte para a proteção de autenticações e mensagens.
Message. usa a segurança de mensagem para a proteção de autenticações e mensagens.
Both: permite que você defina configurações de transporte e mensagem (somente o MSMQ oferece suporte a esse modo).
TransportWithMessageCredential: as credenciais são transmitidas com a mensagem, e a proteção de mensagem e a autenticação de servidor são fornecidas pela camada de transporte.
TransportCredentialOnly: as credenciais do cliente são transmitidas com a camada de transporte e nenhuma proteção de mensagem é aplicada. Use segurança de transporte e de mensagem para proteger a integridade e a confidencialidade das mensagens. A configuração abaixo solicita que o serviço use a segurança de transporte com as credenciais de mensagem.