Gestão de identidades na cloud
Um desafio comum na informática é determinar com precisão quem está a utilizar um sistema num determinado momento. A identidade de um utilizador final é importante por vários motivos. O mais importante dos quais é o de limitar a capacidade desse utilizador de aceder a recursos aos quais não tem autorização de aceder e de realizar ações a que não está autorizado. Por exemplo, uma pessoa que utilize o e-mail baseado na Web não deve ver os e-mails enviados a outros utilizadores. Da mesma forma, quando um administrador de banco de dados acessa um serviço de nuvem, ele não deve ser capaz de acessar bancos de dados pelos quais não tem responsabilidade ou executar outras tarefas administrativas que estão além do escopo de suas funções de trabalho. Nada disso será possível se não soubermos quem é o utilizador.
Existem inúmeros exemplos da forma como a identidade é estabelecida e apresentada para verificação na vida diária. Muitos países/regiões usam números de identificação, como números de segurança social, para identificar indivíduos para fins fiscais ou conceder-lhes acesso a programas governamentais. A aplicação da lei exige que os condutores de automóveis apresentem cartas de condução e recibos de registo de veículos para se identificarem e provarem que estão qualificados para conduzir um veículo a motor. As autoridades internacionais de controlo de fronteiras exigem que os viajantes tenham passaportes para indicar a sua nacionalidade.
No mundo online, a identidade é normalmente determinada desafiando um utilizador a fornecer credenciais que o identifiquem de forma única – por exemplo, um nome de utilizador e uma palavra-passe, uma impressão digital ou, como está a tornar-se cada vez mais comum nos smartphones, um rosto. (Avanços recentes em inteligência artificial elevaram o reconhecimento facial da magia para a ciência.) Eles podem ser desafiados a inserir credenciais quando fazem login no sistema pela primeira vez, o que normalmente é o caso dos portais administrativos para serviços em nuvem. Ou podem não ser desafiados até acederem a um recurso seguro, por exemplo, uma página Web disponível apenas para utilizadores autenticados. A autenticação é o processo de determinar quem é alguém, ou seja, confirmar a sua identidade para além de uma dúvida razoável. É separado da autorização, que determina o que um usuário pode ou não fazer depois de autenticado.
Os exemplos de como é determinada a identidade online são variados e numerosos. Eles também são altamente dependentes de cenários. Vamos considerar dois exemplos comuns de como a autenticação é utilizada para determinar a identidade de um utilizador. O primeiro diz respeito a um site público que exige que o utilizador inicie sessão antes de poder aceder a alguns ou todos os recursos do site. O segundo diz respeito à autenticação de utilizadores que acedem a partilhas de ficheiros, dispositivos de rede e outros recursos internos. Em ambos os casos, determinar a identidade do utilizador antes de lhe conceder acesso é crucial para a implementação de um sistema sólido e seguro.
Autenticação de utilizadores externos do site
Uma utilização comum da identidade digital é o iniciar sessão numa página da Web disponível apenas para os utilizadores autenticados, por exemplo, os utilizadores que compraram assinaturas para a edição online de um jornal. A primeira decisão que os programadores do site devem tomar é se eles próprios escreverão a lógica para permitir que os utilizadores se registem (criem contas) e iniciem sessão, ou utilizarão um fornecedor de identidade de terceiros. Um fornecedor de identidade é um serviço que efetua a autenticação dos utilizadores através de protocolos padrão, como o OAuth 2.0, OpenID Connect e SAML 2.0, e cada um dos quais implementa mecanismos para garantir a autenticidade das informações trocadas. Por exemplo, utilizam assinaturas digitais para garantir que as informações relativas à identidade não sejam alteradas quando transmitidas pela Internet.
Existem muitos serviços de fornecedor de identidade digital. As empresas das redes sociais, como o Facebook e o Twitter, podem atuar como fornecedor de identidade, ao permitir que os utilizadores usem credenciais estabelecidas nos seus próprios sites para aceder a outros sites. Também a Microsoft e a Google oferecem serviços de fornecedor de identidade, ao permitir que os utilizadores iniciem sessão noutros sites ao utilizar as suas próprias contas da Microsoft ou do Google. É precisamente isto que acontece quando utiliza a sua conta da Microsoft para iniciar sessão no E-mail do Outlook ou a sua conta do Google para iniciar sessão no Gmail, YouTube ou outros sites que suportam as contas do Google. Os fornecedores de serviço cloud oferecem serviços de fornecedores de identidade, bem como meios para integrarem-se a si mesmos ou a outros fornecedores de identidade nos sites. Com o Microsoft Entra ID, por exemplo, é relativamente simples construir um site que aceite logins privados, logins "públicos" usando contas do Facebook, Twitter, Microsoft ou Google, ou qualquer combinação dos dois.
A utilização de fornecedores de identidade de terceiros para autenticar os utilizadores possui três vantagens:
Segurança reforçada: os fornecedores de identidade de terceiros, como a Microsoft e a Google, têm uma vasta experiência no armazenamento e troca de credenciais de início de sessão de forma segura. Algumas das violações de segurança de perfil elevado ocorridas nos últimos anos aconteceram porque os programadores, que não eram especialistas em segurança, implementaram os seus próprios sistemas de início de sessão e caíram em erros comuns, como o armazenamento de palavras-passe de texto não encriptado numa base de dados. As palavras-passe não devem nunca ser armazenadas, ainda que estejam encriptadas. Em vez delas, devem ser armazenados hashes de palavra-passe unidirecionais, e devem ser utilizadas técnicas conhecidas, como o salting para ser mais difícil decifrar as palavras-passe1.
Muitos fornecedores de identidade suportam também a autenticação multifator (MFA) para ser mais difícil utilizar credenciais roubadas. Um exemplo de MFA na prática é quando inicia sessão num site e é-lhe pedido que introduza um código de acesso enviado para o seu telemóvel através de um SMS. Por fim, provedores de identidade de terceiros frequentemente implementam o Acesso Condicional, que ergue barreiras de segurança adicionais em tempo real, se justificado pelo histórico de login, localização geográfica ou outros fatores. É por este motivo que, às vezes, lhe pedem que indique informações adicionais quando inicia sessão num site, enquanto está a viajar. O fornecedor de identidade deteta um endereço IP a partir do qual não tinha iniciado sessão anteriormente e adiciona uma camada extra de segurança ao processo de autenticação.
Suporte para logon único (SSO): Usar 20 nomes de usuário e senhas para fazer login em 20 sites diferentes não é apenas um inconveniente, é um problema de segurança. Os utilizadores confrontados a gerir dezenas de nomes de utilizador e palavras-passe têm maior probabilidade de adotar comportamentos de segurança fraca, ao selecionar palavras-passe fáceis de adivinhar ou utilizar a mesma palavra-passe para várias contas. Um relatório indica que o número de contas que os usuários devem acompanhar dobra a cada cinco anos - um fenômeno conhecido como expansão de contas.
Por outro lado, se 20 sites não relacionados permitirem que os utilizador iniciem sessão com as respetivas contas da Microsoft, do Google ou do Facebook, será possível utilizar um conjunto de credenciais para todos os 20 sites. Esta funcionalidade é chamada início de sessão único. Reduz a proliferação de contas (e, por conseguinte, melhora a segurança), ao reduzir o número de credenciais que os utilizadores precisam de gerir.
Menos tempo de desenvolvimento: Escrever seu próprio código para gerenciar logins e credenciais de login também significa escrever código para criar novas contas, alterar senhas, recuperar senhas esquecidas, implementar MFA e Acesso Condicional e muito mais. Os fornecedores de identidade de terceiros prestam estes serviços gratuitamente. A maior parte do trabalho de codificação implica comunicar com os fornecedores de identidade com os protocolos estabelecidos e existem inúmeras bibliotecas disponíveis que o podem ajudar. Não é invulgar, quando se utilizam os fornecedores de identidade, implementar um sistema de gestão de contas e de início de sessão completo em menos de 100 linhas de código. Pelo contrário, o código escrito pelo fornecedor de identidade é várias ordens de grandeza mais extenso e complexo.
A Figura 3.1. mostra uma representação simplificada da interação entre um utilizador e um site que utiliza um fornecedor de identidade de terceiros para autenticar os utilizadores:
O site está configurado para utilizar um fornecedor de identidade no qual confia para autenticar os utilizadores. Quando o utilizador navega até ao site ou acede a uma página que requer autenticação, o site entra em contacto com o fornecedor de identidade e pede-lhe que autentique o utilizador.
O fornecedor de identidade desafia o utilizador a introduzir as suas credenciais. O fornecedor utiliza estas credenciais para estabelecer a identidade do utilizador e emite um token seguro que declara esta identidade. O token está assinado digitalmente para evitar adulteração e, às vezes, inclui informações como o nome e o apelido do utilizador e o endereço de e-mail.
O browser transmite o token para o site. O site verifica a autenticidade do token.
Se a validação for bem sucedida, o utilizador poderá continuar.
Figura 3.1: Autenticando usuários de um site.
Normalmente, logo que o site tenha confirmado a validade do token, o site emite um cookie HTTP encriptado com informações sobre a identidade do utilizador de maneira que o utilizador possa regressar à página por um determinado período de tempo sem precisar de iniciar sessão novamente. O cookie autentica, de forma eficaz, o utilizador nos pedidos subsequentes, como o fez o token de ID após o pedido inicial.
Uma funcionalidade importante deste fluxo é que o site nunca vê as credenciais do utilizador. Na verdade, não está ciente do modo de autenticação do utilizador. Por conseguinte, a responsabilidade de armazenar as credenciais do utilizador e fazê-lo de maneira segura recai no fornecedor de identidade. Além disso, o proprietário do site pode mudar o mecanismo físico utilizado para autenticar os utilizadores, ao passar, por exemplo, de nomes de utilizador e palavras-passe para impressões digitais, ao alterar a configuração no fornecedor de identidade em vez de reescrever uma grande quantidade de código.
Autenticação de utilizadores internos à organização
O que foi dito na secção anterior é relevante para uma equipa de desenvolvimento de software que vai criar um site que suporta utilizadores autenticados fora da organização. Mas suponha que é um administrador de TI cujo objetivo é autenticar os utilizadores dentro da organização a fim de proteger o acesso a partilhas de ficheiros e a outros recursos locais. Este cenário requer uma abordagem diferente para a identidade.
A maioria das empresas armazena as informações de identidade relativas aos utilizadores internos da organização, por exemplo, os funcionários de uma empresa, de forma local, num serviço de diretório. O serviço armazena os nomes de utilizador, os hashes de palavras-passe e outras informações numa base de dados (normalmente uma base de dados distribuída que suporta grafos hierárquicos) e apresenta o seu conteúdo por meio de protocolos padrão, como o Lightweight Directory Access Protocol ou LDAP. (Alguns serviços de diretório usam protocolos proprietários, mas estes estão se tornando menos comuns à medida que as organizações migram cada vez mais para código aberto e padrões abertos.) À medida que os usuários entram e saem da organização, os administradores atualizam o diretório de acordo. Quando um utilizador deixa a organização e é removido do diretório, não pode mais aceder aos recursos na rede da organização.
Um dos serviços de diretório mais populares é o Active Directory da Microsoft, que é uma família de serviços concebida para armazenar informações sobre os utilizadores e proteger o acesso aos recursos em rede. O Active Directory Domain Services armazena objetos, que podem representar utilizadores, computadores, partilha de ficheiros, impressoras e outros recursos. Os objetos podem ser organizados em domínios, os domínios podem ser organizados em árvores e as árvores podem ser organizadas em florestas, o que proporciona a flexibilidade necessária para modelar organizações de pequena e grande dimensão.
Não é importante compreender como funcionam os serviços de diretório, os protocolos que empregam ou o fluxo de informações que se cria com a utilização destes protocolos. O que é importante é saber que os serviços de diretório fornecem um repositório central para as informações de identidade sobre os utilizadores de uma organização. Como vai aprender, os serviços de diretório locais podem ser expandidos para que se apliquem também aos recursos da cloud, ao permitir que as organizações possam autenticar os utilizadores que acedem aos recursos da cloud da mesma forma que autenticam os utilizadores que acedem aos recursos locais. Entre outras coisas, tal permite aos administradores proteger o acesso aos recursos da cloud com as mesmas identidades que utilizam para proteger o acesso aos recursos locais. Além disso, permite que os utilizadores utilizem um único conjunto de credenciais para aceder a ambos.
Referências
- Auth0 (2018). Adicionando sal ao hashing: uma maneira melhor de armazenar senhas. https://auth0.com/blog/adding-salt-to-hashing-a-better-way-to-store-passwords/.