How the Satori Data Access Controller Works
At its core, the Satori architecture is a transparent proxy service to which data consumers connect rather than connecting to the data store itself. Satori is not a query engine, a proprietary API, or an alternative DB driver, but rather it is a security layer that organizations deploy on top of their data stores in a transparent and noninvasive manner. Satori operates at the network level but speaks the data store’s language, allowing it to deliver a rich set of capabilities without changing the configuration of any data sources.
When administrators add a new data store to Satori, a new data store endpoint is generated, and users connect to this new endpoint instead of to the original data store hostname.
Since Satori is transparent for its data users, it does not require making any changes to business intelligence (BI) or analytics tools, so data analysts and scientists are able to continue utilizing data in the exact same manner. Since Satori is also transparent to data stores, the mechanisms of authentication, authorization and auditing remain unchanged. The Satori component that enables this access control flexibility is known as a DAC, or Data Access Controller. For those with a background in application delivery (such as myself) this component may remind you of an ADC, or Application Delivery Controller, which is essentially a fancy name for an application layer load balancer. Indeed, we did borrow successful concepts from the ADC architecture in order to design a modern data access layer. To put this concept in simple terms, in the same way that one configures ACLs (Access Control List) that apply to all applications in their LB (Load Balancer), Satori users can configure access policies that apply to all data locations by using a DAC.
Satori’s engine is deployed in the DAC. DACs can be consumed as a service, or they can be customer hosted. DACs autoscale to support any number of users and data stores, and customers can use as many DACs as they need based on their data stores footprint and the distribution between various public clouds and regions.
Data Access Controller As a Service
For enterprises who wish to completely offload any operational overhead of hosting a DAC, Satori provides a DAC-as-a-service deployment option. Organizations do not need to manage compute, storage, software upgrades or patching—Satori handles all of these aspects. Organizations use a DAC in the same public cloud region as the data store, so the data never leaves the region. DAC-as-a-service supports any type of data store, IaaS, PaaS, and DBaaS.
Customer Hosted Data Access controller
For organizations that seek to own all aspects of data operations and require that data remain within their VPC, Satori provides a customer-hosted DAC. Customer-hosted DACs are identical to SaaS DACs except that they require a one-time deployment and the management of the underlying infrastructure. Software updates are periodic, and we use helm-chart-based deployment on your on-prem Kubernetes cluster, so customers who choose the hosted DAC option can be confident that their Satori DAC is self-sufficient and that data never leaves their VPC.
To learn more about the different deployment options visit our documentation site.
Schedule a Demo
Ready for better data access governance and universal data protection? Schedule a quick, private demo today!
Recent blog posts
- Introducing Data Access Policy as Code With Satori Terraform Provider
- Satori's New DataSecOps Policy Engine Will Streamline and Revolutionize Data Security for Large Enterprises
- Data Classification With Satori
- Data Classification Best Practices - Part 2
- Snowflake & Looker DataSecOps with Satori
- Data Classification Best Practices - Part 1
Posts by Tag
- Access Control
- Data Governance
- Data Protection
- Snowflake Data Warehouse
- data security
- data democratisation
- AWS Redshift
- Data Science
- Sensitive Data
- Data Classification
- Snowflake security
- Data Policy Management
- Policy Management
- self service access control
- Data Masking
- Human Element
- Least Privileges
- Policy Engine
- RSA ISB
- Redshift Security
- Redshift data access
- Row Level Security
- Snowflake Roles
- role hierarchy
- rsa conference
- rsa innovation sandbox
- snowflake stages