Organizational units

Organizational units (OU) allow you to create logical buckets of assets within your organization made up of groupings such as departments, so users can manage the assets under separate data sources relevant to their work. These groupings are called "data groups". You can group data sources in the way that users access information, such as by AWS accounts. Once the data groups are configured, you can create organizational units. For example, you can give developers access to only the development account, and not to the production account.

Until organizational units are configured, you only have a Global organizational unit which provides all your users full visibility of all your assets and policies.

Creating organizational units consists of the following high level steps:

1. Configure data groups that map to the way your company groups data or departments. Examples include separate AWS accounts for developers and production, or VMware VM folders to segregate different tenants or departments.
2. Create organizational units. Provide a name and description, and the data source to include in this workspace.
   1. Choose the specific assets (such as AWS accounts) to assign to this organizational unit.
   2. Select users to add to the organizational unit. By default, all users that have access to the Global organizational unit also have access to the new organizational unit being created.

When you create an organizational unit, assets are added automatically, if they are contained within the selected data group. For example, if your data group for VMware is VM Folders, all VMs contained in those folders are included in the organizational unit by default and any new VM that is added underneath that VM folder is also added to the organizational unit.

Organizational unit hierarchy

Organizational units are configured in a hierarchy. The Global organizational unit includes all assets by default, and all organizational units you create are children of the Global organizational unit. You can add assets, policies, and users to an OU.

You can also create additional organizational units under an existing OU. Any OUs that are at the same level in the hierarchy are considered siblings.

Assets and organizational unit hierarchy

Assets can only belong to one organizational unit hierarchy.

In the following example, OU1 is the parent OU. OU1_a is created as a child of OU1, so OU_1a would inherit the users assigned to OU1, and can share assets with OU1.

OU1_a is the child organizational unit of OU1, and OU2_a is the child organizational unit of OU2. OU2 and OU2_a (parent and child) can share assets, but you cannot share assets between OU1 and OU2 (siblings).

If you assigned an asset to OU1 and OU2, this would create a conflict, and the asset would be inherited by the Global OU until the conflict is resolved. The following diagram is an example of this conflict.

In the case illustrated in the diagram, there are three tags that are part of an entity (VM1), and these tags are placed in sibling OUs (OU1, OU2, and OU3). This creates a conflict. There is a further conflict in the next level of the hierarchy, since tags from the same entity are now shared between another set of siblings (OU-0 and OU-01). Because of this conflict, the tags are inherited up to the Global OU.

Organizational units and policies

When you create a policy in an organizational unit, that policy is available to all child OUs of that OU to view and apply to protect it's assets, but a child OU cannot edit a policy of it's parent OU. In order to edit the policy, you must be in the OU that created the policy, as indicated by the edit icon. You can apply policies to assets down the hierarchy, but not up the hierarchy.

If assets in a child OU are protected by a policy rule from the parent OU, the policy in the rule that protects the asset is visible to the child OU.

For On-demand backups, the Take Backup button is available to a parent OU for any child OU assets. A parent OU can request an On-demand backup of any child OU asset.

Your assigned role determines the actions you can do in the Clumio UI. For example, users with the Reporting/Audit Admin role can only view policies, not edit them. To learn more about roles, see Roles.

Organizational unit management

Editing an organizational unit

Once you have created an organizational unit, you can edit the following options.

• Change name and description.
• Add additional data sources.
• Add or remove assets.
• Invite or remove users.
• Add or remove API Service Tokens.

Moving an AWS account to another OU

You can change an AWS account’s organizational unit directly from the AWS > Accounts page. Click the edit icon in the Actions column for the account you want to move.

Deleting an organizational unit

In order to delete an organizational unit, you need to be in the parent organizational unit workspace. In the following example, OU1 is at level 1 (parent) and OU1_a is at level 2 (child). In order to delete the OU1_a organizational unit, you would need to be in the OU1 workspace.

An organizational unit cannot be deleted if any of the following are true:

• It is the Global organizational unit.
• It has at least one child organizational unit.
• If deleting the organizational unit leaves any user without membership in an organizational unit.
• If deleting the organizational unit leaves and API service token without membership in an organizational unit.
  For example, if User A only has access to OU1, then OU1 cannot be deleted. In this case, the administrator can assign the user to another organizational unit before deleting OU1 Similarly, if an API service token has been created in OU1, the administrator can assign the service token to another organizational unit before deleting OU1.