SGNL Policy Overview

The following diagram shows how policies are structured in SGNL:

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 Protected Systems (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).

Policy Version Modes: You can apply Policy Versions in Enforced mode. Doing so will apply the decision of a given version to a Protected System (i.e. resulting in an Allow or Deny decision). You can also apply Policy Versions to a Protected System 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).

Building Blocks of Policy Versions

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 Protected System 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 Protected System. 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. The Protected System can then be updated to use the new Policy Version. This Policy Version is composed of Policy Snippets, each of which have a specific Policy Snippet Version.