Applying the AWS Shared Responsibility Model to your GxP Solution

The AWS Shared Responsibility Model is often discussed as a topic to illustrate AWS security principles, but you can also apply it to compliance-related activities such as GxP. The shared model provides constructive mechanisms to illustrate the separation of tasks between AWS and the customer. AWS is responsible for the security and compliance of the Cloud, where the customer is responsible for security and compliance in the Cloud.

It’s a bit like driving a car; you don’t need to worry about how a car engine works or how the air-conditioning keeps you cool; all you need is the skill to drive the car and control the basic features of the vehicle. In this fashion, you expect that car’s manufacturer will conform to safety standards that passengers and drivers rely upon for the car’s intended use. As the driver, you take responsibility for how you operate the vehicle, the speed you drive, obeying traffic laws, and who you share your car keys with, allowing access to the car.

Applying this analogy to AWS cloud-based solutions, AWS’ responsibility of security “of” the Cloud includes hardware, global infrastructure, and how regions, availability zones, and edge locations function and operate. It also encompasses the infrastructure software responsible for compute, storage, database, and network services. AWS customers are responsible for security “in” the Cloud, or what they bring into it. This includes network configurations, customer-controlled encryption, identity and access management (IAM), applications, and customer data. This concept is illustrated in Figure 1.

Figure 1: General Shared Responsibility Model on AWS

Shared Responsibility Model and Service Categories

AWS provides various services that cause the line between security “of” and “in” the Cloud to shift relative to responsibility. For example, cars do not have the same built-in capabilities. You could purchase a basic vehicle with no on-board entertainment system for its passengers. If you are technically savvy, you could build a media player and include a screen for your passengers to use. If this custom-built entertainment system breaks down or has a severe problem, the person who constructed it would be responsible for repairing it. The service center where you purchased the vehicle would have no responsibility for the solution you added to the car. A second option is that you could buy an aftermarket solution at your car dealership and install it yourself. In this case, if you bring the car in for service, they would not be responsible for this media device if it was not working correctly, but you could go back to the manufacturer of the device for service. Finally, you could purchase a car that includes the entertainment system, in which case all services associated with the vehicle, including the entertainment system, are included when buying the vehicle (e.g., the car is managed by the dealership). In all these scenarios, you are responsible for whatever music or movies you play on the entertainment system (the data used and stored by the solution). It is essential to consider the possibility that there are multiple car drivers (e.g., the car is multi-tenant). While the vehicle supports the ability to have multiple drivers and occupants, it is the owner’s responsibility to set up the adults’ profiles and other vehicle occupants, such as children, to ensure that they can not access the adult material (data security and isolation).

This car analogy illustrates how AWS services can be segmented relative to responsibility levels of the different systems’ underlying structure. The “build your own media system” analogy is comparable to deploying Amazon EC2 to utilize the infrastructure services to develop your solutions. In our car example, the vehicle provides basic needs such as power, battery backup when the engine is not running, and an interior that is dry and safe for the components. You constructed your media system, plugged it into the car, and configured it to work. Likewise, Amazon EC2 provides the compute environment and you control the entire solution, such as the operating system, application software, and can configure how your software interacts with other components. In this way, Amazon EC2 is considered an infrastructure service, similar to the car’s base vehicle model above, and you created the solution to run on top of it.

In the second scenario, consider a service like Amazon RDS. Here, you purchase a pre-packaged media solution. You are responsible for its configuration and how it is accessed, but you are not responsible for the internals of how it works or functions. You can consider this a containerized type of service where the internals are available for you to configure.

In the final scenario, consider a service like Amazon S3. Much like the pre-installed media system, you are responsible for the data you bring and configuring access to that data, but you do not control how it functions – AWS manages it. In this manner, the service details have been hidden from you.

Figure 2: Shared Responsibility Model by Service Types

AWS provides a continuum across the responsibility spectrum between “of” and “in” the Cloud scenarios, allowing solution developers to focus on their innovation while AWS performs the undifferentiated lifting relative to infrastructure and service management. This spectrum provides customers with the flexibility to choose the most appropriate services for both their solution and regulatory requirements.

Leveraging AWS Documentation as Evidence

These different levels of responsibility also apply to various aspects of solution development, extending to activities associated with security and compliance. From a compliance perspective, the general model applies to HIPAA, HiTrust, GxP, and others. By using the responsibility model guidelines discussed previously, you can perform assessments to determine ‘who’ (AWS or the customer) is responsible for providing the evidence documenting the compliance requirements are being satisfied.

For solutions requiring GxP compliance, the shared responsibility model defines who is responsible for providing the quality system and required documentation artifacts to support it. GxP does not dictate that a solution built from managed services is any worse or better than a solution constructed and deployed with infrastructure services or container services. Quality systems are only concerned with you documenting what you are building and how you will build it, and providing evidence that you followed your established processes. This equates to providing documented evidence from ideation and requirements analysis; design, build, and test; and validation and verification of what was built.

When building a solution involving AWS that requires GxP compliance, you first need to complete supplier assessments. AWS supports supplier assessment by providing access to various documentation artifacts via the AWS Artifact service in your account’s AWS Console. AWS Artifact is a self-service tool that provides on-demand access to AWS compliance reports, such as the Quality Management System Overview document and the ability to download third party audit reports relative to ISO, SOC, and others. These documents and reports become the evidence and attestation required for AWS services and infrastructure. Through AWS Artifact reports, AWS provides the documentation for how the services are built and managed, and the third party audit certifications are the evidence these processes are followed. The AWS Documentation and Service Level Agreements provide the specifications of each service that can be referenced in your design documentation and evidence that the services meet your defined requirements.

When using a managed service, such as Amazon S3, you are responsible for providing the documentation and evidence supporting your customer data, client-side encryption settings, and access control settings. You can reference the AWS documentation and certifications as your evidence of the AWS managed services satisfying your requirements in your documentation.

When you utilize infrastructure services, a larger amount of the general software stack falls under your responsibility. As with managed services, AWS documentation and certifications are used to support compute, storage, network, and hardware infrastructure. You are responsible for the documentation and evidence for the software stack that utilizes the infrastructure services, such as client and server-side encryption, network traffic protection, OS configuration and patching, and the platform and applications running with the infrastructure services.

Summary

AWS provides builders with a wide variety of services that can be utilized in solutions requiring GxP and other regulatory or compliance frameworks. The breadth of services enables solution builders the flexibility to choose between highly customizable options with greater customer responsibility or fully managed services requiring less customer responsibility beyond the basic configuration. In this way, AWS provides the undifferentiated heavy lifting, not only for infrastructure and solution creation, but also for compliance documentation and practices.

For more information on GxP with AWS, see the links in the “Learn more” section. Also, feel free to reach out to your AWS contacts or contact us to inquire about the various programs and offerings available to support you on your GxP journey.

AWS for Industries

Applying the AWS Shared Responsibility Model to your GxP Solution

Shared Responsibility Model and Service Categories

Leveraging AWS Documentation as Evidence

Summary

Learn more

Resources

Follow