Identity, Authentication, and Authorization

Accounts and Credentials

1. Shared user accounts should not be used.
2. Multi-factor (MFA) authentication MUST be enabled for all user accounts where applicable.
3. Access to service account credentials MUST follow the access control of the resources to which the credentials grant access.
4. Service account credentials MUST be rotated every 365 days.
5. Non-MFA user account credentials (for example, API keys) MUST be rotated every 90 days.

Identity

1. An identity provider should be used for all external accounts where applicable.

Authorization

1. Security groups should be used to grant access to sensitive data to users.

Network Security

1. All network firewalls must be configured such that the default policy is deny.
2. Network firewall rules should deny egress by default.
3. All external communication must be encrypted in transit using up-to-date protocols and ciphers.
4. All internal communication should be encrypted in transit if possible.

Data Handling and Isolation

1. Data must be encrypted at rest.
1. Data may be encrypted using provider-managed keys.
2. Data of different types should be logically seperated at rest.
3. Virtual networks (for example, VPC in AWS) may be used as a mechanism for data and workload isolation.

Examples of different data types:

• User content, such as notification entities or subscriber data
• Production-derived data, such as logs
• DFIR (Digital Forensics and Incident Reponse) artifacts, such as system logs and disk images

Vulnerability and Patch Management

1. Resources should be covered by our vulnerability scanning tools in AWS, snyk or deepsource

Change Management and Tracking

1. Changes to systems that process user data must be tracked in a corresponding issue, pull request, or other reviewable process.

Audit Logging

1. Environment audit logs should be enabled and stored in accordance to retention policy
2. Application audit logs, if supported and available, should be enabled and stored in accordance with the retention policy

Best Practices

The following practices are meant to provide more specific technical implementation examples to meet the above criteria.

AWS Practices

Multiple Environments

Development and deployment should occur in a minimum of 2 environments, in addition to local development:

• A shared testing, integration, or other non-production environment.
• A production environment that meets or exceeds the requirements in this page.

The environments should be configured as closely as possible as a best practice to reduce errors in deployment due to inconsistent configuration.

Least Privileges Review

AWS Permissions for accounts should be granted only for the needed use and scoped to minimum.

Based on https://about.gitlab.com/handbook/security/planning/security-development-deployment-requirements/