Contents- Introduction
- Overview
- Network Security Configuration
- User Management
- System Audit Logging
- Certification Authority
- Certificate Generation
- Configuring Secure Database Replication
- Configuring Secure Notifications
- Configuring LDAP Front End Security
- Configuring Secure CUDB OAM Centralized Authentication System Support
- Configuring Secure Centralized Security Event Logging
- Other Security Recommendations
- Privacy
- Reference List
1 Introduction
This document provides a description for the security functions available in the nodes of the Ericsson Centralized User Database (CUDB).
1.3 Typographic Conventions
Typographic Conventions can be found in the following document:
2 Overview
This document provides instructions on how to secure CUDB network interfaces and the CUDB node itself to protect the system from malicious attacks and prevent unauthorized access to the information stored in the system.
The document offers security guidelines for the following topics:
The topics listed above are described in the following sections in more detail.
This document also provides the CUDB privacy-related statements.
3 Network Security Configuration
This section describes the security configuration related to communication between different nodes. For further information about network configuration, refer to CUDB Node Network Description.
3.1 Backbone Security
The CUDB backbone is protected by the following means:
| Note: |
CUDB also supports IPSec, used to encrypt communication links.
IPSec configuration is however not in the scope of this document. |
CUDB offers a large set of security functions to secure communication channels. The use of these functions depends on the security level that CUDB operators prefer to reach.
3.2 ICMP Reply
The Internet Control Message Protocol (ICMP) is allowed by default, since its use does not pose any risks, as CUDB is not exposed to external networks. However, to avoid CUDB being flooded with ICMP messages, other network infrastructure elements (such as routers) must be configured accordingly.
For CUDB systems deployed on native BSP 8100, consult the next level of maintenance support for more information on how to define a policy to disable ICMP traffic in the Component Main Switch (CMX).
For CUDB systems deployed on a cloud infrastructure, refer to the routing related documentation of the infrastructure to determine how to disable ICMP.
3.3 Allowed Protocols, Services, and Ports
Refer to CUDB Node Network Description for detailed information about the protocols, services and ports that must be open or allowed in order to perform CUDB operations.
3.4 Access Filtering
Network security level may be increased by implementing proper access filtering.
For CUDB systems deployed on native BSP 8100, CMX routers implement advanced Policy Based Forwarding (aPBF) rules. These aPBF functions allow to configure or filter match rules and action policies for CMX. Consult the next level of maintenance support for further details.
For CUDB systems deployed on a cloud infrastructure, refer to the routing related documentation of the infrastructure for information about the available access filtering tools and policies.
3.5 Switch Configuration
Implementing secure access to the switches is recommended.
For CUDB systems deployed on native BSP 8100, the System Control Switch Board (SCXB) can be configured by means of a Secure Shell (SSH) interface. If needed consult the next level of maintenance support.
For CUDB systems deployed on a cloud infrastructure, refer to the switching related documentation of the infrastructure for information about implementing secure access to the switches.
3.6 Router Configuration
This section provides information on how to increase security with proper router configuration.
For CUDB systems deployed on native BSP 8100, the CMX control interfaces can be either trusted or non-trusted, which means the following:
The control interfaces work according to the following security restrictions:
For CUDB systems deployed on a cloud infrastructure, refer to the routing related documentation of the infrastructure for information about securing routers configuration.
4 User Management
CUDB offers the following user management tools from a security perspective:
These tools are described in the following sections in more detail.
4.1 LDE User Management
The CUDB users are based on LDE, and are managed on node level. This means that all servers of the CUDB node see the same set of existing users.
The users are stored persistently, which means that they are not deleted if the server is rebooted.
CUDB is preconfigured with two user groups:
Additional users and user groups can also be created. It is mandatory to define passwords for all the groups and to include all the defined users into a group.
Refer to CUDB Users and Passwords for more information on the default user and password pairs used in the CUDB system. For more information on LDE, refer to LDE Management Guide.
4.1.1 cudbadmin Password Expiration Policy
The password expiration policy of LDE users is configured with the chage command.
The default password validity of cudbadmin is 30 days, with password change reminders set to be raised 10 days before password expiration.
4.1.2 User Policies
CUDB offers several user account settings to enhance the security of session establishment. The steps of configuring these settings is described below.
4.1.2.1 Configuring the Maximum Number of Failed Login Attempts
To configure the maximum number of login attempts, set the value of the maxNumFailedLogins attribute located under the cudbSystemSecurity class. For more information, refer to the Class CudbSystemSecurity section in CUDB Node Configuration Data Model Description.
Refer to the Object Model Modification Procedure in CUDB Node Configuration Data Model Description for more information on all the steps required to modify the object model (for example, on using the applyConfig administrative operation to activate the changes).
4.1.2.2 Configuring Lockout Period
To configure the user lockout period, set the value of the lockoutPeriod attribute located under the cudbSystemSecurity class. For more information, refer to the Class CudbSystemSecurity section in CUDB Node Configuration Data Model Description.
Refer to the Object Model Modification Procedure in CUDB Node Configuration Data Model Description for more information on all the steps required to modify the object model (for example, on using the applyConfig administrative operation to activate the changes).
4.1.2.3 Configuring Inactivity Timer
By default, an inactivity timer is enabled for each user account. Account expiry is moved forward by (a fixed) 90 days on each login.
4.1.2.3.1 Accounts not Expiring
Accounts which should not expire must belong to the group no_expire. This privilege can be set by the CUDB system administrator:
Steps
4.1.2.3.2 Expired Accounts
If a user account is expired, it can be re-enabled by the CUDB system administrator:
Steps
Results
By default, the root user account and the following pre-defined local CUDB user accounts will never expire:
| Note: |
When a user account is newly created, no account expiry date is set until the first login
of the user. |
4.1.2.4 cudbadmin Group Permissions
The cudbadmin group
permissions are assigned by using the /etc/sudoers file. Permissions can be granted as follows:
By default, the CUDB system is preconfigured with the following paths in the /etc/sudoers file:
Users in this group can read log files on the /var/log/SC_2_* and /var/log/PL_2_* paths by using the tail and grep commands, as shown below:
sudo grep ERROR /var/log/PL_2_3/messages
sudo tail -50 /var/log/SC_2_1/kernel
| Note: |
For security reasons, cudbadmin group users have no write access in the above
directories. |
4.1.2.5 cudbOperators Group Permissions
The cudbOperators user group is used to perform common configuration and maintenance
tasks. Users of this group can perform the following tasks as super
users:
Refer to CUDB Node Logging Events for more information on CUDB logs.
4.1.3 Password Strength Policy
When new user accounts are created, the CUDB system applies the default password settings on them. It is recommended to configure the password strength according to the desired behavior by following the below instructions.
4.1.3.1 Configuring the Minimum Password Length
To configure the minimum password length, set the value of the minPasswordLength attribute located under the cudbSystemSecurity class. For more information, refer to the Class CudbSystemSecurity section in CUDB Node Configuration Data Model Description.
Refer to the Object Model Modification Procedure in CUDB Node Configuration Data Model Description for more information on all the steps required to modify the object model (for example, on using the applyConfig administrative operation to activate the changes).
4.1.3.2 Configuring the Minimum Number of Unique Passwords
To configure the minimum number of unique passwords before an already used password can be selected again, set the value of the minPasswordNonRepeat attribute located under the cudbSystemSecurity class. For more information, refer to the Class CudbSystemSecurity section in CUDB Node Configuration Data Model Description.
Refer to the Object Model Modification Procedure in CUDB Node Configuration Data Model Description for more information on all the steps required to modify the object model (for example, on using the applyConfig administrative operation to activate the changes).
4.1.3.3 Configuring Password Strength
To ensure the use of strong passwords, the following rules apply to password configuration:
| Note: |
These restrictions do not apply to the root user. When configuring
a new root password which does not meet the above restrictions, the
system sends a warning message, but allows changing the password. |
4.1.4 General Password Recommendations
CUDB users are strongly advised to abide by the following password handling recommendations:
4.2 Remote User Authentication Management
CUDB OAM Centralized Authentication System Support provides a mechanism to authenticate external OAM users stored in a remote LDAP authentication server, not defined locally, and grants them access to OAM SSH interfaces in CUDB nodes. This allows to define and manage new users and groups only in remote LDAP servers, in a centralized way, instead of having to create them locally on all CUDB nodes. Locally defined OAM users are still authenticated locally.
Remote users created inside an LDAP authentication server can belong either to remote groups created in an LDAP authentication server, or to local groups defined inside CUDB nodes, for example the cudbOperators or cudbadmin groups. Authorization rules (permissions) for those groups are applied depending on the context of definition as follows:
It is possible to configure one or two remote LDAP authentication servers, so in case the first one is temporarily down, the second server can provide the authentication service.
The following mandatory parameters must be configured:
Optionally, the following additional configuration attributes may need to be set:
When configuring Centralized Authentication, CUDB, as an additional and unconditional step, overrides the login shell for remote users by putting the nss_override_attribute_value loginShell /bin/bash directive line in /home/cudb/security/config/ldapAA_ldap.conf.
Refer to CUDB Node Configuration Data Model Description for more information on configuring these parameters on the CudbExternalAuthServer class.
CUDB OAM Centralized Authentication System Support supports connection to remote LDAP authentication servers that either have TLS disabled (so messages between CUDB node and remote LDAP authentication servers are not cyphered), or enabled (so messages are cyphered). By default, TLS is disabled: to enable it, set the proper certificates before activation by following the steps of Configuring Secure CUDB OAM Centralized Authentication System Support.
If TLS is enabled, the Certification Authority certificate must be part of the file set in the tlsCaCertificatesFile attribute of the CudbSystemSecurity class.
It is also possible to configure the method of establishing a secure connection to the external server using the tlsMode attribute.
Once the certificates are configured, set the tlsEnabled attribute to true. Refer to CUDB Node Configuration Data Model Description for more information on configuration.
Once the CudbExternalAuthServer class is configured, enable external authentication by setting the enabled attribute of the CudbExternalAuthMgmt class to true.
When configuring and enabling the function, consider also the following:
Once properly configured and enabled, SSH connections to a CUDB node can be done by a remote or a local user. A remote user is a user that is created on the remote LDAP authentication servers; a local user is defined in the CUDB node. If an SSH connection to a CUDB node is initiated, different scenarios can occur based on the availability of the authentication servers. These scenarios are as follows:
4.2.1 Constraints of Remote User Authentication
The following limitations are applied to CUDB OAM Centralized Authentication System Support:
4.2.2 List of Local CUDB Users and Groups, Not Valid on Remote Servers
To avoid conflict, do not use the following predefined local CUDB usernames to create a new remote user on the LDAP authentication servers:
If any of the usernames above is reused as the username of a new remote user created on the LDAP authentication servers, the username on the remote server will be ignored: only the local definition of the user and the local password will work.
Regarding groups, any remote group created on the LDAP authentication servers with a gid corresponding to a default CUDB local group will be ignored, only the local group definition will apply. However, a remote user can belong to local groups (except to 0, as described in Constraints of Remote User Authentication). Local groups defined in the system can be checked in /etc/group directory.
4.2.3 Examples of Using Remote User Authentication
In the following example, OpenLDAP is used for the remote LDAP authentication servers, but any LDAP server compliant with RFC 2307: An Approach for Using LDAP as a Network Information Service is suitable, ensuring that the required object classes and attributes for storing users and groups information are used (mainly posixAccount and posixGroup classes). In case of OpenLDAP, the following schemas are used:
After the remote LDAP authentication servers are properly configured and started, new remote groups and remote users can be defined. Example 1 shows how to define one new remote group and two new remote users in LDAP authentication servers. One user belongs to the newly-defined remote group (9999) and the other belongs to the already existing local group cudbOperators.
On a CUDB node, the CUDB OAM Centralized Authentication System Support function must be properly configured in the configuration model element as follows:
Steps
After the above configuration is properly done, execute the following steps to log in:
Example 1 Defining a New Remote Group and Two New Remote Users
# remoteAdminGroup, Groups, ericsson.com dn: cn=remoteAdminGroup,ou=Groups,dc=ericsson,dc=com objectClass: top objectClass: posixGroup cn: remoteAdminGroup gidNumber: 9999 description: remote admin group # user1Admin, Users, ericsson.com dn: uid=user1Admin,ou=Users,dc=ericsson,dc=com objectClass: top objectClass: person objectClass: organizationalPerson objectClass: posixAccount uid: user1Admin cn: user1 sn: admin title: aaaaa1 telephoneNumber: +34 000 000 0001 loginShell: /dev/null homeDirectory: /home/user1Admin/ description: user1 administrator user userPassword:: e1NTSEF9azBPY2o1ankrUHEzcXR4dDlrU0JwQjI2K1J5NjVJblI= uidNumber: 1500 gidNumber: 9999 # user2Oper, Users, ericsson.com dn: uid=user2Oper,ou=Users,dc=ericsson,dc=com objectClass: top objectClass: person objectClass: organizationalPerson objectClass: posixAccount uid: user2Oper cn: user2 sn: oper title: aaaaa2 telephoneNumber: +34 000 000 0001 loginShell: /dev/null homeDirectory: /home/user2Oper/ description: user2 operator user userPassword:: e1NTSEF9dUFkQVhmMVgyaXdLVElxM3RObHZUaG1ZUm1UREVXdmE= uidNumber: 1700 gidNumber: 1007
Example 2 Successful Login with user1Admin
CUDB_xx SC_2_1# ssh user1Admin@10.22.0.1 Password: Creating directory '/home/user1Admin/'. Last login: xxxxxxxxxxxxxx SC_2_1 user1Admin/> id uid=1500(user1Admin) gid=9999(remoteAdminGroup) groups=9999(remoteAdminGroup) SC_2_1 user1Admin/> echo $SHELL /bin/tcsh
Example 3 Successful Login with user2Oper
CUDB_xx SC_2_1# ssh user2Oper@xx.xx.xx.xx Password: Creating directory '/home/user2Oper/'. Last login: xxxxxxxxxx CUDB_xx SC_2_1$ id uid=1700(user2Oper) gid=1007(cudbOperators) groups=1007(cudbOperators) CUDB_xx SC_2_1$ echo $SHELL /bin/bash CUDB_xx SC_2_1$ /usr/bin/tail -f /var/log/SC_2_1/messages /usr/bin/tail: cannot open `/var/log/SC_2_1/messages' for reading: Permission denied CUDB_xx SC_2_1$ sudo /usr/bin/tail -f /var/log/SC_2_1/messages <works>
After This Task
If both steps are successful, the user1Admin user successfully logs into the CUDB node. The specified /home/user1Admin/ home directory is then created as shown in Example 2, in case it did not exist before.
The same applies to the user2Oper user as shown in Example 3. As that user belongs to the cudbOperators group, it can execute the same sudo commands that any cudbOperator user can.
For users not belonging to local groups but to new remote groups, it is possible to modify the local sudoers file to allow it to have the rules of some local groups.
For example, sudoers can be modified to make the new remote group remoteAdminGroup have the same rules as the local cudbadmin group, by running as root visudo and changing the line User_Alias ADMINS = %cudbadmin to User_Alias ADMINS = %cudbadmin,%remoteAdminGroup.
After saving, the change is persistent to reboots, as it is stored under /cluster and is synchronized with all CUDB node blades or VMs.
Other adaptations can also be done in sudoers to set new rules for new remote groups or specifically for some users.
4.3 LDAP User Management
The CUDB LDAP users represent application FEs, and can read or potentially modify certain branches of the provisioned data in CUDB. User privileges can be set by the CUDB system administrator by changing the Access Control List (ACL) rules. LDAP users must be authenticated with the LDAP BIND operation using a configured password. Simple and Simple Authentication and Security Layer (SASL) authentication is supported.
| Note: |
rootdn has write
access to any part of the Directory Information Tree (DIT), and its
access cannot be restricted with ACLs. |
4.3.1 Changing the Password of the rootdn User
The LDAP password of the traffic root Distinguished Name (DN) can be updated for security reasons in the CUDB Configuration Data Model. To update the LDAP password, modify the value of the ldapRootPassword attribute located under the CudbLdapAccess class. For more information, refer to the Class CudbLdapAccess section in CUDB Node Configuration Data Model Description.
Refer to the Object Model Modification Procedure in CUDB Node Configuration Data Model Description for more information on all the steps required to modify the object model (for example, on using the applyConfig administrative operation to activate the changes).
The password of the rootdn user can contain only ASCII alphabetic, numeric digit characters, and the following symbols: ,-%=?+~_
It is recommended to follow the general password recommendations described in this document. For further information, see General Password Recommendations.
| Note: |
Connections opened towards LDAP FEs are lost during password
change, since the LDAP FEs are restarted to reload the new password. |
4.3.2 Access Control Configuration Rules
This section describes the rules of configuring access control settings. As stated before, ACLs may be configured to set the privileges for every LDAP user to access the LDAP DIT.
ACL processing impacts performance: the larger the list of rules, the more time it takes to process. Therefore, it is recommended to create short rule sets by grouping users.
| Note: |
Apply ACL rules with care, since changes can result in unexpected
access denials due to the access control rule syntax and semantics.
Always test changes on a test configuration before live deployment. |
Follow the steps below to configure access control rules for a CUDB node:
Steps
After This Task
| Note: |
The ACLs must be the same in the entire CUDB system. Therefore, if the access control
rules are changed in a node, the procedure described above must be executed on every node
of the CUDB system starting from Step 4 (copying
the modified acls.conf file to every node, then following the rest of
the steps). |
4.3.2.1 Access Control Configuration Guidelines
This section provides some guidelines on creating ACLs for CUDB. The guidelines are based on the contents of the OpenLDAP manual: refer to OpenLDAP Software 2.4 Administrator's Guide for specific information on the ACLs.
| Note: |
The longer the access control list, the more it degrades
the performance of the node. It is advised to keep the number of users
(and therefore the number of rules) to a minimum. |
Access control rules follow the below syntax:
access to <what> by <who> [ by <who> ...] [break]
A rule can span a number of lines, provided that the first character of all additional lines is a blank space. The elements of the above syntax are as follows:
When configuring access control rules, consider the following:
4.3.2.2 Access Control Configuration Examples
This section offers some example access control lists. In the below examples, dc=operator,dc=com must be replaced with <cudbRootEntryDn> (as defined in CUDB Node Configuration Data Model Description).
| Note: |
Actual access control lists may be much longer than the examples
shown below. |
Default ACL in CUDB, allowing write access for every user to the whole schema, except to the entries where users are defined:
access to dn.regex="ou=admin," by users auth access to * by * write
Example 5 ACL taking advantage of LDAP groups
ACL taking advantage of LDAP groups, granting the following operations: pgUsers group members have write permission for serv=csps,mscId=* and serv=ims,mscId=*; hlrUsers group members have write permission for serv=csps,mscId=*; finally, imsUsers group members have read permission for serv=ims,mscId=*.
access to dn.children="ou=admin,dc=operator,dc=com" by users auth access to dn.regex="serv=csps,mscId=([^,]+),ou=multiSCs,dc=operator,dc=com" by dn.children="ou=hlrUsers,ou=admin,dc=operator,dc=com" write by dn.children="ou=pgUsers,ou=admin,dc=operator,dc=com" write access to dn.regex="serv=ims,mscId=([^,]+),ou=multiSCs,dc=operator,dc=com" by dn.children="ou=imsUsers,ou=admin,dc=operator,dc=com" read by dn.children="ou=pgUsers,ou=admin,dc=operator,dc=com" read
Example 6 Complex example grants the following permissions
This complex example grants the following permissions: pgUsers group members have write permissions for everything, except the "ou=admin" branch; hlrUsers group members can read all the data, and have write permission for serv=ims,mscId=*, and serv=ims,assocId=*; finally, the hssUsers can read all the data, and have write permission for serv=ims,mscId=* and sev=ims,assocId=*.
access to dn.children="ou=admin,dc=operator,dc=com" by users auth access to dn.regex="serv=ims,mscId=([^,]+),ou=multiSCs ,dc=operator,dc=com" by dn.exact="cudbUser=hlr,ou=admin,dc=operator,dc=com" write by dn.exact="cudbUser=pg,ou=admin,dc=operator,dc=com" write access to dn.regex="serv=ims,mscId=([^,]+),ou=multiSCs ,dc=operator,dc=com" by dn.exact="cudbUser=hss,ou=admin,dc=operator,dc=com" write by dn.exact="cudbUser=pg,ou=admin,dc=operator,dc=com" write access to dn.regex="serv=ims,assocId=([^,]+),ou=associations ,dc=operator,dc=com" by dn.exact="cudbUser=hlr,ou=admin,dc=operator,dc=com" write by dn.exact="cudbUser=pg,ou=admin,dc=operator,dc=com" write access to dn.regex="serv=ims,assocId=([^,]+),ou=associations ,dc=operator,dc=com" by dn.exact="cudbUser=hss,ou=admin,dc=operator,dc=com" write by dn.exact="cudbUser=pg,ou=admin,dc=operator,dc=com" write access to dn.subtree="ou=identities,dc=operator,dc=com" by dn.exact="cudbUser=hlr,ou=admin,dc=operator,dc=com" read by dn.exact="cudbUser=hss,ou=admin,dc=operator,dc=com" read by dn.exact="cudbUser=pg,ou=admin,dc=operator,dc=com" write access to dn.subtree="ou=servCommonData,dc=operator,dc=com" by dn.exact="cudbUser=hlr,ou=admin,dc=operator,dc=com" read by dn.exact="cudbUser=hss,ou=admin,dc=operator,dc=com" read by dn.exact="cudbUser=pg,ou=admin,dc=operator,dc=com" write access to dn.subtree="ou=mscCommonData,dc=operator,dc=com" by dn.exact="cudbUser=hlr,ou=admin,dc=operator,dc=com" read by dn.exact="cudbUser=hss,ou=admin,dc=operator,dc=com" read by dn.exact="cudbUser=pg,ou=admin,dc=operator,dc=com" write
| Note: |
ACLs can use both attributes and object classes, since object classes are essentially
shorthands for the available attributes. |
4.3.3 Storage of LDAP users passwords
CUDB makes it possible to store the passwords of the LDAP users in clear text or in hashed form. In case hashed form is selected, several types of hashes are allowed.
4.3.3.1 Default Storage of LDAP Users Passwords
Perform the following steps to configure the way passwords are stored for LDAP users:
Steps
4.3.3.2 Storage of a Specific LDAP User Password
Perform the following steps to configure the way the password is stored for a specific LDAP user, overriding the default configuration:
Steps
Results
| Note: |
The password of the rootdn can only be stored encrypted. The user password is stored according to the values of nodeLdapAuth and nodeLdapHash (or userLdapAuth and userLdapHash, if defined) which are configured at the time the user password is set. |
4.4 Switch User Management
When configuring the switch, take into account the considerations regarding user account management (see LDE User Management) and secure password policies (see Password Strength Policy). For CUDB systems deployed on native BSP 8100, SCXB security features can also be enforced..
4.4.1 Remote Switch User Authentication Management
For CUDB systems deployed on native BSP 8100, the procedure to configure the external user authentication/authorization is described in the Configure LDAP Authentication document in the BSP 8100 CPI.
For CUDB systems deployed on a cloud infrastructure, refer to the infrastructure documentation for information about user authentication management. Implementing such policies is recommended.
4.5 Router User Management
This section provides information on the proper user management on CMX routers for CUDB systems deployed on native BSP 8100.
CMX uses static accounts that cannot be changed. The following set of Linux users is available:
The user names are hard-coded, and it is not possible to change them, or add new ones. For security reasons, the default passwords must be changed to secure CMX.
For CUDB systems deployed on a cloud infrastructure, refer to the infrastructure documentation for information about user authentication management. Implementing such policies is recommended.
5 System Audit Logging
This section describes how to perform a complete audit of the system for security purposes.
5.1 LDE Audit Logging
LDE authentication information is stored in the following file:
/var/log/<hostname>/auth
The file includes information on logging attempts and user creation operations.
Security events are collected to a separate dedicated log file stored at the following location:
/var/log/sec_events/security_events.log
For more information on security log events, refer to CUDB Node Logging Events.
5.2 Switch Audit Logging
For CUDB systems deployed on native BSP 8100, SCXB is configured to log events related to the following event groups:
Refer to the BSP 8100 CPI documentation for more information on switch logging.
For CUDB systems deployed on a cloud infrastructure, refer to the infrastructure documentation for information about user infrastructure audit logging.
5.3 Router Audit Logging
For CUDB systems deployed on native BSP 8100, consult the next level of maintenance support for information on the security management of security audit for CMX.
For CUDB systems deployed on a cloud infrastructure, refer to the infrastructure documentation for information about user infrastructure audit logging.
6 Certification Authority
The TLS configuration of the CA is centralized in the CudbSystemSecurity class. Configure the certificate list for CAs in case an application offers TLS capability for secure communication.
| Note: |
CUDB supports SSL for backward compatibility reasons. However,
using this protocol is heavily discouraged due to its known security
breaches. Instead, only the latest TLS version is recommended. |
The functions currently supporting TLS are as follows:
CUDB supports the storage of CA certificates (refer to the online resource of the OpenSSL Project for more information).
Perform the following steps on each node to set the certificate list for CAs:
Steps
After This Task
Instructions on public certificates and private key deployment are provided in the sections describing the configuration of the available security features (Configuring Secure Database Replication, Configuring Secure Notifications, Configuring LDAP Front End Security, Configuring Secure CUDB OAM Centralized Authentication System Support, and Configuring Secure Centralized Security Event Logging).
Periodically, the file containing the list of certificates for trusted CAs might be updated for security reasons. If that happens, copy the updated file to a persistent file system, and configure the file name as described in the procedure above. When changing the CA file, use a different file name than the previous one.
| Note: |
Certificates cannot be removed once added. However, certificates can be changed by adding
a new certificate. |
8 Configuring Secure Database Replication
Secure database replication is a system-wide procedure involving several nodes.
Database replication traffic can be secured between master and slave replication servers. Execute the following steps to activate SSL/TLS (Secure Socket Layer / Transport Layer Security) master replication server authentication and traffic encryption.
Steps
After This Task
Repeat the above steps for each CUDB node in the system. Slave replication servers reconnect to the master replication servers, establishing the secure channel in this way.
9 Configuring Secure Notifications
Configuring the secure notifications is a system-wide procedure involving several nodes.
The security configuration of notifications protects traffic confidentiality, and guarantees secure authentication between client and server. Execute the following steps to activate SSL/TLS traffic encryption, with client and server-side authentication.
9.1 TLS Configuration
Secure notifications require that the CA signing the SOAP server certificate is included in the recognized CA list. See Certification Authority for more information.
Typically, authentication scenarios are client-side: only the client authenticates the server. However, mutual authentication can also be configured: in such cases, the server also authenticates the client.
To configure secure notifications, provide a TLS key and the required certificates, then configure the file paths (no path is configured for these files by default). CA certificate is mandatory for the CUDB SOAP client to be able to check server identity. In case of mutual authentication, the server authenticates the client by providing a CUDB SOAP client public certificate and private key.
Perform the following steps to configure TLS authentication in CUDB:
Steps
After This Task
If client-side TLS certificates are to be changed for security reasons, repeat the procedure above and make sure to use different names for the TLS certificate file and the corresponding private key file than the ones used previously.
If notifications are running on secured connection, the TLS certificates and keys might be periodically updated for security reasons. If this happens, copy these files to a persistent file system, and configure the paths as described above. Change file names to apply the configuration.
| Note: |
Certificates and keys cannot be removed once set. However, they can be changed by setting
a new certificate or key. |
10 Configuring LDAP Front End Security
Configuring LDAP FE security is a system-wide procedure involving several nodes.
The LDAP FE authentication and traffic confidentiality can be protected by configuring an SSL/TLS security layer for communications between client and server. In case SSL/TLS is not configured or not available, the SASL can be configured instead. This enables the client to send the hash of the password to the server during authentication, protecting password confidentiality in the network in this way.
10.2 Configuring TLS for LDAP Front End
To configure secure LDAP FE over TLS, a CA certificate, a public certificate, and a private key must be provided in a directory with persistent mount point. For example, certificates can be stored in /home/cudb/security/config/certificates/ldapfe/, while the keys can be copied to /home/cudb/security/config/keys/ldapfe/.
After the files have been copied, configure the file paths, as no default path is configured for these files.
Steps
After This Task
If the LDAP server TLS certificates must be changed for security reasons, repeat the procedure above, but make sure to use different names both for the TLS certificate file and for the corresponding private key file than the ones used earlier.
| Note: |
Certificates and keys cannot be removed once set. However, certificates and keys can be
changed by setting a new certificate and key. |
10.3 Configuring Secure LDAP Proxy
To configure the secure LDAP proxy, perform the following steps:
Steps
Results
| Note: |
Connections opened towards LDAP FE are lost during TLS proxy configuration, since the
LDAP FEs are restarted to reload the configuration. |
11 Configuring Secure CUDB OAM Centralized Authentication System Support
The CUDB OAM Centralized Authentication System Support function supports connection to remote LDAP authentication servers with TLS enabled or disabled. If TLS is enabled, the following TLS certificates are required:
The function supports server side certificates only, and not client certificates. If TLS is set to enabled, the following server and client side requirements must be kept:
The same CAcert file that is used to sign the server certificates must also be stored on each CUDB node, under /cluster to be available from all the blades.
The nodes must be configured to use CAcert by setting the tlsCaCertificatesFile attribute located under the CudbSystemSecurity class to the full path of the file containing a list of certificates for trusted Certificate Authorities (CAs) and CAs that signed the certificates stored in a CUDB node. For more information, refer to the Class CudbSystemSecurity section in CUDB Node Configuration Data Model Description.
Refer to the Object Model Modification Procedure in CUDB Node Configuration Data Model Description for more information on all the steps required to modify the object model (for example, on using the applyConfig administrative operation to activate the changes).
As this model attribute is shared with notifications and LDAPs to set a CAcert for the CUDB node, the file can already exist in some cases, and may not contain the required new server CAcert. To solve this situation, add the new required CAcert content to that file, appending it to the previous content (the file can contain more than one CA). See Certification Authority for more information.
Because the client does not have its own certificates, remote LDAP authentication servers must be configured to not require client certificates. For example, in case of OpenLDAP remote servers, TLSVerifyClient can not be set to demand.
For more information on configuring TLS, refer to CUDB Node Configuration Data Model Description..
12 Configuring Secure Centralized Security Event Logging
The Centralized Security Event Logging function can be configured to send logs to log servers over TCP either with using TLS encryption, or without it. TLS is automatically enabled if the key, the public client certificates, and the CAcert are all set in the configuration model. These components are configured with the following configuration classes:
If any of these three attributes are not set, TLS will be automatically disabled, and logs will be sent without TLS encryption.
Enabling TLS on the client side requires the server to also have its own certificates set on its config file. The server also needs to have a private key and public certificate files that are different from the client ones, along with a CAcert. That CAcert, however, must be similar on the client (that is, on the CUDB node) and on the external log server, so that it can be used to sign all client and server certificates.
| Note: |
CAcert is set with the tlsCaCertificatesFile attribute of the CudbSystemSecurity class, which is also used to set CAcert for other CUDB applications
that also use TLS. The file can contain more than one CA: therefore,
in case the attribute is already set to a CAcert file for other applications,
add the new required CAcert content to that file by appending it to
the previous content. See Certification Authority for more
information. |
An extra level of security can also be added to ensure that the CUDB node connects only to the proper log servers. By configuring the optional logServerName attribute of the CudbLogCertificates class with a name or a regular expression, the CUDB node connects and sends its logs to an external server only if the certificate of the server was created with the specified name or pattern (specified with the Common Name field when generated). By default, that attribute has a value of “*”, which means it does not filter any server name.
12.1 Examples of Using Secure Centralized Security Event Logging
This section provides examples on using Centralized Security Event Logging with and without using TLS.
12.1.1 Using TLS
The function is set up with the following example steps:
Steps
Example 7 Example of rsyslog Configuration File on the Remote Server
$ActionFileDefaultTemplate RSYSLOG_TraditionalFileFormat $DefaultNetstreamDriver gtls $DefaultNetstreamDriverCAFile /etc/tlsCerts/ca.pem # CAcert file $DefaultNetstreamDriverCertFile /etc/tlsCerts/server-cert.pem # server public certificate file $DefaultNetstreamDriverKeyFile /etc/tlsCerts/server-key.pem # server private key certificate file $ModLoad imtcp $InputTCPServerStreamDriverMode 1 # run driver in TLS-only mode $InputTCPServerStreamDriverAuthMode x509/name # authenticate by hostname $InputTCPServerStreamDriverPermittedPeer * # accept connections of clients with certificates generated with any name $InputTCPServerRun 2999 # listen on tcp port 2999 *.* /etc/testingTLS # destination of received logs
After This Task
After the above steps, logs will be sent to the external server encrypted with TLS. Refer to CUDB Node Configuration Data Model Description for more information on the affected configuration objects and attributes listed above.
| Note: |
The InputTCPServerStreamDriverPermittedPeer parameter is set to
“*” on this example. This means that the clients can have
certificates generated with any name. If the parameter is set to a regular expression
containing a name, then it establishes connections and accepts logs only from clients that
have certificates generated with a Common Name which matches that
regular expression. For example, if set to CUDBlogClient*, a client with a certificate-created setting Common Name of CUDBlogClient1 will be allowed, while others not matching the specified pattern will not. If this extra level of security is not needed to filter log sources, then set the parameter to “*” as shown above. This setting is similar to the logServerName attribute of the CudbLogCertificates class, as described in Certificate Generation. The difference is that this is a server-side setting instead of a client side configuration, so it filters clients instead of servers. In this example, the log server is started with following parameters: rsyslog -c 5 -n -f /etc/rsyslog.conf |
12.1.2 Not Using TLS
The function is set up with the following example steps:
Steps
Example 8 Example of rsyslog Configuration File on the Remote Server
In this example, the log server is started with following parameters:
rsyslog -c 5 -n -f /etc/rsyslog.conf
$ActionFileDefaultTemplate RSYSLOG_TraditionalFileFormat $ModLoad imtcp $InputTCPServerRun 2999 # listen on tcp port 2999 *.* /etc/testingRemoteLogging # destination of received logs
After This Task
After the above steps, logs will be sent to the external server. Refer to CUDB Node Configuration Data Model Description for more information on the affected configuration objects and attributes listed above.
13 Other Security Recommendations
Besides the security features outlined in this document, It is strongly advised to also observe the following security recommendations:
14 Privacy
This section contains privacy-related statements regarding the CUDB system.
14.1 Notice
CUDB may store personal information, and may impact the right to privacy of the data subjects (that is, subscribers) whose data is stored. The specific data items to be stored depend on the application(s) using the CUDB system.
When operating the CUDB system as a data controller, ensure that personal information is stored in a fair and lawful manner, and in accordance to the local data protection regulation in effect. This can be achieved by providing notice to the subscribers about the privacy policies of the operator, for example at the moment of establishing the subscription.
It is also advised to provide comprehensive and understandable information to subscribers prior to, or at the time of collecting the personal information.
14.2 Consent
Reference List
- CUDB Node Network Description
- CUDB Users and Passwords 3/006 51-HDA 104 03/10
- CUDB Node Configuration Data Model Description
- CUDB Node Logging Events
- CUDB Node Preventive Maintenance
- CUDB Virtual Infrastructure Requirements
- CUDB Glossary of Terms and Acronyms
Other Documents and Online References
- OpenLDAP Software 2.4 Administrator's Guide
- OpenSSL Project http://www.openssl.org/
- An Approach for Using LDAP as a Network Information Service. IETF RFC 2307 https://tools.ietf.org/html/rfc2307