Information technology tools and resources at the UW
Google Drive and OneDrive for Business access management guidance
Document goal: To provide Nebula clients investigating Google Docs or One Drive for Business for file services some useful background and design principles in formulating an approach to designing access control.
MWS Support for OneDrive for Business or Google Drive
Nebula does not manage access controls on Google Drive or OneDrive for Business, because the design of these services is such that access control should be managed by the customer.
Nebula can provide assistance in formulating a specific access management approach for your department on a consulting basis.
Nebula can also help you migrate files in Nebula file services to one of these locations on a consulting basis.
Background information for access control with Google Drive and OneDrive for Business
You’ll want to review:
- UW OneDrive for Business
- Google Drive
These articles provide some basic background material around these services, how to share within them, and how to use Group Service groups with them. They don’t delve into designing your access control–just the mechanics required to implement access control. You’ll need this information – please read through them first, but they won’t give you specific help designing what you need.
Here are the highlights covered in those locations:
- Not all types of UW Groups can be utilized (Privacy-marked groups cannot be accessed by the needed cloud infrastructure)
- UW Groups used for Google Docs (GD) must be Google-enabled. Conversely, One Drive for Business (OD4B) does not require Exchange-enabling.
- Nested groups can be used to create some efficiencies, but there are some limitations
- A folder in GD is a way to logically separate data to a discrete set that can have a single set of access controls on it. A Subsite is the comparable method to separate OD4B files with access controls.
- Your GD can have links to any number of folders owned by other accounts–like the ‘I drive’ has links to a diverse set of locations.
- The UW Group’s Display Name is what’s used to identify a group in OD4B, while an email address is what’s used to identify a group in GD. What people think of as the group name, is actually the Group ID.
- Some permission settings can allow users to re-share files and that may be unexpected or undesirable. Permissions in both GD and OD4B are self-service, compared to the Nebula servers managed by IT staff.
Background information related to use of the Group Service
There are also some basic Groups Service capabilities you should be familiar with, please review the Group Service documentation. Here are some highlights of that documentation which may be especially relevant:
- Delegation of group management. Someone can be assigned to administer the group, while others can simply manage the members in the group.
- Dependency Groups. Group memberships can be based on another group. A master UW Employees group which is well-maintained can result in automatic removal from your departmental group (aka automation)
- Security – Two-factor authentication can be required for managing designated critical groups.
- – a tool that can be used to apply the same operation to multiple groups. A big time saver.
- Programmable API – there is a programming interface to use software to maintain and work with groups.
Access control guidelines
- Keep in mind that for both GD and OD4B, the files reside in the workspace of an individual identity. ‘DIY’ files created and owned by the UW Department. While the identity will be a UW NetID, you want it to be a Departmental identity, not a personal identity. For example, what will happen to your files when an individual leaves the UW? Using a departmental identity–a Shared UW NetID–provides for a more permanent situation.
- You won’t necessarily have the ‘funnel’ structure that the I: drive has, i.e. less and less access as you go down the folder hierarchy into sub-folders. This has a number of deficiencies, and the freer permissions allowed will require care to implement correctly.
- Always use groups to grant access – grant individual permissions via group membership, not by changing the file sharing permissions, because the associated group in GD and OD4B will also help you determine the purpose of the file share/folder.
- Decide that you will have two different kinds of groups:
- Roles, entitlements, and functions. A group of individual members defined by who they are and what they do. Accounting team, HR folks, etc., with the appropriate naming convention. e.g., uw_pottery_accountants.
- Access to resources. This is the group you would apply to your accounting files with an appropriate name and you would add the accounting members group to that. The name helps define the purpose, e.g. uw_pottery_financialdocuments.
- Assign role groups as members to resource groups, e.g. uw_pottery_accounts is a member of uw_pottery_financialdocuments.
- The I: drive cannot use this nested group architecture, but the advantage is clear: the proper use of nested groups provides its own documentation about the structure and aides in retaining that design.
- This approach allows you to easily give User A the same permissions as User B so she can work on X. The permissions should give a clear indication of what User B has access to. Simply find the relevant resource groups where User B is a nested member.
- Removing a user’s access from the right set of resources simply involves removing them from all the role groups which they should no longer be in. This, in turn, removes all his resource access that flows from those roles. The membership dependency group feature in UW Groups may be very useful for automatically doing this.
- Finally, note that this methodology also enables collaborations across multiple parts of the organization. Anyone with a UW NetID can be added for access to the appropriate role groups needed. Depending on how you define your role groups, you may need to assign multiple role groups to a given resource group, e.g. uw_pottery_otheraccountants may need to also be a member of uw_pottery_financialdocuments.
Practical actions to implement access controls
- Get a Groups Service stem for your groups, e.g. uw_pottery. This is similar to I:\groups\<department> and the resulting top level group that controls that, often with a similar name.
- Decide what the naming convention will be for your role groups vs. your resource groups. Have something in the group id which distinguishes one from the other.
- Decide who will manage your role groups. Decide who will manage your resource groups. Create a group for each of these and use it to assign the administrator role on the respective groups. These staff will become knowledgeable about what files and users they are managing.
- Consider using membership dependency groups like uw_employee, especially on the role groups. If you can’t use membership dependency groups to automatically remove access when it is no longer needed, then come up with an alternative plan like an annual review of group membership.
- Create a regular practice of reviewing group memberships of an individual when their role, entitlement, or affiliation changes.
- Communicate the group naming expectations with your users. This will allow them to know who to go to when they need access to a resource.
- Create the role groups you need. This is likely a discrete, one-time activity, but may require you to think about job functions and roles.
- Create the resource groups you need. This is likely less concrete.
- First, you’ll need to identify what resources you’ll have in these cloud-based services.
- Then create one resource group for each resource. Ideally, the resources aren’t individual files, but sets of files
- Link up the role groups and resource groups. Determine which role groups should be a member of which resource groups.