This topic contains a set of recommendations and best practices for administering your LabKey Server in accordance with
a strong security culture across your organization as a whole.
Tips for Operating System User Accounts
Limit Direct Access to Servers
Only authorized users should be allowed login access to the server(s) running LabKey processes (e.g. Web Servers, Database Servers, Storage Arrays, etc). These authorized users should ideally be individuals who will be doing maintenance and administration to maintain the health of the LabKey instance, such as system administrators. Ideally, there should not be any non-administrative users with backend privileges since that can introduce security risks.
Limit Root User Privileges
For those same authorized users, do not give them root level privileges with their login credentials, but instead leverage features such as the sudo command in Linux or the "Run As" option in Windows to temporarily elevate the user's permissions.
Enable Audit Logging
Ensure you have operating system auditing enabled on the server to monitor the activity of the users on the server, and issue alerts when potential threats are detected.
Utilize Password Security Management
Use good password security management and encourage strong security culture within your organization.
Tips for Server-Side Software
Limit System (Service Account) User Permissions
System-based users that are responsible for running certain applications (e.g. the 'labkey' user to run the application, the 'postgres' user to run PostgreSQL) should be given very narrow access to only things that are relevant to that system user's needs to allow the application to run properly. System-based users that are required to run LabKey should not need to have root-level privileges.
Explore Other Methods for Granting Extended Permissions vs Using Root
For some systems, certain application dependencies might require an adjustment to allow non-root level access to things that shouldn't be run as root, such as Java. Using a utility to set the file capabilities, such as the setcap command on Linux, is recommended rather than trying to increase the user's level of access.
Tips for Files and Folders
Use a Dedicated Temporary Folder for the LabKey User
For your LabKey application, you should set up a separate LabKey temp directory that is assigned to
and solely for use by the LabKey system user, rather than use the Linux temp directory, which is shared on the system.
If a shared resource like the Linux temp directory needs to be used, we recommend using methods to control file-level access, such as File Access Control Lists (FACLs) and umasks on Linux or ACLs on Windows.
Limit File/Folder Permissions
Identify what resources your users and groups on your servers should have access to and make sure you have set your file and folder permissions correctly to prevent unauthorized users and groups from being able to view, change, add, or remove files and folders they shouldn't be allowed to access. For example, do not make these files readable or writable by all operating system users.
Review the configuration for default permissions for newly created files. In particular, focus on the LabKey modules and webapp deployment directories, the Tomcat temp directory, and all file roots that LabKey is configured to use.
Ensure that the Tomcat user only has access to the files it needs and does not have access to other areas of the operating system.
Tips for Networks
Limit Access to Backend Application TCP/IP Ports
If your environment runs the LabKey web application and database on a single server, ensure that only trusted IP addresses are allowed access to the server on the backend. Ensure only certain ports are open for backend access (e.g. Port 22 for SSH on Linux, Port 3389 for RDP for Windows) via Network Access Control Lists (NACLs).
If your environment runs the LabKey web application and database on separate servers, ensure that only trusted IP addresses are allowed access to the server on the backend and only have certain ports open for backend access. Ensure that the web server and database server are also configured to only communicate with each other on specific ports (e.g. Port 5432 for PostgreSQL, Port 1433 for Microsoft SQL Server) using NACLs.
Protect Public-Facing Servers from Malicious Attacks
If your LabKey server is public-facing, it is recommended to use a Web Access Firewall and appropriate rules to restrict malicious activities, such as script injections, and to block problematic source IP addresses.
Tips for the LabKey Application
Only Allow Trusted Users to Access the System as Admins or Developers
In addition to reviewing our
Security documentation, we recommend making sure you only allow Admin-level and Developer-level access to trusted users.
Stay Current with Updates
We recommend using this list in conjunction with your existing IT security practices, which also means making sure that your operating systems and applications are kept up to date, including security updates and patches.
Related Topics