You’ve decided that managing your organization’s passwords is essential. You’ve selected a Password Management System that has the level of security you need, while retaining the flexibility to meet individual stakeholder’s requirements. You anticipate there’ll be substantial interest and take-up as you roll out the solution. The only question remains, how do you ensure that the way in which credentials are stored make them easy to locate, ensure they’re accessible to only those that need them, and make management of the solution as straightforward as possible.
Surely the best way to store all the credentials is in one big Password List stored in the root location? That way you could just assign the permissions on a credential-by-credential basis! Or maybe you should let everyone create their own Password Lists and store them all together. If one user needs access to the same credential, they can just enter it in their Password List as well! …..No! Absolutely Not! Let’s rethink that approach!
Organizational Structure is Important
An organization’s structure lays out the official functional relationships governing the workflow and day to day operations in the organization. The structure makes it easier to add new positions and provides a flexible method for growth. Without it, employees find it difficult to know who they officially report to and who has final responsibility over operational elements. It provides a basis for segregation of duties to ensure appropriate governance.
Organizational structure improves operational efficiency. Departments work better together by focusing their effort on productive tasks without duplication. The following diagram is a fictional organizational structure for the company An Example and we’ll be using it for this blog.
Using an organization’s structure is a good place to start when organizing your password credentials. First, we’re going to create folders for all of the Level 1 entities in the diagram below. These are the top-level functional bodies within this organization. You’ll note that the CEO folder is grouped at Level 1 also. There is no value in creating a CEO folder with all other folders nested beneath it so it’s grouped at the same Level as all other top-level folders. Each of these top-level folders may or may not have additional folders nested beneath depending on the complexity of the organizational unit and the granularity of permissions you wish to set,
Next, we create the nested Level 2 folders for each of the Level 1 folders we’ve created. The diagram below shows the examples of the two folders that will be nested beneath Operations (Chief Operating Officer), Operational Services and Metallurgical and Chemical laboratories. Likewise, under Finance (Chief financial officer), we have IT and Legal (Legal matters).
Security Groups and Permissions
Most organizations that use Microsoft’s Active Directory (AD) will have AD Security Groups that closely match their organizational structure. The group charged with IT Security will likely already have agreed and implemented your AD Security Groups and populated them with the appropriate user accounts aligned with the structure. That’s the same in this example and it makes assigning permissions to your folders that much easier.
If you aren’t using Microsoft AD and AD Security Groups you can still create your own Forms based User Accounts and Local Security Groups. It’ll just mean there’s more initial work to create these and regular maintenance will be required to keep these up to date.
You may from time to time be tempted to use individual users instead of Security Groups to assign permissions. Whilst this can be done it should always be used as the exception to the rule…the rule being use Security Groups whenever you can!
In the example above we’ve created a Folder under IT called Desktop Support. We’ve thencreated a Shared Password List called Production Desktops.
The permissions for accessing Production Desktops and the Desktop Support Folder is based on the AD Security Group Desktop Support. Only members of this AD Security Group have been given Admin Access to the Password List. IT staff not in the Desktop Support AD Security Group have no access.
Permission Model Types
It’s probably worthwhile recapping on the two permission models you can use within Passwordstate, Standard and Advanced.
The Standard Permission Model applies the permissions in a bottom-up approach. When you apply the permissions to the Production Desktops Password List the access is applied to all Folders in that hierarchy i.e. An Example->Finance->IT->Desktop Support.
Using the Advanced Permissions Model applies permission in a top-down approach. If we were to apply the Desktop Support Security Group at the IT Folder Level it would provide access to IT->Desktop Support-Production Desktops Password List and IT->Legal and any Password Lists or subfolders located under the Legal Folder. Note the image below is just to show the Advanced Model and doesn’t apply to the Desktop Support example we are using,
Both Permission Models are valid and can be used effectively. The most appropriate model is the one that best suits the way in which your and/or your Security Administrators prefer to work.
Restrictions that can be Applied
There are a number of restrictions that can be applied to manage the folder structure and where Password Lists are placed. The first is limiting who has permission to create new Folders in the root of Passwords Home. This can be found by navigating to Administration->Feature Access->folder options and clicking on the Set Permissions button,
The second is limiting who has permission to create Password Lists in the root of Passwords Home. If you’ve gone to the extent of creating an organised folder structure then the last thing you’ll want is for Shared or Private Password Lists to be inadvertently dumped in the root. This also applies to restricting who is allowed to Drag-N-Drop Password Lists around in the structure you’ve created. These permissions can be set by navigating to Administration->Feature Access->password list options and againclicking on the Set Permissions button for each of the settings you wish to restrict,
Additional Items for Consideration
As you build your Folder structure and start creating Password Lists there are a couple of other points to consider with links to our blog entries below;
Performance Improvements: https://blog.clickstudios.com.au/performance-improvements-how-to-troubleshoot-and-resolve-issues/
Optimal sizing of your Password Lists: https://blog.clickstudios.com.au/password-list-performance-testing/
In Summary
With a bit of thought and alignment you can effectively build a folder hierarchy and manage your Password Lists by using;
- The Organizational Structure as your basis,
- Using Security Groups to your advantage,
- Using the appropriate Permission Model, and
- Restricting who can apply structural changes
This will ensure your Passwordstate instance accommodates changes and growth while minimizing the on-going management effort. We’d love to hear your feedback, send it to support@clickstudios.com.au.