System Access Control
This document describes the processes that support the following company policies:
- System Access Control Policy: Annotated Notes Drata Policy
System Access Change
Performed by Security Officer
Account Provisioning
- Initiate the access request by creating a ticket in Shortcut using the System Access Control - Account Provisioning Story Template:
- Assign the System Access Control label to it
- Perform the account provisioning
- Verify user identity prior to granting access/additional permissions
- Fill the required information in the ticket
- Grant permissions to the systems that are relevant to the user
- Inform user that MFA should be set-up as soon as possible on all accounts (In particular: Google, AWS, Github)
- Update account status/info/mappings in Drata
- The Google Groups whose name starts with
t-(for team), such ast-engineeringhave a special meaning for AWS as they are used to assign permissions during the SSO (AWS IAM Identity Center) process. As a result, make sure to assign the new user to the relevant groups. - To update the AWS IAM Identity Center users and groups, run the ssosync tool after making changes to the users/groups in Google Workspace.
- Complete the ticket
- If the request is rejected, it goes back for further review and documentation.
- If the review is approved, the request is marked as “Done”, and any pertinent notes are added.
Account Provisioning Required Info
Information that must be provided in the ticket:
| Information | Description |
|---|---|
| Name | ??? |
| Narrative Email | ??? |
| How user identity has been verified | By Phone/ By Videocall/In Person |
| Role / Job Title / Responsibilities | ??? |
| Additional access required outside of the minimum necessary to perform job functions with rationale | ?? |
Account Deprovisioning
- Initiate the access request by creating a ticket in Shortcut using the System Access Control - Account Deprovisioning Story Template:
- Assign the System Access Control label to it
- Perform the account deprovisioning
- Fill the required information in the ticket
- Cut access from all systems
- Update account status/info/mappings in Drata
- To update the AWS IAM Identity Center users and groups, run the ssosync tool after making changes to the users/groups in Google Workspace.
- Complete the ticket
- If the request is rejected, it goes back for further review and documentation.
- If the review is approved, the request is marked as “Done”, and any pertinent notes are added.
Account Deprovisioning Required Info
Information that must be provided in the ticket:
| Information | Description |
|---|---|
| Name | ??? |
| Narrative Email | ??? |
Access Change
Additional Permissions, MFA Reset, or Password Reset Procedure:
- Initiate the access request by creating a ticket in Shortcut using the System Access Control - Access Change Story Template:
- Assign the System Access Control label to it
- Perform the access change
- Very user identity prior to granting access to new accounts for Onboarding and Password Reset requests
- Validate that requested permissions are reasonable
- Perform requested changes
- Update account status/info in Drata if needed (e.g. merge access in Github)
- Complete the ticket
- If the request is rejected, it goes back for further review and documentation.
- If the review is approved, the request is marked as “Done”, and any pertinent notes are added.
Access Change Required Info
Information that must be provided in the ticket:
| Information | Description |
|---|---|
| Name | ??? |
| Narrative Email | ??? |
| System Access Control Request Type | Additional Permissions Requested/Password Reset/MFA Reset |
| How user identity has been verified | By Phone/ By Videocall/In Person |
| Role / Job Title / Responsibilities | ??? |
| Additional access required outside of the minimum necessary to perform job functions with rationale | ?? |
System Access Review
Performed by Security Officer
- Once a year, initiate the review of user access by creating a ticket in Shortcut
- that is assigned to the System Access Control label
- from the System Access Control - Access Review Story Template
- Review levels of access for each workforce member
- Summarize the result of the review in the ticket using the System Access Review Summary table
- Write down any additional remarks or comments in the ticket
- If user access is found during review that is not in line with the least privilege principle, modify user access and notify the user of access changes
- Upload evidence to Drata
- Mark the ticket as “Done”, adding any pertinent notes required.
Relevant information:
- Drata's personnel list is the up to date resource to use to determine the list of current employees.
- The Account Provisioning Notion page lists who has admin access to each system to perform the review and corrective actions.
System Access Review Summary
The review can be summarized using the following table:
| Service | Review Status | Corrective Actions Performed |
|---|---|---|
| Narrative | ||
| Google Workspace | ||
| Github | ||
| Cloudflare | ||
| Notion | ||
| Slack | ||
| AWS | ||
| Shortcut (narrative-security) | ||
| Shortcut (narrative-io) | ||
| NPM | ||
| Cron | ||
| Datadog | ||
| Splunk On-call | ||
| Stripe | ||
| Drata | ||
| HubSpot | ||
Managed Systems
This section contains the list of systems relevant to the access change and system access review processes.
As a general rule, whenever someone's access is revoked, it is important to ensure that at least 2 people from the engineering team and 1 person from the operations or executive team still have admin access to each system.
See Account Provisioning (Notion) for help on setting up each of the below:
- Narrative
- Google Workspace
- Google Cloud Console
- Organizations
- Projects
- Warning: Only project owners can access the projects. Organization owners do not automatically inherit project admin permissions.
As a result, whenever revoking someone's access to either an organization or a project, it is important to ensure
that there are at least 2 people from the engineering team and at least one person from the operations or executive team who are owners of
- each of the organizations
- each of the projects
- Github
- Cloudflare
- Notion
- Slack
- AWS
- Shortcut
- NPM
- Cron
- Datadog
- Splunk On-call
- Stripe
- Drata
- HubSpot
- LinkedIn
- Narrative's LinkedIn Business Page
- Narrative-owned Apps
- Warning: LinkedIn page super admins do not have access to LinkedIn apps, even if the apps are "company verified".
Each app has a list of admins that is configured independently of other apps and business pages.
As a result, whenever revoking someone's access to either an app or a business page, it is important to ensure
that there are at least 2 people from the engineering team and at least one person from the operations or executive team who are super admins of
- the LinkedIn Business Page
- each of the Narrative apps.
Partner Offboarding
- Initiate the review of user access by creating a ticket in Shortcut
- that is assigned to the System Access Control - Partner Offboarding label
- using the System Access Control - Access Review Story Template
- Perform the offboarding
- Delete relevant
external-*IAM users (mostly legacy or custom users) - Delete relevant
external-*IAM roles - Deactivate all datasets owned by the partner. The snapshots will be expired automatically
- Delete all Kinesis streams that are specific to the partner's integration (mostly legacy integrations)
- Delete all S3 buckets and associated data that are relevant to the partner's integration (mostly legacy integrations)
- Remove terraform config for legacy ingestion triggers on legacy buckets
- Delete relevant
- Mark the ticket as “Done”, adding any pertinent notes required