XTRA Protection for Workloads, APIs, and Data
Automated Moving Target Defense (AMTD) that prevents attacks on workloads, APIs, and data inside the enterprise.
But XTRA can.
Automated Moving Target Defense (AMTD) that prevents attacks on workloads, APIs, and data inside the enterprise.
But XTRA can.
Secure East-West and North-South traffic with a zero trust
automated moving-target defense
Once an enterprise is registered with Hopr, DevOps staff are trusted to register enterprise workloads and obtain an XTRA 'sidecar' (a container image file from Hopr's repository).
DevOps staff configure XTRA Sidecars with a specific CHIPS algorithm to enable it to communicate with other trusted enterprise workload. Additional Envoy configuration settings are possible, too.
DevOps staff load the XTRA Sidecar container image alongside its registered workload. On first use, the Sidecar builds an ephemeral secret and connects to Hopr to verify operation and trust of the workload.
XTRA's automated moving-target defense is immediately protecting pairs of communicating workloads at every session, whether they operate on-premises, in a commercial cloud, or in a hybrid-cloud environment.
Watch a 7:14 (min:sec)video explaining the DevOps-friendly deployment of XTRA and a demonstration of how it protects workloads from untrusted connections
A comparison of XTRA's features versus four competitor products
XTRA is an acronym for eXceptionally Tamper Resistant APIs. The name reflects the net effect of the many security features provided by Hopr's CHIPS technology when used to protect enterprise workloads and data.
Envoy proxy is open source software developed by the Cloud Native Foundation. It performs many networking functions for workloads using a sidecar pattern. XTRA Sidecars add a custom filter to Envoy.
XTRA is for trusted enterprise workloads only. Enterprise workloads are centrally managed and trusted so they are able to share a CHIPS algorithm with trust and low risk. The verification and trust of external third-party workloads is under development by Hopr.
Only sidecars whose workloads need to inter-operate to perform a service must use the same CHIPS algorithm. Other enterprise workloads/sidecars may be configured with different algorithms for micro-segmentation of enterprise services.
It is symmetric encryption that is made possible by two workloads building an identical key using a CHIPS algorithm. The key is never exchanged or exposed to theft.
The encryption-decryption occurs at Layer 4, the Transport layer. Every IP packet (message headers and bodies) is individually encrypted and decrypted.
No. API keys are still used within messages sent to an API endpoint, but they serve an identification purpose only at the endpoint. They are not needed for security, but are protected because they encrypted in the message so they cannot be sniffed in transit.
Because of XTRA's encryption-decryption approach and high-frequency secrets rotation, only trusted workloads are able to read encrypted messages. All other traffic fails decryption and is blocked from ever reaching the workload (or API endpoint).
Yes. XTRA protects all ingress and egress access to workloads whether or not they are in the same containerized infrastructure or external to it. The only requirement is that the workloads be managed within the enterprise.
Because XTRA encrypts message packets (both headers and message bodies), encrypted traffic must use a Network Load Balancer (NLB). If you require an ALB, then please contact us to discuss your use case.
