Data Team Data Management Page

1. You are here:
2. Business Technology
3. Data Team
4. Data Team Data Management Page

Maintained by:

G

On this page

• Welcome to the Data Management Page
• Data Security Practices
  • Sisense
  • Snowflake
• General Data Security Controls
• Quarterly Data Health and Security Audit
  • Snowflake
  • Sisense
  • Trusted Data

Welcome to the Data Management Page

This page covers practices and policies around managing, securing, and governing the Enterprise Data Platform and activities related to it. The technical components of the Enterprise Data Platform are listed in the GitLab Tech Stack.

Data Security Practices

The Enterprise Data Platform captures, processes, and stores data collected from many systems. Not all of this data is of the same importance and we use the Critical System Tier framework and Data Classification Standard to help us determine what data is most important and how to best secure it.

Sisense

We deploy a Role-Based Data Access Scheme in Sisense:

• User Access is managed with Okta
• Data Access is managed with Roles and Spaces
• Each user is assigned a Sisense Role and this enables Data Access to dashboards and reports
• The Sisense scheme interacts with the Snowflake Data Access schema to ensure a user does not have a "back door" into data from either system

Additional controls include:

• Unused Dashboards Are Archived
• System Access is managed with an API Key

Snowflake

We deploy a Role-Based Data Access Scheme in Snowflake:

• User Access is managed with Okta and Access Requests are managed with GitLab
• Each user is assigned one more (Roles based on their job function)[/handbook/business-technology/data-team/platform/#snowflake-permissions-paradigm] and this configuration is managed with Permifrost
• The Snowflake scheme interacts with the Sisense Data Access scheme to ensure a user does not have a "back door" into data from either system.

Additional controls include:

• Based on the Data Classification standard, data is managed with Databases and Schemas
• Every query/user/process is assigned a pre-defiend Warehouse, or Compute Resource
• (Passwords are rotated)[/handbook/business-technology/data-team/platform/#passwords]

General Data Security Controls

• For the purpose of defining Data Controls, the Enterprise Data Platform is a Tier 1 system.
• IMPORTANT: Customer Private RED data is prohibited from permanent storage in the Enterprise Data Platform.

• Data Infrastructure: includes any systems with interact access or process data as part of a Data Warehouse and makes data available to end users.
• Data Warehouse Controls: The Enterprise Data Warehouse is a Tier 1 System.
• Endpoint Devices: All Endpoints Which Have Access To The Data Warehosue are Classified as Tier 1

Quarterly Data Health and Security Audit

A Quarterly Audit is performed to validate system security, such as ensuring the right people have correct data access configuration and data pipelines are running correctly.

The process is supported by the Quarterly Data Health and Security issue template. The label ~"Quarterly Data Health and Security Audit" is used for all issues and merge requests related to the Quarterly audit.

Here is a sample checklist of activities:

Snowflake

• Deactivate off-boarded employees from Snowflake
  • All Snowflake accounts from GitLab team members that are off-boarded, should be deactived from the day they are off-boarded. This activity checks for any active accounts for off-boared GitLab team members. Subsequently any active account will be deactivated.
• Deactivate any account, that has not logged-in within the past 60 days from the moment of performing an audit, from Snowflake.
  • Any named user Snowflake account that hasn't logged for more than 60 days will be deactivated. After deactivation, the user will be informed. If a GitLab team member wants to have access provsioned back again, a regular AR needs to be created. After manager approval the account will be activated.
  • Validate all user accounts do not have password set.

Sisense

• Deactivate off-boarded employees from Sisense.
  • All Sisense accounts from GitLab team members that are off-boarded, should be deactived from the day they are off-boarded. This activity checks for any active accounts for off-boared GitLab team members. Subsequently any active account will be deactivated. To compare off-boarded employees with the actual users, 2 sources needs to be combined. This is done to extract the list of users from Sisense and load this via sheetload into Snowflake. The queries and details for this proces are in the template.
• Deactivate any account, that has not logged-in within the past 90 days from the moment of performing an audit, from Sisense.
  • Any Sisense account that hasn't logged for more than 90 days will be deactivated. If a GitLab team member wants to have access provsioned back again, a regular AR needs to be created. After manager approval the account will be activated.

Trusted Data

• Review all Golden Record TD tests and make sure they're passing.
• Review Data Siren to confirm known existence of RED data.
• Generate a report of Business logic changes to the TD: Sales Funnel dashboard in the quarter. Business logic such as adding new dimensions, new facts, new marts, changing joins, adding new calculated fields.