Access control analysis in WSNs big data system
The purpose of access control is to ensure the security of data. In the WSNs big data system, the access control will perform the access control operation according to the access control policy, access control information, access control decision, and access control implementation information to obtain the access right to the access data when the visitor accesses the data. As shown in Fig. 1, the execution of access control is a complex process. It is executed in the data storage, access, and processing stages in the WSNs big data system.
The data storage structure is the basic concern of access control. It is determined by the characteristics of the data of WSNs. The resources in big data system can be determined by:
$$ r= dmr(datades) $$
(1)
where r is the resource and datades is the characteristics of the data of WSNs.
Big data system gets rights policies by loading rights resources (metadata) into memory. Its formula is as follows:
where r is the resource and arp is the rights policy for access control.
The system can get the rights policy of the user through the user and policy, the formula is as follows:
$$ uap= getUserPolicy\left(u, arp\right) $$
(3)
where uap is the all rights policy of user for access control.
The accessed object, user, and the rights policy to which the user belongs determine the access control policy when a user accesses the WSNs big data system. The formula is as follows:
$$ ucp= getCurAP\left( ao,u, uap\right) $$
(4)
where ao is the accessed object, u is the access user, uap is the all rights policy of user for access control, and ucp is the access related rights policy.
When a user accesses the WSNs big data system, he will be granted to access if the accessed object is in the access rights policy. The logic can be expressed by:
$$ up= getAP\left( ao, ucp\right) $$
(5)
where up is the rights.
The process for users to get rights is as follows:
$$ {\displaystyle \begin{array}{l} up= getAP\left( ao, ucp\right)\\ {}=> upower=\mathrm{getAP}\left(\mathrm{ao}, getCurAP\left( ao,u, uap\right)\right)\\ {}=> upower=\mathrm{getAP}\left(\mathrm{ao}, getCurAP\left( ao,u, getUserPolicy\left(u, arp\right)\right)\right)\\ {}=> upower=\mathrm{getAP}\left(\mathrm{ao}, getCurAP\left( ao, user, getUserPolicy\left(u,f(r)\right)\right)\right)\\ {}=> upower=\mathrm{getAP}\left(\mathrm{ao}, getCurAP\left( ao,u, getUserPolicy\left(u,f\left( dmp\left( data\mathrm{pro}\right)\right)\right)\right)\right)\end{array}} $$
(6)
Problem analysis
As shown in Fig. 1, the access control for big data systems is very complex. So a unified big data security framework is needed to ensure the realization of big data access control. Apache Ranger is a data security management framework for the Hadoop ecosystem. It performs unified data authorization, management, and auditing for the Hadoop ecosystem. Various algorithms and methods for big data security can be easily applied to the Hadoop ecosystem through it [18,19,20,21]. During the development of the Apache Ranger project, we found that after enabling big data security functions in big data systems, the performance of big data systems will be greatly reduced, which will have a great impact on the application of big data systems.
Apache Ranger uses a policy-based model to express the “User-Resource-Rights” logic. It is also a fine-grained security control model that effectively manages data security on the Hadoop platform. The “User-Resource-Rights” logic has the following characteristics:
A user is an object that accesses a resource and belongs to a group or role.
Different components correspond to different business resources.
AllowACL and DenyACL expressed rights. The AllowACL is an access control list that describes the conditions that allowed to access. The DenyACL is a negative access control list that describes the case of denying access.
Definition 1: Access control item (ACI): A collection of visitors (users, user groups, roles) and access types, represented by AccessItem.
$$ AccessItem= List< User/ Group/ Role>+ List< AccessType> $$
(7)
where User/Group/Role is the object which accesses the big data resource; AccessType is the type of access object requires, i.e. access rights.
Definition 2: Allow access control item (ACCI): A control that allows access to big data resources, represented by allow.
Definition 3: Exceptions allow access control items (EAACI): Allow access to exception access items in control items, represented by allowException.
Definition 4: Allow access control list (AACL): Allows the data set of the access control item set plus the exception allowed access control set, represented by AllowACL.
$$ AllowACL= List< AccessItem> allow+ List< AccssItem> allow Exception $$
(8)
Definition 5: Negative controls item (NCI): Control that do not allow access to big data resources, expressed in deny.
Definition 6: Abnormal negative control item (ANCI): Exception accesses in access control entries did not allow, expressed as denyException.
Definition 7: Negative control list (NCL): A data set in the set of negative access control items that excludes the set of abnormal negative control items, represented by DenyACL.
$$ DenyACL= List< AccessItem> deny+ List< AccssItem> deny Exception $$
(9)
Definition 8: Access control policy (ACP): A logical rule for accessing resources by a large data resource access object, consisting of a resource, an allowable control list, and a negative control list, represented by a Policy.
$$ Policy= List< Resource>+ AllowACL+ DenyACL $$
(10)
Definition 9: Access control service (ACS): A collection of access control policies, represented by a service.
Figure 2 shows the current policy-based access control process.
As can be seen from Fig. 2, when a user AU requests access to resources Ares, Apache Ranger obtains all the rights policies of the user related to requested resources. The access right of AU will be determined by the following logic:
If the ARes is in the NACI and not in ANAC, AU cannot access it.
If the ARes is not in ACCI, AU cannot access it when it is in NACI and ANAC.
If the ARes is not in EAACI, AU cannot access it when it is in NACI, ANAC, and ACCI.
If the ARes is in EAACI, AU can access it when it is in NACI, ANAC, and ACCI.
If the ARes is not in ACCI, AU cannot access it when it is not in NACI.
If the ARes is not in EAACI, AU cannot access it when it is not in NACI but in ACCI.
If the ARes is in EAACI, AU can access it when it is not in NACI but in ACCI.
Figure 2 contains the query of the strategy, the analysis of the strategy, and the logical judgment based on the parsed strategy. Its logic can be decomposed to formulas (7)–(10) in the following order:
$$ \left[\begin{array}{l} AccessItem= List< User/ Group/ Role>+ List< Access\ Type>\\ {} DenyACL= List< Access Item> deny+ List< AccssItem> deny Exception\\ {} AllowACL= List< Access Item> allow+ List< AccssItem> allow Exception\\ {} Policy= List< Resource>+ AllowACL+ DenyACL\end{array}\right. $$
(11)
It can be seen from formula (11) that the user can get rights only after a quadruple loop. Since the time complexity of the nested loop is equal to the number of times the innermost statement of the line is executed, the time complexity of the algorithm is T(n) = O(n4). In big data systems, due to the large amount of data and resources being distributed in many different cluster nodes, the time to judge whether an access object has the right to access a certain resource right will be very long. Therefore, the current implementation of access control based on the “user-resource-priv~ ilege” policy will seriously affect the performance of big data systems.
Security access control algorithm based on memory index acceleration
Definition 10: Security access control algorithm based on memory index acceleration (SACABMIA): Using the principle of second-level cache to build keys, establish indexes, and place frequently accessed resources and rights on the memory accelerator through the index. When a user requests access to a resource, system first checks the index. If there are no objects in the index, the index is then extracted and updated from the configuration resource. When the rights resource is changed, the algorithm updates the indexes in the secondary cache synchronously. Figure 3 shows the execution flow of the algorithm.
The key is constructed based on the user, the accessed object, and the type of access. The formula is as follows:
$$ pk= generateKey\left( ao,u, at\right) $$
(12)
where ao is an accessed object, u is the access user, at is the access type, and pk is the constructed key.
The key can be parsed to obtain the accessed object, access user, and access type. The formula is as follows:
$$ \left\langle ao,u, at\right\rangle = analyseKey(pk) $$
(13)
A memory accelerated index is built using the key and the rights obtained when a user accesses a WSN big data system.
$$ indexMap= indexMap\left( pk, up\right) $$
(14)
where pk is the constructed key, up is the rights and indexMap is the memory accelerated index.
The memory accelerated index can be parsed to a list of keys. The formula is as follows:
$$ List< pk>= getAllKeyInMemoryIndex(indexMap) $$
(15)
where pk is the constructed key and indexMap is the memory accelerated index.
The system updates the policies corresponding to all keys in the memory acceleration index when the system policy is changed. The pseudo code for the update algorithm is as follows:
Input: void
Output: void
1. funcation updateIndexMap()
2. arp←f(r) /*Get new rights policies*/
3. uap←getUserPolicy(u, arp) /* Assign policy to users*/
4. listPowerkey ← getAllKeyInMemoryIndex(indexMap) /* Obtain a list of keys */
5. for k to listPowerkey.size
6. pk←listPowerkey.get(k) /*Get ao, user from Powerkey*/
7. <ao, u, at>←analyseKey(pk) /*Get ao, user from Powerkey*/
8. ucp←getCurAP(ao, u, uap) /*Get user's access control policy*/
9. up←getAP(ao, ucp) /* Get access control rights */
10. indexMap←indexMap(pk, up)/* Update the memory acceleration index */
11. end for
12. return
13. end funcation
The process of getting permissions is as follows:
$$ {\displaystyle \begin{array}{l} up= indexMap(pk)\\ {}=\left\{\begin{array}{l} power,\kern0.75em indexMap(pk)\ne null\\ {}\mathrm{getAP}\Big(\mathrm{ao},\mathrm{getAP}\left(\mathrm{ao}, getCurAP\left( ao,u, getUserPolicy\left(u,f\left( dmp\left( data\mathrm{pro}\right)\right)\right)\right)\right), indexMap(pk)= null\end{array}\right.\end{array}} $$
(16)
In a WSNs big data system, user rights policy rarely changes once it is successfully configured [33, 34]. According to formula (16), the index relationship is relatively stable after the memory index is established, which greatly accelerates the efficiency and speed of access control in WSNs big data systems. It can be seen from formula (16) that the system can get rights when it only reads once from the memory index. So, the time complexity of the algorithm is O(n).
As can be seen from Fig. 3, the system builds a key based on User-Resource-Rights and accesses the memory index accelerator when the user accesses resources. If there is a User- Resource-Rights object corresponding to the key in the accelerator, the user will obtain the requested resources. Otherwise, the system obtains rights according to the logic of Fig. 1. The system re-reads the policy resource file, which is in json format, and converts it into a policy resource object when access control strategy is changed. The system also updates the memory index accelerator.
The specific method of building a key is as follows:
After receiving the user’s access request, the system parses the request to obtain the user who visited this time, the resources to be accessed this time, and the rights of this access. Adds the user of this visit, the resources to be accessed this time, and the rights of this visit to get the key.
The main features of the “value” object of the in-memory index accelerator include service information, service definition list, policy details related to the user, resource, and rights status of the current access. The first layer is service information, service definition list, and policy detail list. The service definition includes the name of the service, the basic configuration related to the service, the resource details, the access type, and the policy conditions. The policy details mainly include information about policy-related resources, policy visitor objects, negative policy details, access policies, and the Exception Access Policy details.
