In a time where services and their consumers are ubiquitous, security risks to enterprise systems and data are exploding. Security offerings from cloud service providers are promising but still traditional in nature and sometimes soft targets for security attacks.
While enterprise CIOs expect applications, infrastructures, and critical data to shift from behind the firewall to running in the cloud, system architects and designers find themselves juggling between custom security implantation and cloud providers’ offerings.
How strongly do you feel about internet traffic be safe from eavesdropping? Does the third-party fiber optic provider guarantee an intrusion-free pipe? Those are some interesting questions for CIOs, and most of the time the answer is not as expected. But organizations can boost their security systems to make it more and more difficult, expensive and time-consuming for hackers to infiltrate.
While there are many enterprise firewall and VPN appliance options available for data center or cloud environments, it is important that security features including access controls, authentication and authorizations are built into application layer rather than relying solely on network security. Application-level security implementation makes access control scalable, portable, and immutable. Access is governed based on real identity of an app or service or microservice rather than on human provisioning.
Security in the cloud
A secured system is a reliable system. Cloud-native applications are secured applications. Application code packaged and deployed across cloud regions is executed in various containers and is accessed by many clients or client applications. This makes it more critical to secure the applications in a cloud environment.
However, writing security code is less interesting than business logic and very often security-related tasks are left until the last moment, leading to major trade-offs in product security features. This is not a good practice.
If you are architecting a cloud solution that can scale to support large volume, can run across different data center instances, and can be provisioned semi or fully automatically, you need to consider security as one of the core building blocks of your architecture.
Cloud-native microservices are growing in numbers exponentially, and the rise of IoT is making ways to create more and more interfaces and service endpoints—this makes it more critical to secure application endpoints based on role-based authentication. Every incoming request knows the caller and its role with respect to the called application endpoint. These roles essentially determine if the calling client has enough privileges to perform the requested operation on the called application.
Patterns for authentication and authorizations
While there is nothing inherently “cloud native” about software security, there are some things to avoid and some best practices to embrace when securing cloud native apps that you plan to deploy in the cloud. There are many tools and technologies available to provide application security. Some of the most popular options in cloud are OAuth, OpenID, SAML, and HTTP Basic Authentication. While they all cover the same basics, there are fundamental differences in their approach and implementations.
OAuth (Open Authorization) as described in RFC 6749: “The OAuth 2.0 authorization framework enables a third-party application to obtain limited access to an HTTP service, either on behalf of a resource owner by orchestrating an approval interaction between the resource owner and the HTTP service, or by allowing the third-party application to obtain access on its own behalf.”
In simple words, OAuth is an open standard for token-based authorization and it allows a user’s account information to be used by third-party applications or systems, such as Facebook, without exposing users’ credentials in a controlled manner.
OpenID Connect is built on top of OAuth2 authorization framework and is intended to provide additional authentication capabilities. OpenID Connect is also aimed to reduce the complexity by avoiding XML and SOAP overheads as in the case of most SAML use cases. OpenID allows the user to be authenticated via third-party services known as identity providers. Users can choose their preferred OpenID providers to log in to the apps or systems that accept the OpenID authentication scheme.
SAML, an XML-based open standard data format for exchanging authorization and authentication data between a service provider that hosts web applications and a identity provider that maintain and provide electronic identity, such as Linkedin, Facebook, and Google. SAML provides a secure way of authenticating and authorizing users across an ever-expanding world of platforms. SAML also enables more robustness in a cloud-native way by enabling platform-independent access to web applications without the need of having IT teams involved for role provisioning.
Security at design, not bolted on
Architects and designers who follow the cloud-native way adhere to 12 factors of cloud-native application development, to build and implement a stateless service that uses externalized configuration. Some of the very basic design approaches when designing a secured cloud-native application are:
- Credentials and endpoints: Always keep service credentials and source/target endpoints outside the memory. With this approach, an intruder will not have access to service credentials or target endpoints at anytime.
- Caching: Cloud-native app need to scale to multiple instances, and apps should use an external cache such as Memcache or Redis. To support stateless design, apps should never store any information in memory any longer than request-execution time.
- Personally identifiable information: Never write PII information to logs. Log streams are relatively insecure and contain information in plain text. Log streams are usually the soft targets for intruders.
- Encrypt data at rest and in transit: This applies not only for cloud applications but also to data centers. Sensitive data should be encrypted while traveling through the network or when at rest in the repositories. IPSec and SSL/TLS come handy to encrypt data flowing through different networks.
- Encryption resources: Al your encryption resources are fluid and dynamic in nature, and they must be cycled or renewed periodically. Encryption at the application, file, or database field level usually provides the highest level of security. However, apps much use a decentralized encryption and decryption approach. This not only provides better performance but also reduces points of failure.
Cloud security is a shared responsibility. Cloud vendors (both IaaS and PaaS) manage the security of the cloud, but it is responsibility of the customer to secure its application in the cloud. To fully secure their data, enterprise architects and technology teams should apply the best practices and design approaches that keep the applications and data safe and secured. Several best practices have emerged for application and data security in cloud, and they will continue to evolve. Security implementation cannot be an afterthought, and implementing it at the design level will help you protect the confidential data entrusted to organizations and maintain regulatory compliance.