There is no shortage of options when it comes to what firewall and VPN appliances are available for data centers or cloud environments. The important factor when it comes to choosing them isn't necessarily the security product, but the given deployment and the features available (including access controls, authentication, and authorization ability). Ensuring these are built into the application layer rather than relying solely on network security is critical. An application-level security implementation makes access control scalable, portable, and immutable. Access can then be governed based on the real identity of an application or (micro)service rather than on human provisioning.

By our definition, a cloud native application is a secured application. A secured system by logical extension must be a reliable system. Application code is packaged and deployed across multiple cloud regions; executed in various containers; and is accessed by many clients or other applications (for more details, please refer to Chapter 5, Scalable and Available). This makes it even more critical to bake security into each microservice. The simple fact that applications are now dispersed across multiple geographic areas (scaling up and down constantly) necessitates a more automated and nuanced security approach.

For the majority of enterprise history, writing security code has been less interesting and less important than business logic. Often security-related tasks are left until the last minute in a development cycle, leading to major trade-offs in a product's security features. If you are trying to build a cloud native solution that can scale to support large volumes, run across different regions, and can self-provision, then it is imperative the chief architect considers security as one of the core building blocks of the architecture.

If security is to be part of the design from the ground up, as opposed to bolted on to the solution at the last minute, then let's examine a few essential features of a secure cloud native stack:

• Compliant: Maintain system compliance and audit trails through automation. Generate and build change logs that can be used for compliance reports (for example, GxP, FFIEC, and so on). Deploy rules to prevent unauthorized deployment patterns.
• Encrypted: Sensitive data should be encrypted while traveling through the network or when residing on storage targets. Protocols such as IPSec and SSL/TLS are essential to securing data flows through multiple networks.
• Scalable and available encryption resources: Do not rely on a single encryption resource to perform encryption functions. These resources, as with all cloud native patterns, must be dispersed and decentralized. This is not only more performant but eliminates any single point of failure.
• DLP: Do not allow any PII or sensitive data to be written to logs or other non-authorized targets. Logs are relatively insecure and often contain information in plaintext. Log streams are often the softest targets for intruders.
• Secure credentials and endpoints: Keep service credentials and source/target endpoints outside of the memory. Utilize native tokenization services, with minimized privileges, to keep blast radius to a minimum. When creating credentials for human operators, create identity and access management (IAM) rules with segregated and specific policies. Review and monitor usage continuously.
• Caching: Cloud native applications scale in and out across multiple instances. Applications should leverage an external cache (for example, Memcache and Redis) to support a stateless design. Apps should never store information in memory longer than needed for the request-execution time. Consequently, in the event of a single machine failure, the request can be easily rolled over to another machine in the application server fleet.