IRON DOME (AKA Kippat Barzel) is a mobile all-weather, multi-purpose combat proven system that detects, assesses and intercepts incoming artillery, It truly protects the cloud of Israel day and night.
Also in the Star Trek fictional universe, shields refer to a 23rd and 24th century technology that provides starships, space stations, and entire planets with limited protection against damage.
A Pragmatic Approach to Scaling Security in the Cloud
Companies that provide "cloud" computing services, such as Amazon, Google and Microsoft put in place Defense in Depth strategy, adding an additional layer of protection to mitigate unknown vulnerabilities on complex infrastructures.
In this post we will review some of the best preventive protection you can define in your cloud accounts.
Let's start with AWS
AWS Service Control Policies (SCPs) are a way of restricting the actions that can be taken in an AWS account so that all IAM users and roles, and even the root user cannot perform them. This feature is part of AWS Organizations, and the SCPs are controlled by the Organization Master account.
See the Effects on permissions in the AWS Organizations User Guide and Determining whether a request is allowed or denied within an account in the IAM User Guide.
At asecure.cloud you can find a repository of AWS SCP templates and examples that can be deployed using CloudFormation custom resource or AWS CLI scripts.
Not like in the Israeli film, Operation Grandma, I will quote and will not recommend you "to start your fastest, and slowly to increase the pace", but you can start by deny console access to newly created IAM users, The SCP is constructed to prevent action which would deny creating of password for IAM user. What we achieve with such a policy is that all the new users we create will have only programmatic access, and all human users will login through AWS Single Sign-On.
You will be able to create an IAM user, however, the new user will have the section disabled by default, thus restricting the new IAM users from accessing the console.
One more cool policy you can use is restricted IAM principals in any account from making changes to our Security Audit IAM roles created in each AWS account.
We will continue with GCP
Google's Organization Policy Service gives you centralized and programmatic control over your organization's cloud resources. As the organization policy administrator, you will be able to configure constraints across your entire resource hierarchy.
I would start here from those that will help us minimize as much future misconfiguration as for example
Enforce public access prevention When you apply the publicAccessPrevention constraint on a resource, public access is restricted for all buckets and objects, both new and existing, under that resource.
The 2nd constraint I would go for in GCP is the
Restrict Public IP access on Cloud SQL instances
I encourage you to read this article by Google about Cloud SQL with private IP only: the Good, the Bad and the Ugly
I recommend you to use a native tool that Google has developed that will help you with Investigating issues as to why a user has access to a resource or does not have permission to call an API - you can find more and how to use it in this video about Policy Troubleshooter
And let's wind up with Azure
Azure Policy helps to enforce organizational standards and to assess compliance at-scale. Through its compliance dashboard, it provides an aggregated view to evaluate the overall state of the environment, with the ability to drill down to the per-resource, per-policy granularity.
I regularly find that Azure always like to complicate the settings and are most of the time much more difficult for implementation, compared to other cloud providers, so keep that in mind. Therefore I highly recommend you to watch this video that explains (not briefly) the service.
Azure shared with us a GitHub repository contains built-in samples of Azure Policies that can be used as reference for creating and assigning policies to your subscriptions and resource groups.
In some organizations there is a requirement from the FinOps team that all of Azure resources must be tagged with a specific set of tags, which were ultimately to be used for cost accounting when the bill came rolling in.
I found that the best way to ensure that this rule is enforced is to use Azure Policy, You can use the Inherit a tag from the resource group if missing, the policy description: Adds the specified tag with its value from the parent resource group when any resource missing this tag is created or updated. Existing resources can be remediated by triggering a remediation task. If the tag exists with a different value it will not be changed.
Thanks for reading this tutorial.
Top comments (0)