A data security policy helps you keep your organization’s data secure by letting you govern how users, apps, and people outside and within your organization can interact with content such as Confluence pages and Jira issues.
Data security policies adopt a content-centric approach to regulating the utilization of your data within Atlassian products. How data security policies work
There are three main componenets of a data security policy:
policyCoverageLevelruleresourcesThis outlines the range of data that the policy will encompass.
WORKSPACE: A component within a product that provides structure and organization of spaces and projects. This level applies to a product or site, such as a Confluence or Jira instance, where the policy is implemented.
CONTAINER: An entity within a product that provides structure and organization for objects and the second layer of the content hierarchy like a Confluence Space or Jira Project.
CLASSIFICATION: Organizational classification levels enable users to categorize their content. By integrating classification with a policy, it can be applied across Confluence, Jira, and Jira Service Management. For instance, an organization with a Confluence space requiring page classification.
Leaving the policyCoverageLevel blank indicates that it is unassigned, and it can be changed to any other policyCoverageLevel. However, once policyCoverageLevel is set to WORKSPACE, CONTAINER or CLASSIFICATION, it is fixed and cannot be changed.
The rule define the specific rules or constraints that are to be applied to the data under the given policyCoverageLevel.
The rule object might be set to empty, indicating that no specific rule will be enforced. It's important to note that not every rule is applicable across all policyCoverageLevel. A detailed matrix showing which rules are applicable at each level of coverage can be accessed through the DSP Rules/Coverage Matrix
The structure consists of three key components:
This is a boolean rule, when activated by setting it to true, blocks the ability to export pages. Understand more about preventing data export
Example request:
1 2curl --request POST \ --url '<https://api.atlassian.com/admin/control/v2/orgs/{orgId}/policies>' \ --header 'Authorization: Bearer <access_token>' \ --header 'Accept: application/json' \ --header 'Content-Type: application/json' \ --{"data": { "type": "policy", "attributes": { "type": "data-security", "name": "test policy", "status": "enabled", "metadata": { "policyCoverageLevel": "WORKSPACE", "description": "Some description" }, "rule": { "export": { "blockPageExport": true } } } }
This is a boolean rule that, if set to true, restricts the sharing of individual pages. Understand more about controlling public links
Example request:
1 2curl --request POST \ --url '<https://api.atlassian.com/admin/control/v2/orgs/{orgId}/policies>' \ --header 'Authorization: Bearer <access_token>' \ --header 'Accept: application/json' \ --header 'Content-Type: application/json' \ --{"data": { "type": "policy", "attributes": { "type": "data-security", "name": "test policy", "status": "enabled", "metadata": { "policyCoverageLevel": "WORKSPACE", "description": "Some description" }, "rule": { "publicLinks": { "block": true } } } }
This is a boolean rule that, when activated by setting it to true, restricts anonymous users from accessing pages or resources. Understand more about anonymous access
Example request:
1 2curl --request POST \ --url '<https://api.atlassian.com/admin/control/v2/orgs/{orgId}/policies>' \ --header 'Authorization: Bearer <access_token>' \ --header 'Accept: application/json' \ --header 'Content-Type: application/json' \ --{"data": { "type": "policy", "attributes": { "type": "data-security", "name": "test policy", "status": "enabled", "metadata": { "policyCoverageLevel": "WORKSPACE", "description": "Some description" }, "rule": { "anonymousAccess": { "block": true } } } }
This rule stands apart from the others. You have the option to either block all apps from accessing data by setting it to true, which prevents any app from gaining access. Alternatively, you can specify the names of the apps that you wish to block or allow. Understand more about blocking app access
appAccess: This is the main key that defines access rules for applications. Only one of the options below can be non-empty.
blockAll: This indicates whether all applications are blocked or not.blockedApps: This is a list (array) of apps that are blocked from access specific containers, the rest of apps will be allowedallowedApps: This is a list (array) of apps that are allowed to access specific containers, the rest of apps will be blocked.1 2curl --request POST \ --url '<https://api.atlassian.com/admin/control/v2/orgs/{orgId}/policies>' \ --header 'Authorization: Bearer <access_token>' \ --header 'Accept: application/json' \ --header 'Content-Type: application/json' \ --{"data": { "type": "policy", "attributes": { "type": "data-security", "name": "test policy", "status": "enabled", "metadata": { "policyCoverageLevel": "WORKSPACE", "description": "Some description" }, "rule": { "appAccess": { "blockAll": true, "blockedApps": "allowedApps": } } } } }
You can submit multiple rules in a single request as long as they do not override each other and share the same policyCoverageLevel. Manage date security policy rules
1 2curl --request POST \ --url '<https://api.atlassian.com/admin/control/v2/orgs/{orgId}/policies>' \ --header 'Authorization: Bearer <access_token>' \ --header 'Accept: application/json' \ --header 'Content-Type: application/json' \ --{"data": { "type": "policy", "attributes": { "type": "data-security", "name": "test policy", "status": "enabled", "metadata": { "policyCoverageLevel": "CONTAINER", "description": "Some description" }, "rule": { "publicLinks": { "block": true }, "anonymousAccess": { "block": true }, "appAccess": { "blockAll": true, "blockedApps": "allowedApps": } } } } }
Show me how to manage data security policy rules
A resource refers to any asset, entity, or item that the policy aims to govern, regulate, or protect. Resources can be associated with different levels of policy coverage which determines the scope of data covered by the policy. Each resource is associated with a unique resource ARI, and the policy can include operations to add or remove these resources as needed.
There are limits to the number of resources that can be added for each policyCoverageLevel.
Explore and learn with our cookbook and create a data security policy
Rate this page: