| Listen on Google Podcasts | Listen on Mave | Listen on Yandex Music |
Ruslan Rakhmetov, Security Vision
Computing systems 40-50 years ago were mainframes (high-performance servers at the time) accessed from terminals (thin clients in today's terminology). Then, as end devices became faster and less expensive, the priority began to be given to the use of personal computers, with all high-loaded systems still running on servers (usually running UNIX-based operating systems). However, in the mid-2000s, it became clear that the growth of digitalisation and the shift of business processes online required flexibility in scaling computing power, lower cost of ownership and maintenance, and simplified administration.
The way out was found: large companies began to gradually introduce cloud computing systems, which, together with the use of virtualisation and containerisation technologies, made it possible to get away from being tied to physical hardware, moving to a new type of abstraction in the operation of IT systems. Then such cloud solutions became a separate and quite profitable business: large IT giants began to lease their computing power to tenant companies (‘tenants’), which sought to reduce their capital expenditures on equipment (CAPEX) and move to a more flexible and predictable model of operating expenses (OPEX) with the ability to shift some of the tasks of infrastructure maintenance to specialists Cloud providers. NISTpublication SP 800-210, ‘General Access Control Guidance for Cloud Systems,’ describes the principles of access control for cloud infrastructures, with specifics for each of the service models of computing service delivery.
So, cloud infrastructures can be categorised according to the principle of operation into the following types:
- Public cloud - a cloud service provider provides its infrastructure and services to the customer on a commercial basis, usually on a subscription basis.
- Private cloud - an organisation hosts part of its infrastructure in its own or a leased data centre and has full control over all hardware and software components.
- Hybrid cloud - An organisation combines both public and private clouds, hosting its applications and data according to its convenience and needs in one or the other infrastructure.
- Multi-cloud - An organisation uses multiple cloud service providers for reliability and resilience, for example, hosting its core infrastructure in one public cloud and backups and backup services in another.
Cloud infrastructures are typically provided with the following options:
- IaaS (infrastructure as a service) - providing a service under the ‘infrastructure as a service’ model, when the cloud provider provides only its hardware, network access and virtualisation system hypervisor, and customers are given the opportunity to install their own operating systems, application and system software, and business applications.
- PaaS (platform as a service) - provision of services on the model ‘platform as a service’, when the cloud provider provides the installed operating system (usually, giving a choice of several OS options based on Winows and Linux), and customers install only their software.
- SaaS (software as a service) - providing a service under the ‘software as a service’ model, where the cloud provider provides the end customer with a pre-installed business application with some ability to customise and modify it.
NIST SP 800-210 points out a number of factors that define the characteristics of access control for cloud systems:
1. broad network access: cloud platforms are accessible by default from the Internet to all users and client types (PCs, smartphones, thin clients, etc.), which increases the potential network attack surface.
2. Allocation of shared resources: cloud systems share their computing resources among users, which leads to the potential cyber risk of unauthorised access of one client to another client's data. In addition, the working principle and architecture of cloud solutions are such that customers cannot know exactly in which data centre, on which server or even in which country their data is processed, which can lead to legal complications.
3. Flexible scaling of computing resources: when a cloud customer needs new computing capacity, the cloud provider provides them with new virtual machines that need to be securely configured and access to them proactively controlled.
4. Resource consumption monitoring service: payment for cloud services depends on the amount of computational power consumed, among other things. Data about the consumed resources should not be unauthorisedly modified by clients, but should be readable by them.
5. Data access protection: clients should secure their data themselves and the cloud service provider can only provide some tools for this purpose. If the client data is not encrypted, it can be accessed by the administrator of the cloud service.
NIST publication SP 800-210 provides recommendations for providing access control for each of the service models (IaaS, PaaS, SaaS).
1. Recommendations for providing access control for the IaaS model.
1.1 Network access protection: at the infrastructure level, attackers can gain unauthorised access to network traffic, so customers should use traffic encryption, segmentation of virtual networks using VLANs, network access delimitation based on ACL lists.
1.2 Protect hypervisor access: hypervisor access allows operations on guest virtual machines and operating systems, including data access and privilege escalation, so only authorised cloud administrators should be given hypervisor administration rights.
1.3 Protect guest virtual machines: Interactions between guest virtual machines and operating systems should be blocked, as such interactions can lead to data leakage or malicious code execution. Isolation of virtual machines is also required to prevent a failing guest OS from consuming excessive amounts of computing resources. In addition, inactive guest machines may still contain sensitive information, which also requires access control to them.
1.4 API access protection: cloud platforms may provide their customers with access to APIs to manage guest virtual machines, which requires access control to such APIs.
1.5. Virtualisation management system protection: protecting a cloud platform with a virtualisation management system protects hypervisor and guest system data from unauthorised access and provides mechanisms to isolate systems.
2. Recommendations for providing access control for PaaS model.
2.1 Data protection: data shared between PaaS applications should be protected from unauthorised access by using the inbuilt security features of guest OSes (e.g. by PaaS containerisation) and by controlling memory access at the hypervisor level.
2.2 API access protection: cloud PaaS providers may provide access to APIs for managing microservices and applications within the platform, which requires access control to such APIs, e.g., through an authorisation server.
2.3 Data access control in PaaS: memory protection of PaaS services can be implemented by flushing the CPU data cache when switching contexts, and by implementing a centralised policy-based access control system that applies to all PaaS services applied by the client.
3. Recommendations for providing access control for the SaaS model.
3.1 Ensuring data protection by the owner: the data provider manages access to the processed data, defines data storage policies and appoints responsible persons.
3.2 Data confidentiality: the use of encryption and various authenticated user access control models ensure the confidentiality of SaaS application users' data.
3.3 Access authority management: a flexible and fast mechanism for assigning and revoking access rights ensures the security of SaaS operation.
3.4 Replicated data management: multiple copies of data (replicas) must be managed by a synchronisable access control policy.
3.5. multi-tenancy management: handling data from different users in the same SaaS application requires strict access control rules based on ABAC (attribute model), RBAC (role model), CBAC (context model) models. In addition, the cyber risks of exploiting vulnerabilities in the SaaS application itself to gain unauthorised access should be considered.
3.6 Attribute and role management: the choice of access attribute types and roles during the design phase of SaaS systems determines the robustness of access control. A small number of attributes can lead to insufficient flexibility of access control policies, and a large number of attributes can lead to excessive complexity of the access model.
3.7 Access policy management: transferring access policy management from the SaaS provider to the customer without providing the provider with the sensitive details of policy validation requirements is key to ensuring robust data access control in a SaaS application.
3.8 API access protection: access control can be implemented via API calls, while only allowing certain types of actions to authenticated API connections. For example, when working via REST and SOAP protocols, API calls must undergo authorisation to check access rights and further controlled execution of actions.
3.9 Data access control in SaaS: Authorisation systems in a multi-tenant environment can be centralised (one authorisation base for all clients), decentralised or hybrid (each tenant is responsible for its own clients in dedicated authorisation bases). For efficient use of access control policies, you can use the authorisation federation service, which is an authorisation broker between the SaaS provider and the client.
