Estrutura de segurança: Autorização | Atenuações

Produto/Serviço Artigo
Limite de confiança de computador
Aplicativo Web
Backup de banco de dados
Gateway de Nuvem IoT
Hub de Eventos do Azure
Azure DocumentDB
Limite de Confiança do Azure
Limite de confiança do Service Fabric
Dynamics CRM
Portal do Dynamics CRM
Armazenamento do Azure
Cliente móvel
WCF
API da Web
Dispositivo IoT
Gateway de Campo de IoT

Garanta que as ACLs apropriadas estejam configuradas para restringir o acesso não autorizado aos dados no dispositivo.

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 as ACLs apropriadas estejam configuradas para restringir o acesso não autorizado aos dados no dispositivo.

Garantir que os conteúdos confidenciais do usuário armazenados no aplicativo sejam armazenados no diretório do perfil do usuário

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 conteúdos confidenciais do usuário armazenados no aplicativo sejam armazenados no diretório do perfil do usuário. Isso impede que os múltiplos usuários do computador acessem dados uns dos outros.

Garantir que os aplicativos implantados sejam executados com privilégios mínimos

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 aplicativos implantados sejam executados com privilégios mínimos.

Impor uma ordem sequencial de etapas durante o processamento dos fluxos de lógica de negócios

Title Detalhes
Componente Aplicativo Web
Fase do SDL Build
Tecnologias aplicáveis Genérico
Atributos N/D
Referências N/D
Etapas Para verificar se esse estágio foi executado por um usuário genuíno, force o aplicativo a processar os fluxos de lógica de negócios seguindo a ordem sequencial das etapas, permitindo que todas as etapas sejam processadas em um tempo humanamente realista e evitando que a ordem das etapas seja desrespeitadas, que alguma etapa seja ignorada, que as etapas de outro usuário sejam processadas ou que as transações sejam enviadas rápido demais.

Implementar um mecanismo de limitação de taxa para evitar a enumeração

Title Detalhes
Componente Aplicativo Web
Fase do SDL Build
Tecnologias aplicáveis Genérico
Atributos N/D
Referências N/D
Etapas Verifique se os identificadores confidenciais são aleatórios. Implemente o controle CAPTCHA em páginas anônimas. Assegure que erros e exceções não revelem dados específicos.

Garantir que um sistema de autorização adequado esteja em vigor e que o princípio dos privilégios mínimos seja seguido

Title Detalhes
Componente Aplicativo Web
Fase do SDL Build
Tecnologias aplicáveis Genérico
Atributos N/D
Referências N/D
Etapas

Seguir esse princípio significa fornecer a uma conta de usuário apenas os privilégios essenciais ao trabalho desse usuário. Por exemplo, um usuário de backup não precisa instalar o software, logo ele terá direitos somente para fazer backups e executar os aplicativos de backup relacionados. Quaisquer outros privilégios, como instalar um novo software, serão bloqueados. Esse princípio também se aplica a um usuário de computador pessoal que geralmente trabalha com uma conta de usuário comum e que abre uma conta com privilégios e protegida por senha (ou seja, a de um superusuário) somente quando for absolutamente necessário.

É possível aplicar esse princípio a aplicativos Web. Em vez de depender apenas dos métodos de autenticação baseada em função usando sessões, queremos atribuir privilégios a usuários por meio de um sistema de autenticação baseado em banco de dados. As sessões continuarão sendo usadas para identificar se o usuário fez logon corretamente, mas agora, em vez de atribuir uma função específica a esse usuário, você pode atribuir privilégios a ele para verificar quais ações ele tem permissão para executar no sistema. Esse método tem uma outra grande vantagem: sempre que for necessário atribuir menos privilégios a um usuário, suas alterações serão aplicadas imediatamente, porque a atribuição não depende da sessão. Se esse fosse o caso, a sessão precisaria expirar primeiro.

As decisões de autorização de acesso a recursos e a lógica de negócios não devem ser baseadas em parâmetros de solicitação de entrada

Title Detalhes
Componente Aplicativo Web
Fase do SDL Build
Tecnologias aplicáveis Genérico
Atributos N/D
Referências N/D
Etapas Sempre que você estiver verificando se um usuário não tem permissão para acessar alguns dados, as restrições de acesso devem ser processadas no servidor. O identificador de usuário (userID) deve ser armazenado dentro de uma variável de sessão no logon e ser usado para recuperar dados do usuário no banco de dados.

Exemplo

SELECT data 
FROM personaldata 
WHERE userID=:id < - session var 

Isso impede agora que invasores adulterem e modifiquem a operação do aplicativo, porque a identificador de recuperação de dados é processado no lado do servidor.

Garantir que conteúdos e recursos não sejam enumeráveis ou estejam acessíveis por meio da navegação forçada

Title Detalhes
Componente Aplicativo Web
Fase do SDL Build
Tecnologias aplicáveis Genérico
Atributos N/D
Referências N/D
Etapas

Arquivos de configuração estáticos e com informações confidenciais não devem ser mantidos no diretório base. Para conteúdos que não precisam ser divulgados, aplique os controles de acesso adequados ou remova esses conteúdos.

Além disso, a navegação forçada geralmente é combinada com técnicas de força bruta para coletar informações durante a tentativa de acessar o máximo de URLs possível para enumerar os diretórios e os arquivos em um servidor. Os invasores podem procurar todas as variações dos arquivos mais comuns existentes. Por exemplo, uma pesquisa de arquivo de senha incluiria os arquivos psswd.txt, password.htm, password.dat e outras variações.

Para atenuar isso, recursos de detecção de tentativas de força bruta tentativas devem ser incluídos.

Garantir que contas com privilégios mínimos sejam usadas para conexão com o servidor de banco de dados

Title Detalhes
Componente Banco de dados
Fase do SDL Build
Tecnologias aplicáveis Genérico
Atributos N/D
Referências Hierarquia de permissões do SQL Server, Protegíveis do SQL
Etapas As contas com privilégios mínimos devem ser usadas para conexão com o banco de dados. O logon em aplicativos deve ser restrito no banco de dados, só deve executar os procedimentos armazenados selecionados e não deve conceder acesso direto à tabela.

Implementar a RLS (Segurança em Nível de Linha) para impedir que locatários acessem os dados uns dos outros

Title Detalhes
Componente Banco de dados
Fase do SDL Build
Tecnologias aplicáveis SQL Azure, OnPrem
Atributos Versão do SQL - V12, Versão do SQL - MsSQL2016
Referências Segurança em Nível de Linha (RLS) do SQL Server
Etapas

A Segurança em Nível de Linha permite aos clientes controlar o acesso às linhas em uma tabela de banco de dados com base nas características do usuário que executa uma consulta (por exemplo, uma associação de grupo ou um contexto de execução).

O RLS (nível de linha de segurança) simplifica o design e a codificação de segurança em seu aplicativo. Ela permite implementar restrições de acesso à linha de dados. Por exemplo, garantindo que os funcionários tenham acesso somente às linhas de dados relevantes aos seus respectivos departamento ou restringindo o acesso de um cliente apenas aos dados pertinentes à sua empresa.

A lógica de restrição de acesso é localizado na camada de banco de dados, em vez de longe dos dados em outra camada de aplicativo. O sistema de banco de dados aplica as restrições de acesso toda vez que há tentativa de acesso a dados a partir de qualquer camada. Isso torna o sistema de segurança mais robusto e confiável, reduzindo a área de superfície do sistema de segurança.

Observe que a RLS, como um recurso de banco de dados pronto para uso, tem suporte apenas a partir do SQL Server 2016, no Banco de Dados SQL do Microsoft Azure e na Instância Gerenciada de SQL do Azure. Se o recurso RLS pronto para uso não for implementado, assegure que o acesso aos dados seja restringido com modos de exibição e procedimentos

A função sysadmin deve ter apenas usuários necessários válidos

Title Detalhes
Componente Banco de dados
Fase do SDL Build
Tecnologias aplicáveis Genérico
Atributos N/D
Referências Hierarquia de permissões do SQL Server, Protegíveis do SQL
Etapas Os membros com a função de servidor fixa sysadmin devem ser muito limitados e não podem possuir contas usadas por aplicativos. Revise a lista de usuários com essa função e remova todas as contas desnecessárias.

Conectar ao Gateway de Nuvem usando tokens com privilégios mínimos

Title Detalhes
Componente Gateway de Nuvem IoT
Fase do SDL Implantação
Tecnologias aplicáveis Genérico
Atributos Opção de gateway - Hub IoT do Azure
Referências Controle de acesso do Hub IoT
Etapas Forneça permissões com privilégios mínimos para vários componentes que se conectam ao Gateway de Nuvem (Hub IoT). Um exemplo típico: o componente de gerenciamento/provisionamento de dispositivos usa os recursos de leitura/gravação do Registro, e o processador de eventos (ASA) usa o recurso de conexão de serviço. Dispositivos individuais se conectam usando as credenciais do dispositivo.

Usar uma chave SAS com a permissão somente envio para gerar tokens de dispositivo

Title Detalhes
Componente Hub de Eventos do Azure
Fase do SDL Build
Tecnologias aplicáveis Genérico
Atributos N/D
Referências Visão geral do modelo de autenticação e segurança dos Hubs de Eventos
Etapas Uma chave SAS é usada para gerar tokens para dispositivos individuais. Use uma chave SAS com a permissão somente envio ao gerar o token do dispositivo para um editor específico.

Não usar tokens de acesso que fornecem acesso direto ao Hub de Eventos

Title Detalhes
Componente Hub de Eventos do Azure
Fase do SDL Build
Tecnologias aplicáveis Genérico
Atributos N/D
Referências Visão geral do modelo de autenticação e segurança dos Hubs de Eventos
Etapas Um token que concede acesso direto ao Hub de Eventos não deve ser fornecido para o dispositivo. Usar para o dispositivo um token com privilégios mínimos e que forneça acesso somente a um editor ajudaria a identificar o dispositivo e cancelar sua permissão, caso ele seja um dispositivo invasor ou comprometido.

Conectar ao Hub de Eventos usando chaves SAS que tenham as permissões mínimas necessárias

Title Detalhes
Componente Hub de Eventos do Azure
Fase do SDL Build
Tecnologias aplicáveis Genérico
Atributos N/D
Referências Visão geral do modelo de autenticação e segurança dos Hubs de Eventos
Etapas Forneça permissões de privilégio mínimo para vários aplicativos back-end que se conectam ao Hub de Eventos. Gere chaves SAS separadas para cada aplicativo de back-end e forneça apenas as permissões necessárias (Envio, Recebimento ou Gerenciamento) a eles.

Usar tokens de recurso para se conectar ao Azure Cosmos DB sempre que possível

Title Detalhes
Componente Azure Document DB
Fase do SDL Build
Tecnologias aplicáveis Genérico
Atributos N/D
Referências N/D
Etapas Um token de recurso é associado a um recurso de permissão do Azure Cosmos DB e captura a relação entre o usuário de um banco de dados e a permissão que ele tem para acessar um recurso de aplicativo específico do Azure Cosmos DB (por exemplo, uma coleção ou um documento). Use sempre um token de recurso para acessar o Azure Cosmos DB se o cliente não puder ser confiável para manipular a chave mestra ou chaves somente leitura, por exemplo, um aplicativo de usuário final, como cliente de dispositivo móvel ou de área de trabalho. Use a chave Mestra ou chaves somente leitura em aplicativos de back-end que podem armazenar essas chaves com segurança.

Habilitar o gerenciamento de acesso refinado à assinatura do Azure usando o RBAC do Azure

Title Detalhes
Componente Limite de Confiança do Azure
Fase do SDL Build
Tecnologias aplicáveis Genérico
Atributos N/D
Referências Atribuir funções do Azure para gerenciar o acesso a seus recursos de assinatura do Azure
Etapas O RBAC (controle de acesso baseado em função) do Azure permite um gerenciar o acesso ao Azure de forma refinada. Usando o RBAC do Azure, você pode conceder apenas a quantidade de acesso de que os usuários precisam para realizar seus trabalhos.

Restringir o acesso do cliente ao cluster de operações usando o RBAC do Service Fabric

Title Detalhes
Componente Limite de confiança do Service Fabric
Fase do SDL Implantação
Tecnologias aplicáveis Genérico
Atributos Ambiente - Azure
Referências Controle de acesso baseado em função para clientes do Service Fabric
Etapas

O Service Fabric dá suporte a dois tipos de controle de acesso diferentes para clientes conectados a um cluster do Service Fabric: administrador e usuário. O controle de acesso permite que o administrador de cluster limite o acesso a determinadas operações de cluster para diferentes grupos de usuários, tornando o cluster mais seguro.

Os administradores têm acesso completo aos recursos de gerenciamento (incluindo recursos de leitura/gravação). Os usuários, por padrão, têm apenas acesso de leitura aos recursos de gerenciamento (por exemplo, recursos de consulta) e a capacidade de resolver serviços e aplicativos.

As duas funções de clientes (administrador ou cliente) são especificadas no momento da criação do cluster, com o fornecimento de certificados separados para cada um.

Execute a modelagem de segurança e use a segurança no nível do campo 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 a segurança no nível do campo onde for necessário.

Execute a modelagem de segurança das contas do portal tendo em mente que o modelo de segurança do portal é diferente do restante do CRM.

Title Detalhes
Componente Portal do 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 das contas do portal tendo em mente que o modelo de segurança do portal é diferente do restante do CRM.

Conceder permissões refinadas em um intervalo de entidades no Armazenamento de Tabelas do Azure

Title Detalhes
Componente Armazenamento do Azure
Fase do SDL Build
Tecnologias aplicáveis Genérico
Atributos Tipo de armazenamento - Tabela
Referências Como conceder acesso a objetos em sua conta de armazenamento do Azure usando SAS
Etapas Em alguns cenários de negócios, o Armazenamento de Tabelas do Azure pode ser necessário para armazenar dados confidenciais que precisam ser acessados por várias pessoas diferentes. Por exemplo, dados confidenciais pertencentes a regiões/países distintos. Nesses casos, assinaturas SAS podem ser criadas com a especificação da partição e dos intervalos de linhas da chave, para que um usuário tenha acesso aos dados de uma região/país específico.

Habilitar o controle de acesso baseado em função (RBAC do Azure) na conta de armazenamento do Azure usando o Azure Resource Manager

Title Detalhes
Componente Armazenamento do Azure
Fase do SDL Build
Tecnologias aplicáveis Genérico
Atributos N/D
Referências Como proteger a conta de armazenamento com o controle de acesso baseado em função do Azure (RBAC do Azure)
Etapas

Ao criar uma nova conta de armazenamento, você seleciona o modelo de implantação Clássico ou o do Azure Resource Manager. O modelo Clássico de criação de recursos no Azure permite apenas acesso tudo ou nada à assinatura e, por sua vez, à conta de armazenamento.

Com o modelo do Azure Resource Manager, você coloca a conta de armazenamento em um grupo de recursos e controla o acesso ao plano de gerenciamento dessa conta de armazenamento específica usando a ID do Microsoft Entra. Por exemplo, é possível permitir que usuários específicos acessem as chaves da conta de armazenamento, enquanto outros usuários podem exibir informações sobre a conta de armazenamento, mas não podem acessar suas chaves.

Implementar detecção de modificação ou desbloqueio implícito

Title Detalhes
Componente Cliente móvel
Fase do SDL Build
Tecnologias aplicáveis Genérico
Atributos N/D
Referências N/D
Etapas

Os aplicativos devem proteger seus próprios dados de configuração e usuários no caso de o telefone ser modificado ou desbloqueado. A modificação ou o desbloqueio consistem em um acesso não autorizado, que os usuários normalmente não fazem em seus próprios telefones. Portanto, o aplicativo deve ter uma lógica de detecção implícita na inicialização do aplicativo para detectar se o telefone foi modificado.

A lógica de detecção pode ser simplesmente acessar os arquivos que normalmente apenas o usuário original acessaria, por exemplo:

  • /system/app/Superuser.apk
  • /sbin/su
  • /system/bin/su
  • /system/xbin/su
  • /data/local/xbin/su
  • /data/local/bin/su
  • /system/sd/xbin/su
  • /system/bin/failsafe/su
  • /data/local/su

Se o aplicativo puder acessar qualquer um desses arquivos, isso indica que o aplicativo está sendo executado como um usuário raiz.

Referência de classe fraca no WCF

Title Detalhes
Componente WCF
Fase do SDL Build
Tecnologias aplicáveis Genérico, NET Framework 3
Atributos N/D
Referências MSDN, Fortify Kingdom
Etapas

O sistema usa uma referência de classe fraca, permitindo que um invasor execute código não autorizado. O programa consulta uma classe definida pelo usuário que não é exclusivamente identificada. Quando .NET carrega essa classe de identificação fraca, o carregador do tipo CLR procura a classe nos seguintes locais e na ordem especificada:

  1. Se o assembly do tipo for conhecido, o carregador pesquisará os locais de redirecionamento do arquivo de configuração, GAC, o assembly atual que está usando as informações de configuração e o diretório base do aplicativo.
  2. Se o assembly for desconhecido, o carregador pesquisará o assembly atual, mscorlib, e o local retornado pelo manipulador de eventos TypeResolve.
  3. Essa ordem de pesquisa do CLR pode ser modificada com ganchos, como o mecanismo de encaminhamento de tipo e o evento AppDomain.TypeResolve.

Se um invasor aproveitar a ordem de pesquisa do CLR para criar uma outra classe com o mesmo nome e colocá-la em um lugar que o CLR carregará primeiro, o CLR poderá acidentalmente executar o código fornecido pelo invasor.

Exemplo

O elemento <behaviorExtensions/> do arquivo de configuração WCF abaixo solicita que o WCF adicione uma classe de comportamento personalizada para uma extensão específica do WCF.

<system.serviceModel>
    <extensions>
        <behaviorExtensions>
            <add name=""myBehavior"" type=""MyBehavior"" />
        </behaviorExtensions>
    </extensions>
</system.serviceModel>

Usar nomes totalmente qualificados (fortes) identifica exclusivamente um tipo e aumenta ainda mais a segurança do sistema. Use nomes de assembly totalmente qualificados ao registrar tipos nos arquivos machine.config e app.config.

Exemplo

O elemento <behaviorExtensions/> do arquivo de configuração do WCF abaixo solicita que o WCF adicione uma classe de comportamento personalizada para uma extensão específica do WCF.

<system.serviceModel>
    <extensions>
        <behaviorExtensions>
            <add name=""myBehavior"" type=""Microsoft.ServiceModel.Samples.MyBehaviorSection, MyBehavior,
            Version=1.0.0.0, Culture=neutral, PublicKeyToken=null"" />
        </behaviorExtensions>
    </extensions>
</system.serviceModel>

Controle de autorização implementado no WCF

Title Detalhes
Componente WCF
Fase do SDL Build
Tecnologias aplicáveis Genérico, NET Framework 3
Atributos N/D
Referências MSDN, Fortify Kingdom
Etapas

Esse serviço não usa um controle de autorização. Quando um cliente chama um determinado serviço do WCF, o WCF fornece vários esquemas de autorização que verificar se o chamador tem permissão para executar o método de serviço no servidor. Se os controles de autorização não estiverem habilitados para os serviços do WCF, um usuário autenticado pode ter seus privilégios elevados.

Exemplo

A configuração mostrada abaixo solicita que o WCF não verifique o nível de autorização do cliente ao executar o serviço:

<behaviors>
    <serviceBehaviors>
        <behavior>
            ...
            <serviceAuthorization principalPermissionMode=""None"" />
        </behavior>
    </serviceBehaviors>
</behaviors>

Use um esquema de autorização de serviço para verificar se o chamador do método de serviço tem autorização para fazer isso. O WCF oferece dois modos e permite a definição de um esquema de autorização personalizado. O modo UseWindowsGroups utiliza funções e usuários do Windows, e o modo de UseAspNetRoles utiliza um provedor de função do ASP.NET, como o SQL Server, para autenticar.

Exemplo

A configuração mostrada abaixo solicita que o WCF se certifique de que o cliente faz parte do grupo Administradores antes de executar o serviço Adicionar:

<behaviors>
    <serviceBehaviors>
        <behavior>
            ...
            <serviceAuthorization principalPermissionMode=""UseWindowsGroups"" />
        </behavior>
    </serviceBehaviors>
</behaviors>

Então, o serviço é declarado da seguinte forma:

[PrincipalPermission(SecurityAction.Demand,
Role = ""Builtin\\Administrators"")]
public double Add(double n1, double n2)
{
double result = n1 + n2;
return result;
}

Implementar mecanismos de autorização apropriados na ASP.NET Web API

Title Detalhes
Componente API Web
Fase do SDL Build
Tecnologias aplicáveis Genérico, MVC5
Atributos N/D, Provedor de Identidade - ADFS, Provedor de Identidade - ID do Microsoft Entra
Referências Autenticação e autorização na ASP.NET Web API
Etapas

As informações de função dos usuários do aplicativo podem ser derivadas das declarações da ID do Microsoft Entra ou do ADFS se o aplicativo depende deles como provedor de identidade ou o próprio aplicativo pode fornecê-las. Em qualquer um desses casos, a implementação de autorização personalizada deve validar as informações de função de usuário.

As informações de função dos usuários do aplicativo podem ser derivadas das declarações da ID do Microsoft Entra ou do ADFS se o aplicativo depende deles como provedor de identidade ou o próprio aplicativo pode fornecê-las. Em qualquer um desses casos, a implementação de autorização personalizada deve validar as informações de função de usuário.

Exemplo

[AttributeUsage(AttributeTargets.Class | AttributeTargets.Method, Inherited = true, AllowMultiple = true)]
public class ApiAuthorizeAttribute : System.Web.Http.AuthorizeAttribute
{
        public async override Task OnAuthorizationAsync(HttpActionContext actionContext, CancellationToken cancellationToken)
        {
            if (actionContext == null)
            {
                throw new Exception();
            }

            if (!string.IsNullOrEmpty(base.Roles))
            {
                bool isAuthorized = ValidateRoles(actionContext);
                if (!isAuthorized)
                {
                    HandleUnauthorizedRequest(actionContext);
                }
            }

            base.OnAuthorization(actionContext);
        }

public bool ValidateRoles(actionContext)
{
   //Authorization logic here; returns true or false
}

}

Todos os controladores e métodos de ação que precisam ser protegidos devem ser decorados com o atributo acima.

[ApiAuthorize]
public class CustomController : ApiController
{
     //Application code goes here
}

Executar verificações de autorização no dispositivo se ele oferecer suporte a várias ações que exigem diferentes níveis de permissão

Title Detalhes
Componente Dispositivo IoT
Fase do SDL Build
Tecnologias aplicáveis Genérico
Atributos N/D
Referências N/D
Etapas

O dispositivo deve autorizar o chamador para verificar se ele tem as permissões necessárias para executar a ação solicitada. Por exemplo, digamos que o dispositivo seja uma fechadura de porta inteligente que pode ser monitorada na nuvem e que permite, entre outras coisas, trancar uma porta remotamente.

A fechadura de porta inteligente só permitirá que uma porta seja destrancada quando alguém se aproximar fisicamente dela com um cartão. Nesse caso, a implementação do controle e do comando remoto deve ser feita de modo a não disponibilizar recursos para destrancar uma porta, visto que o gateway de nuvem não está autorizado a enviar um comando para destrancar portas.

Executar verificações de autorização no Gateway de Campo se ele oferecer suporte a várias ações que exigem diferentes níveis de permissão

Title Detalhes
Componente Gateway de Campo de IoT
Fase do SDL Build
Tecnologias aplicáveis Genérico
Atributos N/D
Referências N/D
Etapas O Gateway de Campo deve autorizar o chamador para verificar se ele tem as permissões necessárias para executar a ação solicitada. Por exemplo, deve haver permissões diferentes para uma API/interface utilizada por um usuário administrador para configurar um gateway de campo e para os dispositivos que se conectam a ele.