Mobile Sicherheit

  • Freigeben Version: Australia
  • Aktualisiert 12. März 2026
  • 7 Minuten Lesedauer
  • Erfahren Sie mehr über die Sicherheitsfunktionen von ServiceNow Mobile Plattform.

    ServiceNow Mobile-Architektur

    ServiceNow Mobile Apps bestehen aus ServiceNow Serverinstanz und native Apps für iOS Und Android. Die Apps verwenden vollständigen nativen Code und sind kein Hybridansatz. Die mobilen Apps übertragen und empfangen Daten über das drahtlose Netzwerk mit dem Server.

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

    Übersicht über die wichtigsten Funktionen von ServiceNow Mobile Plattformsicherheit

    • Die mobilen Apps basieren auf dem sicheren ServiceNow Plattform und ihre APIs, um ihren Anwendern eine nahtlose mobile Experience zu bieten.
    • App-/Serverinteraktionen werden durch das OAuth-Autorisierungs-Framework geschützt.
    • Der Großteil der Anwenderoberfläche auf ServiceNow Die App wird durch Metadaten gesteuert, die von bereitgestellt werden ServiceNow Plattform.
    • 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

    ServiceNow Mobile Apps beginnen nach einer erfolgreichen Anmeldung mit dem Abrufen der ersten Anwender-Experience. Die mobile App ruft die Metadaten ab, um den Zielstartbildschirm aus der Instanz zu rendern. Die App verwendet dann diese Metadaten, um den Startbildschirm zu rendern.

    App-Flow-Übersicht.

    Datenabruf

    Daten lesen
    Wenn ein Anwender die Anzeige von Informationen in der mobilen App anfordert, werden die folgenden Schritte ausgeführt.
    1. Die mobile App sendet eine Anforderung zum Zugriff auf Daten aus der Instanz. Die Anforderung enthält das Token und alle relevanten Datenfelder, die für die Anforderung erforderlich sind.
    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 relevante API weiter, um die Informationen abzurufen.
    4. Die Instanz gibt die Informationen an die mobile App zurück.
    Dokumente werden heruntergeladen
    Wenn ein Anwender das Herunterladen von Dokumenten aus der App anfordert, werden die folgenden Schritte ausgeführt.
    1. Die mobile App sendet eine Anforderung zum 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 Zugriffssteuerungslisten-Regeln (ACL).
    4. Wenn gültig, kann das Dokument angezeigt werden.
    Write-Backs zum Aktualisieren von Feldern
    Wenn ein Anwender ein Feld in der mobilen App aktualisiert, werden die folgenden Schritte ausgeführt.
    1. Die mobile App sendet das Token und die Aktionsmetadaten an die Instanz. Beispiel: Die ID oder das zu aktualisierende Feld.
    2. Die Instanz leitet die Aktion basierend auf der relevanten 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 Anwenderoberfläche wider.
    Write-Backs zum Anhängen von Dateien
    Beim Anhängen von Dateien werden die folgenden Schritte ausgeführt.
    1. Die mobile App fordert den Anwender 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 basierend auf der relevanten API.
    4. Die Instanz sendet eine Antwort an die mobile App zurück.

    Mobile Authentifizierung

    ServiceNow Mobile Apps unterstützen die Plattformauthentifizierung mit OAuth 2,0. Authentifizierungsmechanismen umfassen SSO, MFA, LDAP, lokale DB und Digest für mehrere Anbieter. ServiceNow Mobile Apps verwenden eine Authentifizierungsmethode namens AppAuth. AppAuth verwendet einen externen mobilen Browser, um den Anwender anzumelden.

    Authentifizierungs-Flow

    Wenn sich ein Anwender auf seinem Mobilgerät bei einer App anmeldet, verwendet die App die Anmeldeinformationen des Anwenders, um ein OAuth-Token mit der Instanz auszuhandeln. Die iOS Schlüsselanhänger speichert das Token für iOS Geräte. Android Gerät verwendet Schlüsselspeicher. Die Schlüsselkette-Verschlüsselung ist AES 256 im Galois-/Zählermodus (GCM).

    Bei der ersten Anmeldung gibt die Instanz dem Anwender ein Zugriffstoken und ein Aktualisierungstoken. Diese Token sind für einen Zeitraum gültig, der in Ihrer Instanz konfiguriert werden kann. Wenn ein Anwender die mobile App öffnet, überprüft der Client, ob das Zugriffstoken gültig ist. Wenn gültig, kann der Anwender mit der Sitzung fortfahren. Wenn nicht gültig, überprüft der Client, ob das Aktualisierungstoken gültig ist. Wenn gültig, wird das Aktualisierungstoken verwendet, um ein neues gültiges Zugriffstoken für den Anwender abzurufen, und die Sitzung kann fortgesetzt werden. Wenn das Aktualisierungstoken ungültig ist, muss sich der Anwender erneut authentifizieren.

    Greifen Sie auf Token zu, und aktualisieren Sie sie
    • Die mobilen Apps speichern das Anwenderpasswort nie.
    • Die mobilen Apps speichern die Client-ID, die zum Abrufen des OAuth-Tokens als Teil des Authentifizierungs-Flows erforderlich ist.
    Anwenderbeendigung
    Wenn ein Administrator einen Anwender aus der Instanz löscht oder entfernt, ist das Zugriffstoken nicht mehr gültig, und bei jedem Vorgang wird der Anwender abgemeldet.
    Abbildung : 2. Workflow für mobile Authentifizierung
    Workflow für mobile Authentifizierung.
    Multi-Provider-SSO
    Das SSO-Plugin für mehrere Anbieter [com.snc.integration.sso.multi.installer] bietet Unterstützung für die SAML-Authentifizierung. Der Anmeldeprozess (AppAuth) verwendet dieses Plugin, um den Anwender bei Verwendung von SAML zur Anmeldeseite des IDP (SAML-Provider) umzuleiten.
    Multifaktor-Authentifizierung
    Anwender können über die Multifaktor-Authentifizierung mit dem MFA-Plugin [com.snc.integration.multifactor.authentication] auf die Instanz zugreifen. Die mobile App leitet Anwender zu ihrer Anmeldeseite weiter, nachdem sie ihre Instanz in der mobilen App ausgewählt haben.
    LDAP
    Verwenden Sie die LDAP-Authentifizierung, um mit LDAP-Anmeldeinformationen auf zuzugreifen. Der Anwender sieht dieselbe Anmeldeseite wie die lokale Anmeldung (DB-basiert), aber das Back-End des LDAP-Servers löscht die Authentifizierung.

    Datensicherheit

    ServiceNow Mobile Apps verwenden SSL/TLS Over-the-Air (OTA)-Kommunikationsverschlüsselung für Datensicherheit. Die OAuth-Autorisierungs-Endpunkte sind HTTPS.

    Daten in Ruhe

    Anwendungseinstellungsdaten wie Favoriten, Startbildschirm und mobile Navigatorelemente werden lokal auf dem Gerät gespeichert und zwischengespeichert. Die mobilen Apps speichern Datensatzdaten wie Incidents und Probleme nicht auf dem Gerät, es sei denn, Ihre Organisation hat speziell die Offline-Synchronisierung für den Außendienst aktiviert. Datensatzdaten, die im Offline-Modus gespeichert werden, werden mit FIPS 140-2 validierten Modulen verschlüsselt. ( iOS Kryptografische Module und SQL-Verschlüsselung für Android Welches dieses kryptografische Modul zur Verschlüsselung verwendet).

    Abbildung : 3. Daten in Ruhe
    Daten im Ruhezustand.
    Daten in Bewegung
    Daten in Bewegung werden über einen sicheren SSL/TLS-Kanal und mit FIPS 140-2-validierten Modulen verschlüsselt.
    Vermeidung von Datenverlust
    ServiceNow Bietet Funktionen zur Vermeidung von Datenverlust, ohne dass das Gerät und die Anwendung von einer Enterprise Mobility Management-Suite (EMM) verwaltet werden müssen. Diese Funktionen umfassen das Einschränken des Kopierens/Einfügens, das Erzwingen der PIN, das Blockieren von Anhängen und/oder die Unschärfe-Funktionalität.
    Beschränken Sie das Kopieren/Einfügen
    Kopier-/Einfügebeschränkungen werden durch eine Eigenschaft in der Systemeigenschaftentabelle definiert.
    Systemeigenschaftsfeld Wert
    Name glide.sg.clear_pasteboard_when_background
    Typ wahr | falsch
    Wert wahr
    App-PIN erforderlich
    Anwender müssen jedes Mal, wenn sie sich über ihr Mobilgerät anmelden oder wenn die Anwendung fünf Minuten lang inaktiv war, eine sechsstellige PIN eingeben. Die Anforderung einer App-PIN wird über eine Eigenschaft in der Systemeigenschaftentabelle gesteuert.
    Systemeigenschaftsfeld Wert
    Name glide.sg.require_mobile_application_pin
    Typ wahr | falsch
    Wert wahr
    Deaktivieren von Anhängen auf einem Mobilgerät
    Sie können die ACL-Regel konfigurieren, um Anhänge speziell auf Mobilgeräten zu blockieren. Verwenden Sie IsMobile Methode zum Ü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 ACLs zum Lesen und Schreiben die folgende Prüfung enthalten.
    if( gs.isMobile() ){
         answer = false;
    }
    
    Sie können diesen Code auch allen vorhandenen ACL-Regeln hinzufügen, die Sie für die Anhangstabelle haben. Wenn Sie mehrere ACL-Regeln für Anhänge haben, müssen alle über verfügen Administrator-Überschreibung Option deaktiviert.
    Aktivieren Sie die Option für die Weichzeichnungs-App
    Machen Sie die mobile App unscharf, wenn sie auf einem Mobilgerät nicht im Fokus steht, indem Sie die folgende Systemeigenschaft in der Systemeigenschaftentabelle verwenden.
    Systemeigenschaftsfeld Wert
    Name glide.sg.blur_ui_when_backgrounded
    Typ wahr | falsch
    Wert wahr
    Wichtig:
    • Die glide.sg.blur_ui_when_backgroundedSystemeigenschaft wird für beide 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 Beauftragt eine Drittpartei, Penetrationstests der mobilen App durchzuführen. Dies geschieht normalerweise jährlich, tritt jedoch manchmal häufiger auf. Die Ergebnisse dieser Tests stehen Kunden zur Verfügung. Weitere Informationen zu Sicherheitstests finden Sie unter KB0538598: Sicherheitstests für Kundeninstanzen | Richtlinie und Verfahren .

    Sicherheitspatching
    Wenn ein Sicherheitspatch erforderlich ist, richtet das mobile Entwicklungsteam zum Patchen die SDLC-Standardeigenschaften aus.
    Anwenderdatensammlung

    Die mobile App erfasst keine Anwenderdaten speziell.

    Anwendertransaktionen oder -Nutzung innerhalb der App wird auf nachverfolgt ServiceNow Instanz so, wie sie sich im Web befindet. Für Anwenderanmeldeinformationen verhandelt die mobile App nach der Anmeldung eines Anwenders ein OAuth-Token, das in gespeichert ist Apple Schlüsselanhänger oder Android Schlüsselspeicher. Anwenderanmeldeinformationen werden nie gespeichert. Wenn der Anwender sich entscheidet, werden die folgenden Informationen erfasst:

    • Standort
    • Zugriff auf Kamera
    • Benachrichtigungen