Ambiente de TI distribuído com muitos administradores no mesmo locatário Microsoft Intune

  • Artigo

Muitas organizações usam um ambiente de TI distribuído em que têm um único locatário Microsoft Intune com vários administradores locais. Este artigo descreve uma maneira de dimensionar Microsoft Intune para dar suporte a vários administradores locais que gerenciam seus próprios usuários, dispositivos e criam suas próprias políticas dentro de um único locatário Microsoft Intune. Não há resposta certa ou errada sobre quantos administradores você pode ter em seu locatário. O artigo se concentra em locatários que têm muitos administradores locais.

A TI distribuída é necessária em sistemas em que um grande número de administradores locais se conectam a um único locatário do Intune. Por exemplo, alguns sistemas escolares são organizados para que você tenha um administrador local para cada escola no sistema ou região. Às vezes, esse ambiente distribuído pode ser 15 ou mais administradores locais diferentes que rolam para o mesmo sistema central ou Microsoft Intune locatário.

Cada administrador local pode configurar grupos para atender às suas necessidades organizacionais. O administrador local normalmente cria grupos e organiza vários usuários ou dispositivos por localização geográfica, departamento ou características de hardware. Os administradores locais também usam esses grupos para gerenciar tarefas em escala. Por exemplo, os administradores locais podem definir políticas para muitos usuários ou implantar aplicativos em um conjunto de dispositivos.

Funções que você precisa saber

  • Equipe central: a equipe ou grupo central inclui os administradores globais ou administradores primários em seu locatário. Esses administradores podem supervisionar todos os administradores locais e podem fornecer diretrizes aos administradores locais.

  • Administradores locais: os administradores locais são locais e se concentram em políticas e perfis para seus locais específicos; escolas, hospitais e assim por diante.

Controle de acesso baseado em função

Esta seção descreve brevemente os diferentes modelos e propõe diretrizes em cada modelo para gerenciar políticas, perfis e aplicativos entre a equipe Central e os administradores locais. Os modelos são:

  • Modelo de delegação parcial
  • Modelo de delegação completo
  • Modelo central
  • Modelo desenvolvimentista
  • Modelo híbrido

Modelo de delegação parcial

O modelo de delegação parcial propõe as diretrizes a seguir para o gerenciamento de políticas entre a equipe central e os administradores locais.

✔️ Permissões

  • As permissões criar, atualizar e excluir para políticas, perfis de registro e aplicativos devem ser mantidas pela equipe central.
  • Conceda apenas permissões de leitura e atribuição aos administradores locais.

✔️ Reutilizar

  • Políticas, perfis de registro e aplicativos normalmente configurados devem ser disponibilizados aos administradores locais para reutilizar o máximo possível.
  • Microsoft Intune usa muitas configurações comuns que se enquadram em algumas categorias. Examine as recomendações listadas para Políticas de Proteção de Aplicativo.
  • À medida que os administradores locais estão a bordo, eles devem examinar as políticas existentes e reutilizá-las conforme necessário.

✔️ Exceções

  • A equipe central pode criar determinadas novas políticas, perfis de registro e aplicativos como exceções, quando necessário, em nome dos administradores locais. Normalmente, essas exceções incluem qualquer tipo de perfil que exija parâmetros exclusivos.

Um modelo de delegação parcial é proposto nessas duas áreas:

Diretrizes de grupo e atribuição para administradores locais: quais são algumas das melhores práticas para os administradores locais adotarem durante a organização de grupos para o gerenciamento de dispositivos por meio de Microsoft Intune? Para descobrir, leia o artigo Agrupamento, direcionamento e filtragem do Intune: Recomendações para melhor desempenho - Microsoft Tech Community

Diretrizes específicas do recurso: como as políticas/perfis/aplicativos são gerenciadas entre uma autoridade central e os administradores locais com permissões específicas para os diferentes recursos. Para obter mais informações, acesse a seção Diretrizes específicas do recurso.

Modelo de delegação completo

O modelo de delegação completo propõe as diretrizes a seguir para o gerenciamento de políticas entre a equipe central e os administradores locais.

  • Cada administrador local deve ter sua própria marca de escopo para separar cada objeto que eles gerenciam totalmente.
  • Quando o administrador local não precisar criar, atualizar ou excluir, conceda ao administrador local uma função com permissões de leitura e atribuição e evite atribuir qualquer outra função com permissão completa a eles. Com essa abordagem, você pode evitar combinar permissões entre marcas de escopo.
  • Às vezes, os administradores locais podem precisar criar suas próprias políticas, perfis e aplicativos ao compartilhar algumas políticas, perfis e aplicativos comuns. Nesses casos, crie um grupo especial e atribua as políticas, perfis e aplicativos comuns a esse grupo. Esse grupo não deve ser incluído no Grupo de Escopo para qualquer administrador local. Grupo de escopo. Essa abordagem impede que as permissões de criação, atualização e exclusão atribuídas aos administradores locais se apliquem a essas políticas, perfis e aplicativos comuns.

Modelo central

No modelo central, uma única equipe de administrador local (pai) gerencia várias organizações filho. Fatores como geografia, unidade de negócios ou tamanho podem relacionar organizações infantis.

  • Há apenas uma marca de escopo usada para cobrir todos os administradores locais gerenciados.

  • Se possível, a equipe de administrador local deve padronizar as atribuições entre os administradores locais e colocar todos os seus dispositivos em um único grupo de Microsoft Entra para atribuição. Quando não é possível criar um único grupo Microsoft Entra, a equipe de administrador local pode criar diferentes grupos de Microsoft Entra para fazer diferentes atribuições.

  • Se uma equipe de administrador local diferente gerenciar ou mover uma organização, as seguintes etapas deverão ser tomadas:

    • Todos os dispositivos e usuários da organização devem ser extraídos de grupos de Microsoft Entra comuns no escopo da equipe de administrador local original.

    • Todas as políticas/aplicativos/perfis atribuídos exclusivamente para essa organização devem ter sua marca de escopo atualizada para a nova equipe de administrador local.

Modelo desenvolvimentista

No modelo desenvolvido, vários administradores locais (crianças) são gerenciados por seu administrador local dedicado e também supervisionados por uma equipe de administrador local intermediária. Os administradores pai e filho têm suas próprias marcas de escopo para representar limites de gerenciamento.

  • Se houver menos de 50 administradores filhos, a equipe intermediária de administradores locais poderá ter acesso atribuindo todas as marcas de escopo das crianças à atribuição de função RBAC das equipes de administração locais intermediárias.
  • Se houver mais de 50 administradores filhos, a equipe intermediária de administradores locais deve receber sua própria marca de escopo para representar toda a coleção de administradores infantis que eles supervisionam.
  • As políticas recém-criadas sob as marcas de escopo do administrador infantil devem ter a marca intermediária adicionada por uma função de administrador global para impedir que a equipe de administrador local intermediária perca a visibilidade.

Modelo híbrido

No modelo híbrido, o mesmo administrador pai é usado no modelo Central e Devolved ao mesmo tempo. Não há recomendações especiais para este modelo.

Diretrizes específicas do recurso

Dependendo dos requisitos de negócios para cada recurso, as diretrizes fornecidas nesta seção podem recomendar que você crie políticas por administrador local e/ou delega as permissões necessárias para criar objetos para os administradores locais.

Observação

As diretrizes fornecidas nesta seção não abordam todos os recursos, mas abrangem apenas as áreas para as quais temos instruções especiais.

Proteção de aplicativos política

Políticas de proteção do aplicativo são regras que garantem que os dados de uma organização permanecem seguros ou contidos em um aplicativo gerenciado. Para obter mais informações, acesse Proteção de aplicativos políticas.

As diretrizes para políticas de Proteção de aplicativos são divididas entre a equipe central e os administradores locais da seguinte maneira:

Equipe central – Tarefas

  • Examine as necessidades de segurança e de negócios em toda a organização e gere um conjunto de políticas comuns de Proteção de aplicativos para administradores locais.
  • Examine as recomendações listadas para identificar quais controles de segurança são apropriados antes de criar políticas de Proteção de aplicativos.
  • Tenha um método estabelecido para que os administradores locais solicitem políticas de Proteção de aplicativos personalizadas, se necessário, para necessidades comerciais específicas em que os requisitos de negócios não possam ser alcançados com as políticas comuns existentes.
  • Para obter recomendações específicas sobre cada nível de configuração e os aplicativos mínimos que devem ser protegidos, examine a estrutura de proteção de dados usando políticas de Proteção de aplicativos, acesse Proteção de aplicativos políticas

Administradores locais – Permissões e Tarefas

  • Forneça permissões de leitura e atribuição, mas não crie, atualize, exclua permissões em Aplicativos Gerenciados para que eles não sejam capazes de criar suas próprias políticas de Proteção de aplicativos.
  • Forneça permissões de leitura e atribuição para atribuição de política de configuração de aplicativo aos seus aplicativos.
  • Forneça permissões de leitura e atribuição somente quando houver políticas de proteção diferentes para dispositivos gerenciados e dispositivos não gerenciados. Se a equipe central optar por oferecer apenas uma política para ambos, a política de configuração do aplicativo não será necessária.
  • Se a política de configuração do aplicativo for usada, é recomendável atribuir a política de configuração do aplicativo a todas as instâncias de aplicativo sem exceção.
  • Escolha entre políticas de Proteção de aplicativos comuns. Os administradores locais podem solicitar à equipe central para criar políticas personalizadas de proteção de aplicativo como uma exceção e somente se necessário.
  • Para obter mais informações, acesse Proteção de aplicativos políticas

Política de conformidade

As políticas de conformidade no Intune definem as regras e as configurações que usuários e dispositivos devem atender para estarem em conformidade. Para obter mais informações sobre políticas de conformidade, acesse Políticas de conformidade.

Equipe central

A equipe central deve criar políticas de conformidade comuns para os administradores locais escolherem e somente, se necessário, criar políticas de exceção. Para obter mais informações, acesse Políticas de conformidade. A criação de políticas inclui a criação de scripts de política de conformidade personalizados porque eles estão sujeitos à mesma escala que a política de conformidade normal.

Para obter mais informações sobre como criar uma política de conformidade, acesse Políticas de conformidade.

Administradores locais

Forneça permissões de leitura e atribuição aos administradores locais, mas não crie, atualize ou exclua permissões na política de conformidade. As permissões de leitura e atribuição permitem que elas escolham entre as políticas de conformidade comuns criadas pela equipe central e as atribuam a seus usuários e dispositivos.

Configuração do dispositivo

Nesta seção:

  • Restrições de dispositivo e configuração geral
  • Acesso a recursos
  • Anéis de atualização do Windows
  • Atualizações de recursos
  • Atualizações de qualidade

Restrições de dispositivo e configuração geral

  • Conceda permissão aos administradores locais para criar, atualizar, excluir dentro de seu próprio escopo.

  • Use o Catálogo de Configurações e as linhas de base de segurança na medida máxima possível, em vez de perfis criados na lista De perfis de configuração, para reduzir a escala no centro de administração Microsoft Intune.

  • Em geral, a equipe central deve tentar monitorar centralmente o conteúdo das configurações e substituir muitos perfis duplicados sempre que possível por um perfil compartilhado.

Acesso a recursos

O modelo de delegação completo é recomendado.

Anéis de atualização do Windows

  • Recomendamos que os anéis de atualização do Windows sejam gerenciados centralmente. A equipe central deve criar tantas políticas comuns de anel de atualização do Windows quanto precisar para dar suporte à variação dos administradores locais.
  • Os administradores locais não devem criar seus próprios anéis de atualização do Windows. Quando você delega a um grande número de administradores, o número total de objetos pode se tornar grande e difícil de gerenciar. As práticas recomendadas variam para cada recurso. Para obter mais informações, acesse anéis de atualização do Windows.

Atualizações de recursos

O modelo de delegação completo é recomendado.

Atualizações de qualidade

O modelo de delegação completo é recomendado.

Certificados

  • Recomendamos que você use permissões por meio da equipe Central para integrar/desativar conectores conforme necessário. Conectores integrados para cada administrador local para dar suporte à emissão de certificado.

  • Não conceda permissão aos administradores locais para conectores UPDATE ou DELETE.

Aplicativos

Conceda aos administradores locais permissões completas para gerenciar aplicativos na extensão de seu escopo.

Nesta seção:

  • Programa de Compra de Volume da Apple

  • Windows

  • Android

Para obter mais informações, acesse Gerenciar aplicativos.

Programa de Compra de Volume da Apple

Atualmente, não há preocupações de escala para o número com suporte de tokens do Programa de Compra de Volume. Para obter mais informações, acesse Quantos tokens posso carregar..

Windows

Android

  • Os administradores locais devem escolher entre aplicativos de loja existentes ou pedir à equipe central para adicionar novos aplicativos da loja Android. Os administradores locais não devem criar novos aplicativos de loja Android. O número total de objetos pode se tornar grande e difícil de gerenciar.

  • Os administradores locais podem criar aplicativos de linha de negócios do Android, conforme necessário, dentro do aplicativo multiplataforma, aplicativo de linha de negócios e limite de link da Web.

  • A equipe central deve adicionar aplicativos gerenciados do Google Play.

    • A equipe central só pode ver aplicativos gerenciados do Google Play disponíveis no país/região do locatário. Se a equipe central precisar de um aplicativo Gerenciado do Google Play disponível apenas em alguns países/regiões, talvez seja necessário trabalhar com o desenvolvedor do aplicativo para listá-lo corretamente.
    • A equipe central deve gerenciar todo o conteúdo relacionado a aplicativos gerenciados do Google Play, incluindo aplicativos privados, aplicativos Web e coleções. Por exemplo, se um cliente planeja usar o iframe gerenciado do Google Play para publicar aplicativos privados, ele terá que fazer isso com uma única conta de desenvolvedor de propriedade da equipe central.
    • A equipe central pode selecionar uma única marca de escopo como a marca de escopo gerenciada do Google Play. Ele tem uma lista suspensa especial na página do conector gerenciado do Google Play. A marca de escopo será aplicada a todos os aplicativos gerenciados do Google Play depois que a equipe central os adicionar ao console, mas não se aplicará retroativamente a aplicativos que já foram adicionados. É altamente recomendável que a equipe central defina a marca de escopo antes de adicionar aplicativos e atribua a cada equipe regional essa marca de escopo. Caso contrário, os administradores regionais podem não poder ver seus aplicativos gerenciados do Google Play.

  • Há suporte para apenas uma política OEMConfig por dispositivo, exceto para dispositivos Zebra. Com dispositivos Zebra, é altamente recomendável que você tenha o menor número de políticas possíveis porque o tempo para impor a política é aditivo. Por exemplo, se você atribuir seis políticas com a suposição de que elas serão camadas em cima uma da outra, levará cerca de 6X mais tempo para começar a trabalhar no dispositivo do que uma única política.

Observação

Exerça extrema consideração e cautela ao definir o modo de atualização de alta prioridade em muitos aplicativos e grupos diferentes. Isso é por vários motivos:

  • Embora muitos aplicativos possam ser definidos como modo de alta prioridade, apenas uma atualização de aplicativo pode ser instalada por vez. Uma grande atualização de aplicativo poderia potencialmente bloquear muitas atualizações menores até que o aplicativo grande seja instalado.
  • Dependendo de quando os aplicativos lançam novas atualizações, pode haver um aumento repentino no uso da rede se as versões do aplicativo coincidirem. Se Wi-Fi não estiver disponível em alguns dispositivos, também poderá haver um pico no uso de celular.
  • Embora experiências disruptivas do usuário já tenham sido mencionadas, o problema aumenta à medida que mais aplicativos são definidos como modo de atualização de alta prioridade.

Para obter mais informações sobre as preocupações de escala em relação às atualizações gerenciadas do aplicativo Google Play usando o modo de atualização de alta prioridade, acesse este artigo Techcommunity.

Perfis de registro

Nesta seção:

  • Autopilot
  • Página status de registro (ESP)
  • Gerente de negócios da Apple (ABM)
  • Perfis do Android Enterprise
  • Restrições de registro
  • Categorias de dispositivos

Autopilot

  • Conceda aos administradores locais as permissões para ler dispositivos Autopilot e carregar novos dispositivos Autopilot.
  • Os administradores locais não devem criar perfis do Autopilot. Quando você delega a um grande número de administradores, o número total de objetos pode se tornar grande e difícil de gerenciar. A melhor prática varia de acordo com a área de recurso. Para obter mais informações sobre o Autopilot, acesse Usar o Autopilot para registrar dispositivos Windows no Intune.

Página de status da inscrição

  • Os administradores locais devem selecionar entre os perfis de página status de registro existentes a serem atribuídos ou solicitar à equipe central para criar um perfil de exceção, somente se necessário.
  • Os administradores locais não devem criar perfis de página status de registro. Quando você delega a um grande número de administradores, o número total de objetos pode se tornar grande e difícil de gerenciar. A melhor prática varia de acordo com a área de recurso. Para obter informações sobre Registro status página, acesse Configurar a Página de Status de Registro.

Apple Business Manager

Se possível, os administradores locais não devem receber permissões de criar, atualizar ou excluir em perfis de registro. Se os administradores locais receberem permissões para criar perfis do Apple Business Manager, ele também lhes dará permissões de criar, atualizar e excluir no Autopilot. No entanto, os administradores locais não devem criar perfis do Autopilot.

Quando você delega a um grande número de administradores, o número total de objetos pode se tornar grande e difícil de gerenciar. A melhor prática varia de acordo com a área de recurso. Para obter mais informações, acesse Usar o Apple Business Manager para registrar dispositivos Apple no Intune.

Perfis do Android Enterprise

  • A equipe central deve criar perfis de registro de dispositivos dedicados de propriedade corporativa do Android Enterprise para cada administrador local para agrupamento de dispositivos.
  • Se possível, os administradores locais não devem receber permissões de criação, atualização ou exclusão em dispositivos Android Enterprise. Essas restrições impedem que os administradores locais modifiquem as configurações do Android Enterprise em todo o locatário e o perfil de registro totalmente gerenciado global.

Restrições de registro

  • O mesmo conjunto de permissões rege as restrições de configuração de dispositivo e registro. Quando você concede permissões para criar para a configuração do dispositivo, você também está concedendo permissões para criar para restrições de registro. No entanto, os administradores locais não devem receber permissão para criar perfis de restrição de registro. Portanto, eles devem ser instruídos a não criar novos perfis de restrições de registro.

  • As restrições de limite de dispositivo de registro definem quantos dispositivos cada usuário pode registrar. As restrições de limite de dispositivo de registro devem cobrir todos os limites possíveis de dispositivo para os administradores locais compartilharem. Para obter mais informações, acesse O que são restrições de registro.

  • A equipe central deve padronizar as restrições de tipo de dispositivo o máximo possível e adicionar novas restrições, mas apenas como exceções especiais depois que um administrador local revisou as restrições existentes.

Categorias de dispositivos

O recurso Categorias de dispositivo (categorias>de dispositivos) não tem sua própria família de permissões. Em vez disso, suas permissões são governadas pelas permissões definidas em Organização. Acesse Funções de administração > de locatário. Selecione uma função personalizada ou interna e selecione Propriedades. Aqui você pode atribuir permissões, uma delas sendo Organização. Portanto, se você precisar de permissões de leitura para categorias de dispositivo, defina permissões de leitura na Organização.

As equipes centrais podem criar categorias de dispositivo. No entanto, os administradores locais não devem ter permissão para criar, atualizar ou excluir categorias de dispositivo, pois isso exigiria conceder-lhes permissões na Organização, dando-lhes acesso a outros recursos de nível de locatário regidos por permissões da Organização.

Para obter mais informações, acesse Categorias de dispositivo.

Análise do ponto de extremidade

  • A equipe central deve criar tantas linhas de base comuns do Endpoint Analytics quanto precisar para dar suporte à variação dos administradores locais.
  • Se possível, os administradores locais não devem criar suas próprias linhas de base do Endpoint Analytics. Quando você delega a um grande número de administradores, o número total de objetos pode se tornar grande e difícil de gerenciar. A melhor prática varia de acordo com a área de recurso.
  • Para obter mais informações, acesse Configurando configurações na análise do Ponto de Extremidade.