At the time of writing this material, many individuals and organizations expressed their point of view regarding the “concept” of cloud computing (cloud computing), its advantages and disadvantages. However, it must be understood that the term “cloud computing” encompasses a wide variety of both systems and technologies, as well as deployment models, services, and business conduct. A number of statements that are sometimes made regarding cloud computing, for example, that they “scale” or that they convert capital expenditures (CAPEX) to operational (OPEX), are true only for certain types of cloud systems. The purpose of this section is to clearly describe the separation of cloud computing systems or cloud systems into five significant scenarios and, for each of these scenarios, to explain the main aspects (such
2) This section presents a physical – network view of how subscribers (cloud consumers – customers) of services are connected to cloud systems. Understanding the cloud and the constituent parts of the traditional software “stack” available to subscribers is equally important and is discussed in sections 5, 6 and 7 of this (original) document.
As suggested in the definition of NIST cloud computing, a cloud system is a collection of resources available online for customers ( i.e., cloud subscribers – cloud consumers ). In the general case, the cloud system and its subscribers use the client-server model, which assumes that subscribers send messages to server computers over the network, which, in response to the received messages, perform the corresponding work.
Figure 1: A general view of the cloud and subscribers
Figure 1 gives a general view of the cloud and its customers: cloud computing resources are described as a set of interconnected * computer systems accessed by clients over the network. As shown in the figure, new customers may appear, old customers may leave, at different points in time, the number of customers will be different. Similarly, the cloud supports a hardware pool that it manages to maximize ( increase performance and level ) service and minimize costs. To support high availability of services, despite the expected failures and expiration of the component, the cloud as needed **connects new and decommissioned old or failed hardware components. The cloud effectively manages the pool of hardware resources for optimal, so-called costs of providing services. One of the strategies of <such management> is that the cloud provider disables unused components for a period of reduced subscriber needs. From a power management or hardware upgrade perspective, migrating customer workloads from one physical computer to another is a key strategy that allows a provider to upgrade hardware and consolidate workloads without causing inconvenience to subscribers.
In this case, grid seems logical to translate just like that, because Cloud computing does not always involve the use of Grid technology. Lingvo Computers gives the following definitions:
- Grid – architecture, concept, technology Grid – a virtualization-oriented computing method of organizing the computing process when parts of a task are distributed across all available network resources.
- “Grid computing – network (collective, parallel, distributed) computing,” lattice “of computing resources, grid computing – the term refers primarily to the architecture of global, regional and institutional computer networks, provides for the use of currently free network resources for solving problems, too complex for a single computer, and requires special software.
In turn, cloud technologies do not directly imply (although they do not deny) the use of the distribution of the execution of parts of the task to different nodes of the “lattice”, which is distributed computing resources that are connected in a special way to perform, in fact, mass-parallel computing.
For sure, you noticed that in the proposed translations “as needed” and “on demand” are translated not “on demand”, but “on necessity”. This choice is due to a softer and, to a certain extent, preventive for a number of cases meaning “of necessity”. A customer request, received in one form or another, may not always correspond to the agreed level of service (SLA), and the need can be identified by the service provider without any notice to the client. For example, a need or a need is identified on the basis of an analysis of statistics on the use of a resource pool by customers and a forecast for a further increase in resource utilization, associated with an increase in the resource requirements of existing customers,
Figure 1 represents only a small part of the general statements (considerations, aspects) that are characteristic of cloud computing. Organizations suggest that the use of cloud computing should reflect such general considerations (presented below). At the same time, many of the statements made in relation to cloud computing (for example, that clouds can scale for very large workloads or their application allows replacing capital costs with operational ones), are correct only for certain types of clouds. To avoid confusion, this document explicitly qualifies each of these locations for each type of cloud, where that location applies – i.e. each statement has boundaries of “applicability” of content (“scope”). Such boundaries used in the document are presented in Table 1.
Table 1: Scenarios – Scope Modifiers for Statements Asserted About Clouds
|Application Boundaries – Scenarios||Description of applicability limits|
i.e. all cloud options
|Applies to all cloud deployment models.|
|own private cloud|
|Applies to private clouds implemented at the customer’s site ( i.e., fully controlled by the customer )|
|outsourced private cloud|
|Applies to private clouds hosted on an external hosting hosted by an outsourcing company|
|own community cloud|
|Applies to community clouds implemented at the community customer site.|
|Applies to community clouds whose servers ( and other hardware such as storage systems ) are hosted on an external hosting hosted by an outsourcing company|
|Applies to public clouds|
Each of the presented scenarios of applicability limits is considered below.
The following statements are general in their limits of applicability, i.e. correct regardless of deployment model or service model (i.e. service delivery model):
- Network dependency is a common case. Subscribers, being customers ( from the so-called business ), need a working and secure network access to the cloud. If the network is unreliable (reliable in every sense – stability of access and security ), the cloud will not be considered reliable from the point of view of the subscriber.
- Subscribers still need IT skills – a common case . By operating server computers < at their site >, a provider can reduce the need for IT organizations for subscribing organizations. However, subscribers will access the cloud from their client systems that require management, maintenance, support, security, etc.
- Place of performance of the working load is assigned dynamically , and hidden from the client (Workload locations are dynamically assigned and are thus hidden from clients) – a common case. To effectively manage cloud hardware resources, providers must be able to migrate subscriber workloads between machines ( physical nodes of the cloud ) without inconvenience to customers, i.e. without the requirement for customers to track and adapt to such changes (made by the provider) and even without notifying customers of the changes made (3).
3) In some cases (for example, the IaaS service model described in Section 7 of the original document), the workload can be performed at a specified location in a certain period of time before the migration; in other cases (for example, the PaaS service model described in Section 6 of the original document), the workload can be an initially distributed entity that sequentially performs operations for subscribers on potentially different servers – in this case, < processed> Data exists in a geographically distributed storage.
- Risks of multiple rentals ( Risks from multi – tenancy ) – general case. The workloads of different clients can be performed simultaneously on the same cloud systems and local network, being separated only by access policies defined at the provider software level. Vulnerabilities in this software or in policies could damage the security of subscribers.
- Data import / export restrictions and the possibility of their implementation * (the Data import statement / export, and performance Limitations) – general case. Due to the fact that subscribers access <the cloud> over the network, the required temporal characteristics of bulk import and export of data can exceed the capabilities of the network. In addition, real-time operation or processing of critical requests may be problematic due to network delays and other limitations.
It is understood that we are talking not only about performance limitations, but also other possible limitations that do not allow us to provide the required parameters for mass data input / output to / from the cloud system.
Organizations considering the possibility of using cloud computing should take into account these general considerations and their possible consequences for their business model and the achievement of long-term goals (missions). However, it is not enough to pay attention only to the general aspects of cloud computing. Clouds are also described by the boundaries of applicability of one or more of the characteristics presented in Table 1. Organizations discussing the use of clouds should consider in detail the aspects of using different scenarios ( options taking into account the boundaries of applicability ) of clouds that are the subject of such a discussion. Each of the alternatives is independently considered below in a separate section ( this and, more extensive, original) of the document, focusing on the given limits of applicability (4).
4) This document does not repeat certain fragments of the text. However, for specific types of clouds, more considerations relevant to each specific type can be described; in this case, the name of the general characteristic / statement can be used again, but with an explanation specific to the particular type of cloud.
4.1 Understanding that , who controls the resources in the cloud (Understanding Who Controls Resources in a Cloud )
It is sometimes argued that when comparing the use of clouds with the traditional model of “on-premises” computing, the cloud model requires subscribers to transfer to the provider two important features that require a high level of trust of the subscriber to the provider:
- Control ( the Control ): the possibility to decide who and what can access data and subscriber programs, and execute < certain > actions (such as erasing data or disconnection from the network) to be made, but without further action, which in turn, they may not correspond to the intentions of the subscriber (for example, the subscriber requests the erasure of data objects, which should not be accompanied by their implicit copying at the initiative of the provider ).
- Visibility – Visibility : the ability to monitor the status of programs and subscriber data and how they are accessed.
However, the boundaries of control and visibility that need to be transferred to the provider by subscribers depend on many factors, including physical ownership and the ability to configure (with a high level of trust) mechanisms to protect the boundaries of access to subscribers’ computing resources.
This document uses the concept of access boundaries to structure and characterize different cloud deployment models. Figure 2 illustrates the key concept of computer security * associated with boundaries and control – the security perimeter. As shown in the figure, the security perimeter acts as a barrier to < operations> access: entities that are inside the perimeter can freely access resources that are only inside the perimeter; however, entities that are outside the perimeter can access resources within the perimeter if this is permitted by the border control (boundary controller) based on the use of appropriate access policies. Despite the fact that these terms are often used when discussing firewalls and networks, the concept of a security perimeter is, in reality. It is more general and can be used, for example, to describe the boundaries between different privileges of software execution, i.e. boundaries <between> applications and the operating system. By itself, defining a security perimeter is NOT an adequate security mechanism. However, security perimeter monitoring is an important element in building secure systems.
*) it should be noted that it is the NIST standards and recommendations in the field of computer / information security that to a large extent have determined the foundation and continue to determine the conceptual basis and approaches to the theory and practical security in the information technology industry.
Typical border controllers include firewalls, guards, and virtual private networks (VPNs). The organization can achieve an assessment of quantitative indicators both in terms of controlling the use of resources and monitoring access to them (5). Moreover, by reconfiguring the security perimeter, an organization can adapt it to changing needs (for example, blocking or allowing protocols or data formats based on changes in business conditions).5) When there are uncontrolled paths of < access > to computer resources, the security perimeter is broken ( in the original, weakened, weakened ) or even absent. The pervasive wireless communications, for example, are a threat to the security perimeter, starting with the fact that there can be no reliable way to implement a <boundary controller> between external and internal entities. Similarly, many organizations use mobile devices that sometimes connect < to resources > while inside the perimeter, and sometimes remain without < adequate protection> for example when traveling.
The various cloud deployment models described in the NIST cloud computing definition involve the placement of a subscriber-controlled security perimeter and, therefore, the level of control that subscribers can exercise with respect to resources trusted by the cloud ( i.e., transferred to the control of the cloud provider with a certain level of trust in this provider ).Figure 2: Security Perimeter
Definition of Cloud Computing NIST describes four deployment models: a private cloud, a community cloud, a public cloud, and a hybrid cloud. However, each of the private cloud and community cloud models allows two options – the < deployment > scenario , which must be considered separately, due to the impact on the security perimeter: whether it will be on-site or outsourced. A hybrid deployment model is a combination of other models and, therefore, a hybrid deployment may also have an effect < on the security perimeter> its elements – “building blocks”, and unique aspects of influence that arise as a result of combining many systems into more complex integrated systems.
4.2 Scenario own private cloud ( of The the On – site of Private Cloud the Scenario )
Figure 3 provides a simple view of an on-site private cloud. As shown in the figure, the security perimeter extends around the subscriber’s own resources and private cloud resources. A private cloud can be centralized on one site or distributed between several sites of a subscriber. The security perimeter will exist only if the subscriber implements it. In the case of implementation, the perimeter does not guarantee control of all resources of the private cloud, but its existence gives the subscriber the opportunity to control resources trusted by their own private cloud.Figure 3: Private Private Cloud
Despite the fact that general assumptions remain true for their own private cloud, this scenario allows us to assume others, including more detailed aspects to be taken into account by organizations considering the use of their own private clouds:
- Network dependence (Network dependency) – own private cloud (on-site-private).
Depending on the configuration (for example, one physical site, a secure cloud network), the network dependence for your own private cloud may be limited by the dependence on network resources that the subscriber controls (for example, a local network). In this scenario, problems of large-scale networks such as Internet congestion or communication with remote (in the sense of remote) Internet domain name servers (Internet DNS) can be eliminated. In addition, if a security perimeter is implemented for high levels of protection, it is not always necessary to use security mechanisms such as multi-factor authentication and end-to-end encryption when exchanging within the perimeter even with fairly careful ( minimizing the corresponding risks ) security policies.
If the subscriber organization has many physical sites and organizes access from different sites to the same private cloud, the subscriber must provide control of communications between sites, (for example, encryption communication lines) or use cryptographic tools (for example, VPN) over less controlled communication tools such as the public Internet. Both of these options have the risks of network availability and security of the private cloud, due to the fact that there is a dependence on the performance of resources ( communication tools ) that are outside the subscriber-controlled area, and because any errors in the implementation and configuration of cryptographic mechanisms may allow you to receive access from the outside.
- Subscribers still need IT skills – their own private cloud (on-site-private). Subscribing organizations will need the traditional IT skills necessary to manage the user devices from which they access the private cloud, while the requirements for the availability of skills and the cloud technologies are relevant for them. Earlier, at the stage of deploying their own private cloud, subscribing organizations may want to simultaneously support both cloud and traditional tools for a certain period of time * .
*) There are many factors that influence the choice of systems to be ported to the cloud infrastructure. We can assume that far from all the organization’s resources will be transferred to the cloud infrastructure, both due to technological limitations and specific requirements of many solutions used in the corporate environment, and due to the financial aspects of the transition to cloud versions (if they exist and are available for purchase ) operated traditional systems. Thus, the coexistence (with one or another separation boundary and volume of use) of the cloud and its own traditional infrastructure seems to be the most likely scenario for the organization of corporate IT, which imposes additional requirements not only on skills,
In addition, new cloud skills may be required. For example, organizations performing work requiring intensive computing may need to reorganize these work over time so that they can use a high level of concurrency of cloud resources. Organizations that process large amounts of data, in turn, may need to develop skills in using cloud storage systems ( in a general sense, and not just hardware ).
- The place of execution of workloads is assigned dynamically and is hidden from clients (Workload locations are hidden from clients) – its own private cloud (on-site-private). As in the general case, a private cloud, from the point of view of managing hardware resources, should provide the ability to migrate workloads between machines < physical nodes> without causing any inconvenience to customers, i.e. even without the need for customers to know about it. At the same time, in the case of its own private cloud, the subscriber’s organization selects the physical infrastructure for the deployment and operation of the private cloud and, therefore, determines the possible geographical location of the workload location. And if individual clients may not know exactly where their workloads are physically performed at a given time in terms of the subscriber’s organization infrastructure, the organization itself has the knowledge and control of all workloads that are allowed to be performed < in its own private cloud >.
- Risks from multi-tenancy – own private cloud (on-site-private). As in the general case, the workloads of various clients can be performed simultaneously on the same systems and networks, being separated only by access policies defined at the provider software level. Vulnerabilities in this software or in policies can damage the security of subscriber organizations, making client workloads visible / accessible to other parties, in violation of security policies. Own private cloud < by nature > to some extent mitigates these risks, < initially> limiting the number of possible violators; usually, all clients are members of the subscribing organization or authorized partners or guests ( guest in terms of network access ), however, their own private cloud remains vulnerable to attacks by authorized, but malicious malicious insiders. Various organizational functions, such as payrolls, personal data warehouses, or created intellectual property, may be subject to the same security vulnerabilities that could allow access to users who are unauthorized to access certain classes of data and who may disclose data <out of> from your own private cloud.
- Data import / export, and performance limitations – own private cloud (on-site-private). As in the general case, the required bulk import and export operations are limited by network bandwidth, and real-time operation or processing of critical requests may be problematic due to network restrictions ( including delays in transmitting data over the network) – network latency ). In the particular case, if the subscriber has only one site that needs access to his own private cloud, the subscriber can be provided with access to a local network that provides better performance than that which can be achieved when accessing through the global network.
- Potentially stronger protection from external threats (Potentially strong security from external threats) – own private cloud (on-site-private). When using its own private cloud, the subscriber is able to implement an appropriate <more> strict security perimeter to protect private cloud resources from external threats than can be achieved for non-cloud resources. For not so significant data ( low-impact data – data whose risk of leakage can lead only to insignificant consequences or does not matter at all ) and their processing, the security perimeter can contain < only standard> rule sets defined by commercial firewalls and VPNs. For more meaningful data, a security perimeter can be created using more restrictive restrictive firewall policies, multifactor authentication, and even physical isolation.
- Significant initial investment in building and migration of clouds (Significant-to-high up- front costs to migrate into the cloud) – own private cloud (on-site-private). Own private cloud requires the installation of cloud management software on the computing systems of the subscribing organization. If it is planned that the cloud will support workloads involving intensive computing or data processing, the <appropriate> software must be installed on a large number of widespread ( cheaper– commodity) systems or on fewer high-performance ( more expensive ) systems. Installing and managing cloud software will result in significant up-front costs, even if the cloud software is free, and even if most of the “hardware planned for use in the cloud ” already exists in the organization. There are three possible approaches to building your own private cloud:
New Data Center – data center, data center ( New Data Center ): The most straightforward approach for the subscriber is to create a “dedicated” data center in which the cloud software will be deployed. In this case, your own private cloud involves costs similar to investing in a typical data center and the subscriber can prepare it for the expected workloads. Data Center
Transformation ( Converted Data Center ):As an alternative to creating a new data center, the subscriber can completely transform the existing data center or its individual parts to support its own private cloud. This approach, however, can lead to incompatibility of the parallel functioning of cloud and ordinary non-cloud systems during their coexistence period.
Cleaning Resources ( scavenged the Resources ):Another alternative approach is to install cloud software on existing computers in the organization. In this scenario, cloud systems share hardware resources with other forms of use of equipment and can significantly improve the utilization of resources that might otherwise be idle. This approach gives the advantage of offering cloud services on an experimental basis without a large investment in equipment; however, the resources available in this configuration will be limited by the existing surplus hardware resources present in the organization’s infrastructure (until the previous ways of using the equipment are reduced <to the minimum> and it is <to the maximum volume> transferred to the use of the cloud) .
Additional restrictions include:
(1) hardware resources must be embedded (incorporated) as soon as possible into their own private cloud, regardless of where they exist in the subscriber’s organization infrastructure (being used over the network), despite the greater efficiency of collocation (shared physical placement) );
(2) the available equipment may not be uniform and this will lead to additional administrative difficulties.
- Limited resources – own private cloud (on-site-private). At any given point in time, its own private cloud has a fixed computing power and storage capacity that can be allocated for the corresponding expected workloads. Own private cloud implies appropriate cost restrictions. If the organization is large enough and supports a sufficiently wide variety of workloads, its own private cloud may be able to provide customers with the necessary elasticity within the organization. At the same time, smaller < by available resources> Own private clouds will show maximum load limits in the same way as with traditional data centers. Own private cloud also requires initial investments (for example, in equipment) even before the cloud becomes available to subscribers.