Automated Rulesets with Blueprints
One of the benefits of Access Control is the automation for creating rulesets based on the dimensions and attributes detected in your user profiles.
Before we can automate rulesets, we need to enable Attribute sync for the Dimensions that we want to use.
Importing Dimensions and Attributes
When you sync your Directory Source (ex. Okta) for the first time and during each hourly sync, we look at all of the user profiles and get all of the unique Dimensions (keys) and Attributes (values).
We import the name of each of your Dimensions, but do not automatically import the Attribute values unless that Dimension has been enabled with attributes_enabled
to avoid storing data that you don’t want to use for Rule Conditions in Access Control.
We have a list of sensible defaults for each vendor. For Okta Sources, we enable Attributes for the following dimensions:
- Cost Center
- Division
- Department
- Job Title
In other words, we have a dimension database record for Division
and attributes database records for Engineering
, Marketing
, Sales
, and the other divisions in your organization.
Reminder: All of the names come from your profiles and are not pre-generated in Access Control.
Once the sync jobs for Dimensions and Attributes are completed, the jobs for Rulesets will be dispatched.
Ruleset Blueprints
We use Blueprints to define how to automatically create rulesets.
Each Blueprint specifies which Dimension(s) it is monitoring for new or deprecated Attributes. During each sync job, a new Ruleset will be automatically created and published to the Catalog as each Attribute is added. Once a Ruleset is created, it can be attached to any Resource to grant access to the respective Manifest Users.
Single Dimension Blueprints
If you are used to manually creating a group rule for each of your departments, this is now automated for you.
You simply create a Blueprint and attach the Department
dimension to it. A Ruleset will automatically be created for all of your departments automatically.
To help you get started with Access Control, the Dimensions mentioned above already have Blueprints created and you will find these Rulesets in the catalog.
You can easily create a Blueprint for any other dimension that you want to use. If Attributes are not enabled yet for that Dimension, you will be prompted to enable them.
Multi Dimension Granularity
One of the pain points that many administrators face is scalable automation for multi-dimensional (aka. combination) calculations to determine granular teams or job roles.
For example, let’s assume that you can determine the majority of your least privilege job roles with three pieces of information: department, job title, manager. In other words, if the user’s Department is Corporate IT
, their job title is Support Engineer
, and their manager is Jen Barber
, then we know that they are part of the IT Helpdesk team.
The reason we cannot just use job title is that the Customer Support department and Infrastructure department also have team members with the same job title, but are functionally different job roles.
Since most companies are organized functionally and one or more managers own a specific function, it’s clear to say that if you’re on Jen’s team, then we know what your responsibilities are for client device support. If your manager is Eugene Belford, you will have different permissions for mainframe support.
If you’ve tried to implement least privilege before, you have likely defined these groups of users manually or using other creative solutions.
If you’ve ever audited users access, then you likely used pivot tables to filter by department, then manager, then job title to review appropriate access.
Multi Dimensional Blueprints
You can automate this easily using Blueprints by adding each dimension and choosing the hierarchical level that the grouping should be performed by. In most cases, you will work from the largest number of users (first/lowest level) to the smallest (last/highest level).
-
Blueprint (Option 1)
- Dimension Level 1: Department
- Dimension Level 2: Manager
- Dimension Level 3: Job Title
-
Blueprint (Option 2)
- Dimension Level 1: Department
- Dimension Level 2: Job Title
- Dimension Level 3: Manager
There are no repercussions for switching the level order around based on what you think is best at the more granular levels, the Manifest of Users will be the same, it’s just cosmetics for naming and alphabetical sorting.
If you are enable automatic resource creation for the blueprint, the default group/resource name is based on the concatenation of slugs (ex {department}-{managerHandle}-{title}
.
Each Ruleset that is created has a unique signature based on a concatenation of the Attribute IDs. You are free to rename the generated Ruleset or Resource names and slugs based on your own naming convention.
Scoped Dimension
You may not want to create Rulesets for all of your divisions or departments. You can set a specific attribute_id
for the Level 1 Dimension to only create rulesets for the Level 2+ Dimension Attributes.
In the example above, we could either set a specific department (ex. Customer Support
), or add a Division Dimension, set it to Level 1, and set the attribute to (Engineering
) to cover all departments in the Engineering division.
Pre-Release: This feature may be modified to support specific attribute at any dimension level.
Custom String Logic
You may run into cases where you need to do some string manipulation. For example, you may have a job title (Senior Support Engineer
) with a prefix for each level (ex. Intermediate
, Senior/Sr
, Staff
, Principal
, etc.) for RBAC are the same job (ex. Support Engineer
).
You can solve this by pre-creating your own Custom Dimensions and Custom Attributes and use the Custom Dimension for your Blueprint.
Blueprint Dimensions are only a relational mapping and do not have custom string calculation logic.