Your data is safe with Smallstep
Certificate Authority Signing Keys
We hold your CA signing keys in a hardware security module (HSM), so it’s impossible for anyone to get the private key out, including us. Every interaction with the HSM is logged so that no malicious activity could go unnoticed.
As a point of comparison, if you’re currently using SSH public keys, you’re already trusting every component in your key distribution pipeline with the same level of access. If you push keys out from GitHub, build on Travis, and deploy with Ansible pushing stuff to AWS, all four of those entities could get access to your servers by interfering with key distributions. Relative to public key distribution, our product adds a lot of clarity around where the security responsibilities fall. We think that’s a good thing.
Smallstep employs best practices like end-to-end encryption, single sign-on, and the principle of defense-in-depth for its service delivery. On top of extensive use of mutual TLS everywhere, industry-standard perimeter-based security controls such as security groups, VPCs, firewalls, load balancers are being used to gate access and only allow connections strictly required to deliver Smallstep’s services with multiple layers of access control to provide defense in depth. Smallstep’s services are built on top of broadly adopted and heavily peer-reviewed open source software components and industry standards.
Smallstep employs cloud-backed encrypted volumes to protect personal data at rest. When personal data is in transit, Smallstep exclusively utilizes transport secured by industry-grade Transport Layer Security (TLS, formerly SSL). In cases where Smallstep’s services communicate with one another, they utilize mutual TLS to not just encrypt data in transit, but also mutually authenticate communication parties. For human to service communication, Smallstep employs HTTPS (http over TLS) backed by industry-standard Web PKI certificates. Secrets utilized for such encrypted communication are exclusively stored in ciphertext. Private keys are stored in Key Management System (i.e. Google Cloud KMS) with non-exfiltratable military-grade private keys and audit log records kept for signing/decryption/encryption operations, creation, rotation, and deletion of individual keys.
Smallstep’s services are developed using strongly segregated environments (e.g. development, test, staging, production) where all pre-production deployments only store randomized data; no personal data of any kind. Artifacts and run-time environments are stored separately and contain no personal data of any kind. Third-party dependencies are strongly scrutinized for reliability and security track records. Dependencies are exclusively open source based to allow audits and take advantage of the hardening they went through thanks to widespread industry adoption. Changes introduced into Smallstep’s services are reviewed as part of peer code review throughout the software development lifecycle. Audit logs are kept across the development lifecycle as source code is stored in SVC and artifacts in container registries with record access logs including authentication & authorization information. Smallstep takes advantage of periodic proactive artifact scans that result in a notification for relevant CVEs .
Smallstep grants access to personal data on a need-to-know basis. Need-to-know in the sense that it’s required for the employee to carry out their job duties. Access grants are narrowly scoped, restrictive, and specific to the role of the employee. Smallstep’s employees authenticate with and are on-boarded and off-boarded into the organization using a central identity provider (IdP, i.e. G Suite). The IdP is used to authenticate all users to all Google Cloud Platform’s services using single sign-on with strict enforcement of multi-factor authentication. Authorization for authenticated employees within Google Cloud Platform to APIs and data stores is managed using GCP’s built-in Identity & Access Management (IAM). Smallstep assigns narrowly scoped roles with restrictive access privileges to employees and services accessing personal data.
Smallstep’s services running inside Google Cloud Platform utilize workload-identity where services obtain identity credentials that are being used for both mutual authentication amongst services as well as to govern the level of access to APIs and data stores. All access privileges for APIs and data stores are centrally managed via GCP’s IAM.
Access to Smallstep’s premises and office facilities employs various physical security controls such as key fobs/cards, physical keys, posted door guards, and alarm systems to restrict access to authorized employee-access only. Since no personal data subject to this addendum are being stored physically on Smallstep’s premises, gaining unauthorized access to office facilities will not result or allow unauthorized access to personal data.
Personal data is stored in Google Cloud Platform and consumed as managed services via robust and industry-standard identity and access management for authentication & authorization. Operating Smallstep’s services do not require any of Smallstep’s employees to have physical access to GCP’s facilities.
What if I have questions about this policy?
If you have any questions regarding our privacy policies or need additional documentation, please send us a message to firstname.lastname@example.org.