Partilhar 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ção de 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 aumentar a segurança das chamadas de integração de API do Partner Center. Isso ajuda todas as partes, incluindo a Microsoft, os parceiros CSP e os fornecedores do Painel de Controle, a proteger sua infraestrutura e os dados dos clientes contra riscos de segurança.

Importante

O Azure Ative 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 Azure AD Graph não têm SLA ou compromisso de manutenção além das correções relacionadas à segurança. Os investimentos em 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, consulte Importante: Aposentadoria do Azure AD Graph e Descontinuação do módulo Powershell.

Âmbito

Este artigo aplica-se aos seguintes parceiros:

  • Os Fornecedores de Painel de Controle (CPVs) são fornecedores independentes de software que desenvolvem aplicativos para uso de 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 APIs. São as empresas que desenvolvem aplicações (normalmente aplicações web) que permitem aos CSPs vender os seus produtos através de um mercado unificado.
  • Provedores indiretos de CSP e parceiros diretos de CSP que estão usando ID de aplicativo + autenticação de usuário e se integram diretamente com APIs do Partner Center.

Nota

Para se qualificar como um CPV, você deve integrar ao Partner Center como um 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 aplicações

No processo de fazer pedidos de produtos da Microsoft em nome de CSPs, os aplicativos de mercado de CPVs interagem com APIs da Microsoft para fazer pedidos e provisionar recursos para 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 CSP e locatários de clientes CSP.
  • APIs do Azure Resource Manager (ARM) 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 a esses aplicativos confidenciais podem levar ao comprometimento dos dados do cliente. Portanto, as concessões de permissão e a representação de privilégios de parceiro devem ser projetadas para seguir o princípio do menor privilégio. Os seguintes princípios e práticas recomendadas garantem que os aplicativos de mercado 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 do locatário do parceiro CSP não devem ser compartilhadas com os Fornecedores do Painel de Controle.

  • Um aplicativo de mercado 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 mercado 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 falsificação de identidade.

  • 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 aplicação deve ser favorável a disposições de segurança adicionais, como o acesso condicional a um modelo de segurança melhor.

Nota

Os provedores indiretos do CSP e os parceiros diretos do CSP que estão usando o ID do aplicativo + autenticação do usuário e se integram diretamente com as APIs do Partner Center são obrigados a 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 depois de consentirem em usar sua conta com seu 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 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 ID do Microsoft Entra solicita que ele concorde 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.

Nota

Os provedores indiretos do CSP e os parceiros diretos do CSP que estão usando o ID do aplicativo + autenticação do usuário e se integram 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 suporta dois tipos de permissões, somente para aplicativos e delegadas.

  • A permissão somente aplicativo é concedida diretamente à identidade do aplicativo. Por exemplo, você pode conceder permissão a um aplicativo 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 utilizador regular, enquanto outras requerem o consentimento de um administrador de inquilino. 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 APIs da Microsoft (APIs do Partner Center, APIs do Graph e assim por diante), os parceiros CSP devem fazer logon no aplicativo e consentir em permitir que o aplicativo chame APIs em seu nome.

Nota

Os provedores indiretos do CSP e os parceiros diretos do CSP que estão usando o 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 seu aplicativo de mercado 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 chave secreta.
  • Ele deve ter o modo de autenticação implícita desativado.

Além disso, recomendamos a adesão a estas melhores práticas:

  • Use um certificado para a chave secreta.
  • Habilite o acesso condicional para aplicar restrições de intervalo de IP. Isso pode exigir mais funcionalidade para ser habilitado no locatário do Microsoft Entra.
  • Aplique políticas de tempo de vida do token de acesso para o 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 Azure Resource Manager. A seguir está o conjunto mínimo de permissões necessárias para APIs do Partner Center:

  • Permissões delegadas do Microsoft Entra ID: 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 conceder para fazer mais chamadas para APIs do Partner Center. O consentimento é obtido através de um fluxo de código de autenticação OAuth.

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

Para obter mais informações, consulte Autorizar o acesso a aplicativos Web do Azure Ative e Directory usando o fluxo de concessão de código 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 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 login 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 subsídios 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 login 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 de 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 o token de atualização com segurança. O token de atualização faz parte das credenciais de 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 chamadas de solicitação de token

Um aplicativo de parceiro CPVs ou CSP 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 no login federado. 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 faça passar 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 para o aplicativo a ser chamado. Por exemplo, a URL do recurso para a API do Microsoft Partner Center é https://api.partnercenter.microsoft.com.
  • As credenciais do aplicativo 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 aspeto fundamental da segurança na nuvem é a identidade e o acesso. Em um mundo mobile-first, cloud-first, os usuários podem acessar os recursos da sua organização usando vários dispositivos e aplicativos de qualquer lugar. Concentrar-se simplesmente em quem pode aceder a um recurso já não é 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. Permite-lhe implementar decisões de controlo de acesso automatizadas relativamente ao acesso às aplicações na cloud que têm por base 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 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 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.

Conteúdos relacionados