Sécurité Mobile

  • Rversion finale: Xanadu
  • Mis à jour 1 août 2024
  • 8 minutes de lecture

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

    Architecture ServiceNow Mobile

    Les applications ServiceNow Mobile se composent de l'instance de serveur ServiceNow et d'applications natives pour iOS et Android. Les applications utilisent un code entièrement natif et ne constituent pas une approche hybride. Les applications Mobiles transmettent et reçoivent des données à l'aide du serveur sur l'ensemble du réseau sans fil.

    Figure 1. Architecture Mobile ServiceNow
    Schéma de l’architecture ServiceNow mobile.

    Vue d'ensemble des fonctionnalités clés de sécurité de la plateforme ServiceNow Mobile

    • Les applications Mobile se reposent sur la plateforme ServiceNow sécurisée et ses API pour fournir une expérience mobile transparente aux utilisateurs.
    • Les interactions entre l'application et le serveur sont protégées via le cadre de travail d'autorisation OAuth.
    • L'essentiel de l'interface utilisateur de l'application ServiceNow est piloté par des métadonnées fournies par la plateforme ServiceNow.
    • 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.
    • Pour les instances ServiceNow Government Community Cloud (GCC), les données stockées localement sont chiffrées.
      • Pour les applications iOS, ServiceNow utilise le chiffrement de disque validé par FIPS 140-2 au niveau du système d'exploitation sur Core Data, en forçant un code PIN ou une sécurité biométrique au niveau de l'appareil.
      • 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.

    Vue d'ensemble de flux d'application

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

    Vue d'ensemble de flux d'application.

    Récupération de données

    Lecture des données
    Lorsqu’un utilisateur demande à consulter des informations sur l’application Mobile, les actions suivantes se produisent.
    1. L’application Mobile envoie une demande d’accès aux données à partir de l’instance. Cette demande comprend le jeton et tous les champs de données nécessaires pour la demande.
    2. L'instance reçoit la demande et vérifie la validité du jeton.
    3. Si le jeton est valide, l'instance transmet la demande à l'API concerné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 actions suivantes se produisent.
    1. L'application Mobile envoie une demande d'accès au document. La demande comprend le jeton.
    2. L'instance reçoit la demande et vérifie la validité du jeton.
    3. L'instance vérifie les règles de la liste de contrôle d'accès (ACL).
    4. Si ces éléments sont valides, le document est disponible pour être affiché.
    Écritures conditionnelles pour mettre à jour des champs
    Lorsqu’un utilisateur met à jour un champ sur l’application Mobile, les actions suivantes se produisent.
    1. L'application Mobile envoie à l'instance le jeton et les métadonnées d'action. Par exemple, l'ID ou le champ à mettre à jour.
    2. L'instance redirige l'action en fonction de l'API pertinente.
    3. L’instance effectue l’action et envoie une réponse à l’application Mobile.
    4. En fonction de la réponse, l'application Mobile reflète les modifications du champ et la disponibilité des actions dans l'interface utilisateur.
    Écritures conditionnelles pour joindre des fichiers
    Lorsque vous joignez des fichiers, les étapes suivantes se produisent.
    1. L'application Mobile invite l'utilisateur à joindre un fichier, une image par exemple.
    2. L'application Mobile envoie à l'instance le fichier et le jeton.
    3. L'instance place le fichier en fonction de l'API pertinente.
    4. L'instance renvoie une réponse à l'application Mobile.

    Authentification Mobile

    Les applications ServiceNow Mobile prennent en charge l'authentification de la plateforme en utilisant OAuth 2.0. Les mécanismes d'authentification incluent l'authentification unique (SSO) de plusieurs fournisseurs, la MFA, LDAP, Local DB et Digest. Les applications ServiceNow Mobile 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. iOS Keychain stocke le jeton pour les appareils iOS. Les appareils Android utilisent KeyStore. Le trousseau utilise un chiffrement AES 256 en Galois/Counter Mode (GCM).

    Lorsqu'il se connecte pour la première fois, l'instance donne à l'utilisateur un jeton d'accès et un jeton d'actualisation. Ces jetons sont valides pendant une certaine durée, 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. S'il 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 obtenir 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 renouveler l’authentification.

    Jetons d’accès et d’actualisation
    • Les applications Mobile ne stockent jamais le mot de passe de l'utilisateur.
    • En revanche, elles conservent l'ID client, qui est nécessaire pour obtenir le jeton OAuth dans le cadre du flux d'authentification.
    Suppression d’un utilisateur
    Lorsqu'un administrateur supprime ou retire 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 d'authentification unique (SSO) de plusieurs fournisseurs [com.snc.integration.sso.multi.installer] permet de prendre en charge l'authentification SAML. Le processus de connexion (AppAuth) utilise ce module 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 grâce au 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 l'authentification LDAP pour accéder à l'application à l'aide d'informations d'identification LDAP. L'utilisateur voit la même page de connexion que la connexion locale (basée sur la BD), mais le back-end du serveur LDAP supprime l'authentification.

    Sécurité des données

    Les applications ServiceNow Mobile utilisent le chiffrement des communications over-the-air (OTA) SSL/TLS pour la sécurité des données. Les points de terminaison d'autorisation OAuth sont conformes au protocole HTTPS.

    Données au repos

    Les données des préférences de l’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 Mobile ne stockent pas les données d'enregistrement telles que les incidents et les problèmes sur l'appareil, à moins que votre organisation n'ait spécifiquement activé la synchronisation hors ligne pour le service sur site. Les données d'enregistrement stockées en mode hors ligne sont chiffrées avec des modules validés par FIPS 140-2 (modules cryptographiques iOS et SQL Cipher pour Android, qui 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 sont chiffrées avec les modules validés par FIPS 140-2.
    Prévention de la perte de données
    ServiceNow fournit des fonctionnalités de prévention de la perte de données, sans que l'appareil et l'application n'aient besoin d'être gérés par une suite de gestion de la mobilité d'entreprise (EMM). Ces fonctionnalités incluent des restrictions en matière de copier/coller, l'application de codes PIN, le blocage des pièces jointes et/ou une fonctionnalité de floutage.
    Limitation du copier/coller
    Les restrictions en matière 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 pour une 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. Cette demande de code PIN pour une application est contrôlée par une 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ésactiver les pièces jointes sur un équipement mobile
    Vous pouvez configurer la règle d'ACL pour bloquer les pièces jointes, en particulier sur les équipements mobiles. Utilisez la méthode isMobile pour vérifier si une demande est issue d'un équipement mobile. Par exemple, vous pouvez ajouter une règle d'ACL pour la table de 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 d'ACL existantes dont vous disposez pour la table de pièces jointes. Si vous avez plusieurs règles ACL de pièces jointes, l’option Remplacement administrateur doit être décochée pour toutes.
    Activer l’option d’application floue
    Floutez l'application Mobile lorsqu'elle n'est pas au premier plan sur un équipement mobile en utilisant la propriété système suivante dans la table de 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 ET iOSAndroid
    • Par défaut, la valeur de cette propriété est définie sur faux, 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 sont pas autorisés à prendre des 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 sollicite un tiers pour effectuer des tests de pénétration de l’application Mobile. Ces tests se produisent généralement chaque année mais parfois plus fréquemment. Les résultats de ces tests sont disponibles pour les clients. Pour plus de détails sur les tests de sécurité, consultez KB0538598: Customer Instance Security Testing | Policy and Procedure.

    Application de correctifs 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 pour appliquer le correctif.
    Collecte des données utilisateur

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

    Les transactions utilisateur ou les utilisations au sein de l'application sont suivies sur l'instance ServiceNow, tout comme sur le Web. Pour les informations d'identification utilisateur, une fois qu'un utilisateur est connecté, l'application Mobile négocie un jeton OAuth stocké dans Apple Keychain ou Android KeyStore. Les informations d’identification de l’utilisateur ne sont jamais sauvegardées. Si l’utilisateur s’abonne, les informations suivantes sont collectées :

    • Emplacement
    • Accès à l’appareil photo
    • Notifications