![](\"https:\/\/www.trendmicro.com\/content\/dam\/trendmicro\/global\/en\/devops\/thumbnails\/22\/cloud-native-security-misconfigurations-solutions-tn.jpg\")
<\/p>\n<\/p>\n
<\/div>\nCloud configuration errors are a significant concern for stakeholders invested in modern DevOps processes, thanks to the quantity of cloud-native software used in production environments these days (think of microservices, as well as serverless and containerized workloads such as Kubernetes). Misconfigured cloud environments can result in everything from poor performance, to system downtime, to data breaches.<\/p>\n
Cloud-native architectures mean the introduction of new attack surfaces. Complex architectures with various network stack components can be involved in volatile Kubernetes pod scenarios, microservices architectures primarily relying on API-based integration across systems, or applications running outside the managed cloud environment.<\/p>\n
This article provides insight into some common cloud configuration errors and how to recognize them. Even more importantly, this article explores how you can help avoid them in your various DevOps processes.<\/p>\n
Common cloud configuration errors<\/span><\/p>\n There are three common reasons for cloud configuration errors:<\/p>\n Common cloud configuration problems<\/span><\/p>\n Now that you\u2019ve learned about some common cloud configuration errors, consider some ubiquitous configuration problems seen in cloud-native scenarios:<\/p>\n Lack of access control<\/span><\/p>\n One widespread issue is the lack of tight access controls and failure to apply the Principle of Least Privilege (PoLP) for both machine and human access to systems.<\/p>\n Cloud and DevOps teams often have too many privileges that they don\u2019t need. Having permissions that are too powerful (for example, full administrator or owner roles) can lead to misconfigurations and pose security issues\u2014such as exposing data that your DevOps team should not see.<\/p>\n Apply the PoLP in your Cloud Teams. Only a handful of admins should have owner permissions, and most tasks should not rely on continuously configured administrative permissions. Instead, look into privileged identity management solutions, allowing for just-in-time permissions.<\/p>\n In other words, grant adequate permissions to an admin to perform their administrative task\u2014and nothing more\u2014for a specified amount of time (typically a couple of hours). If your cloud environment doesn\u2019t provide a privileged identity management solution, consider undertaking regular audits to validate current and required permissions.<\/p>\n Overly permissive network flows<\/span><\/p>\n Overly permissive networks and unrestricted inbound\/outbound ports are another common problem in cloud-native architectures.<\/p>\n First, most cloud providers allow for enabling Remote Server Management ports (RDP, SSH) for virtual machines (VMs). Infrastructure compute resources like VMs or Kubernetes clusters are bound to a virtual network. By design, all IP-related traffic within such a virtual network is allowed.<\/p>\n The same goes for network communication between your back-end servers and the front-end load balancers. Applications and resources can have more access than needed, posing a security risk. It can also lead to \u201cpass-the-hash\/pass-the-ticket\u201d attacks (Use alternate authentication material: Pass the hash, 2022<\/i><\/a>) or make it easier for malware to spread across servers with the same network topology. This also applies to hybrid network scenarios and integrating cloud network services with on-premises data center VLANs (or across branch offices). Before you know it, all network resources could be infected\u2014on-premises, remote, and those running in cloud environments.<\/p>\n The primary recommendation is to integrate network security and firewall solutions into each network stack component. For example, keep VM host-based firewall services (such as Windows Firewall) enabled to protect the operating system and application layer, and allow built-in virtual network services like Azure Firewall, Azure Network Security Groups (NSG), or AWS Network Firewall. For hybrid connectivity, rely on on-premises firewall applications to protect and secure these boundaries.<\/p>\n Lack of observability<\/span><\/p>\n Configuration errors that impact observability often include restrictive permissions that prevent access to logs and other data.<\/p>\n Observability and monitoring are key to running a healthy platform, whether on-premises or in a cloud environment. If your DevOps team cannot access the full architectural stack, that raises observability challenges. As you already saw with permissions, you can only monitor what you can manage. Admins don\u2019t need administrative permissions to perform monitoring. Reader or viewer privilege is enough.<\/p>\n With a single cloud provider, developers would normally rely on the cloud provider\u2019s monitoring solutions. For hybrid and multi-cloud topologies, deploy a monitoring and observability solution that spans all clouds. Kubernetes, for example, works perfectly fine with open-source observability solutions like Prometheus<\/a> and Grafana<\/a>.<\/p>\n Poorly configured data storage endpoints<\/span><\/p>\n Another common problem is insecure data storage endpoints. While these cloud services are secure-by-design, relying on HTTPS and offering out-of-the-box encryption, there have been several documented instances, including in 2020<\/a> and 2022<\/a>, where these secure data endpoints were misconfigured.<\/p>\n One issue is that, although these cloud storage solutions provide security features, they\u2019re often not enforced. For example, an Azure Storage Account allows for both HTTP and HTTPS communication and does not enforce HTTPS-only by default\u2014it merely provides the option.<\/p>\n Another issue is that cloud storage is by default a public-cloud endpoint, which means that technically anyone could connect to the URL of the storage endpoint. Similarly, while most cloud providers offer data and storage endpoint encryption, organizations should look into using a bring your own keys (BYOK) solution for more customized encryption security and protection, along with a key-rotation system to avoid compromised keys.<\/p>\n Another layer to highlight here is poorly configured data storage that allows authorized users (cloud admins and DevOps teams) to access information outside the scope of their responsibilities. Often, allocated administrative privileges permit management of the cloud service aspects, which also gives access to the actual data stored in the cloud.<\/p>\n Mitigation means first limiting administrative permissions\u2014what cannot be managed cannot be mismanaged. Next, make your DevOps teams aware of all available security settings for cloud data storage endpoints and integrate policies to enforce them across your cloud environments.<\/p>\n Missing effective secrets management<\/span><\/p>\n With encryption keys, these issues could be handled with an effective secrets management policy. Applying IaC and cloud-deployment automation means that your DevOps teams are continuously handling secrets, which they must do correctly.<\/p>\n Never store secrets in deployment templates\u2014they are not secure. Don\u2019t save any secrets hardcoded in application configuration settings inside your cloud services. It\u2019s recommended that you instead use a secret vault service, such as Azure Key Vault<\/a>, AWS Secrets Manager<\/a>, or HashiCorp Vault<\/a>.<\/p>\n Incomplete or failed audits<\/span><\/p>\n As previously mentioned, another common problem is a failure to validate configurations or perform regular auditing. This is another observability issue: If you don\u2019t monitor your environment, you cannot properly manage it, leading to persistent or unnoticed configuration errors.<\/p>\n Audit your DevOps team\u2019s administrative permissions to learn from them, then lock them down and allocate only the necessary privileges required to perform a task. Next, given the dynamics and fast-changing environment of the cloud, perform those audits regularly on all possible levels: network, storage, compute, application, and administrative access.<\/p>\n Starting from the built-in auditing capabilities of the cloud provider, consider extending them with third-party, multi-cloud, or multi-platform auditing solutions. When your auditing reports and outcomes are in place, perform regular revisions and implement necessary changes continuously.<\/p>\n Failure to scan cloud-native resources and artifacts<\/span><\/p>\n Finally, consider the risks of not scanning third-party resources (for example, container images in your Kubernetes cloud environments) and not validating scans of your application source code or IaC template definition files. Insecure packages, vulnerabilities, and malware are rapidly and easily exposed as part of pre-built development artifacts or nested inside Docker container images.<\/p>\n Your DevOps teams should apply the concept of \u201cshifting left\u201d and moving towards DevSecOps practices. This means that security scanning and security validation becomes an integral part of each cycle of your DevOps process. Integrate security code scanning with source control solutions such as GitHub Repository Security<\/a>, or integrate container and cloud container registry code-scanning with Snyk<\/a> or similar security solutions.<\/p>\n Conclusion<\/span><\/p>\n The cloud has a lot of benefits, but you can\u2019t take them all for granted. With the rapid adoption of cloud-native software solutions, like Kubernetes containerized architectures, and with microservices and serverless becoming more popular, organizations often face new security-related problems.<\/p>\n Trend Micro is a trusted partner for your multi-cloud strategy and has the necessary solutions to optimize your cloud migrations and deployments. Take a look here<\/a> to learn more.<\/p>\n References:<\/p>\n\n