Compartilhar via

Estrutura do modelo de aplicativo seguro

  • Artigo

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

Importante

O Gráfico do Azure Active Directory (Azure AD) foi preterido a partir de 30 de junho de 2023. No futuro, não faremos mais investimentos no Azure AD Graph. As APIs do Azure AD Graph não têm SLA ou compromisso de manutenção além das 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 as 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, consulte Importante: Aposentadoria do Graph do Azure AD e Substituição do módulo do Powershell.

Escopo

Este artigo aplica-se aos seguintes parceiros:

  • Os Fornecedores do Painel de Controle (CPVs) são fornecedores independentes de software 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 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 CPV, você deve integrar o Partner Center como CPV primeiro. Se você é um parceiro CSP existente que também é um CPV, esse pré-requisito também se aplica a você.

Desenvolvimento seguro de aplicativos

No processo de fazer pedidos de produtos da Microsoft em nome de CSPs, os aplicativos de 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 implementando operações de comércio, como fazer pedidos e gerenciar ciclos de vida de assinaturas.
  • APIs do Microsoft Graph que implementam o gerenciamento de identidades para locatários CSP e locatários de clientes CSP.
  • APIs do Azure Resource Manager (ARM) implementando a funcionalidade de implantação do Azure.

Os parceiros CSP são capacitados 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 do privilégio mínimo. Os princípios e práticas recomendadas a seguir garantem que os aplicativos do mercado sejam sustentáveis e possam resistir a compromissos.

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 de parceiro CSP não devem ser compartilhadas.

  • As chaves do aplicativo Web do locatário parceiro CSP não devem ser compartilhadas com os 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 representando 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 pivotada 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 acesso deve identificar a finalidade da representação.

  • As permissões de acesso para um aplicativo do marketplace devem ter limite de 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 de CSP e os parceiros diretos de CSP que estão usando ID de aplicativo + autenticação de usuário e se integram diretamente às APIs do Partner Center devem seguir os princípios acima para proteger seus próprios aplicativos de mercado.

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 Entrar em qualquer usuário do Microsoft Entra usando o padrão de aplicativo multilocatário.

Para que um usuário entre em um aplicativo no Microsoft Entra ID, 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 único aplicativo de locatário, esse registro é simples: é o 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 de CSP e os parceiros diretos de CSP que estiverem usando ID de aplicativo + autenticação de usuário e se integrarem diretamente às APIs do Partner Center terão que dar consentimento para seu aplicativo de mercado usando a mesma estrutura de consentimento.

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

  • A permissão somente para aplicativos é 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 agir 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ário. 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 aberta de aplicativo multilocatário (OAuth), o aplicativo é representado como um aplicativo multilocatário no locatário do parceiro CPV ou CSP.

Para acessar as 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 de CSP e os parceiros diretos de CSP que estiverem usando ID de aplicativo e autenticação de usuário e se integrarem diretamente às APIs do Partner Center terão que dar consentimento para que seu aplicativo de marketplace use 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:

  • Ele 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 aderir a 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 funcionalidade seja habilitada no locatário do Microsoft Entra.
  • Aplique políticas de tempo de vida do token de acesso ao aplicativo.

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

O aplicativo pode ser configurado para chamar várias APIs, incluindo APIs do Gerenciador de Recursos do Azure. A seguir estão o conjunto mínimo de permissões necessárias para APIs do Partner Center:

  • Permissões delegadas do Microsoft Entra ID: acesse o diretório como usuário conectado
  • Permissões delegadas das APIs do Partner Center: Acesso

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

Para obter consentimento, 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 Directory usando o fluxo de concessão de código OAuth 2.0.

Estas são as etapas para que um aplicativo multilocatário capture 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 que o parceiro clique 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 Administrador 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, o Microsoft Entra ID 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 do Microsoft Entra ID. 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 armazenamento de chaves secreto, como o cofre de chaves do Azure.

Fluxo de chamada de solicitação de token

Um aplicativo de parceiro CSP ou CPVs deve adquirir um token de acesso antes de fazer chamadas para APIs do Partner Center. Essas APIs são representadas na 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 parceiro do armazenamento 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 de parceiro refere-se ao locatário do parceiro CSP.

O token de atualização é um token de várias audiências. Isso significa que o token de atualização pode ser usado para obter um token para vários públicos 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 se passe pelo parceiro que consentiu ao chamar essas APIs.

Um token de acesso pode ser adquirido para um único público de cada 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 do aplicativo a ser chamado. Por exemplo, a URL do recurso para a API do Microsoft Partner Center é https://api.partnercenter.microsoft.com.
  • Credenciais de 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 UserPrincipalName (UPN) é 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 Microsoft Entra Conditional Access, você pode resolver 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 no Microsoft Entra ID?

Restrições baseadas em intervalo de IP

Você pode restringir os tokens a serem emitidos apenas a 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 imposiçã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 o Microsoft Entra ID valide a identidade do chamador por meio de canais secundários seguros, como celular ou e-mail, antes de emitir tokens.

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

Próximas etapas