---
sourceDocument: Yokohama Mobile-Konfiguration und -Navigation
sourceDocumentLink: https://servicenow-prod.fluidtopics.net/r/de-DE/yokohama/mobile

 Release :

    - yokohama

ft:locale :

    - de-DE

ft:publication_title :

    - Yokohama Mobile-Konfiguration und -Navigation

ft:clusterId :

    - mobile

bundleId :

    - mobile

workflow :

    - Platform


---

# Mobile Sicherheit

# Mobile Sicherheit {#ariaid-title1}

* Freigeben Version: Yokohama
* 
* Aktualisiert 30. Januar 2025
* 
* ![](https://www.servicenow.com/docs/portal-asset/ico-clock) 6 Minuten Lesedauer

Erfahren Sie mehr über die Sicherheitsfunktionen von ServiceNow MobilePlattform.

## ServiceNow Mobile Architektur {#mobile-security-landing__section_bgc_rmw_3lb}

ServiceNow MobileApps bestehen aus ServiceNowServerinstanz und native Apps für iOSUnd 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

## Übersicht über die wichtigsten Funktionen von ServiceNow MobilePlattformsicherheit {#mobile-security-landing__section_fwd_m5w_3lb}

* Die mobilen Apps basieren auf dem sicheren ServiceNowPlattform 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 ServiceNowDie App wird durch Metadaten gesteuert, die von bereitgestellt werden ServiceNowPlattform.
* Die ServiceNowMobile Apps rufen alle ihre Daten von ab ServiceNowPlattform und speichern Sie sie in einem lokalen Cache auf der App-Client-Ebene.
* Für Government Community Cloud (GCC) ServiceNowInstanzen, lokal gespeicherte Daten sind verschlüsselt.
  * Für iOSApps, ServiceNowVerwendet die FIPS 140-2-validierte Datenträgerverschlüsselung auf Betriebssystemebene für Kerndaten, indem eine PIN- oder Biometriesicherheit auf Geräteebene erzwungen wird.
  * Für AndroidApps, ServiceNowVerwendet das SQLCipher-SDK. Dieses SDK bietet Verschlüsselung mit FIPS 140-2-validiertem Krypto-Modul für alle in Room DB gespeicherten App-Daten.
  {#mobile-security-landing__ul_yyh_fvw_3lb}
{#mobile-security-landing__ul_bnr_n5w_3lb}

## App-Flow-Übersicht {#mobile-security-landing__section_zl5_yrw_3lb}

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.

## Datenabruf {#mobile-security-landing__section_i21_dxw_3lb}

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.
    {#mobile-security-landing__ol_aqw_fxw_3lb}

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.
    {#mobile-security-landing__ol_smd_mxw_3lb}

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.
    {#mobile-security-landing__ol_br3_zxw_3lb}

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-security-landing__ol_nc1_fyw_3lb}

## Mobile Authentifizierung {#mobile-security-landing__section_vl2_nyw_3lb}

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 MobileApps 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 iOSSchlüsselanhänger speichert das Token für iOSGeräte. AndroidGerä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.
    {#mobile-security-landing__ul_dtb_nzw_3lb}

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

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 {#mobile-security-landing__section_hzq_v1x_3lb}

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. ( iOSKryptografische Module und SQL-Verschlüsselung für AndroidWelches dieses kryptografische Modul zur Verschlüsselung verwendet).

:   Abbildung : 3. Daten in Ruhe

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.
:   {#mobile-security-landing__table_mx1_ncx_3lb__entry__2}

    | Systemeigenschaftsfeld | Wert |
    |-|-|
    | Name | glide.sg.clear_pasteboard_when_background |
    | Typ | wahr \| falsch |
    | Wert | wahr |
    [ ]

    {#mobile-security-landing__table_mx1_ncx_3lb}

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.
:   {#mobile-security-landing__table_i4w_qcx_3lb__entry__2}

    | Systemeigenschaftsfeld | Wert |
    |-|-|
    | Name | glide.sg.require_mobile_application_pin |
    | Typ | wahr \| falsch |
    | Wert | wahr |
    [ ]

    {#mobile-security-landing__table_i4w_qcx_3lb}

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.
:   {#mobile-security-landing__table_ikr_ydx_3lb__entry__2}

    | Systemeigenschaftsfeld | Wert |
    |-|-|
    | Name | glide.sg.blur_ui_when_backgrounded |
    | Typ | wahr \| falsch |
    | Wert | wahr |
    [ ]

    {#mobile-security-landing__table_ikr_ydx_3lb}  
    Wichtig:  
    * Die glide.sg.blur_ui_when_backgroundedSystemeigenschaft wird für beide unterstützt iOSUnd AndroidGeräte.
    * Standardmäßig ist der Wert für diese Eigenschaft auf festgelegt <kbd class="ph userinput">Falsch </kbd>, Wodurch es deaktiviert wird.
    * Für AndroidGeräte, wenn diese Eigenschaft durch Festlegen des Werts auf aktiviert ist <kbd class="ph userinput">Wahr </kbd>, 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.

      {#mobile-security-landing__ul_abj_dvd_dwb}

      Diese Einschränkungen gelten nicht für iOSGeräte, wenn glide.sg.blur_ui_when_backgroundedEigenschaft ist aktiviert.
    {#mobile-security-landing__ul_j5q_dxc_dwb}

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](https://support.servicenow.com/kb_view.do?sysparm_article=KB0538598).

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 ServiceNowInstanz 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 AppleSchlüsselanhänger oder AndroidSchlüsselspeicher. Anwenderanmeldeinformationen werden nie gespeichert. Wenn der Anwender sich entscheidet, werden die folgenden Informationen erfasst:

    * Standort
    * Zugriff auf Kamera
    * Benachrichtigungen
    {#mobile-security-landing__ul_zb3_m2x_3lb}

