Mobile-Sicherheit

  • Freigeben Version: Zurich
  • Aktualisiert 31. Juli 2025
  • 7 Minuten Lesedauer

    • Erfahren Sie mehr über die Sicherheitsfunktionen der ServiceNow Mobile-Plattform.

    ServiceNow Mobile-Architektur

    ServiceNow Mobile Apps bestehen aus ServiceNow Serverinstanz und nativen Apps für iOS und Android. Die Apps verwenden ausschließlich nativen Code ohne hybriden Ansatz. Der Datenaustausch zwischen den Mobile-Apps und dem Server erfolgt über das drahtlose Netzwerk.

    Abbildung : 1. ServiceNow Mobile-Architektur
    Diagramm von ServiceNow Mobile Architektur.

    Übersicht über die wichtigsten Features der ServiceNow Mobile-Plattformsicherheit

    • Die Mobile-Apps stützen sich auf die sichere ServiceNow-Plattform und ihre APIs, um den Benutzern eine nahtlose Mobile Experience zu bieten.
    • App/Server-Interaktionen werden durch das Autorisierungs-Framework OAuth geschützt.
    • Die Benutzeroberfläche der App ServiceNow wird zum größten Teil durch Metadaten von der ServiceNow-Plattform gesteuert.
    • Die ServiceNow Mobile-Apps rufen all ihre Daten von der ServiceNow-Plattform ab und speichern sie in einem lokalen Cache auf der Ebene des App-Client.
    • Daten, die an und von übertragen werden ServiceNow Instanzen und Daten, die lokal gespeichert werden, werden verschlüsselt.
      • Für iOS Apps, ServiceNow Verwendet die FIPS 140-2-validierte Datenträgerverschlüsselung auf Betriebssystemebene für Kerndaten, indem eine PIN- oder Biometriksicherheit auf Geräteebene erzwungen wird. iOS Hält FIPS-konforme Verschlüsselungs-Suites mit Betriebssystem-Updates auf dem Laufenden.
      • Für Android-Apps verwendet ServiceNow das SDK SQLCipher. Dieses SDK kann alle in Room DB gespeicherten App-Daten mit dem Krypto-Modul verschlüsseln, das gemäß FIPS 140-2 validiert wurde.
        In Client-Version 20.1.0 von Android Apps, die Cipher-Suite TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 wurde hinzugefügt, und die Unterstützung für die folgenden CBC-Cipher wurde eingestellt:
        • TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA
        • TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA256
        • TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256

        Im Falle von SSL-Handshake-Problemen aufgrund von Verschlüsselungskonflikten überprüfen Sie die unterstützten Verschlüsselungen in Ihrer Instanz, und fügen Sie eine weitere unterstützte Verschlüsselungsfunktion hinzu.

        Unten finden Sie die Liste der unterstützten Verschlüsselungen für 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

    Apps im Flow-Überblick

    Nach der erfolgreichen Anmeldung beginnen die ServiceNow Mobile-Apps mit dem Abrufen der ursprünglichen Benutzer-Experience. Die Mobile-App ruft die Metadaten ab, um den Startbildschirm der Zielseite aus der Instanz zu rendern. Die App verwendet diese Metadaten dann, um den Startbildschirm zu rendern.

    Überblick über App-Flow.

    Datenabruf

    Daten lesen
    Wenn ein Benutzer die Anzeige von Informationen in der Mobile-App anfordert, werden die folgenden Schritte ausgeführt.
    1. Die Mobile-App sendet eine Anforderung, um auf Daten aus der Instanz zuzugreifen. Die Anforderung enthält das Token und alle relevanten Datenfelder, die für die Anforderung benötigt werden.
    2. Die Instanz empfängt die Anforderung und überprüft, ob das Token gültig ist.
    3. Wenn das Token gültig ist, leitet die Instanz die Anforderung an die entsprechende API weiter, um die Informationen abzurufen.
    4. Die Instanz gibt die Informationen an die Mobile-App zurück.
    Dokumente herunterladen
    Wenn ein Benutzer den Download von Dokumenten aus der App anfordert, werden die folgenden Schritte ausgeführt.
    1. Die Mobile-App sendet eine Anforderung für den Zugriff auf das Dokument. Die Anforderung enthält das Token.
    2. Die Instanz empfängt die Anforderung und überprüft, ob das Token gültig ist.
    3. Die Instanz überprüft die Regeln der Zugriffssteuerungsliste (Access Control List, ACL).
    4. Wenn sie gültig sind, kann das Dokument angezeigt werden.
    Zurückschreiben bei der Aktualisierung von Feldern
    Wenn ein Benutzer ein Feld in der Mobile-App aktualisiert, werden die folgenden Schritte ausgeführt.
    1. Die Mobile-App sendet das Token und die Aktions-Metadaten an die Instanz. Beispielsweise die ID oder das zu aktualisierende Feld.
    2. Die Instanz startet die Aktion basierend auf der entsprechenden API.
    3. Die Instanz schließt die Aktion ab und sendet eine Antwort an die Mobile-App.
    4. Basierend auf der Antwort spiegelt die Mobile-App die Feldänderungen und die Aktionsverfügbarkeit in der UI wider.
    Zurückschreiben beim Anhängen von Dateien
    Beim Anhängen von Dateien werden die folgenden Schritte ausgeführt.
    1. Die Mobile-App fordert den Benutzer auf, eine Datei anzuhängen, z. B. ein Bild.
    2. Die Mobile-App sendet die Datei und das Token an die Instanz.
    3. Die Instanz platziert die Datei anhand der entsprechenden API.
    4. Die Instanz sendet eine Antwort zurück an die Mobile-App.

    Mobile-Authentifizierung

    ServiceNow Mobile-Apps unterstützen die Plattform-Authentifizierung mit OAuth 2.0. Zu den Authentifizierungsmechanismen gehören Mehrfachanbieter-SSO, MFA, LDAP, lokale DB und Digest. ServiceNow Mobile-Apps verwenden eine neue Authentifizierungsmethode namens AppAuth. AppAuth verwendet einen externen mobilen Browser, um den Benutzer anzumelden.

    Authentifizierungs-Flow

    Wenn sich ein Benutzer auf seinem Mobilgerät bei der App anmeldet, verwendet die App seine Anmeldeinformationen, um ein OAuth-Token mit der Instanz auszuhandeln. Der iOS-Schlüsselbund speichert das Token für iOS-Geräte. Android-Geräte verwenden KeyStore. Die Schlüsselbund-Verschlüsselung ist AES 256 im Galois/Counter-Modus (GCM).

    Bei der erstmaligen Anmeldung gibt die Instanz dem Benutzer ein Zugriffstoken und ein Aktualisierungstoken. Diese Token sind für einen bestimmten Zeitraum gültig. Dieser kann auf Ihrer Instanz konfiguriert werden. Wenn ein Benutzer die Mobile-App öffnet, prüft der Client, ob das Zugriffstoken gültig ist. Falls es gültig ist, kann der Benutzer mit der Sitzung fortfahren. Falls es ungültig ist, überprüft der Client, ob das Aktualisierungstoken gültig ist. Falls es gültig ist, wird das Aktualisierungstoken verwendet, um ein neues gültiges Zugriffstoken für den Benutzer abzurufen, und die Sitzung kann fortgesetzt werden. Wenn das Aktualisierungstoken nicht gültig ist, muss der Benutzer sich erneut authentifizieren.

    Token für Zugriff und Aktualisierung
    • Mobile-Apps speichern das Benutzerpasswort nie.
    • Mobile-Apps speichern die Client-ID, die zum Abrufen des OAuth-Tokens als Teil des Authentifizierungsflusses erforderlich ist.
    Benutzer entfernen
    Wenn ein Administrator einen Benutzer aus der Instanz löscht oder entfernt, ist das Zugriffstoken nicht mehr gültig, und jeder Vorgang meldet den Benutzer ab.
    Abbildung : 2. Workflow für Mobile-Authentifizierung
    Workflow für mobile Authentifizierung.
    Mehrfachanbieter-SSO
    Das Mehrfachanbieter-SSO-Plugin [com.snc.integration.sso.multi.installer] bietet Unterstützung für die SAML-Authentifizierung. Der Anmeldeprozess (AppAuth) verwendet dieses Plugin, um den Benutzer bei Verwendung von SAML zur Anmeldeseite des IDP (SAML-Provider) zu leiten.
    Multifaktor-Authentifizierung
    Benutzer können über die Multifaktor-Authentifizierung mit dem MFA-Plugin [com.snc.integration.multifactor.authentication] auf die Instanz zugreifen. Die Mobile-App leitet Benutzer an ihre Anmeldeseite weiter, nachdem sie ihre Instanz in der Mobile-App ausgewählt haben.
    LDAP
    Verwenden Sie die LDAP-Authentifizierung für den Zugriff mit LDAP-Anmeldeinformationen. Der Benutzer sieht dieselbe Anmeldeseite wie bei der lokalen Anmeldung (DB-basiert), doch löscht das Back-End des LDAP-Servers die Authentifizierung.

    Datensicherheit

    ServiceNow Mobile-Apps nutzen SSL/TLS für die terrestrische Kommunikationsverschlüsselung, um Datensicherheit zu erreichen. Die OAuth-Autorisierungsendpunkte sind HTTPS.

    Daten in Ruhe

    Anwendungseinstellungsdaten wie Favoriten, Startbildschirm und mobile Navigator-Elemente werden lokal auf dem Gerät gespeichert und zwischengespeichert. Mobile-Apps speichern keine Datensätze wie Incidents und Probleme auf dem Gerät, es sei denn, Ihr Unternehmen hat speziell für den Außendienst die Offline-Synchronisierung aktiviert. Im Offline-Modus gespeicherte Datensatzdaten werden mit Modulen verschlüsselt, die gemäß FIPS 140-2 validiert sind. (iOS-Kryptografiemodule und SQL Cipher für Android, wobei dieses Kryptografiemodul zur Verschlüsselung verwendet wird).

    Abbildung : 3. Daten in Ruhe
    Daten im Ruhezustand.
    Daten in Bewegung
    Daten in Bewegung werden über einen sicheren SSL/TLS-Kanal übertragen und mit Modulen verschlüsselt, die gemäß FIPS 140-2 validiert sind.
    Vermeidung von Datenverlust
    ServiceNow verfügt über Funktionen zur Vermeidung von Datenverlust, ohne dass das Gerät und die Anwendung von einer EMM-Suite (Enterprise Mobility Management) verwaltet werden müssen. Zu diesen Funktionen zählen Einschränkungen für das Kopieren/Einfügen, das Erzwingen einer PIN, das Blockieren von Anhängen und/oder die Unschärfefunktion.
    Kopieren/Einfügen einschränken
    Kopieren/Einfügen-Einschränkungen werden durch eine Eigenschaft in der Tabelle „Systemeigenschaften“ definiert.
    Feld „Systemeigenschaft“ Wert
    Name glide.sg.clear_pasteboard_when_background
    Typ richtig | falsch
    Wert Wahr
    App-PIN erzwingen
    Lassen Sie Benutzer jedes Mal, wenn sie sich von ihrem Mobilgerät aus anmelden oder wenn die Anwendung fünf Minuten lang inaktiv war, eine sechsstellige PIN eingeben. Die Notwendigkeit der Eingabe einer App-PIN wird über eine Eigenschaft in der Tabelle „Systemeigenschaften“ gesteuert.
    Feld „Systemeigenschaft“ Wert
    Name glide.sg.require_mobile_application_pin
    Typ richtig | falsch
    Wert Wahr
    Anhänge auf einem Mobilgerät deaktivieren
    Sie können die ACL-Regel so konfigurieren, dass Anhänge speziell auf Mobilgeräten blockiert werden. Verwenden Sie die isMobile-Methode, um zu überprüfen, ob eine Anforderung von einem Mobilgerät stammt. Sie können beispielsweise eine ACL-Regel für die Tabelle „Anhang“ [sys_attachment] hinzufügen, in der die geskripteten Lesen- und Schreiben-ACLs die folgende Prüfung enthalten.
    if( gs.isMobile() ){
     answer = false;
}
    Sie können diesen Code auch anderen vorhandenen ACL-Regeln hinzufügen, die Sie für die Tabelle „Anhang“ haben. Wenn Sie mehrere ACL-Regeln für Anhänge haben, müssen alle über verfügen Administratorüberschreibung Option deaktiviert.
    App-unscharf-Option aktivieren
    Sie können die Mobile-App unscharf machen, wenn sie auf einem Mobilgerät nicht im Fokus ist, indem Sie die folgende Systemeigenschaft in der Tabelle „Systemeigenschaften“ verwenden.
    Feld „Systemeigenschaft“ Wert
    Name glide.sg.blur_ui_when_backgrounded
    Typ richtig | falsch
    Wert wahr
    Wichtig:
    • Die glide.sg.blur_ui_when_backgroundedDie Systemeigenschaft wird auf beiden unterstützt iOS Und Android Geräte.
    • Standardmäßig ist der Wert für diese Eigenschaft auf festgelegt Falsch , Wodurch es deaktiviert wird.

    • Für Android Geräte, wenn diese Eigenschaft durch Festlegen des Werts auf aktiviert ist Wahr , Gelten die folgenden Einschränkungen:

      • Die Bildschirmfreigabefunktion wird nicht unterstützt, und der Bildschirm der freigegebenen App wird schwarz angezeigt.
      • Anwender werden daran gehindert, Screenshots zu erstellen.

      Diese Einschränkungen gelten nicht für iOS Geräte, wenn glide.sg.blur_ui_when_backgroundedEigenschaft ist aktiviert.

    Penetrationstests

    ServiceNow setzt einen Drittanbieter ein, um Penetrationstests der Mobile-App durchzuführen. Dies geschieht normalerweise jährlich, tritt jedoch manchmal häufiger auf. Die Ergebnisse dieser Tests stehen den Kunden zur Verfügung. Weitere Informationen zu Sicherheitstests der Kundeninstanz finden Sie im Knowledge Base-Artikel KB0538598: Customer Instance Security Testing | Policy and Procedure.

    Sicherheitspatches
    Für den Fall, dass ein Sicherheitspatch benötigt wird, richtet sich das Mobile-Entwicklungsteam nach den Standard-SDLC-Vorgaben für die Durchführung des Patch.
    Benutzerdatensammlung

    Die Mobile-App erfasst keine spezifischen Benutzerdaten.

    Benutzertransaktionen oder -nutzungen innerhalb der App werden in der ServiceNow-Instanz genauso verfolgt wie im Web. Für Benutzeranmeldeinformationen verhandelt die Mobile-App nach der Anmeldung eines Benutzers ein OAuth-Token, das im Apple-Schlüsselbund oder im Android-KeyStore gespeichert ist. Benutzeranmeldeinformationen werden nie gespeichert. Wenn sich der Benutzer dafür entscheidet, werden die folgenden Informationen erfasst:

    • Standort
    • Zugriff auf die Kamera
    • Notifications