Partilhar via

Exigir a autenticação multifator (MFA) para o inquilino parceiro

  • Artigo

Funções apropriadas: Agente administrativo | Agente de vendas | Agente de helpdesk | Administrador de faturação | Administrador de segurança

Uma melhor segurança e salvaguardas contínuas de segurança e privacidade estão entre as nossas principais prioridades, e continuamos a ajudar os parceiros a proteger os seus clientes e inquilinos.

Para ajudar os parceiros a proteger as suas empresas e clientes contra roubo de identidade e acesso não autorizado, ativámos mais proteções de segurança para inquilinos parceiros. Estas salvaguardas impõem e verificam a MFA. Mandating MFA ajuda os parceiros a proteger seu acesso aos recursos do cliente contra comprometimento de credenciais.

Este artigo fornece exemplos detalhados e orientações para a obrigatoriedade da autenticação multifator (MFA) no Partner Center.

Os parceiros que participam no programa Provedor de Soluções na Nuvem (CSP), os Fornecedores do Painel de Controlo (CPVs) e os Consultores devem implementar os Requisitos de Segurança do Parceiro para permanecerem em conformidade.

Os parceiros são obrigados a impor MFA para todas as contas de utilizador no locatário do parceiro, incluindo utilizadores convidados. Os usuários devem concluir a verificação de MFA para as seguintes áreas:

Centro de Parceiros

Algumas páginas no Partner Center são protegidas por MFA, incluindo:

  • Todas as páginas sob a aba Clientes (ou seja, todas as páginas com um URL que começa com https://partner.microsoft.com/commerce/*)
  • Todas as páginas na aba SuporteSolicitações do Cliente (por exemplo, todas as páginas acessadas com um URL que começa com https://partner.microsoft.com/dashboard/v2/support/customers/*)
  • Todas as páginas no separador Faturação

Outras páginas do Partner Center, como a página de Visão geral e a página de verificação do estado de funcionamento do serviço, não exigem MFA.

A tabela a seguir mostra quais tipos de usuário estão autorizados a acessar essas páginas protegidas por MFA (e são afetados por esse recurso).

Página protegida por MFA Agentes administrativos Agentes de vendas Agentes do serviço de assistência Administrador de segurança Administrador de faturação
Todas as páginas sob a guia Clientes x x x
Todas as páginas na aba Suporte > Solicitações de Clientes x x
Página de faturação x x x
Espaço de trabalho de Segurança x x

Para acessar essas páginas, você deve primeiro concluir a verificação de MFA.

Opções de MFA suportadas

  • Os parceiros que usam a Microsoft oferecem suporte à autenticação multifator Microsoft Entra. Para obter mais informações, consulte Várias maneiras de habilitar a autenticação multifator do Microsoft Entra (MFA suportada)
  • Parceiros que implementaram a autenticação federada MFA integrada. Esses usuários parceiros têm permissão para acessar o Partner Center e gerenciar os clientes usando o GDAP. Veja os fornecedores de MFA integrados com ofertas de MFA disponíveis no AD FS: Configurar Métodos de AD FS.

Importante

Os parceiros são obrigados a usar um provedor de autenticação que seja compatível com a declaração de MFA integrada do Microsoft Entra ID. A declaração integrada indica o tipo de credencial real fornecido durante a autenticação. Os parceiros são obrigados a usar MFA integrado para gerenciar locatários de clientes com GDAP.

Centro de Parceiros e APIs

Para as seguintes APIs do Partner Center, o acesso App+User e o Microsoft Entra ID Support MFA são necessários:

  • Descubra (preço/catálogo/promoção)
  • Transacionar e gerenciar
  • Faturação e reconciliação
  • Gerencie clientes usando acesso delegado/AOBO
  • Atribuição de usuário e licença (somente com DAP)
  • Atribuição de usuário e licença (com GDAP)
  • Relações granulares com administradores Solicitação e atribuição de acesso

As seguintes opções estão disponíveis para parceiros:

  • Use os métodos de autenticação internos da Microsoft para satisfazer os requisitos de MFA.
  • Se estiver a usar um provedor de identidade federada, verifique se a federação está configurada para aceitar a MFA federada.
  • Se você quiser usar o ADFS para configurar o segundo fator externo, consulte os provedores de terceiros com ofertas de MFA disponíveis com o AD FS: Configurar métodos de autenticação para AD FS
  • Implementar MFA: habilite imediatamente MFA por meio de definições de segurança ou de Acesso Condicional seguindo as diretrizes de definições de segurança.

Exemplos de verificação

Para ilustrar como a verificação funciona no Partner Center, considere os exemplos a seguir.

Exemplo 1: O parceiro implementou a autenticação multifator Microsoft Entra

  1. Alejandra trabalha para um CSP chamado Contoso. A Contoso implementou a MFA para todos os seus usuários em locatário parceiro da Contoso usando a autenticação multifator do Microsoft Entra.

  2. Alejandra inicia uma nova sessão do navegador e vai para a página de visão geral do Partner Center (que não está protegida por MFA). O Partner Center redireciona Alejandra para o Microsoft Entra ID para entrar.

  3. Devido à configuração de autenticação multifator existente do Microsoft Entra pela Contoso, Alejandra precisa concluir a verificação de MFA. Após o login bem-sucedido e a verificação de MFA, Alejandra é redirecionada de volta para a página de visão geral do Partner Center.

  4. Alejandra tenta acessar uma das páginas protegidas por MFA no Partner Center. Como Alejandra concluiu a verificação de MFA durante o login mais cedo, Alejandra pode acessar a página protegida por MFA sem precisar passar pela verificação de MFA novamente.

Exemplo 2: O parceiro implementou MFA que não é da Microsoft usando a federação de identidades

  1. Prashob trabalha para um CSP chamado Wingtip. A Wingtip implementou MFA para todos os seus usuários sob locatário parceiro Wingtip usando MFA não-Microsoft, que é integrado com o Microsoft Entra ID via federação de identidade.

  2. Prashob inicia uma nova sessão do navegador e vai para a página de visão geral do Partner Center (que não é protegida por MFA). O Partner Center redireciona Prashob para o Microsoft Entra ID para entrar.

  3. Como a Wingtip federou a identidade, o Microsoft Entra ID redireciona Prashob para o provedor de identidade federada para concluir o início de sessão e a verificação de autenticação multifatores. Após a entrada bem-sucedida e a verificação de MFA, Prashob é redirecionado de volta para o Microsoft Entra ID e, em seguida, para a página inicial do Partner Center.

  4. Prashob tenta acessar uma das páginas protegidas por MFA no Partner Center. Como Prashob já concluiu a verificação de MFA durante o login anterior, ele pode acessar a página protegida por MFA sem ser obrigado a passar pela verificação de MFA novamente.

  5. Prashob então vai para a página de gerenciamento de serviços para adicionar usuários na ID do Microsoft Entra da Contoso. Como o Prashob usou o provedor de autenticação compatível com o Entra com autenticação forte, eles podem acessar o locatário do cliente sem problemas.

A recomendação para Prashob neste exemplo é usar a solução de autenticação multifator Microsoft Entra ou um provedor de autenticação compatível com Entra, para que eles possam gerenciar o locatário do cliente com êxito.

Exemplo 3: O parceiro não implementou a MFA

  1. Um parceiro CSP chamado Fabrikam ainda não implementou o MFA. A Microsoft recomenda que implementem uma solução de MFA suportada pelo Microsoft Entra ID.

  2. John trabalha para a Fabrikam. A empresa Fabrikam não implementou MFA para nenhum utilizador no âmbito do inquilino parceiro da Fabrikam.

  3. João inicia uma nova sessão do navegador e vai para a página de visão geral do Partner Center (que não está protegida por MFA). O Partner Center redireciona John para o Microsoft Entra ID para entrar.

  4. Depois de entrar com êxito, John é redirecionado de volta para a página de visão geral do Partner Center, porque ele não concluiu a verificação de MFA.

  5. João tenta acessar uma das páginas protegidas por MFA no Partner Center. Como John não concluiu a verificação de MFA, o Partner Center redireciona John para o Microsoft Entra ID para concluir a verificação de MFA. Como esta é a primeira vez que John é obrigado a completar o MFA, John também é solicitado a registar-se para o MFA. Após o registro e a verificação de MFA bem-sucedidos, John pode acessar a página protegida por MFA.

  6. Em outro dia, antes de a Fabrikam implementar o MFA para qualquer usuário, John inicia uma nova sessão do navegador e vai para a página de visão geral do Partner Center (que não é protegida por MFA). Partner Center redireciona João para o Microsoft Entra ID para iniciar sessão sem que seja solicitado MFA.

  7. João tenta acessar uma das páginas protegidas por MFA no Partner Center. Como John não concluiu a verificação de MFA, o Partner Center redireciona John para o Microsoft Entra ID para concluir a verificação de MFA. Uma vez que John registou o MFA, desta vez pedem-lhe apenas para concluir a verificação do MFA.

Exemplo 4: O parceiro implementou uma MFA não-Microsoft que não é compatível com o Microsoft Entra.

  1. Trent trabalha para um CSP chamado Wingtip. A Wingtip implementou MFA para todos os seus usuários sob locatário parceiro Wingtip usando MFA não-Microsoft em seu ambiente de nuvem com acesso condicional.

  2. Trent inicia uma nova sessão do navegador e vai para a página de visão geral do Partner Center (que não é protegida por MFA). O Partner Center redireciona Trent para o Microsoft Entra ID para entrar.

  3. Como o Wingtip usou uma integração de MFA que não é compatível com o ID do Microsoft Entra e não tem uma autenticação forte, Trent será impedido de acessar todas as páginas e APIs protegidas por MFA no Partner Center.

Como Trent está acessando as páginas protegidas por MFA, ele é obrigado a apresentar a MFA com Strong Auth para obter acesso às páginas protegidas por MFA.

Os parceiros devem usar um provedor de autenticação compatível com o ID do Microsoft Entra que ofereça suporte à declaração do método de credencial ("declaração amr" na referência de declarações de token do Access - plataforma de identidade da Microsoft, refletindo o tipo de credencial real fornecido durante a autenticação.

Recomendamos vivamente aos Parceiros CSP que implementem imediatamente o MFA compatível com o Microsoft Entra ID para aumentar a linha de base de segurança do seu inquilino.

Partner Center API

A API do Partner Center suporta autenticação somente de aplicativo e autenticação de aplicativo e usuário (aplicativo+usuário).

Quando a autenticação App+User é usada, o Partner Center requer verificação de MFA. Mais especificamente, quando um aplicativo parceiro envia uma solicitação de API para o Partner Center, ele deve incluir um token de acesso no cabeçalho de autorização da solicitação.

Nota

A framework do Modelo de Aplicações Seguras é um framework escalável para autenticar parceiros CSP e CPVs através da arquitetura MFA do Microsoft Azure ao chamar as APIs do Partner Center. Você deve implementar essa estrutura ao usar MFA na automação de serviços.

Quando o Partner Center recebe um pedido de API com um token de autenticação obtido usando a autenticação App+User, a API do Partner Center verifica a presença do valor MFA na declaração AMR (Authentication Method Reference). Você pode usar um decodificador JWT para validar se um token de acesso contém o valor de referência de método de autenticação esperado (AMR) ou não:

{
  "aud": "https://api.partnercenter.microsoft.com",
  "iss": "https://sts.windows.net/df845f1a-7b35-40a2-ba78-6481de91f8ae/",
  "iat": 1549088552,
  "nbf": 1549088552,
  "exp": 1549092452,
  "acr": "1",
  "amr": [
    "pwd",
    "mfa"
  ],
  "appid": "00001111-aaaa-2222-bbbb-3333cccc4444",
  "appidacr": "0",
  "family_name": "Adminagent",
  "given_name": "CSP",
  "ipaddr": "127.0.0.1",
  "name": "Adminagent CSP",
  "oid": "aaaaaaaa-0000-1111-2222-bbbbbbbbbbbb",
  "scp": "user_impersonation",
  "tenant_region_scope": "NA",
  "tid": "aaaabbbb-0000-cccc-1111-dddd2222eeee",
  "unique_name": "Adminagent.csp@testtestpartner.onmicrosoft.com",
  "upn": "Adminagent.csp@testtestpartner.onmicrosoft.com",
  "ver": "1.0"
}

  • Se o valor estiver presente, o Partner Center concluirá que a verificação de MFA foi concluída e processará a solicitação de API.

  • Se o valor não estiver presente, a API do Partner Center rejeitará a solicitação com a seguinte resposta:

    HTTP/1.1 401 Unauthorized - MFA required
Transfer-Encoding: chunked
Request-Context: appId=cid-v1:11112222-bbbb-3333-cccc-4444dddd5555
WWW-Authenticate: Bearer error="invalid_token"
Date: Thu, 14 Feb 2019 21:54:58 GMT

Ao chamar as APIs do Partner Center, os tokens de acesso apenas para aplicações são suportados apenas para operações que não requerem atribuições de funções GDAP num inquilino cliente.

Para saber mais sobre as práticas recomendadas, consulte Autenticação e autorização de API - Visão geral.

Administração Delegada de Parceiros

Os locatários parceiros devem usar privilégios de administrador delegado granular (GDAP) para gerenciar recursos do cliente por meio de portais do Microsoft Online Services (portal.azure.com ou admin.microsoft.com), interface de linha de comando (CLI) e APIs (usando autenticação App+User). Para mais informações, ver Opções de MFA suportadas.

Usando portais de serviço

Os Parceiros CSP podem administrar os seus clientes a partir do portal do Centro de Parceiros através da interface de Gestão de Serviços. Os parceiros podem navegar até o cliente e selecionar Gerenciamento de serviços para poder administrar um serviço específico para o cliente. Os parceiros devem seguir as orientações da função GDAP para obter a função GDAP adequada de privilégios mínimos para gerir os seus clientes.

Ao aceder aos portais do Microsoft Online Services usando privilégios de administrador delegado de parceiro (Admin-On-Behalf-Of) para gerir recursos do cliente, muitos desses portais exigem que a conta de parceiro se autentique interativamente, com o inquilino do Microsoft Entra do cliente definido como o contexto de autenticação. A conta de parceiro é necessária para iniciar sessão no locatário cliente.

A autenticação do ID do Microsoft Entra exige que um utilizador conclua a verificação de MFA se houver uma política que a exija. Há duas experiências de usuário possíveis, dependendo se a conta de parceiro é uma identidade gerenciada ou federada:

  • Se a conta de parceiro for uma identidade gerida, o Microsoft Entra ID solicita diretamente que o utilizador conclua a verificação MFA. Se a conta de parceiro não tiver registado para MFA com antecedência no Microsoft Entra ID, será solicitado ao utilizador que conclua o registo de MFA primeiro.

  • Se a conta de parceiro for uma identidade federada, a experiência dependerá de como o administrador do parceiro configurou a federação no Microsoft Entra ID. Ao configurar a federação no Microsoft Entra ID, o administrador parceiro pode indicar ao Microsoft Entra ID se o provedor de identidade federada suporta MFA ou não.

    • Em caso afirmativo, o Microsoft Entra ID redireciona o usuário para o provedor de identidade federada para concluir a verificação de MFA.
    • Caso contrário, o Microsoft Entra ID solicita diretamente que o usuário conclua a verificação de MFA. Se a conta de parceiro não tiver se registrado para MFA com o Microsoft Entra ID antes, o usuário será solicitado primeiro a concluir o registro de MFA.

A experiência geral é como o cenário em que um locatário cliente final implementou MFA para seus administradores. Por exemplo, o cliente habilitou os padrões de segurança do Microsoft Entra, o que exige que todas as contas com direitos administrativos façam login no sistema do cliente com verificação de MFA, incluindo agentes de administração e agentes de helpdesk.

Para fins de teste, os parceiros podem ativar os padrões de segurança do Microsoft Entra no inquilino do cliente e, em seguida, tentar utilizar os Privilégios de Administração Delegada Granular para Parceiros (GDAP) para aceder ao inquilino do cliente.

Nota

Nem todos os portais do Microsoft Online Service exigem contas de parceiro para entrar no locatário do cliente ao acessar os recursos do cliente usando o GDAP. Em vez disso, alguns exigem apenas que as contas de parceiro façam login no inquilino parceiro. Um exemplo é o Centro de Administração do Exchange. Com o tempo, esperamos que esses portais exijam que as contas de parceiros iniciem sessão no cliente tenant ao usar o GDAP.

Experiência de registo MFA

Durante a verificação de MFA, se a conta de parceiro não tiver se registrado para MFA antes, o Microsoft Entra ID solicitará que o usuário conclua o registro de MFA primeiro.

Consulte mais informações sobre o método Microsoft Authenticator:

Screenshot of the first step in MFA registration.Captura de ecrã da primeira etapa no registo de MFA.

Após o utilizador selecionar Avançar, é-lhe pedido que escolha de uma lista de métodos de verificação.

Screenshot of the second step in MFA registration.Captura de ecrã da segunda etapa no registo de autenticação multifator (MFA).

Após o registro bem-sucedido, o usuário deve concluir a verificação de MFA usando o método de verificação escolhido.

Problemas comuns

Para entender se sua solicitação é válida, revise a lista de problemas comuns relatados por outros parceiros.

Problema 1: O parceiro precisa de mais tempo para implementar o MFA para seus agentes parceiros

Um parceiro não iniciou ou ainda está no processo de implementação do MFA para seus agentes parceiros que precisam de acesso aos Portais do Microsoft Online Services usando privilégios de administração delegada de parceiro para gerenciar recursos do cliente. O parceiro precisa de mais tempo para concluir a implementação da AMF. Trata-se de uma razão válida para uma exceção técnica?

Resposta: Não. Um parceiro precisa planejar a implementação de MFA para seus usuários para evitar interrupções.

Nota

Mesmo que um parceiro não tenha implementado a MFA para seus agentes parceiros, os agentes parceiros ainda podem acessar portais do Microsoft Online Services usando Privilégios de Administração Delegada de Parceiro se puderem concluir o registro de MFA e a verificação de MFA quando solicitados durante a entrada no locatário do cliente. Concluir o registo de MFA não ativa automaticamente o utilizador para MFA.

Problema 2: o parceiro não implementou o MFA porque não precisa de acesso para gerenciar clientes

Um parceiro tem alguns usuários em seus locatários parceiros que não precisam de acesso aos Portais do Microsoft Online Services para gerenciar recursos do cliente usando Privilégios de Administração Delegada de Parceiro. O parceiro está no processo de implementação do MFA para esses usuários e precisa de mais tempo para concluir. Trata-se de uma razão válida para uma exceção técnica?

Resposta: Não. Como essas contas de usuário não estão usando privilégios de administração delegada de parceiro para gerenciar recursos do cliente, elas não serão obrigadas a entrar no locatário do cliente. Eles não serão afetados pelo Microsoft Entra ID que exige verificação de MFA durante a entrada no locatário do cliente. Todos os utilizadores são obrigados a ter MFA ao aceder ao Partner Center ou às cargas de trabalho do cliente para gerir os recursos do cliente.

Problema 3: O parceiro não implementou a MFA para contas de serviço de usuário

Um parceiro tem algumas contas de usuário em seus locatários parceiros, que estão sendo usadas por dispositivos como contas de serviço. Essas contas com privilégios baixos não exigem acesso ao Partner Center nem aos Portais do Microsoft Online Services para gerenciar recursos do cliente usando privilégios de administração delegada de parceiros. Será esta uma razão válida para uma exceção técnica?

Resposta: Não. Como estas contas de utilizador não estão a utilizar privilégios de administração delegada de parceiro para gerir recursos dos clientes, não precisam de iniciar sessão no tenant do cliente. Eles não serão afetados pelo Microsoft Entra ID que exige verificação de MFA durante a entrada no locatário do cliente. Se a API ou o portal exigiu autenticação app+user, todos os usuários deverão usar MFA para autenticação.

Problema 4: O parceiro não pode implementar MFA usando o aplicativo Microsoft Authenticator

Um parceiro tem a política de "mesa limpa", que não permite que os funcionários tragam seus dispositivos móveis pessoais para sua área de trabalho. Sem acesso aos seus dispositivos móveis pessoais, os funcionários não podem instalar o aplicativo Microsoft Authenticator, que é a única verificação MFA suportada pelos padrões de segurança do Microsoft Entra. Trata-se de uma razão válida para uma exceção técnica?

Resposta: Não. O parceiro deve considerar a seguinte alternativa para que seus funcionários ainda possam concluir a verificação de MFA ao acessar o Partner Center:

  • O parceiro também pode se inscrever no Microsoft Entra ID P1 ou P2 ou usar soluções de MFA que não sejam da Microsoft compatíveis com o Microsoft Entra ID que podem fornecer mais métodos de verificação. Para saber mais, consulte em Métodos de autenticação suportados.

Problema 5: O parceiro não pode implementar MFA devido ao uso de protocolos de autenticação herdados

Um parceiro tem alguns agentes parceiros que ainda estão usando protocolos de autenticação herdados, que não são compatíveis com MFA. Por exemplo, os usuários ainda estão usando o Outlook 2010, que se baseia em protocolos de autenticação herdados. Habilitar o MFA para esses agentes parceiros interromperá o uso de protocolos de autenticação herdados. Trata-se de uma razão válida para uma exceção técnica?

Resposta: Não. Os parceiros são incentivados a se afastar do uso de protocolos de autenticação herdados devido a possíveis implicações de segurança, pois esses protocolos não podem ser protegidos com verificação de MFA e são muito mais suscetíveis ao comprometimento de credenciais. Recomendamos descontinuar qualquer autenticação herdada e usar definições de segurança predefinidas ou Acesso Condicional. Para se preparar para transitar da autenticação herdada, reveja o relatório de acessos com autenticação herdada e as orientações sobre como bloquear a autenticação herdada.

Para entender o mais recente plano de suporte à autenticação antiga para o Outlook, leia o artigo sobre a autenticação básica e o Exchange Online e siga o blog da equipa do Exchange para obter as próximas notícias.

Problema 6: O parceiro implementou um MFA que não é da Microsoft que não é reconhecido pelo Microsoft Entra ID

Um parceiro implementou MFA para seus usuários usando uma solução de MFA que não é da Microsoft. No entanto, o parceiro não consegue configurar corretamente a solução de MFA que não é da Microsoft para retransmitir para o Microsoft Entra ID que a verificação de MFA foi concluída durante a autenticação do usuário. Trata-se de uma razão válida para uma exceção técnica?

Resposta: Não, os parceiros devem usar um fornecedor de autenticação compatível com o Microsoft Entra ID que suporte a afirmação do método de credencial ("AMR"), refletem o tipo de credencial real fornecido durante a autenticação. Consulte as referências de afirmações de token de acesso na plataforma de identidade da Microsoft.

Recomendamos vivamente que implemente imediatamente o MFA compatível com o Microsoft Entra ID para aumentar a linha de base de segurança do seu inquilino.

Conteúdos relacionados