PEM application Security Configurations v8.0

Edit this page

Session Timeout

Insufficient session expiration by the web application increases the exposure of other session-based attacks, as it allows time for the attacker to be able to reuse a valid session ID and hijack the associated session. The shorter the session interval is, the lesser the time an attacker has to use the valid session ID. We recommend setting the inactivity timeout for the web application to a low value to avoid this security issue.

Postgres Enterprise Manager provides a way to set the timeout value for a user session. When there is no user activity for a specified duration on the web console, PEM will log out the user from the web console. A PEM Administrator can set the length of time for inactivity. This value is application-wise, rather than for an individual user. To configure the timeout duration, modify the USER_INACTIVITY_TIMEOUT parameter in config_local.py file, located in the <PEM_INSTALLATION_PATH>/web directory. By default this functionality is disabled.

For example, to specify that an application should log out a user after 15 minutes of inactivity, set:

USER_INACTIVITY_TIMEOUT = 900

Note

The timeout value is specified in seconds.

This changes requires an Apache service restart in order to take effect.

For more detailed information on config.py file you can see PEM Online Help.

RestAPI Header Customization

You can customize the RestAPI token headers as per your requirements. The default values are not exposed by the config.py file; customize the following headers in the config_local.py file:

PEM_HEADER_SUBJECT_TOKEN_KEY

This configuration option will allow you to change the HTTP header name to get the generated token. By default, when the user sends a request to create a token, the server response will have an ‘X-Subject-Token’ header, which will contain the value of a newly generated token. If you want to customize the header name, then you can update the config_local.py file as shown:

PEM_HEADER_SUBJECT_TOKEN_KEY = 'Pem-RestAPI-Generate-Token'

Which will give you the following output:

curl -ik -X POST -d '{"username":"enterprisedb","password":"edb"}' -H "Content-Type: application/json" https://localhost:8443/pem/api/token/

HTTP/1.1 201 CREATED

Date: Thu, 29 Oct 2020 11:03:48 GMT

Server: Apache

Content-Length: 326

Pem-RestAPI-Generate-Token: 997aef95-d46d-4d84-932a-a80146eaf84f

PEM_HEADER_TOKEN_KEY

This configuration option will allow you to change the HTTP request header name through which you will send the token to the PEM server. By default, when the user sends a request to generate a token, the token header will be X-Auth-Token. If you want to customize the RestAPI request header name then you can update the config_local.py file as follows:

PEM_HEADER_TOKEN_KEY = 'Pem-Token'

Which will allow you to send the token:

$ curl -Lk -X GET -H "Pem-Token: gw5rzaloxydp91ttd1c97w24b5sv60clic24sxy9" https://localhost:8443/pem/api/v4/agent

PEM_TOKEN_EXPIRY

This configuration option will allow you to change the PEM RestAPI token expiry time after it is generated. By default, the token expiry time is set to 20 minutes (1200 seconds). If you want to change the token expiry time to 10 minutes then you can update the config_local.py file as shown:

PEM_TOKEN_EXPIRY = 600

This changes requires an Apache service restart in order to take effect.

Role-based Access Control in PEM

Role-based access control (RBAC) restricts application access based on a user’s role within an organization and is one of the primary methods for access control. The roles in RBAC refer to the levels of access that users have to the application. Users are only allowed to access the information necessary to effectively perform their job duties. Roles in PEM are inheritable and additive rather than subscriptive. In simple terms, as a PEM admin you need to grant the lowest level role to the user and then grant the roles which are required for the user to perform their respective tasks. For example, to give access only to SQL profiler:

CREATE ROLE user_sql_profiler WITH LOGIN NOSUPERUSER NOCREATEDB NOCREATEROLE INHERIT NOREPLICATION CONNECTION LIMIT -1 PASSWORD 'xxxxxx';

GRANT pem_user, pem_comp_sqlprofiler TO user_sql_profiler;

For more detailed information on roles, you can see PEM Roles.

SQL/Protect Plugin

Preventing a SQL injection attack is usually the responsibility of the application developer. The database administrator typically has little or no control over the potential threat. The difficulty for database administrators is that the application must have access to the data to function properly.

SQL/Protect is a module that allows a database administrator to protect a database from SQL injection attacks. SQL/Protect provides a layer of security in addition to the standard database security policies by examining incoming queries for typical SQL injection profiles.

There are several different techniques used to perpetrate SQL injection attacks. A specific signature characterizes each technique. SQL/Protect examines queries for Unauthorized Relations, Utility Commands, SQL Tautology, Unbounded DML Statements. SQL/Protect gives the control back to the database administrator by alerting the administrator to potentially dangerous queries and blocking them.

Note

This plugin works only on the EPAS server, so this is useful only when your PEM database is hosted on the EPAS server.

For more detailed information about the SQL Profiler plugin, see the PEM Online Help - SQL Profiler.

Password Management

One security tip for PEM administrative users is to change your PEM login passwords to something new regularly. Changing your password avoids a number of dangers including:

  • breaches of multiple accounts
  • prevents constant access
  • prevents the use of saved passwords on a physically unsecured system
  • limits access gained by keystroke loggers

Run pemAgent Jobs with a Non-root User

In most cases, pemAgent is installed as a root user, and runs as a daemon process with root privileges. By default, PEM disables running the scheduled jobs/task. PEM provides support for running scheduled jobs as a non-root user by changing the pemAgent configuration file.

To run scheduled jobs as a non-root user, modify the entry for the batch_script_user parameter in the agent.cfg file and specify the user that should be used to run the script. You can either specify a non-root user or root user identity. If you do not specify a user, or the specified user does not exist, then the script will not execute. Restart the agent after modifying the file. If a non-root user is running pemagent, then the value of batch_script_user will be ignored, and the same non-root user used for running the pemagent will execute the script.

To invoke a script on a Windows system, set the registry entry for AllowBatchJobSteps to true and restart the PEM agent. PEM registry entries are located in:

HKEY_LOCAL_MACHINE\Software\Wow6432Node\EnterpriseDB\PEM\agent

Changing the pemAgent and PEM Backend Database Server Certificates

By default, when you install PEM, the installer will generate and use self signed certificates for the pemAgent and PEM database server. PemAgent uses these certificates when connecting to the PEM database server. To use your own SSL certificate for the pemAgent and PEM database server, follow the steps mentioned in the Managing Certificates section of the PEM Administrators's Guide:

Note

PEM does not support placing the SSL CA certificates at a custom location; you should not change the location of ca_certificate.crt and ca_key.key.