在 2015年iDempiere全球会议 期间，Carlos做了一个关于安全的演讲，可以在Youtube上观看该演讲视频。
- 在系统配置（SysConfig）中配置 ZK_ROOT_FOLDER_BROWSER
- 散列密码 （如果没有使用散列密码，需要加密 AD_User.Password 和 AD_Password_History.Password列)
- 加密数据库中包含密码的所有列 (如果已经使用了散列密码则不需要加密AD_User.Password 和AD_Password_History.Password列)
- 更改用户SuperUser, System, GardenAdmin, GardenUser和WebService的缺省密码 仅iDChina：建议更改SuperUser, System, GardenAdmin, GardenUser和WebService的用户名称
- 创建新租户后更改默认密码 (在初始租户设置中，可以选择默认情况下不分配密码以提高安全性)
浏览器(chrome, firefox, safari, ie, opera)
proxy_set_header X-Forwarded-Proto $scheme;
代理WEB服务器 (nginx, apache)
VPN (openvpn, cisco)
我们有一个被广泛使用的REST插件 widely used REST plugin ），通过该插件可以在iDempiere上启用REST WEB服务。由于该插件功能过于强大，不建议公开。 REST Web服务的使用取决于角色和用户配置，它可以执行特别的查询和CRUD操作、可以访问所有的表。
还有一些第三方插件提供WEB服务，例如ADAXA_Mobile（已弃用）或者BX Service Vaadin Mobile。
服务器操作系统 (linux, windows, mac)
NEVER install iDempiere with root, this is a common advice for any software that exposes services to the internet. If somebody - for any reason - could exploit iDempiere to gain access to the operating system, they'll have the permissions from the user that runs iDempiere, so if you run it with root, they'll have complete access to the server. For the same reason it is recommended that you consider carefully which permissions and access to give to the operating system user that is running iDempiere.
Many developers use iDempiere in Windows for development, but very few people run iDempiere in production using Windows, some of the support scripts (f.e. applying migration scripts) are just developed for Linux, so you would need to do some tasks manually.
Linux is the preferred option.
nginx, apache can be configured to allow access to clients that are authenticated with a client certificate
- There is a provision to customize the way to obfuscate/encrypt the password, or externalize it (avoid to save it on the server). Note externalizing the password protect against physical access (like stolen hard drive), but these passwords CANNOT be protected against a hacker accessing the live server, unless you sacrifice the ability to automate many things requiring manual intervention from an operator to provide some credentials.
database password encrypted in properties file
The database password on swing client is "encrypted" in a properties file, the problem is that the encryption algorithm is usually common and easy to decrypt, and even if you change it can be easily extracted from the jar files. There is the possibility of implementing alternative keys, algorithm or even classes to encrypt better the strings.
terminal server approach (nx, citrix, ts)
if definitely you are needing to use swing client is better to use it via a terminal server where you have control of the machines
- Be careful, jasper can read anything over the database, just install trusted reports.
- Consider including in your jasper queries the security layer of iDempiere, like is included by MRole.addAccessSQL, like:
- Restrict to the organizations the user has access to
- Take into account AD_Private_Access and AD_Record_Access
If you need to give direct SQL access to other tools like jasper, odbc/jdbc connections to libreoffice, datawarehouses, ETL, talend, etc - better consider creating a read-only user with access to preconfigured views. The views can contain the security filter for AD_Client_ID
iDempiere supports postgresql and oracle. Most implementations run on postgresql, however oracle support is good and permanently maintained.
By default the installers create a database user (usually named adempiere) with complete DBA/SUPERUSER permissions, this is, this user have ability to do everything on your database. It is possible to install iDempiere with a less powerful user, but you need to configure it manually
When creating a new tenant, by default iDempiere assign a weak password which is the same as the user name. It is recommended better to disable the flag "Set Initial Password" and assign secure passwords to the new users manually after the tenant is created.
- it is recommended to configure the security using access, not menus (menus don't restrict access - user still can zoom)
You can configure organization access in the role window.
You can configure specific menus for roles, however it is important to note that the menu is just visual, the users can still navigate to the windows they have permissions using the zoom function.
db access (table, column)
You can configure / restrict access for roles using the Role Data Access window
private record & record access
To configure record access you must use the "Lock" button on the toolbar. This button can make a record:
- private: just visible for the user who locked it and the roles allowed to see locked records
- restricted: just visible for certain roles
NOTE ON ADVANCED ROLES
The advanced roles are intended for IT on tenant side - do not give an advanced role to an end user. You must consider advanced roles as SuperUser, they have access to all security holes.
Also you must consider SuperUser as if it has access to the operating system user used to install iDempiere on the server.
In other words, the advanced roles have access to iDempiere features that can be easily exploited to gain access to SuperUser in the application, to the database as a DBA, and to the operating system as the user that run iDempiere server.
iDempiere comes with 5 users by default with very easy and insecure passwords. It is a mandatory first step to change these passwords on: SuperUser, System, GardenAdmin, GardenUser, WebService
sensitive fields (like passwords)
It is recommended to encrypt sensitive data, iDempiere has a mechanism to encrypt that can be easily enabled/disabled per column.
To encrypt data in the database, iDempiere uses an algorithm and a key that is exposed in the open source code. So, is not very secure.
In order to encrypt sensitive data - as recommended - it is better to configure a proper keystore, this can be achieved setting idempiere.ks and idempiere-ks.properties in the server. As of today, there is no documentation about how to use this feature, check the class DefaultKeyStore for more defaults about the implementation.
It is absolutely recommended as one of the first steps of your installation to use the hashed passwords feature, you can find more information at NF1.0 HashedPasswords. These passwords are very secure as they are not encrypted, but hashed, so it can be seen as a one-way encryption, for example even if somebody obtain the hashed passwords with direct access to the database, they cannot go back and figure out the password.
It is recommended to setup a set of password rules for your users. You can find more information at NF1.0 PasswordRules
iDempiere provides features to manage automatic user locking on certain events. It is recommended to setup these features. You can find more information at NF1.0 User_Locking
The SysConfig key ZK_ROOT_FOLDER_BROWSER defines the folder that is shown when clicking on a Folder type field.
As this folder can be exploited to get information from the server, it is recommended to set this SysConfig key to a secure folder in your server that does not contain any sensitive information.
You can trace MFA failures in the file AuthFailure.log, it is recommended to setup a mechanism to inform users when MFA failures happen, it can mean that their password was leaked.
tracing possible attacks
Every trial to login with a wrong password, or an MFA failure is recorded in the file AuthFailure.log
external tools to deny service on attacks
You can use tools like denyhosts to ban IP addresses that are testing passwords based on the AuthFailure.log file