Segurança móvel

Saiba mais sobre os recursos de segurança do ServiceNow Mobile plataforma.

Arquitetura ServiceNow Mobile

ServiceNow Mobile os aplicativos consistem em ServiceNow instância do servidor e aplicativos nativos para iOS e. Android. Os aplicativos usam código nativo completo e não são uma abordagem híbrida. Os aplicativos para celular transmitem e recebem dados com o servidor na rede sem fio.

Figura 1. ServiceNow arquitetura móvel

Visão geral dos principais recursos do ServiceNow Mobile segurança da plataforma

• Os aplicativos para celular dependem do SECURE ServiceNow E suas APIs para fornecer uma experiência móvel perfeita para seus usuários.
• As interações entre app/servidor são protegidas por meio da estrutura de autorização OAuth.
• A maior parte da interface do usuário no ServiceNow a aplicação é orientada por metadados entregues pelo ServiceNow plataforma.
• . ServiceNow os aplicativos para celular obtêm todos os dados do ServiceNow e armazene-o em um cache local na camada de cliente do app.
• Dados transferidos de e para ServiceNow as instâncias e os dados armazenados localmente são criptografados.
  • Para iOS aplicações, ServiceNow Usa a criptografia de disco validada FIPS 140-2 no nível do SO nos Dados principais, forçando um PIN no nível do dispositivo ou segurança biométrica. iOS Mantém-se atualizado sobre pacotes de criptografia compatíveis com FIPS com atualizações do sistema operacional.
  • Para Android aplicações, ServiceNow Usa o SQLCipher SDK. Este SDK fornece criptografia usando o módulo de criptografia validado pelo FIPS 140-2 para todos os dados do aplicativo armazenados no banco de dados da sala.
    No cliente versão 20.1.0 de Android O pacote de cifras TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 foi adicionado e o suporte para as cifras CBC abaixo foi descontinuado:

    • TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA
    • TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA256
    • TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256

    Em caso de problemas de handshake SSL devido à incompatibilidade de criptografia, revise as cifras compatíveis em sua instância e adicione mais uma cifra compatível.

    Abaixo está a lista de cifras compatíveis em Android:

    • TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384
    • TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256
    • TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256
    • TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384

Visão geral do fluxo da aplicação

ServiceNow Mobile os apps começam a buscar a experiência inicial do usuário após um login bem-sucedido. O aplicativo para celular busca os metadados para renderizar a tela inicial principal da instância. Em seguida, o aplicativo usa esses metadados para renderizar a tela inicial.

Recuperação de dados

Ler dados

Quando um usuário solicita a exibição de informações no aplicativo para celular, ocorrem as etapas a seguir.

1. O aplicativo para celular envia uma solicitação para acessar dados da instância. A solicitação inclui o token e qualquer campo de dados relevante necessário para a solicitação.
2. A instância recebe a solicitação e verifica se o token é válido.
3. Se o token for válido, a instância direcionará a solicitação para a API relevante para buscar as informações.
4. A instância retorna as informações para o aplicativo para celular.

Baixando documentos

Quando um usuário solicita o download de documentos do app, ocorrem as etapas a seguir.

1. O aplicativo para celular envia uma solicitação para acessar o documento. A solicitação inclui o token.
2. A instância recebe a solicitação e verifica se o token é válido
3. A instância verifica as regras da lista de controle de acesso (ACL).
4. Se for válido, o documento estará disponível para exibição.

Write-backs para atualizar campos

Quando um usuário atualiza um campo no aplicativo para celular, ocorrem as etapas a seguir.

1. O aplicativo para celular envia o token e os metadados da ação para a instância. Por exemplo, o ID ou o campo a ser atualizado.
2. A instância direciona a ação com base na API relevante.
3. A instância conclui a ação e envia uma resposta para o aplicativo para celular.
4. Com base na resposta, o aplicativo para celular reflete as mudanças de campo e a disponibilidade da ação na IU.

Write-backs para anexar arquivos

Ao anexar arquivos, ocorrem as etapas a seguir.

1. O aplicativo para celular solicita que o usuário anexe um arquivo, por exemplo, uma imagem.
2. O aplicativo para celular envia o arquivo e o token para a instância.
3. A instância coloca o arquivo com base na API relevante.
4. A instância envia uma resposta de volta para o aplicativo para celular.

Autenticação móvel

ServiceNow Mobile As aplicações são compatíveis com autenticação de plataforma usando OAuth 2,0. Os mecanismos de autenticação incluem SSO de vários provedores, MFA, LDAP, banco de dados local e Resumo. ServiceNow Mobile As aplicações usam uma metodologia de autenticação chamada AppAuth. O AppAuth usa um navegador móvel externo para fazer login do usuário.

Fluxo de autenticação

Quando um usuário faz login em um app em seu dispositivo móvel, o app usa as credenciais do usuário para negociar um token OAuth com a instância. . iOS O conjunto de chaves armazena o token para iOS dispositivos. Android Armazenamento de chaves de uso do dispositivo. A criptografia de cadeia de chaves é AES 256 no modo Galois/Contador (GCM).

No primeiro login, a instância fornece ao usuário um token de acesso e um token de atualização. Esses tokens são válidos por um período de tempo que podem ser configurados em sua instância. Quando um usuário abre o aplicativo para celular, o cliente verifica se o token de acesso é válido. Se for válido, o usuário poderá continuar com a sessão. Se não for válido, o cliente verificará se o token de atualização é válido. Se for válido, o token de atualização será usado para buscar um novo token de acesso válido para o usuário e a sessão poderá continuar. Se o token de atualização não for válido, o usuário deverá autenticar novamente.

Tokens de acesso e atualização

• Os aplicativos para celular nunca armazenam a senha do usuário.
• Os aplicativos para celular armazenam o ID do cliente, que é necessário para obter o token OAuth como parte do fluxo de autenticação.

Encerramento do usuário

Quando um administrador exclui ou remove um usuário da instância, o token de acesso não é mais válido e qualquer operação desconecta o usuário.

Figura 2. Fluxo de trabalho de autenticação móvel

SSO de vários provedores

O plug-in SSO de vários provedores [com.snc.integration.sso.multi.installer] fornece suporte à autenticação SAML. O processo de login (AppAuth) usa este plug-in para redirecionar o usuário para a página de login do IdP (provedor SAML) ao usar o SAML.

Autenticação multifator

Os usuários podem acessar a instância por meio da autenticação multifator usando o plug-in MFA [com.snc.integration.multifactor.authentication]. O aplicativo para celular direciona os usuários para a página de login depois de selecionar sua instância no aplicativo para celular.

LDAP

Use a autenticação LDAP para obter acesso usando credenciais LDAP. O usuário vê a mesma página de login que o login local (baseado em banco de dados), mas o back-end do servidor LDAP exclui a autenticação.

Segurança de dados

ServiceNow Mobile As aplicações usam criptografia de comunicação OTA (Over-the-air) SSL/TLS para segurança de dados. Os endpoints de autorização do OAuth são HTTPS.

Dados em repouso

Os dados de preferência da aplicação, como favoritos, tela inicial e itens do navegador móvel, são armazenados e armazenados em cache localmente no dispositivo. Os aplicativos para celular não armazenam dados de registro, como incidentes e problemas no dispositivo, a menos que sua organização tenha habilitado especificamente a sincronização off-line para o serviço de campo. Os dados de registro armazenados durante o modo off-line são criptografados com módulos validados pelo FIPS 140-2. ( iOS Módulos criptográficos e codificação SQL para Android que usa este módulo criptográfico para criptografia).

Figura 3. Dados em repouso

Dados em movimento

Os dados em movimento estão em um canal SSL/TLS seguro e criptografados com módulos validados pelo FIPS 140-2.

Prevenção contra perda de dados

ServiceNow Fornece recursos de prevenção contra perda de dados sem a necessidade de que o dispositivo e a aplicação sejam gerenciados por um pacote de gestão de mobilidade empresarial (EMM). Esses recursos incluem restringir copiar/colar, impor PIN, bloquear anexo e/ou desfocar a funcionalidade.

Copiar/colar

As restrições de copiar/colar são definidas por uma propriedade na tabela de propriedades do sistema.

Campo Propriedade do sistema	valor
Nome	glide.sg.clear_pasteboard_when_background
Tipo	verdadeiro | falso
Valor	verdadeiro

Exigir um PIN do app

Exigir que os usuários insiram um PIN de seis dígitos sempre que fizerem login no dispositivo móvel ou quando o aplicativo estiver inativo por cinco minutos. Exigir um PIN do app é controlado por uma propriedade na tabela de propriedades do sistema.

Campo Propriedade do sistema	valor
Nome	glide.sg.require_mobile_application_pin
Tipo	verdadeiro | falso
Valor	verdadeiro

Desabilitando anexos em um dispositivo móvel

Você pode configurar a regra de ACL para bloquear anexos especificamente em dispositivos móveis. Use IsMobile método para verificar se uma solicitação vem de um dispositivo móvel. Por exemplo, você pode adicionar uma regra de ACL para a tabela de anexo [sys_attachment] em que as ACLs de script de leitura e gravação incluem a verificação a seguir.

if( gs.isMobile() ){
     answer = false;
}

Você também pode adicionar esse código a qualquer regra de ACL existente para a tabela de anexos. Se você tiver várias regras de ACL de anexo, todas precisarão ter Substituição do administrador opção desmarcada.

Habilite a opção do app desfoque

Desfoque o aplicativo para celular quando não estiver em foco em um dispositivo móvel usando a seguinte propriedade do sistema na tabela de propriedades do sistema.

Campo Propriedade do sistema	valor
Nome	glide.sg.blur_ui_when_backgrounded
Tipo	verdadeiro | falso
Valor	verdadeiro

Importante:

• . glide.sg.blur_ui_when_backgroundeda propriedade do sistema é compatível com ambos iOS e. Android dispositivos.
• Por padrão, o valor desta propriedade é definido como falso , que o desativa.

• Para Android quando esta propriedade está habilitada definindo o valor como verdadeiro as seguintes restrições se aplicam:

  • O recurso de compartilhamento de tela não é compatível e a tela do aplicativo compartilhado aparece em preto.
  • Os usuários são impedidos de fazer capturas de tela.

  Essas restrições não se aplicam a. iOS dispositivos quando glide.sg.blur_ui_when_backgroundeda propriedade está habilitada.

Teste de invasão

ServiceNow contrata um terceiro para executar testes de invasão do aplicativo para celular. Isso normalmente acontece anualmente, mas às vezes ocorre com mais frequência. Os resultados desses testes estão disponíveis para os clientes. Para obter mais detalhes sobre testes de segurança, consulte KB0538598: Teste de segurança da instância do cliente | Política e procedimento .

Aplicação de patches de segurança

Caso um patch de segurança seja necessário, a equipe de desenvolvimento móvel se alinha com as propriedades SDLC padrão para corrigir.

Coleta de dados do usuário

O aplicativo para celular não coleta especificamente dados do usuário.

As transações ou o uso do usuário no app são rastreados no ServiceNow da mesma forma que está na web. Para credenciais de usuário, depois que um usuário faz login, o aplicativo para celular negocia um token OAuth que é armazenado no Apple Porta-chaves ou Android Armazenamento de chaves. As credenciais do usuário nunca são salvas. Se o usuário optar, as seguintes informações serão coletadas:

• Local
• Acesso à câmera
• Notificações