10 Rules for Better Cloud Security
Tags: cloud, cloudsecurity, security
Published: 2022-01-07 10:37:33

---
title: 10 Rules for Better Cloud Security
published: true
description: Cloud security is a shared responsibility and a big challenge. Here are the basic rules to have in mind to set up efficient guardrails.
tags: cloud, cloudsecurity, security, 
cover_image: https://blog.gitguardian.com/content/images/size/w2000/2021/12/21W48-Blog-Banner-CloudSecurity.png
canonical_url: https://blog.gitguardian.com/10-rules-for-better-cloud-security/
---
## Introduction
It’s estimated that already [50% of all global corporate data is being stored in the cloud](https://www.statista.com/statistics/1062879/worldwide-cloud-storage-of-corporate-data/), which is quite telling about the explosive growth of this still relatively young sector. We all know the benefits which propelled this adoption: increased agility, ease of scaling, and cost-effectiveness.

But regarding security, things are more nuanced: for some, the idea of handling most if not all of one business’s most valuable assets to a third-party organization is a kind of crazy, but for the (vast majority) of the others, it totally makes sense. You can benefit from the enormous security resources put in place by the cloud providers to protect your data, with the very best engineers working 24/7 to fulfill their mission. Even though, this is not quite the end of the story.

In this article, we will highlight the basic concepts of cloud security and give you ten rules to get it right.

## Shared Responsibility Model
Security in the cloud is following a pattern known as the [shared responsibility model](https://aws.amazon.com/fr/compliance/shared-responsibility-model/), which states that **the provider is only responsible for security ‘of’ the cloud**, while **customers are responsible for security ‘in’ the cloud.**

This essentially means that to operate in the cloud, you still need to take your share of work for secure configuration and management. The scope of your commitment can vary widely because it depends on the services you are using: if you’ve subscribed to an Infrastructure as a Service (IaaS) product, you are responsible for OS patches and updates. If you only require object storage, your responsibility scope will be limited to data loss prevention.

Despite this great diversity, there are some guidelines that apply no matter what your situation is.

And the reason for this is simply because all the cloud vulnerabilities are essentially reduced to one thing: misconfigurations. Cloud providers have put at your disposal powerful security tools, yet we know that **they will fail at some point**. People make mistakes, and misconfigurations are easy. That’s why we need **guardrails**, in order to help reduce the possibility of mistakes happening and/or reduce their impact when they do happen.

We will soon enumerate the list of the 10 most important areas for setting up guardrails in your security policy, but first, we need to explain what makes cloud security different compared to “traditional” infosec.

## 3 Keys to Understand Cloud Security
The cloud is a dynamic environment where things are constantly changing, yet the goals of security stay the same: make sure systems work as intended and only as intended. Therefore many base concepts need to be redefined:

- **Perimeter**: traditional security is essentially based on securing a trusted perimeter, the so-called “fortress”. However, a cloud environment is characterized by being spread over the internet, with dynamically evolving endpoints and many interconnecting layers. Any cloud security model should then be centered on **identity and access management** and focused on hardening authorization for suspect accounts (this is where techniques like behavior modeling are especially powerful).
- **Scalability**: storage and processing are dynamic, thus a **cloud security framework** should also be able to take into account the infrastructure evolution. In other words, it needs to be aware of the system state and **adapt its policies** accordingly.
- **Monitoring**: the threat landscape is evolving as rapidly as new cloud resources are stacked up and new attack vectors are found. The added complexity of dynamic systems is a liability: security breaches can proliferate, are harder to spot, and attacks are more sophisticated. Staying up to date requires being reactive to a rapidly changing security landscape.

## 10 Rules for Better Cloud Security
**Rule 1: Don’t Overlook Developer Credentials**

As a company scanning millions of public and private code repositories [every day](https://www.gitguardian.com/state-of-secrets-sprawl-on-github-2021), we cannot stress enough the importance of sound credentials policies. You should make sure your developers use only short-lived credentials at least and eventually put the needed time to come up with a complete set-up, including both management (like a vault) and detection (like our solution, [learn why](https://blog.gitguardian.com/talking-about-data-security-an-introduction-to-aws-kms-and-hashicorp-vault/#summary)). [One of our customers](https://www.itcentralstation.com/product_reviews/gitguardian-internal-monitoring-review-671614-by-danny) couldn’t have put it clearer:

>“If a colleague at another company said to me that secrets detection is not a priority, I would ask what is more of a priority, and then I would point to a quick Google search with a myriad of issues and data breaches that have happened from leaked secrets.”

This is why this rule is number one on this list.

**Rule 2: Always Review Default Configurations**

Cloud providers pre-configure common access control policies. These are convenient but often change because new services are being introduced and they don’t necessarily correspond to your needs. Reduce the attack surface by opting out of unnecessary or unused services.

**Rule 3: List Publicly Accessible Storage**

It is not uncommon to read in the news that some cloud storage was left wild open and publicly accessible. No matter what method of storage you choose for your objects and your data, check that only the intended components are publicly accessible.

**Rule 4: Regularly Audit Access Control**

As explained earlier, cloud security is pretty much as strong as your identity and access management policies are. Identity-based security system are progressively becoming predominant, forming the basis of the so-called “zero-trust” strategies. But as everything else does, these policies will be modified. Implementing the least privileged principle is an active process, involving fine-tuning access to services, systems, and the network. Manual and automated checks should be scheduled and rigorously conducted on a regular basis.

**Rule 5: Leverage Network Constructs**

The same rule applies for networks: you should leverage your cloud provider’s controls to build better, granular-level, policies to segment traffic thoughtfully.

**Rule 6: Make Logging and Monitoring Preventive**

Good security cannot go without robust monitoring and logging. A risk-based logging strategy is a must, but above all, you should make sure that alerting not only is enabled and working but also actionable and not something you look at after an event happened. Ideally, you should be able to aggregate cloud logs on your own logging systems via API or another mechanism.

**Rule 7: Enrich your Asset Inventory**

Using your provider’s APIs to ease the arduous task of inventory management is nice, but enriching this with additional information around ownership, use-case, and sensitivity is even better. Consider it in your strategy.

**Rule 8: Prevent Domain Hijacking**

Transitive trust often exists between cloud services and DNS entries. Regularly review your DNS and cloud configurations to prevent take-over situations.

**Rule 9: A Disaster Recovery Plan is not Optional**

Cloud environments do not automatically solve disaster recovery (DR) concerns. Consider what level of investment is appropriate for catastrophic events within your cloud environment. Design a DR program to recover from outside accounts, providers, or locales.

**Rule 10: Limit Manual Configurations**

Leveraging cloud-native security tools and controls means automating. Remember that vulnerabilities stem from misconfigurations, and misconfigurations are mistakes. The more manual work needs to be done, the more doors it opens for mistakes to sneak in. You need to nudge your team toward more automation, using security-as-code wherever possible and progressively enforcing immutability (no more configuration by hand possible).

## Conclusion
The cloud is complex to manage even for the experts, but it is here to stay. For security professionals, it is an especially big challenge because the scope of responsibility is no longer static, but continuously evolving both to cater to the infrastructure’s needs and to respond to new threats. But it’s also an exciting time for them because they can use all their ingenuity to build very efficient solutions, leveraging the already existing cloud provider’s toolset, to balance between security requirements and flexibility. We’ve presented you with 10 rules to build better cloud security, but it’s up to you to come up with your guardrails!