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. 

Flow of policies in Satori's policy engine

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.

Boolean tags in Satori's policy engine

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|alert|block>
        data_tags:
          - [NOT] <data_tag>
    ...
          - [NOT] <data_tag>
        identity_tags:
          - [NOT] <identity_tag>
    ...
          - [NOT] <identity_tag>

      - name: "Rule display name"
    ...

 

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.