Security
Authentication
S2 API requires an authentication token which can be generated and revoked from the dashboard, and has an expiry time at which it is automatically revoked.
Direct revocation may take upto 1 hour to be fully effective.
S2 SDKs take care of supplying the authentication token automatically. If you are using curl or grpcurl, you can use -H "Authorization: Bearer ${TOKEN}".
The name Authorization for this header is a misnomer: it is purely for authentication. Currently, we do not support finer-grained authorization controls on basins and streams owned by an account. We will be learning about requirements in this area, so we can build it right.
Encryption
Data in transit
S2 endpoints are secured by Transport Layer Security (TLS), and we always use TLS within S2 when data is transferred between services.
Data at rest
S2 does not use any local disks. Data at rest is encrypted by the cloud systems we rely on, e.g. S3’s native server-side encryption.
Lean into client-side record encryption for the strongest protection.
On our roadmap: authenticated encryption of records at the edge service in S2, with a basin or stream-specific key.
Responsible Disclosure
Ethical hackers and security researchers can report vulnerabilities to us at [email protected].