Technical security overview

The following diagram shows the components in a Citrix DaaS Standard for Azure (formerly Citrix Virtual Apps and Desktops Standard for Azure) deployment. This example uses a VNet peering connection.

With Citrix DaaS for Azure, the customer’s Virtual Delivery Agents (VDAs) that deliver desktops and apps, plus Citrix Cloud Connectors, are deployed into an Azure subscription and tenant that Citrix manages.

NOTE:

This article provides an overview of security requirements for customers deploying Citrix DaaS for Azure using a Citrix Managed Azure subscription. For an architectural overview of a deployment of Citrix DaaS for Azure using a customer-managed Azure subscription, including security information, see Reference Architecture: Virtual Apps and Desktops Service - Azure.

Citrix cloud-based compliance

As of January 2021, the use of Citrix Managed Azure Capacity with various Citrix DaaS editions and Workspace Premium Plus has not been evaluated for Citrix SOC 2 (Type 1 or 2), ISO 27001, HIPAA, or other cloud compliance requirements. Visit the Citrix Trust Center for more information regarding Citrix Cloud Certifications, and check back frequently for updates.

Citrix responsibility

Citrix Cloud Connectors for non-domain-joined catalogs

Citrix DaaS for Azure deploys at least two Cloud Connectors in each resource location. Some catalogs may share a resource location if they are in the same region as other catalogs for the same customer.

Citrix is responsible for the following security operations on non-domain-joined catalog Cloud Connectors:

• Applying operating system updates and security patches
• Installing and maintaining antivirus software
• Applying Cloud Connector software updates

Customers do not have access to the Cloud Connectors. Therefore, Citrix is wholly responsible for the performance of the non-domain-joined catalog Cloud Connectors.

Azure subscription and Azure Active Directory

Citrix is responsible for the security of the Azure subscription and Azure Active Directory (AAD) that are created for the customer. Citrix ensures tenant isolation, so each customer has their own Azure subscription and AAD, and cross-talk between different tenants is prevented. Citrix also restricts access to the AAD to the Citrix DaaS for Azure and Citrix operations personnel only. Access by Citrix to each customer’s Azure subscription is audited.

Customers employing non-domain-joined catalogs can use the Citrix-managed AAD as a means of authentication for Citrix Workspace. For these customers, Citrix creates limited privilege user accounts in the Citrix-managed AAD. However, neither customers’ users nor administrators can execute any actions on the Citrix-managed AAD. If these customers elect to use their own AAD instead, they are wholly responsible for its security.

Virtual networks and infrastructure

Within the customer’s Citrix Managed Azure subscription, Citrix creates virtual networks for isolating resource locations. Within those networks, Citrix creates virtual machines for the VDAs, Cloud Connectors, and image builder machines, in addition to storage accounts, Key Vaults, and other Azure resources. Citrix, in partnership with Microsoft, is responsible for the security of the virtual networks, including virtual network firewalls.

Citrix ensures the default Azure firewall policy (network security groups) is configured to limit access to network interfaces in VNet peering connections. Generally, this controls incoming traffic to VDAs and Cloud Connectors. For details, see:

• Firewall policy for Azure VNet peering connections

Customers cannot change this default firewall policy, but may deploy additional firewall rules on Citrix-created VDA machines; for example, to partially restrict outgoing traffic. Customers that install virtual private network clients, or other software capable of bypassing firewall rules, on Citrix-created VDA machines are responsible for any security risks that might result.

When using the image builder in Citrix DaaS for Azure to create and customize a new machine image, ports 3389-3390 are opened temporarily in the Citrix-managed VNet, so that the customer can RDP to the machine containing the new machine image, to customize it.

Citrix responsibility when using Azure VNet peering connections

For VDAs in Citrix DaaS for Azure to contact on-premises domain controllers, file shares, or other intranet resources, Citrix DaaS for Azure provides a VNet peering workflow as a connectivity option. The customer’s Citrix-managed virtual network is peered with a customer-managed Azure virtual network. The customer-managed virtual network may enable connectivity with the customer’s on-premises resources using the cloud-to-on-premises connectivity solution of the customer’s choice, such as Azure ExpressRoute or iPsec tunnels.

Citrix responsibility for VNet peering is limited to supporting the workflow and related Azure resource configuration for establishing peering relationship between Citrix and customer-managed VNets.

Firewall policy for Azure VNet peering connections

Citrix opens or closes the following ports for inbound and outbound traffic that uses a VNet peering connection.

Citrix-managed VNet with non-domain-joined machines

• Inbound rules
  • Allow ports 80, 443, 1494, and 2598 inbound from VDAs to Cloud Connectors, and from Cloud Connectors to VDAs.
  • Allow ports 49152-65535 inbound to the VDAs from an IP range used by the Monitor shadowing feature. See Communications Ports Used by Citrix Technologies.
  • Deny all other inbound. This includes intra-VNet traffic from VDA to VDA, and VDA to Cloud Connector.
• Outbound rules
  • Allow all traffic outbound.

Citrix-managed VNet with domain-joined machines

• Inbound rules:
  • Allow ports 80, 443, 1494, and 2598 inbound from the VDAs to Cloud Connectors, and from Cloud Connectors to VDAs.
  • Allow ports 49152-65535 inbound to the VDAs from an IP range used by the Monitor shadowing feature. See Communications Ports Used by Citrix Technologies.
  • Deny all other inbound. This includes intra-VNet traffic from VDA to VDA, and VDA to Cloud Connector.
• Outbound rules
  • Allow all traffic outbound.

Customer-managed VNet with domain-joined machines

• It is up to the customer to configure their VNet correctly. This includes opening the following ports for domain joining.
• Inbound rules:
  • Allow inbound on 443, 1494, 2598 from their client IPs for internal launches.
  • Allow inbound on 53, 88, 123, 135-139, 389, 445, 636 from Citrix VNet (IP range specified by customer).
  • Allow inbound on ports opened with a proxy configuration.
  • Other rules created by customer.
• Outbound rules:
  • Allow outbound on 443, 1494, 2598 to the Citrix VNet (IP range specified by customer) for internal launches.
  • Other rules created by customer.

Access to infrastructure

Citrix may access the customer’s Citrix-managed infrastructure (Cloud Connectors) to perform certain administrative tasks such as collecting logs (including Windows Event Viewer) and restarting services without notifying the customer. Citrix is responsible for executing these tasks safely and securely, and with minimal impact to the customer. Citrix is also responsible for ensuring any log files are retrieved, transported, and handled safely and securely. Customer VDAs cannot be accessed this way.

Backups for non-domain-joined catalogs

Citrix is not responsible for performing backups of non-domain-joined catalogs.

Backups for machine images

Citrix is responsible for backing up any machine images uploaded to Citrix DaaS for Azure, including images created with the image builder. Citrix uses locally redundant storage for these images.

Bastions for non-domain-joined catalogs

Citrix operations personnel have the ability to create a bastion, if necessary, to access the customer’s Citrix-managed Azure subscription for diagnosing and repairing customer issues, potentially before the customer is aware of a problem. Citrix does not require the customer’s consent to create a bastion. When Citrix creates the bastion, Citrix creates a strong randomly generated password for the bastion and restricts RDP access to Citrix NAT IP addresses. When the bastion is no longer needed, Citrix disposes of it and the password is no longer valid. The bastion (and its accompanying RDP access rules) are disposed of when the operation completes. Citrix can access only the customer’s non-domain-joined Cloud Connectors with the bastion. Citrix does not have the password to log in to non-domain-joined VDAs or domain-joined Cloud Connectors and VDAs.

Firewall policy when using troubleshooting tools

When a customer requests creation of a bastion machine for troubleshooting, the following security group modifications are made to the Citrix-managed VNet:

• Temporarily allow 3389 inbound from the customer-specified IP range to the bastion.
• Temporarily allow 3389 inbound from the bastion IP address to any address in the VNet (VDAs and Cloud Connectors).
• Continue to block RDP access between the Cloud Connectors, VDAs, and other VDAs.

When a customer enables RDP access for troubleshooting, the following security group modifications are made to the Citrix-managed VNet:

• Temporarily allow 3389 inbound from the customer-specified IP range to any address in the VNet (VDAs and Cloud Connectors).
• Continue to block RDP access between the Cloud Connectors, VDAs, and other VDAs.

Customer-managed subscriptions

For customer-managed subscriptions, Citrix adheres to the above responsibilities during deployment of the Azure resources. After deployment, everything above falls to the customer’s responsibility, because the customer is the owner of the Azure subscription.

Customer responsibility

VDAs and machine images

The customer is responsible for all aspects of the software installed on VDA machines, including:

• Operating system updates and security patches
• Antivirus and antimalware
• VDA software updates and security patches
• Additional software firewall rules (especially outbound traffic)
• Follow Citrix security considerations and best practices

Citrix provides a prepared image that is intended as a starting point. Customers can use this image for proof-of-concept or demonstration purposes or as a base for building their own machine image. Citrix does not guarantee the security of this prepared image. Citrix will make an attempt to keep the operating system and VDA software on the prepared image up to date, and will enable Windows Defender on these images.

Customer responsibility when using VNet peering

The customer must open all ports specified in Customer-managed VNet with domain-joined machines.

When VNet peering is configured, the customer is responsible for the security of their own virtual network and its connectivity to their on-premises resources. The customer is also responsible for security of the incoming traffic from the Citrix-managed peered virtual network. Citrix does not take any action to block traffic from the Citrix-managed virtual network to the customer’s on-premises resources.

Customers have the following options for restricting incoming traffic:

• Give the Citrix-managed virtual network an IP block which is not in use elsewhere in the customer’s on-premises network or the customer-managed connected virtual network. This is required for VNet peering.
• Add Azure network security groups and firewalls in the customer’s virtual network and on-premises network to block or restrict traffic from the Citrix-managed IP block.
• Deploy measures such as intrusion prevention systems, software firewalls, and behavioral analytics engines in the customer’s virtual network and on-premises network, targeting the Citrix-managed IP block.

Proxy

The customer may choose whether to use a proxy for outbound traffic from the VDA. If a proxy is used, the customer is responsible for:

• Configuring the proxy settings on the VDA machine image or, if the VDA is joined to a domain, using Active Directory Group Policy.
• Maintenance and security of the proxy.

Proxies are not allowed for use with Citrix Cloud Connectors or other Citrix-managed infrastructure.

Catalog resiliency

Citrix provides three types of catalogs with differing levels of resiliency:

• Static: Each user is assigned to a single VDA. This catalog type provides no high availability. If a user’s VDA goes down, they will have to be placed on a new one to recover. Azure provides a 99.5% SLA for single-instance VMs. The customer can still back up the user profile, but any customizations made to the VDA (such as installing programs or configuring Windows) will be lost.
• Random: Each user is assigned randomly to a server VDA at launch time. This catalog type provides high availability via redundancy. If a VDA goes down, no information is lost because the user’s profile resides elsewhere.
• Windows 10 multisession: This catalog type operates in the same manner as the random type but uses Windows 10 workstation VDAs instead of server VDAs.

Backups for domain-joined catalogs

If the customer uses domain-joined catalogs with a VNet peering, the customer is responsible for backing up their user profiles. Citrix recommends that customers configure on-premises file shares and set policies on their Active Directory or VDAs to pull user profiles from these file shares. The customer is responsible for the backup and availability of these file shares.

Disaster recovery

In the event of Azure data loss, Citrix will recover as many resources in the Citrix-managed Azure subscription as possible. Citrix will attempt to recover the Cloud Connectors and VDAs. If Citrix is unsuccessful recovering these items, customers are responsible for creating a new catalog. Citrix assumes that machine images are backed up and that customers have backed up their user profiles, allowing the catalog to be rebuilt.

In the event of the loss of an entire Azure region, the customer is responsible for rebuilding their customer-managed virtual network in a new region and creating a new VNet peering within Citrix DaaS for Azure.

Citrix and customer shared responsibilities

Citrix Cloud Connector for domain-joined catalogs

Citrix DaaS for Azure deploys at least two Cloud Connectors in each resource location. Some catalogs may share a resource location if they are in the same region, VNet peering, and domain as other catalogs for the same customer. Citrix configures the customer’s domain-joined Cloud Connectors for the following default security settings on the image:

• Operating system updates and security patches
• Antivirus software
• Cloud Connector software updates

Customers do not normally have access to the Cloud Connectors. However, they may acquire access by using catalog troubleshooting steps and logging in with domain credentials. The customer is responsible for any changes they make when logging in through the bastion.

Customers also have control over the domain-joined Cloud Connectors through Active Directory Group Policy. The customer is responsible for ensuring that the group policies that apply to the Cloud Connector are safe and sensible. For example, if the customer chooses to disable operating system updates using Group Policy, the customer is responsible for performing operating system updates on the Cloud Connectors. The customer can also choose to use Group Policy to enforce stricter security than the Cloud Connector defaults, such as by installing a different antivirus software. In general, Citrix recommends that customers put Cloud Connectors into their own Active Directory organizational unit with no policies, as this will ensure that the defaults Citrix uses can be applied without issue.

Troubleshooting

In the event the customer experiences problems with the catalog in Citrix DaaS for Azure, there are two options for troubleshooting: using bastions and enabling RDP access. Both options introduce security risk to the customer. The customer must understand and consent to undertaking this risk prior to using these options.

Citrix is responsible for opening and closing the necessary ports to carry out troubleshooting operations, and restricting which machines can be accessed during these operations.

With either bastions or RDP access, the active user performing the operation is responsible for the security of the machines that are being accessed. If the customer accesses the VDA or Cloud Connector through RDP and accidentally contracts a virus, the customer is responsible. If Citrix Support personnel access these machines, it is the responsibility of those personnel to perform operations safely. Responsibility for any vulnerabilities exposed by any person accessing the bastion or other machines in the deployment (for example, customer responsibility to add IP ranges to allow list, Citrix responsibility to implement IP ranges correctly) is covered elsewhere in this document.

In both scenarios, Citrix is responsible for correctly creating firewall exceptions to allow RDP traffic. Citrix is also responsible for revoking these exceptions after the customer disposes of the bastion or ends RDP access through Citrix DaaS for Azure.

Bastions

Citrix may create bastions in the customer’s Citrix-managed virtual network within the customer’s Citrix-managed subscription to diagnose and repair issues, either proactively (without customer notification) or in response to a customer-raised issue. The bastion is a machine that the customer can access through RDP and then use to access the VDAs and (for domain-joined catalogs) Cloud Connectors through RDP to gather logs, restart services, or perform other administrative tasks. By default, creating a bastion opens an external firewall rule to allow RDP traffic from a customer-specified range of IP addresses to the bastion machine. It also opens an internal firewall rule to allow access to the Cloud Connectors and VDAs through RDP. Opening these rules poses a large security risk.

The customer is responsible for providing a strong password used for the local Windows account. The customer is also responsible for providing an external IP address range that allows RDP access to the bastion. If the customer elects not to provide an IP range (allowing anyone to attempt RDP access), the customer is responsible for any access attempted by malicious IP addresses.

The customer is also responsible for deleting the bastion after troubleshooting is complete. The bastion host exposes additional attack surface, so Citrix automatically shuts down the machine eight (8) hours after it is powered on. However, Citrix never automatically deletes a bastion. If the customer chooses to use the bastion for an extended period of time, they are responsible for patching and updating it. Citrix recommends that a bastion be used only for several days before deleting it. If the customer wants an up-to-date bastion, they can delete their current one and then create a new bastion, which will provision a fresh machine with the latest security patches.

RDP access

For domain-joined catalogs, if the customer’s VNet peering is functional, the customer can enable RDP access from their peered VNet to their Citrix-managed VNet. If the customer uses this option, the customer is responsible for accessing the VDAs and Cloud Connectors over the VNet peering. Source IP address ranges can be specified so RDP access can be restricted further, even within the customer’s internal network. The customer will need to use domain credentials to log in to these machines. If the customer is working with Citrix Support to resolve an issue, the customer may need to share these credentials with support personnel. After the issue is resolved, the customer is responsible for disabling RDP access. Keeping RDP access open from the customer’s peered or on-premises network poses a security risk.

Domain credentials

If the customer elects to use a domain-joined catalog, the customer is responsible for providing to Citrix DaaS for Azure a domain account (username and password) with permissions to join machines to the domain. When supplying domain credentials, the customer is responsible for adhering to the following security principles:

• Auditable: The account should be created specifically for Citrix DaaS for Azure usage so that it is easy to audit what the account is used for.
• Scoped: The account requires only permissions to join machines to a domain. It should not be a full domain administrator.
• Secure: A strong password should be placed on the account.

Citrix is responsible for the secure storage of this domain account in an Azure Key Vault in the customer’s Citrix-managed Azure subscription. The account is retrieved only if an operation requires the domain account password.

More information

For related information, see:

• Secure Deployment Guide for the Citrix Cloud Platform: Security information for the Citrix Cloud platform.
• Technical security overview: Security information for the Citrix DaaS
• Third party notifications