Abstract
Enterprise cloud computing provides various services to enterprises, but access to these services is controlled by a firewall. The firewall determines the actions and operations a legitimate user can perform on the available resources. Access control policies allow or restrict access to resources, and they also keep a record of attempted access. In the role-based access control model, access to resources is based on a user’s role in the enterprise. As resources are limited, the policy manager has to create policies that optimize resource availability to different roles to improve overall resource utilization. However, this optimization is challenging without prior knowledge of user behaviour and resource requirements for each role. Due to insufficient knowledge, some resources may be available to the wrong roles, while others may be required by other roles but are inaccessible. This results in decreased resource utilization, requiring the redefinition of access control policies with optimal resource availability. The optimal allocation of resources can be achieved by analyzing user behaviour under different roles. The study proposes a novel method for access control that utilizes role profiling and redefines access control policies for different roles to optimize resource availability. Formal methods are employed to ensure accurate system behaviour in software and hardware systems. Formal specifications provide a high-level representation of system behaviour and characteristics. This paper proposes formal specifications using the “Z” language to ensure accurate system behaviour in access control mechanisms. The proposed mechanism is implemented in a simulated environment and validated using four variants of the recommender approach. The study concludes that the proposed mechanism consistently enhances operational capability, minimizing over- and under-allocation of resources to roles and improving overall resource utilization within the enterprise. The proposed method is beneficial in dynamic environments where the system must adapt to evolving scenarios.
1. Introduction
Enterprise cloud computing offers infrastructure, software, and platform services to an enterprise whose access is controlled by a firewall. Enterprise cloud computing results in better speed and performance of computing resources as well as improved utilization and lower operational and infrastructure costs for an enterprise. Enterprise cloud computing provides a secure computing environment, providing the capability for access control policies, where decisions are based on numerous factors, such as the role of the user defined within the enterprise, the type of data or application being accessed by the user, and the kind of device being used. Enterprise clouds are better than conventional on-premise servers and other storage systems because they are faster, reduce latency, and prevent data loss.
The primary objective of access control is to ensure security. In situations where resources are limited or optimizing their utilization is important, such as in an enterprise cloud environment, access control can be employed to restrict resource access to only those users who genuinely require it. However, this requirement may change over time. Traditional access control models face a challenge in that their policies are static and lack a recommender system to adapt them based on resource usage. This paper introduces a mechanism to tackle this issue. The novelty of this paper lies in proposing the utilization of access control to enhance the overall service of an enterprise cloud, aiming to achieve maximum resource utilization with a minimal number of resources used. Other suggested improvements in access models in literature have not addressed this particular aspect. In the context of present paper, adaptiveness refers to the ability of the access control model to dynamically modify its policies based on the changing requirements of different roles within an enterprise. It recognizes that the access requirements of users may vary over time and aims to provide a flexible and responsive approach to managing resource access.
In the context of the present study, an enterprise has users and resources. The users of the enterprise are intended to use the resources of the enterprise to accomplish their tasks. The resources are not physically and dedicatedly allocated to any of the users. The resources are provided logically to the users based on their needs, specified in their requests, but as per the policies of the enterprise that are defined as access control policies of the resource, depending on the role of the user requesting the resource(s). The resources are available in the form of an enterprise cloud. Roles are assigned to every user depending on their assigned duties and responsibilities. In order to use resources of the cloud, a user has to submit a request to the cloud through the access control policy module. The policy manager of the access control module either accepts or discards the request based on the request submitted by the user and policies defined for the role of the user. The accepted request is forwarded to the cloud for processing. At regular intervals of time, the log entries that encompass the status of the user requests of each role are analyzed, and a number of reports are generated. The requests are analyzed with the intention to define the role profile in terms of resources because of the variation in user requests for resources in every role. The purpose of the analysis is to identify over-availability and under-availability of the resources as per the policies defined by the enterprise for each role. The analysis of log entries regarding the resource request from a user, request, and role perspectives helps in the redefinition of access control policies. The intention behind the redefinition is to increase the overall resource utilization and optimal availability of the resources of the enterprise to their users.
The paper includes a review of access control, its policies, and models in Section 2. This section also contains a review of access control in cloud computing. Section 3 describes the formal specifications in the “Z” language and behaviour of the proposed adaptive access control mechanism. Section 4 provides a performance evaluation of the proposed study using four variants to suggest recommendations and redefinition of policies to avoid any over- and under-utilization of resources at that time. Section 5 concludes the study. The intended audience for the paper is researchers interested in improving the utilization of computing resources of an enterprise cloud by controlling access control policies.
2. Review of Literature
For the present study, we have conducted a thorough review of various papers related to access control in general and specifically for cloud computing. These papers have been selected based on their relevance and significance to our research topic. The review has provided us with a comprehensive understanding of the current state-of-the-art techniques and approaches used for access control in cloud computing. We have also identified the gaps in the existing literature and the research opportunities that can be explored to improve the access control mechanisms in enterprise clouds. The insights gained from this review have been used to develop our proposed adaptive access control mechanism and to evaluate its performance against existing methods.
2.1. Access Control
An important security aspect of an organization is to safeguard its data and resources for unauthorized revelation or modifications [1–3]. Access control covers three functions: authentication, authorization, and accountability [4]. Authentication is the process of verifying the identity of a user who requests access to a resource. This process involves the submission of a user ID and a password or other credentials to prove the user’s identity. Authorization is the process of determining whether a user is allowed to access a specific resource or perform a particular operation on that resource. This process involves comparing the user’s credentials to the access control rules defined for the resource. Accountability is the process of tracking the actions of users who access resources and recording them in a log. This information can be used to trace security breaches or violations of access control policies.
The development of an access control system demands that the rules to control access be defined. It follows a multi-phase process based on the following concepts [1]: Security policy: it defines the (high-level) rules according to which access control must be regulated. Security model: It provides a formal representation of the access control security policy and its functioning. The formalization allows the proof of properties on the security provided by the access control system being designed. Security mechanism: it defines the low-level (software and hardware) functions that implement the control imposed by the policy and formally stated in the model.
In the context of cloud computing, access control plays a crucial role in ensuring the security of the cloud environment. Cloud computing provides a shared computing environment, which means that multiple users and applications share the same physical infrastructure. As a result, the access control policies must be carefully designed and implemented to prevent unauthorized access to sensitive data and resources. Cloud providers typically offer various access control mechanisms and tools that can be used to manage user access to cloud resources.
2.2. Access Control Policies and Models
Access control is a fundamental concept in computer security that refers to the process of selectively restricting access to resources or data within a computing environment. Access control models provide a framework for enforcing access control policies that define who can access what resources and under what conditions.
The initial access control models focused on identity-based access control, where access is granted based on the identity of the user. The initial work in this direction was proposed by Lampson [5]. The proposed model uses the access control matrix as framework for reasoning about the permitted access in the computing environment. In 1973, Bell-LaPadula [6] proposed a model of protection systems that deals with the control of information flow and assigns access permissions to users based on specific rules. Sandhu and Samarati [2] discussed various access control policies, and the authors also suggested the role-based access control to be an appealing substitute to conventional access control. However, as computing environments became more complex, new access control models were proposed to address the limitations of identity-based access control.
The three main categories of access control models [1, 7–9] are discretionary access control (DAC), mandatory access control (MAC), and role-based access control (RBAC). DAC policies allow users to control access to resources based on their discretion. MAC policies, on the other hand, are centrally controlled and enforce mandatory rules for access control. RBAC policies [9] control access based on the roles assigned to users within the system. Hu et al. [3] explained some of the commonly employed access control services offered in IT systems.
RBAC is considered to be the most promising access control policy for complex environments, as it provides a flexible and scalable approach [10] to access control that can be easily customized to meet the specific needs of different organizations.
Among these policies, RBAC is the most promising access control policy for complex environments [11].
Other access control policies have also been proposed, including attribute-based access control [12–14], gateway-based access control [15], and context-aware access control [4, 16, 17]. These policies are designed to address specific access control requirements in different computing environments. The paper [18] is to introduce and delve into the concept of activity-centric access control (ACAC) within smart and connected ecosystems, emphasizing its significance, vision, and research agenda. The study [19] introduces a novel approach to data security using multiple device shadows (digital twins) to separate and restrict access to data points based on assigned tags. The work [20] proposes ReBAC IoT, an attribute-aware relationship-based access control model for smart IoT systems, considering social relationships among users and attributes to enable dynamic and fine-grained access control. The paper [21] focuses on examining the problem of user attribute reachability, specifically considering attributes assigned directly to users as well as those inherited through group memberships. The paper [22] introduces a hybrid RBAC model that combines offline deep reinforcement learning and Bayesian belief networks to dynamically improve the initial RBAC policy while ensuring compliance with system security rules.
2.3. Access Control in Cloud Computing
Neumann [23] gave the insight into the barriers and its fixes to offer a reliable cloud computing environment. Khan [12] presented various access control methods used in cloud computing and highlighted attribute-based access control features required in dynamic environments. Meghanathan [7] reviewed various dynamic access control models to achieve cross-domain authentication. Li and Zhao [24] highlighted the key challenges towards access control in cloud computing environment and the ensuing research directions. Ahmed and Ashraf Hossain [25] presented a study of the cloud computing concepts involving security issues with respect to cloud computing and cloud infrastructure. Majumder et al. [26] discussed the issues and challenges faced in the cloud computing environment. Aluvalu and Muddana [27] presented the analysis of different access control models for cloud computing elucidating the problems faced by these models and their viable solutions. Indu et al. [28] reviewed the challenges concerning authentication, access management, security, and services in cloud environment and proposed the solutions to address these issues. Various existing access control schemes were examined for the security concerns in cloud computing environment [29]. Karataş and Akbulut [30] described numerous access control mechanisms in cloud computing environment for various purposes. El Sibai et al. [31] presented a survey on access control mechanisms for cloud computing.
Cha et al. [32] presented an attribute-based access control (ABAC) model that controls access based on the attributes of requestors, services, resources, and environment. Lin et al. [33] provided a trust-based access control mechanism for cloud computing by incorporating the trust into the cloud environment. Younis et al. [8] proposed an access control model for cloud computing AC3 to meet the identified cloud access control requirements. It ensured the secure sharing of resources, providing diverse access control to the same cloud user, and gave user the capability to utilize various services securely. The researchers suggested different types of access control models for the cloud computing environments [34]. To address the vulnerability in data privacy of cloud users in cloud computing environment, a fine-grained access control mechanism using cryptography was proposed. The paper [35] covers several features of access control mechanisms, including attribute-based encryption, role-based and hierarchical identity management, identity-based authentication, and trust-based models that are suitable for cloud computing environments. A new enhanced authorization approach to access control in cloud was proposed [36]. The study [37] presents an online malware detection system that utilizes process level performance metrics, evaluating the efficacy of various baseline machine learning models. A smart healthcare cloud using smart contract access control [38] was introduced. A role-based access control for cloud storage [39] was proposed. The paper [40] evaluates and analyzes access control mechanisms in cloud computing based on centralized and decentralized models and presents a comparison of each model’s advantages and limitations and discusses the challenges associated with access control in the cloud.
Overall, the studies mentioned focus on the challenges and solutions related to access control in cloud computing environments. These challenges include issues with authentication, access management, security, and privacy. Various access control models are discussed such as attribute-based access control (ABAC) [41], trust-based access control, and fine-grained access control using cryptography. The studies highlight the importance of developing reliable and effective access control mechanisms to ensure the reliable sharing of resources and services in cloud computing environments.
3. Design of the Adaptive Access Control Mechanism
The mechanism presented in the paper introduces a fresh approach to access control mechanisms that can enhance the efficient utilization of cloud resources. This approach involves utilizing role profiling and adjusting access control policies for different roles to optimize the availability of cloud resources while maintaining security. The mechanism is especially beneficial in scenarios where access control policies can also be leveraged to enhance resource utilization, leading to better overall efficiency. By implementing this mechanism, enterprises can streamline their resource allocation processes, improve the response time to requests, and ensure optimal utilization of their cloud resources, thereby improving operational efficiency and reducing costs. The implementation cost of the proposed approach involves efforts in creating and maintaining log files to capture user requests, analyzing the log file contents using a recommender algorithm, and making access control decisions based on the recommendations generated. It includes resources for developing and managing the log files, designing and training the recommender algorithm, integrating it into the system, and implementing decision-making logic. Additionally, integration, deployment, maintenance, monitoring, training, and documentation efforts are also necessary.
3.1. Requirements of the Mechanism
The basic requirements of the stated mechanism are as follows:(i)A user is identified by a unique ID and designation(ii)A user may have additional charges(iii)Every user has at least one role(iv)Designation and additional charges may map to different roles(v)There are a number of users with same role(vi)Each role has the availability of subset of the available resources(vii)Available resources are allocated among the various roles in a controlled manner(viii)A user may have a number of requests(ix)A request is identified by the unique ID and the information related to the owner of the request(x)A request belongs to single user under one role(xi)A request is either accepted or discarded on the basis of the defined policies(xii)Policies are defined in terms of instances available for a given resource for every role
3.2. Features of the Mechanism
The proposed access control mechanism introduces several additional features to the traditional RBAC model to enhance its capabilities in improving resource utilization in dynamic environments.
Firstly, the mechanism is designed to be dynamic and adaptable to changing operational scenarios. This means that the access control policies can be redefined at regular intervals to optimize resource allocation based on changing demand and availability.
Secondly, the mechanism allows a user to have multiple roles, but the applicable policies are determined by the role requested. The user has one designated role, while additional roles may be assigned with additional charges. This enables more flexible resource allocation based on the specific needs of each role.
Thirdly, the mechanism supports requests for multiple resources with multiple instances in a single request. The access policy includes limits on the number of instances for each allowed resource, as well as a limit on the number of instances for each role. This ensures that resources are allocated optimally and efficiently, while also preventing over-allocation and under-utilization of resources.
Finally, the mechanism provides results that aid in decision making about the addition, deletion, and redistribution of resources among roles to optimize utilization at a lower cost. The mechanism generates reports that can be used to identify over- and under-utilized resources and to identify trends in resource usage, enabling enterprises to make informed decisions about resource allocation.
In summary, the proposed access control mechanism introduces new features that allow for more efficient resource allocation in dynamic environments, ultimately leading to optimized resource utilization. The mechanism achieves this by allowing for dynamic adaptation to changing operational scenarios, allowing users to have multiple roles and requesting multiple resources with multiple instances in a single request, and aiding in the decision-making process for resource allocation. The overall result is increased resource availability with fewer resources, all while maintaining security.
3.3. Formal Specifications and Behaviour of the AACM
Formal methods [42, 43] are procedures based on mathematical models for the design of software and hardware systems. Unlike other design systems, formal methods use mathematical proof as a complement to system testing to ensure correct behaviour. The strength of formal methods lies in their ability to verify the entire state space of the system, and the properties that can be proved to hold in the system will hold for all possible inputs.
Formal specifications provide a concise description of the high-level behaviour and properties of a system. These specifications can be model-oriented by constructing a model of the system behaviour using mathematical objects such as sets and sequences. Alternatively, they can use a set of necessary properties to describe system behaviour, such as axioms and rules. Formal specifications provide several benefits, including(i)Higher level of rigor: Formal specifications offer a higher level of rigor, which leads to better problem understanding. This helps ensure that the system meets its requirements and specifications.(ii)Uncovering defects: Formal specifications help uncover defects that may be missed when using traditional specification methods. By using a formal notation, it becomes easier to identify problems and inconsistencies in the system design.(iii)Early defect detection: Formal specifications allow for early defect detection, which can save time and reduce costs. By detecting defects early in the development process, it is easier to fix them before they become major problems.(iv)Self-consistency: The semantics of formal specification languages allow for verification of self-consistency. This means that the specification itself can be checked for consistency, which helps ensure that the system will behave as intended.(v)Formal proofs: Formal specifications facilitate the use of formal proofs to establish fundamental system properties and invariants. This can help ensure that the system meets its requirements and specifications.
Overall, formal specifications provide several benefits that can help ensure the correctness and reliability of software and hardware systems.
Many formal notations have been developed for writing formal specifications.
The B method [44] is a method of software development based on B, a tool-supported formal method based on an abstract machine notation, used in the development of computer software. It was originally developed by Jean-Raymond Abrial. B is related to the Z notation.
VDM [45] was developed at the IBM laboratories in Vienna. The current version of the VDM specification language, VDM-SL, has been standardized by the International Standards Organization (ISO). It supports the modelling and analysis of software systems at different levels of abstraction. Using VDM-SL constructs, both data and algorithmic abstractions expressed in one level can be refined to a lower level to derive a concrete model that is closer to the final implementation of the system.
Z is a formal specification language [46] based on Zermelo set theory. It was developed at the Programming Research Group at Oxford University in the early 1980s and became an ISO standard in 2002. Z specifications are mathematical and employ a classical two-valued logic. The use of mathematics ensures precision and allows inconsistencies and gaps in the specification to be identified. Theorem provers may be employed to demonstrate that the software implementation meets its specification [47].
Z has been used to underpin a model of RBAC [48]. The Z specification is created for the commercial application of online food ordering system to improve the order detail accuracy and efficiency [49]. Z specification language is used to design the e-commerce system and specify security constraints [50]. A scanner and parser for Z specifications [51] was introduced.
Other formal specification languages include(i)CSP (communicating sequential processes) [52]: a formal language for describing patterns of interaction in concurrent systems.(ii)TLA+ (temporal logic of actions): a language for specifying and verifying concurrent and distributed systems, developed by Leslie Lamport.(iii)Alloy [53]: a lightweight specification language and analyzer for software modelling and analysis, developed at MIT.
Each of these languages [54] has its own strengths and weaknesses, and the choice of language depends on the specific requirements and constraints of the system being modelled.
3.3.1. Formal Specifications
In the study, the specification pattern is utilized to define the formal specifications of the proposed mechanism. This pattern involves employing the syntax and semantics of the Z language to capture the desired behaviour and properties of the system or process being modelled.
The enterprise is defined as E = {USERS, RESOURCE} where USERS is the set of users and RESOURCES is the set of available computing resources. So, USERS = {u1, u2, u3, …, un} is a finite set of users where each user is identified by a set of attributes. The USER_ID is to uniquely identify the user, USER_DESIG is attributed to designation of the user, a finite set of ROLES is assigned to user on the basis of their designation and additional charges assigned, ADDL_CHARGE is a finite set of additional charges held by the user, and ALLOCATED_RESOURCES is a finite set of tuples of resource and the number of instances of that resource allocated to the user at a given instant for each of the assigned role.
RESOURCES = {res1, res2, res3, …, resn} is a finite set of resources. Each resource has one or more instances of each resource.
ROLES = {r1, r2, r3, …, rn} is a finite set of roles that are assigned to users.
The statement of the problem is to find the optimized mapping of the members of the RESOURCES set, as resources, to members of the ROLES set. The optimization is with the intention to enhance the resource utilization. Role profiling is used for it. The formal specifications for the USERS, RESOURCES, and ROLES are given in Figure 1.
The specifications for various operations on USER set like to add new user and delete an existing one are shown in Figure 2. In order to add a new user, user designation and additional charges (if any) are provided as input. The USER_ID is automatically generated by using a global variable USER_COUNT.
The specifications for mapping User_Desig to ROLES and Addl_Charges to ROLES are shown in Figure 3 along with the operations for adding and deleting a role for a given designation or charge and updating an existing mapping from designation to role or charge to role.
The roles are assigned to users based on their designation and additional charges (if any) held by them. This mapping is shown by the specifications shown in Figure 4.
The specifications of the queries that can be asked on the basis of role assignment like to find the roles for a given designation/charge or vice versa are shown in Figure 5.
The policy database as shown in Figure 6 consists of set of policies where each policy is characterized by a tuple of ROLES and RESOURCE_ALLOWED. Here, RESOURCE_ALLOWED itself is a tuple of RESOURCE and INSTANCES indicating the instances of each resource allowed to a particular role.
The specifications to manage the policy database are given in Figure 7.
The specification regarding the request for the resources is specified in Figure 8.
There are some declarations that are required for further operations. The motive behind creating these declarations is to create a log set as specified in Figure 9. Here, each log entry is attributed by the identity of the user, the role among the possible roles assigned to that user, and a unique identity of the request. In addition, the status of the request that is initially waiting and completed on successful completion of that request and a set to indicate the status of each requested resources are also recorded. The purpose of the log entries is for further analysis of the requests by the user for optimizing the usage of the resources. LOG is used to record data on day-to-day basis. For analysis on data for more days, MONTH_LOG is maintained. It has the same members as LOG. It appends the daily entries of LOG to it.
The specification regarding the limit on number of users and the number of current users for each role is shown in Figure 10. Here, the limit indicates the maximum allowed users for a given role and current users indicate the number of users for a given role at a given instance of time.
With an aim to characterize the role, a log that encapsulate the details regarding every resource with the number of instances currently allocated, number of times the limit of permissible instances gets exceeded for the given request, and an entry to record the number of moments the requested resource is not available for a given role is specified as shown in Figure 11, . The availability grade is also assigned as per the values in other attributes of the log.
The specifications of the module that makes a decision either to accept or discard the submitted request on the basis of the policies defined as per the credentials of the request, i.e., role of the user in the present context, are defined in Figure 12. The requested resources with their instances are compared to the resources allowed for a given role. The currently allocated resources are also considered for comparison purposes. If the requested resources and the required instances satisfy the criteria specified in the policy, the user request is marked as accepted. Otherwise, the request is graded as discarded. Furthermore, the status of each requested resource is graded as ALLOW, BEYOND_LIMIT, and UNAVAILABLE depending upon the requested resource and specified policies.
The request that is accepted by the access control module is forwarded to the cloud for further processing. The status of the request is changed to processing. The resources available in cloud serve the incoming request. The specifications of the above said functionality are shown in Figure 13.
On the completion of the service to the request, the request status is changed to completed. Furthermore, the values in allocated resources in the user profile are also modified, and it reflects that the resources of the cloud are not more with the user of the request. The specifications are shown in Figure 14.
The specification to query the log for a given role and to query the log for a given user is shown in Figure 15. These types of queries are helpful in the analysis of the requests from the role and from the user perspectives.
The role log is modified by querying the log for requests. The specification of the said module is shown in Figure 16. This modification is an important step as on its basis further recommendations take place for optimizing the availability of resources among the various roles.
On the basis of it, resource availability of each resource for a role is graded. The grade is OVER, NORMAL, or UNDER. The resource is graded as NORMAL, if that resource is in the requests of the users of that role. It is graded as UNDER, if the resource is in the requests of the users of role under observation but it is not available as per the present policy of that role. Resource is with grade OVER, if it is in the policy of the role but it was never requested by the users of that role. The specifications for the same are shown in Figure 17. The stated figure shows the specifications of the module for the creation of OVER_ALLOC, NORM_ALLOC, and UNDER_ALLOC sets of resources for each role by analysis of the MONTH_LOG. The specifications of grading resources using these sets are also shown in this figure.
ROLE_RESOURCE_CLUSTER is created to make the clusters of the resources for each role appear in the requests of the users of that role. Here the clusters may overlap, i.e., a resource can be a member of more than one cluster. The module uses the MONTH_LOG to find out the clusters of resources for every role. The specifications of this module are shown in Figure 18.
The specifications of the module to find the weights of every resource in each role are shown in Figures 19 and 20. This module is to take into account the probability of the requests of every resource in each role and the probability of every role having that resource in their requests. Figure 19 shows the specifications of types used in Figure 20.
Figure 20 shows the specification to find ROLE_RES_PROB and RES_ROLE_PROB and then to find the weight of each resource in every role using these probabilities.
The specifications to find the appearance of each resource in the requests for every role in terms of percentage to the total number of requests for that resource in all roles are shown in Figure 21.
(1) Recommenders. The recommender system is responsible for providing recommendations to adjust the access control policies for resources and the number of instances allowed for each role. These recommendations are based on the data collected and organized during the operation of computing services offered by the cloud, to serve the requests made by the users of the cloud. Requests that comply with the access control policies are forwarded to the cloud, while those that do not comply are rejected. The current study proposes four approaches for making these recommendations, and their performance is shown in the next section.
The specifications to provide recommendation and to adapt the policy with the suggested recommendations using grading of the resources are shown in Figure 22. This recommender uses RESOURCE_GRADING_SET that is defined in earlier specifications.
ROLE_RESOURCE_CLUSTER, which is defined above, is used by the module to suggest recommendations and to adapt the policy. The specifications for this module are shown in Figure 23.
The weight of the resource in a role is used to decide either to recommend or reject a resource for every role. This approach is useful where the policy is only adapted to resources in every role where its weight is equal to or more than the threshold weight which is decided by the policy manger. The specifications of this recommender module are shown in Figure 24. The threshold input is input to this module.
In order to adapt the policy with only those resources that appear more frequently in the requests, the percentage recommender is proposed. In this module, the frequency is determined in the form of percentage, a resource requested in a role to the total number of requests with that resource in all roles. The specification is shown in Figure 25. In this module, the percentage threshold is input parameter.
3.3.2. Behaviour of the AACM
A finite state machine to specify the behaviour of the request in terms of its states and the action(s) to change the state is shown in Figure 26.
The state transition diagram of the request is shown in Figure 27.
The state transition table of the request object is shown in Table 1.
The states and action for querying policy and updating it as a finite state machine are shown in Figure 28.
The state transition diagram of the policy database is shown in Figure 29.
The state transition table for policy database is shown in Table 2.
4. Implementation
Using a simulator to generate data and validate the study is a common approach in computer science research, particularly in the field of cloud computing. Simulators are used to create a realistic environment for testing and evaluation, allowing researchers to analyze the performance of proposed mechanisms under various conditions without the need for expensive physical infrastructure. By using a simulator, researchers can generate large amounts of data in a controlled environment and use statistical analysis to draw conclusions about the effectiveness of the proposed mechanism. This can help researchers to identify potential issues and optimize the mechanism before it is implemented in a real-world setting. The proposed mechanism is implemented in a simulated environment to show its effectiveness. The next subsection presents the simulation and the outcomes. The other subsection validates the simulation mechanism.
4.1. Simulation Model and Performance
The simulation model used in the study is presented in Figure 30. The model generates users, roles, and resources based on user inputs. Roles and resources are also generated with the given number as input. For the generated set of roles, a mapping is generated to map designation and charge to role with role assignment. For the given roles and resources, initially a policy is generated. Requests are generated by users and processed by the policy enforcement module, which logs each request in a log file. The log file is then used to create ResourceLog and RoleLog files, which are used as inputs for the proposed recommender algorithms. The recommendations are fed to the policy management module (PEM), which adapts the policies based on the recommendations. In the simulation, the same set of users, roles, and resources is used with different sets of requests to evaluate the impact of the recommendations on the system’s performance. The next subsection presents the simulation outcomes, while the other subsection validates the simulation model.
A simulation study has been conducted to showcase the effectiveness of the proposed formal specifications, and various simulation parameters have been varied to observe their impact on the performance of the suggested mechanism. The simulation parameters are presented in Table 3.
Conventional RBAC is static in nature. An enterprise cloud is intended for an enterprise. The goal of an enterprise is to have the optimal availability of its resources to their users for maximal utilization of its resources with minimal availability. However, the subjective approach used in defining access control policies in traditional RBAC may have an impact on resource utilization. This effect is illustrated in Figure 31, where resources allowed for each role are categorized as normal, over, or under. A resource is considered normal if it appears in the user’s request, over if it is never requested by the role’s user, and under if it is in the requests but not available to users according to the defined policy. The figure displays the resource usage for one simulation scenario, showing that some resources are available for roles but are not requested, while others may be required by requests where they are not available.
So, the need for the present study arises. The present study suggests recommendations for revising the policies by extracting the role profile from the requests made by the users under each role. The role profile entails several aspects related to resource management within a specific role. The role profile identifies and lists the resources that are accessible and available to users assigned to that particular role. It also includes a record of the resources that users belonging to that role commonly request or require for their tasks or responsibilities. The role profile specifies the current availability status of the resources for users assigned to that role. Conversely, the role profile also notes any resources that are unavailable or restricted for users in that role.
The application of the proposed recommendations yields a scenario shown in Figure 32 with maximum availability of resources to each role and that too with the same set of resources. A confusion matrix has been generated for each outcome of the simulation. The description of the entries of the matrix is as follows: True positive: the number of resources required by the users of role is available in defined policy True negative: the number of resources not required by the users of role is not available in defined policy False positive: the number of resources not required by the users of role is available in defined policy False negative: the number of resources required by the users of role is not available in defined policy
The performance of the suggested approach has been evaluated on the bases of the following performance metrics presented in Table 4.
The simulation study uses four approaches to validate the outcome of suggested study. These approaches are intended to build the role profile by mining the requests made by the users of that role and then propose recommendation on these bases. The brief idea of each approach is as follows: Clustering approach: This approach is to make clusters of only those resources that are requested by the users for each role. A snapshot of sample output is shown in Figure 33. Grading approach: The resources are graded as over, normal, and under for each role. The suggested recommendations are to keep resources with grade normal, remove resources with grade over, and add the resources with grade under. A sample output is shown in Figure 34. Weight approach: The weights are assigned to each resource for every role. The weights are calculated on the basis of the probability of the role having a resource in their requests and the probability of resource request made by the role. Both of these probabilities are multiplied to get the weight. These weights are normalized in the range of 0 to 1. These weights are sorted in decreasing order for each role. The sorted list gives the recommendations of the resources in the order of their weights. A sample output is shown in Figure 35. Percentage approach: The percentage is determined individually for each resource within each role by comparing the number of times the resource was requested to the total number of requests made by the users in that role. The calculated percentage is used for recommendation of the resources in the policy for every role. A sample output is shown in Figure 36.
Each approach is evaluated based on performance metrics. The first performance metric is the acceptance ratio of requests by the access control. Figure 37 shows the results before and after the adaptation of policies as per the recommendations. The figure demonstrates the results for every combination of simulation parameters, including the number of users, number of roles, and number of requests per day. It is observed from the figure that the acceptance ratio tremendously increases in all approaches. The performance of clustering and grading is comparable, while the outcome of the weight and percentage approaches is less. The reason for this is that in clustering and grading, all recommendations are adapted into policies, while restrictions are imposed on the weight and percentage approaches. The intention is to show the variant with and without restrictions.
(a)
(b)
(c)
(d)
To study the effect of the number of users on the results of the performance metrics, the proposed mechanism was simulated with 50, 200, 1000, and 5000 users, and the outputs are shown in Table 5. The values in the table reveal that the metric values increase with the increase in the number of users, but only to some extent. The main observation is that the mechanism consistently performs much better in all cases after adapting policies to the current behaviour of the users in terms of their requests.
The visual representation of the outputs of the abovementioned explanation is shown in Figure 38. The bars representing the performance have large values for the metrics after adapting the policies with the suggested recommendations. Therefore, it can be concluded that the proposed mechanism performs well irrespective of the number of users.
(a)
(b)
(c)
(d)
The roles are very important as they determine the classes to which the resources are assigned. To investigate their effect on the performance metrics, a simulation study with 20, 35, and 50 possible roles was performed. The values for different numbers of roles are tabulated in Table 6. It is evident from the table that the proposed mechanism achieves better performance for all values of roles and in all approaches studied.
The outcomes in graphical form are shown in Figure 39. It can be observed from the representation that the values decrease in trend with the increase in roles. This is because with the increase in the number of roles, the number of classes also increases, and this increase has an effect on the value. However, even with the decreasing trend, the values are always better than before the adaptation of policies.
(a)
(b)
(c)
(d)
To investigate the effect of the number of requests on the outcomes of the proposed mechanism, a simulation study with 10, 100, and 1000 requests per day was conducted. The results are presented in Table 7, which shows that the proposed mechanism improves the metrics in all cases and in every approach. The increase in the number of requests leads to an increase in the values of the metrics, as expected. However, the improvement in performance is significant, indicating that the proposed mechanism is effective in handling large numbers of requests while maintaining high levels of security and resource availability.
The effects of the variation in the number of requests on the outcomes are visualized in Figure 40. It is observed that a smaller number of requests have a slightly lower improvement in performance, and it increases with an increase in the number of requests, but the performance improvement is very small after an increase in the number of requests. In the present simulation study, with 10 requests, the enhancement is less compared to 100 requests per day. Another increase to 1000 has no significant improvement compared to 100 requests.
(a)
(b)
(c)
(d)
4.2. Verification and Validation of Simulation Model
Model validation aims to verify that the model is actually performing satisfactorily in its application area. In this case, the model was developed to demonstrate a recommender system for adapting access control policies to prevent over-allocation and under-allocation of resources. The outcomes of the trials and evaluations conducted during the model development phases were validated and verified to ensure that the model’s performance meets the expected level of satisfaction. The following techniques are used for validation: Degeneracy tests: to prove the degeneracy of the behaviour of model, it is tested with various combination of number of users, number of roles, and number of requests. Event validity: acceptance or rejection of requests by policy enforcement module and revision of the policies are some of the events that happen in the model, and the occurrence of such events is similar to the real system. Extreme condition tests: the conditions like no request generated by a role, request of more than permissible instances of an allowed resource, and having multiple roles are considered and the handling mechanism is implemented. Internal validity and parameter variability: a number of simulations for the same set of users, roles, and resources but different set of requests that are of the same number as in other simulation show the consistent behaviour. Operational graphics: the dynamism in the values of performance indicators is visualized to confirm the correctness of the mechanism. Predictive validation: The mechanism is to suggest the recommendations by forecasting the behaviours of users in every role. The improvement in acceptance and other performance metrics validates the predictive ability of the model. Traces: The outcomes of various kinds of internal processing are recorded and used for further processing in the generation of recommendations. The acceptance ratio and confusion matrix entries are some of the traces used in the proposed system.
So, on the bases of these techniques, the simulation model is operationally validated.
To elaborate further, the mechanism presented in the paper involves regularly analyzing the log entries that encompass the status of user requests for computing resources in the enterprise cloud. The analysis is done to identify over- and under-utilization of resources as per the policies defined by the enterprise for each user role. Based on the analysis, the access control policies are redefined to optimize the utilization of resources and improve the acceptance rate of requests. By optimizing the utilization of computing resources, the proposed mechanism helps to reduce over-allocation and under-allocation of resources to different roles within the enterprise, which can result in improved speed, performance, and utilization of computing resources. Additionally, the mechanism can provide insights into which resources are no longer needed or not frequently used, allowing for more efficient management of resources in the enterprise cloud. Overall, the proposed mechanism is valuable in dynamic environments where the demand for computing resources can fluctuate rapidly. By regularly analyzing and redefining access control policies, the mechanism enables the enterprise to adapt to changing scenarios and ensure that computing resources are allocated efficiently and effectively to different user roles. This can ultimately result in improved operational capabilities and lower costs for the enterprise.
5. Conclusion
In this paper, the authors propose a mechanism designed to improve the utilization of computing resources in an enterprise by regularly redefining access control policies. The mechanism is particularly valuable in dynamic environments where the system must adapt to changing scenarios. The authors explain that in traditional enterprise systems, computing resources are physically and dedicatedly allocated to specific users or roles. However, in an enterprise cloud computing environment, resources are not allocated in this way. Instead, resources are provided logically to users based on their needs, as specified in their requests, but are subject to access control policies defined by the enterprise. These policies determine which users have access to which resources based on factors such as the role of the user, the type of data or application being accessed, and the kind of device being used.
The proposed mechanism is designed to analyze log entries that encompass the status of user requests for each role in order to identify over- and under-availability of resources as per the access control policies defined by the enterprise. This analysis is intended to lead to the redefinition of access control policies in order to increase overall resource utilization and optimal availability of resources to enterprise users. The mechanism is described in detail, including a state transition diagram and table that depict its behaviour. The authors explain that the mechanism enhances operational capabilities by reducing over-allocation and under-allocation of resources to roles. The reports generated by the mechanism can also aid in decision making about the need for additional instances of resources and identify resources that are no longer needed or not frequently used.
Overall, the proposed mechanism is intended to improve the utilization of computing resources in an enterprise by dynamically redefining access control policies based on user requests and role profiles. By increasing the availability of resources to users and roles that need them and reducing over-allocation and under-allocation, the mechanism is expected to lead to improved operational capabilities with less number of resources and increased overall resource utilization.
Data Availability
The results presented in this study are based on simulations. The underlying data used to support the findings of this study are available from the corresponding author upon request.
Conflicts of Interest
The authors declare that they have no conflicts of interest.