In fact, if role hierarchies are not separated or role privileges are inherited an administrator role could create parties that can be assigned SD administration roles or SD user roles which could bypass security constraints or in case roles inherit privileges, an administrator could act as a SD administrator or SD user and therefore act on classified objects.

As an alternative, a cloud administrator role and cloud SD administrator role may be assigned to one party having SOD applied already to this level. This implies that even a cloud administrator may not perform any action on sensitive objects, not even listing (READ only).

Here below is presented one example of a minimal role hierarchy. Additional roles may extend the hierarchy as long as security principles are complied with.

Example operations that may be considered are Create, Read, Update and Delete (CRUD) operated on objects. This comprises many variations, for instance cloning of data streams should be considered as a “create” type of operation and similarly for other specified operations.

The objects involved may be VL, VNF, VNFC, VNFCI, virtual machine image, VS, vTap, and/or vFEP, whenever they are used to implement a SD function.

A cloud administrator will have permission to create a tenant administrator.

A tenant administrator will have permission to create tenant users in standard data center domain.

A tenant user will have permission to create CRUD objects, except SD protected objects.

And especially, a cloud administrator SD, that is, an administrator in the secure domain of the cloud, will have permission to create a SD tenant administrator, that is, an administrator of a secure domain of a tenant.