- Identity – Satori monitors the creation of new connections to data stores and uses that information to look up the profile of the user in the Identity and Access Management (IAM) system of the organization.
- Data – Satori looks at both the query and the result set to classify the transaction for sensitive information, like names, email addresses and social security numbers.
- Behavior – Satori profiles real-user access in the environment to know what normal access looks like while also delivering a rich set of out of the box behavioral policies that promote good data access hygiene.
How do I start using Satori?
To start routing traffic through Satori, you select the type of data store in the Satori management console and enter its hostname. Satori generates an alternative hostname that points to the proxy service. You can use the new hostname right away in any query tool of your choice, in parallel to your other users who are still using the original hostname.
Original and Satori generated hostnames in the Satori Management Console
Using the Satori generated hostname in SQL Workbench
Dynamic InliningSatori’s architecture is optimized for reliability and low latency. Our approach to solving for that is to separate data traffic into two data paths: proxying and analysis. Proxying means the transfer of bytes from data consumers to data stores and analysis is where we run our algorithms and policy engine. Each path is handled by a separate set of compute resources and, more importantly, separate software with a different codebase and release cadence. For proxying, Satori uses NGINX, a well-known proxy software that has become ubiquitous across the web due to its flexibility and reliability. As an example, Cloudflare uses NGINX to power its Content Delivery Network and other HTTP-related services. We use NGINX’s out-of-the-box capabilities to proxy both TCP and HTTP traffic and to terminate TLS connections. Every Satori deployment includes a highly-available set of NGINX proxy servers as containers in a Kubernetes cluster. Connections between data consumers and data stores only go through NGINX. We’ve very creatively coined our analysis software as the ‘Analyzer’. We built Analyzer using Rust, a system programming language focused on safety, concurrency and high performance. Analyzer’s software is not in the data path between data consumers and data stores. Instead, it receives traffic captures from NGINX using a module we built to facilitate that, and processes them asynchronously. Depending on the policies that are applied to the connection, Analyzer can instruct NGINX to terminate the connection, block a query, return an empty result set or mask sensitive data.
The architecture of the Satori platform
Get our solution brief and stay tuned for future blogs where we share more details about how Satori’s Context, Policy and Analytics engines work.