Perguntas frequentes sobre o MAM e a proteção do aplicativo

Visão geral do MAM

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. Uma política é uma regra que o Intune impõe quando o usuário tenta acessar ou mover dados "corporativos". Ele também pode definir ações que o Intune bloqueia ou monitora enquanto o usuário está no aplicativo.

Para obter detalhes sobre cada configuração de política de proteção do aplicativo, consulte Configurações da política de proteção do aplicativo Android e configurações da política de proteção do aplicativo iOS/iPadOS.

Se você aplicar uma política de MAM ao usuário sem definir o estado de gerenciamento do dispositivo, o usuário receberá a política de MAM no dispositivo pessoal, também conhecido como BYOD (traga seu próprio dispositivo), e no dispositivo gerenciado pelo Intune. Você também pode aplicar uma política de MAM com base no estado de gerenciamento do dispositivo. Portanto, ao criar uma política de proteção de aplicativo, ao lado de Direcionar para aplicativos em todos os tipos de dispositivo, selecione Não. Escolha uma das seguintes opções:

• Aplique uma política de MAM menos rígida a dispositivos gerenciados pelo Intune e uma política de MAM mais restritiva a dispositivos não registrados no MDM.
• Aplicar uma política de MAM igualmente rigorosa a dispositivos gerenciados pelo Intune e a dispositivos não gerenciados pela Microsoft.
• Aplique uma política de MAM apenas a dispositivos não registrados.

Para obter mais informações, consulte Como monitorar políticas de proteção do aplicativo.

Qualquer aplicativo integrado ao SDK do Aplicativo Intune ou encapsulado pelo Intune App Wrapping Tool pode ser gerenciado usando políticas de proteção de aplicativo Intune. Veja a lista oficial de aplicativos gerenciados pelo Intune disponíveis para uso público.

• O usuário final deve ter uma conta do Microsoft Entra. Para obter mais informações sobre como criar usuários do Intune no Microsoft Entra ID, consulte Adicionar usuários e conceder permissão administrativa ao Intune.

• O usuário final deve ter uma licença para o Microsoft Intune atribuída à sua conta do Microsoft Entra. Para obter mais informações sobre como atribuir licenças do Intune a usuários finais, consulte Gerenciar licenças do Intune.

• O usuário final deve pertencer a um grupo de segurança direcionado por uma política de proteção de aplicativo. A mesma política de proteção de aplicativo deve ser aplicada ao aplicativo específico que está sendo usado. Proteção de aplicativos As políticas podem ser criadas e implantadas no centro de administração do Microsoft Intune. No momento, grupos de segurança podem ser criados no centro de administração do Microsoft 365.

• O usuário final deve entrar no aplicativo usando sua conta do Microsoft Entra.

A equipe de desenvolvimento do SDK do Intune testa e mantém ativamente o suporte para aplicativos criados com as plataformas nativas Android, iOS/iPadOS (Obj-C, Swift), .NET e MAUI. Alguns clientes integram com êxito o SDK do Intune a outras plataformas, como o React Native e o NativeScript. No entanto, a Microsoft não fornece diretrizes ou plug-ins para plataformas diferentes das com suporte.

O SDK do aplicativo do Intune pode usar a Biblioteca de Autenticação da Microsoft para seus cenários de autenticação e inicialização condicional. Ele também depende da MSAL para registrar a identidade do usuário no serviço MAM para gerenciamento sem cenários de registro de dispositivo.

• O usuário final deve ter o aplicativo móvel Outlook instalado em seu dispositivo.

• O usuário final deve ter uma caixa de correio e uma licença do Microsoft 365 Exchange Online vinculadas à sua conta do Microsoft Entra.

  Observação

  Atualmente, o aplicativo móvel do Outlook só dá suporte à Proteção de Aplicativo do Intune para o Microsoft Exchange Online e o Exchange Server com autenticação híbrida moderna e não dá suporte ao Exchange no Office 365 Dedicado.

• O usuário final deve ter uma licença para o Microsoft 365 Apps para Pequenos e Médios negócios ou para empresas vinculada à sua conta do Microsoft Entra. A assinatura deve incluir os aplicativos do Office em dispositivos móveis e pode incluir uma conta de armazenamento em nuvem com o armazenamento em nuvem do OneDrive e compartilhamento de arquivos para empresas. As licenças do Microsoft 365 podem ser atribuídas no Centro de Administração do Microsoft 365 seguindo estas instruções.

• O usuário final deve configurar um local gerenciado usando o salvamento granular como funcionalidade na configuração "Salvar cópias de dados da organização" da política de proteção do aplicativo. Por exemplo, se o local gerenciado for o OneDrive, o aplicativo OneDrive deverá ser configurado no aplicativo Word, Excel ou PowerPoint do usuário final.

• Se o local gerenciado for o OneDrive, será necessário direcionar o aplicativo de acordo com a política de proteção do aplicativo implantada para o usuário final.

  Observação

  No momento, os aplicativos móveis do Office dão suporte apenas ao SharePoint Online e não ao SharePoint local.

O Intune marca todos os dados no aplicativo como "corporativos" ou "pessoais". Os dados são considerados "corporativos" quando se originam de um local de negócios. Para aplicativos do Office, o Intune trata o email (Exchange) e o armazenamento em nuvem (OneDrive) como locais de negócios.

Consulte os requisitos de licença do Skype for Business. Para configurações híbridas e locais do Skype for Business (SfB), consulte Autenticação Moderna Híbrida para SfB e Exchange entra em GA e Autenticação Moderna para SfB local com o Microsoft Entra ID, respectivamente.

O suporte a várias identidades é a capacidade do SDK do aplicativo do Intune de aplicar apenas políticas de proteção de aplicativo à conta corporativa ou de estudante conectada ao aplicativo. Se uma conta pessoal estiver conectada ao aplicativo, os dados permanecerão inalterados.

O suporte a várias identidades permite que aplicativos com públicos "corporativos" e consumidores (ou seja, os aplicativos do Office) sejam lançados publicamente com recursos de proteção de aplicativo do Intune para as contas "corporativas".

Como o Outlook tem uma exibição combinada de email de emails pessoais e "corporativos", o aplicativo Outlook solicita o PIN do Intune na inicialização.

O PIN (Número de Identificação Pessoal) é uma senha usada para verificar se o usuário correto está acessando os dados da organização em um aplicativo.

O Intune solicitará o PIN do aplicativo do usuário quando o usuário estiver prestes a acessar dados "corporativos". Em aplicativos de várias identidades, como Word/Excel/PowerPoint, o usuário é solicitado a fornecer o PIN quando tenta abrir um documento ou arquivo "corporativo". Em aplicativos de identidade única, como aplicativos de linha de negócios gerenciados usando o Intune App Wrapping Tool, o PIN é solicitado na inicialização, pois o SDK do aplicativo Intune sabe que a experiência do usuário no aplicativo é sempre "corporativa".

O administrador de TI pode definir a configuração da política de proteção do aplicativo do Intune "Verificar novamente os requisitos de acesso após (minutos)" no centro de administração do Microsoft Intune. Essa configuração especifica a quantidade de tempo antes que os requisitos de acesso sejam verificados no dispositivo e a tela PIN do aplicativo seja mostrada novamente. No entanto, detalhes importantes sobre o PIN que afetam a frequência com que os usuários são solicitados são:

• O PIN é compartilhado entre aplicativos do mesmo editor para melhorar a usabilidade: No iOS/iPadOS, um PIN de aplicativo é compartilhado entre todos os aplicativos do mesmo editor de aplicativo. No Android, um PIN de aplicativo é compartilhado entre todos os aplicativos.
• O comportamento "Verificar novamente os requisitos de acesso após (minutos)" após a reinicialização do dispositivo: Um "temporizador de PIN" rastreia o número de minutos de inatividade que determinam quando mostrar o PIN do aplicativo do Intune em seguida. No iOS/iPadOS, o temporizador do PIN não é afetado pela reinicialização do dispositivo. Portanto, a reinicialização do dispositivo não tem efeito sobre o número de minutos que o usuário está inativo de um aplicativo iOS/iPadOS com a política de PIN do Intune. No Android, o temporizador do PIN é redefinido na reinicialização do dispositivo. Dessa forma, os aplicativos Android com a política de PIN do Intune provavelmente solicitarão um PIN de aplicativo, independentemente do valor de configuração "Verificar novamente os requisitos de acesso após (minutos)" após a reinicialização do dispositivo.
• A natureza contínua do temporizador associado ao PIN: Depois que um PIN é inserido para acessar um aplicativo (aplicativo A) e o aplicativo deixa o primeiro plano (foco de entrada principal) no dispositivo, o temporizador do PIN é redefinido para esse PIN. Qualquer aplicativo (aplicativo B) que compartilhe esse PIN não solicita a entrada do PIN para o usuário porque o temporizador foi redefinido. A solicitação será exibida novamente quando o valor "Verificar novamente os requisitos de acesso após (minutos)" for atendido novamente.

Em dispositivos iOS/iPadOS, aplicativos de diferentes editores podem compartilhar o mesmo PIN. No entanto, quando o valor Verificar novamente os requisitos de acesso após (minutos) for atingido, o Intune solicitará ao usuário um PIN se o aplicativo não for o foco de entrada principal. Por exemplo, um usuário tem o aplicativo A do fornecedor X e o aplicativo B do fornecedor Y, e esses dois aplicativos compartilham o mesmo PIN. O usuário está concentrado no aplicativo A (primeiro plano), e o aplicativo B está minimizado. Depois que o valor Verificar novamente os requisitos de acesso após (minutos) for atendido e o usuário alternar para o aplicativo B, o PIN será necessário.

O PIN do Intune funciona com base em um temporizador baseado em inatividade (o valor de 'Verificar novamente os requisitos de acesso após (minutos)'). Portanto, os prompts do PIN do Intune são mostrados independentemente dos prompts do PIN do aplicativo interno do Outlook e do OneDrive, que geralmente são vinculados à inicialização do aplicativo por padrão. Se o usuário recebe ambos os prompts de PIN ao mesmo tempo, o comportamento esperado é que o PIN do Intune tenha precedência.

O PIN serve para permitir que somente o usuário correto acesse os dados de sua organização no aplicativo. Portanto, um usuário final deve entrar com sua conta corporativa ou de estudante antes de definir ou redefinir o PIN do aplicativo do Intune. O Microsoft Entra ID lida com essa autenticação por meio da troca segura de tokens e não é transparente para o SDK do Aplicativo do Intune. Sob a perspectiva de segurança, a melhor maneira de proteger dados corporativos ou de estudante é criptografá-los. A criptografia não está relacionada ao PIN do aplicativo, mas é sua própria política de proteção de aplicativo.

Como parte da política de PIN do aplicativo, o administrador de TI pode definir o número máximo de vezes que um usuário pode tentar autenticar seu PIN antes do bloqueio do aplicativo. Depois que o número de tentativas for atendido, o SDK do aplicativo do Intune poderá apagar os dados "corporativos" no aplicativo.

O MAM no iOS/iPadOS dá suporte a PINs no nível do aplicativo com caracteres alfanuméricos e especiais (chamados de senha). Para impor configurações de senha, aplicativos como Word, Excel, PowerPoint, Outlook, Navegador Gerenciado e Yammer devem integrar o SDK do Aplicativo do Intune para iOS/iPadOS. Sem essa integração, o Intune não pode impor as configurações de senha para esses aplicativos. O Intune introduziu esse recurso no SDK versão 7.1.12 para iOS/iPadOS.

Para dar suporte a esse recurso e manter a compatibilidade com versões anteriores do SDK do Intune para iOS/iPadOS, a versão 7.1.12 e posterior lidam com todos os PINs (numéricos ou senha) separadamente do PIN numérico usado em versões anteriores. Portanto, se um dispositivo tiver aplicativos com SDK do Intune para versões iOS/iPadOS anteriores à 7.1.12 E posteriores à 7.1.12 do mesmo editor, ele precisará configurar dois PINs.

Dito isto, os dois PINs (para cada aplicativo) não estão relacionados de forma alguma. Eles devem aderir à política de proteção do aplicativo aplicada ao aplicativo. Dessa forma, somente se os aplicativos A e B tiverem as mesmas políticas aplicadas (em relação ao PIN), o usuário poderá configurar o mesmo PIN duas vezes.

Esse comportamento é específico ao PIN em aplicativos do iOS/iPadOS habilitados com o Gerenciamento de Aplicativo Móvel do Intune. Ao longo do tempo, à medida que os aplicativos adotam versões posteriores do SDK do Intune para iOS/iPadOS, a necessidade de definir um PIN duas vezes em aplicativos do mesmo editor se torna um problema menos significativo.

Os administradores de TI podem implantar uma política de proteção do aplicativo que exige a criptografia dos dados do aplicativo. Como parte da política, o administrador de TI também pode especificar quando o conteúdo é criptografado.

O Intune criptografa dados de acordo com a configuração da política de proteção do aplicativo para criptografia. Para obter detalhes, consulte Configurações da política de proteção do aplicativo Android e configurações da política de proteção do aplicativo iOS/iPadOS.

Somente os dados marcados como “corporativos” são criptografados, de acordo com a política de proteção do aplicativo do administrador de TI. Os dados são considerados “corporativos” quando tem como origem um local da empresa. Para aplicativos do Office, o Intune trata o email (Exchange) e o armazenamento em nuvem (OneDrive) como locais de negócios. Para aplicativos de linha de negócios gerenciados pelo Intune App Wrapping Tool, todos os dados do aplicativo são considerados "corporativos".

O Intune pode apagar dados do aplicativo de três maneiras diferentes: apagamento completo do dispositivo, apagamento seletivo para MDM e apagamento seletivo do MAM. Para obter mais informações sobre o apagamento remoto para MDM, consulte Remover dispositivos usando o apagamento ou a desativação. Para obter mais informações sobre o apagamento seletivo usando MAM, confira A ação Desativar e Como apagar apenas dados corporativos dos aplicativos.

O apagamento remove todos os dados e configurações do usuário do dispositivo , restaurando-o às configurações padrão de fábrica. O dispositivo é removido do Intune.

O apagamento seletivo para MDM remove apenas os dados da empresa do dispositivo sem afetar os dados pessoais. Para obter mais informações, consulte Remover dispositivos - desativar.

O apagamento seletivo para MAM simplesmente remove dados de aplicativo da empresa de um aplicativo. A solicitação é iniciada usando o centro de administração do Microsoft Intune. Para saber como iniciar uma solicitação de apagamento, confira Como remover apenas dados corporativos dos aplicativos.

Se o usuário estiver usando o aplicativo quando o apagamento seletivo for iniciado, o SDK do aplicativo do Intune verificará a cada 30 minutos se há uma solicitação de apagamento seletivo do serviço Intune MAM. Ele também verifica o apagamento seletivo quando o usuário inicia o aplicativo pela primeira vez e se conecta com sua conta corporativa ou de estudante.

A proteção do aplicativo Intune depende da identidade do usuário para ser consistente entre o aplicativo e o SDK do aplicativo do Intune. A única maneira de assegurar isso é por meio da autenticação moderna. Há cenários em que os aplicativos podem funcionar com uma configuração local, mas eles não são consistentes ou garantidos.

Sim! O administrador de TI pode implantar e definir a política de proteção do aplicativo para o aplicativo Microsoft Edge. O administrador de TI pode exigir que todos os links da Web em aplicativos gerenciados pelo Intune sejam abertos usando o aplicativo Microsoft Edge.

Aplicativo Portal da Empresa e Proteção de Aplicativo do Intune

As políticas de proteção de aplicativo do Intune para acesso são aplicadas em uma ordem específica em dispositivos de usuários finais à medida que tentam acessar um aplicativo de destino de sua conta corporativa. Em geral, um bloqueio teria precedência e, em seguida, um aviso dispensável. Por exemplo, se aplicável ao usuário/aplicativo em questão, uma configuração de versão de patch mínima do Android que avisa o usuário para fazer uma atualização de patch, que será aplicada após a configuração da versão de patch mínima do Android que bloqueia o acesso do usuário. Portanto, o cenário em que o administrador de TI configura a versão de patch de Android mínima 2018-03-01 e a versão de patch de Android mínima (somente Aviso) 2018-02-01, enquanto o dispositivo tentar acessar o aplicativo estava em uma versão de patch 2018-01-01, o usuário final seria bloqueado com base a configuração mais restritiva para a versão de patch de Android mínima que resulta em acesso bloqueado.

Ao lidar com diferentes tipos de configurações, um requisito de versão do aplicativo teria precedência, seguido por um requisito de versão do sistema operacional de versão de patch do Android. Em seguida, os avisos para todos os tipos de configurações na mesma ordem são verificados.

O serviço do Intune entra em contato com o Google Play em um intervalo não configurável determinado pela carga do serviço. Qualquer ação configurada pelo administrador de TI para a configuração de marca de integridade do dispositivo do Google Play será executada com base no último resultado relatado ao serviço do Intune no momento da inicialização condicional. Se o resultado de integridade do dispositivo do Google estiver em conformidade, nenhuma ação será executada. Se o resultado de integridade do dispositivo do Google não estiver em conformidade, a ação configurada pelo administrador de TI será executada imediatamente. Se a solicitação para a marca de integridade do dispositivo do Google Play falhar por qualquer motivo, o resultado em cache da solicitação anterior será usado por até 24 horas ou a próxima reinicialização do dispositivo, o que ocorrer primeiro. Nesse momento, as Políticas de Proteção de Aplicativos do Intune bloqueiam o acesso até que um resultado atual possa ser obtido.

As instruções sobre como fazer isso variam um pouco de acordo com o dispositivo. O processo geral envolve acessar a Google Play Store, clicar em Meus aplicativos e jogos e clicar no resultado do último exame de aplicativo que o levará até o menu do Play Protect. Verifique se Examinar no dispositivo se há ameaças à segurança está ativado.

O Intune aplica APIs de Integridade do Google Play para adicionar às nossas verificações de detecção de raiz existentes para dispositivos não registrados. O Google desenvolveu e manteve esse conjunto de APIs para aplicativos Android adotarem se não quiserem que seus aplicativos sejam executados em dispositivos com root. O aplicativo Android Pay incorporou isso, por exemplo. Embora o Google não compartilhe publicamente todas as verificações de detecção de raiz que ocorrem, esperamos que essas APIs detectem usuários que fizeram root em seus dispositivos. Esses usuários podem ter o acesso bloqueado ou suas contas corporativas podem ser apagadas dos aplicativos habilitados por política. 'Verificar integridade básica' informa sobre a integridade geral do dispositivo. Dispositivos desbloqueados por rooting, emuladores, dispositivos virtuais e dispositivos com sinais de falsificação apresentam falha na integridade básica. "Verificar integridade básica & dispositivos certificados" informa sobre a compatibilidade do dispositivo com os serviços do Google. Somente dispositivos não modificados que foram certificados pelo Google podem ser aprovados nessa verificação. Os dispositivos que falham incluem:

• dispositivos que apresentam falha na integridade básica
• dispositivos com um carregador de inicialização desbloqueado
• Dispositivos com uma imagem/ROM do sistema personalizada
• Dispositivos que o fabricante não solicitou ou não foi aprovado na certificação do Google
• Dispositivos com uma imagem do sistema criada diretamente de arquivos de origem do Programa de Software Livre do Android
• dispositivos com uma imagem do sistema de versão prévia beta/do desenvolvedor

Consulte a documentação do Google sobre a API Play Integrity para obter detalhes técnicos.

As verificações da API de integridade do Google Play exigem que o usuário final esteja on-line, pelo menos durante o tempo em que a "viagem de ida e volta" para determinar os resultados do atestado é executada. Se o usuário final estiver offline, o administrador de TI ainda poderá esperar que um resultado seja imposto a partir da configuração 'dispositivos desbloqueados/raizados'. Dito isso, se o usuário final estiver offline por muito tempo, o valor do "Período de carência offline" entrará em jogo e todo o acesso aos dados corporativos ou de estudante será bloqueado quando o valor do temporizador for atingido, até que o acesso à rede esteja disponível. Ativar ambas as configurações permite uma abordagem em camadas para manter os dispositivos do usuário final íntegros, o que é importante quando os usuários finais acessam dados corporativos ou de estudante no celular.

As configurações "Reproduzir veredicto de integridade" e "Verificação de ameaças em aplicativos" exigem que a versão determinada pelo Google dos Serviços do Google Play funcione corretamente. Como essas são configurações que se enquadram na área de segurança, o usuário final será bloqueado se ele for direcionado a essas configurações e não estiver atendendo à versão apropriada do Google Play Services ou não tiver acesso ao Google Play Services.

As políticas de Proteção de Aplicativo do Intune permitem controlar o acesso do aplicativo somente para o usuário licenciado do Intune. Uma das maneiras de controlar o acesso ao aplicativo é exigir uma Touch ID ou a Face ID da Apple em dispositivos com suporte. O Intune implementa um comportamento em que, se houver alguma alteração no banco de dados biométrico do dispositivo, o Intune solicitará ao usuário um PIN quando o próximo valor de tempo limite de inatividade for atingido. As alterações aos dados biométricos incluem a adição ou a remoção de uma impressão digital ou detecção facial. Se o usuário do Intune não tiver um PIN definido, ele será levado a configurar um PIN do Intune.

A intenção disso é continuar mantendo os dados da sua organização dentro do aplicativo seguros e protegidos no nível do aplicativo. Esse recurso só está disponível para iOS/iPadOS e requer a participação de aplicativos que integram o SDK do APP do Intune para iOS/iPadOS, versão 9.0.1 ou posterior. A integração do SDK é necessária para que o comportamento possa ser aplicado aos aplicativos de destino. Essa integração ocorre sem interrupção, e depende de equipes do aplicativo específico. Alguns aplicativos que participam incluem WXP, Outlook, Managed Browser e Yammer.

A política de proteção do aplicativo Intune não pode controlar a extensão de compartilhamento do iOS sem gerenciar o dispositivo. Portanto, o Intune criptografa dados "corporativos" antes de compartilhá-los fora do aplicativo. Você pode validar isso tentando abrir o arquivo "corporativo" fora do aplicativo gerenciado. O arquivo deve ser criptografado e não pode ser aberto fora do aplicativo gerenciado.

As políticas de proteção de aplicativo do Intune para acesso serão aplicadas em uma ordem específica nos dispositivos dos usuários finais à medida que eles tentam acessar um aplicativo de destino de sua conta corporativa. Em geral, uma limpeza teria precedência, seguida por um bloqueio e, em seguida, um aviso dispensável. Por exemplo, se aplicável ao usuário/aplicativo em questão, uma configuração de sistema operacional mínima do iOS/iPadOS que avisa o usuário para atualizar a versão de iOS/iPadOS, que será aplicada após a configuração de sistema operacional mínima do iOS/iPadOS que bloqueia o acesso do usuário. Portanto, no cenário em que o administrador de TI configura o sistema operacional iOS/iPadOS mínimo como 11.0.0.0 e o sistema operacional iOS/iPadOS mínimo (somente aviso) como 11.1.0.0, enquanto o dispositivo que tenta acessar o aplicativo estava no iOS/iPadOS 10, o usuário final seria bloqueado com base na configuração mais restritiva para a versão mínima do sistema operacional iOS/iPadOS que resulta em acesso bloqueado.

Ao lidar com diferentes tipos de configurações, um requisito de versão do SDK do Aplicativo do Intune teria precedência e, em seguida, um requisito de versão do aplicativo, seguido pelo requisito de versão do sistema operacional iOS/iPadOS. Em seguida, os avisos para todos os tipos de configurações na mesma ordem são verificados. Recomendamos que o requisito de versão do SDK do Aplicativo do Intune seja configurado somente sob orientação da equipe de produto do Intune para cenários essenciais de bloqueio.

Confira também

• Implantar o Intune
• Criar um plano de distribuição
• Configurações da política de gerenciamento de aplicativo móvel Android no Microsoft Intune
• Configurações de política de gerenciamento de aplicativos móveis iOS/iPadOS
• Atualização da política de políticas de Proteção de aplicativos
• Validar as políticas de proteção do aplicativo
• Adicionar políticas de configuração de aplicativo para aplicativos gerenciados sem registro de dispositivo
• Como obter suporte no Microsoft Intune