Gerenciamento de identidade e acesso para cargas de trabalho SaaS no Azure
A identidade do aplicativo é uma área crítica para cargas de trabalho SaaS porque serve como a primeira linha de defesa para proteger dados. Muitas vezes é negligenciado até o final de um projeto, mas muitas decisões sobre outros elementos do aplicativo dependem de uma estratégia de identidade sólida. Não subestime a importância da identidade para ajudar a proteger os dados dos seus clientes.
No contexto de cargas de trabalho SaaS, existem dois tipos distintos de identidade.
A identidade do aplicativo, também conhecida como CIAM (Customer Identity and Access Management, gerenciamento de acesso e identidade do cliente), permite que os usuários finais autentiquem e usem seu aplicativo SaaS. Há dois métodos principais para conectar usuários a um provedor de identidade de aplicativo:
Identidades federadas. Os usuários entram com credenciais existentes que são mantidas por outro provedor de identidade. Esse provedor pode ser um provedor de identidade social, como Google, Facebook ou LinkedIn, ou um provedor de identidade corporativa que seus clientes usam, como Microsoft Entra ou Okta. A manutenção da conta do usuário é de responsabilidade do provedor de identidade federada.
Identidades locais. Os usuários criam uma conta apenas para o seu aplicativo. A conta é protegida por nome de utilizador e palavra-passe, chave de acesso ou outros métodos de autenticação. A manutenção da conta do utilizador é da sua responsabilidade.
A identidade corporativa é a solução de identidade usada para autenticar usuários internos e cargas de trabalho em ferramentas de produtividade corporativa, ferramentas ou serviços internos e serviços do Azure. Você usa uma solução de identidade corporativa para seus usuários internos e cargas de trabalho para autenticá-los em ferramentas de produtividade corporativa, ferramentas ou serviços internos e serviços do Azure.
Consulte SE :05 Gerenciamento de identidade e acesso.
As identidades de aplicativos e corporativas servem a finalidades diferentes e podem usar provedores de identidade diferentes. Este artigo se concentra em considerações de design para a identidade do aplicativo, embora ambos os tipos provavelmente estejam presentes em seu ambiente de carga de trabalho SaaS.
O gerenciamento de identidades envolve duas preocupações relacionadas: autenticação (verificação da identidade de um usuário) e autorização (concessão de permissões com base na identidade). As três primeiras seções deste artigo se concentram na autenticação para SaaS. A seção final aborda considerações de autorização para provedores de SaaS.
Identidade em um aplicativo multilocatário
Manter os dados do locatário separados em um aplicativo multilocatário é fundamental. Essa segmentação é impulsionada pela sua escolha de autenticação e autorização de usuário efetivas. Além disso, a escolha do modelo de locação influencia significativamente suas decisões sobre o provedor de identidade. Priorize a identidade como seu perímetro principal.
Consulte SE :04 Recomendações para segmentação.
Considerações de design
Entenda os modelos de locação e implantação para seu aplicativo. Pode haver nuances que influenciam sua estratégia de identidade. Por exemplo, é um equívoco que o padrão Deployment Stamps exija um provedor de identidade em cada carimbo. Para a maioria dos provedores de identidade, muitas vezes você pode usar um modelo de isolamento alternativo.
Ao escolher seu provedor de identidade para multilocação, avalie o impacto das falhas. Erros de configuração podem potencialmente derrubar todo o seu aplicativo para todos os locatários. Ponderar os custos gerais em relação ao risco do potencial raio de impacto.
Se você implantar sua solução no ambiente do Azure de um cliente e gerenciá-la em seu nome, talvez seja necessário integrá-la ao provedor de identidade corporativa dele. Ter uma compreensão clara destes aspetos:
- Os tipos de usuários e suas necessidades de acesso quando interagem com os locatários do aplicativo. Por exemplo, o usuário A pode precisar apenas de acesso para entrar no locatário 1, mas o usuário B pode precisar de acesso para entrar no locatário 1 e no locatário 2.
- Conformidade com os regulamentos de residência de dados, se forem aplicáveis ao seu provedor de identidade. Em alguns casos, os dados armazenados por um provedor de identidade podem estar sujeitos a regulamentações. Muitos provedores de identidade fornecem orientação e recursos específicos para esse cenário. Avalie se esse cenário é relevante para você e tome as medidas necessárias para garantir a conformidade.
Recomendações de design
| Recomendação | Benefício |
|---|---|
| Siga as práticas recomendadas e as diretrizes do seu provedor de identidade para particionar a solução para vários locatários. | O isolamento do inquilino ajuda-o a atingir os seus objetivos de segurança e conformidade. |
| Evite ter várias contas para o mesmo usuário. Um usuário deve ter uma única conta com um conjunto de credenciais, mesmo que precise de acesso a vários locatários. Conceda acesso a cada locatário conforme necessário, em vez de criar várias contas para o mesmo usuário. | Criar várias contas para o mesmo usuário aumenta os riscos de segurança e pode confundir os usuários que precisam se lembrar de vários nomes de usuário e senhas para o mesmo software. |
| Ao considerar a residência de dados, planeje como armazenar dados do usuário em locais separados. Se você implantar um carimbo de implantação separado para seus usuários em outras geografias, também poderá precisar de provedores de identidade separados. Verifique se você tem uma maneira de identificar onde os dados dos usuários estão armazenados para que você possa direcioná-los para a região correta para entrar, se necessário. |
Poderá suportar os seus requisitos de conformidade e melhorar a experiência do utilizador encaminhando os utilizadores para a experiência de início de sessão adequada à sua localização. |
Seleção do provedor de identidade
Cada provedor de identidade oferece recursos exclusivos, limitações, modelos de preços e padrões de implementação. Microsoft Entra e Okta são opções populares de identidade como serviço (IDaaS). Existem também outros provedores de código aberto, como Keycloak e Authentik.
Considerações de design
Documente os seus requisitos de identidade. Comece listando os recursos que seu aplicativo precisa agora e precisará no futuro. As características típicas a considerar incluem:
-
- Suporte ao provedor de identidade federada para integração com as soluções de identidade dos clientes. Esse recurso permite que você evite a criação de novas identidades.
- Fluxo de entrada/inscrição personalizável para modificar a aparência e manter sua marca. Esse recurso também fornece a capacidade de injetar lógica de negócios personalizada no processo de entrada/inscrição.
- Separação dos dados do locatário em silos distintos para manter o isolamento do locatário.
- Suporte de auditoria para reter ou exportar logs de entrada para gerenciamento de segurança.
Importante
Considere o crescimento de usuários planejado ao avaliar o custo de uma solução de identidade. Uma solução pode não ser rentável ou escalável a longo prazo, mas pode ser útil por enquanto. Tenha um plano de migração que você possa usar se necessário.
Por exemplo, uma solução pode ser acessível para 500 utilizadores, mas insustentável para 5 milhões. Se ele requer uma configuração mínima e é fácil de usar e migrar, ainda pode ser a escolha certa até que os custos de dimensionamento justifiquem a mudança para uma solução diferente.
Pesquise minuciosamente os recursos do provedor de identidade. Verifique se a solução de identidade corresponde à sua lista de recursos necessários. Mesmo que você não precise atualmente de cenários complexos, como identidade federada, considere as necessidades futuras. Para soluções SaaS business-to-business (B2B), a identidade federada provavelmente será necessária eventualmente.
Fator nas despesas gerais de gestão. Diferentes provedores de identidade exigem diferentes níveis de despesas gerais de gerenciamento. Soluções IDaaS bem conhecidas geralmente têm menos sobrecarga porque lidam com hospedagem, manutenção e segurança. No entanto, a sobrecarga adicional de uma solução de código aberto pode valer a pena se a solução for mais adequada às suas necessidades especializadas.
Recomendações de design
| Recomendação | Benefício |
|---|---|
| Não crie sua própria solução de identidade. A identidade é uma área altamente especializada, e criar uma solução de identidade é complexo e caro. É difícil criar uma solução de identidade que seja segura e confiável. | Você evitará o antipadrão de criar seu próprio provedor e aumentará a segurança, a confiabilidade e a eficiência operacional de sua solução. |
| Crie uma matriz de recursos dos recursos oferecidos pelos provedores de identidade e mapeie-a em relação aos seus requisitos de identidade. | Você garantirá sua capacidade de evoluir sem ser limitado por um conjunto limitado de recursos de identidade. |
| Prefira opções de IDaaS em vez de soluções de código aberto. Hospedar uma solução de código aberto incorre em despesas operacionais e riscos de segurança significativos. No entanto, você pode escolher essa opção para atender a requisitos específicos de conformidade, residência de dados ou confiabilidade que um provedor não pode cumprir. Para obter mais informações, consulte Provedores de identidade IDaaS. |
Ao usar um provedor de identidade IDaaS, você evitará complexidade desnecessária e poderá concentrar seus esforços em seu negócio principal. |
Identidade federada
A identidade federada, também conhecida como logon único (SSO), permite que os usuários entrem com credenciais que já usam em outro lugar. Você habilita a identidade federada estabelecendo uma relação de confiança entre o provedor de identidade do aplicativo e o provedor de identidade existente do cliente. A identidade federada é um requisito comum para soluções SaaS, especialmente em B2B, porque os clientes preferem que seus funcionários usem credenciais corporativas. Ele oferece vários benefícios para soluções B2B, como gerenciamento centralizado de identidades e gerenciamento automático do ciclo de vida. Em produtos SaaS B2C, a integração com provedores de identidade social é comum para permitir que os usuários entrem com credenciais existentes.
Tradeoff: Complexidade e eficiência operacional. Ao trabalhar com provedores de identidade federada, você descarrega a complexidade do gerenciamento das identidades dos usuários. No entanto, você assume o custo da integração com outro provedor de identidade. Decida onde quer concentrar os seus esforços operacionais.
Embora a implementação da identidade federada seja inicialmente simples, ela se torna mais complexa à medida que o número de provedores de identidade suportados aumenta. Um planejamento cuidadoso é essencial, especialmente se cada cliente usa um provedor de identidade exclusivo. Mesmo que eles usem o mesmo provedor de identidade, relações de confiança exclusivas geralmente são necessárias para cada cliente devido a detalhes de configuração específicos.
Esta imagem mostra a relação entre seu aplicativo, seu provedor de identidade de aplicativo e os provedores de identidade downstream que você pode optar por implementar usando a federação de identidades.
Considerações de design
Estime os tipos e o número de provedores de identidade aos quais você precisa dar suporte. Você pode precisar de um número estático de provedores de identidade social ou pode precisar de provedores de identidade federada exclusivos para cada cliente. Você deve saber se seus clientes usarão OpenID Connect (OIDC), Security Assertion Markup Language (SAML) ou ambos para integração.
Mapeie a experiência de início de sessão. Visualize o fluxo do usuário do processo de inscrição e login. Observe quaisquer requisitos especiais que possam alterar seu design de fluxo de usuário. Por exemplo:
Branding personalizado. White labeling ou domínios de entrada personalizados por cliente.
Informações personalizadas. Recolha de informações adicionais do utilizador durante a inscrição ou início de sessão, tais como a seleção de inquilinos para utilizadores com acesso a vários inquilinos.
Seleção do provedor de identidade. Se você usar um único provedor de identidade de aplicativo que tenha muitos provedores de identidade federada confiando nele, decida como selecionar um provedor. Esta seleção pode ser feita manualmente através de um botão ou automaticamente com base em informações conhecidas do utilizador. À medida que o número de prestadores aumenta, a seleção automática torna-se mais prática. Esse recurso é conhecido como Home Realm Discovery.
Recomendações de design
| Recomendação | Benefício |
|---|---|
| Escolha um provedor de identidade que possa ser dimensionado para acomodar o número de provedores de identidade federada de que você precisa. Esteja ciente dos limites rígidos do provedor, que não podem ser excedidos. |
Você garantirá que sua solução de identidade possa ser dimensionada à medida que você cresce. |
| Planeje a integração de cada provedor de identidade federada e automatize o processo o máximo possível. Esse esforço colaborativo entre sua organização e seus clientes envolve a troca de informações para estabelecer uma relação de confiança, geralmente por meio de protocolos OIDC ou SAML. |
A integração de identidade pode levar tempo e esforço para você e seus clientes. Ao planejar o processo, você melhorará sua eficiência operacional. |
| Reflita a complexidade e o custo da identidade federada em seus preços e modelo de negócios. Permitir que os clientes usem seu próprio provedor de identidade aumenta a complexidade operacional e os custos devido à sobrecarga de manter várias relações de confiança de identidade federada. É comum em soluções SaaS que as empresas paguem por uma camada mais alta que permite o login federado. |
A federação com o provedor de identidade de um cliente pode ser um custo oculto em soluções SaaS. Ao planejá-lo, você evitará custos inesperados durante a implementação. |
| Planeje como o provedor de identidade de um usuário será selecionado durante o fluxo de entrada. Considere o uso do Home Realm Discovery. O Microsoft Entra ID fornece o Home Realm Discovery integrado. |
Você simplificará a experiência do cliente e garantirá que os usuários sejam direcionados para o processo de login correto. |
Autorização
A autorização do usuário é crucial para aplicativos SaaS, que geralmente armazenam dados para vários locatários. Defina claramente como os usuários serão autorizados a acessar apenas seus dados sem acessar inadvertidamente os dados de outros locatários. Além disso, forneça autorização granular dentro de um locatário, permitindo que os usuários leiam ou acessem determinadas informações enquanto restringem atualizações ou acesso a outros dados.
Considerações de design
Escolha o modelo de autorização certo para o caso de uso. Existem dois tipos principais:
- Autorização baseada em funções. Os usuários recebem funções ou grupos, e recursos específicos são restritos a determinadas funções. Por exemplo, os administradores podem executar qualquer ação, mas os usuários em outras funções têm permissões limitadas.
- Autorização baseada em recursos. Cada recurso tem seu próprio conjunto de permissões. Um usuário pode ser um administrador de um recurso, mas não tem acesso a outro.
Decida onde armazenar os dados de autorização. Os dados de autorização para o seu pedido podem ser armazenados em:
- Seu provedor de identidade. Aproveite os grupos ou funções internos, exibindo permissões como declarações no token emitido para seu aplicativo. Seu aplicativo pode então impor regras de autorização usando essas declarações de token.
- A sua candidatura. Desenvolva sua própria lógica de autorização e armazene as permissões do usuário em um banco de dados ou sistema semelhante, permitindo controles de autorização refinados baseados em função ou no nível de recursos.
Compensação: Complexidade, flexibilidade e segurança. Armazenar dados de autorização em um provedor de identidade e surgir por meio de declarações de token geralmente é mais simples do que gerenciar seu próprio sistema de autorização. No entanto, a autorização baseada em declarações limita sua flexibilidade e você precisa aceitar que as declarações só são atualizadas quando um token é reemitido, o que pode causar um atraso na aplicação de permissões alteradas.Avaliar o impacto da gestão delegada. Na maioria dos aplicativos SaaS, especialmente em aplicativos B2B, o gerenciamento de funções e permissões é delegado aos clientes. Sem essa funcionalidade, você pode aumentar sua sobrecarga de gerenciamento se os clientes alterarem frequentemente as permissões de seus usuários.
Avalie o acesso multilocatário. Em alguns sistemas, um único usuário pode precisar acessar dados de vários locatários. Por exemplo, os consultores podem precisar acessar dados de vários locatários. Planeje como os clientes concederão acesso a esses usuários e como seu fluxo de entrada dará suporte à seleção e à alternância entre locatários.
Recomendações de design
| Recomendação | Benefício |
|---|---|
| Impedir que os usuários acessem dados entre os limites do locatário, a menos que esse acesso seja explicitamente permitido. | O acesso não autorizado aos dados de outro inquilino, mesmo o acesso acidental, pode ser visto como um grande incidente de segurança e minar a confiança do cliente na sua plataforma. Bloquear o acesso desnecessário irá ajudá-lo a evitar estas situações. |
| Se os dados forem estáticos e forem alterados com pouca frequência, armazene-os no provedor de identidade. Se forem necessárias alterações frequentes enquanto o usuário estiver usando o software, armazene os dados de autorização em seu aplicativo. | Selecionar o melhor armazenamento de dados para seus dados de autorização aumentará sua eficiência operacional e ajudará você a atender às suas necessidades de escalabilidade. |
| Se você delegar o gerenciamento de permissões aos clientes, forneça um método claro para que eles gerenciem as permissões. Por exemplo, crie um portal da Web acessível apenas a administradores de locatários para alterar as permissões do usuário. | Você fornecerá mais controle aos seus clientes e evitará encargos operacionais desnecessários para sua equipe de suporte. |
Recursos adicionais
A multilocação é uma metodologia de negócios central para projetar cargas de trabalho SaaS. Estes artigos fornecem mais informações sobre gerenciamento de identidade e acesso:
- Considerações arquitetônicas para identidade em soluções multilocatárias
- Abordagens arquitetônicas para identidade em soluções multilocatárias
Próximo passo
Saiba mais sobre como escolher seu modelo de hospedagem de computação, os aspetos operacionais e como otimizar as opções de tecnologia para ajudá-lo a cumprir seus contratos e objetivos de nível de serviço.