Impact Group: Blog
Cloud Migration – Demystifying the Shared Responsibility Model
It’s common knowledge that cloud service providers follow a shared responsibility model, which means that when migrating applications, data, containers, and workloads to the cloud, your security team has some responsibility for security. However, many IT leaders share in confidence that they remain unclear about how the cloud works and hope that somehow mysteriously, everything works out as it should – all without their involvement.
In this post, we will try to demystify the migration to the cloud when it comes to the division of responsibility, also known as the Shared Responsibility Model, with a strong emphasis on security.
Under this model, the provider has some responsibility for security, but not entirely. Defining the boundaries between your and the vendor’s responsibilities is critical to reducing the risk of vulnerabilities in public, hybrid, and multi-cloud environments.
In the traditional data center model, you are responsible for securing the entire operating environment, applications, physical servers, user controls, and even the physical security of the building. Your provider takes on many such operational burdens in the cloud model, including security.
A good cloud service provider will share some of the responsibility for security while you maintain a secure environment and lower your operating costs. In this shared responsibility model, responsibility for security must be clearly defined, with each party retaining complete control of the assets, processes, and functions it owns. With this defined, you will have a clear picture of how the cloud works, who secures what, and what happens in case of a breach. The key to successfully implementing security in the cloud is understanding where your provider’s responsibility ends, and yours begins. Both AWS and Azure state that the security responsibilities you retain will depend on your chosen service.
For example, under the AWS Shared Security Model, AWS is responsible for “protecting the hardware, software, networks, and facilities that run AWS cloud services.” Microsoft Azure states that they protect “physical hosts, networks and data centers.”
This Microsoft white paper might provide additional insight into the complexities of the Shared Responsivities Model and its industry adoption.
Even though similar in wording, the above Shared Responsibility agreements leave much room for discussion and interpretation.
Each environment, application, and service will require a unique approach to assessing and monitoring security. One of the most fundamental facts is that some security aspects are provider-specific, and others will always remain yours for services, applications, and controls between these ownership levels. Furthermore, these ownership changes create complexities and risks in a multi-cloud environment.
Before we get too granular, let me point out one more essential fact. Your weakest link will determine your overall security position. If you have a coverage gap on any one system, you increase the vulnerability of the entire stack and all connected systems.
Layers of the Shared Responsibility Model
Information and Data: By maintaining control over information and data, you control how and when your data is used. Your ISP does not have access to your data, and all access to the data belongs to you, and you can control it.
Application logic and code: Regardless of how you choose to run your cloud resources, your proprietary applications will remain at your disposal for protection and control throughout the entire application lifecycle. Including protecting code repositories from abuse or malicious intrusion, testing application builds throughout the development and integration process, ensuring secure access to the production environment, and maintaining the security of all connected systems.
Identity and Access: You are responsible for all aspects of identity and access management (IAM), including authentication and authorization mechanisms, single sign-on (SSO), multi-factor authentication (MFA), access keys, certificates, and user creation, and password management processes.
Platform and Resource Configuration: You control the operating environment when running cloud environments. Maintaining control over these environments depends on whether your instances are server or serverless. A server-based instance requires more practical security controls, including the operating system and application hardening, application patch support, etc.
Essentially, your server instances in the cloud behave just like your physical servers and function as an extension of your data center. For serverless resources, your provider’s control plane gives you access to your configuration, and it is your responsibility to know how to set up your instance securely. In addition, you remain responsible for protecting everything in your organization that connects to the cloud, including the local infrastructure stack and user devices, your networks, applications, and the communication layers that link your users and between internal and external clouds.
Alerting and Monitoring: Cloud providers offer different types of alerting; you are responsible for configuring those, setting up monitoring and alerting for security threats, events, and responses for domains that are still under your control. Whether you use systems from AWS, Azure, or any other public cloud provider, these responsibilities are yours.
Identity and Directory Infrastructure: Whether you use OS-level identity directories such as Microsoft Active Directory or LDAP on Linux, you can choose a third-party identity directory solution, set up security, and manage that system in an IaaS cloud implementation.
Applications: Server-based cloud environments, like local hosts, are a clean slate for installing and maintaining applications and workloads. You can run PaaS applications on your cloud servers, in which case you can take some of the security burdens off. However, you are responsible for the security of any application or workload that you move from your data center to a server instance in the cloud.
Network Control: Your ISP only manages the network under its direct control. All networks above the virtualization layer, whether physical or infrastructural as code, require security configuration and monitoring.
Operating system: You can select the operating system and patch levels for server-based instances. While this gives you more flexibility, it also means more responsibility from a security standpoint. To secure your server-based cloud resources, you will need to keep up to date with current vulnerabilities, security patches, and hardening exercises. By choosing serverless or PaaS solutions, you remove some security burdens.
Serverless solutions provide a configuration management plane, and it is the user’s responsibility to configure this service securely. Serverless environments typically offer some control over the physical implementation of identity and directory infrastructure, applications, and network controls, but you are still responsible for properly configuring access control through the control plane. For example, in a serverless environment, you may be able to choose an operating system (usually Microsoft or Linux), and your provider retains responsibility for patching the operating system and managing security in that environment. It may feel like you have a lot of security responsibility, but most of the burden lies with your ISP.
Virtualization layer: By managing physical resource allocation through virtualization, providers provide CPU, GPU, storage, and memory segmentation and isolation to protect users, applications, and data. This abstraction layer acts as a gateway and fence, allowing access to the provisioned resources and protecting against potential misuse or malicious intrusion from the user environments below and the physical layer above.
Physical Hosts, Network, and Data Center: Cloud service providers protect their hardware through various software and physical means. Major cloud providers such as AWS and Azure defend their servers from physical intrusion and unauthorized access using a variety of protocols and provide a fast failover and high availability with integrated backup, recovery, and disaster recovery solutions.
The speed and ease of setting up software-defined infrastructure open new levels of flexibility and agility for your business. However, reconfiguring resources on the fly can also have immediate and far-reaching implications. The possibility of misconfiguration can lead to security vulnerabilities.
In closing, your operations team must work closely with security professionals to maintain policy-based control over how and when cloud resources are configured. Your security team is also responsible for monitoring potential vulnerabilities in cloud resource management. Configuration and Security Teams can work together through planned scenarios, automation, and self-service workflows, providing you with secure, controlled access to the cloud. Wherever your security responsibilities end and your cloud provider’s responsibilities begin, your company’s responsibility is to meet the necessary organizational standards and regulations. Centralized security management, automation, and response enable you to collect and analyze data across your infrastructure, including on-premises, public, hybrid and multi-cloud environments, all the way to the edge and endpoint.
As you can see, there is no mystery in how security responsibility are shared under this model. And, if it sounds overwhelming, you’re not the only one to feel this way. More and more organizations rely on managed service providers like IMPACT Group to provide you with the consistency and efficiency needed in running a secure cloud implementation.
To maximize your IT operations, [reach out to us] to find out how Impact Group can help you in the journey to better security.
References:
