CLOUD COMPUTING FOR REGULATED "GXP" ENVIRONMENTS - PART 1

Since the beginning of the Internet, only network administrators and IT infrastructure architects took care of the effective topology and details of the network. End users needed only to know where and how to connect their terminal devices without any knowledge about the details behind the network outlet in the wall. That's how the term cloud developed which comes from the traditional graphical representation used for "Internet" as well as for "outside" IT Infrastructure.

From identified server to hyperlink

Starting by a "pure" network infrastructure (Internet), with the deployment of the World Wide Web, the Cloud began to propose more services and at the same time to become more abstract. While in the early time of Internet the connection to the ftp server of the Library of Congress was assumed to be connected to a hardware server located within the IT infrastructure of the Library, the use of web services became to be less location related and the end user started to ignore the real location of the servers behind the hypertext link. Since the relationship to a clearly identified geographical location was lost, the Cloud was definitively born.

Various kinds of application could be deployed based on cloud computing, for example:

• Collaborative tools, including calendars, address books, mail services
• Dedicated applications such as ERP, relationship management system, procurement platform
• Information management systems, e.g. document management system.

Cloud definitions

Cloud computing is typically a generic and nebulous term describing a lot of various topologies and services where each of them has a specific meaning with specific benefits and concerns.

The cloud implies a kind of "black box" view. Indeed, the cloud is an abstraction of a collection of IT infrastructure components such as servers, storage systems, networks, etc. The cloud makes it possible for the user to ignore the detail of the IT infrastructure which supports their own application and data.

Recommendation

Berlin, Germany23 April 2024

Computerised System Validation: Introduction to Risk Management

Only in September 2011, NIST^[1] provided a formal and well accepted brief set of definitions about cloud computing covering:

• Service models
• Deployment models

Usually three models of services¹ are associated with cloud computing:

• Software as a Service (SaaS)
• Platform as a Service (PaaS)
• Infrastructure as a Service (IaaS)

Each model represents a specific scope and implies a specific sharing of responsibility between service provider (SP) and regulated user (RU).

SaaS - Software as a Service

By the SaaS model, a configured application, including all necessary infrastructure and platform components as well as hosting facility, is delivered to the regulated user. The RU contribution is limited to the following activities:

• Final configuration and verification
• User management

The data reside in the cloud infrastructure under the SP's responsibility. The RU can only have an impact - if any - on backup scheduling. The RU will only request restore activities without any impact on their execution.

Application Operational and Performance Qualification (OQ, PQ) remain the RU 's responsibilities. It is possible for the regulated user to buy the execution of qualification activities from the service provider. Nevertheless, from a regulatory point of view, the qualification activities remain in the scope of the RU's responsibility.

The SaaS model is similar to the ASP concept - Application Service Provider - as promoted in the late 1990ies. The regulated user does not own the application but he pays a right to use it.

PaaS - Platform as a Service

By the PaaS model, a middleware, including all necessary infrastructure components as well as hosting facility, is delivered to the regulated user. The RU has to perform the following activities:

Middleware configuration and verification

Application development respectively installation

Application configuration and verification

User management

As by the SaaS model, the data reside in the cloud infrastructure under the SP's responsibility. The RU can only have an impact on backup scheduling. The RU will only request restore activities without having any impact on their execution.

Depending on the technology used and the agreed contract, the RU could be allowed to perform some data dumps to save data and configuration outside of the cloud.

IaaS - Infrastructure as a Service

By the IaaS model, computational and storage resources, including all necessary network components and hosting facilities, are delivered to the regulated user. Depending on the contract conditions, the RU has to perform the following activities:

• Installation, configuration and maintenance of the server operating system
• Installation, configuration and maintenance of the middleware
• Verification of the installed configuration
• Application development respectively installation
• Application configuration and verification
• User management.

Like by the SaaS and PaaS models, the data reside in the cloud infrastructure under the SP's responsibility. The RU can only have an impact on backup scheduling. The RU will only request restore activities without having any impact on their execution.

Depending on the technology used and the agreed contract, the RU could be allowed to perform some data dumps in order to save data and configuration outside of the cloud.

Based on the infrastructure used and on the contract conditions, it is possible for the RU to have some limited controls on network security components such as firewalls.

Practical example

Operating a web site requires the installation of an IT network, mail service, server hardware, operating system (Linux, Windows, …), http-server software (Apache, Tomcat, IIS, …), analysis and reporting tools, programming language (PHP, Perl, Ruby, …), content management software (Drupal, Joomla, Typo3, …), database (MySQL, Postgres, Oracle-DB, MS-SQL, …). Additionally data storage (SAN, NAS, …) and backup facilities must be installed in order to store and to secure the data.

The impact of the corresponding service models on the provided service package is shown in the following table:

Depending on the service provider, in particular the scope of the platform can vary. Obviously, the content remains in the direct responsibility of the regulated user.

Cloud deployment models

Deploying applications over the cloud does not have to imply sharing infrastructure, platform or applications with external users. Indeed various deployment models are possible based on a cloud approach:

• Internal / external private cloud
  The cloud infrastructure is designed and delivered for the exclusive use by the regulated user organisation. In such cases, the cloud could be operated by the internal IT organisation or by an IT outsourcer. The cloud infrastructure can be located "in-house" (internally) or externally.
• Community cloud
  The cloud infrastructure is designed and delivered for the exclusive use by a specific community of user organisations. In such cases, the user organisations share common concerns, requirements as well as compliance needs.
• Public cloud
  The cloud infrastructure is open for public use.
• Hybrid cloud
  The cloud infrastructure is a combination of the above mentioned deployment models (private, community, public).

Benefits and concerns

The main benefits of cloud-based service delivery could be summarized as follows:

• Flexibility and service elasticity: capability to simply upand down-size the delivered services without thresholds
• Rapid and on-demand service delivery: no delay due to procurement
• Better energy and resources management: "green IT"
• Availability and business continuity, if the cloud infrastructure is designed and managed adequately (see part II of this article in the next GMP Journal issue).

Even if cloud computing seems to be attractive, some significant concerns should be taken into account, especially for regulated organisations:

• Data privacy, data confidentiality
• Security
• Service availability
• Service provider dependency.

As soon as data are not stored within an internal private cloud², they are possibly accessible to third parties and at least partially out of direct control of the data owner (regulated user). The use of encryption may help to improve the data privacy and confidentiality. However, in such cases, one should not rely exclusively on built-in cloud encryption mechanisms, because such mechanisms could contain some back doors or other security weaknesses. Ideally encryption should be deployed and managed by the data owner themselves. Nevertheless even if the concept is simple, its implementation could imply the need to master various technological challenges and to suffer some negative impacts regarding performance and limitations during operation.

Recommendation

Berlin, Germany24-26 April 2024

Computerised System Validation: The GAMP 5 Approach

The marketing departments of cloud service providers like to advertise the availability of cloud solutions. Nonetheless, the last five years show a collection of significant interruption of service from some hours to several days. All cloud service providers have to report service breakdowns. In October 2011, the disruption of mail services during several days by a mobile phone company showed how companies are technology and service dependent. If a large part of the office work requires cloud access, companies will be simply unable to work in the case of service disruption. The "29th February 2012 bug" - 12 years after year 2000 - showed again the weaknesses³ and the limited availability of some cloud solutions. The ability "to have access to the data anywhere" (marketing claim) can rapidly become "no access from anywhere" (sad reality).

By using cloud-based solutions, the RU has to manage a double dependency regarding its service provider:

• During operation, since the service must be available. The cloud service is the new and crucial "common mode failure" within the IT landscape.
• When changing the service provider, since the migration of data and application could represent a very expensive, time consuming, and challenging project. Every service level agreement (SLA) should define the conditions to cancel the service delivery as well as to move and to secure the data to another place. Surprisingly, this specific point is both rarely as well as inadequately addressed and the conditions for changing the service provider are unclear and they could jeopardize data integrity and availability.

Part II of this article will be published in the next issue.

Author:
Yves Samson
... is founder and Director of the consulting firm Kereon AG located in Basle, Switzerland. He has been in computerized system validation since 1992. He is the editor of the French Version of GAMP^®4 and GAMP^®5 and he translated the PIC/S Guide PI 011 into French.

Source:
[1] National Institute of Standards and Technology, "NIST Special Publication 800-145 - The NIST Definition of Cloud Computing," NIST, Gaithersburg, 2011.
¹ Further service models can be found in the technical literature, although they mostly correspond to a combination of the three service models defined by NIST. This article focuses on the service models as defined by NIST, see [1].
² Because of possible security weaknesses, data stored within the internal IT infrastructure may be subject to unauthorized access. Nevertheless it is simpler to limit and to control the access to data within an internal infrastructure than if the data are stored externally. This remark applied equally to data hosted by an outsourced datacentre operated by an external service provider.
³ The same company did experience significant availability problems in September 2011 impacting all cloud-based services, because of load balancing malfunction inducing DNS-failures. Regarding the leap year issue, it is probably justified by a real sense for accuracy since the leap year is out of the scope of the solution's name "…365".