Compartilhar via

Requisitos de segurança para usar o Partner Center ou as APIs do Partner Center

  • Artigo

Funções apropriadas: todos os usuários do Partner Center

Como consultor, fornecedor de painel de controle ou parceiro CSP (Provedor de Soluções na Nuvem), você tem decisões a tomar em relação às opções de autenticação e outras considerações de segurança.

A segurança e as proteções de privacidade para você e seus clientes estão entre nossas principais prioridades. Sabemos que a melhor defesa é a prevenção e que somos tão fortes quanto nosso vínculo mais fraco. É por isso que precisamos de todos em nosso ecossistema para garantir que as proteções de segurança apropriadas estejam em vigor.

Requisitos de segurança obrigatórios

O programa CSP permite que os clientes comprem produtos e serviços da Microsoft por meio de parceiros. De acordo com o contrato deles com a Microsoft, é necessário que os parceiros gerenciem o ambiente e forneçam suporte para os clientes para os quais eles vendem.

Os clientes que compram por meio desse canal confiam em você como parceiro porque você tem acesso de administrador de alto privilégio ao locatário do cliente.

Os parceiros que não implementarem os requisitos de segurança obrigatórios não poderão fazer transações no programa de CSP nem gerenciar locatários de clientes que utilizam direitos de administrador delegado. Além disso, os parceiros que não implementam os requisitos de segurança podem colocar em risco sua participação em programas.

Os termos associados aos requisitos de segurança do parceiro foram adicionados ao Contrato de Parceiro da Microsoft. O MPA (Contrato de Parceiro da Microsoft) é atualizado periodicamente e a Microsoft recomenda que todos os parceiros verifiquem regularmente. Como ele é relacionado aos consultores, os mesmos requisitos contratuais estarão em vigor.

Todos os parceiros são obrigados a aderir às melhores práticas de segurança para que possam proteger ambientes de parceiros e clientes. A adesão a essas práticas recomendadas ajuda a mitigar problemas de segurança e corrigir escalonamentos de segurança, garantindo que a confiança do cliente não seja comprometida.

Para proteger você e seus clientes, exigimos que os parceiros tomem as seguintes medidas imediatamente:

Habilitar a MFA em todas as contas de usuário no seu locatário de parceiro

Você precisa impor a MFA em todas as contas de usuário no seu locatário de parceiro. Os usuários precisam passar pela MFA ao entrarem nos serviços de nuvem comercial da Microsoft ou ao realizarem transações no programa Provedor de Soluções na Nuvem por meio do Partner Center ou de APIs.

A imposição da MFA segue estas diretrizes:

  • Parceiros que usam a autenticação multifator do Microsoft Entra com suporte da Microsoft. Para obter mais informações, consulte Várias maneiras de habilitar a autenticação multifator do Microsoft Entra (MFA com suporte)
  • O parceiro que implementou qualquer MFA de terceiros e parte da lista de exceções ainda pode acessar o Partner Center e as APIs com exceções, mas não pode gerenciar o cliente usando o DAP/GDAP (sem exceções permitidas)
  • Se a organização do parceiro tiver recebido anteriormente uma exceção para MFA, os usuários que gerenciam locatários do cliente como parte do programa CSP deverão ter habilitado os requisitos do Microsoft MFA antes de 1º de março de 2022. O não cumprimento dos requisitos de MFA pode resultar na perda do acesso do locatário do cliente.
  • Saiba mais sobre como exigir a MFA (autenticação multifator) para seu locatário parceiro.

Adotar a estrutura do Modelo de Aplicativo Seguro

Todos os parceiros que integram as APIs do Partner Center precisam adotar a estrutura do Modelo de Aplicativo Seguro em qualquer aplicativo e aplicativos de modelo de autenticação de usuário.

Importante

É altamente recomendável que os parceiros implementem o Modelo de Aplicativo Seguro para integrar com uma API da Microsoft, como Azure Resource Manager, Microsoft Graph ou aproveitem a automação, como o PowerShell, usando as credenciais do usuário, para evitar qualquer interrupção quando a MFA é imposta.

Esses requisitos de segurança ajudam a proteger sua infraestrutura e proteger os dados de seus clientes contra possíveis riscos de segurança, como roubo de identidade ou outros incidentes de fraude.

Outros requisitos de segurança

Os clientes confiam em você como parceiro deles para fornecer serviços com valor agregado. É imperativo que você tome todas as medidas de segurança para proteger a confiança do cliente e sua reputação como parceiro.

A Microsoft continua a adicionar medidas de imposição para que todos os parceiros sejam obrigados a aderir e priorizar a segurança de seus clientes. Esses requisitos de segurança ajudarão a proteger a sua infraestrutura e a proteger os dados dos seus clientes contra possíveis riscos de segurança, como identificar roubos ou outros incidentes de fraude.

O parceiro é responsável por garantir que ele esteja adotando os princípios de confiança zero, especificamente o seguinte.

DAP (privilégios de administrador delegado)

Os DAP (privilégios de administrador delegado) fornecem a capacidade de gerenciar o serviço ou a assinatura de um cliente em seu nome. O cliente deve conceder ao parceiro permissões administrativas para esse serviço. Como os privilégios fornecidos ao parceiro para gerenciar o cliente são altamente elevados, a Microsoft recomenda que todos os parceiros removam DAPs inativos. Todos os parceiros que gerenciam o locatário do cliente usando Privilégios de Administrador Delegado devem remover o DAP inativo do Partner Center para evitar qualquer impacto no locatário do cliente e em seus ativos.

Para obter mais informações, consulte o Guia de monitoramento de relações administrativas e remoção de DAP de autoatendimento, as perguntas frequentes sobre privilégios de administração delegada e o guia de privilégios administrativos delegados de direcionamento NOBELIUM.

Além disso, o DAP será preterido em breve. Incentivamos fortemente todos os parceiros que estão usando ativamente o DAP para gerenciar seus locatários de clientes e avançar para um modelo de privilégios mínimos de privilégios delegados granulares para gerenciar com segurança os locatários de seus clientes.

Transição para funções de privilégios mínimos para gerenciar locatários de cliente

Como o DAP será preterido em breve, a Microsoft recomenda se afastar do modelo DAP atual (que dá aos agentes de administração acesso de administrador global permanente ou perpétuo) e substituí-lo por um modelo de acesso delegado refinado. O modelo de acesso delegado refinado reduz os riscos de segurança para os clientes e os efeitos desses riscos sobre eles. Ele também oferece controle e flexibilidade para restringir o acesso por cliente no nível de carga de trabalho dos funcionários que estão gerenciando os serviços e ambientes de seus clientes.

Para obter mais informações, consulte a Visão geral dos GDAP (privilégios de administrador delegado granular), informações sobre funções com privilégios mínimos e as Perguntas frequentes sobre os GDAP

Fique atento às notificações sobre fraude do Azure

Como parceiro no programa do CSP, você é responsável pelo consumo do Azure por parte do seu cliente, portanto, é importante estar ciente de quaisquer atividades potenciais de mineração de criptomoeda nas assinaturas do Azure dos seus clientes. Essa atenção permite que você tome medidas imediatas para determinar se o comportamento é legítimo ou fraudulento e, se necessário, suspender os recursos afetados do Azure ou a assinatura do Azure para atenuar o problema.

Para obter mais informações, consulte a Detecção e notificação de fraude do Azure.

Inscreva-se no Microsoft Entra ID P2

Todos os Agentes Administrativos no locatário do CSP devem fortalecer sua segurança cibernética implementando a ID P2 do Microsoft Entra e aproveitar os vários recursos para fortalecer seu locatário do CSP. O Microsoft Entra ID P2 fornece acesso estendido a logs de entrada e recursos premium, como o Microsoft Entra Privileged Identity Management (PIM) e recursos de Acesso Condicional baseados em risco para fortalecer os controles de segurança.

Aderir às melhores práticas de segurança do CSP

É importante seguir todas as melhores práticas do CSP para segurança. Saiba mais em Melhores Práticas de segurança do Provedor de Soluções na Nuvem.

Implementando a autenticação multifator

Para atender aos requisitos de segurança do parceiro, você precisa implementar e impor a MFA para cada conta de usuário no seu locatário do parceiro. É possível fazer isso das seguintes maneiras:

Padrões de segurança

Uma das opções que os parceiros podem escolher para implementar os requisitos de MFA é habilitar os padrões de segurança na ID do Microsoft Entra. Os padrões de segurança oferecem um nível básico de segurança sem nenhum custo adicional. Examine como habilitar a MFA para sua organização com a ID do Microsoft Entra e as principais considerações abaixo antes de habilitar os padrões de segurança.

  • Os parceiros que já adotaram políticas de linha de base precisam tomar medidas para fazer a transição para os padrões de segurança.
  • Os padrões de segurança são a substituição de disponibilidade geral das políticas de linha de base de versão prévia. Depois que um parceiro habilita os padrões de segurança, ele não pode habilitar as políticas de linha de base.
  • Com padrões de segurança, todas as políticas são habilitadas de uma só vez.
  • Para parceiros que usam acesso condicional, os padrões de segurança não estão disponíveis.
  • Os protocolos de autenticação herdados são bloqueados.
  • A conta de sincronização do Microsoft Entra Connect é excluída dos padrões de segurança e não será solicitada a se registrar ou executar a autenticação multifator. As organizações não devem usar essa conta para outros fins.

Para obter informações detalhadas, consulte Visão geral da autenticação multifator do Microsoft Entra para sua organização e O que são padrões de segurança?.

Observação

Os padrões de segurança do Microsoft Entra são a evolução das políticas de proteção de linha de base simplificadas. Se você já tiver habilitado as políticas de proteção de linha de base, é altamente recomendável habilitar os padrões de segurança.

FAQ (Perguntas Frequentes) sobre implementação

Como esses requisitos se aplicam a todas as contas de usuário no seu locatário do parceiro, há várias considerações que precisam ser feitas para garantir uma implantação tranquila. Por exemplo, identifique contas de usuário na ID do Microsoft Entra que não podem executar MFA e aplicativos e dispositivos em sua organização que não dão suporte à autenticação moderna.

Antes de executar qualquer ação, recomendamos que você conclua as seguintes validações.

Você tem um aplicativo ou dispositivo que não dá suporte ao uso de autenticação moderna?

Quando você impõe a MFA, a autenticação herdada usa protocolos como IMAP, POP3, SMTP e outros que são bloqueados porque não dão suporte à MFA. Para resolver essa limitação, use o recurso de senhas de aplicativo para garantir que o aplicativo ou dispositivo ainda seja autenticado. Examine as considerações para usar senhas de aplicativo a fim de determinar se elas podem ser usadas no seu ambiente.

Você tem usuários do Office 365 com licenças associadas ao seu locatário do parceiro?

Antes de implementar qualquer solução, recomendamos que você determine quais versões dos usuários do Microsoft Office em seu locatário de parceiro estão usando. Há uma chance de que os usuários tenham problemas de conectividade com aplicativos como o Outlook. Antes de impor a MFA, é importante confirmar que você está usando o Outlook 2013 SP1 ou posterior e que a sua empresa tem a autenticação moderna habilitada. Para obter mais informações, confira Habilitar a autenticação moderna no Exchange Online.

Para habilitar a autenticação moderna para dispositivos que executam o Windows que têm o Microsoft Office 2013 instalado, você deve criar duas chaves do Registro. Consulte Habilitar a autenticação moderna para o Office 2013 emdispositivos Windows.

Há uma política que impede que qualquer usuário use seus dispositivos móveis enquanto trabalha?

É importante identificar toda política corporativa que impede que os funcionários usem dispositivos móveis enquanto trabalham, porque isso influenciará qual solução de MFA você implementará. Existem soluções, como a fornecida por meio da implementação de padrões de segurança do Microsoft Entra, que permitem apenas o uso de um aplicativo autenticador para verificação. Caso sua empresa tenha uma política que impeça o uso de dispositivos móveis, considere uma das seguintes opções:

  • Implantar um aplicativo com senha TOTP (senha única baseada em tempo) que pode ser executado no sistema seguro.

Qual automação ou integração você tem para usar as credenciais do usuário para autenticação?

A imposição de MFA para cada usuário, incluindo contas de serviço, em seu diretório de parceiros, pode afetar qualquer automação ou integração que use credenciais de usuário para autenticação. Assim, é importante que você identifique quais contas estão sendo usadas nessas situações. Consulte a seguinte lista de aplicativos de exemplo ou serviços a serem considerados:

  • Painel de controle usado para provisionar recursos em nome de seus clientes
  • Integração com qualquer plataforma usada para faturamento (pois está relacionada ao programa CSP) e suporte aos seus clientes
  • Scripts do PowerShell que usam o Az, AzureRM, Microsoft Graph PowerShell e outros módulos

A lista anterior não é abrangente, portanto, é importante que você execute uma avaliação completa de qualquer aplicativo ou serviço em seu ambiente que use credenciais de usuário para autenticação. Para lidar com o requisito de MFA, você deve implementar a orientação na estrutura de Modelo de Aplicativo Seguro , sempre que possível.

Acessando seu ambiente

Para entender melhor o que ou quem está autenticando sem ser desafiado pela MFA, recomendamos que você examine a atividade de entrada. Por meio da ID P1 ou P2 do Microsoft Entra, você pode usar o relatório de entrada. Para obter mais informações sobre esse assunto, consulte Relatórios de atividades de entrada no centro de administração do Microsoft Entra. Se você não tiver a ID P1 ou P2 do Microsoft Entra ou se estiver procurando uma maneira de obter essa atividade de entrada por meio do PowerShell, precisará usar o cmdlet Get-PartnerUserSignActivity do módulo do PowerShell do Partner Center.

Como os requisitos são impostos

Se a organização do seu parceiro recebeu anteriormente uma exceção para MFA, os usuários que gerenciam locatários do cliente como parte do programa CSP deverão ter habilitado os requisitos do Microsoft MFA antes de 1º de março de 2022. O não cumprimento dos requisitos de MFA pode resultar na perda do acesso do locatário do cliente.

Os requisitos de segurança do parceiro são impostos pela ID do Microsoft Entra e, por sua vez, pelo Partner Center, verificando a presença da declaração de MFA para identificar que a verificação de MFA ocorreu. Desde 18 de novembro de 2019, a Microsoft ativou mais proteções de segurança (anteriormente conhecidas como "imposição técnica") para locatários parceiros.

Após a ativação, os usuários no locatário do parceiro são solicitados a concluir a verificação de MFA ao executar qualquer operação de administrador em nome de (AOBO), acessar o Partner Center ou chamar APIs do Partner Center. Para obter mais informações, consulte Exigir a autenticação multifator (MFA) para o locatário do parceiro.

Os parceiros que não atenderam aos requisitos devem implementar essas medidas assim que possível para evitar qualquer interrupção nos negócios. Se você estiver usando a autenticação multifator do Microsoft Entra ou os padrões de segurança do Microsoft Entra, não precisará executar nenhuma outra ação.

Se você estiver usando uma solução de MFA de terceiros, há uma chance de que a declaração de MFA não seja emitida. Se essa declaração estiver ausente, a ID do Microsoft Entra não poderá determinar se a solicitação de autenticação foi contestada pela MFA. Para obter informações sobre como verificar se sua solução está emitindo a declaração esperada, leia Testando os requisitos de segurança do parceiro.

Importante

Se sua solução de terceiros não emitir a declaração esperada, você precisará trabalhar com o fornecedor que desenvolveu a solução para determinar quais ações devem ser tomadas.

Recursos e exemplos

Consulte os seguintes recursos para obter suporte e o código de exemplo:

Conteúdo relacionado