So you have your data in place and also the users and groups. There is however a very important part that needs your attention before letting your users loose on the new platform. Which parts of your dataset should be granted access to who?
Cloud platforms treat their permission structure differently. Some focus on shared links to allow users to collaborate, others may introduce permission levels, or user roles. Those levels can be anything between the most complicated approach, like NTFS permissions, which allow the most granular approach (read more) and a service like Egnyte, which allows for “only” four levels of permissions, solely applied on folder level. Beware, many a time, the simpler permissions are much more grounded, secure, and maintainable. They impose permission hygiene and data structure consideration.
Some of our customers decide to take the opportunity and reevaluate their permission structure, or maybe they have never considered the permissions in the first place, as every employee had access to all the data. Regardless, if you decide to apply permissions manually, here are some best practices:
Favour group based permissions rather than individually assigned ones. It will be more scalable and easier to maintain if you only need to add or remove someone from some groups (preferably via an integration with an IDP) than going through every folder and file to give a new employee access or remove access from someone switching teams or leaving.
Keep your permissions simple. Consider keeping the permission structure as simple as possible. Keep in mind that you may restructure your data around rather than granulate your permissions. Consider this scenario: You have a folder for each customer. The folder may contain a subfolder accessible only to the sales people and managers. Let’s call the folder “Legal”. Instead of having a “Legal” folder within each customer folder, you may want to create a single “Legal” folder at a higher level and create customer folders within that. That way you do not need to break the permission inheritance and maintain a separate permission set within every customer folder. Consider this example:
Worse Folder Structure
Better Folder Structure
3x4=12 permission sets to maintain
4 permission sets to maintain
Designate data owners. Delegate as much as you can. Assuming there are team managers and or department directors, they should be in charge of assigning permissions. Again, keeping in mind point 1 and 2, allow them to manage groups rather than assign permissions individually. Do the groups not work for their particular workflow or use case? That’s OK, create new ones, restructure your data, add more groups to the permission set of a folder. There is almost always a way of compromising between delegation of ownership and enforcing best practices. My advice, make team leaders group owners. That way they can manage access without compromising you tidy beautiful permission structure.
Learn how to use reports. Many cloud collaboration platforms allow you to create and even schedule recurring generation of permission reports or even permission audit reports (detailing only changes). That way you can make it a habit to revisit the permission structure regularly and avoid any unwanted data leaks. For local NTFS permissions, you may want to check out NTFS Permissions Reporter.
Use automatic risk assessment tools. There are tools that can analyse your permission structure and alert you to any risky situations. They will also analyse the content of your data in search for any sensitive or personal information that may be exposed to more audience than intended. Egnyte has Secure and Govern that does that and much more for you, IBM has Guardium.
Train your users. Most cloud collaboration platforms have a ton of fancy collaboration features. Shared links, public links, internal sharing. The more your users know the better for your company and security.
Make use of folder templates. You can create a template folder having the right group based permissions set. This folder can then be copied wherever needed and will allow for the right access without further effort. Investigate templating options of your cloud provider.
Automatic Permissions Migration
Suppose you’re perfectly satisfied with the way your permissions are at the moment. Switching to another Cloud Collaboration provider may impose unnecessary additional work, as most do not allow for easy permissions migration.
Translating between permission levels of different data repositories is a challenge in itself. Most of the time they do not align perfectly, so there is almost always a tradeoff. There may also be a difference between how permissions are inherited by child objects (sub folder and files). Some Clouds may not allow for inheritance breaks. Lets compare some permission structures:
Additionally, there are more advanced permission settings available for site administrators or users with the appropriate permissions:
"Can edit" (Read & Write) and "Can view" (Read-only)
Same as on folder level: "Viewer" (Read-only), "Commenter", and "Editor" (Read & Write)
In Egnyte, you can set permissions at the folder level, but not directly at the individual file level. When you grant permissions to a folder, the files within that folder inherit the folder's permissions by default. However, you can share individual files using secure links with specific access levels and expiration dates.
To clarify, in Egnyte, you can share individual files but cannot assign file-level permissions in the same way you do for folders. Sharing files using secure links provides an alternative method for controlling access to specific files.
When sharing a file, you can generate a shared link with different access levels (open, company, collaborators) or directly invite collaborators with either "Editor" (Read & Write) or "Viewer" (Read-only) permissions.
You can choose between "Can edit" (Read & Write) and "Can view" (Read-only) permissions for the recipients. However, when using link-based sharing, it will provide view-only access.
All Folder level permissions can be applied to individual files as well.
As you can see translating from one data repo to another can be daunting, and there are very few automatic solutions out there. Mygreat.cloud aims to change that. We create inhouse curated script that prepare a permission’s report that you can then apply using the mygreat.cloud platform. You can also change the permission translation mapping should you so choose.