Moving to the Cloud: Cloud Security Considerations

Cloud computing is different from traditional organization-controlled IT in that a cloud is an infrastructure shared by multiple tenants. When using shared infrastructures, organizations do not control much of the IT infrastructure that underlies the cloud services they engage, especially networking. Shared infrastructures have their own cloud security considerations that should be assessed before embracing the cloud.
One of the more obvious changes to an organization’s security posture that is a direct result of cloud computing is the inability to hide authentication mechanisms behind corporate firewalls. Most organizations would not, for example, make the ability to log in to their VMware infrastructure accessible through the public internet.
Most organizations require their employees to connect to the organization’s network via a VPN (or other similar solution) before being allowed to log in to the administration interfaces of any IT infrastructure. In this manner, even if someone knew the administrative credentials of some piece of IT infrastructure (such as the aforementioned VMware infrastructure) they would also have to obtain the credentials that allow access to the corporate network in the first place.
The access point for logging into a public cloud infrastructure, on the other hand, is available to all. If you know an organization’s administrative credentials, you can do a great deal of damage. The canonical example of this is Code Spaces, which had both their production data and backups destroyed in just such a manner.
The security threat posed by the public accessibility of management interfaces is easily compounded by simple and understandable human error. Consider the common mistake of developers leaving their public cloud credentials embedded in code that they upload to GitHub. Even as early as 2015, GitHub was being crawled regularly by bots looking for such credentials, using them for everything from data exfiltration and spinning up public cloud instances to mining for bitcoin.
Here are some of the top public cloud security considerations to consider on your cloud journey:
 

Segmenting Administrative Authority Into Multiple Credentials

The simple takeaway from the Code Spaces and GitHub examples above would be that organizations need to more assiduously keep credentials a secret. Also, we should eat a bland diet consisting mostly of green leafy things, exercise a great deal, ignore social media, maintain an ideal work/life balance, and sort our recycling, all while calling our mothers regularly!
Because humans make mistakes, it is important that we accept their inevitability and plan accordingly. This means using different credentials for different administrative tasks, as well as making sure backups and production data are never stored together, nor are they accessible from the same set of credentials.
On-premises administrators have known for decades that we should be breaking up administrative rights into different user contexts, but, in most organizations, this is rarely done. When using public clouds, it is imperative that administrators presume that any and all credentials will eventually be compromised and that care and attention must be applied to ensuring that the compromise of any one set of credentials cannot lead to irreparable harm.
 

Hybrid IT

The credential segmentation advice above does not only apply to public clouds. Very few organizations are “cloud only.” Most organizations today run a combination of on-premises and public cloud workloads. There are even a number of popular applications that have both an on-premises component and a cloud component.
The use of both on-premises and public cloud infrastructures magnifies the importance of administrative authority segmentation. If credential reuse is common and/or a single set of credentials contains administrative rights to both on-premises and public cloud infrastructures, the likelihood of compromise of both infrastructures rises. Any hope of using the cloud as a safe and secure backup for on-premises data, or vice versa, in the event of ransomware is lost.
The likelihood of a credential being compromised is a combination of the number of services that credential is used for, the number of different authentication interfaces that credential can be used on, and the number of those interfaces that are exposed to an attacker. Let’s consider a simple scenario involving Microsoft unified credentials and a single systems administrator using a single account.
Microsoft makes unifying an organization’s on-premises Active Directory (AD) infrastructure with their Azure public cloud and their Office 365 productivity suite simple. Many organizations take advantage of this capability. Let’s assume that the organization’s systems administrator has a user account they use for administration.
Hypothetically, without even making any severely flawed design decisions, a malicious actor could attack that username using the Azure portal, the Azure API, the Office 365 portal, the Office 365 API, the on-premises Outlook Web Access server, potentially at least one RDP gateway server, and likely at least one VPN server.
In this fairly simple hybrid IT setup, an attacker could attempt to compromise administrative credentials in at least five, and more likely seven, separate places. In this scenario, because of credential reuse, the attacker needs to compromise these credentials only once to be able to compromise the entire organization.
 

CASBs

Securing public clouds against attackers isn’t simply a matter of segmenting administrative authority across multiple credentials. Defending an organization’s authentication footprint can also take the form of reducing the number of authentication interfaces that are made public.
Cloud Access Security Brokers (CASBs) are an emerging category of security product that sits between an organization’s on-premises infrastructure, their public cloud infrastructure, and the users and administrators of both. CASB is something of a catch-all category for a number of different security products, and different CASB solutions perform different tasks.
Many CASB solutions occupy themselves with applying security policies that are set on-premises to public cloud workloads. Others serve as authentication gateways, allowing organizations to use familiar, easy-to-remember credentials on-premises which are then mapped back through the CASB to randomized credentials in the public cloud.
In the latter case, an administrator named Joe Admin might use their user account Joe.A@Corporate.Org to administer their organization’s local network, but they might also access public cloud services using those same credentials via the CASB. The CASB, in turn, maps the Joe.A@corporate.org credential to IUeh9we8hOIUEh@corporate.org for accessing Amazon and J(*H894y48y($*y4@corporate.org for accessing Azure.
CASBs also monitor login attempts and activity and report any suspicious activity. Many will also incorporate tools for checking regulatory compliance, performing automated security audits, and even handling encryption. CASB functionality overlaps in many ways with Multi-Cloud Management Solutions (MCMs), which, in addition to providing a “single pane of glass” to manage multiple infrastructures, may also offer unified authentication across those infrastructures and CASB features.
 

Additional Cloud Security Considerations

Securing networking between on-premises and public cloud infrastructures is just as important as properly administering credentials. Many services will have applications across multiple sites and multiple clouds, and they will often need access to data located in multiple infrastructures.
Unstructured data (file server and object storage) access is one of the more challenging security problems for organizations embracing public cloud infrastructures. Many workloads need access to unstructured data, regardless of where the workloads (or the data) are. End users often need access to unstructured data as well.
In most organizations, nobody ever deletes anything in unstructured data shares, making it a gold mine of important but forgotten data. Because this data is difficult—if not impossible—to fully evaluate for sensitivity, it must be defended. At the same time, it is also the source of a lot of security vulnerabilities.
The segmentation of workloads is another of the most important cloud security considerations. Workload segmentation involves grouping applications into services then limiting access between services.
Workload segmentation aims to minimize the likelihood that an attacker which successfully compromises one workload can parlay that compromise into something more damaging. Ideally, if a workload is compromised, then it can, at most, affect the other workloads that make up the service it participates in. It should not be able to compromise workloads located in other services.
While workload segmentation can be accomplished manually, it becomes difficult at scale. Microsegmentation solutions aim to provide workload isolation within both on-premises and public cloud infrastructures. Combined with the segmentation of administrative authority amongst multiple credentials, workload segmentation can greatly reduce the damage that any individual compromise event can produce.
 

Absolute Musts

While generic advice regarding public cloud security considerations serves as a good refresher, it’s important to remember that nothing beats performing a proper needs analysis. Knowing what your organization has in terms of existing IT, what it hopes to have for future IT, and what the necessary security posture for all phases of a project will be is hard work. Few shortcuts exist to make it easier.
If unified authentication isn’t yet an absolute must, it soon will be. Unified authentication makes everything simpler. While segmentation of administrative authority amongst multiple credentials is a good idea, having a single authentication solution is an even better one.
Unified authentication makes logging, monitoring, alerting, and covering the IT team’s behind easier. Without unified authentication, a security solution looking for odd login behavior, for example, might not identify login attempts against multiple infrastructures as being part of a coordinated attack. Without unified authentication, each username on each infrastructure appears to be a separate user.
With unified authentication, it becomes much simpler to see that an attacker is trying a given user’s credentials across multiple infrastructures. It is also possible to see that a given user’s credentials were used to access multiple infrastructures, though seemingly from different geographic locations.
Similarly, unified authentication usually makes auditing easier. It also simplifies the establishment of data access chains of custody and their automation. With unified authentication, a user’s access to management interfaces, data, and networking can all be ascribed to that single user, even if the unified authentication solution is serving as an abstraction layer overtop of the native authentication structures of the various infrastructures in use.
 

Visibility into Your Risk Profile

CloudCheckr can help organizations get a handle on their most pressing cloud security considerations. CloudCheckr examines and monitors an organization’s public cloud configurations, ensuring that they meet both best practices and the requirements of over thirty regulatory compliance schemes.
CloudCheckr provides visibility into infrastructure access as well as usage, while enforcing security policies across multiple infrastructures. Get visibility into your risk profile with CloudCheckr, and reduce your organization’s risk today. Sign up for a demo to see CloudCheckr in action.