|
| 1 | +# Security Overview |
| 2 | + |
| 3 | + |
| 4 | +At Tobiko, we treat security as a first class citizen because we know how valuable your data assets are. Our team follows and executes security best practices across each layer of our product. |
| 5 | + |
| 6 | +## Tobiko Cloud Standard Deployment |
| 7 | + |
| 8 | +Our standard Tobiko Cloud deployment consists of several componenets that are each responbisble for different parts of the product. |
| 9 | + |
| 10 | +Below is a diagram of the components along with their description. |
| 11 | + |
| 12 | +{ width=80% height=60% style="display: block; margin: 0 auto" } |
| 13 | + |
| 14 | +- **Scheduler**: Orchestrates schedule cadence and hosts state metadata(code versions, logs, cost) |
| 15 | +- **Executor**: Applies code changes and runs SQL queries (actual data processing in SQL Engine) and python models in proper DAG order. |
| 16 | +- **Gateway**: Stores authentication to SQL Engine. Secured through encryption. |
| 17 | +- **SQL Engine**: Processes and stores data based on the above instructions within the **customer’s** environment. |
| 18 | + |
| 19 | +## Internal Code Practices |
| 20 | + |
| 21 | +Our coding standards are guidelines we enforce throughout the organization to write, maintain, and collaborate on code effecively. These practice ensure consistency, maintainability, realibility, and most importantly, trust. |
| 22 | + |
| 23 | +Below you will find a few examples of our interal code requirements. |
| 24 | + |
| 25 | +- We have signed commits, required approvers, and signed docker artifacts. |
| 26 | +- Each commit to main is approved by someone different than the author. |
| 27 | +- We follow the standard of signing commits and then registering the key with GitHub. [Github Docs](https://docs.github.com/en/authentication/managing-commit-signature-verification/signing-commits) |
| 28 | +- Binary is signed using cosign and OIDC for keyless. [Signing docs](https://docs.sigstore.dev/cosign/signing/overview/) |
| 29 | + |
| 30 | + |
| 31 | +## Physical Property |
| 32 | + |
| 33 | +### How do we protect PGP keys? |
| 34 | + |
| 35 | +If an employee loses their laptop, we don't need to get the old PGP key back. We use GitHub to sign code. At the time the code was committed, the PGP key was valid. When an employee loses their laptop, we will invalidate it, and they will regenerate a new key. The old commits are valid because the PGP key was valid at the time. |
| 36 | + |
| 37 | +### How do we invalidate PGP keys if someone did steal it and could potentially use it? |
| 38 | + |
| 39 | +Revoke access for the GitHub user account associated with the compromised key and not give them access again until the old PGP key is deprecated and issue a new PGP key. |
| 40 | + |
| 41 | +### If someone steals a laptop, what's our continuity plan in protecting code? |
| 42 | + |
| 43 | +- All employee devices are monitored for appropriate encryption and password policies |
| 44 | +- Laptop protection is done through file encryption for Vanta |
| 45 | +- Mandatory lock screen after a timeout |
| 46 | +- We have a procedure for the disposal of an IT asset to mitigate keys being compromised through inappropriate disposal |
| 47 | +- See above for PGP key protection |
0 commit comments