When it comes to Laserfiche Security, it is essential for repository access to be configured correctly for users to perform their tasks. This article discusses several steps that can be taken to optimize the overall effectiveness of your Laserfiche content security.
Laserfiche Security best practice suggests it is helpful to concentrate on keeping the all-around infrastructure simple. It is recommended to work from the repository root folders largest toward the smallest document level and fine-tune, as needed.
Where to Begin?
Here are some simple tips to get you started:
Begin by logically configuring your users and groups as if you are setting up the repository from scratch; if you have an existing system, you will want to run a security report to understand the current security situation.
Determine feature rights, privileges, and entry access rights.
Determine what security features are needed.
Test and correct as necessary.
Groups Vs. Users
There are benefits to setting Laserfiche Security at the group level as opposed to the user level. The users will inherit security from the group. Group configuration advantages include:
Easy setup and low maintenance going forward
Increased consistency
Laserfiche repository groups can collect a variety of users
Useful for Windows/LDAP groups that don’t align with Laserfiche use cases perfectly
Helpful for testing
When creating groups, consider the types of users that you have and how you want to group or separate users for security purposes. Groups are often set based on roles or department. In some circumstances, users will need to have security set at the user level; examples include:
Personal folders
Folders with special security needs
Distribution of privileges
Core Security
When administrators are configuring security for the repository, three questions are commonly asked.
1. Who - Which users and groups have access?
It is important to remember that users inherit access from groups they belong to, and in a well-designed repository, most security is set at the group level. Additionally, many security settings for a single user are combined.
2. What - What can they do?
The individual access rights determine what operations are possible. Examples:
Browse – See but not open folders and documents
Read – Open folders and documents viewing contents and metadata
Modify contents – Make changes
Additionally, the permitted or prevented actions are specified with the following settings:
Allow - users can perform the action
Deny - user is prevented from performing an action
Blank - user can perform the action if they have inherited the right from higher in the tree; if not, they can’t
3. Where – What portion of the repository will the rights will be applied to?
It’s worth noting that every document and folder does not need separate security rights applied. The best practice uses inheritance propagate rights downward and scope to allow administrators to determine how far to propagate the right.
Repository relevant security that all administrators need to be aware of include:
Entry Access Rights – Refers to direct access to documents and folders within the repository. When configuring entry access rights, it is beneficial to plan and determine the configure setup that requires the least amount of manual configurations.
Recommended best practices for setting entry access rights include:
Establish rights on folders, not documents
Configure your repository to take advantage of inheritance
Use scope to determine how far down the tree the rights should extend
Keep configurations to a minimum
Feature Rights – Tools available to specific user or groups;, giving administrators the ability to allow or deny actions across the entire repository. Users are required to have both the relevant feature right and the appropriate access right to perform the actions.
Privileges – Privileges grant administrative power; granting a wide-range of abilities. These privileges can override other security when the user is granted the Manage Entry
Access Privilege, which allows the user to browse the entire repository. Privileges are not required for standard tasks such as filing, viewing, and modifying documents.
Security Deployment Considerations
While User access is a critical component of effective security administration, securing your network environment and automation factors is also key. Cover the basics by locking down and encrypting file in Windows, you will want to include: formatting
Volume locations
Databases
Search index files
Another important component is ensuring secure communications between components.
Using other supplemental methods to help support your security plan include supplemental security items like:
Security tags - Referred to as point security and is used to “hide” a document. Access to a document with a tag applied is only available to users that are granted access to the tag. The tag follows a document through the repository and overrules other security including privileges.
Template access rights - Administrators can deny Read access for a template to hide the template or hide its fields on entries with that template even if those fields have individually been given Read access. Fields that appear outside of the template on an entry are not affected. Template access rights are often used for user convenience (showing only relevant templates).
Field access rights - The Write Metadata entry access right controls who can edit fields on specific documents. However, field and template access rights can be used to make exceptions for specific fields or templates.
Volume security - Volumes store copious amounts of information including images, text, and electronic files on the hard drive. Volume rights control access to those components of a document. The default security settings are usually enough but can be adjusted if the need exists.
Test, Test, Test
Finally, as security measures are being configured, test your progress.
Setting up security by Groups is very useful for testing. Additionally, testing as you implement helps verify that your ‘broad strokes’ approach worked properly before handling exception cases, and will help you pinpoint any security features that maybe misconfigured. Remember that access rights take effect immediately and everything else requires a logout/login.
If you want to see the security configuration at any point, run a security report. These reports allow for easy spot checking and rights reports, which are great for troubleshooting or auditing purposes. This can be an extremely useful tool to help administrators understand a repository that they have just inherited.
In summary, a comprehensive look at your current security practices or implementation plan will help you identify and address any issues, allowing you to achieve a Laserfiche system that operates with top notch security.
Final key takeaways include:
Leverage scope and inheritance for simplicity
Work from largest to smallest
Set general rights and increasing granularity
Start small, test and then expand
Use the fewest number of features to do what is needed
We hope you have enjoyed this article. If you need assistance configuring your Laserfiche system security, please contact the CDI Support Team.
Comments