**2.5 The proposed SoD deployment in IaaS by ABACsh**

Based on the above investigation [22–24, 29], SoD can be defined as an enforcement constraint configured to avoid conflict between policies. This conflict can be due to multi-access requests from different subjects to the same resource simultaneously, or the same subject requesting access to multiple resources at the same time. From this definition, it can be observed that SoD may be viewed as object-operation-oriented, which can be aligned with ABAC's relation between appropriate to enhance SoD by implementing a form of HSoD which will be suitable to be enforced in a dynamic access control policy environment such as ABAC. With RBAC, the centric entity involved in the SoD principle design is the role set. In contrast, ABAC cannot consider a role in the form of an attribute as it can lead to a chaos [30]. Therefore, the focus of this paper regarding formally defining SoD within ABAC will be on attributes and attribute-relations, with no aim to define an application-oriented SoD. Thus, we aim to identify a logical based design for SoD within the ABAC policy model. The proposed work is based on formal logic; exception cases are not encouraged in a formal logic as exceptions make regulations non-monotonic and introduce conflict between proven conclusions [31].

Therefore, the proposed SoD is operation-object orientated that defines a rulesset reflecting the forbidden operations on the set of objects under a specific situation of a collection of entities attributes. Entities include the object, the subject, the environment, and the system context. Moreover, formal logic facilitates SoD rule creation, even by non-expert security administrators. Since the proposed system is attribute-based, it is not necessary to update different locations if a new action restriction is added, deleted, or modified. Object-attributes and operations. We can discern from the above that it is more appropriate to enhance SoD by implementing a form of HSoD which will be suitable to be enforced in a dynamic access control policy environment such as ABAC. With RBAC, the centric entity involved in the SoD principle design is the role set. In contrast, ABAC cannot consider a role in the form of an attribute as it can lead to a chaos [30]. Therefore, the focus of this paper regarding formally defining SoD within ABAC will be on attributes and attribute-relations, with no aim to define an application-oriented SoD. Thus, we aim to identify a logical based design for SoD within the ABAC policy model. The proposed work is based on formal logic; exception cases are not encouraged in a formal logic as exceptions make regulations non-monotonic and introduce conflict between proven conclusions [31]. Therefore, the proposed SoD is operation-object orientated that defines a rules-set rejecting the forbidden operations on the set of objects under a specific situation of a collection of entities attributes. Entities include the object, the subject, the environment, and the system context. Moreover, formal logic facilitates SoD rule creation, even by non-expert security administrators. Since the proposed system is attribute-based, it is not necessary to update different locations if a new action restriction is added, deleted, or modified.
