You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Copy file name to clipboardExpand all lines: content/docs/data-access/definitions/access-policies.md
+6-22Lines changed: 6 additions & 22 deletions
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -12,34 +12,18 @@ Access Policies control the circumstances under which data can be retrieved or e
12
12
13
13
Access Policies are executed in three places in UserClouds:
14
14
15
-
- Every <<glossary:accessor>> (read path) is associated with an access policy that controls access for each target user record and filters the records in the response accordingly.
16
-
- Every <<glossary:mutator>> (write path) is associated with an access policy that governs whether the write is allowed.
17
-
- Every <<glossary:token>> is associated with an access policy that governs the circumstances in which the token can be exchanged for the original data ("resolved").
15
+
- Every <glossary>accessor</glossary> (read path) is associated with an access policy that controls access for each target user record and filters the records in the response accordingly.
16
+
- Every <glossary>mutator</glossary> (write path) is associated with an access policy that governs whether the write is allowed.
17
+
- Every <glossary>token</glossary> is associated with an access policy that governs the circumstances in which the token can be exchanged for the original data ("resolved").
18
18
19
19
In addition, two special types of access policies are available:
20
20
21
-
-**Column Default Access Policies**: These policies are associated with specific columns and are applied by default to all reads that extract data from those columns. They ensure consistent application of access rules for sensitive data, such as automatically applying a role check to the SSN column. They can be overridden for individual accessors. Learn more [here](https://docs.userclouds.com/docs/protect-a-column-with-defaults).
22
-
-**Global Baseline Access Policies**: These policies are applied by default to all reads, providing a consistent security baseline. For example, a global policy might always require a valid token or restrict access to trusted IP addresses. They cannot be overridden. Learn more [here](https://docs.userclouds.com/docs/apply-global-protection-policies).
21
+
-**Column Default Access Policies**: These policies are associated with specific columns and are applied by default to all reads that extract data from those columns. They ensure consistent application of access rules for sensitive data, such as automatically applying a role check to the SSN column. They can be overridden for individual accessors. Learn more [here](https://docs.userclouds.com/docs/protect-a-column-with-defaults).
22
+
-**Global Baseline Access Policies**: These policies are applied by default to all reads, providing a consistent security baseline. For example, a global policy might always require a valid token or restrict access to trusted IP addresses. They cannot be overridden. Learn more [here](https://docs.userclouds.com/docs/apply-global-protection-policies).
23
23
24
24
Access policies provide central, fine-grained control over sensitive data access. They can evaluate purpose, identity, authorization, location, , and more. They can range from simple "always allow resolution" policies to complex evaluations.
"Access policies give you central, fine-grained control over sensitive data access. Policies can evaluate purpose, identity, permissions, location, expiration timelines, rate limits and more."
34
-
],
35
-
"align": "center",
36
-
"sizing": "400px",
37
-
"caption": "Access policies give you central, fine-grained control over sensitive data access. Policies can evaluate purpose, identity, permissions, location, expiration timelines, rate limits and more."
38
-
}
39
-
]
40
-
}
41
-
[/block]
42
-
26
+
Accessors are configurable APIs that allow a client to retrieve data from the user store. Accessors are intended to be use-case specific. For example, you might configure two separate accessors `GetEmailForMarketing` and `GetEmailForAuthentication`. They enforce data usage policies and minimize outbound data from the store for their given use case.
12
12
13
-
As an example of data minimization, you might configure an accessor called `GetPhoneCountryCodeForAnalytics` that returns the country code of a user's phone number when called, instead of the raw phone number. This reduces the sensitivity of the data outside your store, minimizing your surface area for an attack and simplifying compliance.
13
+
As an example of data minimization, you might configure an accessor called `GetPhoneCountryCodeForAnalytics` that returns the country code of a user's phone number when called, instead of the raw phone number. This reduces the sensitivity of the data outside your store, minimizing your surface area for an attack and simplifying compliance.
14
14
15
15
Accessors can be configured to access either live or soft-deleted data. Soft-deleted data is data that has been deleted but is temporarily retained for a narrow set of purposes, e.g. fraud investigations. See [Data Lifecycle](https://docs.userclouds.com/docs/data-lifecycle) for more details.
1. Data, <<glossary:consent>>s and <<glossary:purpose>>s are stored inside the safety layer boundary (either in UserClouds User Store or an owned-and-operated database like RDS)
38
24
2. Data consumers request access by sending context, like purpose or identity, to a use-case specific <<glossary:accessor>> API
39
25
3. Several access policies are evaluated for each user record, using the data passed in <<glossary:context>> and data in the user object:
40
-
1.**Global baseline policy for accessors**: Applied to ensure baseline security. Learn more [here](https://docs.userclouds.com/docs/apply-global-protection-policies).
41
-
2.**Column-default access policies**: Column default policies for all columns accessed by the accessor are applied, unless overridden. Learn more [here](https://docs.userclouds.com/docs/protect-a-column-with-defaults).
26
+
1.**Global baseline policy for accessors**: Applied to ensure baseline security. Learn more [here](https://docs.userclouds.com/docs/apply-global-protection-policies).
27
+
2.**Column-default access policies**: Column default policies for all columns accessed by the accessor are applied, unless overridden. Learn more [here](https://docs.userclouds.com/docs/protect-a-column-with-defaults).
42
28
3.**Accessor-specific access policy composition**: Applied in addition to the above policies.
43
29
4. User data is further filtered according to whether the users have consented to the accessor's data processing purpose.
44
30
5. For records where access is granted, the accessor's <<glossary:data transformer>>s transform each column of the outbound data, minimizing the data for the given use case. If no transformer is specified for a given column, the column's default transformer is used. Learn more [here](https://docs.userclouds.com/docs/protect-a-column-with-defaults).
@@ -48,7 +34,7 @@ Accessors can be configured to access either live or soft-deleted data. Soft-del
48
34
At creation time, each accessor is associated with a user record <<glossary:selector>>, a set of <<glossary:column>>s, a set of <<glossary:data transformer>>s, a <<glossary:purpose>> and an <<glossary:access policy>>.
49
35
50
36
- The user record <<glossary:selector>> is a SQL-like clause that specifies which records the accessor should return data for, based on an array of values that are passed at execution time. The accessor's response will only include users that have consented to the accessor's purpose for all non-<<glossary:system column>>s used in the selector. Since UserClouds does not store consents for <<glossary:system column>>s, they can be referenced in the selector regardless of accessor purpose / user consents.
51
-
- The columns indicate which data fields the accessor will retrieve.
37
+
- The columns indicate which data fields the accessor will retrieve.
52
38
- Each column is associated with a transformer, which tokenizes, minimizes or otherwise obscures the outbound data from that column.
53
39
- The purpose is selected from your company's list of data processing purposes. This indicates what the accessor will be used for, e.g. marketing. The accessor will run a <<glossary:purpose check>>, filtering out user records and data for which the user has not consented to the specified purpose across all columns. The accessor's response will only include users that have consented to the accessor's purpose for all columns being retrieved, and all non-system columns used in the selector. Learn more [here](https://docs.userclouds.com/docs/purpose-and-consent).
54
40
- The access policy determines the circumstances in which the data can be retrieved. Access policies run on each user record and filter out user records which fail the access policy.
Transformers are re-usable functions that manipulate data in UserClouds. They allow you to minimize the data that you pass or store for each use case. This is key for complying with the data minimization principles in regulations like GDPR.
12
12
13
-
[block:image]
14
-
{
15
-
"images": [
16
-
{
17
-
"image": [
18
-
"https://files.readme.io/6d22973-Frame_1006.png",
19
-
"",
20
-
"Transformers can be arbitrarily smart about how they obfuscate data."
21
-
],
22
-
"align": "center",
23
-
"sizing": "400px",
24
-
"caption": "Transformers can be arbitrarily smart about how they obfuscate data."
25
-
}
26
-
]
27
-
}
28
-
[/block]
13
+
29
14
30
15
31
16
Transformers allow you to retain select structure and information from the raw data for different use cases, like sorting alphabetically, zip code analysis or simply flowing through your systems without triggering validation errors. For example, if you want to conduct analysis assessing the differences in behavior between children and adults, you may use a data transformer to pass a string indicating `child` or `adult`, instead of pulling raw Date of Birth from the store.
@@ -45,22 +30,7 @@ In addition, column default transformers provide a way to consistently apply tra
45
30
46
31
Transformers range from the simplest UUID function that replaces any given data with a unique identifier, to custom-written Javascript that runs in a carefully-controlled sandbox.
"One simple transformer receives raw data, and creates a UUID token."
56
-
],
57
-
"align": "center",
58
-
"caption": "One simple transformer receives raw data, and creates a UUID token."
59
-
}
60
-
]
61
-
}
62
-
[/block]
63
-
33
+
64
34
65
35
Let’s look at four possible transformers, to see how transformers work.
66
36
@@ -93,22 +63,7 @@ A transformer consists of:
93
63
-`Transform Function` - a transform function with the signature `func(data Object, parameters Object) (Token | error)`
94
64
-`Transform Parameters` - a static JSON object (not containing un-encoded PII) that is available at runtime, allowing you to parameterize and reuse functions like "obfuscate all but the first X letters of these emails"
95
65
96
-
[block:image]
97
-
{
98
-
"images": [
99
-
{
100
-
"image": [
101
-
"https://files.readme.io/f14e1c2-image_1.png",
102
-
null,
103
-
"The PreserveCommonValue parameter allows you to optionally preserve common email domains (like gmail.com). Rare domains, like userclouds.com, will be obscured."
104
-
],
105
-
"align": "center",
106
-
"caption": "The PreserveCommonValue parameter allows you to optionally preserve common email domains (like gmail.com). Rare domains, like userclouds.com, will be obscured."
107
-
}
108
-
]
109
-
}
110
-
[/block]
111
-
66
+
Copy file name to clipboardExpand all lines: content/docs/data-access/how-to-guides/create-a-transformer.md
+3-31Lines changed: 3 additions & 31 deletions
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -12,21 +12,7 @@ Transformers are re-usable JavaScript functions that manipulate data in UserClou
12
12
13
13
Transformers can be managed in the User Store page of the UserClouds Console, or via the UserClouds API.
14
14
15
-
[block:image]
16
-
{
17
-
"images": [
18
-
{
19
-
"image": [
20
-
"https://files.readme.io/d78d5ab-image_8.png",
21
-
null,
22
-
"Transformers can be managed from the Policies page in the UserClouds Console"
23
-
],
24
-
"align": "center",
25
-
"caption": "Transformers can be managed from the Policies page in the UserClouds Console"
26
-
}
27
-
]
28
-
}
29
-
[/block]
15
+
30
16
31
17
32
18
## How Transformers Work
@@ -49,7 +35,7 @@ Remember to convert these strings into the JavaScript objects or primitives that
49
35
50
36
## Creating a transformer in UserClouds Console
51
37
52
-
To create a transformer in UserClouds, go to the Policies page, accessible from the sidebar in Console, and click Create Transformer.
38
+
To create a transformer in UserClouds, go to the Policies page, accessible from the sidebar in Console, and click Create Transformer.
53
39
54
40
**1 Name and Describe the Transformer**
55
41
@@ -71,21 +57,7 @@ Transformers should be written to act on a single piece of data. UserClouds nati
71
57
72
58
Finally, test your transformer by adding raw data to the "Data" field and clicking "Run Test". Once you are happy with the test results, click "Save Transformer" to finish.
Copy file name to clipboardExpand all lines: content/docs/data-access/how-to-guides/create-an-access-policy.md
+8-78Lines changed: 8 additions & 78 deletions
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -16,21 +16,7 @@ New access policies can be created by writing a new policy or template from scra
16
16
17
17
Access policies and templates are managed under the Access Rules element in the UserClouds Console sidebar.
18
18
19
-
[block:image]
20
-
{
21
-
"images": [
22
-
{
23
-
"image": [
24
-
"https://files.readme.io/184bfbc-image_4.png",
25
-
null,
26
-
"Policies and templates can be managed from the Policies page, accessible from the sidebar of UserClouds Console."
27
-
],
28
-
"align": "center",
29
-
"caption": "Policies and templates can be managed from the Policies page, accessible from the sidebar of UserClouds Console."
30
-
}
31
-
]
32
-
}
33
-
[/block]
19
+
34
20
35
21
36
22
## Creating Policy Templates in the UI
@@ -41,42 +27,14 @@ Policy templates are parametrizable functions that can be parametrized to create
41
27
42
28
Specify a name, a description and a javascript function for your policy. The javascript function may optionally accept parameters, which you can test below.
Use the "Test Your Draft" card at the bottom of the page to test your policy template. You can add test parameters to simulate turning the policy template into an access policy, and then test that access policy with test context. The interface will show the result of your test as "Access Allowed" or "Access Denied".
"The \"Test Your Draft\" card allows you to parametrize your draft template (creating an access policy) and then test that access policy with test context."
73
-
],
74
-
"align": "center",
75
-
"caption": "The \"Test Your Draft\" card allows you to parametrize your draft template (creating an access policy) and then test that access policy with test context."
76
-
}
77
-
]
78
-
}
79
-
[/block]
37
+
80
38
81
39
82
40
## Creating Access Policies in the UI
@@ -87,42 +45,14 @@ To create a new access policy, click "Create Policy" from the Policies page, acc
87
45
88
46
**2 Set your <<glossary:access policy>> name and description**
89
47
90
-
Next, add a name and a description for your policy.
91
-
92
-
[block:image]
93
-
{
94
-
"images": [
95
-
{
96
-
"image": [
97
-
"https://files.readme.io/e0bf498-image_6.png",
98
-
null,
99
-
"The Create Access Policy page in UserClouds Console."
100
-
],
101
-
"align": "center",
102
-
"caption": "The Create Access Policy page in UserClouds Console."
103
-
}
104
-
]
105
-
}
106
-
[/block]
48
+
Next, add a name and a description for your policy.
49
+
50
+
Next, compose the policy from one or more policies and templates in the "Compose Policy" card.
@@ -149,7 +79,7 @@ Nice job! You created an access policy.
149
79
150
80
The checkAttribute function runs a permission check against the UserClouds authorization graph. If you are using UserClouds for authorization as a service, this can verify if a user has the necessary permissions. You can read more about this in the Authorization Documentation.
151
81
152
-
### Example:
82
+
### Example
153
83
154
84
**Use Case: Does the calling user have view permission on the target user?**
0 commit comments