We are excited to introduce our opensource zero trust service access project - TRASA. It essentially:

  • Is a Layer 7 protocol, user identity, and privilege aware access proxy.
  • Can enforce security policies (time, file transfers, location, context, 2FA) to SSH, RDP, web, database access.
  • Can enforce access policy based on the security hygiene of user devices.
  • Add two-factor authentication agent (native integration) to protect console access to SSH, RDP, and hardware appliance.

These features cumulatively enable zero trust access control security modal to protect remote access to server (Windows, Linux, Unix, Hardware appliance) and services(Web, SSH, RDP, and Database).

Why and when would you need this?

Immediate use cases and benefits for TRASA includes:

  • Secure remote access to internal infrastructure and services by the internal team or 3rd party vendors.
  • Secure machine access (access made by other tools, API clients,  systems).
  • Enforce modern security features and best-practice security for remote access.
  • Born to protect cloud-native workflows, but equally adapts to protect legacy infrastructure as well.

How TRASA Works

TRASA controls users (DevOps, Software, Marketing teams, 3rd party vendors, etc.) access to services (SSH, RDP, Web, Database). The decision to control access depends on access policy and access privilege defined by administrators.

Once TRASA is installed and configured, users will  access servers and services through TRASA access proxy.

Users access server and services via TRASA access proxy where security policies are enforced. 

Quick introduction to components of TRASA project

  1. Providers - These are a collection of user identity (Active Directory, Okta, Onelogin), service identity (AWS, GCP), Secrets provider (Hashicorp Vault, Passbolt), which provides data related to objects and entities TRASA needs to protect. By default, TRASA offers features to replace these providers.
  2. Access Proxy - A reverse proxy that is Layer 7 aware (SSH, RDP, HTTPs, Database) and is Identity aware (data from providers). Access proxy controls access based on policies and privileges defined by administrators.
  3. Policies - Add time, location, context, and device hygiene based security policies.
  4. Two factor authentication agents - Native agents for windows and Linux systems to add native two factor authentication protection (at the operating system level).
  5. Device Hygiene Agents - Agents that collects security hygiene from user workstation devices (laptops, PC).
  6. Radius server - Add native security policies to servers that do not support agent installations.  
  7. Mobile app - Mobile authenticator app for TOTP and TRASA push U2F. It is also used to collect security hygiene from the user's mobile device.

How will users access the services?

Currently supported methods of connection:

  • RDP: Only possible from TRASA RDP client (web application, access from the browser)
  • SSH: TRASA ssh client (web application, access from the browser ), *nix terminal ssh client,  putty, bitvise, moba xterm. Basically, any ssh client should work.
  • Web (HTTP): Normal as you would browse web page (session is managed with TRASA browser extension
  • Database (MySQL only): Using MySQL client you already use.

What's next for TRASA?

An exciting Future ahead...

We have an exciting roadmap for TRASA ahead. Our next first milestone includes extending integration with the ecosystem so that everyone can use TRASA to protect remote access in any infrastructure and any use case. Next, we will be working on enhancing more security and compliance capabilities of TRASA. If you have any specific use case that TRASA does not support yet, reach out to our team via Github or contact us at trasa@seknox.com. As an opensource project, your contribution and voice matters.

P.S. If you like the project, don't forget to star ⭐️ it on Github :)