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 and SD-WAN connections. Generally, this controls incoming traffic to VDAs and Cloud Connectors. For details, see:
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.
Citrix responsibility when using SD-WAN connectivity
Citrix supports a fully automated way of deploying virtual Citrix SD-WAN instances to enable connectivity between Citrix DaaS for Azure and on-premises resources. Citrix SD-WAN connectivity has a number of advantages compared to VNet peering, including:
High reliability and security of VDA-to-datacenter and VDA-to-branch (ICA) connections.
- Best end-user experience for office workers, with advanced QoS capabilities and VoIP optimizations.
- Built-in ability to inspect, prioritize, and report on Citrix HDX network traffic and other application usage.
Citrix requires customers who want to take advantage of SD-WAN connectivity for Citrix DaaS for Azure to use SD-WAN Orchestrator for managing their Citrix SD-WAN networks.
The following diagram shows the added components in a Citrix DaaS for Azure deployment using SD-WAN connectivity.
The Citrix SD-WAN deployment for Citrix DaaS for Azure is similar to the standard Azure deployment configuration for Citrix SD-WAN. For more information, see Deploy Citrix SD-WAN Standard Edition Instance on Azure. In a high availability configuration, an active/standby pair of SD-WAN instances with Azure load balancers is deployed as a gateway between the subnet containing VDAs and Cloud Connectors, and the Internet. In a non-HA configuration, only a single SD-WAN instance is deployed as a gateway. Network interfaces of the virtual SD-WAN appliances are assigned addresses from a separate small address range split into two subnets.
When configuring SD-WAN connectivity, Citrix makes a few changes to the networking configuration of managed desktops described above. In particular, all outgoing traffic from the VNet, including traffic to Internet destinations, is routed through the cloud SD-WAN instance. The SD-WAN instance is also configured to be the DNS server for the Citrix-managed VNet.
Management access to the virtual SD-WAN instances requires an admin login and password. Each instance of SD-WAN is assigned a unique, random secure password that can be used by SD-WAN administrators for remote login and troubleshooting through the SD-WAN Orchestrator UI, the virtual appliance management UI and CLI.
Just like other tenant-specific resources, virtual SD-WAN instances deployed in a specific customer VNet are fully isolated from all other VNets.
When the customer enables Citrix SD-WAN connectivity, Citrix automates the initial deployment of virtual SD-WAN instances used with Citrix DaaS for Azure, maintains underlying Azure resources (virtual machines, load balancers, etc.), provides secure and efficient out-of-the-box defaults for the initial configuration of virtual SD-WAN instances, and enables ongoing maintenance and troubleshooting through SD-WAN Orchestrator. Citrix also takes reasonable measures to perform automatic validation of SD-WAN network configuration, check for known security risks, and display corresponding alerts through SD-WAN Orchestrator.
Firewall policy for SD-WAN connections
Citrix uses Azure firewall policies (network security groups) and public IP address assignment to limit access to network interfaces of virtual SD-WAN appliances:
- Only WAN and management interfaces are assigned public IP addresses and allow outbound connectivity to the Internet.
- LAN interfaces, acting as gateways for the Citrix-managed VNet, are only allowed to exchange network traffic with virtual machines on the same VNet.
- WAN interfaces limit inbound traffic to UDP port 4980 (used by Citrix SD-WAN for virtual path connectivity), and deny outbound traffic to the VNet.
- Management ports allow inbound traffic to ports 443 (HTTPS) and 22 (SSH).
- HA interfaces are only allowed to exchange control traffic with each other.
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.
Customer responsibility when using SD-WAN connectivity
When SD-WAN connectivity is configured, customers have full flexibility to configure virtual SD-WAN instances used with Citrix DaaS for Azure according to their networking requirements, with the exception of a few elements required to ensure correct operation of SD-WAN in the Citrix-managed VNet. Customer responsibilities include:
- Design and configuration of routing and firewall rules, including rules for DNS and Internet traffic breakout.
- Maintenance of the SD-WAN network configuration.
- Monitoring of the operational status of the network.
- Timely deployment of Citrix SD-WAN software updates or security fixes. Since all instances of Citrix SD-WAN on a customer network must run the same version of SD-WAN software, deployments of updated software versions to Citrix DaaS for Azure SD-WAN instances need to be managed by customers according to their network maintenance schedules and constraints.
Incorrect configuration of SD-WAN routing and firewall rules, or mismanagement of SD-WAN management passwords, may result in security risks to both virtual resources in Citrix DaaS for Azure, and on-premises resources reachable through Citrix SD-WAN virtual paths. Another possible security risk stems from not updating Citrix SD-WAN software to the latest available patch release. While SD-WAN Orchestrator and other Citrix Cloud services provide the means to address such risks, customers are ultimately responsible for ensuring that virtual SD-WAN instances are configured appropriately.
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 or a new SD-WAN instance 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