Compartilhar via

Estrutura do modelo de aplicativo seguro

  • Artigo

A Microsoft está introduzindo uma estrutura segura e escalonável para autenticar parceiros CSP (provedor de soluções em nuvem) e CPV (Fornecedores de Painel de Controle) por meio da arquitetura de MFA (autenticação multifator) do Microsoft Azure. Os parceiros CSP e os fornecedores do Painel de Controle podem contar com o novo modelo para elevar a segurança das chamadas de integração de API do Partner Center. Isso ajuda todas as partes, incluindo a Microsoft, parceiros CSP e fornecedores de painéis de controle, a proteger sua infraestrutura e dados de clientes contra riscos de segurança.

Importante

O Azure Active Directory (Azure AD) Graph foi preterido a partir de 30 de junho de 2023. No futuro, não faremos mais investimentos no Azure AD Graph. As APIs do Graph do Azure AD não têm SLA ou compromisso de manutenção além de correções relacionadas à segurança. Os investimentos nos novos recursos e funcionalidades só serão feitos no Microsoft Graph.

Desativaremos o Azure AD Graph em etapas incrementais para que você tenha tempo suficiente para migrar seus aplicativos para APIs do Microsoft Graph. Em uma data posterior que anunciaremos, bloquearemos a criação de novos aplicativos usando o Azure AD Graph.

Para saber mais, confira Importante: desativação do Azure AD Graph e substituição do módulo do Powershell.

Escopo

Este artigo se aplica aos seguintes parceiros:

  • Os CPVs (Fornecedores de Painel de Controle) são fornecedores de software independentes que desenvolvem aplicativos para uso por parceiros CSP para integração com APIs do Partner Center. Um CPV não é um parceiro CSP com acesso direto ao painel do parceiro ou às APIs. São as empresas que desenvolvem aplicativos (geralmente aplicativos da web) que permitem que os CSPs vendam seus produtos por meio de um mercado unificado.
  • Provedores indiretos do CSP e parceiros CSP diretos que estão usando ID do aplicativo + autenticação de usuário e se integram diretamente às APIs do Partner Center.

Observação

Para se qualificar como um CPV, você deve primeiro integrar o Partner Center como um CPV. Se você for um parceiro CSP existente que também seja um CPV, esse pré-requisito também se aplicará a você.

Desenvolvimento seguro de aplicativos

No processo de fazer pedidos de produtos da Microsoft em nome de CSPs, os aplicativos do marketplace de CPVs interagem com as APIs da Microsoft para fazer pedidos e provisionar recursos para os clientes.

Algumas dessas APIs incluem:

  • APIs do Partner Center que implementam operações de comércio, como fazer pedidos e gerenciar ciclos de vida de assinatura.
  • APIs do Microsoft Graph que implementam o gerenciamento de identidades para locatários do CSP e locatários do cliente do CSP.
  • APIs do ARM (Azure Resource Manager) que implementam a funcionalidade de implantação do Azure.

Os parceiros CSP são habilitados com privilégios delegados para agir em nome de seus clientes ao chamar APIs da Microsoft. Os privilégios delegados permitem que os parceiros CSP concluam cenários de compra, implantação e suporte para seus clientes.

Os aplicativos do Marketplace são projetados para ajudar os parceiros CSP a listar suas soluções para os clientes. Para conseguir isso, os aplicativos do marketplace precisam representar privilégios de parceiro CSP para chamar APIs da Microsoft.

Como os privilégios de parceiro CSP são altos e fornecem acesso a todos os clientes do parceiro, é importante entender como esses aplicativos devem ser projetados para resistir a vetores de exploração de segurança. Ataques de segurança nesses aplicativos confidenciais podem levar ao comprometimento dos dados do cliente. Portanto, as concessões de permissão e a representação de privilégio de parceiro devem ser projetadas para seguir o princípio de privilégios mínimos. Os princípios e práticas recomendadas a seguir garantem que os aplicativos do marketplace sejam sustentáveis e possam resistir a comprometimentos.

Princípios de segurança para representação de credenciais

  • Os aplicativos do Marketplace não devem armazenar credenciais de parceiros CSP.

  • As senhas de usuário do parceiro CSP não devem ser compartilhadas.

  • As chaves do aplicativo Web de locatário do parceiro CSP não devem ser compartilhadas com fornecedores do Painel de Controle.

  • Um aplicativo do marketplace deve apresentar a identidade do aplicativo junto com as informações do parceiro, em vez de usar apenas credenciais de parceiro ao fazer chamadas que representam uma identidade de parceiro CSP.

  • O acesso a um aplicativo de marketplace deve ser baseado no princípio do menor privilégio e claramente articulado em permissões.

  • A autorização para um aplicativo do marketplace deve ser articulada para várias credenciais.

  • As credenciais do aplicativo e as credenciais do parceiro devem ser fornecidas juntas para obter acesso.

    Importante

    É importante que não haja um único ponto de compromisso.

  • O acesso deve ser restrito a um público ou API específico.

  • O Access deve identificar a finalidade da representação.

  • As permissões de acesso para um aplicativo do marketplace devem ser limitadas por tempo. Os parceiros CSP devem ser capazes de renovar ou revogar o acesso ao aplicativo do marketplace.

  • Processos rápidos de controle ou correção devem estar em vigor para lidar com comprometimentos de credenciais de aplicativos do marketplace.

  • Todas as contas de usuário devem usar autenticação de dois fatores (2FA).

  • O modelo de aplicativo deve ser amigável a provisões de segurança extras, como acesso condicional a um modelo de segurança melhor.

Observação

Os provedores indiretos do CSP e os parceiros diretos do CSP que estão usando a ID do aplicativo + autenticação do usuário e se integram diretamente às APIs do Partner Center devem seguir os princípios acima para proteger seus próprios aplicativos do marketplace.

Identidade e conceitos do aplicativo

Aplicativos multilocatários

Um aplicativo multilocatário geralmente é um aplicativo SaaS (software como serviço). Você pode configurar seu aplicativo para aceitar entradas de qualquer locatário do Microsoft Entra configurando o tipo de aplicativo como multilocatário no painel do Azure. Os usuários em qualquer locatário do Microsoft Entra poderão entrar em seu aplicativo após o consentimento para usar sua conta com o aplicativo.

Para saber mais sobre como criar um aplicativo multilocatário, consulte Conectar qualquer usuário do Microsoft Entra usando o padrão de aplicativo multilocatário.

Para que um usuário entre em um aplicativo na ID do Microsoft Entra, o aplicativo deve ser representado no locatário do usuário, o que permite que a organização faça coisas como aplicar políticas exclusivas quando os usuários de seu locatário entrarem no aplicativo. Para um aplicativo de locatário único, esse registro é simples: é aquele que acontece quando você registra o aplicativo no painel do Azure.

Para um aplicativo multilocatário, o registro inicial do aplicativo reside no locatário do Microsoft Entra usado pelo desenvolvedor. Quando um usuário de um locatário diferente entra no aplicativo pela primeira vez, o Azure AD solicita que ele consinta com as permissões solicitadas pelo aplicativo. Se eles consentirem, uma representação do aplicativo chamada entidade de serviço será criada no locatário do usuário e o processo de entrada poderá continuar. Uma delegação também é criada no diretório que registra o consentimento do usuário para o aplicativo.

Observação

Os provedores indiretos do CSP e os parceiros diretos do CSP que estão usando a ID do aplicativo + autenticação do usuário e se integram diretamente às APIs do Partner Center terão que dar consentimento ao aplicativo do marketplace usando a mesma estrutura de consentimento.

A experiência de consentimento é afetada pelas permissões solicitadas pelo aplicativo. A ID do Microsoft Entra dá suporte a dois tipos de permissões, somente aplicativo e delegada.

  • A permissão somente do aplicativo é concedida diretamente à identidade do aplicativo. Por exemplo, você pode conceder a um aplicativo permissão para ler a lista de usuários em um locatário, independentemente de quem está conectado ao aplicativo.
  • A permissão delegada concede a um aplicativo a capacidade de atuar como um usuário conectado para um subconjunto das coisas que o usuário pode fazer. Por exemplo, você pode conceder a um aplicativo a permissão delegada para ler o calendário do usuário conectado.

Algumas permissões são consentidas por um usuário comum, enquanto outras exigem o consentimento de um administrador de locatários. Para obter mais informações sobre a estrutura de consentimento do Microsoft Entra, consulte Noções básicas sobre experiências de consentimento de aplicativo do Microsoft Entra.

Fluxo de token de autorização aberta de aplicativo multilocatário (OAuth)

Em um fluxo de autorização de abertura de aplicativo multilocatário (OAuth), o aplicativo é representado como um aplicativo multilocatário no locatário do parceiro CPV ou CSP.

Para acessar APIs da Microsoft (APIs do Partner Center, APIs do Graph e assim por diante), os parceiros CSP devem fazer logon no aplicativo e consentir para permitir que o aplicativo chame APIs em seu nome.

Observação

Os provedores indiretos do CSP e os parceiros diretos do CSP que estão usando a ID do aplicativo e a autenticação do usuário e se integram diretamente às APIs do Partner Center terão que dar consentimento ao aplicativo do marketplace para usar a mesma estrutura de consentimento.

O aplicativo obtém acesso aos recursos do parceiro, como APIs do Graph e do Partner Center, por meio de consentimento e concessões OAuth.

Criar um aplicativo multilocatário

Um aplicativo multilocatário deve atender aos seguintes requisitos:

  • Deve ser um aplicativo Web com uma ID de aplicativo e uma chave secreta.
  • Ele deve ter o modo de autenticação implícita desativado.

Além disso, recomendamos seguir estas práticas recomendadas:

  • Use um certificado para a chave secreta.
  • Habilite o acesso condicional para aplicar restrições de intervalo de IP. Isso pode exigir que mais funcionalidades sejam habilitadas no locatário do Microsoft Entra.
  • Aplique políticas de tempo de vida do token de acesso para o aplicativo.

Ao adquirir um token, a ID do aplicativo e a chave secreta devem ser apresentadas. A chave secreta pode ser um certificado.

O aplicativo pode ser configurado para chamar várias APIs, incluindo APIs do Azure Resource Manager. Veja a seguir o conjunto mínimo de permissões necessárias para APIs do Partner Center:

  • Permissões delegadas da ID do Microsoft Entra: acessar o diretório como usuário conectado
  • Permissões delegadas de APIs do Partner Center: acesso

Um aplicativo multilocatário deve obter o consentimento dos parceiros e usar o consentimento e a concessão para fazer mais chamadas para as APIs do Partner Center. O consentimento é obtido por meio de um fluxo de código de autenticação OAuth.

Para obter consentimento, os CPVs ou parceiros CSP devem criar um site de integração que possa aceitar uma concessão de código de autenticação da ID do Microsoft Entra.

Para obter mais informações, consulte Autorizar o acesso a aplicativos Web do Azure Active e do Directory usando o fluxo de concessão de código do OAuth 2.0.

Aqui estão as etapas para um aplicativo multilocatário capturar o consentimento do parceiro CSP junto com um token reutilizável para fazer chamadas para APIs do Partner Center.

Use as etapas a seguir para obter o consentimento do parceiro.

  1. Crie um aplicativo Web de integração de parceiro que possa hospedar um link de consentimento para o parceiro clicar para aceitar o consentimento para o aplicativo multilocatário.
  2. O parceiro CSP clica no link de consentimento. Por exemplo, https://login.microsoftonline.com/common/oauth2/authorize?&client_id=<marketplaceappid>&response_ty
  3. A página de logon do Microsoft Entra explica as permissões que serão concedidas ao aplicativo em nome do usuário. O parceiro CSP pode decidir usar as credenciais do Agente Administrativo ou do Agente de Vendas para entrar e aprovar o consentimento. O aplicativo recebe permissões com base na função de usuário usada para entrar.
  4. Depois que o consentimento é concedido, a ID do Microsoft Entra cria uma entidade de serviço do aplicativo multilocatário do CPV no locatário do parceiro CSP. O aplicativo recebe concessões OAuth para agir em nome do usuário. Essas concessões permitem que o aplicativo multilocatário chame APIs do Partner Center em nome do parceiro. Neste ponto, a página de logon do Microsoft Entra redireciona para o aplicativo Web de integração do parceiro. O aplicativo Web recebe um código de autorização da ID do Microsoft Entra. O aplicativo Web de integração do parceiro deve usar o código de autorização junto com a ID do aplicativo e a chave secreta para chamar a API de tokens de ID do Microsoft Entra para obter um token de atualização.
  5. Armazene com segurança o token de atualização. O token de atualização faz parte das credenciais do parceiro usadas para obter acesso às APIs do Partner Center em nome do parceiro. Depois que o token de atualização for adquirido, criptografe-o e armazene-o em um repositório de chaves secretas, como o cofre de chaves do Azure.

Fluxo de chamada de solicitação de token

O aplicativo de um parceiro CPVs ou CSP deve adquirir um token de acesso antes de fazer chamadas para APIs do Partner Center. Essas APIs são representadas no URL https://api.partnercenter.microsoft.comdo recurso.

Um aplicativo CPV deve identificar qual conta de parceiro ele deve representar para chamar APIs do Partner Center com base no produto ou na entrada federada. O aplicativo recupera o token de atualização criptografado para esse locatário do parceiro do repositório de chaves secretas. O token de atualização deve ser descriptografado antes do uso.

Para parceiros CSP em que há apenas um locatário que dá consentimento, a conta do parceiro refere-se ao locatário do parceiro CSP.

O token de atualização é um token de vários públicos. Isso significa que o token de atualização pode ser usado para obter um token para vários públicos-alvo com base no consentimento concedido. Por exemplo, se o consentimento do parceiro for dado para APIs do Partner Center e APIs do Microsoft Graph, o token de atualização poderá ser usado para solicitar um token de acesso para ambas as APIs. O token de acesso tem a concessão "em nome de" e permite que um aplicativo do marketplace represente o parceiro que consentiu ao chamar essas APIs.

Um token de acesso pode ser adquirido para um único público por vez. Se um aplicativo precisar acessar várias APIs, ele deverá solicitar vários tokens de acesso para o público-alvo. Para solicitar um token de acesso, o aplicativo precisa chamar a API de Tokens de ID do Microsoft Entra. Como alternativa, ele também pode usar o AuthenticationContext.AcquireTokenAsync do SDK do Microsoft Entra e passar as seguintes informações:

  • URL do recurso, que é a URL do ponto de extremidade para o aplicativo a ser chamado. Por exemplo, a URL do recurso para a API do Microsoft Partner Center é https://api.partnercenter.microsoft.com.
  • Credenciais do aplicativo que consistem na ID do aplicativo Web e na chave secreta.
  • O token de atualização

O token de acesso resultante permite que o aplicativo faça chamadas para APIs mencionadas no recurso. O aplicativo não pode solicitar um token de acesso para APIs que não receberam permissão como parte da solicitação de consentimento. O valor do atributo UPN (UserPrincipalName) é o nome de usuário do Microsoft Entra para as contas de usuário.

Mais considerações

Acesso condicional

Quando se trata de gerenciar seus recursos de nuvem, um aspecto fundamental da segurança na nuvem é a identidade e o acesso. Em um mundo que prioriza a mobilidade e a nuvem, os usuários podem acessar os recursos da sua organização usando vários dispositivos e aplicativos de qualquer lugar. Simplesmente focar em quem pode acessar um recurso não é mais suficiente. Para dominar o equilíbrio entre segurança e produtividade, você também precisa considerar como um recurso é acessado. Usando o Acesso Condicional do Microsoft Entra, você pode atender a esse requisito. Com o acesso condicional, você pode implementar decisões de controle de acesso automatizado para o acesso a aplicativos de nuvem com base em condições.

Para obter mais informações, consulte O que é acesso condicional na ID do Microsoft Entra?

Restrições baseadas em intervalo de IP

Você pode restringir os tokens a serem emitidos apenas para um intervalo específico de endereços IP. Esse recurso ajuda a restringir a área de superfície de ataque apenas a uma rede específica.

Autenticação multifator

A aplicação da autenticação multifator ajuda a restringir situações de comprometimento de credenciais, impondo a verificação de credenciais a dois ou mais formulários. Esse recurso permite que a ID do Microsoft Entra valide a identidade do chamador por meio de canais secundários seguros, como celular ou email, antes de emitir tokens.

Para obter mais informações, consulte Como funciona: Azure Multi.

Conteúdo relacionado