Com o passar dos anos, você deve ter ouvido falar muito sobre gerenciamento de acesso (Access Management). Então, é comum acreditar que já sabemos tudo sobre gerenciamento de acesso (Access Management). No entanto, usávamos os termos “autenticação” e “gerenciamento de acesso” como se fossem sinônimos. Entretanto, existem diferenças entre os dois. Afinal, a autenticação valida a identidade de um usuário. Contudo, o gerenciamento de acesso determina que um usuário tem permissão para acessar um determinado recurso. Então, ele aplica a política de acesso que foi configurada para esse recurso.
O gerenciamento de acesso (Access Management) é muito importante. Especialmente quando se trata de gerenciar o acesso aos recursos da nuvem. Afinal, atualmente é comum uma pessoa precisar acessar vários aplicativos em nuvem ao longo do dia. Contudo, isso é um incômodo para usuários e para a TI. Por que? Porque os usuários precisam se lembrar de inúmeras senhas. Em paralelo, a TI precisa redefinir senhas esquecidas indefinidamente.
Contudo, há uma solução para esse problema. Trata-se do SSO, que permite ter uma credencial para todos os aplicativos da nuvem. Dessa forma, os usuários podem facilmente fazer login uma vez em vários aplicativos. Enquanto isso, a TI economiza um tempo precioso com redefinições de senha.
Vale ressaltar que essa identidade única é tão segura quanto a autenticação usada para verificá-la. Portanto, o método de verificar as identidades dos usuários é fundamental para manter a segurança do acesso à nuvem. Para este fim, soluções de gerenciamento de acesso (Access Management) e de logon único oferecem mais controle sobre o acesso. Tal como às políticas definidas por aplicativo. Então, ao exigir um fator de autenticação adicional em situações de alto risco, mantém-se uma experiência de usuário sem atrito.
Dicionário de termos de gerenciamento de acesso (Access Management)
Autenticação e gerenciamento de acesso (Access Management)
As soluções de autenticação e gerenciamento de acesso (Access Management) são compostas pela funcionalidade de governança e administração de identidade (IGA) e acesso a funcionalidade de gerenciamento (AM).
As soluções IAM fornecem uma estrutura metódica para conceder (e solicitar) acesso a aplicativos (IGA). Isso é feito aplicando controles de acesso (AM) e garantindo visibilidade em eventos de acesso (AM). Contudo, a maioria das organizações implementam componentes IGA e AM separadamente. Portanto, essas disciplinas estão sendo cada vez mais avaliadas como famílias de soluções distintas e autônomas. Ou seja, deixam de ser tratadas como funcionalidades compostas de um único pacote de autenticação e gerenciamento de acesso (Access Management).
Gestão de acesso (Access Management)
O gerenciamento de acesso (Access Management) é uma funcionalidade com objetivo simples. Afinal, permite determinar se um usuário tem permissão para acessar um determinado recurso. Consequentemente, permite a aplicação da política de acesso que foi configurada para esse recurso.
O gerenciamento de acesso (Access Management) é implementado com base em políticas de acesso. Estas são definidas por administradores de TI e incluem informações de quais grupos de usuários (por exemplo, Vendas, P&D, RH) têm acesso a determinados aplicativos em nuvem (por exemplo, Salesforce, Office 365, Jira, Taleo). Contudo, inclui também o conjunto de atributos de usuário necessários para acessar cada aplicativo. Por exemplo, rede confiável, senha, OTP, etc.
A política de acesso pode exigir que mais ou menos atributos do usuário sejam avaliados. Tudo depende da sensibilidade de um aplicativo em nuvem. Esses atributos são avaliados com base em risco ou contexto de autenticação. Afinal, isso é fundamental para fazer cumprir as diferentes políticas de acesso definidas para cada aplicativo em nuvem.
O logon único também é central para o gerenciamento de acesso à nuvem. Afinal, ele permite o uso de um único conjunto de nome de usuário e senha ou “identidade” para fazer login em todos os aplicativos da nuvem.
IDaaS
IDaaS significa IAM-as-a-Service. Contudo, também é chamado de identidade-as-a-service. Seu intuito é descrever soluções de gerenciamento de identidade e acesso (IAM) que oferecem um modelo de entrega como serviço baseado em nuvem para gerenciamento de acesso e autenticação.
Nos últimos anos o IDaaS foi revisado como sendo um mercado separado. Contudo, dadas as tendências recentes do mercado, daqui para frente será tratado como duas disciplinas separadas. A de Gerenciamento de Acesso e IGA, cujos métodos de entrega incluem instalações no local, software ou baseiam-se em plataformas de nuvem.
Governança e administração de identidade (IGA)
As soluções de Governança e Administração de Identidade (IGA) ajudam a responder às seguintes perguntas:
“Quem deve receber acesso, ou quem tem ‘direito de acesso’, para cada aplicação?”
“Quem, na prática, teve acesso a qual aplicação, por quem e quando?”
Ou seja, uma solução IGA pode ajudar a estabelecer que a equipe de P&D tem direito de acesso a determinados desenvolvimentos de aplicativos. É o caso de:
- GitHub;
- Jira;
- Confluence.
Uma solução IGA pode provisionar automaticamente o acesso a esses aplicativos, com base em sua associação ao grupo P&D. Contudo, o usuário de P&D também pode solicitar acesso a outros aplicativos. Entretanto, essa solicitação passaria por um processo de aprovação de gerenciamento suportado por algumas soluções IGA.
Federação de identidade
Com a federação de identidade, um único sistema denominado Provedor de Identidade confiável (“IdP”) rege a autenticação dos usuários. Ela usa aplicativos em nuvem retransmitindo o processo de autenticação para o provedor de identidade cada vez que um usuário tenta acessá-los.
Portanto, a identidade federada resolve os desafios e frustrações de gerenciamento de credenciais para vários aplicativos da web separadamente. Sejam eles internos ou externos a uma organização. Contudo, a federação de identidade depende de protocolos de federação como SAML e Open ID Connect. Isso, além de protocolos proprietários, como o WS-Federation da Microsoft.
Com a federação de identidade, um único sistema chamado de provedor de identidade confiável, governa a autenticação de usuários. Então, ele retransmite aos aplicativos em nuvem o processo de autenticação para a identidade cada vez que um usuário tenta acessá-los.
Login federado
O login federado é uma função de protocolos de federação, como SAML, Open ID Connect e outros. Eles usam um modelo de provedor de identidade para autenticar usuários e retransmitir essas informações de autenticação para o sistema de destino. Isso é feito na forma de uma “declaração de autenticação”. A afirmação contém um “Aceitar” ou “rejeitar” a resposta. Ou seja, traz um resultado negativo ou de concessão de acesso ao usuário.
Contudo, o login federado permite que os usuários façam login uma vez para obter acesso ao mesmo tempo a todos os seus aplicativos em nuvem. Portanto, não é necessário fazer login para separar aplicativos em nuvem usando diferentes conjuntos de nome de usuário e senha, ou “identidades”.
Então, o login federado permite que os usuários façam login no escritório 365, Salesforce, AWS etc. com a mesma identidade que usam para fazer login na rede corporativa pela manhã ou VPN à noite.
Provedor de identidade
SAML, tal como outros protocolos de federação de identidade que permitem segurança na troca de dados de identidade entre sites não afiliados, são baseados em um provedor de identidade (IdP) e modelo de provedor de serviços.
Portanto, quando um usuário acessa um provedor de serviços (serviço baseado em nuvem), eles são redirecionados ao provedor de identidade confiável para autenticação e / ou autorização de dados. Então, o provedor de identidade verifica os dados de autenticação do usuário e produz uma “aceitação” ou “rejeição”. A resposta é, então, enviada ao Provedor de Serviços. Os dados de autenticação do usuário podem incluir:
- Cookie;
- Dispositivo;
- Rede;
- OTP do usuário.
Dados de autorização podem incluir a permissão para acessar informações como e-mail, endereços de uma conta de webmail ou nomes de amigos de uma rede social.
Por exemplo, o SafeNet Trusted Access atua como um provedor de identidade. Isso ocorre quando os usuários acessam os aplicativos em nuvem como no cenário descrito acima.
Serviços de token de segurança
Modelos de provedor de identidade também são chamados de autenticação baseada em token ou Serviços de token de segurança. Um serviço de token de segurança (STS), é equivalente a um provedor de identidade. Contudo, uma parte de confiança (RP) é equivalente a um serviço Fornecedor. Afinal, ao invés de trocar asserções SAML, eles são chamados de Tokens de segurança. Ou seja, nomes diferentes, mesmo conceito.
SAML
SAML, pronuncia-se ‘sammel’ e significa Security Assertion Markup Language. Trata-se de um padrão aberto baseado em XML para troca de dados de autenticação entre sites não afiliados. Ou seja, é um recurso também conhecido como federação de identidade ou autenticação federada.
Federação de identidade significa a capacidade de estender as identidades corporativas atuais dos usuários para a nuvem. Dessa forma, permite que eles façam login em seus aplicativos de nuvem com sua identidade corporativa.
Já a autenticação federada para aplicativos em nuvem com SAML permite que os usuários façam login em todos os seus aplicativos em nuvem com sua identidade corporativa. Então, ao invés de manter 5 ou 25 conjuntos de nome de usuário e senha, eles podem manter apenas um.
Como funciona o SAML?
Quando um usuário tenta fazer login em um aplicativo baseado em nuvem, ele é redirecionado a um provedor de identidade confiável para autenticação. Então, o provedor coleta as credenciais do usuário. Por exemplo, seu nome de usuário e senha de uso único. Depois, ele retorna uma resposta ao aplicativo em nuvem sendo acessado.
Essa resposta é chamada de asserção SAML. A asserção SAML contém uma resposta de aceitação ou rejeição. Com base nesta resposta, o provedor de serviços, por exemplo Salesforce, Office 365 ou DropBox, bloqueia ou concede acesso ao aplicativo.
WS-Fed
O WS-Federation Services, ou WS-Fed, é o protocolo de federação de identidade. WS-Fed de propriedade da Microsoft. Ele trabalha com o Active Directory Federation Services, ou AD FS. Seu intuito é estender identidades armazenadas no Active Directory para aplicativos da nuvem da Microsoft. É o caso do Office 365 e Azure, por exemplo.
Contudo, como o SAML, o WS-Fed usa um modelo de provedor de identidade. Portanto, ao acessar um aplicativo de nuvem da Microsoft, o usuário é redirecionado para autenticação para AD FS. E isso é feito com base na resposta que o aplicativo da nuvem concede ou nega o acesso do usuário.
OAuth
OAuth, pronunciado “oh-auth”, significa Autorização Aberta. Trata-se de um padrão aberto para autenticação federada ou “baseada em token”. Contudo, inclui autorização entre sites não afiliados. Tal como acontece com outra federação de identidade protocolos, o OAuth permite o login em um aplicativo com uma identidade verificada por um provedor de identidade confiável.
Entretanto, ele vai além da autenticação federada para permitir que os usuários autorizem sites de terceiros a acessar certas contas e informações. É o caso de nomes de contato e endereços de e-mail.
Ou seja, o OAuth é o protocolo usado por sites de redes sociais para acessar seus contatos de webmail. Aquele mesmo que pergunta se você gostaria de convidar seus contatos de webmail para suas redes sociais.
Open ID Connect
Como o SAML, o OpenID Connect é um protocolo de federação de identidade de padrão aberto que usa um modelo de provedor de identidade. No entanto, o SAML funciona usando um cookie e, portanto. Ou seja, só funciona com aplicativos que abrem em um navegador (“aplicativos baseados em navegador”).
Por outro lado, o OpenID Connect fornece uma estrutura de logon único que permite a implementação de logon único em aplicativos baseados em navegador, aplicativos móveis nativos e clientes de desktop (inclusive alguns VPNs).
A maioria das implementações de logon único atuais suportam apenas nuvem e apps baseados em navegador. Contudo, à medida que mais provedores de identidade adotam o OpenID Connect, seremos capazes de autenticar apenas uma vez, a fim de obter simultaneamente acesso a todos os nossos recursos. Sejam eles clientes de desktop, aplicativos baseados em navegador ou aplicativos móveis nativos.
Traga sua própria identidade (BYOI)
Para que serve um espaço de gerenciamento de identidade? Simples. Para fornecedores e organizações permitirem que funcionários e parceiros usem sua própria identidade para acessar recursos corporativos.
Essa identidade poderia teoricamente ser qualquer identidade. Contanto que forneça um nível suficiente de garantia de identidade, é claro. É o caso de cartões de identidade emitidos pelo governo, cartões inteligentes de saúde, bem como identidades online, sociais, de rede profissional e aquelas disponíveis comercialmente, como FIDO.
Afinal, os mundos empresarial e de consumo estão se fundindo cada vez mais. Portanto, equipes de segurança empresarial estão sendo cada vez mais pressionadas para implementar o mesmo tipo de métodos de autenticação normalmente vistos em serviços ao consumidor.
Single Sign-On (SSO)
O logon único (SSO) fornece a capacidade de autenticar uma vez e ser subsequentemente e automaticamente autenticado a acessar vários recursos. Ou seja, ele elimina a necessidade de fazer login separadamente e autenticar em aplicativos e sistemas individuais. Portanto, serve essencialmente como um intermediário entre o usuário e os aplicativos de destino.
Contudo, nos bastidores, os aplicativos e sistemas de destino ainda mantêm seus próprios armazenamentos de credenciais. Ou seja, apresentam prompts de logon para o sistema do usuário. Então, o SSO responde a esses prompts e mapeia as credenciais para um único par de login / senha.
O SSO, seja em uma solução autônoma ou em uma solução de gerenciamento de acesso (Access Management) mais ampla, pode ser obtido por meio de uma variedade de protocolos de federação de identidade. Isso inclui protocolos de código aberto, como SAML 2.0 e Open ID Connect. Contudo, também abrenge protocolos proprietários, como WSFederation da Microsoft, e outras tecnologias, como proteção de senha e proxies reversos.
Senha do cofre (Password Vault)
As senhas do cofre, também chamados de gerenciadores de senhas, são uma maneira simples de criar uma experiência de logon único (SSO). Especialmente quando um aplicativo de destino não oferece suporte a protocolos de federação de identidade. Por exemplo, em um aplicativo legado ou personalizado. As senhas do cofre são sistemas que funcionam armazenando e criptografando as senhas de diferentes sites. Então, ao invés de fazer login em cada aplicativo com uma senha dedicada, o usuário pode simplesmente autenticar com uma senha mestra. Esta, por sua vez, descriptografa o cofre de senha. Assim, elimina-se a necessidade de manter senhas diferentes.
Autorização
A autorização é um processo que garante que usuários devidamente autenticados possam acessar apenas os recursos aos quais têm permissão de acesso. É o caso de acesso definido pelo proprietário ou administrador do recurso. Contudo, no mundo do consumidor, a autorização também pode se referir ao processo pelo qual um usuário garante que um aplicativo baseado em nuvem acesse apenas certas informações de um site não afiliado. É o caso de uma rede social acessando a conta de webmail do usuário, por exemplo.
Autenticação
A autenticação é um processo no qual a identidade de um usuário é validada ou verificada com base nas credenciais que ele fornece ao fazer login em:
- Um aplicativo;
- Serviço;
- Computador;
- Ambiente digital.
Portanto, a maioria das credenciais de autenticação consiste em algo que o usuário possui. Por exemplo, um nome de usuário e algo que ele conhece, como uma senha. Então, se as credenciais fornecidas pelo usuário corresponderem àquelas armazenadas pelo aplicativo ou provedor de identidade, o usuário é autenticado com êxito e recebe acesso.
Autenticação baseada em contexto
A autenticação baseada em contexto também verifica a identidade dos usuários. Contudo, o faz avaliando uma gama de informações complementares no momento em que uma pessoa faz login em uma aplicação. O tipo mais comum de informação contextual inclui:
- A localização do usuário;
- Hora do dia;
- Endereço IP;
- Tipo de dispositivo;
- URL;
- Reputação do aplicativo.
A autenticação baseada em contexto pode ser chamada também de autenticação baseada em risco ou adaptativa. Portanto, para o mundo do SSO e do gerenciamento de acesso (Access Management), ela é fundamental. Afinal, seu objetivo é tornar a jornada de autenticação o mais transparente e indolor possível.
Os atributos de login de um usuário podem ser contextuais ou de comportamento.
Contextuais
|
Comportamentais
|
Desta forma, a autenticação é aplicada da maneira mais simples possível de acordo com a política de acesso de um aplicativo. Ou seja, não depende de uma regra geral e uniforme para todos os recursos da empresa.
Autenticação contínua
Com um token, uma senha ou uma impressão digital a autenticação é basicamente uma decisão sim / não. Ou seja, para permitir ou negar acesso, o sistema valida a identidade do usuário.
Contudo, graças às tecnologias mais recentes, como autenticação baseada em contexto ou biometria comportamental, a autenticação pode se tornar um processo mais contínuo. Afinal, é possível verificar continuamente a identidade de uma pessoa cada vez que ela fizer login
uma aplicação. Na verdade, pode fazer isso mesmo sem o usuário estar sabendo. Basta avaliar uma gama de atributos, como:
- Endereço IP;
- Parâmetros móveis conhecidos;
- Dispositivo;
- Sistema operacional etc.
Ainda assim, a autenticação contextual oferece muitas maneiras fáceis de verificar a identidade de uma pessoa. E isso é o que realmente permite equilibrar a conveniência do usuário com a capacidade de aplicar controles de acesso para vários aplicativos em nuvem. Portanto, o conceito de autenticação contínua é a base do gerenciamento de acesso da nuvem. Ou seja, utiliza a autenticação baseada em contexto.
