This post is an add-on to my previous blog post related to CSP comparison👇. Some of the readers to the previous post asked to cover security considerations while selecting a CSP, hence I thought of creating a new article on the topic because this is one of the most crucial and important factors to be considered.
It has been already explained in my previous post on CSP comparison that Cloud service Providers follow Shared Responsibility Model with respect to security and compliance. The Shared Responsibility Model is a security and compliance framework that defines responsibilities of cloud service providers and the customers for securing every aspect of the cloud environment, including but not limited to infrastructure, hardware, data, endpoints, operating system (OS), configurations, networking and access control.
Shared Responsibility Model defines that the cloud provider such as Amazon Web Service (AWS), Microsoft Azure, or Google Cloud Platform (GCP) should monitor and respond to security threats related to the cloud itself and its underlying infrastructure. Whereas end users, including individuals and companies, are responsible for protecting data and other assets they store in any cloud environment.
Ref: The following diagram has been taken from AWS documentation that visualizes Shared Responsibility Model in a graphical form.
All the three major CSPs that we are comparing i.e. AWS, Azure and GCP are the top three public CSPs and have global presence. Hence they have to make their environment compliant with respect to Infrastructure and Data security standards, at the same time they also have to be compliant with respect to any kind of government regulations and industry certifications to be obtained from time to time prevailing in the region.
There are many such certification and compliance standards prevailing across different countries and regions of the world. It’s not possible to discuss them all, however there are some common ones that we can refer to.
- Certifications / Attestations:
- ISO -> Different levels of ISO Certification like 9001, 27001, 27017, 27018 etc. is proof from a third party that your management system complies with one of the internationally recognised ISO standards.
- PCI DSS -> The Payment Card Industry Data Security Standard (PCI DSS) applies to entities that store, process, or transmit cardholder data (CHD) or sensitive authentication data (SAD), including merchants, processors, acquirers, issuers, and service providers. The PCI DSS is mandated by the card brands and administered by the Payment Card Industry Security Standards Council. Most BFSI organizations need this certification.
- SOC -> Different System and Organization Controls (SOC) Reports i.e. SOC 1, SOC 2, SOC 3 etc. are independent third-party examination reports that demonstrate how CSPs achieves key compliance controls and objectives. These are mostly audit reports and the purpose of these reports is to help you and your auditors understand the CSP controls established to support operations and compliance.
- FIPS -> The Federal Information Processing Standard (FIPS) Publication 140-2 is a US and Canadian government standard that specifies the security requirements for cryptographic modules that protect sensitive information.
- C5 -> Cloud Computing Compliance Controls Catalog (C5) is a German Government-backed attestation scheme introduced in Germany by the Federal Office for Information Security (BSI). C5 helps organizations demonstrate operational security against common cyber-attacks when using cloud services within the context of the German Government’s “Security Recommendations for Cloud Providers”.
- Others
- Laws / Regulations:
- HIPPA -> The Health Insurance Portability and Accountability Act of 1996 (HIPAA) is legislation that is designed to make it easier for US workers to retain health insurance coverage when they change or lose their jobs. The legislation also seeks to encourage electronic health records to improve the efficiency and quality of the US healthcare system through improved information sharing.
- CLOUD Act -> The CLOUD Act it is an update to United States law that clarifies the geographic scope for United States law enforcement requests and provides new means for services providers to challenge requests that conflict with another country’s laws or national interests. Where we need to act to protect customers, we’ll continue to do so. We have a history of challenging government requests for customer information that we believe are overbroad or otherwise inappropriate.
- ITAR -> International Traffic in Arms Regulations (ITAR) controls the export from the US of defense-related articles, and the regulations state that no non-US person can have physical or logical access to the articles stored in the ITAR environment.
- Others
- Privacy:
- PIPEDA -> The Personal Information Protection and Electronic Documents Act (PIPEDA) is a Canadian federal law that applies to the collection, use, and disclosure of personal information in the course of commercial activities in all Canadian provinces as supplemented by substantially similar provincial privacy laws in Alberta, British Columbia and Québec. PIPEDA also applies to international and interprovincial transfers of personal information.
- GDPR -> The European Union’s General Data Protection Regulation (GDPR) protects European Union (EU) individuals’ fundamental right to privacy and the protection of personal data. The GDPR includes robust requirements that raise and harmonize standards for data protection, security, and compliance.
- India Data Privacy
- Other region/country specific data protection and privacy rights/regulations.
- Alignments / Frameworks:
- CSA -> Cloud Security Alliance (CSA) is a not-for-profit organization with a mission to “promote the use of best practices for providing security assurance within Cloud Computing, and to provide education on the uses of Cloud Computing to help secure all other forms of computing.”
- GxP -> GxP is an acronym that refers to the regulations and guidelines applicable to life sciences organizations that make food and medical products such as drugs, medical devices, and medical software applications. The overall intent of GxP requirements is to ensure that food and medical products are safe for consumers and to ensure the integrity of data used to make product-related safety decisions.
- NIST -> The National Institute of Standards and Technology (NIST) 800-53 security controls are generally applicable to US Federal Information Systems. Federal Information Systems typically must go through a formal assessment and authorization process to ensure sufficient protection of confidentiality, integrity, and availability of information and information systems.
- HITRUST -> The Health Information Trust Alliance Common Security Framework (HITRUST CSF) incorporates nationally and internationally accepted security frameworks such as ISO27001 and NIST 800-53 to create a comprehensive set of baseline security and privacy controls tailorable to your specific data flows and architectures.
Please refer to the respective CSP’s documentation links for a wide list of Security, Risk and Compliance certifications and practices followed each of them.
https://aws.amazon.com/compliance/programs/
https://learn.microsoft.com/en-IN/azure/compliance/
https://cloud.google.com/security/compliance/offerings
Once you go through their documentation, you will find that their risk and compliance practices are robust enough and they are following very stringent audit mechanisms to maintain their security, risk and compliance certifications up to date. This makes them a highly secure and trusted service provider for any kind of Industry your organization falls into. Now its up to you to find out which of the certifications, controls, audit reports with respect to your organization and region/location and also it depends on your data security requirement, you want to review before finalizing the deal.
Moreover the regulations and certifications mentioned above and also those which are listed in their documentation links are not only applicable to the but also those are applicable to users of the cloud. For example, in case your organization is a banking organization and falls under BFSI where you are providing facility to your customer to make online payments using credit/debit cards, the you also need to be compliant with PCI DSS Level certification else you might not be allowed to run such business operation in country or region where such kind of certifications are mandatory.
Let’s take another example. In case your organization provides some kind of healthcare services like hospital, nursing homes etc. and you are storing confidential patient data records and your location is US, then your infrastructure has to be HIPPA compliant.
The above discussion is mostly related to the CSPs responsibility part of the Shared Responsibility Model.
Let’s discuss now a bit about the Customers responsibility in brief
You as a customer need to host your application on the cloud or you are going to migrate your IT resources from an on-premises to a public cloud. In either case you are going to put your data both sensitive and non-sensitive to the external public cloud. As part of the shared responsibility model, it’s your responsibility to take care of the data you are going to put in the cloud and secure the IT resources that you are deploying on the cloud or migrating. This is almost similar to the security controls, risk and compliance related practices that have been already implemented for your existing application hosted on your on-premises setup however the approach, tools, technologies and mechanisms would differ a bit because you have less control and visibility on the underlying cloud infrastructure provided by the CSP.
All of the three major CSPs we are comparing provide various tools, technologies and services that can be utilized to make your environment secure. At the same time they have robust documentation that helps your IT team to understand the security resources as a product provided by them. Your IT team has to take that effort to understand how to use those tools, technologies and services and configure them as per your requirement.
It is highly recommended to design your architecture on the cloud considering all the security best practices. Let’s discuss some of them below.
Network Security Design (Ref diagram taken from Microsoft Azure Documentation):
- Use hub and spoke network model as defined in the above microsoft diagram.
- Both hub networks and spoke networks are respective secure private networks on the cloud i.e. VNet (Azure) or VPC (AWS/GCP).
- Enable North-South traffic through Hub network using VNet/VPC peering connections to spoke network. North-south traffic typically refers to communication between devices inside an organization and devices or services outside of the organization, such as the internet or cloud-based services.
- Enable East-West traffic between internal VNets/VPCs within the organization using VNet/VPC peering connections. East-west traffic refers to the traffic that occurs within the network/organization.
- Enable East-West internal traffic between cloud and on-premises data centers (i.e. In a hybrid setup) )through hub network only i.e. VPN or ExpressRoute(Azure) or DirectConnect(AWS) or DedicatedInterconnect(GCP) connections from on-premises should terminate at the hub network.
- Use some kind of Firewall in the hub network. You can use either the cloud firewall provided by the CSPs or you can also obtain third party firewall services from cloud marketplace like F5 or Fortinet etc. They are available either as a managed service or VM applications in most of the cases.
- Use private endpoints in order to access any managed service from within your VNets/VPCs which are public in nature like AWS S3, Azure Blob Storage, AWS Elastic Container Registry (ECR), Azure Container Service (ACS), Key Vaults and key management services, managed databases like AWS RDS, Azure Databases etc.
- All public entry points that provide public access to web services should be configured behind an L7 load balancer like Azure Application Gateway or AWS ALB etc. and the traffic should pass through proper firewall setup and a DDOS protection.
- Management traffic should be from through hub network and it is only recommended to use authentication connection only using VPN and may be through Bastion host (Linux based recommended)
- In case using Linux based bastion host, it is recommended to enable advanced secondary logging for audit purposes.
- Use encryption technologies to encrypt data in transit and also in rest. You can use the CSP provided/managed encryption keys or you can also use your own keys for the same which we call customer managed keys (CMKs).
Security considerations when using managed Kubernetes like AKS, EKS or GKE along with Ingress and third party cloud hosted DevOps CI/CD tools like Bitbucket or Gitlab:
- It is recommended to deploy a private Kubernetes cluster inside the spoke private VNet/VPC in order to provide maximum security.
- In a private Kubernetes cluster, the kube-api server resides inside the Vnet/VPC and can only be accessible using an authenticated VPN connection routed to the subnet in the respective Vnet/VPC.
- Ingress traffic should be through Ingress like Application Gateway in azure that uses L7 load balancer and can be configured with Application Specific Ingress controller (AGIC) add on or we can also configure Nginx based Ingress controller. Similar functionality can be configured in AWS EKS as well and both use L7 Load balancer as default to route and distribute traffic. We can configure path based routing as well using the ingress controller.
- Ingress traffic from the public should pass through proper firewall setup and a proper DDOS protection in place.
- Use RBAC for authentication and authorization to access Kubernetes cluster for management.
- In case using external third party cloud hosted DevOps CI/CD tools like Bitbucket pipelines or cloud hosted Gitlab, it should have a secure connection to the container registry for uploading container images during the pipeline execution and also to download and deploy images securely through internal private endpoints to the Kubernetes.
- It is recommended to use a self hosted runner with a third party cloud hosted DevOps CI/CD tools like Bitbucket pipelines or cloud hosted Gitlab. The self hosted runner should be hosted in a hub or spoke network VNet/VPC and traffic should pass through proper firewall setup.
- All database connections from the private Kubernetes cluster should pass through a private endpoint/private link.
- All security/authentication keys should be stored in a key vault and Kubernetes cluster should be configured with Container Storage Interface (CSI) driver so that the respective keys could be mounted as a volume in the respective microservice pod. Key vault should be accessible only via private endpoint/private link.
- In case the applications you are hosting are distributed e.g. an ecommerce application with multiple microservices and there are many APIs to be exposed to the external world, then it is recommended to use some kind of API Management tool mostly available natively as a managed service from all three CSPs.
- Else if majority of the APIs are for internal consumption, then some kind of microservice based internal API management solution might be developed or procured as a local deployment that does the job of API request routing internally. (Topic for further exploration)
Authentication and Authorization in the Cloud:
- It is always recommended to use the natively available Identity and Access Management (IAM) services provided by the CSP for better integration of the services to the cloud platform.
- You can utilize Azure AD for Authentication and Authorization in the Cloud.
- In case you are using On-premises based Active Directory service, then the same can be used in the cloud as well with integration with Azure AD or in AWS you can use identity federation using IAM plus integration with on-premises AD.
- Azure AD can also be used as a source of authentication in AWS IAM and SSO.
- In Azure, we can leverage Service Principals and Managed Identities for seamless integration with external services and between internal services.
- You can also explore OpenID Connect in order to access multiple services using SSO
- Some reference web links from the respective documentation of AWS, Azure and GCP
https://www.linkedin.com/pulse/azure-service-principle-vs-managed-identity-pathirippilly-mana/
https://cloud.google.com/identity-platform?hl=en
Logging, Monitoring, Observability, Vulnerability scanning and reporting:
- Proper logging, monitoring and observability solutions should be in place in order to track and identify issues during runtime and also for proactive monitoring.
- Azure Monitor, AWS Cloud Watch and Google Cloud’s operations suite (formerly Stackdriver) could be utilized with proper configuration.
- Alternatively third party solutions could be used like ELK, Prometheus & Graffana, NewRelic, Datadog or Crowdstrike etc. These third party tools are available as managed or marketplace products in most of CSPs.
- There are many third party security and vulnerability scanning tools available in the market that support AWS, Azure and GCP. You can explore them as per your requirement.
CDN and Edge network solution:
- In case your user base is spread across multiple geographies and regions, it is recommended to utilize the natively available edge or CDN network in combination with Firewall and DDOS protection.
- Alternatively you can also procure third party self managed CDN subscription from an organization like Akamai etc. They also provide Firewall and API management solutions bundled as a package.
Security in the cloud is itself a huge topic in itself hence its not possible to cover every minute details in a single blog post. All the three major CSPs provide equivalent tools and service along with robust frameworks and documentations that could be utilized to gain more insights on the security related services provided by them natively.
In conclusion, I highly recommend to utilize the native services wherever available and possible to be used from the CSPs that makes your configuration and management easier. At the same time, their native security tools and services are designed with proper alignment with the robust cloud Infra security practices they are following themselves at their underlying cloud infrastructure.
Some reference web links from the respective documentation of AWS, Azure and GCP
https://aws.amazon.com/compliance/shared-responsibility-model/
https://aws.amazon.com/security/
https://azure.microsoft.com/en-in/explore/trusted-cloud/compliance
https://learn.microsoft.com/en-us/azure/security/fundamentals/overview
Passion For Technology 
Leave a comment