SGNL Policy Overview

SGNL Policies are designed to be human-readable sentences that define whether a principal (e.g. a user, service, robot) can perform some action (e.g. read, write, update, view) on an asset (e.g., a customer account, a document, a piece of infrastructure).

Policy Versions are applied to your Integrations (e.g. apps, services, infrastructure). When you create a new policy, you create version 1. Any updates or edits you make to that policy going forward, create new Policy Versions (i.e. 2, 3, and so on).

You can apply Policy Versions in Enforced mode. Doing so will apply the decision of a given version to an integration(i.e. resulting in an allow or deny decision). You can also apply Policy Versions to an integration in Simulated mode. In this mode, a policy version will only simulate a policy decision (resulting in only a log of the decision that would have been made, to be used for what-if analysis or debugging).

The basic building blocks of a Policy Version are Policy Snippets – small, reusable components that describe the different parts of a policy. Policy Snippets have an attribute called a Scope, that helps to define how and where within a policy you can use the Snippet. The Scopes available for a Policy Snippet include:

• Principal - Defines the population of principals (e.g. users, services, robots) that a policy will apply to. It may look at an attribute or relationship of users in order to define a cohort, e.g. All Users in a Corporate Azure AD that have a department of ‘Engineering’.
• Action - Defines the actions that SGNL receives from your integration at the Access Service. These might include simple actions such as “read” or “write”, or more complex actions such as “issue refund” or “createUser”.
• Asset - Defines the resource(s) that need protecting within a specific Integration. These may be individual customers, accounts, products, or something else. Asset-scoped snippets can increase the specificity of policies, e.g. Customer data for customers with more than 10,000 employees.
• Condition - Defines the conditions with which to allow or deny. Condition snippets might look to ensure that a given principal has an appropriate business justification (e.g. through a ServiceNow Case assigned for a given customer), or might look to ensure the user is in the right location, on a trusted device.

Similar to Policies and Policy Versions - Policy Snippets are version-controlled. Any updates or changes result in a new Policy Snippet Version.

When creating a new Policy, you create a new Policy Version that gets applied to your Integrations. This Policy Version is composed of Policy Snippets, each of which have a specific Policy Snippet Version.