Enterprise Content Management System Monitor 5.1 Security Considerations Revision CENIT AG Brandner, Marc

Transcription

1 Enterprise Content Management System Monitor 5.1 Security Considerations Revision CENIT AG Brandner, Marc

2 INTRODUCTION... 3 SSL SECURITY... 4 ACCESS CONTROL... 9 SERVICE USERS...11

3 Introduction Overview This guide intends to address the main settings of the ECM System Monitor application which are of interest in targeting a secure monitoring environment, whereas this guide will not discuss monitoring or auditing the security status of your ECM environment using ECM SM. If you want to notify us about mistakes or improvement suggestions, either talk to us in the IBM developerworks forums 1 or send us a mail to ECM.SystemMonitor@cenit.com. Disclaimer The content of this document is based on ECM SM in version The descriptions and guidelines in this document are for informational purposes only. Up-to-dateness, content completeness, appropriateness and validity for all possible scenarios cannot be guaranteed. All information is provided on an as-is basis. The author is not liable for any errors or omissions in this document or any losses, injuries and damages arising from its use. If you are planning to setup or configure ECM SM or to adjust an existing installation, it is absolutely necessary to take into account current security whitepapers, release notes and announcements from the official IBM ECM System Monitor product documentation website June 23 rd, 2014 ECM System Monitor 5.1 Page 3 of 11

4 SSL Security Overview Enabling SSL security for the transfer protocol is one of the basic measures to secure the ECM SM monitoring environment. All access attempts to the ECM SM Web UI (by default running on port 23990) are then only establishable via HTTPS. Basically there are two options to configure SSL for the ECM SM Server: Using a self-signed certificate Using a certificate signed by a CA (certificate authority) In enterprise networks typically there exists a PKI (Public Key Infrastructure) which is capable and responsible of issuing, distributing and validating digital certificates. Chapter Using a certificate signed by a CA will therefore explain the steps necessary to integrate the ECM SM Server into this infrastructure. Using a self-signed certificate Configuring HTTPS using a self-signed certificate is the configuration entailing the smallest configuration efforts. The communication between the user s browser and the ECM SM Server will be encrypted, however the user has to confide in the circumstance, that is not verifiable whether the host claiming to be the ECM SM Server is authentic or not. The ECM SM Server will claim to certify its authenticity by delivering the a certificate to the browser, but as this certificate is only signed by the ECM SM Server itself ( self-signed ), and not signed by a enterprise-wide trusted certificate authority, a trusted communication in the purpose of a PKI is not possible. This will most likely result in the browser showing a warning message mentioning that the website cannot be trusted. A direct workaround to remove these warnings would be to import the ECM SM Server s self-signed certificate into the browsers truststore. This workaround solution will not be amplified any further, because it is for one thing not in the proper sense of a PKI and for another thing it is technically cumbersome to safely distribute the stand-alone certificate to all devices which might address the ECM SM Server Web UI in future. June 23 rd, 2014 ECM System Monitor 5.1 Page 4 of 11

5 Using a certificate signed by a CA To integrate the ECM SM Server into a PKI several steps are necessary to acquire the required certificates and properly import them. The described steps are confined to the ones to be conducted on the ECM SM Server, whereas the required steps to be done by the PKI are not explained, because the issuing of certificates is usually done by specialized administrators and organisations in enterprise IT departments. Further these steps only apply for installations based on the Jetty Servlet container (default setting in the installer), not to ECM SM Server installations based on Websphere Application Server. 1. Optional: Requesting a certificate from the CA without providing a CSR (Certificate Signing Requests) In case the designated CA offers provisioning of certificates without requiring a CSR (Certificate Signing Request) as input data, the CA will create a key pair valid for the ECM SM Server as well as an appropriate certificate for this key pair. Most likely the key pair and the certificate will then be delivered as a PKCS12 formatted package (e.g. ecmsm.p12 or ecmsm.pfx). The package s private key will replace the private key when the package is imported into a keystore in case the keystore already contains another private key. In case it is planned or required to provide a CSR to the CA, skip step N 1 and continue with step N Install ECM SM Server with HTTPS support 2 Choose the option to create a keystore (e.g. ecmsm_keystore.jks) and follow the directions given by the graphical ECM SM Server installer. 2 For additional information on the HTTPS configuration especially in the ECM SM Installer tool please consult the ECM SM Installation Guide. June 23 rd, 2014 ECM System Monitor 5.1 Page 5 of 11

6 3. Delete and re-create the previously automatically created keystore keytool -keystore ecmsm_keystore.jks -alias jetty -genkey - keyalg RSA Ensure to use the exact same name for the keystore file as used before in the ECM SM installer. Notice: If you plan to request a certificate based on the private key of the keystore you have just created, please ensure that the hostname and the Distinguished Names entered during keystore creation are compatible with those parameters required by the enterprise s certificate authority. 4. Optional: Requesting a certificate from the CA providing a CSR (Certificate Signing Requests) The returned certificate (e.g. ecmsm.pem) will be imported in the following steps. If you have accomplished step N 1 successfully, this step can be skipped. In case you skipped step 1 (Requesting a certificate from CA the without providing a CSR to the CA) it is now required to create a CSR from the ECM SM Server s keystore and to utilize it in order to request an appropriate certificate for the ECM SM Server from the CA. Generate a CSR (Certificate Signing Request) and provide it to the CA to receive an appropriate certificate for your System Monitor server host using the following command: keytool -certreq -alias jetty -keystore ecmsm_keystore.jks - file ecmsm_csr.csr 5. Import trusted CA certs into keystore For a Java keystore like the ECM SM Server uses it it is required to contain all certificates which are part of the key chain of the signed certificate we want to import. The Root CA certificates should be transferred securely to the ECM SM Server from the CA. If you know other HTTPS-secured websites or web applications whose certificates are based on the same key chain, you can obtain the required certificates using your browser from those pages. Most browsers provide a feature which allows you to show the certification path of a HTTPS webpage and also to export each of those certificates from the path. Use the following path to import those certificates: keytool -keystore ecmsm_keystore.jks -import -alias jetty -file <*.pem or *.cer certificate file> June 23 rd, 2014 ECM System Monitor 5.1 Page 6 of 11

7 6. Import ECM SM Server certificate signed by the CA into the keystore a. IMPORTING A PKCS12 PACKAGE keytool -importkeystore -srckeystore ecmsm.p12 - srcstoretype PKCS12 -destkeystore ecmsm_keystore.jks b. IMPORT A CERTIFICATE IN PEM FORMAT keytool -keystore ecmsm_keystore.jks -import -alias jetty -file ecmsm.pem Remarks on usage of keytool: Before configuring the keystore, verify that you are using the correct keystore file and the correct keytool binary when executing the commands stated above. This can be ensured by using the full paths of the binary instead of the short command names and by always passing the keystore path as an argument in every keytool command (-keystore). This is the case for the examples stated above. The keytool binary which should be used here is the one from the ECM SM Server s Java Runtime Environment (located in path <ECM SM Server install directory>/jre/bin) Importing the ECM SM certificate you should use the alias jetty. This is the case for the example commands stated above. Remarks on certificates: In case the CA delivers a new private key and a respective certificate in two separate files, follow the steps in chapter Loading Keys and Certificates via PKCS12 of the Jetty online documentation 3. To ensure that the Jetty server is able to access the keystore and the deliver the certificate to the clients, the password of the imported certificate needs to be same one as configuried in the ECM SM UI configuration. This password is initially configured during an the ECM SMinstallation and can be adjusted on fixpack installations or upgrade installations. In case changing the password using the installer mechanism is not possible, another possibility is to change the password of the import certificate. For a PKCS12 package this can be achieved using the 3 June 23 rd, 2014 ECM System Monitor 5.1 Page 7 of 11

8 keytool with the following command before importing it to the ECM SM keystore: keytool storepasswd all new <newpassword> keystore ecmsm.p12 storepass <oldpassword> storetype pkcsl2 June 23 rd, 2014 ECM System Monitor 5.1 Page 8 of 11

9 Access Control Password of default user It is absolutely necessary to change the default password of the admin user immediately after the initial installation of the ECM SM Server. The default admin user has extensive permissions on the ECM SM Server itself as well as on the connected agent systems. To change this password follow the steps listed below: 1. Log in to the ECM SM Web UI using the admin account. 2. Open the User Management console, listed under the menu Window > Consoles. 3. In the tree User Management expand node USERS 4. Doubleclick user admin 5. Enter a new password in field Password and re-type it in field Verify Password Caution: For security reasons it is not possible to reset the password of the user admin with another user than itself. Remote Execution Agent The ECM SM Remote Execution Agent (CALA_Rex) is an essential part of the ECM SM feature set. As it can be used to issue commands on the ECM systems it is installed on, access of unauthorized users or processes to the CALA_Rex functionalities has to be prevented. Other unexperienced users or attackers could using the built-in configuration tools accidentially or willingly modify the monitoring configuration, and compromise or damage the monitored ECM system. Therefore only selected ECM SM users should be permitted to use CALA_Rex functions. The following Functions (as they are called in the User Management) are related to CALA_Rex: June 23 rd, 2014 ECM System Monitor 5.1 Page 9 of 11

10 application cepest.archive cepest.script client_ip action file.exec file.read file.write To make this role part of another custom role or group definition, the predefined role cala_rex can be reused, as this one bundles all of the functions mentioned above Auditing Part of the User Management is a built-in Transaction Log which records every configuration change on the ECM SM Server and the attached agents. If named user IDs are utilized by the users to work with ECM SM, it is always traceable which changes have been committed at which point in time to any part of the ECM SM configuration (server-side and agent-side). The transaction log is only available to users with the role fsm_usermanagement permissions due to reasons of data privacy. For the reasons of disk space control, it is possible to constrain the retention time of transaction log records. This can be configured in the Database Cleanup Configuration console where either the number of total entries can be limited or a maximum age for entries can be defined: Maximum number of transaction log entries to keep Delete transaction log entries older than June 23 rd, 2014 ECM System Monitor 5.1 Page 10 of 11

11 Service Users When installing an ECM SM Agent on a monitored ECM system (based on a Linux/Unix operating system), the service user of the agent (also called technical user ) is defined during the agent installation routine. Choosing the correct user depends on two basic factors: The user must be permitted to access all data relevant for monitoring. The user should only have those permissions which are required to perform monitoring activities. In order to ensure that all access attempts of CALA_Rex and CALA will succeed, the technical user of the ECM application can be utilized. If possible, a separate monitorung user should be created for these purposes, that is having a set of permissions to read only the data relevant for monitoring. Using the root account to install and run the ECM SM agent software should be absolutely avoided! June 23 rd, 2014 ECM System Monitor 5.1 Page 11 of 11