Cloud security - a multi faced approach : Part 1

Dear Readers,

I'm here with a pertinent question that comes often in various conversations. Security in the Cloud is a fearful thing for many professional & rightly so, since its not in my-premise, I don't have same control, hence the panic. Of course there is no magic wand in the cloud & you have to plan for security of your cloud assets with same vigor.

Best way to look at Cloud security is to look holistically, from the networking stack to Cloud services and everything in between. Data protection and privacy is a shared responsibility between the provider and its customers. The provider should be responsible for the platform and accountable for creating a service that can meet the security, privacy, and compliance needs of its customers. Customers are responsible for configuring and operating their service after it has been provisioned, including managing access credentials and regulatory and legal compliance, protecting applications through the service’s configurable controls, data content, and any virtual machines or other data that you use with their account.

In this post ( Part 1 ), lets dig deep into the IaaS deployment concerns. In upcoming posts, will focus more on Data layer and application security.

The following table breaks down specific cloud provider responsibilities versus the responsibilities of their business customers. The boundaries between these responsibilities is not always clear cut, and can depend on the agreement signed by the customer and other factors.

I can speak only from Microsoft perspective, but you could apply the same principle to any Cloud provider and ask for transparency in security accountability. At Microsoft, we work to be as transparent as possible about these roles and responsibilities. We make clear our contractual commitments, publish whitepapers such as this one, and detail service specific considerations on each of our cloud services’ Trust Centers.

So clearly, there is no one-size-fit all for all the Cloud deployments, depending on how much you control, you are more accountable. Eg : If its an IaaS deployment then of course you've to think of many layers of security vis-à-vis an SaaS solution.

If you have an Azure IaaS deployment then, below is a good pictorial depiction of all the major layers to consider for Security.

 

Inbound from the Internet, Azure DDoS helps protect against large-scale attacks against Azure. The next layer is customer-defined public endpoints, which are used to determine which traffic can pass through the cloud service to the virtual network. Native Azure virtual network isolation ensures complete isolation from all other networks, and that traffic only flows through user configured paths and methods. These paths and methods are the next layer, where NSGs, UDR, and network virtual appliances can be used to create security boundaries to protect the application deployments in the protected network.

Now, more about these,

Before Internet traffic can get to the Azure virtual networks, there are two layers of security inherent to the Azure platform:

1. DDoS protection: DDoS protection is a layer of the Azure physical network that protects the Azure platform itself from large-scale Internet-based attacks. These attacks use multiple “bot” nodes in an attempt to overwhelm an Internet service. Azure has a robust DDoS protection mesh on all inbound Internet connectivity. This DDoS protection layer has no user configurable attributes and is not accessible to customer. This protects Azure as a platform from large-scale attacks, but will not directly protect individual customer application. Additional layers of resilience can be configured by the customer against a localized attack. For example, if customer A was attacked with a large-scale DDoS attack on a public endpoint, Azure blocks connections to that service. Customer A could fail over to another virtual network or service endpoint not involved with the attack to restore service. It should be noted that although customer A might be affected on that endpoint, no other services outside that endpoint would be affected. In addition, other customers and services would see no impact from that attack.
2. Service endpoints: Endpoints allow cloud services or resource groups to have public Internet IP addresses and ports exposed. The endpoint will use Network Address Translation (NAT) to route traffic to the internal address and port on the Azure virtual network. This is the primary path for external traffic to pass into the virtual network. The service endpoints are user configurable to determine which traffic is passed in, and how and where it's translated to on the virtual network.

Once traffic reaches the virtual network, there are many features that come into play. Azure virtual networks are the foundation for customers to attach their workloads and where basic network-level security applies. It is a private network (a virtual network overlay) in Azure for customers with the following features and characteristics:

• Traffic isolation: A virtual network is the traffic isolation boundary on the Azure platform. Virtual machines (VMs) in one virtual network cannot communicate directly to VMs in a different virtual network, even if both virtual networks are created by the same customer. This is a critical property that ensures customer VMs and communication remains private within a virtual network.
• Multitier topology: Virtual networks allow customers to define multitier topology by allocating subnets and designating separate address spaces for different elements or “tiers” of their workloads. These logical groupings and topologies enable customers to define different access policy based on the workload types, and also control traffic flows between the tiers.
• Cross-premises connectivity: Customers can establish cross-premises connectivity between a virtual network and multiple on-premises sites or other virtual networks in Azure. To do this, customers can use Azure VPN Gateways or third-party network virtual appliances. Azure supports site-to-site (S2S) VPNs using standard IPsec/IKE protocols and ExpressRoute private connectivity.
• NSG allows customers to create rules (ACLs) at the desired level of granularity: network interfaces, individual VMs, or virtual subnets. Customers can control access by permitting or denying communication between the workloads within a virtual network, from systems on customer’s networks via cross-premises connectivity, or direct Internet communication.
• UDR and IP Forwarding allow customers to define the communication paths between different tiers within a virtual network. Customers can deploy a firewall, IDS/IPS, and other virtual appliances, and route network traffic through these security appliances for security boundary policy enforcement, auditing, and inspection.
• Network virtual appliances in the Azure Marketplace: Security appliances such as firewalls, load balancers, and IDS/IPS are available in the Azure Marketplace and the VM Image Gallery. Customers can deploy these appliances into their virtual networks, and specifically, at their security boundaries (including the perimeter network subnets) to complete a multi-tiered secure network environment.

Another related but very important aspect is : RBAC ( Role based access control ) : Cannot emphasize enough about the importance of giving "right access to right people for right duration". RBAC have been there for a long time so just make sure that fewer privilege accounts exist ad practice "Just in time" access for one time activities. This way you'll avoid too many people to have the high privilege access in your cloud deployment as well as at the subscription level.

Hope this post helped you build better understanding of cloud security and what responsibilities & possibilities lie with you.

Some good references to look at for steps to follow -

MSFT_cloud_architecture_security

Cheers,

Pracheta