Documentação do Oracle Cloud Infrastructure

Recomendações de Segurança

Para integrar com segurança seus aplicativos a domínios de identidades usando OAuth, implemente controles de segurança recomendados pelo padrão.

Os controles de segurança podem ser considerados obrigatórios ou opcionais, dependendo dos requisitos de confidencialidade, integridade e disponibilidade do aplicativo.

Uma integração OAuth segura requer:

  • Controles de segurança implementados em todos os participantes do OAuth, que incluem o Servidor de Autorização (IAM), o Proprietário do Recurso (usuário), o Cliente e os aplicativos do Servidor de Recursos

  • Confidencialidade das informações da chave: código, access_token, refresh_token, credenciais do cliente e credenciais do usuário

  • Autenticação do servidor estabelecida entre participantes do OAuth (para evitar ataques de personificação)

  • Validação de informações adequada para qualquer solicitação (especialmente para tokens de acesso JWT (JSON Web Token))

  • Uso de tokens com escopos mínimos e timeout (para reduzir a exposição em caso de divulgação e para suportar a revogação do token)

  • Uso de princípios típicos de segurança da informação, como privilégio mínimo

Recursos

Para obter mais informações sobre a segurança OAuth, acesse os seguintes links:

Observação

Recomendamos que você monitore a segurança de forma proativa para que possa identificar rapidamente novas ameaças à segurança.

Lista de Verificação de Recomendações de Segurança

Esta página lista as recomendações de segurança mais relevantes como uma lista de verificação, para que você possa validar a segurança do aplicativo e tratar os itens de segurança de acordo com suas expectativas.

Criptografia

  • Usar TLS nos Aplicativos Cliente e Servidor de Recursos

    O uso do TLS com todos os aplicativos fornece confidencialidade nas comunicações entre domínio de identidades, proprietários de recursos, aplicativos clientes e aplicativos do servidor de recursos. Isso evita a espionagem durante a transmissão do código de autorização, tokens de acesso, tokens de atualização, credenciais de cliente e credenciais de usuário e impede ataques de repetição.

  • Estabelecer Autenticação do Servidor (HTTPS com Validação de CA Confiável)

    A autenticação do servidor permite que clientes, servidores de recursos e proprietários de recursos estabeleçam comunicação entre si e com um domínio de identidades após verificar o certificado público em relação à CA confiável.

    Se o servidor não fornecer um certificado confiável (fornecido por uma CA confiável e com um nome de host correspondente), a comunicação será considerada um ataque man-in-the-middle.

    A autenticação do servidor impede ataques de spoofing, proxying, man-in-the-middle e phishing para capturar códigos de autorização, tokens de acesso, credenciais do cliente e credenciais do usuário.

  • Considere o Uso de uma Asserção Confiável com Domínios de Identidades

    Os clientes de segurança crítica podem usar uma asserção de cliente com criptografia de chave (em vez de um segredo de cliente) para autenticação.

  • Proteger o URI de Redirecionamento com HTTPS e Validação de CA Confiável

    O HTTPS e o uso da validação de CA confiável impede a autorização do phishing de "código" e a representação da sessão do usuário.

Administração

  • Configurar Aplicativos Seguindo o Princípio do Privilégio Mínimo

    Os aplicativos devem ser configurados em um domínio de identidades com apenas os direitos mínimos necessários para sua operação.

    Restringir o escopo, fluxos, tipos de concessão e operações melhora a postura de segurança e reduz o impacto de um aplicativo comprometido.

  • Especifique um Nome e uma Descrição Significativos para Aplicativos

    As informações do aplicativo são exibidas para os usuários nas páginas Meus Aplicativos e de consentimento.

    O uso de nomes e descrições de aplicativos significativos pode impedir que os usuários cometam erros durante a autorização de consentimento e também contribui para um melhor relatório de auditoria.

  • Fornecer uma Descrição Significativa para Escopos

    A descrição do escopo é exibida na página de deferimento. Explicar o escopo, que o usuário está prestes a conceder, de forma compreensível impede que o usuário cometa erros durante a autorização e contribui para uma melhor geração de relatórios de auditoria.

  • Evitar Escopos Fornecidos sem Consentimento

    Para alavancar a transparência e confiar no proprietário do recurso, forneça escopos sem permissão apenas quando um escopo for obrigatório, e o usuário não poderá negá-lo.

  • Reduzir o Timeout do Token de Acesso e Usar Tokens de Atualização

    Os domínios de identidades suportam JWT, um token de acesso que pode ser validado em servidores de recursos sem verificar o token no domínio de identidades. Por causa disso, os tokens de acesso com longa duração não podem ser facilmente revogados.

    Para implementar a revogação oportuna, você pode configurar o token de acesso com uma vida útil curta e, em seguida, usar o token de atualização para solicitar novos tokens de acesso. Para executar uma revogação oportuna, você precisa revogar o token de atualização.

  • Rotacionar os Segredos do Cliente do Aplicativo

    Para implementações críticas de segurança, implemente uma rotação de segredo do cliente. Isso reduz o risco de obter um segredo de cliente comprometido explorado.

Proprietário do Recurso (Usuário)

  • Manter o Proprietário do Recurso Informado

    O uso do escopo com consentimento fornece transparência ao proprietário do recurso e impede que os aplicativos solicitem escopos que não são necessários.

  • Detecção de Usuários

    Ensine aos usuários como proteger suas credenciais e identificar cliente, aplicativo do servidor de recursos e legitimidade do domínio de identidades (especialmente quando páginas de autenticação e consentimento aparecem). Isso reduz o risco de ataques de phishing e o comprometimento de credenciais do usuário.

Desenvolvimento de Aplicações

  • Proteger códigos, tokens de acesso, tokens de atualização e credenciais do cliente

    Os aplicativos devem preservar a confidencialidade dos códigos, tokens de acesso, tokens de atualização e credenciais do cliente. Ao desenvolver o aplicativo, considere as seguintes medidas (entre outras medidas de segurança do aplicativo):

    • Não armazenar códigos (use o código somente durante o runtime para obter o token de acesso)

    • Mantenha os tokens de acesso na memória transitória e limite suas concessões

    • Armazene tokens de atualização e credenciais do cliente em locais seguros que só possam ser acessados pelo aplicativo

  • Proteger o URL de redirecionamento

    O URL de redirecionamento (de onde o domínio de identidades recupera o código de autorização) é considerado um componente-chave para a segurança OAuth. Tenha cuidado ao definir esse URL para evitar ameaças, como falsificação de solicitações entre sites e negação de serviço.

  • Ler Tokens do Sistema de Arquivos de Aplicativos Nativos

    Os invasores podem tentar obter acesso ao sistema de arquivos no dispositivo e ler os tokens de atualização usando um aplicativo malicioso. Para reduzir esse risco, armazene segredos em armazenamento seguro e use o bloqueio do dispositivo para evitar acesso não autorizado ao dispositivo.

  • Implementar Controles para Dispositivos Clonados e Roubados com Aplicativos Nativos

    Para reduzir os riscos quando um dispositivo com Aplicativos Nativos for clonado ou roubado, use o bloqueio do dispositivo para evitar acesso não autorizado e revogar tokens de atualização.

  • Validar Segurança do Aplicativo Antes da Publicação

    Teste o aplicativo e sua segurança de ambiente de hospedagem antes de publicar o aplicativo para reduzir vulnerabilidades. As ameaças relacionadas à hospedagem e ao desenvolvimento de aplicativos não são tratadas pelos domínios de identidade. Essas ameaças incluem, mas não se limitam ao acesso indireto a bancos de dados e armazenamento de aplicativos, clickjacking, cross-site scripting, injeção de script/SQL e fluxos de confidencialidade de informações no aplicativo.

  • Aplicar Privilégio Mínimo Durante a Solicitação do Escopo

    Os aplicativos clientes devem solicitar tokens que contenham apenas escopos que possivelmente ou realmente usarão.

    O uso do urn:opc:idm:__myscopes__ scope, embora conveniente, pode recuperar mais tokens do que o necessário pelo aplicativo cliente.

    Um token com escopos extensos pode aumentar o impacto de segurança quando um token é comprometido.

    Consulte Escopos para obter informações sobre como usar o parâmetro de escopo e um token de acesso para conceder diferentes níveis de acesso a domínios de identidades.

  • Validar Tokens JWT

    Ao receber um token de acesso (JWT) de qualquer parte (exceto o servidor de domínio de identidades em uma solicitação direta do seu aplicativo), valide o JWT seguindo o Perfil JWT para Concessões de Autorização e Autenticação do Cliente 2.0 OAuth e as RFCs JWT.

    Consulte Validação de Token para obter mais informações sobre como validar o token.

    Observação

    Os servidores de recursos devem processar informações somente depois que toda a validação JWT for executada.

  • Receber Tokens JWT Corretamente

    Os aplicativos do servidor de recursos devem receber o token de acesso usando apenas o cabeçalho Authorization: bearer <token> para evitar ameaças relacionadas ao armazenamento no cache de parâmetros.

  • Implementar o TLS de 2 Maneiras entre os Aplicativos Cliente e Servidor de Recursos

    Para aplicativos críticos de segurança, você pode implementar um TLS de 2 vias entre aplicativos cliente e servidor de recursos para reduzir o risco de ataques de negação de serviço (DoS) e de representação.

    Não escreva aplicativos que coletem informações de autenticação diretamente dos usuários.

  • Impedir clickjacking

    Para navegadores mais recentes, evite iFrames durante a autorização impondo o uso do cabeçalho X-FRAME-OPTIONS.

    Para navegadores mais antigos, as técnicas de eliminação de quadros JavaScript podem ser usadas, mas podem não ser eficazes em todos os navegadores.

  • Evite o Uso de Credenciais de Senha do Proprietário do Recurso

    O fluxo do proprietário do recurso permite que um cliente solicite um token de acesso usando o ID, a senha e as próprias credenciais de um usuário final. Este tipo de concessão apresenta um risco maior porque:

    • É responsável por coletar as credenciais do usuário no aplicativo cliente (mantém o UID/anti-padrão de senha).

    • Não apresenta uma tela de consentimento para solicitações de escopo.

    Exceto por motivos de migração, evite o uso desse tipo de concessão.

  • Use o Cabeçalho Cache-Control="no-store"

    Este cabeçalho minimiza o risco de não proteger o conteúdo autenticado e vazar dados confidenciais em proxies HTTP.

  • Evitar Solicitações com Informações Confidenciais Enviadas Usando Parâmetros de URL

    Os parâmetros de URL (usados em solicitações GET) podem ser registrados em qualquer componente entre aplicativos, como logs de aplicativos, servidores proxy, firewalls e componentes de borda de rede.

    Os domínios de identidades implementam pontos finais REST de pesquisa alternativos usando POST que resolvem esse risco. Consulte a página Parâmetros de Consulta para obter mais informações.