Everyone knows about the many benefits of the cloud: it is infinitely scalable, developer-friendly, and easy to use. However, we often avoid addressing the reality that the cloud is not perfect. The truth is that, despite the cloud’s many merits, it presents a significant challenge from a security standpoint. Security concerns might make you hesitate to deploy your workloads in any cloud, be it public or private – and understandably so.
You might need to adapt your views about security, but there are ways to handle security within the cloud so that you can still take full advantage of its benefits. There is, however, a fundamental difference between the approach you would use to protect the resources in a private cloud like OpenStack and the one you would use to protect applications in a public cloud like AWS. As a result, security becomes much more difficult to manage when you have an application operating in a hybrid cloud.
Chances are that your organization is using a hybrid cloud for some of its applications. So, when running an application in a hybrid platform configuration, you need to understand the different security tools available, how they are different and similar, and considerations for ensuring strong security. Both OpenStack and AWS offer security capabilities such as Security Groups, ACLs, and VPNs, but each cloud provider implements these security measures differently, which makes conformity and ensuring strong security configurations across multiple clouds an even bigger challenge.
In this post, we offer suggestions for managing two, different sets of security tools in a hybrid cloud. Specifically, we review some of the default options in OpenStack and AWS that you can use to protect your workloads in the private and public clouds.
Conceptually, Security Groups are similar to firewalls in that they are not dependent on your workload’s operating system (i.e., Windows/Linux), and they control the traffic that flows in and out of your network card.
Here is an example of how to allow HTTP traffic to into a web server.
As you can see, this a very permissive rule, so you might want to consider limiting access to a subset of addresses—or perhaps limit it even further to only allow internal access. This approach is an IP-based solution, which does have its limitations. You cannot deny access from a specific location or domain; instead, you can only allow traffic from a specific range. This means that you will not be able to block a specific IP range.
Another important thing to keep in mind is that Security Groups are permissive only, which means that, by default, everything is closed unless you specifically open something. However, you are not able to deny traffic that is coming from a specific source or that is going to a specific destination. These might seem like minor details, but it is still important to understand the difference.
Network Access Lists (NACLs) are an additional layer that you can apply above and beyond a Security Group. You can also impose a set of restrictions across the entire network in the cloud, which will enforce security limitations on everything in that network (you can have different NACLs for different networks in AWS) regardless of what the application owner decides to open. An NACL will always override the Security Group.
Let’s say you have the following NACL and Security Group settings:
Since the NACL has precedence over the Security Group in this case, no web traffic will reach the server.
Private and Public Networks
When you deploy workloads, you are only as vulnerable as your attack surfaces, and your attack surfaces are the endpoints that are exposed outside of your cloud. This is your public network. There are certain workloads that are not customer-facing and that therefore do not need to be accessible from the outside world. This is your private network. Workloads that reside in the public network will be able to communicate with workloads in the private networks, and vice versa.
When you deploy a private cloud like OpenStack, you might think that it is safe to deploy everything on a public network because it is actually a part of your private data center, but this is not the case. Even if this were the case, there are important reasons to segregate even your private cloud into two, different categories. You should also limit your attack surface in the data center by creating two categories of exposure.
Let’s consider a real-world example of this concept. You have a single-family home that has a fence surrounding the property. The fence has a gate as the single entry point. Without this fence, your house would be exposed to all kinds of unwanted guests. Having a perimeter and a minimal number of access points secures everything on your property, both inside and outside of the house.
You can build the fence as high as you like, but the height depends on the amount of money you are willing to spend on securing your possessions and on how important those possessions are to you. With a fence and a gate, visitors can still come onto your property, but only when you choose to let them in.
The Principle of Least Privilege in the Cloud
If you give someone a set of keys with access to every building in town, and that person loses the keys, you will have to change each of the locks across the whole town. As a general best practice – not only in the cloud – you should be cautious about giving out privileges to your users. They should only be able to access exactly what they need. Users should not have access to everyone’s private information, but they should be able to access their own information.
The same goes for your cloud in that users’ access should be defined by the duties they perform. Storage administrators should not have full access to DNS records, and help desk support should not have full control over creating new accounts in your cloud (whether they are IAM in AWS or Keystone in OpenStack).
If possible, you should integrate authentication into the cloud with your current authentication mechanism (i.e., LDAP or Active Directory). In most clouds today, there is typically an option to do this. It will save you the trouble of having to manage two directories of accounts, and it will allow for better security, compliance, and auditing.
You should also consider enabling multi-factor authentication (MFA) to add an additional layer of security for physical and virtual devices for users who have substantial privileges in the cloud. This is straightforward in public clouds like AWS, and it is also possible in private clouds such as OpenStack (although private clouds will require some additional configuration).
Some might say that it is impossible to adequately secure workloads in the cloud, and that the cloud cannot offer the same level of security that you can achieve in-house. This is simply untrue.
Do not let the naysayers dissuade you from reaping the full benefits of the cloud because of security concerns. It is true that security will have to be done differently in the cloud, but it is incorrect to assume that security in the cloud cannot be just as strong as it is in-house. In some cases, security measures for protecting your instances and workloads are even stronger in the cloud than they are in-house. If you use default options such as Security Groups and NACLs, and as long as you operate based on best practices, you will be able to deploy your applications securely.
If you want to strengthen your security stance even further beyond these basic default protections, Guardicore is a great option. Guardicore provides a holistic view of your infrastructure across multiple clouds and ensures that your workloads are secure and protected.