Estrutura do modelo de aplicativo seguro

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.

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 é considerado um parceiro CSP com acesso direto ao painel de controlo do parceiro ou às 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 e parceiros diretos do CSP que estão a utilizar a autenticação de utilizador com ID de aplicação e integram-se diretamente com as APIs do Partner Center.

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 a gestão de identidades para inquilinos CSP e inquilinos 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 assumir os 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.

• 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 das aplicações web de clientes CSP não devem ser partilhadas com os fornecedores do painel de controlo.

• 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 uma aplicação de um marketplace tem de ser alinhada a 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 o propósito da simulaçã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.

Uma aplicação multilocatário geralmente é uma aplicação 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 utilizadores de qualquer inquilino do Microsoft Entra poderão entrar na sua aplicação depois de consentirem em usar a sua conta na sua aplicação.

Para saber mais sobre como criar uma aplicação multilocatária, consulte Como iniciar sessão com qualquer utilizador do Microsoft Entra utilizando o padrão de aplicação multilocatária.

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 derem consentimento, uma representação da aplicação denominada 'principal de serviço' será criada no inquilino do utilizador, e o processo de início de sessão poderá prosseguir. Uma delegação também é criada no diretório que registra o consentimento do usuário para o aplicativo.

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 exclusiva para aplicação é concedida diretamente à identidade da aplicação. 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.
• 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.

• Visão geral de permissões e consentimento na plataforma de identidade da Microsoft
• Noções básicas sobre o consentimento do usuário e do administrador

Num fluxo OAuth de autorização aberta para aplicações multilocatárias, a aplicação é representada como uma aplicação multilocatária no tenant 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 entrar no aplicativo e consentir em permitir que o aplicativo chame APIs em seu nome.

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.

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 funcionalidades a serem ativadas 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: aceder ao diretório como utilizador autenticado
• Permissões delegadas de APIs do Partner Center: Access

Uma aplicação multilocatário deve obter o consentimento dos parceiros e usar esse consentimento e autorização para efetuar mais chamadas às APIs do Partner Center. O consentimento é obtido através de um fluxo de código de autenticação OAuth.

Para obter consentimento, os parceiros CPV ou CSP devem criar um website de integração inicial 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 OAuth 2.0.

Eis os passos para uma aplicação multilocatária capturar o consentimento de um parceiro CSP juntamente com um token reutilizável para realizar chamadas às APIs do Partner Center.

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

1. Crie uma aplicação web para integrar parceiros que possa hospedar um link de consentimento, permitindo que o parceiro clique para aceitar o consentimento para a aplicação multicliente.
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.
   • A aplicação recebe permissõ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 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. A aplicação web de integração de parceiro deve usar o código de autorização junto com a ID da aplicação e a chave secreta para chamar a API de Tokens da Microsoft Entra ID para obter um token de renovaçã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.

Uma aplicação de parceiro CPVs ou CSP deve adquirir um token de acesso antes de efetuar chamadas às APIs do Partner Center. Essas APIs são representadas na URL do recurso https://api.partnercenter.microsoft.com.

Uma aplicação CPV deve identificar por qual conta de parceiro se deve fazer passar para fazer chamadas às APIs do Partner Center com base no produto ou no login federado. A aplicação recupera o token de atualização criptografado para esse inquilino 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 atende a 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 o Microsoft Entra ID Tokens API. 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 endpoint para a aplicação que será chamada. 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.

Quando se trata de gerenciar seus recursos de nuvem, um aspeto fundamental da segurança na nuvem é a identidade e o acesso. Num mundo primariamente móvel e em nuvem, os utilizadores podem aceder aos recursos da sua organização usando vários dispositivos e aplicações 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. Com o acesso condicional, você pode implementar decisões automatizadas de controle de acesso para acessar seus aplicativos na nuvem com base em condições.

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

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.

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.

• Como configurar um novo aplicativo multilocatário
• Autorizar o acesso a aplicativos Web do Microsoft Entra usando o fluxo de concessão de código OAuth 2.0
• Como funciona o consentimento do aplicativo
• Referência da API REST do Partner Center