O que é SSO (Single Sign-On)? Como o SSO Funciona?

Todos nós fazemos isso, e sabemos que não devemos. Tem aquele arquivo no telefone ou pedaço de papel na carteira, ou pior, um post-it colado na parte de trás do teclado, contendo nomes de usuário e senhas. Depois, há o hábito de usar o nome do nosso cão, juntamente com alguns números e alguma pontuação.

A verdade é que a vida moderna no mundo da web significa que precisamos de alguma forma rastrear dezenas de nomes de contas e senhas. A menos que você seja dotado de uma memória notável, eles não serão todos diferentes. Principalmente eles são simples, eles são velhos, e se alguém realmente tentou, eles são adivinháveis. É um presente para os possíveis cibercriminosos, e é 100% evitável.

O que é SSO (Single Sign-On)?

A tecnologia de login único é uma solução parcial para o problema de senha que nos assola tanto no trabalho quanto em nossas vidas pessoais. Ele nos permite fazer login uma vez em um servidor de autenticação, que emite certificados em nosso nome que servem como credenciais verificadas para os aplicativos participantes.

As chances são de que você tenha usado esse sistema. Se você optou por "Fazer login com a Apple", ou Google, ou algum sistema de gerenciamento de identidade de outro grande fornecedor, em vez de criar uma nova senha para um aplicativo web, você está usando o SSO. Cada vez mais, o SSO também é usado na empresa, muitas vezes em combinação com outras tecnologias de autorização para proteger sistemas corporativos e tornar a manutenção de senhas legível em dezenas a centenas de aplicativos e serviços.

Principais Conclusões

• O SSO alivia o incômodo de uma pessoa que precisa lembrar de muitas combinações de senha e nome de usuário.
• O SSO facilita a vida das equipes de TI, fornecendo a elas apenas um sistema de autenticação para gerenciar para toda a organização.
• O SSO também permite que aplicativos autenticarem usuários em serviços que o aplicativo precisa operar, como aqueles que gerenciam conexões de rede ou verificam atualizações de software.

SSO Explicado

O conceito de single sign-on é simples: em vez de fornecer um nome de usuário e senha ou se identificar de outra forma com cada aplicativo que você usa, você fornece essas informações apenas uma vez para um servidor de autenticação. Uma vez feito isso, o servidor de autenticação envia certificados de identificação em seu nome quando você acessa qualquer aplicativo que participa do sistema SSO.

O SSO reduz o número de nomes de usuário e senhas que você precisa saber. Ele também pode reduzir significativamente o número de vezes que você é solicitado a fornecer credenciais de identificação, tornando mais fácil usar uma ampla gama de aplicativos e mais provável que você crie senhas mais fortes. Do ponto de vista dos planejadores corporativos de TI, o SSO permite que eles atualizem os procedimentos de segurança e implantem mecanismos de autenticação mais avançados a serem usados pelo servidor de autenticação, permitindo que todos os aplicativos participantes desfrutem de autenticação mais segura sem a necessidade de modificação.

Na sua vida pessoal, usar o sistema de autenticação de um grande fornecedor em vez de configurar manualmente um novo nome de usuário e senha em cada aplicativo traz vários benefícios. Uma das principais vantagens é que os grandes fornecedores de serviços de gerenciamento de identidade federada são bons em proteger senhas e outros dados pessoais confiados a eles pelos clientes. Um novo fornecedor com um novo aplicativo pode não proteger tão bem as credenciais que você fornece.

Como o SSO Funciona?

O SSO funciona pedindo aos usuários que se autentiquem em um servidor SSO em vez de em aplicativos individuais. Uma vez concluído o processo de autenticação, o servidor SSO fornece certificados para os aplicativos que um indivíduo autenticado deseja acessar. Os certificados servem para verificar a identidade do usuário.

Os certificados são geralmente válidos por apenas um determinado período de tempo e geralmente estão vinculados ao sistema a partir do qual os usuários individuais se autenticaram. Para participar, os aplicativos devem ser escritos de forma a permitir que eles usem o serviço de SSO. Na empresa, os planejadores de TI normalmente escolhem um modelo de SSO e, em seguida, exigem que os aplicativos o usem para verificar as identidades dos funcionários. Isso pode ser um problema para aplicativos monolíticos mais antigos que criam seus próprios repositórios de credenciais de usuário ou que podem não suportar arquiteturas SSO comuns.

Tipos Comuns de Configuração de SSO

Componentes e conceitos comuns de SSO compartilham várias características, incluindo gerenciamento de identidade centralizado, padronização e medidas de segurança robustas. Uma chave é a interoperabilidade — esses sistemas precisam trabalhar juntos para garantir que o processo de autenticação seja fácil de usar e funcione sem problemas em vários aplicativos. Quando isso for alcançado, as equipes de TI descobrirão que serão capazes de exigir senhas mais seguras e autenticação de dois fatores com resistência mínima.

• SAML. Security Assertion Markup Language (Linguagem de Marcação de Asserção de Segurança) é uma especificação técnica que descreve a estrutura de um documento que servirá para autenticar usuários em aplicativos. O SAML usa o padrão XML amplamente aceito para especificar a estrutura do documento que os servidores de identidade — também conhecidos como provedores de identidade — criam e enviam aos aplicativos. Esses aplicativos são frequentemente chamados de "provedores de serviços" na linguagem SSO. Qualquer provedor de identidades usando o SAML criará credenciais de autenticação que podem ser usadas por qualquer aplicativo com conhecimento do SAML, tornando-o uma boa escolha para aplicativos da Internet.

  O SAML não fornece um mecanismo para garantir que as informações de autenticação que um aplicativo recebe estejam inalteradas. Isso é tratado por outras tecnologias.

• Kerberos. Criado no MIT no final do 1980s como parte do Project Athena, o Kerberos é uma arquitetura completa de autenticação e autorização. O Projeto Athena procurou criar uma rede de recursos computacionais universalmente acessíveis aos alunos do MIT em todo o campus. O Kerberos usou originalmente o DES (Data Encryption Standard) para criptografar mensagens passadas entre servidores de autenticação e aplicativos. Usava chaves simétricas de 48 bits, o que significa que a mesma chave é usada para criptografar e descriptografar mensagens. Na época, o DES era a forma mais segura de criptografia disponível como um padrão mantido pelo National Institute of Standards and Technology (NIST).

  Atualmente, o Kerberos usa o Advanced Encryption Standard (AES), que substituiu o DES nos padrões de criptografia do NIST. O AES especifica chaves mais longas, com até 256 bits de comprimento, e permite várias rodadas de criptografia, tornando o sistema muito difícil de quebrar.

  Como o Kerberos usa criptografia de chave simétrica, ele requer um terceiro confiável para gerenciar chaves, tornando-o mais apropriado para aplicativos empresariais onde um domínio de uso pode ser firmemente estabelecido, geralmente limitado às LANs e VPNs da empresa. Embora o Kerberos possa ser usado na internet, onde nenhum domínio será estabelecido usando um padrão de autenticação diferente, a criptografia de chave pública, para iniciar o processo, ele raramente é empregado dessa maneira. O Kerberos pode usar seu próprio formato de credencial ou ser configurado para usar o SAML. Ele continua popular, inclusive com a Microsoft, que usa o padrão Kerberos em vez de seu sistema de autenticação NTLM menos seguro para redes corporativas.

• OAuth. Como um framework de autorização aberta que não inclui um framework de autenticação, OAuth é o sistema padrão quando um aplicativo de internet precisa acessar os recursos de um serviço protegido em nome de um usuário. A maioria dos provedores de nuvem, incluindo a Oracle com sua Oracle Cloud Infrastructure (OCI), usa o OAuth para gerenciar o acesso aos seus recursos de nuvem. A Oracle também oferece bibliotecas e serviços que facilitam para os desenvolvedores criar seus próprios aplicativos que usam o OAuth.

  Estes são os componentes principais de um sistema OAuth:

  • O sistema cliente, geralmente um aplicativo de usuário final que pode querer acessar os recursos de vários serviços disponíveis na internet.
  • O servidor de autorização, que recebe solicitações de tokens que permitirão que um cliente acesse serviços protegidos. O servidor de autorização receberá solicitações de tokens junto com o certificado de autenticação do cliente. Ele emitirá tokens de acesso que foram autorizados pelo proprietário do recurso.
  • O servidor de recursos, que tem as informações ou fornece o serviço que o cliente está procurando usar. Fornece dados ou serviços quando recebe tokens de acesso válidos do cliente.

  Uma variedade de tipos de concessão de acesso pode ser especificada pelo token de acesso. Os vários tipos são emitidos dependendo do nível de confiança exigido e da natureza do dispositivo do cliente. Por exemplo, uma smart TV pode receber uma concessão de acesso diferente de um laptop.

• OpenID Connect (OIDC). O OpenID Connect é o sistema de gerenciamento de identidades criado para uso com o OAuth. Juntos, o OIDC e o OAuth fornecem um ambiente de SSO completo para aplicativos baseados na Web e sistemas nativos da Internet, como aplicativos móveis. Em vez de usar o SAML como base para retornar informações de credenciais, o OIDC usa um documento JSON conhecido como JSON Web Tokens, descrito abaixo, e protocolos RESTful; ambos são nativos da internet e simples para os desenvolvedores usarem.

  Em vez de usar a criptografia de chave simétrica como o Kerberos, o OIDC usa criptografia de chave pública, o que melhor se presta a redes sem domínio como a internet.

• Autenticação de cartão inteligente. Sistemas como o OIDC usam criptografia de chave pública para garantir que apenas os destinatários pretendidos possam ver os dados trocados com um provedor de gerenciamento de identidades durante e após a autenticação. A criptografia de chave pública é assimétrica e envolve uma chave pública, que pode ser usada para criptografar mensagens a serem enviadas a um cliente ou servidor, e uma chave privada que é secreta e que deve ser usada para descriptografar mensagens.

  Geralmente, as chaves privadas são armazenadas no dispositivo de um usuário. A maioria dos laptops vem com um chip resistente a adulterações que usa a tecnologia Trusted Platform Module (TPM) para descriptografar mensagens destinadas ao sistema. Os telefones Apple e Android usam sistemas diferentes, mas semelhantes. A Apple é chamada de Secure Enclave e a Android é chamada de Android Knox. Essas tecnologias permitem que o dispositivo forneça sua chave pública para qualquer sistema que o solicite corretamente e usará sua chave privada que nunca é divulgada para descriptografar as mensagens que recebe.

  A vantagem desses sistemas é que o usuário do dispositivo não precisa saber nada sobre como a criptografia é tratada em seus sistemas. A desvantagem é que cada dispositivo que o usuário possui terá um único par de chaves públicas / privadas, de modo que os dispositivos são conhecidos individualmente no processo de criptografia. Se um laptop ou telefone for perdido ou roubado, seu sistema de criptografia não ajudará a impedir o acesso se o ladrão souber a senha do proprietário.

  Usar um cartão inteligente com um chip semelhante aos chips incorporados em cartões de crédito permite que os usuários sejam autenticados com um conjunto de chaves, independentemente dos dispositivos que estão usando. O chip no cartão é seu próprio microprocessador, por isso deve ser inserido em um leitor de cartão ou ativado e alimentado usando uma tecnologia RFID, como comunicações de campo próximo. A segurança do cartão inteligente é semelhante à oferecida pelos chips TPM.

• SSO da empresa. Grandes organizações com infraestruturas de aplicações complexas podem criar um sistema de SSO empresarial, ou eSSO, que é limitado aos espaços de suas redes. Os funcionários apreciarão a necessidade de conhecer apenas uma ou duas senhas e nomes de usuário para acessar os aplicativos que seu trabalho exige, e a organização se beneficiará de uma segurança melhor e mais gerenciável para sistemas e dados. Esses sistemas de eSSO podem preferir a criptografia de chave simétrica com base em sua capacidade de revogar chaves com mais facilidade e SAML por seu formato bem conhecido, e geralmente empregam vários tipos de autenticação multifator para melhor segurança de endpoint.

  À medida que os aplicativos SaaS se tornam mais comuns, as empresas têm a opção de migrar para um sistema como OAuth, que é mais comumente usado na internet, ou que exige que os aplicativos SaaS se encaixem na estrutura de eSSO que a empresa escolheu. O SAML pode ser usado na rede corporativa e na internet. Muitos aplicativos SaaS suportarão ambos os frameworks para autenticação de usuário.

• SSO da Web. É provável que os aplicativos Web funcionem melhor com ou sejam limitados ao uso do OAuth para autorizar a atividade do usuário e do OpenID Connect para autenticar usuários. Como a internet é considerada o transporte, os componentes de um sistema Web SSO são definidos como um padrão IETF e, portanto, tendem a funcionar de uma forma que os desenvolvedores web esperam e apreciam. Além disso, a autenticação é fortemente acoplada à autorização e usa métodos de acesso como protocolos REST e padrões de informação baseados em JSON para criar um sistema completo e extensível. Os sistemas SSO da Web também se destinam a funcionar em domínios e em escala.

• LDAP. O Lightweight Directory Access Protocol foi introduzido pela primeira vez no 1990s para permitir que os usuários encontrem recursos que eles possam querer usar em uma rede local, como servidores ou impressoras. Ele prevê um servidor autorizado que saberá sobre todos os recursos dentro de um domínio. Como tal, não é adequado para uso na internet.

  Como o LDAP é usado para conceder acesso a recursos de rede, ele inclui um sistema de autenticação de usuário com as credenciais do usuário armazenadas no servidor LDAP. Seus mecanismos de autenticação de usuário não são fortes; por exemplo, ele envia senhas pela rede como texto claro. A criptografia pode ser fornecida por outro protocolo, como SSL/TLS.

  O LDAP tem a vantagem de ser flexível e extensível, para que as empresas possam usá-lo para armazenar informações adicionais sobre funcionários, como funções organizacionais e associações de grupos, além de atributos como local do escritório e número de telefone. Ainda assim, privilégios de acesso mais granulares são frequentemente necessários na empresa – pense em informações sobre quem tem acesso a determinados dados – e esses direitos de acesso não podem ser facilmente gerenciados pelo LDAP.

• JWT Os JSON Web Tokens são documentos compactos usados para transmitir informações de forma segura entre as partes de forma estruturada. Eles preenchem a mesma necessidade dos documentos SAML, mas em formato mais curto, o que os torna adequados para inclusão em URLs. Os JWTs são assinados criptograficamente usando técnicas de criptografia de chave pública para garantir a autenticidade. Em Open Authentication (Oath), depois que um usuário for autenticado, o servidor de identidades retornará um token de ID JSON.

  As solicitações de autorização para acessar recursos protegidos retornarão subsequentemente um token de acesso JSON, que deverá ser incluído em cada solicitação ao servidor de recursos. Essas transações transferem o estado do cliente — neste caso, autenticado e autorizado — como parte de cada solicitação, tornando-as chamadas de trocas RESTful. O REST, que significa "transferência de estado representacional", é benéfico porque os servidores de recursos não precisam estabelecer e manter sessões com todos os clientes que desejam usar os recursos do servidor.

  Os JWTs são documentos de texto sem formatação, portanto devem ser usados em conexões criptografadas por HTTPS. Os tokens geralmente são projetados para que não contenham dados confidenciais, como informações de identificação pessoal. Como cada token é assinado de acordo com o X.509, o padrão internacional para formatação de certificados de chave pública, essa assinatura será validada pelos servidores de recursos para garantir que o token não tenha sido adulterado. Os JWTs são componentes de um sistema de autenticação e autorização OAuth/OpenID. Eles são projetados para uso por aplicativos web, dimensionam bem e são destinados a serem usados em todos os domínios.

Benefícios do SSO

Os profissionais de TI e segurança tendem a ser fãs do SSO; eles entendem que isso significa centralizar a autenticação do usuário, proteger informações potencialmente confidenciais e gerenciar a integração com sistemas e aplicativos corporativos. Eles geralmente ficam felizes em lidar com o treinamento de usuários necessário e abordar o monitoramento e a manutenção contínuos. Isso é resultado direto de vários benefícios significativos que vêm com a tecnologia.

• Acesso centralizado. Os sistemas SSO simplificam a carga de gerenciamento de contas de usuário e acesso aos muitos aplicativos que a maioria das empresas e provedores de nuvem de internet mantêm. O acesso do usuário a todos os aplicativos pode ser concedido e revogado em um só lugar. Assim, se, por exemplo, um funcionário sair de uma organização, os administradores não precisarão remover as credenciais do funcionário para cada aplicativo individualmente. Os profissionais de segurança também podem fazer alterações nos sistemas de autenticação em apenas um lugar, em vez de precisar fazer alterações em cada aplicativo.
• Segurança aprimorada. O SSO reduz muito o número de pares de nome de usuário e senha que os funcionários precisam memorizar. Com essa carga reduzida, é razoável, especialmente para as empresas, melhorar a segurança das trocas de autenticação com autenticação multifator e políticas de senha forte.
• Maior produtividade dos funcionários. Os funcionários terão menos dificuldade em lembrar nomes de usuário e senhas quando o SSO estiver em vigor. Após a autenticação, as pessoas geralmente podem acessar aplicativos sem reautenticar. O SSO deve, portanto, permitir que os funcionários cheguem mais rápido à tarefa planejada. Dependendo dos detalhes da implementação, talvez eles ainda precisem se autenticar nos aplicativos que usam, mas pelo menos precisarão lembrar apenas de suas credenciais de SSO.
• Redução da fadiga de senhas. Convenhamos, ninguém quer lidar com dezenas de pares de nome de usuário e senha. A dificuldade de lembrar senhas complexas, especialmente se elas precisarem ser alteradas com frequência, pode levar à frustração e resultar em pessoas usando senhas fáceis de adivinhar, reutilizando a mesma senha para várias contas ou empregando o método de gerenciamento de senhas com Post-its. O SSO alivia esse fardo.
• Conformidade regulatória. O SSO pode facilitar a conformidade regulatória por meio dos benefícios do gerenciamento de acesso centralizado acabado de descrever. A auditoria e a correção também são simplificadas, pois há apenas um framework SSO para verificar.
• Integração simplificada. Uma empresa típica gerencia petabytes de dados armazenados em muitas instâncias de banco de dados. Não é difícil imaginar um banco de dados para dados de manufatura, outro para dados da cadeia de suprimentos e outros para dados financeiros, de marketing, de vendas e assim por diante. Também é fácil entender o quão útil seria para os vendedores terem acesso aos dados do estoque, por exemplo. Um sistema de CRM pode acessar esses dados, mas cada vendedor deve ser conhecido pelo banco de dados de gerenciamento de estoque, bem como pelo sistema de CRM. O SSO pode fornecer a identidade verificada necessária do solicitante, e os tokens de acesso podem ajudar a determinar quais dados uma pessoa em cada função deve ter permissão para ver. Sem o SSO, a integração entre o CRM e o sistema de inventário seria muito mais difícil de criar e gerenciar e envolveria outra etapa de autenticação para os usuários ou uma segurança potencialmente mais fraca para os dados de inventário.
• Experiência do usuário simplificada. Reduzir a necessidade de autenticação em aplicativos empresariais e aplicativos Web geralmente proporciona uma melhor experiência do usuário. E como muitas pessoas estão acostumadas ao SSO por meio de sua presença pessoal on-line, muitas vezes é necessário um treinamento mínimo.

SSO e segurança: o SSO é seguro?

Primeiro, não existe segurança, existem apenas níveis de segurança. Dito isto, qualquer estrutura de SSO disponível comercialmente será altamente segura, o que faz parte do objetivo da tecnologia. Geralmente, o sistema SSO por si só não é uma solução de segurança total. Em vez disso, é um componente importante de um ambiente seguro. Seu papel como um sistema para autenticar usuários e fornecer credenciais de autenticação para aplicativos e outros sistemas de fornecimento de recursos é uma parte crítica de uma estratégia de segurança geral.

SSO e privacidade

O SSO se presta a uma melhor privacidade, mas a privacidade pode variar com cada implementação. Por exemplo, as respostas SAML e JWT conterão, no mínimo, uma asserção de autenticação. Também podem conter informações, como grupos e funções que se aplicam ao usuário, bem como outros dados que os implementadores optam por fornecer.

No varejo on-line ou nas mídias sociais, pode ser útil para o aplicativo saber a idade, a localização e outras informações pessoais de um usuário. Geralmente, se você estiver fornecendo essas informações pessoais para o Facebook, presuma que o Facebook as fornecerá a outras pessoas, a menos que a política de privacidade diga que não o fará ou que o aplicativo permita que você diga explicitamente para não compartilhar algumas informações.

Na empresa, os sistemas SSO devem retornar asserções de autenticação juntamente com as funções relevantes que o usuário tem na organização. Também pode ser útil oferecer o escritório da empresa onde o usuário trabalha e o número de telefone comercial. Outras informações devem ser mais difíceis de obter. O que é fornecido por padrão geralmente é determinado pelas políticas de RH.

Casos de uso do SSO

O SSO foi projetado para fornecer aos usuários acesso contínuo a vários aplicativos e sistemas com apenas um conjunto de credenciais de login. Embora as organizações que têm requisitos rigorosos de conformidade regulatória possam achar que precisam implementar medidas de segurança adicionais, há muitos casos de uso para SSO. Eles incluem o seguinte:

• Aplicativos empresariais. Uma empresa geralmente gerencia dezenas a centenas de aplicativos, cada um exigindo que os usuários sejam autenticados. Criar e manter sistemas de gerenciamento de identidade por aplicativo não é prático para usuários ou equipes de TI. O SSO oferece uma maneira de autenticar funcionários uma vez e, em seguida, gerenciar sua autorização para usar recursos com base nessa autenticação única.

  As asserções de autenticação são normalmente válidas por apenas um determinado período e em um único sistema. Detalhes mais específicos sobre as funções de cada funcionário na empresa podem ser mantidos pelo sistema SSO e usados por aplicativos ou sistemas de autorização para fornecer acesso limitado a aplicativos, dados e outros recursos.

• Aplicativos baseados em nuvem. Para uso comercial e de consumidores, os sistemas baseados em nuvem vêm com diferentes necessidades de identificação e autorização em comparação com os sistemas SSO destinados à empresa. Para os consumidores, a conveniência pode determinar que, uma vez que os usuários são autenticados, eles podem usar o serviço perpetuamente a partir desse dispositivo. Uma vez conectado ao Gmail, por exemplo, você pode usá-lo e outros aplicativos do Google, como Docs ou Sheets, sem reautenticar. Nos negócios, os provedores de serviços de nuvem que oferecem aplicativos ou plataformas SaaS e a infraestrutura como serviço também permitirão amplo acesso aos seus serviços quando a identidade do usuário for confirmada. A autenticação é o primeiro passo em um esquema de autorização de serviço maior que permite aos usuários fazer login uma vez e usar uma ampla gama de serviços. O acesso ao serviço dependerá da função de cada usuário para cada aplicativo — talvez ele seja um administrador em um aplicativo, um desenvolvedor em um segundo e um usuário final em um terceiro. O acesso também dependerá do que a organização pagou.

Implementação SSO

Não deixe que a falta de experiência interna em segurança o afaste da adoção do SSO. Provedores de serviços de segurança gerenciados, bem como equipes de implementação de fornecedores de SSO estão lá para ajudar. Muitas empresas optam por usar serviços de SSO oferecidos por provedores de terceiros. A empresa se beneficia da experiência, dos recursos avançados de segurança e da escalabilidade, e as equipes de TI podem se concentrar em ajudar a expandir os negócios, deixando o gerenciamento de SSO para os especialistas.

Em um nível alto, a implementação requer três elementos principais.

1. Escolher e distribuir sistemas de autenticação de clientes que coletarão com segurança as informações do usuário final, como nome de usuário e senha. Mesmo na empresa, esses sistemas geralmente são fornecidos como páginas da Web, por isso é fácil manter os processos de autenticação uniformes entre os dispositivos. Geralmente, na empresa, o usuário deve estar na rede da empresa ou acessá-la por meio de uma VPN. Esse requisito permite que a organização crie um sistema de gerenciamento de ID único e autorizado.
2. Configurar um gerenciador de IDs que autenticará usuários e emitirá certificados em nome da organização. Na maioria das lojas, o gerenciador de ID será parte de um sistema que também fornece tokens de autorização de usuário que permitem que os aplicativos saibam o que um indivíduo pode fazer dentro do aplicativo ou estão fortemente vinculados ao servidor de autorização.
3. Configurar ou modificar aplicativos para usar os certificados e tokens do SSO e dos sistemas de autorização, em vez de manter seu próprio sistema de ID de usuário.

Melhores Práticas de SSO

Não importa se você está implementando internamente, com a ajuda de terceiros ou usando um modelo como serviço, há chaves para o sucesso. Eles incluem o seguinte:

1. Exigir autenticação multifator (MFA). Assim como o SSO permite que as organizações apliquem políticas de senha de um único framework, ele também pode permitir que as organizações implementem uma tecnologia de identificação mais forte, conhecida coletivamente como autenticação multifator. Esses fatores podem incluir cartões inteligentes, aplicativos executados em smartphones, várias formas de autenticação biométrica e outros.
2. Realize o controle de acesso baseado em funções (RBAC). A autenticação de usuários resolve apenas parte do problema de gerenciar o acesso a recursos empresariais. O outro desafio é limitar o acesso dos usuários apenas aos recursos que eles têm permissão para usar. Ao estabelecer grupos — como marketing, finanças, manufatura e vendas — e ao estabelecer funções dentro de cada grupo para seus membros, o controle de acesso pode ser ajustado e mantido em um local central e gerenciável.
3. Auditar e atualizar padrões. Ter a autenticação centrada em uma única estrutura de mecanismos simplifica muito a auditoria e o processo de fazer atualizações para atender a novos padrões à medida que surgem.
4. Implementar o gerenciamento de permissões e funções. O SSO se presta à filosofia de confiança zero. Os usuários podem acessar apenas os recursos explicitamente necessários para suas funções e ver apenas os dados para os quais têm permissão explícita.
5. Aderir às leis de privacidade dos dados. O uso de uma estrutura SSO não garante a conformidade com as leis de privacidade de dados, mas pode facilitar muito a obtenção e a demonstração dessa conformidade.

Controle o Acesso com Segurança e Facilidade com a Oracle

Precisa gerenciar identidades de usuário e acesso para a Oracle Cloud Infrastructure (OCI) e entre aplicações na nuvem e on-premises? Para organizações que buscam uma estratégia de segurança de confiança zero, o Oracle Cloud Infrastructure Identity and Access Management (IAM) fornece as ferramentas de gerenciamento e integração necessárias.

Interessado em implantar um autenticador universal com suporte a autenticação multifator? O Oracle Access Management oferece um sistema flexível que pode ser executado on-premises ou na nuvem. As organizações podem permitir que essas políticas sigam o usuário, independentemente do dispositivo e do local, para ajudar a garantir o acesso aos dados em todos os lugares, a qualquer momento, usando qualquer dispositivo. Junto com a MFA, o portfólio de IAM da Oracle oferece suporte a SSO de dispositivo confiável e SSO de aplicativo - tudo necessário para atingir os princípios e exigências da arquitetura zero trust.

À medida que as empresas dependem de mais aplicativos e os aplicativos dependem de mais serviços e fontes de dados para fazer seu trabalho, a autenticação e a autorização do usuário se tornam mais difíceis de gerenciar. As estruturas SSO simplificam a vida dos usuários finais e dos arquitetos de aplicativos, simplificando o processo de autenticação e autorização.

Perguntas Frequentes sobre SSO

O que significa SSO?

SSO significa single sign-on.

Qual é a minha conta SSO?

Sua conta SSO é um serviço de autenticação centralizado que permite usar um conjunto de credenciais de login para acessar vários aplicativos e sistemas. Isso significa que você precisa lembrar apenas um nome de usuário e uma senha para acessar todos os serviços e recursos que sua organização fornece. As contas SSO simplificam o processo de login, melhoram a segurança e facilitam o acesso dos usuários às informações e ferramentas necessárias para realizar suas tarefas.

Qual é o exemplo de um SSO?

No espaço do consumidor, grandes fornecedores como Amazon, Google, Meta e Microsoft podem atuar como uma fonte de credenciais de usuário para outros aplicativos. Se você tiver uma caixa de diálogo que permita inserir suas credenciais ou fazer log-in usando um dos serviços acima, você estará usando o SSO.