Integrations
User and Administrator Authentication
In Hypori, authentication is required when the Hypori client app connects users to their virtual devices, and when administrators connect to the Hypori Admin console via a web browser.
The Hypori client app uses certificate based (mTLS) authentication. The Hypori client creates a certificate when the user first connects to their virtual device. Hypori can also be configured to perform secondary authentication using TOTP from an authenticator app or Biometric authentication. Secondary authentication is configured by administrators within the Hypori console.
Administrators accessing the Hypori Admin Console authenticate using certificates. They can either upload a p12 certificate file via their web browser (most browsers securely store the certificate, so the p12 file only needs to be uploaded once) or use a Common Access Card (CAC) with a CAC card reader for authentication.
User Provisioning
When provisioning user virtual devices, Hypori recommends integrating with an existing customer-managed LDAP server to access user details whenever possible. LDAP connection details are set up by administrators within the Hypori console. Administrators can then query the LDAP server and trigger the provisioning of virtual devices for selected users. Hypori fetches the user’s name, email address, and LDAP Distinguished Name (DN) from the LDAP server and stores a local copy of the user details in Hypori own user account database for ongoing use.
For cases when the customer does not have an existing LDAP server holding user details, Hypori offers an internal LDAP server and tools to add individual users via a web form or bulk add users from a CSV file. Users have a virtual device provisioned when the user’s details are added to the internal LDAP server.
Hypori provides APIs to facilitate the automation of user provisioning, whether using external or internal LDAP servers.
Log Management Systems
Hypori platform provides infrastructure and application logging as part of system health monitoring. We leverage AWS CloudWatch agents for collection of infrastructure logs. Each application/microservice writes to its own log files which are collected by telemetry collector/agent and sent to telemetry backend system.
Infrastructure Logging
We leverage AWS Landing Zone Accelerator (LZA) as a framework for hosting secure cloud workloads. LZA is designed to align with AWS best practices and in conformance with multiple, global compliance frameworks.
LZA uses multiple AWS accounts to isolate different components. Log messages are collected per component and sent to Cloud Watch Log Groups. These log streams are sent to Kinesis Data Stream and Firehose, allowing the logs to collected centrally in a S3 bucket, with directories structured based on scope. Scopes include AWS account level, environment level, and component (Hypori firewall, EKS cluster, TLS Proxy, compute node, etc.).
Application Logging
Application-level logs are also collected from microservices run inside EKS clusters. Each node in the EKS cluster uses agents to collect microservice log files and send them directly to a telemetry backend system (Splunk). Each microservice emits logs in JSON format to stdout, which are then collected by the telemetry agent and forwarded to the telemetry backend system.