Device and app policies 编辑

Endpoint Management 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. If 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

Endpoint Management device and app policies address many situations that might pose a security risk, such as when:

• Users try to access apps and data from untrusted devices and unpredictable locations
• Users pass data between devices
• An unauthorized user tries to access data
• A user who has left the company had used their own device (BYOD)
• A user misplaces a device
• Users must access the network securely always
• Users have their own device managed and you must separate work data from personal data
• A device is idle and requires verification of user credentials again
• Users copy and paste sensitive content into unprotected email systems
• 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 Endpoint Management protects data at rest

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

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

The Mobile Apps SDK enables apps for Endpoint Management 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.

Endpoint Management also includes app-level encryption. Endpoint Management 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.

• On iOS devices, Endpoint Management uses strong FIPS-validated cryptographic services and libraries such as keychain.
• OpenSSL provides FIPS-validated modules for various device platforms. OpenSSL further secures data in motion and the certificates required to manage and enroll devices.
• Endpoint Management uses the MAM SDK shared vault API to share managed content between apps that have the same keychain access group. For example, you can share user certificates through an enrolled app so that apps can obtain a certificate from the secure vault.
• Endpoint Management uses the device encryption provided by the platforms.
• Endpoint Management MAM controls at the app level perform a compliance check to validate that device encryption is enabled at every app launch.

How Endpoint Management 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 can 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. The policy is used for authentication and for micro VPN sessions with an app. You can use an Alternate Citrix Gateway with the micro VPN 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 Endpoint Management 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 Endpoint Management operation in sync with enterprise or industry changes, such as new corporate security policies or compliance regulations
• When a new version of the 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 Endpoint Management. 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 Settings > Client Properties in the Endpoint Management console. You can set an inactivity timer in Client Properties so that Secure Hub doesn’t prompt the user to reauthenticate to the managed app until the timer expires.

  The app passcode differs from a device passcode. With a device passcode policy pushed to a device, Secure Hub prompts the user to configure a passcode or PIN. The user must unlock their device when they turn on the device or when the inactivity timer expires. For more information, see Authentication in Endpoint Management.

  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.

• micro VPN session required

  Why use this policy: If an application requires access to a web app (web service) to run, enable this policy. Endpoint Management then 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 micro VPN session required policy enabled: They can’t use the app until they connect to the network. The connection must use a cellular or Wi-Fi service.

• Maximum offline period

  Why use this policy: Use this policy as an extra security option. The policy ensures that users who run an app offline for a specified duration must reconfirm app entitlement and refresh policies.

  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 app 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 users who might experience long periods offline when traveling internationally.

  User example: You load a new version of Secure Mail in the app store and then set an app update grace period of 6 hours. Secure Hub users then have 6 hours to upgrade Secure Mail before they are routed to the app store.

• Active poll period (minutes)

  Why use this policy: The active poll period is the interval at which Endpoint Management 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 and then send the App Lock command, the lock occurs within 60 minutes of the last poll.

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
• pasting data from outside 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. The user 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 QuickEdit. The user 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. The restrictions help 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: Suppose that you enable the App Restriction policy to block dictation on iOS in an MDX app. As a result, the user can’t use the dictate function on the iOS keyboard while the MDX app is running. Thus, data that 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. The Tunneled - Web SSO option allows only the tunneling of HTTP and HTTPS traffic. That option provides single sign-on (SSO) for HTTP and HTTPS traffic and PKINIT authentication.

User example: When a user opens an MDX app that has tunneling enabled, the browser opens an intranet site without requiring the user to start a VPN. The app automatically accesses the internal site using the 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 use 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 NetScaler 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. Two weeks of email take longer to sync than three days of email. More data to sync prolongs the setup process for the user.

  User example: Suppose that the default sync interval is set to three days when the user first sets up Secure Mail. The user can see any emails in their Inbox that they received from the present to three days in the past. If a user wants to see emails that are older than three 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 Endpoint Management manages 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: To see the apps installed by a user, deploy the App inventory policy to a device. If you don’t deploy the policy, you can see only the apps that a user installed from the app store, not personally installed apps. Use the App inventory policy 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 Endpoint Management administrators.

• App lock policy

  Why use this policy: The App Lock policy, for Android, allows you to place apps on an allow list or block list. For example, for allowed 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: The Connection scheduling policy enables Windows Mobile devices to connect back to Endpoint Management for MDM management, app push, and policy deployment. For Android, Android Enterprise, and Chrome OS devices, use Google Firebase Cloud Messaging (FCM) instead. FCM controls connections to Endpoint Management. The Scheduling options are as follows:

  • Never: Connect manually. Users must initiate the connection from Endpoint Management on their devices. Citrix doesn’t recommend this option for production deployments because it prevents you from deploying security policies to devices. As a result, users don’t receive new apps or policies. The Never option is enabled by default.

  • Every: Connects at the designated interval. When you send a security policy, such as a lock or a wipe, Endpoint Management processes the policy on the device the next time the device connects.

  • Define schedule: Endpoint Management attempts to reconnect the user’s device to the Endpoint Management server after a network connection loss. Endpoint Management 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 with a network policy, the Credentials policy lets you deploy certificates for authentication to internal resources that require certificate authentication.

  User example: You deploy a network policy that configures a wireless network on the device. The Wi-Fi 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 Endpoint Management, 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 app store.

  • Native email app: Enable ActiveSync email for the native email client on the device. 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 Endpoint Management, 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 Endpoint Management Self-Help Portal and choose the locate option to see their device location on a map. A user chooses whether 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. The passcode or PIN gives the user access to their device during start-up 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 must remove that policy from a subset of the users. You can remove the policy for selected users by creating a Profile removal policy. Then, use deployment rules to deploy the Profile removal policy only to specified users.

  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 doesn’t know about the change. 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. For example, you can: disable the camera or microphone on a device, enforce roaming rules, and enforce access to third-party services like app stores.

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

• Terms and conditions policy

  Why use this policy: It might be necessary to advise users of the legal implications of having their device managed. In addition, you might want to ensure that users are aware of the security risks when corporate data is pushed to the device. The 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 back-end systems using older VPN Gateway technology. The policy supports various VPN providers, including Cisco AnyConnect, Juniper, and 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.

• Web clip policy

  Why use this policy: Use the Web clip 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 a web clip icon to open an internet site to gain access to needed services. Using a web link is more convenient than typing a link address in a browser.

• Network policy

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

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

• Endpoint Management Store policy

  Why use this policy: The app 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 Endpoint Management, they access the app store through the Citrix Secure Hub app or, if using Citrix Workspace, through the workspace. The user can then see all the corporate apps and services available to them. Users can click an app to install it, access the data, rate and review the app, and download app updates from the app store.