Gerenciamento de identidade e acesso para cargas de trabalho SaaS no Azure
A identidade do aplicativo é uma área crítica para cargas de trabalho de SaaS porque serve como a primeira linha de defesa para proteger os 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 de seus clientes.
No contexto de cargas de trabalho SaaS, há dois tipos distintos de identidade.
A identidade do aplicativo, também conhecida como gerenciamento de identidade e acesso do cliente (CIAM), 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 federado.
Identidades locais. Os usuários criam uma conta apenas para seu aplicativo. A conta é protegida por nome de usuário e senha, senha ou outros métodos de autenticação. A manutenção da conta do usuário é de sua responsabilidade.
A identidade corporativa é a solução de identidade usada para autenticar usuários internos e cargas de trabalho em ferramentas de produtividade de negócios, 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 de negócios, ferramentas ou serviços internos e serviços do Azure.
Consulte SE:05 Gerenciamento de identidade e acesso.
As identidades de aplicativo e corporativa servem a propósitos 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 por sua escolha de autenticação e autorização de usuário eficazes. 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 sobre o design
Entenda os modelos de locação e implantação do seu aplicativo. Pode haver nuances que influenciam sua estratégia de identidade. Por exemplo, é um equívoco pensar que o padrão Selos de Implantação exija um provedor de identidade em cada selo. Para a maioria dos provedores de identidade, você geralmente pode usar um modelo de isolamento alternativo.
Ao escolher seu provedor de identidade para multilocação, avalie o impacto das falhas. Configurações incorretas podem potencialmente derrubar todo o aplicativo para todos os locatários. Pese os custos indiretos em relação ao risco do raio potencial de impacto.
Se você implantar sua solução no ambiente do Azure de um cliente e gerenciá-la em nome dele, talvez seja necessário integrá-la ao provedor de identidade corporativa. Tenha uma compreensão clara destes aspectos:
- Os tipos de usuários e suas necessidades de acesso quando eles 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 eles forem aplicáveis ao seu provedor de identidade. Em alguns casos, os dados armazenados por um provedor de identidade podem estar sujeitos a regulamentos. Muitos provedores de identidade fornecem diretrizes 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 provedor de identidade para particionar a solução para vários locatários. | O isolamento de locatário ajuda você a atingir suas metas 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. | A criação de 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 os dados do usuário em locais separados. Se você implantar um selo de implantação separado para seus usuários em outras regiões geográficas, também poderá precisar de provedores de identidade separados. Certifique-se de ter uma maneira de identificar onde os dados dos usuários são armazenados para que você possa direcioná-los para a região correta para entrada, se necessário. |
Você poderá dar suporte aos seus requisitos de conformidade e aprimorar a experiência do usuário roteando os usuários para a experiência de entrada apropriada para sua localização. |
Seleção do provedor de identidade
Cada provedor de identidade oferece recursos, limitações, modelos de preços e padrões de implementação exclusivos. O Microsoft Entra e o 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 sobre o design
Documente seus requisitos de identidade. Comece listando os recursos que seu aplicativo precisa agora e precisará no futuro. Os recursos típicos a serem considerados incluem:
-
- Suporte ao provedor de identidade federado 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 de dados de 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 planejado de usuários ao avaliar o custo de uma solução de identidade. Uma solução pode não permanecer econômica 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 usuários, mas insustentável para 5 milhões. Se exigir configuração mínima e for fácil de usar e fácil de migrar, ainda poderá 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 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 gerenciamento. Diferentes provedores de identidade exigem níveis variados de sobrecarga de gerenciamento. As soluções IDaaS 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 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 por conta própria incorre em sobrecarga operacional significativa e riscos de segurança. 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 atender. 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 identidade 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.
Compensação: Complexidade e eficiência operacional. Ao trabalhar com provedores de identidade federados, você alivia a complexidade de gerenciar as identidades de seus usuários. No entanto, você assume o custo de integração com outro provedor de identidade. Decida onde você deseja concentrar 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 com suporte aumenta. O planejamento cuidadoso é essencial, especialmente se cada cliente usar 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 identidade.
Considerações sobre o 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 federados exclusivos para cada cliente. Você deve saber se seus clientes usarão o OpenID Connect (OIDC), o Security Assertion Markup Language (SAML) ou ambos para integração.
Mapeie a experiência de entrada. Visualize o fluxo do usuário do processo de inscrição e entrada. Observe quaisquer requisitos especiais que possam alterar o design do fluxo do usuário. Por exemplo:
Marca personalizada. Domínios de assinatura de marca branca ou personalizados por cliente.
Informações personalizadas. Coletar informações adicionais do usuário durante a inscrição ou entrada, como seleção de locatário para usuários com acesso a vários locatários.
Seleção do provedor de identidade. Se você usar um único provedor de identidade de aplicativo que tenha muitos provedores de identidade federados confiando nele, decida como selecionar um provedor. Essa seleção pode ser feita manualmente por meio de um botão ou automaticamente com base nas informações conhecidas do usuário. À medida que o número de provedores aumenta, a seleção automática se torna mais prática. Esse recurso é conhecido como Descoberta de Realm Inicial.
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 federados necessários. 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 federado 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, normalmente 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ários relacionamentos de confiança de identidade federada. É comum em soluções SaaS que as empresas paguem por uma camada mais alta que permite a entrada federada. |
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 usar a Descoberta de Realm Inicial. A ID do Microsoft Entra fornece Descoberta de Realm Inicial interna. |
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 em um locatário, permitindo que os usuários leiam ou acessem determinadas informações enquanto restringem as atualizações ou o acesso a outros dados.
Considerações sobre o design
Escolha o modelo de autorização certo para o caso de uso. Existem dois tipos principais:
- Autorização baseada em função. 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 administrador de um recurso, mas não ter acesso a outro.
Decida onde armazenar os dados de autorização. Os dados de autorização para sua aplicação 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 impor regras de autorização usando essas declarações de token.
- Seu aplicativo. Desenvolva sua própria lógica de autorização e armazene permissões de usuário em um banco de dados ou sistema semelhante, permitindo controles de autorização refinados baseados em função ou em nível de recurso.
Compensação: Complexidade, flexibilidade e segurança. Armazenar dados de autorização em um provedor de identidade e exibir 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ção 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.Avalie o impacto do gerenciamento delegado. 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 com frequência 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 limites de locatário, a menos que esse acesso seja explicitamente permitido. | O acesso não autorizado aos dados de outro locatário, mesmo o acesso acidental, pode ser visto como um grande incidente de segurança e corroer a confiança do cliente em sua plataforma. Bloquear o acesso desnecessário ajudará você a evitar essas 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 aos administradores de locatários para alterar as permissões do usuário. | Você fornecerá mais controle aos seus clientes e evitará cargas operacionais desnecessárias em 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 o gerenciamento de identidade e acesso:
- Considerações de arquitetura para identidade em soluções multilocatários
- Abordagens arquitetônicas para identidade em soluções multilocatários
Próxima etapa
Saiba mais sobre como escolher seu modelo de hospedagem de computação, os aspectos operacionais e como otimizar as opções de tecnologia para ajudá-lo a cumprir seus contratos e objetivos de nível de serviço.