Client/Server Resources

Client/server resources encompass applications, file servers, and multiple Web resources and are specified in AMC using either a domain, subnet, IP range, host name, or IP address:

• Client/server applications include “traditional” applications developed for a particular operating system, or thin-client applications that are Web-based.
• Network shares include Windows file servers or file shares. Network shares are accessible using either OnDemand or Connect Tunnel. (To access a network share using a Web browser, you must instead define it as a file system resource.)
• Source networks are referenced in an access rule to permit or deny a connection to a destination resource based on the location from which the request originates. For example, you might permit connections only from a particular domain, or permit them only from a specific IP address.
• Graphical terminal agents can be added to WorkPlace as shortcuts that provide access to a terminal server (or Citrix server farm) using a Windows Terminal Services or Citrix client.

• Multiple Web resources on your network—whether in a domain, subnet, or IP range—can be defined. This is a convenient way for you to administer multiple Web servers from a single resource in AMC. For example, if you specify a domain (and create the appropriate access rule), users are able to use their Web browsers to access any Web resources contained within that domain. They can also use OnDemand or Connect Tunnel to get to those resources.

  On the downside, however, your users cannot access those resources from a shortcut on WorkPlace; instead, they must know the internal host name of the resource. If the Web proxy agent is running, they can enter any URL directly in the browser. However, in translated mode, users must manually type URLs in the Intranet Address box in WorkPlace.

To align with a zero trust and least privilege approach, network resources should be defined with the greatest specificity possible, minimizing access to only what is necessary. Rather than defining broad resources, such as entire domains or subnets, which may grant excessive privileges, zero trust principles dictate a narrow, resource-by-resource definition. For instance, instead of defining a domain-wide policy, each specific host or IP address should be defined as a distinct resource. This enforces granular control and limits user privileges strictly to the minimum required.

In scenarios where employees require network access, policies should be crafted to target specific services or resources, reducing exposure and enhancing security. For example, instead of broadly allowing DNS namespace access, policies should be narrowly tailored to define only the specific resources needed. Similarly, for external partners or suppliers, access should be confined to particular hosts or applications required for their role, rather than broad access to subnet ranges. This least privilege approach tightly restricts permissions, allowing only essential access, and ensuring the security posture adheres to zero trust standards.