Compartilhar via

Estrutura de modelo de aplicativo seguro

  • Artigo

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

Importante

O Graph do Azure AD (Azure Active Directory) foi preterido em 30 de junho de 2023. Daqui para frente, não faremos mais investimentos no Azure AD Graph. As APIs do Graph do Azure AD não têm nenhum compromisso de manutenção ou SLA além de correções relacionadas à segurança. Os investimentos em novos recursos e funcionalidades serão feitos apenas 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: 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 do CSP para integrar-se às APIs do Partner Center. Um CPV não é um parceiro CSP com acesso direto ao painel de parceiros ou APIs. São as empresas que desenvolvem aplicativos (geralmente aplicativos Web) que permitem que os CSPs vendam seus produtos por meio de um marketplace unificado.
  • Provedores indiretos de CSP e parceiros diretos de CSP que estão usando a ID do aplicativo + autenticação de usuário e integram-se diretamente às APIs do Partner Center.

Nota

Para se qualificar como CPV, você deve fazer sua integração no Partner Center como CPV primeiro. 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 para 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 implementando 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 próprios da CSP e locatários dos clientes da CSP.
  • APIs do ARM (Azure Resource Manager) 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 do CSP concluam cenários de compra, implantação e suporte para seus clientes.

Os aplicativos do Marketplace foram projetados para ajudar os parceiros do CSP a listar suas soluções para os clientes. Para isso, os aplicativos do marketplace precisam assumir 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 suportar 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égio de parceiro devem ser projetadas para seguir o princípio do privilégio mínimo. Os princípios e as práticas recomendadas a seguir garantem que os aplicativos do marketplace sejam sustentáveis e possam suportar 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 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 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 do 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 baseada em múltiplas credenciais.

  • Credenciais de aplicativo e credenciais de parceiro devem ser fornecidas em conjunto para obter acesso.

    Importante

    É importante que não haja nenhum ponto único de comprometimento.

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

  • Access deve identificar a finalidade da impersonação.

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

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

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

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

Nota

Provedores indiretos e parceiros diretos do CSP que usam ID do 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 no 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 multitenant no painel do Azure. Os usuários em qualquer locatário do Microsoft Entra poderão se conectar ao seu aplicativo depois de consentirem em usar a própria conta no 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 ú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, a ID do Microsoft Entra solicita que ele consenta com as permissões solicitadas pelo aplicativo. Se consentirem, uma representação do aplicativo chamada de 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

Provedores indiretos do CSP e parceiros diretos do CSP que estão usando ID de aplicativo + autenticação de usuário e se integram diretamente às APIs do Partner Center terão que dar consentimento ao aplicativo de 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 delegadas.

  • A permissão exclusiva para o 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.
  • Permissão Delegada concede a um aplicativo a capacidade de atuar como um usuário autenticado 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 regular, 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 as experiências de consentimento do aplicativo Microsoft Entra.

Fluxo de token OAuth (Open Authorization) de aplicativo multilocatário

Em um fluxo de OAuth (Open Authorization) de aplicativo multilocatário, 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 do CSP devem fazer logon no aplicativo e consentir para 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 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 concessões de consentimento e OAuth.

Criar um aplicativo multilocatário

Um aplicativo multilocatário deve seguir os seguintes requisitos:

  • Deve ser um aplicativo Web com uma ID do aplicativo e uma chave secreta.
  • Ele deve ter o modo de autenticação implícito 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 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, 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ário para APIs do Partner Center:

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

Um aplicativo multilocatário deve obter consentimento dos parceiros e usar o consentimento e a concessão para fazer outras chamadas às APIs do Partner Center. O consentimento é adquirido 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 do Microsoft Entra ID.

Para obter mais informações, consulte plataforma de identidade da Microsoft e fluxo de código de autorização do OAuth 2.0.

Estas são as etapas para que um aplicativo multilocatário obtenha o consentimento do parceiro CSP, juntamente com um token reutilizável, para fazer chamadas para as APIs do Partner Center.

Use as etapas a seguir para adquirir 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 do 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 de Administração 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 atuar 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 de parceiros. O aplicativo Web recebe um código de autorização da ID do Microsoft Entra. O aplicativo Web de integração de parceiros deve usar o código de autorização junto com a ID do aplicativo e a chave secreta para chamar a API de Tokens do Microsoft Entra ID 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 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 repositório de chaves secretas, 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 realizar chamadas às APIs do Partner Center. Essas APIs são representadas na URL do recurso https://api.partnercenter.microsoft.com.

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 de 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 de parceiro refere-se ao locatário do parceiro CSP.

O token de atualização é um token de vários públicos-alvo. 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 fornecido 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 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 do Microsoft Entra ID. Como alternativa, ele também pode usar 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 de recurso da 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 móvel e em primeiro lugar na 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 automatizadas de controle de acesso para acessar seus aplicativos de nuvem com base em condições.

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

Restrições baseadas em intervalo de IP

Você pode restringir que os tokens sejam emitidos apenas para um intervalo específico de endereços IP. Esse recurso ajuda a restringir a área de superfície do 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 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