Introduction to Satori’s Policy Engine
Introduction to Satori’s Policy Engine
Satori’s secure data access platform enables organizations to create policies that enforce access to data stores. Enforcement is achieved by the policy engine which considers information about the requestor’s identity, the request itself (query or API call), and the actual data returned to determine how access should be handled.
The policy engine executes rules defined in the data store setting view. Rules execution is prioritized from the lowest to the highest value. A rule contains a boolean condition and an action. When the boolean condition evaluates to True, the action is taken.
Actions determine how Satori should process data access. Satori supports the following actions:
- Allow - instructs the policy engine to stop processing the subsequent rules and allow data access.
- Alert - instructs the policy engine to continue processing the subsequent rules and generate an incident report in the management console for the current data access.
- Block - instructs the policy engine to stop processing the subsequent rules and to block the data access, returning an error message to the client.
- Masking (coming soon) - instructs the policy engine to apply a transformation on the data before it is returned to the client.
- Terminate (coming soon) - instructs the policy engine to stop processing the subsequent rules and terminate the connection to the data store.
Satori separates tags into two categories: identity tags and data tags. Identity tags provide contextual information about the entity attempting to access the data (e.g. the organizational unit, location, or even a specific account). The data tags give contextual information about the data accessed. The majority of the contextual information is generated by default by our classification engine and can be customized by customers.
Conditions are composed of tags representing various aspects of the data access. For example, the tag identity.principal.name:john@example.com will be available when john@example.com is connecting to the data store.
Conditions are a conjunction of the tags they contain. For a condition to evaluate to True, all tags must exist. The negation of a tag is supported by using the NOT keyword before the tag itself.
Rules are defined in YAML and maintained in the Data Access Policies section of the data store settings view in the management console. The general format is:
| rules: - name: "Rule display name" priority: <0..n> action: <allow |
Let’s look at a few examples:
Allow all traffic
| rules: - name: "Allow all" priority: 0 action: allow |
Block all traffic
| rules: - name: "Block all" priority: 0 action: block |
Alert on access to any PII
| rules: - name: "Alert on access to PII" action: alert data_tags: -"c12n.pii" priority: 0 |
Alert on access to email addresses
| rules: - name: "Alert on access to email addresses" action: alert data_tags: -"c12n.pii.email" priority: 0 |
Block access to passwords except for the admin user
| rules: - name: "Only admins can access passwords" action: block data_tags: -"c12n.password" identity_tags: - "NOT identity.principal.name:admin@example.com" priority: 0 |
Moving Forward
The above examples represent common uses of our policy engine. With a full integration, using the Satori policy engine can provide robust, detailed security that is decoupled from the data warehouse infrastructure. Implementing such policies can transform data access to be more secure and to require less maintenance. To learn more about how we can help you gain these benefits, contact us.
About the author
Yoav Cohen is the Co-Founder and Chief Technology Officer of Satori Cyber. At Satori, Yoav is building the company’s technology vision and leading the research and engineering teams that build the Secure Data Access Cloud. Prior to founding Satori Cyber, Yoav was the Senior Vice President of Product Development for Imperva, which he joined as part of the acquisition of Incapsula, a Cloud-based web applications security and acceleration company, where he was the Vice President of Engineering. Before joining Incapsula, Yoav held several technology leadership positions at SAP.
When he isn’t glued to his laptop or on a whiteboard, Yoav can be found traveling with his wife and four kids in an RV, playing electric guitar or doing laps at the pool. He is still dreaming about building his own Operating System.
Yoav holds an M.Sc in Computer Science from Tel-Aviv University and a B.Sc in Computer Science and Biology from Tel-Aviv University.