Cloud security is complex and has several layers to it—first and most important is access to the control plane. The control plane is your cloud vendors internet portal, APIs, and various command lines that allow authenticated users to deploy, manage, and delete cloud resources. As you can imagine managing access to that control plane is as important as managing access to your data center or virtualization management tools. Beyond managing control plane access, it is important to understand the network security aspects of cloud computing.
You may notice a trend in this series—PaaS and IaaS cloud solutions have different layers. With PaaS solutions the vendor provides more management, whereas with IaaS solutions you and your organization take on full control of networking and patching both your operating systems and database platforms. Cloud security requires different approaches depending on the tools you are using. In this post you will learn about the different aspects of managing cloud security.
Starting with the Control Plane
Azure and Amazon both use a fairly common security approach known as role-based access control (RBAC). There are three basic types of roles:
- Reader—Can see resources, but cannot make any changes
- Contributor—Can create, change, and delete resources, but cannot assign security roles
- Owner—Contributor, but can also assign security roles
Beyond these three basic roles many Azure and AWS resources have their own roles to assign specific permissions. You can also assign individual permissions with custom roles for specific use cases. Azure uses Azure Active Directory (AAD) for identity management, while AWS uses Identity and Access Management (IAM) both of which can be synced with on-premises Active Directory to maintain a common set of users. RBAC in Azure can be scoped at four levels:
- Management Group—a high-level construct to manage multiple subscriptions under the same AAD. Typically used in large corporations with multiple subscriptions
- Subscription—a subscription represents both a billing and a security boundary. Any permissions assigned here will cascade to all resource groups and resources
- Resource Group—the most commonly used security scope in Azure, a resource group is a collection of resources in a common logical container
- Resource—the individual resource is the lowest level of where you can assign RBAC
With all of this in mind, one thing DBAs should note is that all of the RBAC permissions in either the AWS or Azure platform do not impact database permissions, which have to be assigned from within the database.
IaaS Security
Infrastructure as a service (IAAS) solutions are defined as storage, networking, and virtual machines (and sometimes Kubernetes) offerings, that are deployed on the public cloud. The hosting provider is responsible for providing the platform, but you are responsible for how you configure security within the platform. Some examples of things you can do, but shouldn’t do, include putting your SQL Servers on the internet (we at DCAC once did this as an experiment, and our SQL Server was hacked within 15 minutes) or making your storage accounts publicly accessible. While these seem like common sense measures, you might be surprised what I’ve seen in the wild. While this can seem daunting, both AWS and Azure provide security best practices that evaluate the resources in your subscriptions to see how they align with known best practices. These scores also allow you to compare your cloud resources to known auditing standards for all kinds of regulatory standards.
The basics of IaaS security are pretty much the same as if you were managing an on-premises environment. Just like on-premises, it is important to ensure that you patch your operating systems and your database platform regularly. It is also important to segregate your network traffic—this is something that is actually easier in the cloud. What do we mean by network segregation? Let’s start with this Azure graphic below:
This is a pretty complex architecture, but let’s talk about the basics of network security in place here. The front-end has a public IP address in front of an application gateway, which serves as a web application firewall (WAF) and only allows traffic to the web tier over port 443. No traffic from that public IP address can reach any of the other subnet, as that traffic is blocked by firewall rules in the form of network security group rules. Likewise, the data tier can only be accessed from the business tier, over port 1433. This design prevents malicious actors or ransomware from infecting more than a single subnet. A good design like this prevents user machines from impacting server resources as well.
Beyond network security, and not making things that should be private, public, the rest of IaaS security is pretty straightforward—you administer just as you would on-premises.
PaaS Security
While each PaaS platform is a little bit different in terms of how security gets applied, the concepts are pretty similar across AWS and Azure. The first aspect of this is network security—Azure SQL Database and AWS RDS have public endpoints. While having a public endpoint for your database sounds a bit scary, both cloud platforms have included firewalls which allow you to limit the source IP addresses that can connect to your databases. Beyond firewalls, both Azure and AWS offer private access which allows connections from within a virtual network in the cloud (or a hybrid network connection from on-premises) without any connectivity from outside.
Beyond the network aspect and securing access to the control plane PaaS databases are just databases to the DBA. The only other significant difference with the Azure SQL Database service is that users should be scoped to the database—using contained users. The other thing to note is that Azure doesn’t support the use of service accounts to connect to PaaS databases, you will need to register your apps in AAD, and create a service principal for them. You can then grant that service principal to that database.
There can be a lot of fear, uncertainty, and doubt around security in the cloud. In most cases, the cloud platforms offer you more tools to secure your environment than you have in your on-premises environment. While it is possible to do bad things like enabling public access to your SQL Server, you can take advantage of built-in security tool to evaluate your environment against known best practices. One final thing to note is that encryption at rest, is effectively a default setting for both storage and database platform services providing an additional layer of security.