DigitalOcean Security Checklist: Score Your Team

Secure sign-in is required for the team (2FA, Google or GitHub sign-in), with an authenticator app rather than SMS where possible.

Backup codes are generated and stored where you can reach them without your phone.

Few people hold the Owner role; others use Modifier, Member, Resource Viewer or Billing roles that match the job.

Where predefined roles are too broad, custom roles grant only the permissions needed.

Leavers and contractors are removed from the team the same day, and nobody shares a login.

Automation uses tokens with custom scopes limited to the actions it needs, not Full Access tokens.

Tokens have an expiration and unused tokens are deleted.

Tokens are kept in environment variables or a secret store, never hard-coded in repositories.

You know how to revoke a leaked token: delete it, then issue a narrower replacement.

Repositories and CI logs are scanned for DigitalOcean tokens and Spaces keys.

Every internet-facing Droplet is covered by a Cloud Firewall, organised by role (for example web and management).

SSH is allowed only from known addresses (an office range or VPN), not from the whole internet.

Deny rules are used to block known hostile sources, and you know deny rules win over allow rules.

Development, staging and production sit in separate VPC networks and databases are reachable only inside them.

Backend resources reach the internet through a NAT gateway rather than public addresses where practical.

Droplets use SSH keys and password login is disabled.

Daily work uses a sudo non-root user; root is not used for routine tasks.

Listening services are reviewed on a schedule and unknown services are investigated.

The metrics agent is installed so usage is visible.

Operating-system updates are applied on a routine and images are rebuilt rather than patched forever.

Each application has its own Spaces access key limited to the buckets and permissions it needs; full-access keys are rare.

Buckets holding private data have no policy or ACL that lets anyone read; public policies are reviewed.

Each bucket uses either limited-access keys or a bucket policy, and the team knows they cannot be combined.

Spaces secret keys are stored securely and regenerated if lost or exposed, after moving applications to the new key.

Versioning is enabled (through the API) on buckets where an overwrite or delete would hurt.

Droplet backups are enabled at an interval that fits your recovery point, and snapshots are taken before risky changes.

A restore has been rehearsed from a backup or snapshot within the last year.

Monitoring is enabled and resource alerts have thresholds chosen after reviewing normal usage.

Cloud Security Posture Management scans are run on a routine you set and findings are fixed by severity.

You have a written step list for a leaked token or key: who revokes, what to check, who to tell.