Here are 7 key considerations to securely transition your apps to the cloud: cloud configuration, IAM, microservices, automation, microsegmentation, APIs, and DevSecOps. Written in coordination with Ugochukwu Enyioha.
Organizations are moving their applications to the cloud (or using the cloud as a starting point for application development) at an astonishing rate. According to Forbes, 73% of companies are planning to move to a fully software-defined data center within two years. The shift is motivated by three primary aims:
Owing to this trend, cloud security is becoming more critical, since the cloud interfaces with just about every application and corresponding infrastructure stack in existence. It is also for this reason that hackers are increasingly targeting cloud systems, security controls, and applications. They’re taking advantage of the cloud’s significance in the compute stack and the vulnerabilities that come from its relatively young existence.
In addition to rehosting and replatforming (i.e., migrating) existing applications to the cloud, organizations are actively developing new cloud-native applications. Thus, they’re striving to balance modernization, dependability, productivity, and security in and around the cloud. To give you more insight into what this means, let’s examine how various cloud scenarios affect security posture:
Also known as rehosting, the lift-and-shift method typically entails the rapid, wholesale movement of an existing application, as is, into the cloud. This approach appeals to organizations looking to shift the capital expense and complexity of buying and managing their own physical servers and other data center infrastructure to operational expenses. Initially, the migrated applications are deployed using an infrastructure-as-a-service (IaaS) strategy, which entails significant use of the cloud service provider’s (CSP’s) basic compute instances (e.g., Amazon EC2, Google Compute, and Azure VMs). Reliance on the CSP’s platform-layer controls is minimal, as the goal is just to move application workflows into the cloud.
As with lift-and-shift, the goal with lift-and-refit is fast migration to the cloud. However, in this case the organization makes small changes to the application so it works more effectively in the cloud environment. In some cases, the motivation is cost optimization. In lift-and-refit, replatform changes allow the application to take advantage of cloud capabilities—for example, by moving from file to object storage. Changes can also include automated infrastructure-as-code deployment, data backup and restore, and autoscaling. From a security perspective, reliance on the CSP’s controls should increase slightly—especially for new cloud services that the organization adds to support the application.
Cloud-native development is a re-architecting (or a greenfield development) effort in which new applications are developed and built specifically for the cloud. One motivation for taking this approach is the speed of feature development. The CSP might offer services that make application development faster, and the ability to realize an application’s value proposition through reduced time to market is highly desirable.
Cloud-native applications are designed to integrate well with the cloud computing architecture. They take advantage of a CSP’s computing frameworks and services. The typical attributes for cloud applications include a microservices architecture, the use of containerized services, distributed management and orchestration, and a heavy reliance on infrastructure-as-code for deployment.
Many organizations also decide to re-architect an existing application (or develop a new one) as a cloud-native equivalent to fully optimize their costs in the cloud.
As organizations endeavor to strike a balance between cost, efficiency, and security, how do they know whether they have sacrificed security? With that concern in mind, there are seven areas of focus to examine:
To manage security concerns when migrating cloud applications—whether taking a lift-and-shift, lift-and-refit, or cloud-native approach—the organization must depend in part on its CSP’s platform-layer controls. CSPs such as Amazon, Azure, and Google explain these obligations via the shared security model.
From a CSP’s perspective, an organization should use these controls to secure its workloads. It’s important to use these controls securely; we have seen the introduction of security issues within the cloud when services are misconfigured.
To prevent unexpected access to your cloud resources, it’s essential to maintain strong identity and access policies. All CSPs offer identity and access management (IAM) services to control access to cloud services and resources and to effectively detect and react to unauthorized access. These services can be integrated with existing authentication systems.
Essentially, microservice architecture is a method of developing software as a collection of small, modular, independently deployable services. Each service runs a unique process and communicates through a well-defined, lightweight mechanism to serve a business goal. Microservice-style application development is also gaining popularity in the cloud—especially with serverless infrastructures. Security experts and developers are realizing the benefits of microservices, but at the same time, security concerns are emerging.
CSPs and organizations are still working to figure out how microservices play out from a security perspective. Thus, securing these services is becoming a pressing issue.
We’ve crossed the tipping point where automation has become useful—and even paramount for some processes. So it should be no surprise that using automation to address security issues at scale is an intriguing trend. Automating security also ties into building systems that self-heal to protect against future threats. When a DevSecOps culture is strong and ingrained within an organization, this approach substantially reduces the cost of implementing security programs. Applications can take advantage of cloud APIs to resolve issues automatically and return to full production status without requiring manual effort.
While security professionals are still needed for design and periodic security assessments, there is an increasing trend toward automation to keep up with the rapid pace of development. Large CSPs, such as Amazon, Microsoft, and Google, are bringing native security services into their platforms to meet this need. Vendors are also beginning to deliver solutions built on top of public cloud platforms.
Enterprises continue to recognize the importance of proper division and microsegmentation within public cloud infrastructures. Microsegmentation groups the nodes in cloud environments by logical function, making it easier to apply security policies. If a node is compromised, microsegmentation limits an attacker’s ability to move laterally within the cloud environment.
The increasing complexities of virtualization and the cloud, not to mention increasing security controls, is driving a desire for improved efficiency, agility, orchestration, and consolidation of products and tools. From a security perspective, application programming interfaces (APIs) pose both an opportunity and a threat. One of the largest technology threats in the cloud today is insecure APIs. It’s not unusual for insecure APIs to be used in a rush to deploy a new cloud application. Moving too fast can cause a developer to use a service that hasn’t been vetted appropriately—leading to a variety of security risks. Similarly, assigning a broad range of permissions to an API creates the potential for an attack to have a large impact on an organization’s applications, data, and assets. An important trend right now is securing APIs and using them to increase an organization’s defensive security posture.
Faced with the threats and opportunities outlined above, businesses are taking cloud security into their own hands. Enterprises are increasingly focusing on engineering their own platform-as-a-service (PaaS) stacks to provide a layer of abstraction between their applications and public IaaS offerings. This essentially allows them to retain control and independence while reaping the benefits of cloud economics. Central to the success of this endeavor is the ability to provide a set of consistent, appropriate security controls across multicloud venues, all while retaining full control and visibility at the PaaS level. Organizations can accomplish this by nurturing a DevSecOps culture, which allows them to maintain velocity without compromising security by integrating security at every stage of development.
As organizations increasingly use cloud services as the foundation for their infrastructure and application stacks, the risk of a breach rises—and cloud security must evolve to keep pace with such growth.
At Synopsys, we’re driven to support developers and security professionals speed their innovations to the market without sacrificing security.
Steve Cohen is a product marketing manager within the Synopsys Software Integrity Group. He focuses on the Cloud and CI/CD services. Steve has extensive experience in product marketing and product management. He specializes in software security, cloud, storage management, and systems products.