Device and App Policies 编辑

XenMobile device and app policies enable you to optimize a balance between factors, such as:

• Enterprise security
• Corporate data and asset protection
• User privacy
• Productive and positive user experiences

The optimum balance between those factors can vary. For example, highly regulated organizations, such as finance, require stricter security controls than other industries, such as education and retail, in which user productivity is a primary consideration.

You can centrally control and configure policies based on users’ identity, device, location, and connectivity type to restrict malicious usage of corporate content. In the event a device is lost or stolen, you can disable, lock, or wipe business applications and data remotely. The overall result is a solution that increases employee satisfaction and productivity, while ensuring security and administrative control.

The primary focus of this article is the many device and app policies related to security.

Policies that address security risks

XenMobile device and app policies address many situations that may pose a security risk, such as the following:

• When users try to access apps and data from untrusted devices and unpredictable locations.
• When users pass data from device to device.
• When an unauthorized user tries to access data.
• When a user who has left the company had used their own device (BYOD).
• When a user misplaces a device.
• When users need to access the network securely at all times.
• When users have their own device managed and you need to separate work data from personal data.
• When a device is idle and requires verification of user credentials again.
• When users copy and paste sensitive content into unprotected email systems.
• When users receive email attachments or web links with sensitive data on a device that holds both personal and company accounts.

Those situations relate to two main areas of concern when protecting company data, which are when data is:

• At rest
• In transit

How XenMobile protects data at rest

Data stored on mobile devices is referred to as data at rest. XenMobile uses the device encryption provided by the iOS and Android platforms. XenMobile supplements platform-based encryption with features such as compliance checking, available through the Citrix MAM SDK.

The mobile application management (MAM) capabilities in XenMobile enable complete management, security, and control over mobile productivity apps, MDX-enabled apps, and their associated data.

The Mobile Apps SDK enables apps for XenMobile deployment through use of the Citrix MDX app container technology. The container technology separates corporate apps and data from personal apps and data on a user device. The data separation allows you to secure any custom-developed, third-party, or BYO mobile app with comprehensive policy-based controls.

XenMobile also includes app-level encryption. XenMobile separately encrypts data stored within any MDX-enabled app without requiring a device passcode and without requiring that you manage the device to enforce the policy.

Policies and the Mobile Apps SDK enable you to:

• Separate business and personal apps and data in a secure mobile container.
• Secure apps with encryption and other mobile Data Loss Prevention (DLP) technologies.

MDX policies provide many operational controls. You can enable seamless integration between apps that are MAM SDK enabled or MDX-wrapped, while also controlling all communication. In this way, you can enforce policies, such as ensuring that data only is accessible by MAM SDK enabled or MDX-wrapped apps.

Beyond device and app policy control, the best way to safeguard data at rest is encryption. XenMobile adds a layer of encryption to any data stored in an MDX-enabled app, giving you policy control over features such as public file encryption, private file encryption, and encryption exclusions. The Mobile Apps SDK uses FIPS 140-2 compliant AES 256-bit encryption with keys stored in a protected Citrix Secret Vault.

How XenMobile protects data in transit

Data on the move between your user’s mobile devices and your internal network is referred to as data in transit. MDX app container technology provides application-specific VPN access to your internal network through Citrix Gateway.

Consider the situation where an employee wants to access the following resources residing in the secure enterprise network from a mobile device:

• The corporate email server
• An SSL-enabled web application hosted on the corporate intranet
• Documents stored on a file server or Microsoft SharePoint

MDX enables access to all these enterprise resources from mobile devices through an application-specific micro VPN. Each device has its own dedicated micro VPN tunnel.

Micro VPN functionality does not require a device-wide VPN, which can compromise security on untrusted mobile devices. As a result, the internal network is not exposed to malware or attacks that could infect the entire corporate system. Corporate mobile apps and personal mobile apps are able to coexist on one device.

To offer even stronger levels of security, you can configure MDX-enabled apps with an Alternate Citrix Gateway policy, used for authentication and for micro VPN sessions with an app. You can use an Alternate Citrix Gateway with the Online session required policy to force apps to reauthenticate to the specific gateway. Such gateways would typically have different (higher assurance) authentication requirements and traffic management policies.

In addition to security features, the micro VPN feature also offers data optimization techniques, including compression algorithms. Compression algorithms ensure that:

• Only minimal data is transferred
• The transfer is done in the quickest time possible. Speed improves user experience, which is a key success factor in mobile device adoption.

Reevaluate your device policies periodically, such as in these situations:

• When a new version of XenMobile includes new or updated policies due to the release of device operating system updates

• When you add a device type:

  Although many policies are common to all devices, each device has a set of policies specific to its operating system. As a result, you might find differences between iOS, Android, and Windows devices, and even between Android devices from different manufacturers.

• To keep XenMobile operation in sync with enterprise or industry changes, such as new corporate security policies or compliance regulations
• When a new version of MAM SDK includes new or updated policies
• When you add or update an app
• To integrate new workflows for your users as a result of new apps or new requirements

App Policies and Use Case Scenarios

Although you can choose which apps are available through Secure Hub, you might also want to define how those apps interact with XenMobile. Use app policies:

• If you want users to authenticate after a certain time period passes.
• If you want to provide users offline access to their information.

The following sections include some of the policies and example usage.

• For a list of the third-party policies you can integrate in your iOS and Android app by using the MAM SDK, see MAM SDK Overview.
• For a list of all MDX policies per platform, see MDX Policies at a Glance.

Authentication policies

• Device passcode

  Why use this policy: Enable the Device passcode policy to enforce that a user can access an MDX app only if the device has a device passcode enabled. This feature ensures use of iOS encryption at the device level.

  User example: Enabling this policy means that the user must set a passcode on their iOS device before they can access the MDX app.

• App passcode

  Why use this policy: Enable the App passcode policy to have Secure Hub prompt a user to authenticate to the managed app before they can open the app and access data. The user might authenticate with their Active Directory password, Citrix PIN, or iOS TouchID, depending what you configure under Client Properties in your XenMobile Server Settings. You can set an inactivity timer in Client Properties so that, with continued use, Secure Hub doesn’t prompt the user to authenticate to the managed app again until the timer expires.

  The app passcode differs from a device passcode in that, with a device passcode policy pushed to a device, Secure Hub prompts the user to configure a passcode or PIN, which they must unlock before they can gain access to their device when they turn on the device or when the inactivity timer expires. For more information, see Authentication in XenMobile.

  User example: When opening the Citrix Secure Web application on the device, the user must enter their Citrix PIN before they can browse websites if the inactivity period is expired.

• Online session required

  Why use this policy: If an application requires access to a web app (web service) to run, enable this policy so that XenMobile prompts the user to connect to the enterprise network or have an active session before using the app.

  User example: When a user attempts to open an MDX app that has the Online session required policy enabled, they can’t use the app until they connected to the network using a cellular or Wi-Fi service.

• Maximum offline period

  Why use this policy: Use this policy as an additional security option, to ensure that users can’t run an app offline for long time periods without reconfirming app entitlement and refreshing policies from XenMobile.

  User example: If you configure an MDX app with a Maximum offline period, the user can open and use the app offline until the offline timer period expires. At that point, the user must connect back to the network via cellular or Wi-Fi service and reauthenticate, if prompted.

Miscellaneous Access policies

• App update grace period (hours)

  Why use this policy: The app update grace period is the time available to the user before they must update an app that has a newer version released in the XenMobile Store. At the point of expiry, the user must update the app before they can gain access to the data in the app. When setting this value, keep in mind the needs of your mobile workforce, particularly those who might experience long periods offline when travelling internationally.

  User example: You load a new version of Secure Mail in the XenMobile Store and then set an app update grace period of 6 hours. All Secure Mail users will see a message asking them to update their Secure Mail app, until the 6 hours expires. When the 6 hours expire, Secure Hub routes users to the XenMobile Store.

• Active poll period (minutes)

  Why use this policy: The active poll period is the interval at which XenMobile checks apps for when to perform security actions, such as App Lock and App Wipe.

  User example: If you set the Active poll period policy to 60 minutes, when you send the App Lock command from XenMobile to the device, the lock occurs within 60 minutes of when the last poll took place.

Non-compliant device behavior policies

When a device falls below the minimum compliance requirements, the Non-compliant device behavior policy allows you to select the action to take. For information, see Non-compliant device behavior.

App Interaction Policies

Why use these policies: Use App Interaction policies to control the flow of documents and data from MDX apps to other apps on the device. For example, you can prevent a user from moving data to their personal apps outside of the container or from pasting data from outside of the container into the containerized apps.

User example: You set an App interaction policy to Restricted, which means a user can copy text from Secure Mail to Secure Web but can’t copy that data to their personal Safari or Chrome browser that is outside the container. In addition, a user can open an attached document from Secure Mail into Citrix Files or Quick Edit but can’t open the attached document in their own personal file viewing apps that are outside the container.

App Restrictions policies

Why use these policies: Use App Restriction policies to control what features users can access from an MDX app while it is open. This helps to ensure that no malicious activity can take place while the app is running. The App Restriction policies vary slightly between iOS and Android. For example, in iOS you can block access to iCloud while the MDX app is running. In Android, you can stop NFC use while the MDX app is running.

User example: If you enable the App Restriction policy to block dictation on iOS in an MDX app, the user can’t use the dictate function on the iOS keyboard while the MDX app is running. Thus, data users dictate isn’t passed to the unsecure third-party cloud dictation service. When the user opens their personal app outside of the container, the dictate option remains available to the user for their personal communications.

App Network Access policies

Why use these policies: Use the App Network Access policies to provide access from an MDX app in the container on the device to data sitting inside your corporate network. For the Network access policy, set the Tunneled to the internal network option to automate a micro VPN from the MDX app through the Citrix ADC to a back-end web service or datastore.

User example: When a user opens an MDX app, such as Secure Web, that has tunneling enabled, the browser opens and launches an intranet site without the user needing to start a VPN. The Secure Web app automatically accesses the internal site using micro VPN technology.

App Geolocation and Geofencing policies

Why use these policies: The policies that control app geolocation and geofencing include center point longitude, center point latitude, and radius. Those policies contain access to the data in the MDX apps to a specific geographical area. The policies define a geographic area by a radius of latitude and longitude coordinates. If a user attempts to use an app outside of the defined radius, the app remains locked and the user cannot access the app data.

User example: A user can access merger and acquisition data while they are in their office location. When they move outside of their office location, this sensitive data becomes inaccessible.

Secure Mail App policies

• Background network services

  Why use this policy: Background network services in Secure Mail leverage Secure Ticket Authority (STA), which is effectively a SOCKS5 proxy to connect through Citrix Gateway. STA supports long-lived connections and provides better battery life compared to micro VPN. Thus, STA is ideal for mail that connects constantly. Citrix recommends that you configure these settings for Secure Mail. The Citrix ADC for XenMobile wizard automatically sets up STA for Secure Mail.

  User example: When STA isn’t enabled and an Android user opens Secure Mail, they are prompted to open a VPN, which remains open on the device. When STA is enabled and the Android user opens Secure Mail, Secure Mail connects seamlessly with no VPN required.

• Default sync interval

  Why use this policy: This setting specifies the default days of email that synchronize to Secure Mail when the user accesses Secure Mail for the first time. Be aware that 2 weeks of email takes longer to sync than 3 days and prolongs the setup process for the user.

  User example: If the default sync interval is set to 3 days when the user first sets up Secure Mail, they can see any emails in their Inbox that they received from the present to 3 days in the past. If a user wants to see emails that are older than 3 days, they can do a search. Secure Mail then shows the older emails stored on the server. After installing Secure Mail, each user can change this setting to better suit their needs.

Device Policies and Use Case Behavior

Device policies, sometimes referred to as MDM policies, determine how XenMobile works with devices. Although many policies are common to all devices, each device has a set of policies specific to its operating system. The following list includes some of the device policies and discusses how you might use them. For a list of all device policies, see the articles under Device policies.

• App inventory policy

  Why use this policy: Deploy the App inventory policy to a device if you need to see the apps installed by a user. If you don’t deploy the App inventory policy, you can see only the apps that a user installed from the XenMobile Store and not any personally installed applications. You must use this policy if you want to block certain apps from running on corporate devices.

  User example: A user with an MDM-managed device cannot disable this functionality. The user’s personally installed applications are visible to XenMobile administrators.

• App lock policy

  Why use this policy: The App Lock policy, for Android, allows you to block or allow apps. For example, by allowing apps you can configure a kiosk device. Typically, you deploy the App lock policy only to corporate owned devices, because it limits the apps that users can install. You can set an override password to provide user access to blocked apps.

  User example: Suppose that you deploy an App lock policy that blocks the Angry Birds app. The user can install the Angry Birds app from Google Play, yet when they open the app a message advises them that their administrator blocked the app.

• Connection scheduling policy

  Why use this policy: You must use the Connection scheduling policy so that Windows Mobile devices can connect back to XenMobile Server for MDM management, app push, and policy deployment. For Android, Android Enterprise, and Chrome OS devices, use Google Firebase Cloud Messaging (FCM), instead of this policy, to control connections to XenMobile Server. The Scheduling options are as follows:

  • Always: Keeps the connection alive permanently. Citrix recommends this option for optimized security. When you choose Always, also use the Connection timer policy to ensure that the connection is not draining the battery. By keeping the connection alive, you can push security commands like wipe or lock to the device on-demand. You must also select the Deployment Schedule option Deploy for always-on connection in each policy you deploy to the device.

  • Never: Connects manually. Citrix does not recommend this option for production deployments because the Never option prevents you from deploying security policies to devices; thus, users never receive any new apps or policies.

  • Every: Connects at the designated interval. When this option is in effect and you send a security policy, such as a lock or a wipe, XenMobile processes the policy on the device the next time the device connects.

  • Define schedule: When enabled, XenMobile attempts to reconnect the user’s device to the XenMobile server after a network connection loss and monitors the connection by transmitting control packets at regular intervals within the timeframe you define.

  User example: You want to deploy a passcode policy to enrolled devices. The scheduling policy ensures that the devices connect back to the server at a regular interval to collect the new policy.

• Credentials Policy

  Why use this policy: Often used in conjunction with a WiFi policy, the Credentials policy lets you deploy certificates for authentication to internal resources that require certificate authentication.

  User example: You deploy a WiFi policy that configures a wireless network on the device. The WiFi network requires a certificate for authentication. The Credentials policy deploys a certificate that is then stored in the operating system keystore. The user can then select the certificate when connected to the internal resource.

• Exchange policy

  Why use this policy: With XenMobile, you have two options to deliver Microsoft Exchange ActiveSync email.

  • Secure Mail app: Deliver email by using the Secure Mail app that you distribute from the public app store or the XenMobile Store.

  • Native email app: Use the Exchange policy to enable ActiveSync email for the native email client on the device. With the Exchange policy for native email, you can use macros to populate the user data from their Active Directory attributes, such as ${user.username} to populate the user name and ${user.domain} to populate the user domain.

  User example: When you push the Exchange policy, you send Exchange Server details to the device. Secure Hub then prompts the user to authenticate and their email begins to sync.

• Location policy

  Why use this policy: The Location policy lets you geolocate devices on a map, if the device has GPS enabled for Secure Hub. After you deploy this policy and then send a locate command from the XenMobile server, the device responds back with the location coordinates.

  User example: When you deploy the location policy and GPS is enabled on the device, if users misplace their device, they can log on to the XenMobile Self-Help Portal and choose the locate option to see the location of their device on a map. Note that the user makes the choice to allow Secure Hub to use location services. You cannot enforce the use of location services when users enroll a device themselves. Another consideration for using this policy is the effect on battery life.

• Passcode policy

  Why use this policy: The passcode policy allows you to enforce a PIN code or password on a managed device. This passcode policy allows you to set the complexity and time-outs for the passcode on the device.

  User example: When you deploy a passcode policy to a managed device, Secure Hub prompts the user to configure a passcode or PIN, which they must unlock before they can gain access to their device when they turn on the device or when the inactivity timer expires.

• Profile removal policy

  Why use this policy: Suppose that you deploy a policy to a group of users and later need to remove that policy from a subset of the users. You can remove the policy for selected users by creating a Profile removal policy and using deployment rules to deploy the Profile removal policy only to specified user names.

  User example: When you deploy a Profile removal policy to user devices, users might not notice the change. For example, if the Profile removal policy removes a restriction that disabled the device camera, the user won’t know that camera use is now allowed. Consider letting users know when changes affect their user experience.

• Restrictions policy

  Why use this policy: The restriction policy gives you many options to lock down and control features and functionality on the managed device. You can enable hundreds of restriction options for supported devices, from disabling the camera or microphone on a device to enforcing roaming rules and access to third-party services like app stores.

  User example: If you deploy a restriction to an iOS device, the user may not be able to access iCloud or the Apple App store.

• Terms and conditions policy

  Why use this policy: You might need to advise users of the legal implications of having their device managed. In addition, you may want to ensure that users are aware of the security risks when corporate data is pushed to the device. The custom Terms and Conditions document allows you to publish rules and notices before the user enrolls.

  User example: A user sees the Terms and Conditions information during the enrollment process. If they decline to accept the conditions stated, the enrollment process ends and they cannot access corporate data. You can generate a report to provide to HR/Legal/Compliance teams to show who accepted or declined the terms.

• VPN policy

  Why use this policy: Use the VPN policy to provide access to backend systems using older VPN Gateway technology. The policy supports a number of VPN providers, including Cisco AnyConnect, Juniper, as well as Citrix VPN. It is also possible to link this policy to a CA and enabled VPN on-demand, if the VPN gateway supports this option.

  User example: With the VPN policy enabled, a user’s device opens a VPN connection when the user accesses an internal domain.

• Webclip policy

  Why use this policy: Use the Webclip policy if you want to push to devices an icon that opens directly to a website. A web clip contains a link to a website and can include a custom icon. On a device a web clip looks like an app icon.

  User example: A user can click on a web clip icon to open an internet site that provides services they need to access. Using a web link is more convenient than needing to open a browser app and type a link address.

• WiFi policy

  Why use this policy: The WiFi policy lets you deploy WiFi network details, such as the SSID, authentication data, and configuration data, to a managed device.

  User example: When you deploy the WiFi policy, the device automatically connects to the WiFi network and authenticates the user so they can gain access to the network.

• Windows Information Protection policy

  Why use this policy: Use the Windows Information Protection (WIP) policy to protect against the potential leakage of enterprise data. You can specify the apps that require Windows Information Protection at the enforcement level you set. For example, you can block any inappropriate data sharing or warn about in appropriate data sharing and allow users to override the policy. You can run WIP silently while logging and permitting inappropriate data sharing

  User example: Suppose that you configure the WIP policy to block inappropriate data sharing. If a user copies or saves a protected file to a non-protected location, a message similar to the following appears: You can’t place work protected content in this location.

• XenMobile Store policy

  Why use this policy: The XenMobile Store is a unified app store where administrators can publish all the corporate apps and data resources needed by their users. An administrator can add:

  • Web apps, SaaS apps, and MAM SDK enabled apps or MDX-wrapped apps
  • Citrix mobile productivity apps
  • Native mobile apps such as .ipa or .apk files
  • Apple App Store and Google Play apps
  • Web links
  • Citrix Virtual Apps published using Citrix StoreFront

  User example: After a user enrolls their device into XenMobile, they access the XenMobile Store through the Citrix Secure Hub app. The user can then see all the corporate apps and services available to them. Users can click on an app to install it, access the data, rate and review the app, and download app updates from the XenMobile Store.