This chapter argues that “cloud thinking” — designing software with twelve-factor and cloud‑native principles — yields clear security gains whether you run on public cloud, a PaaS, or on‑premises. By favoring statelessness, environment‑agnostic deployment, and platform‑provided capabilities, teams can simplify nonfunctional concerns and systematically improve confidentiality, integrity, and availability. The focus is on design choices that inherently strengthen security rather than on platform hardening or vendor comparisons.
Key practices include externalizing configuration so code and secrets are never bundled together, avoiding credentials in code or resource files, and leveraging the environment (and IAM) to control access and auditing. Because environment variables can be read on many systems, the chapter advocates short‑lived, automatically rotated secrets over static, encrypted blobs. Running applications as separate, stateless processes with least privilege, and relying on backing services, improves containment, enables zero‑downtime rollout, and lets compromised instances be killed and replaced quickly. Centralized, service‑based logging strengthens confidentiality (fine‑grained access control and auditing), integrity (append‑only, separated write vs read paths, aggregated views), and availability (elastic storage and resilience), while avoiding the pitfalls of local log files. Treating admin functionality as a first‑class, version‑controlled, separately deployed interface reduces the attack surface compared to ad hoc SSH or direct database access and keeps operational tools in sync with the system. Finally, dynamic service discovery and load balancing embrace constant change, raising availability and making exploitation of a moving target harder.
These foundations enable the three R’s of enterprise security: rotate, repave, and repair. Rotate secrets frequently and prefer ephemeral credentials injected by the platform or retrieved from a dedicated service, minimizing the window of misuse. Repave servers, containers, and applications from known‑good images on a regular cadence via rolling deployments, erasing any footholds and keeping instances fresh without downtime. Repair quickly by rebuilding and redeploying as soon as patches are available—for operating systems, dependencies, and your own code—so an attacker can’t rely on a long‑lived, vulnerable target. While easiest on modern cloud platforms, the same approach can be achieved with virtual machines and containers on‑premises, and legacy systems can evolve toward these practices iteratively.
Figure 10.1. Configuration data provided by the environment.
Figure 10.2. Processes serving stateless requests, only communicating via backing services.
Figure 10.3. Every log call is sent over the network to the logging service.
Figure 10.4. Administrative tasks deployed to the server, ready to run via a separate API.
Figure 10.5. Centralized load balancing
Figure 10.6. Client-side load balancing using service discovery
Figure 10.7. The platform injecting ephemeral secrets into the environment.
Figure 10.8. The client retrieves secrets from a dedicated service.
Figure 10.9. Repaving instances by rolling deployment
Summary
- The twelve-factor app and cloud-native concepts can be used to increase the security of applications and systems.
- You should run your application as stateless processes that can be started or decommissioned for any occasion.
- Any result of processing should be stored to a backing service such as a database, log service, or distributed cache.
- Separating code and configuration is the key to allowing deployment to multiple environments without rebuilding the application.
- Sensitive data should never be stored in resource files because it can be accessed even after the application has terminated.
- Configuration that changes with the environment should be part of the environment.
- Administration tasks are important and should be part of the solution; these should be run as processes on the node.
- Logging shouldn’t be done to a local file on disk because it yields several security issues.
- Using a centralized logging service yields several security benefits, regardless of whether you’re running an application in the cloud or on-premise.
- Service discovery can increase security by improving availability and promoting an ever-changing system.
- Applying the concept of the three R’s—rotate, repave, and repair—significantly improves many aspects of security. Designing your applications for the cloud is a prerequisite for doing this.
Secure by Design ebook for free
