TransientAccess FAQ

TransientX Cloud Delivered Services
  • All services delivered for TransientAccess are configured and managed through the TransientX Cloud where the Controller for each customer is served.
  • Managed Service Providers and TransientX Partners can deliver managed services to their customers by accessing each tenant controller and viewing the operational status of multiple tenants through the TransientX service portal.
Cloud Controller Infrastructure (SaaS control Plane)
  • The Transient Cloud is hosted on a hyperscale cloud (currently on Google Cloud and soon Amazon Web Services).
Cloud resiliency
  • The service delivers 99.99% availability at this time
  • In the event of an outage:
  • Existing connections between clients and connectors will be unaffected. Users that have already established a connection to their application will not see any impact of the cloud service outage. Some statistics may be lost depending on outage duration
  • New user logins will be stopped during an outage
  • New application connections will not be available during an outage

- Latency

  • The TransientX design only requires a limited number of control connections to be sent to the TransientX cloud. Only AuthN and AuthZ messages are sent, which are not as sensitive to web flow latency.

- Compliance

  • For all customers, the email address and name of the user is securely stored in the TransientX Cloud.
  • TransientX offers regional cloud POPS to ensure compliance with data sovereignty. For example, European Union customer data is kept in Cloud controllers based in the EU.

- Security

  • Admin access control is managed through a dedicated tenant per customer. Every customer has a customer portal in the form of #tenantname#.portal.transientx.com. Administrators can simply login through this URL.
  • Communication between control and broker is based on https, with a secure handshake protocol that ensures that no MIM attackers can impersonate a client, connector or the controller.
  • The controller is secured through multiple layers: Access to workloads are secured by TransientAccess and our servers are not exposed to public access
  • In the cloud, TransientX utilizes IDS/DDOS protection and access control enforcement
  • At the app level, TransientX implements security controls monitoring patterns at the webapp level as well as server level.
  • TransientX cloud engineering performs daily basic vulnerability scans and weekly comprehensive vulnerability scans to our infrastructure externally.

- Logging

  • A Full trail of audit events are recorded

- User/ Customization

  • Customer logos can be placed and used for customer instances
Reporting and Analytics
  • Full user activity is available through the portal
  • Time based reporting and machine learning based analytics are on the roadmap
External Integrations
  • All major IdPs including Okta and AzureAD are supported.
  • RESTFul APIs allow any external integration including with SOAR and/SIEM tools
Connector
  • The Connector component is a lightweight executable that is intended to provide ephemeral connectivity of each client app instance to the server app. The Connector is deployed either in a corporate data center environment or a public cloud.
  • The Connector accepts a secure tunnel connection from the Client. The traffic inside the tunnel is transparently forwarded to the Data Center, and vice-versa. The Connector does not process the traffic in any form. Specifically, the Connector does not decrypt user traffic, for example.
Operating Environments
  • Hypervisors: VMWare, OpenStack
  • Cloud: Azure, AWS, GCP
Compute requirements and deployment
  •  The Connector requires the following compute, storage and network requirements to provide consistent performance:
  • Memory: 4 GB RAM
  • CPU:
    • Data Center/ Server
      • 2 CPU cores (Xeon E5 class) for physical machines
        without hyper-threading
      • 4 CPU cores (Xeon E5 class) for virtual machines (VMs)
        with hyper threading
  • Cloud
    • Both Amazon Web Services (AWS) and Google Cloud Platform (GCP) require a minimum of 4 CPU cores due to hyperthreading
    • AWS: To deploy a Connector on AWS, recommendation is a t3.xlarge (for non-production or low traffic Connectors) or m5a.xlarge (for production or high traffic Connectors)
    • GCP: To deploy an App Connector on GCP, recommendation is n1-standard-4 or n1-highcpu-4
    • Azure: Azure VMs older than V3 require 2 CPU cores, while VMs V3 and higher require 4 CPU cores due to
      • To deploy an App Connector on Azure, recommendation is Standard_F4s_v2 or Standard_D4s_v3
  • Disk Space: 8 GB (thin provisioned)
  • Network Card: 1 NIC (minimum)
Connector Deployment Models and Security
  • The Connector is recommended to be deployed in a HA (high availability) pair
  • Each Connector supports 750 Mbps of traffic when the specifications above are utilized. For additional capacity, multiple Connectors can be used. In this case, they will be automatically load balanced based on incoming session requests from clients.
  • Security – I understand that everything is delivered via 443 – what algorithm is being used? Eg – is there a potential for compatibility challenges with older browsers that do not support TLS 1.2? Appreciate this may be niche but a common issue in the BYOD & public sector space for us.
The connector is NOT accessible directly and does not have any dependencies on browsers. We have not encountered so far any major challenges with old browsers when the end users try to connect to our portal.
Client Capabilities
  • The TransientX Client is a lightweight secure container that providers a rich set of security and ephemeral networking functionality as part of the TransientAccess solution. The Client is managed by the Controller.
Secure Container
  • The Client is functionally a secure container within which any application can be configured to execute. When an application runs inside the secure container, it has access to all OS services. However, these services are limited to execution inside the container. Specifically, the following capabilities are controlled by TransientAccess:

Network: The secure container blocks all network access except for specific DNS and IP routes specified for that customer and user based on their Conditional Access controls. There, applications, including browsers will only access those destinations that are configured

File System: The applications have a replicated filesystem. Any file writes and reads are within the container only. The replication of the open content is configurable by the administrator. This granular control enables the application to execute while its data to fully remain inside the container.

Data Loss Prevention
  • The TransientX Client software provides data loss and leakage prevention features. The feature are designed to ensure the security of the data presented by the application, stored by the application, and input into the application.
  • All DLP features can be configured as policies from the TransientX cloud. The policy scope can be based on per customer, per AD group or per user. Additional Contextual Access controls are available to apply policies based on device, OS and location. Dynamic DLP features are planned to enable additional controls based on user behavioral analysis
DLP Features
  • Data Cut and Paste: Prevents the CUT, COPY or PASTE of data inside an application
  • External storage: USB or other external storage access can be controlled for read-only, write-only, no-access or full read/write
  • Screen capture prevention: Prevents capture of screen content with screen capture tools
  • Screen watermarking: Places a dynamic watermark on content, based on configurable environment variables that can be customized per user
  • Keyboard logger prevention: Prevents malware key logging software from capturing keyboard activity
Data Loss Prevention example scenarios
  • User opens SAP in secure container on their device. Accesses and downloads data but the file cannot be moved outside the container. Is there anything to stop a user opening a new tab in that secure container browser to a file share (e.g. Dropbox) and uploading to the 3rd party from within the container?
    • Such scenarios can be blocked easily using policies.
      Container’s network access is fully under the policy control.
  • Similarly, can a user import a file in to the secure container from the local device – pre-empting that there may be a legitimate reason why an organization may wish to do this.
    • Users can use the files outside the container seamlessly. They just can’t move internal files externally.
  • If a user opens Office or SAP from the portal, do they open in separate containers on the end point?
    • Yes.
  • Is so, then I assume it would not be possible to move files or data from one container on an endpoint to another container on an endpoint – is this correct?
    • It is one container per user. So if the user opens SAP and other apps, the apps will share the container and hence be able to access each others’ data.
System Performance and Scale
  • Is there any limit in the number of applications that an organization can provide to its user base?
  • Up to 10,000 applications can be provisioned at this time. App provisioning may be regulated based on license packages.
Client OS Support
  • Windows 10
  • MacOS 11 (Big Sur)
  • iOS
  • Android
  • Linux (future)
  • ChromeOS (future)