Quadro de modelo de aplicação segura

  • Artigo
  • 12 minutos para ler

A Microsoft está a introduzir um quadro seguro e escalável para autenticar parceiros de fornecedores de soluções de nuvem (CSP) e fornecedores de painéis de controlo (CPV) através da Microsoft Azure arquitetura de autenticação de vários fatores (MFA). Os parceiros CSP, bem como os Fornecedores de Painéis de Controlo, podem contar com o novo modelo para elevar a segurança das chamadas de integração da API do Partner Center. Isto ajudará todas as partes, incluindo a Microsoft, parceiros CSP e Fornecedores de Painéis de Controlo a protegerem as suas infraestruturas e dados de clientes contra riscos de segurança.

Âmbito

Este artigo aplica-se aos seguintes parceiros:

  • Os Fornecedores de Painéis de Controlo (CPVs) são fornecedores de software independentes que desenvolvem aplicações para uso por parceiros CSP para integrar com APIs do Partner Center. Um CPV não é um parceiro CSP com acesso direto ao painel de instrumentos ou APIs do parceiro. São as empresas que desenvolvem aplicações (geralmente aplicações web) que permitem aos CSPs vender os seus produtos através de um mercado unificado.
  • Os fornecedores indiretos da CSP e os parceiros diretos da CSP que estão a utilizar a autenticação de aplicações ID + de utilizador e a integrar-se diretamente com as APIs do Partner Center.

Nota

Para se qualificar como CPV, você deve embarcar no Partner Center como um CPV primeiro. Se é um parceiro CSP existente que também é um CPV, este pré-requisito também se aplica a si.

Desenvolvimento seguro de aplicações

No processo de colocação de encomendas de produtos da Microsoft em nome de CSPs, as aplicações de marketplace de CPVs interagem com as APIs da Microsoft para emissão de encomendas e recursos de fornecimento para os clientes em nome de CSPs.

Algumas destas APIs incluem:

  • ApIs do Partner Center implementando operações de comércio como colocar encomendas e gerir ciclos de vida de subscrição.
  • A Microsoft Graph APIs que implementam a gestão de identidade para inquilinos da CSP e inquilinos do cliente CSP.
  • Azure Resource Manager (ARM) APIs implementando a funcionalidade de implementação do Azure.

Os parceiros da CSP estão habilitados com privilégios delegados para agir em nome dos seus clientes ao ligarem para as APIs da Microsoft. Os privilégios delegados permitem aos parceiros da CSP completar cenários de compra, implementação e suporte para os seus clientes.

As aplicações do marketplace são projetadas para ajudar os parceiros da CSP a listar as suas soluções para os clientes. Para isso, as aplicações do mercado precisam de personificar os privilégios dos parceiros CSP para chamar APIs da Microsoft.

Uma vez que os privilégios dos parceiros da CSP são muito elevados e proporcionam acesso a todos os clientes do parceiro, é muito importante entender como estas aplicações devem ser concebidas para resistir a vetores de exploração de segurança. Os ataques de segurança a estas aplicações sensíveis podem levar ao compromisso dos dados dos clientes. Por conseguinte, as concessões de autorização e a personificação do privilégio dos parceiros devem ser concebidas para seguir o princípio do menor privilégio. Os seguintes princípios e boas práticas garantem que as aplicações no mercado são sustentáveis e podem resistir a compromissos.

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

  • As aplicações do mercado não devem armazenar credenciais de parceiros da CSP.

  • As palavras-passe do utilizador do parceiro CSP não devem ser partilhadas.

  • As chaves da aplicação web do inquilino parceiro CSP não devem ser partilhadas com os fornecedores de painéis de controlo.

  • Um pedido de mercado deve apresentar a identidade do pedido, juntamente com as informações dos parceiros, em vez de utilizar apenas credenciais de parceiros ao fazer chamadas que se fazem passar por uma identidade de parceiro CSP.

  • O acesso a uma aplicação de mercado deve basear-se no princípio do menor privilégio e articulado claramente nas permissões.

  • A autorização para um pedido de mercado deve ser apostada em múltiplas credenciais.

  • As credenciais de aplicação e as credenciais dos parceiros devem ser fornecidas em conjunto para ter acesso.

    Importante

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

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

  • O acesso deve identificar o propósito da personificação.

  • As permissões de acesso a uma aplicação de mercado devem estar limitadas ao tempo. Os parceiros da CSP devem poder renovar ou revogar o acesso à aplicação do mercado.

  • Devem ser realizados processos de controlo ou de reparação rápidos para lidar com compromissos de credenciais de aplicação do mercado.

  • Todas as contas de utilizador devem utilizar a autenticação de dois fatores (2FA).

  • O modelo de aplicação deve ser favorável a disposições adicionais de segurança, como o acesso condicional a um melhor modelo de segurança.

Nota

Os fornecedores indiretos da CSP e os parceiros diretos da CSP que utilizam o ID + a autenticação do utilizador e integram-se diretamente com as APIs do Partner Center são obrigados a seguir os princípios acima referidos para garantir as suas próprias aplicações de mercado.

Identidade e conceitos de aplicação

Aplicações multi-inquilino

Uma aplicação multi-inquilino é geralmente um software como uma aplicação de serviço (SaaS). Pode configurar o seu pedido de aceitação de inscrições de qualquer inquilino Azure Ative Directory (Azure AD) configurando o tipo de aplicação como multi-inquilino no painel Azure. Os utilizadores de qualquer inquilino Azure AD poderão inscrever-se na sua aplicação depois de consentir em utilizar a sua conta com a sua aplicação.

Para saber mais sobre a criação de uma aplicação multi-inquilino, consulte o Sign in any Azure Ative Directory utilizador utilizando o padrão de aplicação multi-inquilino.

Para que um utilizador inscreva-se numa aplicação em Azure AD, a aplicação deve ser representada no arrendatário do utilizador. Isto permite que a organização faça coisas como aplicar políticas únicas quando os utilizadores do seu inquilino se inscrevem na aplicação. Para um único pedido de inquilino, este registo é simples: é o que acontece quando se regista o pedido no painel Azure.

Para uma aplicação multi-arrendatário, o registo inicial para a aplicação vive no inquilino AZURE AD utilizado pelo promotor. Quando um utilizador de um inquilino diferente assina o pedido pela primeira vez, a Azure AD pede-lhes que concordem com as permissões solicitadas pelo pedido. Se consentirem, então uma representação da aplicação chamada principal de serviço é criada no arrendatário do utilizador, e o sinal em processo pode continuar. É também criada uma delegação no diretório que regista o consentimento do utilizador para a aplicação.

Nota

Os fornecedores indiretos da CSP e os parceiros diretos da CSP que utilizam o ID + autenticação do utilizador e se integram diretamente com as APIs do Partner Center terão de dar consentimento à sua aplicação de mercado utilizando o mesmo quadro de consentimento.

A experiência de consentimento é afetada pelas permissões solicitadas pelo pedido. A Azure AD suporta dois tipos de permissões, apenas para aplicações e delegadas.

  • A permissão apenas para aplicações é concedida diretamente à identidade da aplicação. Por exemplo, pode conceder uma permissão de pedido para ler a lista de utilizadores num inquilino, independentemente de quem esteja inscrito na aplicação.
  • A permissão delegada concede a uma aplicação a capacidade de agir como um utilizador assinado no utilizador para um subconjunto das coisas que o utilizador pode fazer. Por exemplo, pode conceder a um pedido a permissão delegada para ler o assinado no calendário do utilizador.

Algumas permissões podem ser consentidas por um utilizador regular, enquanto outras requerem o consentimento de um administrador de inquilino. Para obter mais informações sobre Azure Ative Directory quadro de consentimento, consulte as experiências de consentimento do pedido de Ad da Azure.

Fluxo de ficha de pedido de vários inquilinos (OAuth)

Num fluxo de autorização aberta de pedido de vários inquilinos (OAuth), o pedido é representado como um pedido de multi-inquilino no cpV ou inquilino do parceiro CSP.

Para aceder às APIs do Microsoft (APIs do Partner Center, Graph APIs, e assim por diante), os parceiros CSP devem iniciar sessão na aplicação e consentimento para permitir que a aplicação ligue para APIs em seu nome.

Nota

Os fornecedores indiretos da CSP e os parceiros diretos da CSP que utilizam o ID da aplicação e a autenticação do utilizador e que se integram diretamente com as APIs do Partner Center terão de dar consentimento à sua aplicação de mercado para utilizarem o mesmo quadro de consentimento.

A aplicação ganha acesso aos recursos do parceiro, como apis Graph e Partner Center, através de consentimento e bolsas de OAuth.

Criar uma aplicação multi-inquilino

Um pedido multi-arrendatário deve respeitar os seguintes requisitos:

  • Deve ser uma aplicação web com identificação de aplicação e chave secreta.
  • Deve ter o modo de autenticação implícito desligado.

Além disso, recomendamos aderir a estas boas práticas:

  • Use um certificado para a chave secreta.
  • Permitir o acesso condicional para aplicar restrições de alcance IP. Isto pode exigir uma funcionalidade adicional para ser ativada no inquilino AZure AD.
  • Aplicar políticas de vida simbólicas para a aplicação.

Ao adquirir um token, o ID da aplicação e a chave secreta devem ser apresentados. A chave secreta pode ser um certificado.

A aplicação pode ser configurada para chamar várias APIs, incluindo APIs gestor de recursos Azure. Segue-se o conjunto mínimo de permissões necessárias para as APIs do Partner Center:

  • Azure Ative Directory permissões delegadas: Aceda ao diretório conforme assinado no utilizador
  • Permissões delegadas do Centro De Parceiros: Acesso

Um pedido multi-inquilino deve adquirir o consentimento dos parceiros e usar o consentimento e o subsídio para fazer novas chamadas para as APIs do Partner Center. O consentimento é adquirido através de um fluxo de código de autenticação OAuth.

Para obter o consentimento, os parceiros CPVs ou CSP devem construir um website de bordo que possa aceitar uma concessão de código de autenticação a partir do diretório ativo da Azure.

Para obter mais informações, consulte Autorizar o acesso às aplicações web Azure Ative e Diretório utilizando o fluxo de concessão de código OAuth 2.0.

Aqui estão os passos para uma aplicação multi-inquilino para capturar o consentimento do parceiro CSP, juntamente com um token reutilizável para fazer chamadas para APIs do Partner Center.

Utilize os seguintes passos para adquirir o consentimento do parceiro.

  1. Construa um parceiro a bordo de uma aplicação web que possa hospedar um link de consentimento para o parceiro clicar para aceitar o consentimento para a aplicação multi-inquilino.
  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 da AZure AD explica as permissões que serão concedidas à aplicação em nome do utilizador. O parceiro da CSP pode decidir usar credenciais de Agente Administrador ou de Agente Comercial para assinar e aprovar o consentimento. A aplicação é dada permissões com base na função de utilizador utilizada para iniciar sinsumento.
  4. Uma vez concedido o consentimento, Azure Ative Directory cria um principal de serviço da aplicação multi-arrendatário do CPV no inquilino do CSP. O pedido recebe subsídios da OAuth para agir em nome do utilizador. Estas subvenções permitem que a aplicação multi-inquilino ligue para as APIs do Partner Center em nome do parceiro. Neste ponto, a página de login AZure AD redireciona para o parceiro na aplicação web. A aplicação web recebe um código de autorização da Azure AD. O parceiro que está a bordo da web deve utilizar o código de autorização juntamente com o ID da aplicação e a chave secreta para ligar para a Azure AD Tokens API para obter um token de atualização.
  5. Guarde de forma segura o token de atualização. O token de atualização faz parte das credenciais de parceiro usadas para obter acesso a APIs do Partner Center em nome do parceiro. Assim que o token de atualização for adquirido, criptografe-o e armazene-o numa loja secreta, como o cofre-chave Azure.

Fluxo de chamada de pedido de token

A aplicação de um parceiro cpv ou CSP deve adquirir um token de acesso antes de fazer chamadas para APIs do Partner Center. Estas APIs estão representadas na URL https://api.partnercenter.microsoft.comde recursos.

Uma aplicação CPV deve identificar qual a conta parceira que deve fazer para chamar APIs do Partner Center com base em qualquer produto ou sindiscêntido. A aplicação recupera o token de atualização encriptado para o inquilino parceiro da loja secreta. O token de atualização deve ser desencriptado antes da utilização.

Para os sócios da CSP onde existe apenas um inquilino que dá o seu consentimento, a conta do parceiro refere-se ao inquilino do sócio da CSP.

O token refresh é um símbolo multi-público. Isto significa que o token de atualização pode ser usado para obter um símbolo para vários públicos com base no consentimento que é 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 pode ser usado para solicitar um token de acesso para ambas as APIs. O token de acesso terá a concessão "em nome de" e permitirá que uma aplicação de marketplace se personiu pelo parceiro que consentiu ao chamar estas APIs.

Um símbolo de acesso pode ser adquirido para um único público de cada vez. Se uma aplicação precisar de aceder a várias APIs, deve solicitar vários tokens de acesso para o público-alvo. Para solicitar um token de acesso, a aplicação precisa de ligar para a Azure AD Tokens API. Em alternativa, também poderia utilizar o Azure AD SDK's AuthenticationContext.AcquireTokenAsync e passar nas seguintes informações:

  • URL de recurso, que é o URL do ponto final para a aplicação a ser chamada. Por exemplo, o URL de recursos para a API do Microsoft Partner Center é https://api.partnercenter.microsoft.com.
  • Credenciais de aplicação que consistem no ID de aplicação da web e chave secreta.
  • O token refresh

O token de acesso resultante permitirá que a aplicação faça chamadas para APIs que são mencionadas no recurso. O pedido não pode solicitar um sinal de acesso para APIs que não tenham sido autorizados como parte do pedido de consentimento. O valor do atributo UserPrincipalName (UPN) é o nome de utilizador Azure AD para as contas do utilizador.

Considerações adicionais

Acesso condicional

Quando se trata de gerir os seus recursos na nuvem, um aspeto chave da segurança na nuvem é a identidade e o acesso. Num mundo “mobile-first, cloud-first”, os utilizadores podem aceder aos recursos da sua organização com diversos dispositivos e aplicações em qualquer local. Concentrar-se simplesmente em quem pode aceder a um recurso já não é suficiente. Para dominar o equilíbrio entre segurança e produtividade, também é necessário considerar como um recurso é acedido. Ao utilizar o acesso condicional Azure AD, pode endereçar este 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 mais informações, consulte o que é o acesso condicional em Azure Ative Directory?

Restrições baseadas na gama IP

Pode restringir as fichas a serem emitidas apenas para uma gama específica de endereços IP. Esta funcionalidade ajuda a restringir a área de ataque à superfície de ataque apenas a uma rede específica.

Autenticação multifator

A aplicação da autenticação de vários fatores ajuda a restringir as situações de compromisso credenciais, impondo a verificação de credenciais a duas ou mais formas. Esta funcionalidade permite ao Azure AD validar a identidade do chamador através de canais secundários seguros, como telemóveis ou e-mails, antes de emitir fichas.

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

Passos seguintes