Overview of share management for data stewards


Table of Contents

Key concepts

If you're looking to submit a Data Steward Nomination Request, please use the form linked here.

 

The Share Management System is an eSolutions developed system to delegate the management, maintenance and creation of file shares to elected staff members within a school, faculty or division.

Using the Share Management System, delegated staff members (henceforth referred to as Data Stewards) may manage file shares associated with their area. This empowers Deakin staff members to manage resources and undertake management tasks that have traditionally required the assistance and intervention of eSolutions staff.

This delegation of management to non-eSolutions staff members represents a key paradigm shift in transitioning ownership and responsibility of share resources back to the customer, simplifying the service request process and expediting request-response and action times.

Share drive layout

The Share Management System introduces the fundamental design principle of having a single share for each Faculty, Division, School, Institute or other area in the university.

This design approach allows a simplified top-down, logical approach to share management and reduces the complexity introduced by the fragmentation of related shares over a large number of locations both from a management perspective and as a potential source of confusion and frustration for users.

image

Figure 1.1 - Logical topology of Share Management System design.

Within the root of the divisional share, Share Folders may be created and the access to each folder may be restricted to specified groups or users. By following this design rule, users accessing the faculty or division share will then see all shared folders for their area. However, users will only be permitted to access those Share Folders for which they have been specifically granted access.

Files and directories created within each Share Folder automatically inherit the access restrictions defined on the Share Folder. In this way, each shared folder contains documents and files that are accessible only by those users who have access to each shared folder.

No additional access permissions may be defined on folders or files within a Share Folder. This simplifies the access management process, eliminates the need for complex access topologies and assists in preventing any accidental or inadvertent granting of access to sensitive materials.

To demonstrate, consider a scenario whereby a new employee, John Doe, is a member of a hypothetical user group; faculty-users.

In this scenario, the faculty-users user group contains all members of the faculty. The group is also used to restrict access to a shared folder (Share-1) within the faculty share containing files and documents common to all faculty users (i.e. induction information, superannuation information, request forms).

Being a member of only the faculty-users user group, John's access is restricted solely to the shared folder

Share-1 on the Faculty share, and all files and sub-folders contained within.

Figure 1.2 shows the scope of John's access (highlighted in blue) in the Faculty share.

image

Figure 1.2 - Scope of accessible content for a shared folder.

Note that access to documents and subdirectories within Share 1 is defined only once and at the level of Share 1. John will be able to access all documents and folders underneath Share 1.

For the purposes of demonstration, we now consider the scenario whereby John now requires access to the shared folder Share 2 in the faculty share. Share 2 contains sensitive faculty financial information and details which in John's role as a financial clerk, he requires regular access to.

In this scenario, it makes little sense from an organisational and managerial viewpoint to create a separate folder underneath the common faculty shared folder (Share 1) containing the financial information and attempt to subsequently restrict access to authorised personnel.

Adhering to common security principles, creating a new shared folder at the top level of the faculty share and restricting access only to authorised users reduces the managerial complexity of nested permission models and enforces the grouping of related documents and data.

In the proposed hypothetical situation, access to Share 2 is restricted via membership of the group faculty- finance. After requesting access to Share 2 from the appointed Data Steward for his faculty, John is added as a member to the group faculty-finance and now has access to the shared folder.

Figure 1.3 shows the increased scope of John's access to the Faculty share after he has been added to the group faculty-finance providing him with access to the shared folder Share 2. Note that the increased scope of access is highlighted by red shading, the existing scope of access remains highlighted in blue.

image

Figure 1.3 - Scope of accessible content after being added to the faculty-finance group.

From Figure 1.3 we can see that John now has access to the shared folder Share 2, as well as access to any content within this share.


Containers

Whilst the concept of a shared folder is extensible enough to encompass most situations, particular scenarios may require an additional level of access management or abstraction. For example, in a large division documents and files common to a particular group of employees operating in a particular group and performing a similar role may still require an additional level of separation or access restriction.

For the purposes of demonstration, consider a situation whereby finance staff within a division perform different roles. Some documents and files will still be common to all members of the finance group (i.e. purchase order and requisition forms) however some files may only be used by certain members of the group. If these files also contain sensitive or restricted information, then they will need to be placed in a separate share.

However, from a management and organisational viewpoint, it still makes sense to somehow group together shares common to all finance staff and the restricted share accessible only by certain finance staff. Doing so allows users to infer a semantic relationship from the share structure and also reduces the risk that common documents may be duplicated across numerous shares.

Using the concept of a container, we are able to provide the required level of abstraction whilst still maintaining a simple and logical directory structure.

Conceptually, a container is a directory containing one or more shared folders. However the container itself, unlike a shared folder, cannot be used to restrict access to users. Furthermore, a container may only ever contain shared folders, not files or other containers.

Figure 1.4 shows the logical topology of a container - Container 1 - integrated into our example faculty share.

image

Figure 1.4 - Logical topology of Share Management System Design showing Container object.

From Figure 1.4 we can see that the introduction of a container object appears logically as an additional layer of abstraction at the top level of the faculty share. In our example model, the container object Container 1 contains two Shared Folders (Share 5 and Share 6). The shared folders within Container 1 have the same attributes and properties as the shared folders directly underneath the top level of the Faculty Share.

For a faculty share that has a large number of top-level shared folders, the advantages of using containers are a reduction in the number of top-level shared folders and the logical grouping of shared folders into fewer, generalised containers.

By grouping related shared folders underneath a single container, a structure enforcing a topology where files and folders are organised from general to increasingly specific as the share is traversed is achieved.

Users accessing the faculty share may now infer the location of a required folder or file by first navigating to the top-level container, then to the appropriate shared folder and hence on to the required file or folder.

Figure 1.5 shows the scope of accessible content for a user who has been granted access to Share 6 in Container 1. Note that although the user has access to Container 1 and Share 6, this does not automatically imply that they have access to Share 5.

image

Figure 1.5 - Scope of accessible content using Container object.


Share folders

From our excursion into the workings of the Share Management System thus far, we have seen how shared folders and user groups may be used to restrict access to shared folders, and we have seen how containers may be used to group related shared folders.

However, quite often the requirements of shared folders extend beyond simply restricting access to resources and grouping related files and data. For example, a common requirement of some shared folders is that all users within a faculty or group should be able to read files in a shared folder, however, only a select group of users should be able to write to that folder.

This scenario is commonly seen where a faculty may have a shared folder containing files common to all users within the faculty, however, to restrict any unauthorised modification of files in the shared folder, or the creation of new files in the shared folder, only a trusted group of users should be able to write, modify or create files within the share.

To enable this level of user access and restriction within the Share Management System, a new shared folder is created along with both a read-only user group and a read-write user group.

Building on our previous examples with the user John; on receiving the request from John to establish the Publish Share Folder, the Data Steward for the faculty share creates a new top-level Publish Share Folder Share 5. When creating the share, the Data Steward specifies the faculty user group (faculty-users) as a read-only group.

Then, to allow the finance staff members responsible for maintaining the price list read-write access to the shared folder, the Data Steward specifies the finance user group (finance-users) as a read-write group. If only a small number of users are responsible for maintaining the price list, the Data Steward may choose to specify the staff members individually as having read-write access.

In cases where a large number of users require read-write access to a share, a pre-existing user group may be specified as a read-write group for the share.

Using this security model, we extend the functionality of the Share Management System to provide a method for restricting not only access to resources but also to restrict the allowed actions of users to resources.


Restricted folders

In our overview of the Share Management System thus far, we have seen how Share Folders, Containers and Publish Shared Folders may be used to provide varying levels of access and restriction. We have also seen that the nominated Data Stewards for a faculty are responsible for actioning requests for new Share Folders and maintaining access restrictions.

However, the observant user will note that the concept of a Data Steward introduces a challenging consideration to security design; namely that the Data Steward, having access to modify the access list of a Shared Folder, could hypothetically grant themselves access to a share that they should not have access to.

Although some may consider this an uncomfortable topic of discussion, the reality is that the security and integrity of any system is ultimately a function of those who would maintain it.

Consider a scenario whereby a Shared Folder within a Faculty Share contains Human Resources documentation and staff appraisals. Being of a sensitive nature, when the Share was created, access was restricted to only faculty Human Resources staff members.

In this scenario, our Data Steward is concerned with the outcome of his staff appraisal and without approval, adds himself to the access list for the Share to view his staff appraisal. After viewing his staff appraisal, he then removes himself from the user list, leaving no one wiser of his actions.

The security implications of such a misappropriation of privilege and abuse of trust should be plainly apparent here.

To address this potential abuse of security, a Restricted Shared Folder may be used to prevent unauthorised modification of access by Data Stewards. A Restricted Shared Folder is a type of folder for which access may only be altered by lodging a service request to the eSolutions Systems Unit via the IT Service Desk with explicit written approval from the Head of School, Faculty or Division.

Hence, even though the Share Management System aims to delegate daily operations and management tasks to nominated Data Stewards, the management of access restrictions to Restricted Share Folders is still performed by eSolutions.

This security model of using a trusted third party to undertake approved management of Restricted Share Folder access restrictions provides a secure method of preventing against potential abuse and misuse of the administrative power of Data Stewards to gain access to shares containing sensitive information.

Summary

Reviewing the sections in the introduction and overview section, we have demonstrated how a simple, yet flexible and powerful security model underpins the design of the Share Management System catering to the requirements of share provisioning whilst enforcing a uniform access model and design topology.

In closing, the fundamental design concepts should be enumerated and clarified before proceeding to the Operations section of this manual.

More Information