Mobile-Sicherheit

  • Freigeben Version: Yokohama
  • Aktualisiert 30. Januar 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 der mobilen Architektur von ServiceNow.

    Ü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.
    • Für ServiceNow-Instanzen der Government Community Cloud (GCC) werden lokal gespeicherte Daten verschlüsselt.
      • Für iOS-Apps wendet ServiceNow auf Kerndaten die validierte Festplattenverschlüsselung FIPS 140-2 auf Betriebssystemebene an, indem auf Geräteebene die Sicherheitsabfrage einer PIN oder biometrischer Eingaben erzwungen wird.
      • 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.

    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
    Mobile-Authentifizierungs-Workflow.
    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 in Ruhe.
    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, muss für alle die Option „Administratorüberschreibung“ deaktiviert sein.
    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 Systemeigenschaft glide.sg.blur_ui_when_backgrounded wird auf iOS - und Android -Geräten unterstützt.
    • Standardmäßig ist der Wert für diese Eigenschaft auf „false“festgelegt, wodurch sie deaktiviert wird.
    • Für Android -Geräte gelten die folgenden Einschränkungen, wenn diese Eigenschaft durch Festlegen des Werts auf „true“aktiviert wird:

      • Die Bildschirmfreigabefunktion wird nicht unterstützt, und der Bildschirm der freigegebenen App wird schwarz angezeigt.
      • Anwender können Screenshots nicht erstellen.

      Diese Einschränkungen gelten nicht für iOS -Geräte, wenn die Eigenschaft glide.sg.blur_ui_when_backgrounded aktiviert ist.

    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