Conheça o framework ManagedApp

Olá! Sou Bob Whiteman, Senior iOS Device Management Engineer. Estou feliz em compartilhar um novo framework para tornar os apps em implantações gerenciadas mais seguros e fáceis de usar. Organizações do mundo todo usam dispositivos Apple em escritórios, lojas e escolas. Eles são usados para aprender, ensinar, trabalhar e criar. Os apps executados nesses dispositivos tornam tudo isso possível. Os administradores da organização usam os serviços de gerenciamento de dispositivos para que os funcionários tenham os apps de que precisam. As pessoas logo se tornam especialistas no uso dos apps em suas organizações. Elas geralmente configuram esses apps apenas uma vez, então essa é uma experiência nova e assustadora. Talvez seja necessário inserir um servidor, nome de usuário, senha e código de autenticação de dois fatores. Depois, elas devem acessar os ajustes do app e personalizá-las conforme os requisitos da organização. Há várias etapas, e se um problema ou erro ocorrer, bem, raramente termina bem. Elas podem desistir de usar o app por frustração. Se elas falarem com o suporte, isso desperdiçará tempo e aumentará os custos com suporte da organização. Essa organização pode até decidir abandonar o suporte ao app. Como desenvolvedor, você pode tentar melhorar essa experiência, mas isso requer esforço que não faz parte da funcionalidade principal do app. Considere tudo de que você precisa criar para tornar essa experiência perfeita. Você implementa a federação com o provedor de identidade da organização. Você cria e opera um site de configuração para que o administrador especifique a configuração que entrega aos apps executados nos dispositivos. Você integra a autoridade de certificação e a infraestrutura de autenticação da organização para que seu app se comunique com os servidores dela. Você publica variantes personalizadas do app para fornecer a identidade visual e recursos personalizados que algumas organizações exigem. E se você não precisasse fazer nada disso? Vamos eliminar essa experiência de configuração complexa. Agora, o app pode ser pré-configurado para essa organização, para esse dispositivo e para essa pessoa. Não é preciso um processo de configuração. Desde o lançamento, o app está pronto para uso. As primeiras impressões do app são muito melhores, por isso ele é mais usado. Os administradores estão mais dispostos a implantá-lo porque as pessoas gostam dele e os custos com suporte são minimizados. Então, como podemos tornar isso possível? Tenho o prazer de apresentar o framework ManagedApp. O framework ManagedApp configura automaticamente apps gerenciados e suas extensões. Os apps podem usá-lo para autenticar dispositivos e simplificar a autenticação de usuários. Usar esse framework ajuda os apps a atenderem aos altos requisitos de segurança de dados e controle de acesso.

Para isso, o framework ManagedApp permite que o administrador forneça configurações personalizadas do app e provisione senhas, certificados e identidades. Ele pode funcionar com tecnologias de gerenciamento de dispositivos, como início de sessão único extensível, atestado de dispositivo gerenciado e início de sessão único de registro. O framework ManagedApp pode fornecer quatro tipos de dados. A configuração específica são dados arbitrários compatíveis com um determinado app. Isso inclui ajustes, opções e pequenos recursos significativos para o app. Os outros três tipos são segredos: senhas, certificados e identidades. As identidades podem ser arquivos PKCS #12, identidades SCEP ou identidades ACME. As identidades ACME são compatíveis com chaves e atestados vinculados a hardware. Esses tipos de dados são armazenados com segurança e fornecidos só aos apps gerenciados ou extensões especificadas pelo administrador. O framework ManagedApp está disponível no iOS 18.4, iPadOS 18.4 e visionOS 2.4. Ele requer que o servidor MDM gerencie o app com o gerenciamento declarativo de dispositivos. Ele funciona assim que instala o app ou quando assume o gerenciamento de um app já instalado. Ele funciona com todos os tipos de registro de MDM. Ele aceita a maioria dos tipos de extensão de app, embora não funcione com extensões executadas em ambiente muito restrito. Por exemplo, uma extensão de teclado só poderá usar o framework ManagedApp se receber acesso total. Nesta sessão, vou descrever o fluxo de trabalho de desenvolvimento e implantação, explorar cenários em que o framework é útil, detalhar códigos e apresentar melhores práticas. Primeiro, como isso funciona? Começamos com um dispositivo gerenciado. O administrador usa um servidor de MDM para enviar comandos de gerenciamento e consultas para o dispositivo com o protocolo de MDM.

O administrador gerencia o app, e isso geralmente instala o app. Como parte do gerenciamento do app, o administrador especifica a configuração e segredos que o dispositivo deve disponibilizar para o app e suas extensões.

Quando iniciado, o app pede ao framework ManagedApp sua configuração e segredos e o framework entrega uma cópia ao app. O app aplica imediatamente a configuração e usa os segredos, conforme apropriado. Depois, quando quiser, o administrador pode atualizar a configuração ou os segredos. Se o app estava em execução no momento, o framework notifica o app, que aplica imediatamente as atualizações. Antes que isso aconteça, você, como desenvolvedor, deve escrever o app. Você escreve um decodificador para a configuração e escreve o código para aplicar a configuração e usar os segredos. Depois, você escreve e publica uma especificação que informa aos administradores como configurar seu app. Essa especificação detalha quais chaves e valores o app aceita na configuração, o que eles controlam, quais segredos o app espera e como eles serão usados. Isso é o que me deixa tão animado em relação a esse framework. A configuração não é especificada pela Apple, um protocolo ou um servidor de MDM. Isso a tornaria genérica em todos os apps. Não é muito útil. Você, como desenvolvedor, especifica como seu app pode ser configurado. Isso cria oportunidades. Você conhece seu app melhor do que ninguém. Você pode oferecer os modos mais eficazes, úteis e inovadores de configurar o app, potencializando-o para as organizações. O framework ManagedApp não é uma solução. É uma plataforma onde você pode facilmente criar sua solução. Com isso em mente, vamos analisar cenários em que achamos que o framework ManagedApp será útil. Há muitos cenários em que ele pode ser utilizado. Fornecer credenciais com segurança a um navegador de terceiros. Personalizar um app interno para a função da pessoa. Configurar uma extensão do Safari. Comunicações seguras entre o serviço de gerenciamento de dispositivos e seu app de gerenciamento. Darei mais detalhes sobre três desses cenários, começando pelo licenciamento. Muitas vezes, um desenvolvedor de app precisa de um jeito para que o servidor do app atribua solicitações ao cliente correto. Uma solução comum para isso é um token de licença. Quando a organização licencia o uso do servidor, o desenvolvedor emite para ela um token de licença exclusivo. O administrador usa o MDM para distribuir o token de licença para todas as instâncias do app usadas pela organização. Quando o app faz uma solicitação ao servidor, ele inclui o token de licença na solicitação. Agora o servidor sabe que deve atribuir essa solicitação à organização correta. Isso gera preocupações com a segurança. A organização deve proteger esse token conforme é armazenado e transmitido. Se alguém de fora da organização obtiver o token de licença, poderá usar o servidor. A organização pagará isso. Desenvolvedores e administradores podem usar o recurso de configuração do ManagedApp para distribuir o token a dispositivos gerenciados. No entanto, o framework ManagedApp foi projetado para proteger a configuração contra extração ou manipulação. Mais importante, o framework ManagedApp oferece uma opção melhor do que um token de licença: uma chave de licença. Esse framework pode provisionar uma identidade criptográfica para fins de licenciamento, o que é mais seguro que um token. O administrador provisiona uma identidade criptográfica no dispositivo, com seu certificado emitido pela organização ou desenvolvedor do app. A chave privada é gerada no dispositivo e nunca sai de lá, o que é mais seguro do que transmitir tokens por toda a arquitetura. O antigo recurso de configuração do ManagedApp não aceita chaves de licença. O framework ManagedApp é mais seguro e aceita identidades e extensões de app. Se o app usa a configuração do ManagedApp, mude para o framework ManagedApp. Vamos investigar as extensões de VPN. O framework ManagedApp é útil para extensões de VPN. Um servidor de VPN requer autenticação forte, garantindo que o dispositivo faça parte da organização e esteja autorizado a conectar à rede. A arquitetura é semelhante ao cenário anterior, mas a identidade é fornecida a uma extensão de VPN em vez de um app. O framework ManagedApp pode fornecer o tipo mais forte de material de autenticação que a Apple aceita. Com o Managed Device Attestation, o administrador provisiona uma chave vinculada a hardware atestada para esse dispositivo. O framework ManagedApp a disponibiliza diretamente para a extensão de VPN e apenas para ela. Ele usa essa identidade para autenticar no servidor de VPN. Isso acaba com muitas ameaças potenciais que preocupam administradores de VPN. Nosso último cenário é um provedor de identidade. Um provedor de identidade usa o início de sessão único extensível para facilitar o início de sessão em contas federadas em apps e sites. Também pode funcionar com Contas Apple federadas para tipos de registro com base em conta. Cada provedor de identidade cria o próprio protocolo de autenticação, que geralmente usa credenciais manuais. Com o framework ManagedApp, um provedor de identidade também pode incorporar outros tipos de materiais de autenticação. Pode ser uma identidade vinculada ao hardware para autenticar o dispositivo e garantir que a sessão seja iniciada em um dispositivo autorizado. Se a conta for nova, poderá ser uma senha temporária inicial para autenticação pela primeira vez. Pode ser um token ou identidade que vincula a entrada à organização. Na verdade, pode ser qualquer tipo de segredo que o provedor de identidade precise. O framework ManagedApp é compatível com todos eles. Se o provedor de identidade aceitar início de sessão único de registro, a configuração e os segredos estarão disponíveis durante o registro. Espero que agora você entenda melhor como o framework ManagedApp potencializa apps gerenciados. É hora de ver como implementá-lo no seu app. A API do framework ManagedApp se concentra em fornecer a configuração e segredos ao app da forma mais simples e segura possível. O framework tem quatro classes independentes, uma para cada tipo de dado. As três primeiras fornecem o tipo de dados integrado exato de que seu app precisa: Uma string que contém a senha, um SecCertificate ou um SecIdentity. A quarta é um pouco diferente. O provedor de configuração do ManagedApp fornece a configuração específica do app. Não há um tipo integrado para isso. Pode ser qualquer tipo de dado que o app precisa. Como desenvolvedor do app, você define a estrutura desses dados. Vou dar um exemplo de uso de configuração, depois outro usando uma identidade. Por fim, falarei sobre a publicação da especificação do app.

Começaremos com o app Landmarks. Vamos torná-lo configurável para facilitar o uso em sala de aula. O primeiro passo é decidir o que o administrador pode configurar. Essa é a visualização de coleções no app Landmarks. Vamos permitir que o administrador configure uma nova coleção. Isso permite que um professor colete os pontos de referência que os estudantes usarão na próxima aula de geografia.

No código, escreveremos uma estrutura que representa tudo o que o administrador configurou para uma instância do app. Ele tem uma propriedade somente leitura para a coleção gerenciada. O tipo de propriedade é opcional. Isso ocorre porque o app pode não ser gerenciado, o administrador pode não ter aplicado uma configuração ou o administrador aplicou uma configuração, mas não incluiu uma coleção gerenciada. A maioria das propriedades da configuração é opcional ou fornece um valor padrão.

Quando o framework ManagedApp recebe uma configuração do servidor de MDM, precisa decodificar o formato over-the-wire, então faremos com que a estrutura esteja em conformidade com Decodable. Especificamos um CodingKey para a coleção. Após aplicar a conformidade com Decodable à classe de coleção de marcos, poderíamos parar por aqui e deixar o compilador sintetizar um inicializador para a classe de configuração. No entanto, a maioria dos apps precisará de regras de validação personalizadas. Então vamos escrever um inicializador explícito aqui. É isso que temos para a classe de configuração. Então, como seu app recebe essa configuração? A API usa a concorrência do Swift, então começamos criando uma tarefa. Dentro dessa tarefa, usamos a classe ManagedAppConfigurationProvider no framework ManagedApp. O método fornece configurações usando uma sequência assíncrona. O parâmetro que você envia para o método de configurações é o tipo da estrutura de configuração. Para começar a receber configurações, use um loop for-await. A sequência assíncrona produz um opcional do tipo de configuração. Neste código, o tipo de configuração é um LandmarksManagedConfig opcional. Vamos ver como essas peças funcionam juntas, analisando os eventos que acontecem no dispositivo. Primeiro, o administrador cria uma configuração codificada e a envia para o dispositivo, que a armazena. Quando o app começa a repetir a sequência assíncrona com um loop for-await, o dispositivo envia uma cópia da configuração codificada para o método decodificador. Isso instancia sua estrutura de configuração que contém as propriedades de que o app precisa. Por fim, o framework produz essa instância para a sequência assíncrona. Depois disso, se o administrador enviar uma configuração atualizada, o processo se repetirá automaticamente. Se o app não for gerenciado, o administrador não especificar uma configuração ou a decodificação falhar, a sequência será nula. Em suma, seu app não precisa se preocupar com essas condições. Sempre que essa sequência produz um valor ou zero, essa será a configuração gerenciada atual do app. Tudo que precisamos fazer no corpo do loop for-await é copiar o valor da configuração para uma propriedade de coleção gerenciada nos dados do modelo. Como a configuração pode ser atualizada a qualquer momento, o loop for-await não tem condições de encerramento. Não se preocupe. Gerar loops infinitos não desperdiça recursos. O corpo de um loop for-await só é executado quando produz um valor. Por onde devemos começar essa tarefa? Ela pode ficar em qualquer lugar do seu app. Ela costuma ficar em um método no início do caminho de inicialização do app. No app Landmarks, vamos incorporá-la ao método loadCollections do Model Data. As coleções são carregadas logo após a inicialização do app. Adicionamos a managedCollection à visualização e pronto. É assim que fica. A visualização Coleções tem uma seção Coleção gerenciada com o título e os pontos de referência que o administrador configurou. Aqui vai um bônus. O código que já escrevemos é tudo o que precisamos para permitir atualizações. Quando o administrador altera a configuração, a visualização é atualizada para mostrar os novos pontos de referência. Vamos a um exemplo que usa identidades. Imagine que queremos permitir que o administrador adicione mais pontos de referência. Faremos o app baixar os pontos de referência de um servidor de recursos. Permitiremos que o administrador especifique o URL onde os recursos estão hospedados. Isso dá ao administrador a flexibilidade de hospedar os recursos onde precisar. Podemos adicionar facilmente um URL de recursos à configuração que desenvolvemos. E permitiremos que o administrador provisione uma identidade que o app usa para autenticar com TLS mútuo ao conectar ao servidor de recursos. Todos os três provedores secretos no framework usam esse mesmo padrão. Cada segredo tem um identificador de string. Existe um método para procurar o segredo pelo identificador. Você escolhe os identificadores compatíveis com seu app. Na maioria das vezes, você pode codificar os identificadores. Para que seu app seja notificado quando os segredos disponíveis mudarem, use um AsyncSequence. Ele produz uma matriz dos identificadores de segredos daquele tipo que estão provisionados no momento. O AsyncSequence também será útil se o app permitir uma lista dinâmica de identificadores. Quando o app Landmarks baixa recursos, não precisa dessa complexidade extra, então usaremos apenas um identificador embutido no código. O app faz uma solicitação usando a sessão de URL. Quando você implementa TLS mútuo, a maior parte do código envolvido é padrão. Queremos apenas obter a identidade, que são essas linhas no meio. Usamos o provedor de identidades ManagedApp e um identificador embutido no código para procurar uma identidade secundária. Se o administrador não fornecer uma identidade, cancelaremos o desafio. É isso. Com essas poucas linhas de código, nosso app conseguiu a identidade necessária. Não tivemos que lidar com propriedades da chave, solicitações de assinatura de certificado ou outras tarefas do provisionamento de identidade. Usamos só o que o administrador provisionou para nós. Nossa tarefa final é publicar uma especificação que explique como um administrador pode configurar o app Landmarks. Documentamos o formato da configuração. Uma maneira simples de fazer isso é fornecer um exemplo. Aqui está um exemplo do formato codificado para a configuração. O formato over-the-wire para configurações é uma lista de propriedades. A especificação precisa documentar os detalhes, como a lista de valores válidos para IDs de ponto de referência. Se o decodificador tiver validação personalizada, documentaremos os possíveis códigos de erro dele para que os administradores diagnostiquem problemas nas configurações criadas. Documentamos os identificadores de segredos compatíveis com nosso app. Para o app Landmarks, esse é o identificador embutido no código que usamos antes. Documentamos que ele é usado para baixar recursos. Esse é um bom lugar para documentar o formato esperado dos recursos do Landmark. Publicamos essas informações normalmente na forma de documento ou site que os administradores podem acessar. E está pronto. Existem melhores práticas que você deve lembrar ao desenvolver seu app. A configuração não se destina a grandes movimentos de dados. Pense em kilobytes, não em megabytes. Faça com que o app baixe os dados de um servidor e especifique o URL na configuração, como fizemos antes com o app Landmarks. Não guarde segredos por mais tempo do que o necessário. Basta procurar o segredo cada vez que precisar. Além de ser uma melhor prática para programação segura, também garante que o app sempre use o segredo mais recente caso o administrador o atualize. Ao projetar sua configuração, não tenha apenas um controle para saber se o app é gerenciado, o que altera vários comportamentos no app. Forneça opções de configuração individuais, em que cada uma controla uma parte do comportamento do app. Isso oferece maior flexibilidade aos administradores. Considere a compatibilidade retroativa e futura. Ao lançar novas versões do app, você poderá adicionar, alterar ou remover opções na configuração. Seria difícil para um administrador fornecer configurações diferentes para versões diferentes do seu app. Para evitar isso, garanta que o decodificador lide com configurações mais antigas e ignore novas chaves que não reconhece. Isso permite que o administrador forneça uma configuração para toda a frota de dispositivos. Se o seu app está usando o antigo recurso de configuração de ManagedApp, é hora de fazer a transição. Durante essa transição, seu app pode aceitar ambos os recursos, priorizando a configuração do framework ManagedApp. Assim, um administrador pode mudar para o framework ManagedApp sem problemas. Quando você envia seu app para revisão, o revisor testa os recursos dele. Se alguns recursos só estiverem acessíveis quando o app for gerenciado e a configuração ou os segredos forem aplicados, talvez o revisor não consiga revisar o app. Há algumas maneiras de resolver isso. Considere adicionar um modo de demonstração ao app, que mostra a funcionalidade como se tivesse uma configuração. Isso também pode ser útil para demonstrar seu app aos clientes. Outra opção é gravar um vídeo do seu app mostrando esses recursos. Você pode enviar isso para a App Store Connect, em Notes for App Review. E prepare-se para fornecer instruções e credenciais que permitam ao revisor registrar seu dispositivo com um serviço de gerenciamento de dispositivos que configure o app adequadamente. Acima de tudo, use sua criatividade. Pense em como o framework ManagedApp pode deixar todos empolgados com a facilidade de usar seu app. Converse com os clientes sobre o que eles querem. Adote o framework e descontinue o uso da configuração do ManagedApp. Envie qualquer comentário que tiver sobre o framework. Para obter mais informações sobre o gerenciamento de dispositivos, confira a sessão "Novidades no gerenciamento de dispositivos Apple". Obrigado. Tenha uma ótima WWDC.