Security
Disaster recovery & BI
A word about Sveltekit adapters.
21RISK is built with Sveltekit , a modern application framework that makes a clear abstraction so developers don’t have to think about the target deployment. This makes it very flexible to change where the application code is deployed. As of june 2023, Sveltekit supports the following deployment targets:
| Adapter | Target |
|---|---|
| @sveltejs/adapter-cloudflare | Cloudflare Pages |
| @sveltejs/adapter-cloudflare -workers | Cloudflare Workers |
| @sveltejs/adpater-netlify | Netlify |
| @sveltejs/adapter-node | Node servers |
| @sveltejs/adapter-static | Static site generation |
| @sveltejs/adapter-vercel | Vercel (The adapter 21RISK is currently using, since may 2023.) |
Failover strategy
To avoid any downtime we utilise a comprehensive failover strategy on all avenues of our application. This helps ensure that any regional or local incidents do not impact performance and result in downtime.
- Vercel uses AWS Global Accelerator and Anycast network to automatically reroute traffic to another region in case of regional failure.
- Edge functions and Edge Middleware switch to another region automatically using Cloudflare's automatic failover feature
- Mongodb Cross cloud failover - ensures that data is replicated to multiple regions.
- Mongodb Multi cloud provider backups - We do periodic backups to multiple different cloud providers to ensure that even in the event of a total loss of the cloud provider AWS we still have ensured our data.
Disaster Recovery Plan
A Disaster Recovery Plan (DRP) is essential for businesses of all sizes, including your small development team. The purpose of a DRP is to ensure that your team can respond to a disaster or other emergency that affects information systems and minimize the effect on the operation of the business.
Risk Assessment
An ordered list of the most critical incidents to affect our system: This list provides the foundation for the steps we take in order to minimize the impact if they should occur.
- Regional at MongoDB Atlas -> Failover strategy
- Complete Outage at MongoDB Atlas -> Move to alternate processing site
- Outage at Doppler -> Move to alternate processing site
- Outage at WorkOS -> Move to alternate processing site
- Regional outage at Vercel -> Failover strategy
- Complete outage at Vercel -> Move to alternate processing site
- Outage at AWS -> Move to alternate processing site
- Outage at Github -> Move to alternate processing site
Identify Critical Assets
Identify which data, hardware, and software are critical to business operations. Prioritize their recovery in the event of a disaster.
- MongoDB Atlas
- WorkOS
- UploadCare
- Github
- NPM
- Doppler
- AWS
- Power BI
Backup and Restore Procedures
| Service | Backup policy | Recovery Point Objective |
|---|---|---|
| MongoDB Atlas | We have an extensive backup policy, described in this document. It’s cross-region. The backups are full, nothing is left out. | full |
| Uploadcare | We have AWS-bucket backups of all files in UploadCare configured | full |
| Github | All changes to the code is in version control, running on Github.com | full |
| Power BI | All Power BI files are backed up in Google Drive | full |
Disaster Response
Step 1 Better stack will automatically contact Alex and Andreas, when downtime in the system is identified.
Step 2 Depending on the severity of the plan, a physical meetup is arranged with the priority to protect/verify all backups are in place.
Recovery Procedures
Document the steps necessary to recover each of your critical assets. This should include steps to restore data from backups, how to ensure that restored systems are secure, and how to validate that systems are functioning correctly after recovery.
| Service | Steps to validate | Steps to recover |
|---|---|---|
| MongoDB Atlas | Navigate to MongoDB.com, login and verify backups are there. | Create a new target cluster, and restore the backup. |
| Uploadcare | Log into the AWS portal, and find the backup bucket “21risk-backup-static-files” | Download files and upload to alternate provider |
| SourceCode | Connect to the 21RISK/eddystone repository and download the codebase. (Alternatively use Github codespaces, where the code is also present). |
Alternate Processing Sites: For critical systems
In the event of a disaster at one of our current service providers, we would migrate the following services to the alternative providers to ensure functionality. 28 Please note that the alternate providers are not actively used currently.
| Service | Current | Alernative |
|---|---|---|
| Database | MongoDB Atlas | Self-hosted on Digital Ocean / Heroku |
| Hosting | Vercel | Heroku |
| Data storage | Uploadcare | Cloudinary |
| Authentication | WorkOS | Auth0 |
| Version control | Github | Gitlab |
| Secrets management | Doppler | 1Password |