Technical security overview 编辑

This article applies to Citrix Workspace Microapps services hosted in Citrix Cloud.

Before you start deployment of Citrix Workspace Microapps services, review the Secure Deployment Guide for the Citrix Cloud Platform.

Security overview

The Microapps platform is integrated into Workspace and uses existing identity management. OAuth is the primary authentication mechanism for writing to SaaS applications. A SaaS-provided user access token specific to each user in Credential Wallet is stored to enable an efficient user experience for user actions.

This component is connected to the cloud service using an agent called the Citrix Cloud Connector. The following diagram illustrates the service and its security boundaries.

Credential handling

This service handles the following types of credential for Application Integrations:

• Basic user credentials
• OAuth
• OAuth2

General Security Overview

Microapps template apps and integrations are provided ‘as is’. All data, fields, and entities described in the connector guides are extracted in whole from the source system of record (SOR) and transferred to the Microapps cache. Templates are not configurable at this time.

Microapps stores a cache of data from the integrated system of record. For HTTP integrations, the scope of the data is fully configurable by the customer when setting up the configuration, and can be changed anytime.

A system account is used to retrieve the data for the cache using the target system of record API. The system account is typically required to have read-only access to all the data required for Microapps across all users using the microapps.

Credentials for the service account, in addition to OAuth tokens for individual user accounts are used for write actions are stored securely by Microapps using a service backed by Azure Key Vault.

Microapps also stores all the notification cards generated for users. Events triggering these notifications, in addition to content of these cards is also configurable by the administrator.

User interactions with the system are logged. Log data does not contain any system of records data or secrets.

Content is stored in the region selected when setting up your Citrix Cloud account. Regions currently available are US, EU, and AP/S (Asia Pacific South).

Customer content and logs are stored entirely within the Citrix platform and are not available to third parties.

Data backups of microapp for the purposes recovery are stored for the period of two weeks.

Microapp data is held for 30 days after the termination of an entitlement. After this grace period, all resources are deleted.

Data

Data is not explicitly seen, only entity properties and integration tables.

This data is displayed in two places:

1. On the Microapps admin/builder page (and therefore Workspace)

2. Data related to the record can be displayed in the feed cards (as defined variables). These definitions are in the microapp builder. Microapps can potentially be defined to export all data depending on administrator definition.

Example: if someone syncs or adds personal information (potentially PII) and sets to display all records and fields. The predefined templates are constructed according to security best practices and provided in a way that does not display sensitive data.

Note:

Creating integrations requires Administrator (or equivalent) privileges in the customer organization. Microapps provides the tools, it is up to the customer/administrators to utilize these tools to be as secure as possible based on the customer requirements.

Personally Identifiable Information (PII)

Personally Identifiable Information (PII) is designated on a case-by-case basis depending on geographical, business, security, and compliance considerations. PII is a matter for the administrator/customer to decide as each individual company/customer can have different definitions of what is ‘sensitive’ within their own organization.

Personally Identifiable Information changes depending on different geographical authorities but can include names, social security / national insurance numbers, biometric records, ID numbers, factors specific to physical, physiological, mental, economic, cultural, or social identity, or information that combined with other pieces of data, can identify an individual.

In terms of general best practices consider the following to identify and practice when handling data.

• Identify the PII your application integration stores
• Find all the places PII is stored
• Classify PII in terms of sensitivity

Identify PII

PII can include bank details and log-in information. Government agencies store PII including social security numbers, addresses, passport details, and license numbers.

PII Storage Location

PII can exist in a range of different locations such as file servers, cloud services, employee laptops, portals, and more including:

Data in use: The data employees use to do their jobs.

Data at rest: This is the data stored or archived in locations like hard drives, databases, laptops, Sharepoint, and web servers.

Data in motion: This is the data which is transitioning from one location to another. An example would be data moving from a local storage device to a cloud server or moving between employees and business partners via email.

PII Sensitivity Classification

PII must be classified based on its sensitivity. This is a vital part of PII protection. Consider if data is:

Identifiable: How unique is the PII data? If a single record can identify an individual by itself it is a sign that the data is highly sensitive.

Combined data: Try to identify two or more pieces of data that, when combined, can identify a unique individual.

Compliance: Depending on the type of organization you work for there are various regulations and standards for PII. Regulations you may be subject to include the Payment Card Industry Data Security Standard (PCI DSS), General Data Protection Regulation (GDPR), or HIPAA.

For more information regarding GDPR and Citrix see Citrix GDPR FAQ.

Read Access

The Microapps platform reads from the cache. The cache is encrypted at rest at the storage level, as provided by the cloud vendor. The READ access is not available in the source system. It is audited in Microapps platform.

Write Access

Write APIs are used. If services do not allow write APIs, we fall back to service accounts. In all cases, write access is auditable and attributed to the user in the source system.

Data flow

As the components hosted by the cloud service do not include the VDAs, the customer’s application data and golden images required for provisioning are always hosted within the customer setup. The control plane has access to metadata, such as user names, machine names, and application shortcuts, restricting access to the customer’s Intellectual Property from the control plane.

Data flowing between the cloud and customer premises uses secure Transport Layer Security (TLS) connections over port 443.

Citrix Cloud Connector network access requirements

The Citrix Cloud Connectors require only port 443 outbound traffic to the internet, and can be hosted behind an HTTP proxy.

The communication used in Citrix Cloud for HTTPS is TLS 1.0, 1.1, or 1.2. (See Deprecation of TLS versions for in-progress changes.)

IP whitelist configuration

You may need to configure third-party service providers, such as Salesforce, with designated IP addresses from which the microapps service accesses their APIs. The microapps service makes requests from an external IP address within the ranges listed below. Configure your third-party provider according to your microapp service region. Ensure you configure both listed ranges for the US and EU regions.

If you do configure designated IPs, we recommend bookmarking and revisiting this article regularly to stay informed with IP ranges and addresses that may be added or removed in the future.

US Region (32 addresses):

• 20.57.83.64/28
• 20.57.83.192/28

EU Region (32 addresses):

• 20.86.245.144/28
• 20.86.245.160/28

AP-S Region (16 addresses):

• 20.205.243.64/28

Security best practices

Note:

Your organization may need to meet specific security standards to satisfy regulatory requirements. This document does not cover this subject, because such security standards change over time. For up-to-date information on security standards and Citrix products, consult Citrix Security.

To ensure you have reviewed all security considerations:

• Grant users only the capabilities they require
• Review your organizations minimum security guidelines
• Use encrypted communication (HTTPS), with at minimum Transport Layer Security (TLS) 1.2
• Check your rate limits
• Use a system account with minimum permissions to fetch data (bulk reads)
• Consider how long you must retain data once the sync is not running
• Use public APIs for production
• OAuth2 is the preferred authentication protocol for this SaaS service
• Always use OAuth2 for write-backs
• Keep the integration updated. Verify it works and external APIs did not change

Where to go next

See the following resources for more security information and security guides for a similar Citrix Cloud service:

• Citrix Security

• Citrix ADC Secure Deployment guide

• Security considerations and best practices

• Smart cards

• Transport Layer Security (TLS)

Note:

This document is intended to provide the reader with an introduction to and overview of the security functionality of Citrix Cloud; and to define the division of responsibility between Citrix and customers regarding securing the Citrix Cloud deployment. It is not intended to serve as a configuration and administration guidance manual for Citrix Cloud or any of its components or services.