💻/🖥️ Manage Sensitive Files in the Cloud with a Team

Last updated on : 2021-09-12

Instructions

What you should know

• One of the downsides and challenges of using Cryptomator with a team is that there is no way to directly share specific files with your team. Since the clear documents themselves aren't stored in the cloud, you can't simply share a link to the cloud drive location, or attach it to your email like you normally would. You can still share folders with your team, and thus share the encrypted vaults inside of those folders, but this is merely an indirect way of sharing. Even if files are synchronised and available on both your computers i.e. you still need to tell someone which file to look at, instead of being able to just directly share the document, or a link to open the document.
  • Note: If this is not feasible in your team's workflow, consider replacing the OneDrive/Google Drive + Cryptomator with Tresorit, though note it starts at USD 18/user/month for teams, or
• Given the limitation on sharing, this guide offers suggestions for how to organise files in a team using Cryptomator and Bitwarden.
• This guide merely provides suggestions on how to organise your files - you still need to translate the advice to the specifics of your organisation.
• The suggestions here scale for organisations up to 50 people.

What you should prepare

• This guide assumes basic familiarity with 💻-🖥️ How to Manage Sensitive Files in the Cloud], and extends the advice to teams.

What you should do

1. Design your folder hierarchy

Since you can only share vaults, not files or folders within those vaults, the main idea is to create a new vault for reach group of people that needs access to those files.

Projects

So for example, if you are collaborating with a group of people on a project, in your Cloud drive, make a folder called projects and inside that folder create folders for each of the projects:

/projects
    /2021.01 - Alpha Project
    /2021.02 - Beta Project
    ...
    /2021.999 - Omega Project

Then the project folder, e.g. 2021.02 - Beta Project is the folder where you would store your vault to contain all the encrypted files for the 2021.02 - Beta Project. This project folder would then be shared with the team members.

But without a password, the files would still remain encrypted! So the password would be safely shared with BitWarden's organisation feature, with the name referring to the path of the vault, so for example, in the

Business Functions

In addition to projects, most organisations also have supporting business functions. For the files which need to be shared in the team, simply automatically stored in the cloud, we recommend that you create top-level folders in your drive alongside the projects folder created above

/admin
/finances
/hr
/legal
/projects

Then depending on your organisation's structure, you can again create sub-folders

/finances
    /bank statements
    /donations
    /receipts

If you only have a single team which all shares access to, for example, the finance documents, then you'd create the vault inside the finances folder and the sub-folders (i.e. bank statement, donations, and receipts would be inside your vault) but if different people have access to different parts of the finance documents, you would create vaults inside each of the sub-folder at a level where only the same set of people have access to the files contained within.

Only encrypt sensitive files

Due to the overhead of managing passwords and access rights for the vaults, it is sometimes more practical to only store sensitive files inside of a vault and have guidelines for what to consider as sensitive, and what is not.

With this practice, you could continue to store non-sensitive files in your regular cloud drives, share them with the built-in sharing functionality, and collaborate on the files with web apps (e.g. Google Docs or MS Word Online).

In this setup, it makes sense to have an explicit folder to contain your vault, next to the regular folders. So in the example where only the director and the finance officer need access to the finance documents, the folder structure could be

/finances
    /bank statements
    /donations
    /receipts
    /vault

Where the finances folder would be shared with those two people, so they would both have access to the bank statement, donations, receipts and vault folders. The director and the finance officer could then collaborate on all files in the first three folders using online tools, and the sensitive files in the vault would first need to be decrypted on their computers to access and modify them. But the changes one person makes would still be synced back to the cloud drive.

2. Password sharing in Bitwarden

When you create new vaults, you also setup passwords.

Vault Paths as Names

These passwords should of course be stored in a login profile in a password manager, but we also recommend that you name them in reference to the path of the vault. A path is the location of the vault in your cloud drive, or in other words, which directories you need to navigate through to get there. In the example above where we discussed putting our vault inside a folder named 2021.02 - Beta Project which itself was inside a folder named projects, the path is simply projects/2021.02 - Beta Project. That's what we recommend that you use as the "name" of your Login Profile:

This way it's immediately clear to the staff administrating the collections and the people receiving access to which vault the password applies, and where to find it in the cloud drive. This is especially handy when the vault is deeply nested, for example in a structure like projects/2021/active/burma/alpha project/proposals/<VAULT>.

Teams as Collections

A collection in BitWarden is group of people who all share the same access rights. An "access right" means that the user who has it is enabled to access something. For example, to login to a service like Facebook, the organisation's bookkeeping system, or the admin account on the password manager. In BitWarden, collections group passwords together, because effectively a shared password confers an access right. So this functionality can also be used to organise the teams in your organisation.

Each organisation is different. For some it will make sense to have function-based teams, for others project-based teams, again for others it would be geographic teams, or any combination thereof!

When you share a login profile with a particular collection in your Bitwarden Organisation, you restrict access to the team members that need to have access to those files.

In the example below, we've added four people to the "media team" collection (the last four)

With the team members assigned to the collection, you can then also assign the login profiles to the collection, so the four people above would all have access to the two login profiles below.

In our ongoing example, each member of the team would thus be able to unlock the vaults stored in projects/2021.01 - Alpha Project and projects/2021.02 - Beta Project based on the passwords shared in the "Media Team" collection.

Login Profiles in many Collections

As the same password can be provided as part of different collections, you don't need to copy passwords / login profiles around anymore, but can simply associate them with all the teams they should be available to.

In the example above, the Login Profile for the "Alpha Project" is both shared as part of the "Directors" collection and the "Media Team" collection. In other words, the users who have been given access to the "directors" collection - because they are directors! - will have access to this password, as well as the users who have been assigned to the "media team" collection - either because they are part of the media team, or have the same access rights as a member of the media team.

3. Steps for an Example Implementation

So to summarise. Implementing this system with a Cloud Drive, Cryptomator and Bitwarden, the person responsible for managing the organisation's digital security would:

1. Create 1 Bitwarden organisation for your organisation
2. Create collections for each group of people with the same access rights (i.e. have passwords shared among them).
   • TIP Give collections a representative name for the group of people, e.g. "Yangon Team", "Paralegals", "Finance", or "Social Media Admin".
3. Invite everyone you need to manage or share passwords with to BitWarden.
4. Assign everyone to their respective collections, i.e. based on your organisation structure.
   • Example everyone in the Yangon team should be assigned to the "Yangon Team" collection and everyone responsible for managing the social media accounts should be assigned to the "Social Media Admin"
5. Create and follow the folder hierarchy that suits your organisation and workflows, and create 1 vault with Cryptomator in each folder where you would want to share sensitive files and folders with the same people
   • TIP the password should always be a 64-character long generated password
6. Create 1 login profile for each vault, using the path of the vault as the name.
   • Example for the second project we started in 2021 called "Beta Project", we created a vault in the Cloud Drive at projects/2021.02 - Beta Project/<VAULT>, in BitWarden we add a login profile where:
     • name : projects/2021.02 - Beta Project
     • password : JUST-AN-EXAMPLE-AuXXU$h4n8xRibpGf%C&*8FtFRpEKEg8Eu9VLPnG%SEqKW
7. For each of the login profiles created, assign them to the relevant collections
   • Example Both the Directors and the Access2Justice team should have access to the files in the "Beta Project" vault. So the login profile would be assigned to both the Directors and the Access2Justice collections, which should now already have all the relevant people assigned to them.

4. Further Considerations

Once this is done, you will have fine-grained control over which teams have access to which vaults.

You can now easily:

• manage your passwords based on the teams who require access to them;
• keep a single source of truth for your passwords - i.e. as soon as you change the password in a login profile, the change will be available in all collections. Similarly, if you needed to move the location of a vault (for example if it were archived), then updating the name of the login profile would also be reflected immediately in each of the collections, and everyone would be aware of the change;
• revoke access to vaults by removing users from collections;
• share a teams' passwords to a new team member by adding them to the relevant collections;
• get an overview of all the passwords that are shared with a particular user, so in the case of an emergency (where revoking isn't enough), you have a list of passwords to change.

This method also gives you some additional benefits since it is quite likely that if the person seizing your devices are not so sophisticated, they might just copy the whole hard drive, or the cloud drive that could be logged into, but without the passwords they would be useless. The delay in this discovery could be all the difference you need to change the passwords on the vaults, or wipe the contents from the encrypted drives.

Also no person can be expected to know all the passwords to all the vaults, so by separating your sensitive files across many vaults, you can also make sure that even if one or some passwords are leaked, your other vaults would still be secured.

There is quite some administrative overheads to this process though, so it is recommended to have a single point person responsible for maintaining the collections and the users and logins profiles associated with them. The overheads is also why this probably would not scale well for organisations beyond 50 staff members (which all had very different functions). It might also take a some experimenting to know at which 'level of the folder hierarchy' a vault should be created, i.e. if you create it to high in the hierarchy, then you can't be precise with who you share it with access would not be sufficiently restricted, but if you put it too far down in the hierarchy, staff members would have an excessive number of vaults to mount and decrypt to get access to their files. So it is normal that it takes some experimentation before the right balance (i.e. level in the hierarchy) is found.