Compartilhar via


Controle de acesso do Microsoft 365 para engenheiro de serviço

O ZSA (Acesso Permanente Zero) significa que o pessoal da equipe de serviço da Microsoft não tem acesso privilegiado permanente ao ambiente de produção do Microsoft 365 ou aos dados do cliente. Quando um membro da equipe de serviço da Microsoft deseja atualizar o serviço ou acessar dados do cliente por qualquer motivo, ele deve enviar uma solicitação justificando a necessidade e receber aprovação de um gerenciador autorizado. Em escala, não é viável fornecer e remover manualmente o acesso conforme necessário para manter os serviços do Microsoft 365, portanto, a Microsoft desenvolveu uma solução automatizada para gerenciar o acesso privilegiado conforme necessário.

Lockbox

Todo o acesso aos sistemas e dados do cliente do Microsoft 365 é intermediado pelo Lockbox, um sistema de controle de acesso que usa um modelo JIT (Just-In-Time) e just-enough-access (JEA) para fornecer aos engenheiros de serviço acesso privilegiado temporário a serviços e dados especificados do Microsoft 365. Além disso, todas as solicitações e ações são registradas para fins de auditoria e são acessíveis usando a API de Atividade de Gerenciamento Office 365 e a Central de Segurança e Conformidade.

Antes que um engenheiro de serviço da Microsoft possa se conectar a qualquer sistema do Microsoft 365 ou acessar dados do cliente, ele deve enviar uma solicitação de acesso por meio do Lockbox. Essa solicitação só poderá ser aprovada se determinados critérios forem atendidos:

  • O engenheiro de serviço atende aos requisitos de qualificação de uma conta de equipe de serviço,
  • Eles pertencem à função Lockbox associada ao trabalho na solicitação,
  • O tempo de acesso solicitado não excede o tempo máximo permitido,
  • Eles têm uma justificativa comercial legítima,
  • O recurso solicitado que eles desejam acessar está dentro de seu escopo de trabalho e
  • Eles recebem aprovação do gerente

Depois que todos os critérios forem atendidos e verificados pelo Lockbox, o acesso temporário será concedido para executar a ação específica solicitada. Depois que o tempo da solicitação tiver decorrido, o acesso será revogado.

Fluxo de caixa de bloqueio.

Além disso, se um cliente licenciar e habilitar o recurso Customer Lockbox , qualquer tentativa de um engenheiro de serviço da Microsoft para acessar dados do cliente deverá ser aprovada adicionalmente por um administrador no locatário do cliente. A necessidade de acessar dados do cliente pode surgir tanto do cliente quanto da Microsoft. Por exemplo, um incidente gerado por um cliente pode exigir acesso aos seus dados para corrigir o problema ou quando a Microsoft precisa de acesso a dados para aplicar uma atualização específica.

Os clientes não têm ferramentas para iniciar uma solicitação de Caixa de Bloqueio do Cliente; eles devem enviar um tíquete para a Microsoft que requer que uma solicitação de Caixa de Bloqueio do Cliente seja levantada. Uma solicitação de Caixa de Bloqueio do Cliente levantada por um engenheiro de serviço da Microsoft deve ser aprovada por um Microsoft Manager e um administrador autorizado no locatário do cliente.

Fluxo de caixa de bloqueio do cliente.

Funções lockbox

Para impor a separação de tarefas e o princípio de menor privilégio, os engenheiros de serviço devem pertencer a uma função lockbox que corresponda à sua função na equipe. As funções lockbox são gerenciadas dentro da ferramenta Gerenciamento de Identidade e definem os privilégios e as ações para as quais um membro da equipe de serviço pode ser aprovado por meio do processo de solicitação do Lockbox. O pessoal da equipe de serviço deve solicitar ser membro de uma função lockbox e receber aprovação gerencial. Se aprovada, a conta da equipe de serviço do funcionário será colocada em um grupo de segurança imposto pelo Active Directory (AD) e Microsoft Entra ID.

Interfaces de gerenciamento restritas

Os engenheiros de serviço usam duas interfaces de gerenciamento para executar tarefas administrativas: a Área de Trabalho Remota de uma SAW (Estação de Trabalho de Segurança Administração) por meio de um TSG (Terminal Service Gateway) protegido e o PowerShell Remoto. Dentro dessas interfaces de gerenciamento, os controles de acesso com base na solicitação de Lockbox aprovada e nas políticas de software colocam restrições significativas sobre quais aplicativos são executados e quais comandos e cmdlets estão disponíveis.

Área de Trabalho Remota

Os membros da equipe de serviço que administram seu serviço usando a Área de Trabalho Remota devem se conectar a partir de um LAPTOPS SAW, especialmente projetados e fabricados gerenciados pela Microsoft especificamente para este caso de uso. A Microsoft faz parcerias com fornecedores para criar SAWs, criando uma cadeia de suprimentos curta e segura. Os SAWs usam sistemas operacionais endurecidos que são configurados para limitar todas as funcionalidades, exceto o necessário para tarefas de gerenciamento definidas. Essas limitações incluem desabilitar todas as portas USB, listas estritas de acesso ao aplicativo, remoção do acesso por email, limitar a navegação na Internet e impor bloqueios de protetor de tela de inatividade. Os sistemas de controle de acesso da Microsoft examinam os computadores SAW periodicamente para garantir que eles estejam em conformidade com os controles de segurança mais recentes e desabilitar automaticamente os computadores se eles estiverem determinados a não estar em conformidade.

Engenheiros de serviço só têm permissão para se conectar a um TSG por vez e várias sessões não são permitidas. No entanto, os TSGs permitem que os administradores da equipe de serviço do Microsoft 365 se conectem a vários servidores, cada um com apenas uma sessão simultânea, para que os administradores possam executar efetivamente suas funções. Os administradores da equipe de serviço não têm permissões nos próprios TSGs. O TSG é usado apenas para impor requisitos de autenticação multifator (MFA) e criptografia. Depois que o administrador da equipe de serviço se conecta a um servidor específico por meio de um TSG, o servidor específico impõe um limite de sessão de um por administrador.

Restrições de uso, conexão e requisitos de configuração para o pessoal do Microsoft 365 são estabelecidos pelas políticas de grupo do Active Directory. Essas políticas incluem as seguintes características de TSG:

  • Usar apenas a criptografia validada fips 140-2
  • Sessões desconectadas após 15 minutos de inatividade
  • As sessões saem automaticamente após 24 horas

As conexões com TSGs também exigem MFA usando uma cartão inteligente física separada. Engenheiros de serviço são emitidos cartões inteligentes diferentes para várias plataformas e plataformas de gerenciamento de segredos garantem o armazenamento seguro de credenciais. Os TSGs usam políticas de grupo do Active Directory para controlar quem pode fazer logon em servidores remotos, o número de sessões permitidas e as configurações de tempo limite ocioso.

PowerShell Remoto

Além do acesso remoto usando TSGs especialmente configurados, o pessoal da equipe de serviço com a função Lockbox de Operações do Engenheiro de Serviço pode acessar determinada funcionalidade administrativa em servidores de produção usando o PowerShell Remoto. Para usar esse acesso, o usuário deve ser autorizado para acesso somente leitura (depuração) ao ambiente de produção do Microsoft 365. O escalonamento de privilégios está habilitado da mesma forma que está habilitado para TSGs usando o processo lockbox.

Para acesso remoto, cada datacenter tem um IP virtual balanceado por carga que serve como um único ponto de acesso. Os cmdlets do PowerShell Remoto disponíveis baseiam-se no nível de privilégio identificado na declaração de acesso obtida durante a autenticação. Esses cmdlets fornecem a única funcionalidade administrativa acessível pelos usuários que se conectam usando esse método. O PowerShell Remoto limita o escopo dos comandos disponíveis para o engenheiro e se baseia no nível de acesso concedido por meio do processo lockbox. Por exemplo, em Exchange Online, o cmdlet Get-Mailbox pode estar disponível, mas o cmdlet Set-Mailbox não.

Recursos