diff --git a/app/(home)/page.tsx b/app/(home)/page.tsx index 4564639..f2aa9a6 100644 --- a/app/(home)/page.tsx +++ b/app/(home)/page.tsx @@ -24,7 +24,7 @@ export default function HomePage() {
Read Documentation diff --git a/content/_dangling-articles/key-concepts.mdx b/content/_dangling-articles/key-concepts.mdx deleted file mode 100644 index 7f07491..0000000 --- a/content/_dangling-articles/key-concepts.mdx +++ /dev/null @@ -1,25 +0,0 @@ ---- -title: "Key Concepts" -slug: "key-concepts" -excerpt: "" -hidden: true -createdAt: "Fri Apr 05 2024 21:34:13 GMT+0000 (Coordinated Universal Time)" -updatedAt: "Tue Sep 10 2024 18:33:44 GMT+0000 (Coordinated Universal Time)" ---- -UserClouds’s is a safety layer for data protection. The layer mediates access to sensitive data, enforcing best practices in security, privacy and governance. It can be deployed in several distinct areas of your stack, depending on your use case. - -The Safety Layer allows you to define custom access paths, called **accessors** (for reading data) and **mutators** (for writing data) - see below for more detail. **Access policies** (like `IsRoleEngineer` and `IsIPTrusted`) describe a set of rules around reading and writing data. Policies control the circumstances in which data can be retrieved from and written to the store. **Data transformers** (like `BirthdayToAge` or `PhoneToAreaCode`) obscure, minimize or tokenize outbound data for a given use case. - -# Reading Data - -Data can be retrieved from the store using **accessors** (custom read paths that you define). Accessors are intended to be use-case specific, e.g.`GetEmailForMarketing` or `GetNameAndPhoneForSupport`. They enforce data usage policies and minimize outbound data from the store for their given use case. Each accessor is associated with a **user record selector**, a set of **columns**, a set of **data transformers**, a **purpose**, an **access policy** and an **optional token resolution policy** (see below). The user record 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 columns indicate which data fields the accessor will pull. Each column is associated with a transformer, which transforms, minimizes or obscures the outbound data from that column. The purpose indicates what the accessor will be used for, e.g. marketing. The accessor will filter out user records where the user has not consented to the specified purpose. The access policy determines the circumstances in which the data can be retrieved. - -# Writing Data - -New data can be written to the store using **mutators** (custom write paths that you define). Examples of mutators are `SetProfile` and `SetEmailAndPhoneNumber`. Each mutator is associated with a **user record selector**, a set of **columns**, a set of **validators** and an **access policy**. The record selector is a SQL-like clause that specifies which records the mutator should edit data for, based on an array of values that are passed at execution time. The columns indicate which data fields the mutator will edit. Each column is associated with a validator, which is a special data transformer that validates the incoming data and may transform it before saving it to the columns in the store. The access policy determines the circumstances in which the write is allowed. - -# Tokenizing Data - -When using an accessor to retrieve data from the store, it is possible to **tokenize** the data. When you tokenize a piece of sensitive data, you replace it with a secure (but resolvable) reference token. Tokenization differs from other forms of data transformation: it allows an employee or service with sufficient permissions to **resolve** the token back into the raw data. - -The token is generated from the accessor's **transformer** code. It is common to generate tokens randomly and/or to match the format of the raw data so that the token can be used in place of the data without causing validation errors. For example, you might transform an email address like `john@beatles.com` to `550e8400e@a59d15b1.com`. The token is associated with a separate **token resolution policy** which controls the circumstances in which the token can be exchanged for the original raw data. When an application or employee needs the original data, it can request to exchange the raw data from the tokenization service. If the resolution access policy is met, the raw data is returned. Once the purpose for which the data was retrieved is achieved, the raw data should be discarded. diff --git a/content/_dangling-articles/principles-for-use.mdx b/content/_dangling-articles/principles-for-use.mdx deleted file mode 100644 index 7d84543..0000000 --- a/content/_dangling-articles/principles-for-use.mdx +++ /dev/null @@ -1,33 +0,0 @@ ---- -title: "Principles for use" -slug: "principles-for-use" -excerpt: "" -hidden: true -createdAt: "Thu Aug 03 2023 18:41:15 GMT+0000 (Coordinated Universal Time)" -updatedAt: "Tue Sep 10 2024 18:33:44 GMT+0000 (Coordinated Universal Time)" ---- -Following a few key principles will help you get the most out of User Store. - -### 1. Avoid storing raw PII outside of the Safety Layer, unless necessary - -The key benefits of Safety Layer come from the ability to draw a protective boundary around your data. This boundary governs access control and minimizes or tokenizes outbound data. If data is stored outside the store, it does not receive these protective benefits. When applications or employees need raw data to complete a task, they should hold the data for the minimum time frame required to complete the task. - -### 2. When PII must be stored outside of the Safety Layer, tokenize or mask it wherever possible - -Of course, sometimes, data does need to be stored outside of the Safety Layer, e.g. for offline data analysis. In these cases, use a data transformer to obscure the data as much as possible. For example, use a tokenizing function that replaces the data with a random UUID. Attach this token to an access policy that only allows the token to be resolved in specific circumstances, such as by an authenticated employee, with the role of engineer, on the company VPN. - -### 3. Use transformers to minimize the information carried by a piece of data for a given task - -When you are passing data out of the store for a specified use case, minimize the information as much as possible for the specified task. For example, if you want to conduct analysis assessing the differences in behavior between children and adults, do not pull raw Dates of Birth from the store. Instead, use a data transformer to pass a string indicating `child` or `adult`. By minimizing outbound data, you reduce your surface area from attack, enable better enforcement of least privilege and better align with the GDPR principle of data minimization. - -### 4. Create different accessors and mutators for different use cases - -User Store makes creating a new accessor (read API) as simple as writing a database query. This is because accessors are intended to be use-case specific. For example, you should configure one accessor `GetPhoneAndNameForMarketing`, and another `GetPhoneForMFA`. Configuring one accessor per use case makes accidental misuse of the system less likely. It lets you enforce different purpose-based access policies for different use cases, automatically create an audit log of data access and turn off individual data streams in case of emergency. It is essential for automatically generating DPIAs and other documentation about data use practices. - -### 5. Re-use access policies, transformers and validators to keep your code [DRY](https://en.wikipedia.org/wiki/Don't_repeat_yourself) - -Unlike accessors, each access policy, data transformer and validator can be re-used to maximize auditability, reduce update costs and prevent errors. Access policies can be easily built from parametrizable access policy templates. This allows you to update a set of access policies with parallel logic just by updating the template. Similarly, complex access policies can be composed of other policies to maximize re-use. - -### 6. Adopt a naming practice for accessors and mutators that describes what they do and why - -Accessor and mutator names are used in your codebase (to call the API), in code review (to identify accidental misuse) and in your audit log (to understand whether data usage aligns with user consents). Use the names to describe what the API does and why it exists. A good approach to naming describes the transformed data and the purpose, e.g. `GetAgeGroupForDataScience`, `SetPhoneNumberForMarketing` or `GetLastFourOfPhoneForCustomerService`. diff --git a/content/docs/guides/(data-access)/how-to-guides/use-your-custom-sdk.mdx b/content/docs/guides/(data-access)/how-to-guides/use-your-custom-sdk.mdx index 4e60151..6615f9f 100644 --- a/content/docs/guides/(data-access)/how-to-guides/use-your-custom-sdk.mdx +++ b/content/docs/guides/(data-access)/how-to-guides/use-your-custom-sdk.mdx @@ -6,12 +6,9 @@ hidden: false createdAt: "Fri Feb 09 2024 20:27:45 GMT+0000 (Coordinated Universal Time)" updatedAt: "Fri Feb 09 2024 20:28:13 GMT+0000 (Coordinated Universal Time)" --- -For a smooth developer experience, UserClouds automatically generates a custom SDK for each of your tenants. This SDK allows you to call each of your accessors and mutators as functions directly in your codebase. + +For a smooth developer experience, UserClouds automatically generates a custom SDK for each of your tenants. This SDK allows you to call each of your accessors and mutators as functions directly in your codebase. ## Downloading the custom SDK You can download your custom SDKs manually from your tenant homepage in the UserClouds console. Custom SDKs are currently available in Go and Python, with more languages in development. Please reach out to us if you need a different SDK! - -## Deploying the custom SDK - -_More info coming soon!_ diff --git a/content/docs/guides/(data-access)/proxy-and-plug-in-implementation/1-proxy-introduction.mdx b/content/docs/guides/(data-access)/proxy-and-plug-in-implementation/1-proxy-introduction.mdx index fee63e0..25d7908 100644 --- a/content/docs/guides/(data-access)/proxy-and-plug-in-implementation/1-proxy-introduction.mdx +++ b/content/docs/guides/(data-access)/proxy-and-plug-in-implementation/1-proxy-introduction.mdx @@ -49,8 +49,8 @@ Each of these proxies sits between the application and data source, intercepting | Functionality | SQL Proxy | NoSQL Proxy | API Proxy | | :------------------------------------------------- | :-------------------- | :----------------------------------------------- | :-------- | | Granularity | Global, Column, Query | Object Store _(file path considered in context)_ | Endpoint | -| Masking | ✅ | :x: _ (coming soon!)_ | ✅ | -| Tokenization | ✅ | ❌ _ (coming soon!)_ | ❌ | +| Masking | ✅ | ❌ | ✅ | +| Tokenization | ✅ | ❌ | ❌ | | Access Policies | ✅ | ✅ | ✅ | | Access Policies that consider data in the response | ✅ | ❌ | ❌ | | Logging | ✅ | ✅ | ✅ | diff --git a/content/docs/guides/(data-storage)/definitions/purpose-and-consent.mdx b/content/docs/guides/(data-storage)/definitions/purpose-and-consent.mdx index b902057..4dcbe57 100644 --- a/content/docs/guides/(data-storage)/definitions/purpose-and-consent.mdx +++ b/content/docs/guides/(data-storage)/definitions/purpose-and-consent.mdx @@ -6,9 +6,10 @@ hidden: false createdAt: "Thu Aug 03 2023 19:04:43 GMT+0000 (Coordinated Universal Time)" updatedAt: "Fri Jun 28 2024 22:47:11 GMT+0000 (Coordinated Universal Time)" --- + ## Summary -Purposes are used to track, enforce and audit user consent in User Store. Purposes have names like `marketing`, `analytics` and `operations` that map to the data processing purposes described in your privacy policy and terms of service. +Purposes are used to track, enforce and audit user consent in User Store. Purposes have names like `marketing`, `analytics` and `operations` that map to the data processing purposes described in your privacy policy and terms of service. When users share data with you, they consent to a set of purposes for each piece of data that they share. For example, they might consent to using their email address for personalization, but not marketing. User consent is granular: it is stored per piece of data. Note that system column are not associated with purposes. @@ -20,7 +21,6 @@ You can define and describe your own set of purposes in the Purposes table of th ![Name and describe your data processing purposes in the Purposes table under Access Rules.](/assets/images/purposes.webp) - ## How users consent to purposes Users can share and revoke consent to process their data for a particular purpose (or set of purposes) when: @@ -29,7 +29,7 @@ Users can share and revoke consent to process their data for a particular purpos - They share a new piece of data with you - They complete flows authorizing or revoking authorization for particular uses of their data, e.g. a sign-up for a weekly newsletter -Consent is granular: it is stored per piece of data. For example, an end user might consent to using their email address for marketing, but not their phone number. When a user consents to a particular data processing purpose for a particular piece of data, this is tracked in User Store as a **consented purpose**. +Consent is granular: it is stored per piece of data. For example, an end user might consent to using their email address for marketing, but not their phone number. When a user consents to a particular data processing purpose for a particular piece of data, this is tracked in User Store as a **consented purpose**. ## How user consents are stored @@ -39,8 +39,6 @@ Consented purposes are stored per column, per user in User Store. For example, a Consents must be specified for all mutator operations (creates, updates and deletes). Consents are passed to the User Store in the context at execution time. If a data value is authorized for multiple purposes, deleting a data value for a single specified purpose will remove that consented purpose (only). -_(Coming soon)_ UserClouds is building off-the-shelf integrations with consent management solutions like OneTrust and PrivacyArc to pass consent data collected by third party services into User Store. - ## How user consent is enforced In UserClouds, data accessors (read APIs) are used to retrieve a pre-specified set of columns of data for 1+ users. Every accessor is associated with a purpose at creation time. diff --git a/content/docs/guides/(data-storage)/definitions/regions.mdx b/content/docs/guides/(data-storage)/definitions/regions.mdx deleted file mode 100644 index 235d4aa..0000000 --- a/content/docs/guides/(data-storage)/definitions/regions.mdx +++ /dev/null @@ -1,9 +0,0 @@ ---- -title: "Regions" -slug: "regions" -excerpt: "" -hidden: true -createdAt: "Fri Apr 05 2024 20:23:30 GMT+0000 (Coordinated Universal Time)" -updatedAt: "Fri Apr 05 2024 20:23:30 GMT+0000 (Coordinated Universal Time)" ---- -_Docs coming soon!_ diff --git a/content/docs/guides/(data-storage)/how-to-guides/import-user-data.mdx b/content/docs/guides/(data-storage)/how-to-guides/import-user-data.mdx index c57dde4..cb0cc50 100644 --- a/content/docs/guides/(data-storage)/how-to-guides/import-user-data.mdx +++ b/content/docs/guides/(data-storage)/how-to-guides/import-user-data.mdx @@ -7,4 +7,4 @@ createdAt: "Fri Apr 05 2024 22:04:25 GMT+0000 (Coordinated Universal Time)" updatedAt: "Fri Apr 05 2024 22:05:06 GMT+0000 (Coordinated Universal Time)" --- -\_User Data can be imported into the User Data Vault in bulk. Docs coming soon! +User Data can be imported into the User Data Vault in bulk.