Perguntas Frequentes sobre Gerenciamento de Acesso

O Gerenciamento de Identidade e Acesso (IAM) é uma sub-disciplina de segurança de dados que compreende dois conjuntos de funcionalidades: Governança e Administração da Identidade (IGA) e Gestão de Acesso (AM).

O IAM fornece uma estrutura metódica para conceder (e solicitar) acesso a aplicativos (IGA), fazendo cumprir os controles de acesso (AM) e garantindo a visibilidade dos casos de acesso (AM).

As soluções de IGA ajudam a responder às perguntas: "Quem deve receber acesso, ou quem tem "direito a acesso" a um aplicativo?" e "A quem, na prática, foi concedido acesso a que aplicativo, por quem e quando". As soluções AM ajudam a responder às perguntas: "Quem acessou o quê e quando, e como sua identidade foi verificada?".

Uma solução de Gerenciamento de Identidade e Acesso (IAM) é composta pela funcionalidade de Governança e Administração de Identidade (IGA) e pela funcionalidade de Gerenciamento de Acesso (AM). As soluções de IAM fornecem uma estrutura metódica para conceder (e solicitar) acesso a aplicativos (IGA), fazendo cumprir os controles de acesso (AM) e garantindo a visibilidade dos casos de acesso (AM). Uma vez que a maioria das empresas implantam os componentes IGA e AM separados um do outro, estas disciplinas estão sendo cada vez mais avaliadas como famílias de soluções autônomas e distintas, em vez de como funcionalidades compostas de um único conjunto de IAM.

O gerenciamento de acesso é uma funcionalidade que permite determinar se um usuário tem permissão para acessar um determinado recurso, e permite a aplicação da política de acesso que foi estabelecida para esse recurso.

O gerenciamento de acesso é implementado com base nas políticas de acesso definidas pelos administradores de TI e inclui informações como quais grupos de usuários (por exemplo, Vendas, P&D, RH) têm permissão de acesso a quais aplicativos em nuvem (por exemplo, Salesforce, Office 365, Jira, Taleo), bem como o conjunto de atributos de usuário necessários para acessar cada aplicativo (por exemplo, rede confiável, senha, OTP).

A política de acesso pode exigir que mais ou menos atributos do usuário sejam avaliados, dependendo da sensibilidade de um aplicativo em nuvem. Estes atributos são avaliados utilizando autenticação baseada em risco ou em contexto, o que é central para fazer cumprir as diferentes políticas de acesso definidas para cada aplicativo em nuvem. (Para mais detalhes, veja autenticação baseada em contexto.)

Também é central para o gerenciamento de acesso à nuvem o login único, o que permite o uso de um único conjunto de nome de usuário e senha ou "identidade" para fazer login em todos os aplicativos em nuvem. (Para mais detalhes, veja login único.)

IDaaS é IAM como serviço, e também é chamada de identidade como serviço. A infraestrutura IDaaS descreve as soluções de gerenciamento de identidade e acesso (IAM) que oferecem um modelo de prestação de serviços baseado em nuvem para o gerenciamento de identidade e acesso. Embora a IDaaS tenha sido revista como um mercado separado nos últimos anos, dadas as tendências recentes do mercado, no futuro será tratada como duas disciplinas separadas - a de gerenciamento de acesso e de IGA, cujos métodos de entrega incluem instalações no local, software ou plataformas baseadas em nuvem.

Governança e administração de identidade (IGA) é um conjunto de funcionalidades que ajudam a responder às perguntas: "Quem deve receber acesso, ou quem tem "direito a acesso" a um aplicativo?" e "A quem, na prática, foi concedido acesso a que aplicativo, por quem e quando". Por exemplo, uma solução IGA pode ajudar a estabelecer que o pessoal de P&D tenha acesso a certos aplicativos de desenvolvimento, como GitHub, Jira e Confluence. Uma solução IGA pode fornecer automaticamente acesso a esses aplicativos se a pessoa pertencer ao grupo de P&D. O usuário de P&D também pode solicitar o acesso provisionado a outros aplicativos, uma solicitação que passa por um processo de aprovação da gerência que é suportado por algumas soluções IGA.

A federação de identidade é uma arquitetura baseada em um único provedor de identidade confiável ("IdP") que controla a autenticação dos usuários, com aplicativos transmitindo o processo de autenticação para o provedor de identidade cada vez que um usuário tenta acessá-los. Os aplicativos que retransmitem o processo de autenticação para o provedor de identidade confiável são chamados de provedores de serviços ("SPs").

A federação de identidade resolve os desafios e frustrações de gerenciar as credenciais de numerosos aplicativos de web separadamente, sejam internos ou externos a uma empresa, e permite que administradores e usuários mantenham um único conjunto de nome de usuário e senha (ou "identidade") para múltiplos aplicativos e recursos de TI. A federação de identidade elimina a fadiga da senha, melhora a segurança e resolve o problema de lidar com inúmeras redefinições de senhas.

A federação de identidade conta com protocolos de federação como SAML e Open ID Connect, assim como protocolos proprietários como o WS-Federation da Microsoft.

O login federado é uma função dos protocolos de federação (por exemplo, SAML, Open ID Connect etc.) que permite que os usuários façam login em múltiplos aplicativos usando sua identidade empresarial atual. Por exemplo, em vez de efetuar login separadamente em aplicativos em nuvem usando diferentes conjuntos de nome de usuário e senha, ou "identidades", o login federado permite aos usuários efetuar login no Office 365, Salesforce, AWS etc. com a mesma identidade que eles usam para efetuar login na rede corporativa pela manhã, ou na VPN à noite.

Um provedor de identidade é um sistema que autentica usuários que estão tentando acessar outros sites não afiliados ("provedores de serviços"). Os provedores de identidade, juntamente com os provedores de serviços, compreendem uma arquitetura de federação de identidade, na qual os usuários que tentam acessar um site (ou provedor de serviços), são retransmitidos para o provedor de identidade para autenticação. O provedor de identidade verifica os dados de autenticação do usuário (por exemplo, cookies do usuário, dispositivo, rede, OTP) e produz uma resposta de "aceitar" ou "rejeitar" que é então enviada ao provedor de serviço. Os provedores de identidade também podem solicitar autorização para acessar certos dados em nome de outro site não afiliado. Os dados de autorização podem incluir a permissão de acesso a informações como e-mail de uma conta de webmail ou nomes de amigos de uma conta de rede social.

Por exemplo, o SafeNet Authentication Service funciona como um provedor de identidade quando os usuários acessam aplicativos em nuvem, como no cenário descrito acima.

Um serviço de token de segurança é um sistema que autentica usuários que estão tentando acessar outros sites não afiliados ("provedor de confiança"). Os serviços de token de segurança, juntamente com terceiros de confiança, compreendem uma arquitetura de serviço de segurança de token na qual os usuários que tentam acessar um site (provedor de confiança), são retransmitidos para o serviço de segurança de token para autenticação.

Os serviços de token de segurança também são chamados de modelos de provedor de identidade ou autenticação baseada em token. Um serviço de token de segurança (STS) é equivalente a um provedor de identidade, e um provedor de confiança (RP) é equivalente a um provedor de serviços. E ao invés de enviar confirmações SAML, estes são chamados de tokens de segurança. Nomes diferentes, mas o mesmo conceito.

Linguagem de confirmação para autorização de segurança, ou SAML (pronuncia-se "sammel"), é um padrão aberto baseado em XML para troca de dados de autenticação entre sites não afiliados, uma capacidade que também é chamada de federação de identidade ou autenticação federada.

A federação de identidade significa a capacidade de estender as identidades empresariais atuais dos usuários para a nuvem, permitindo que eles façam login em seus aplicativos em nuvem com sua identidade empresarial atual. A autenticação federada para aplicativos em nuvem com SAML permite que os usuários acessem todos os seus aplicativos em nuvem com sua identidade empresarial atual, de modo que, ao invés de manter 5 ou 25 conjuntos de nomes de usuários e senhas, eles podem manter apenas um.

Como o padrão SAML funciona
Quando um usuário tenta entrar em um aplicativo baseado em nuvem, ele é redirecionado para um provedor de identidade confiável para autenticação. O provedor de identidade coleta as credenciais do usuário, por exemplo, seu nome de usuário e senha descartável, e envia uma resposta para o aplicativo em nuvem que está sendo acessado. Esta resposta é chamada de confirmação SAML, e ela 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 pedido.

WS-Federation Services, ou WS-Fed, é o protocolo de identidade proprietário da Microsoft. O WS-Fed trabalha com o Microsoft Active Directory Federation Services, ou AD FS, para estender as identidades armazenadas no Active Directory para aplicativos em nuvem da Microsoft, como o Office 365 e o Azure. Como a SAML, os usuários do WS-Fed utilizam um modelo de Provedor de Identidade. Ao acessar uma aplicativo em nuvem da Microsoft, o usuário é redirecionado para autenticação no AD FS, com base em cuja resposta o aplicativo em nuvem concede ou nega o acesso do usuário.

OAuth (pronuncia-se "oh-auth"), abreviação de Autorização Aberta, é um padrão aberto para autenticação e autorização federada, ou "baseada em tokens", entre sites não afiliados. Como com outros protocolos de federação de identidade, como SAML, Open ID Connect e WS-Fed, o OAuth permite o login em um aplicativo com uma identidade que é verificada por um provedor de identidade confiável. A OAuth vai além da autenticação federada para permitir que os usuários autorizem os sites de terceiros a acessar certas informações de conta, como nomes de contato e e-mails. Por exemplo, OAuth é o protocolo utilizado pelos sites de redes sociais para acessar seus contatos de webmail e perguntar se você gostaria de convidar seus contatos de webmail para suas redes sociais.

O OpenID Connect, como o SAML, é um protocolo de federação de identidade de padrão aberto que usa um modelo de Provedor de Identidade. Entretanto, ao contrário do SAML, que funciona usando um cookie e, portanto, só funciona com aplicativos que abrem em um navegador ("aplicativos baseados em navegador"), o OpenID Connect fornece uma única sinal estrutura que permite a implementação de um único login para aplicativos baseados em navegador, aplicativos móveis nativos e clientes desktop (como rich clients e algumas VPNs). Assim, enquanto a maioria das implementações de login único de hoje suportam apenas aplicativos baseados em nuvem e navegador, com mais provedores de identidade adotando o OpenID Connect seremos capazes de autenticar apenas uma vez a fim de concomitantemente obter acesso a todos os nossos recursos - sejam eles clientes desktop, aplicativos baseados em navegador ou aplicativos móveis nativos.

Bring Your Own Identity, ou BYOI, é um termo usado para descrever a capacidade de uma empresa ou outra organização de aceitar uma identidade que tenha sido emitida em outro lugar, e permitir o acesso seguro a recursos usando essa identidade.

No espaço de gerenciamento de identidade, provedores e empresas estão procurando permitir que funcionários e parceiros usem sua própria identidade para acessar recursos corporativos. Esta identidade poderia teoricamente ser qualquer identidade que forneça um nível suficiente de garantia de identidade - por exemplo, carteiras de identidade emitidas pelo governo, cartões inteligentes de saúde, bem como identidades online, como identidades sociais, identidades de redes profissionais e identidades disponíveis comercialmente, como FIDO. Os universos empresarial e de consumo estão se unindo mais, com equipes de segurança empresarial sob crescente pressão para implementar o mesmo tipo de métodos de autenticação tipicamente vistos nos serviços ao consumidor.

Um Identity Broker é um sistema que suporta esquemas BYOI tomando a identidade existente de um usuário (ou qualquer número de identidades existentes), e permitindo que ele se autentique em sites não afiliados usando essa identidade. Por exemplo, um Identity Broker pode aceitar a identidade social ou identidade de webmail de um usuário e permitir que esse usuário acesse uma infinidade de sites não afiliados. Os Identity Brokers permitem que as empresas aceitem múltiplos provedores de identidade.

O login único (SSO) fornece a capacidade de autenticar uma vez, e ser subsequente e automaticamente autenticado ao acessar vários recursos. Ele elimina a necessidade de se logar e autenticar separadamente em aplicativos e sistemas individuais, servindo essencialmente como um intermediário entre o usuário e os aplicativos desejados. Internamente, os aplicativos e sistemas desejados ainda mantêm seus próprios armazenamentos de credenciais e apresentam avisos de login para o sistema do usuário. O SSO responde a essas solicitações e mapeia as credenciais para um único par de login/senha. (Fonte: Gartner)

O SSO, seja em uma solução autônoma ou em uma solução mais ampla de gerenciamento de acesso, pode ser obtido através de uma série de protocolos de federação de identidade. Estes incluem protocolos de código aberto como SAML 2.0 e Open ID Connect, protocolos proprietários como o WS-Federation da Microsoft, e outras tecnologias como vaulting de senhas e proxies reversos.

Um vault de senhas, também chamado de gerenciador de senhas, é uma maneira simples de criar uma experiência de login único (SSO) quando um determinado aplicativo não aceita protocolos de federação de identidade, por exemplo, um aplicativo já existente ou personalizado. Os vaults de senhas são sistemas que funcionam armazenando e criptografando as senhas de diferentes sites. Em vez de entrar em cada aplicativo com uma senha dedicada, o usuário pode simplesmente autenticar-se com uma senha-mestra (que por sua vez descriptografa o vault de senhas), eliminando a necessidade de manter senhas diferentes.

A autorização é um processo que garante que os usuários devidamente autenticados possam acessar apenas os recursos aos quais estão autorizados a acessar, conforme definido pelo proprietário ou administrador do recurso. No universo de consumo a autorização também pode se referir ao processo pelo qual um usuário garante que um aplicativo baseado em nuvem (por exemplo, uma rede social) acesse apenas certas informações de um site não afiliado (por exemplo, a conta de webmail do usuário).

A autenticação é um processo no qual a identidade de um usuário é validada ou verificada com base nas credenciais que o usuário fornece ao efetuar login em um aplicativo, serviço, computador ou ambiente digital. A maioria das credenciais de autenticação consiste em algo que o usuário tem, por exemplo, um nome de usuário, e algo que o usuário sabe, por exemplo, uma senha. Se as credenciais fornecidas pelo usuário corresponderem às que são armazenadas pelo aplicativo ou provedor de identidade subjacente, o usuário é autenticado com sucesso e o acesso é concedido.

A autenticação baseada em contexto é um método de autenticação baseado em uma gama de informações suplementares avaliadas no momento em que uma pessoa faz o login em um aplicativo. O tipo mais comum de informação contextual inclui a localização do usuário, hora do dia, IP, tipo de dispositivo, URL e reputação do aplicativo. A autenticação baseada em contexto, também chamada de autenticação baseada em risco ou adaptativa, é central para o mundo do SSO e do gerenciamento de acesso, onde o objetivo é tornar a jornada de autenticação o mais transparente e indolor possível.

Ao avaliar os atributos de login de um usuário, sejam eles contextuais (dispositivo, função, localização) ou baseados no comportamento (por exemplo, velocidade de digitação, sequência de visualização de página), as soluções de gerenciamento de acesso e de login único podem combinar continuamente o nível de autenticação exigido do usuário com a política de acesso definida para cada aplicativo. Desta forma, a autenticação é aplicada de forma granular - da maneira mais sem atritos possível - pela política de acesso de um aplicativo, em vez de como uma regra geral e uniforme para todos os recursos da empresa.

Autenticação contínua é uma forma de autenticação que ocorre continuamente, cada vez que um usuário acessa um novo aplicativo ou recurso, em contraste com a autenticação única ou binária, que fornece uma decisão única de sim/não que só é válida para um único login em um único aplicativo.

Com um token, uma senha ou uma impressão digital - a autenticação é basicamente uma decisão de sim/não: o sistema valida a identidade de um usuário e permite ou nega o acesso a um aplicativo.

Mas graças a novas tecnologias, como a autenticação baseada em contexto ou biometria comportamental (por exemplo, padrão de navegação, padrão de digitação e outras características físicas), a autenticação pode se tornar um processo mais contínuo. Ao avaliar uma gama de atributos como IP, parâmetros móveis, dispositivo conhecido, sistema operacional etc., a autenticação contextual ou baseada em risco pode verificar continuamente a identidade de uma pessoa cada vez que ela entra em um aplicativo. Na verdade, ela pode fazer isso sem que o usuário sequer saiba.

A autenticação contextual oferece muitas formas descomplicadas de verificar a identidade de uma pessoa. E isso é o que permite equilibrar a conveniência do usuário com a capacidade de aplicar controles de acesso granulares a vários aplicativos em nuvem. E é por isso que o conceito de autenticação contínua - que se baseia na autenticação baseada em contexto - é essencial para o gerenciamento do acesso à nuvem.