When developing and testing software, Jedox carefully addresses all aspects of the so-called triangle of information security:
- Confidentiality is the property of preventing disclosure of information to unauthorized individuals or systems. Confidentiality is necessary for maintaining the privacy of the people whose personal information a system holds. The Jedox system will never expose the customer’s data. Furthermore, a properly configured Jedox system will not only prevent unauthorized access but also allow for granular access to data (up to cell level).
- Integrity means that data cannot be modified without authorization. The Jedox system will never alter customer data on its own.
- Availability – for any information system to serve its purpose, the information must be available when it is needed.
Furthermore, all Jedox developers are fully aware of and develop according to principles of the Open Web Application Security Project (OWASP).
The following list is not intended to be a comprehensive list of hardening tasks for the Jedox environment, and Jedox may add to the list over time:
- Jedox software consists of multiple components. Install only the components you really need in the project. Do not install portions of Jedox that are not necessary for running a project. Not only does this reduce the risk for potential attack, but it also reduces the number of resources used, improving the performance of the Jedox system.
- The Jedox setup will install demo data that can help you understand how Jedox works. This data includes:
- OLAP DBs: Demo, Biker, fgrp2 ,rgrp2, modified system db (no demo users)
- ETL samples: ..\etlserver\samples\* , ..\etlserver\files\*
- SVS Samples: ..\svs\sample_scripts\*
- Jedox web files: ..\httpd\app\docroot\pr\jedox\* , ..\storage\h1-Demos
- Excel demos: %SHAREDDOCS%\Jedox\* (Dimension templates also)
You can opt out of installing this demo data. On the first run, un-check “Install Demo Data”:
When unchecked, no demo content will be installed. On successive installs, make sure “Overwrite Demo Data” is not checked.
These options are also covered in unattended installation; the option is called UpdateDemoContent=true/false in config.inf.
- If you are adding your own code to the solution, make sure this code follows the same rules as those above.
- If you are adding your own PHP code, make sure you are using Jedox Web API and adding a check for a valid session and/or user.
- If your code is using third-party libraries, make sure those libraries are up to standards, follow same rules, and are up to date.
- If you are using SVS and SSO, make sure SSO scripts are not “too open”, e.g. make sure there is no “allow all” access in those scripts.
- Use the open_basedir PHP directive whenever possible (Apache, Spreadsheet Server, SVS).
- Use CFG_DISABLE_AUTOCOMPLETE = true config directive to disable the autocomplete feature of the web browser on the logon form.
- Use CFG_HTTP_HOST = <HOSTNAME> config directive to explicitly set hostname value on the target host and “guess” it from $_SERVER[‘HTTP_HOST’] variable.
- Use CFG_HTTP_HDRS =  config directive to set additional HTTP headers. This can be used to enable Strict Transport Security or Content Security Policy. For example: CFG_HTTP_HDRS’, [ ‘X-MyHeader1: 123’, ‘MyHeader2: true’ ]. For more details, see Web Services and Configurations.
- Use CFG_COOKIE_SECURE in config.php to control cookie secure flags. You must also set the session.cookie_secure=On in ..\httpd\php\php.ini.
- Use CFG_ANTI_CLICKJACK_LEGACY = true in config.php to enable the anti-clickjacking settings.
- Jedox Integrator: restrict the capabilities of Groovy script execution in jobs or Transform functions of type “Groovy”. Details can be found in the article Jedox Integrator: Security of Script Jobs and Functions.
- Set up the failed-login-threshold in palo.ini to prevent any brute force login. See more in Configuring palo.ini for the In-Memory Database Server.
- Enable the password-pattern parameters to check the password complexity when the password ins changed or a new password is assigned to a new user. For more details, see Configuring palo.ini for the In-Memory Database Server.
A chain is no stronger than its weakest link
Securing data is an important part of the power user/consultant role. One has to ensure that applications built on top of Jedox also follow all these rules.
Jedox software never exists on its own. It is part of a bigger ecosystem. Jedox runs on an operating system, on real or virtual hardware, and is incorporated into an existing corporate network (portal, SSO,…). Hardening Jedox alone will not make the system as whole secure if any other part of the system isn’t hardened too. Make sure the whole environment is hardened the same way Jedox is. Where applicable, all software components should be up to date, OS on the latest patch level, and antivirus software and firewall rules in place.
See also Jedox Security Overview for more information.