Sécurité mobile

  • Rversion finale: Australia
  • Mis à jour 12 mars 2026
  • 8 minutes de lecture

    • Découvrez les fonctionnalités de sécurité de la ServiceNow Mobile plateforme.

    Architecture ServiceNow Mobile

    ServiceNow Mobile Les applications se composent d’une instance serveur et d’applications ServiceNow natives pour iOS et Android. Les applications utilisent un code natif complet et ne sont pas une approche hybride. Les applications mobiles transmettent et reçoivent des données avec le serveur via le réseau sans fil.

    Figure 1. ServiceNow Architecture mobile
    Diagramme de l’architecture ServiceNow mobile.

    Vue d’ensemble des principales fonctionnalités de la sécurité de la ServiceNow Mobile plateforme

    • Les applications mobiles s’appuient sur la plateforme sécurisée ServiceNow et ses API pour offrir une expérience mobile transparente à ses utilisateurs.
    • Les interactions application/serveur sont protégées par le cadre de travail d’autorisation OAuth.
    • La majeure partie de l’interface utilisateur de l’application ServiceNow est pilotée par les métadonnées fournies par la ServiceNow plateforme.
    • Les applications Mobile ServiceNow récupèrent toutes leurs données à partir de la plateforme ServiceNow et les stockent dans un cache local sur la couche du client de l'application.
    • Les données transférées vers et depuis ServiceNow les instances et les données stockées localement sont chiffrées.
      • Pour iOS les applications, ServiceNow utilise le chiffrement de disque validé FIPS 140-2 au niveau du système d’exploitation sur les données principales, en forçant un code PIN au niveau de l’appareil ou une sécurité biométrique. iOS se tient à jour sur les suites de chiffrement conformes à la norme FIPS avec les mises à jour du système d’exploitation.
      • Pour les applications Android, ServiceNow utilise le SDK SQLCipher. Ce SDK fournit un chiffrement à l'aide du module crypto validé par FIPS 140-2 pour toutes les données d'application stockées dans la base de données Room.
        Dans la version 20.1.0 des applications clientes, la suite de Android chiffrement TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 a été ajoutée et la prise en charge des chiffrements CBC ci-dessous a été interrompue :
        • TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA
        • TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA256
        • TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256

        En cas de problèmes de négociation SSL dus à une incohérence de chiffrement, examinez les chiffrements pris en charge sur votre instance et ajoutez un autre chiffrement pris en charge.

        Vous trouverez ci-dessous la liste des chiffrements pris en charge sur 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

    Vue d'ensemble de flux d'application

    ServiceNow Mobile Les applications commencent à extraire l’expérience utilisateur initiale après une connexion réussie. L’application mobile extrait les métadonnées pour afficher l’écran d’accueil de l’instance de destination. L’application utilise ensuite ces métadonnées pour afficher l’écran d’accueil.

    Vue d’ensemble du flux d’application.

    Récupération de données

    Lire les données
    Lorsqu’un utilisateur demande à afficher des informations sur l’application mobile, les étapes suivantes se produisent.
    1. L’application mobile envoie une demande d’accès aux données de l’instance. La demande inclut le jeton et tout champ de données pertinent nécessaire pour la demande.
    2. L’instance reçoit la demande et vérifie si le jeton est valide.
    3. Si le jeton est valide, l’instance dirige la demande vers l’API appropriée pour récupérer les informations.
    4. L’instance renvoie les informations à l’application mobile.
    Téléchargement de documents
    Lorsqu’un utilisateur demande à télécharger des documents à partir de l’application, les étapes suivantes se produisent.
    1. L’application mobile envoie une demande d’accès au document. La demande inclut le jeton.
    2. L’instance reçoit la demande et vérifie si le jeton est valide
    3. L’instance vérifie les règles de liste de contrôle d’accès (ACL).
    4. S’il est valide, le document peut être consulté.
    Écritures différées pour la mise à jour des champs
    Lorsqu’un utilisateur met à jour un champ dans l’application mobile, les étapes suivantes se produisent.
    1. L’application mobile envoie le jeton et les métadonnées d’action à l’instance. Par exemple, l’ID ou le champ à mettre à jour.
    2. L’instance dirige l’action en fonction de l’API pertinente.
    3. L’instance termine l’action et envoie une réponse à l’application mobile.
    4. En fonction de la réponse, l’application mobile reflète les changements de champ et la disponibilité des actions dans l’interface utilisateur.
    Écritures différées pour joindre des fichiers
    Lors de l’attachement de fichiers, les étapes suivantes se produisent.
    1. L’application mobile invite l’utilisateur à joindre un fichier, par exemple une image.
    2. L’application mobile envoie le fichier et le jeton à l’instance.
    3. L’instance place le fichier en fonction de l’API pertinente.
    4. L’instance renvoie une réponse à l’application mobile.

    Authentification mobile

    ServiceNow Mobile les applications prennent en charge l’authentification de plateforme à l’aide d’OAuth 2.0. Les mécanismes d’authentification incluent l’authentification unique (SSO) de plusieurs fournisseurs, la MFA, LDAP, la base de données locale et la synthèse. ServiceNow Mobile les applications utilisent une méthodologie d’authentification appelée AppAuth. AppAuth utilise un navigateur mobile externe pour connecter l’utilisateur.

    Flux d’authentification

    Lorsqu’un utilisateur se connecte à une application sur son équipement mobile, l’application utilise les informations d’identification de l’utilisateur pour négocier un jeton OAuth avec l’instance. Le iOS trousseau stocke le jeton des iOS appareils. Android l’appareil utilise le magasin de clés. Le chiffrement du trousseau est AES 256 en mode Galois/compteur (GCM).

    Lors de la première connexion, l’instance attribue à l’utilisateur un jeton d’accès et un jeton de rafraîchissement. Ces jetons sont valables pendant une période qui peut être configurée sur votre instance. Lorsqu’un utilisateur ouvre l’application mobile, le client vérifie si le jeton d’accès est valide. Si la valeur est valide, l’utilisateur peut poursuivre la session. S’il n’est pas valide, le client vérifie alors si le jeton d’actualisation est valide. S’il est valide, le jeton d’actualisation est utilisé pour extraire un nouveau jeton d’accès valide pour l’utilisateur, et la session peut continuer. Si le jeton d’actualisation n’est pas valide, l’utilisateur doit s’authentifier à nouveau.

    Jetons d’accès et actualisation
    • Les applications mobiles ne stockent jamais le mot de passe de l’utilisateur.
    • Les applications mobiles stockent l’ID client, qui est nécessaire pour obtenir le jeton OAuth dans le cadre du flux d’authentification.
    Arrêt de l’utilisateur
    Lorsqu’un administrateur supprime ou supprime un utilisateur de l’instance, le jeton d’accès n’est plus valide et toute opération déconnecte l’utilisateur.
    Figure 2. Workflow d’authentification mobile
    Workflow d’authentification mobile.
    Authentification unique (SSO) de plusieurs fournisseurs
    Le module d’extension SSO multifournisseurs [com.snc.integration.sso.multi.installer] assure la prise en charge de l’authentification SAML. Le processus de connexion (AppAuth) utilise ce module d’extension pour rediriger l’utilisateur vers la page de connexion IdP (fournisseur SAML) lors de l’utilisation de SAML.
    Authentification multifacteur
    Les utilisateurs peuvent accéder à l’instance via l’authentification multifacteur à l’aide du module d’extension MFA [com.snc.integration.multifactor.authentication]. L’application mobile dirige les utilisateurs vers leur page de connexion après avoir sélectionné leur instance dans l’application mobile.
    LDAP
    Utilisez LDAP Authentication pour accéder à l’aide des informations d’identification LDAP. L’utilisateur voit la même page de connexion que la connexion locale (basée sur la base de données), mais le back-end du serveur LDAP supprime l’authentification.

    Sécurité des données

    ServiceNow Mobile les applications utilisent le chiffrement des communications sans fil (OTA) SSL/TLS pour la sécurité des données. Les points de terminaison d’autorisation OAuth sont HTTPS.

    Données au repos

    Les données de préférences d’application telles que les favoris, l’écran d’accueil et les éléments du navigateur mobile sont stockées et mises en cache localement sur l’appareil. Les applications mobiles ne stockent pas les données d’enregistrement telles que les incidents et les problèmes sur l’appareil, sauf si votre organisation a spécifiquement activé la synchronisation hors connexion pour le service sur site. Les données d’enregistrement stockées en mode hors ligne sont chiffrées avec des modules validés FIPS 140-2. iOS (modules cryptographiques et chiffrement SQL pour Android lesquels utilise ce module cryptographique pour le chiffrement).

    Figure 3. Données au repos
    Données au repos.
    Données en mouvement
    Les données en mouvement sont sur un canal SSL/TLS sécurisé et cryptées avec des modules validés FIPS 140-2.
    Prévention de la perte de données
    ServiceNow fournit des fonctionnalités de prévention des pertes de données sans que l’appareil et l’application aient besoin d’être gérés par une suite de gestion de la mobilité d’entreprise (EMM). Ces fonctionnalités incluent la fonctionnalité de restriction du copier/coller, d’appliquer le code PIN, de bloquer les pièces jointes et/ou de flouter.
    Restreindre le copier/coller
    Les restrictions de copier/coller sont définies par une propriété dans la table des propriétés système.
    Champ de propriété système Valeur
    Nom glide.sg.clear_pasteboard_when_background
    Type vrai | faux
    Valeur VRAI
    Exiger un code PIN d’application
    Exigez des utilisateurs qu’ils saisissent un code PIN à six chiffres chaque fois qu’ils se connectent à partir de leur équipement mobile ou lorsque l’application est inactive depuis cinq minutes. L’exigence d’un code PIN d’application est contrôlée en tant que propriété dans la table des propriétés système.
    Champ de propriété système Valeur
    Nom glide.sg.require_mobile_application_pin
    Type vrai | faux
    Valeur VRAI
    Désactivation des pièces jointes sur un appareil mobile
    Vous pouvez configurer la règle ACL pour bloquer les pièces jointes spécifiquement sur les équipements mobiles. Utilisez la méthode isMobile pour vérifier si une demande provient d’un appareil mobile. Par exemple, vous pouvez ajouter une règle ACL pour la table des pièces jointes [sys_attachment] où les ACL scriptées en lecture et écriture incluent la vérification suivante.
    if( gs.isMobile() ){
     answer = false;
}
    Vous pouvez également ajouter ce code à toutes les règles ACL existantes dont vous disposez pour la table des pièces jointes. Si vous avez plusieurs règles ACL de pièce jointe, toutes devront avoir l’option Remplacement administrateur décochée.
    Activer l’option de floutage de l’application
    Floutez l’application Mobile lorsqu’elle n’est pas prioritaire sur un équipement mobile à l’aide de la propriété système suivante dans la table des propriétés système.
    Champ de propriété système Valeur
    Nom glide.sg.blur_ui_when_backgrounded
    Type vrai | faux
    Valeur VRAI
    Important :
    • La glide.sg.blur_ui_when_backgrounded propriété système est prise en charge sur les appareils iOS and Android .
    • Par défaut, la valeur de cette propriété est définie sur false, ce qui la désactive.

    • Pour Android les appareils, lorsque cette propriété est activée en définissant la valeur sur vrai, les restrictions suivantes s’appliquent :

      • La fonctionnalité de partage d’écran n’est pas prise en charge et l’écran de l’application partagée apparaît en noir.
      • Les utilisateurs ne peuvent pas prendre de captures d’écran.

      Ces restrictions ne s’appliquent pas aux iOS appareils lorsque la glide.sg.blur_ui_when_backgrounded propriété est activée.

    Test de pénétration

    ServiceNow engage un tiers pour effectuer un test de pénétration de l’application mobile. Cela se produit généralement chaque année, mais parfois plus fréquemment. Les résultats de ces tests sont disponibles pour les clients. Pour en savoir plus sur les tests de sécurité, reportez-vous à KB0538598 : Test de sécurité d’instance client | Politiques et procédures.

    Application de correctif de sécurité
    Dans le cas où un correctif de sécurité est nécessaire, l’équipe de développement mobile s’aligne sur les propriétés SDLC standard afin d’appliquer le correctif.
    Collecte de données utilisateur

    L’application mobile ne collecte pas spécifiquement de données utilisateur.

    Les transactions ou l’utilisation de l’utilisateur au sein de l’application sont suivies sur l’instance ServiceNow comme sur le Web. En ce qui concerne les informations d’identification de l’utilisateur, une fois qu’un utilisateur s’est connecté, l’application mobile négocie un jeton OAuth qui est stocké dans le Apple trousseau ou le Android magasin de clés. Les informations d’identification de l’utilisateur ne sont jamais enregistrées. Si l’utilisateur s’abonne, les informations suivantes sont collectées :

    • Emplacement
    • Accès à la caméra
    • Notifications