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 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 amount 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 solution, make sure this code follows 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 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.
- 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.
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.