Security Best Practices
Security has been a strong focus in the design and development of Sage X3. The solution has been audited and certified by an external authority for safe operation in the Cloud.
A security policy is always compromised by its weakest link. It is therefore critical to pay attention to the security of your system, and to use all available tools for this.
This document summarizes what you should pay attention to when implementing Sage X3.
Customer details, financial records, staff information – you probably store a lot of sensitive data using your business software. It might be stored on your own servers if you have in-house systems, or outside your business if you use cloud computing services.
You get maximum security for your data without any action if you use Sage X3 Cloud. However, if you choose to install Sage X3 as an on-premise instance, or if you host it with a non-Sage managed cloud provider, there are a few rules to follow.
Wherever your data is, it is important you take a multi-layered, industry-proven approach to keeping your data where it belongs and as secure as possible. This document reviews the main controls you should implement to secure your data.
Sage X3 is a Web application that can be accessed using an http or https connection. Although http is available, we recommend you always use https for production instances, especially if your Sage X3 instance is accessed from the public Internet.
Make sure you change the default Sage X3 Administrator password to a strong password after the application setup. Ideally, it should:
Sage X3 supports several state-of-the-art services (such as LDAP and OAuth2) which should be used for user authentication on production instances, or on any instance holding sensitive data. Refer to the Sage X3 guides on setting up advanced authentication for more details.
We do not recommend using basic authentication (user/password) except on implementation or test instances. Even then, make sure those instances do not contain any sensitive data as basic authentication exposes you to inside and outside threats.
Caution: A user account should never be shared to ensure traceability of user actions.
The servers that host Sage X3 components contain configuration files and other data vulnerable to inside threats. Administrators should be the only persons allowed to log in to the servers. Make sure you set up users for Sage X3 Administration with the appropriate rights to the relevant directories.
Caution: Do not mix Server Administrators with Sage X3 Administrators.
Sage X3 servers should be built using industry-standard guidelines (such as the Center for Internet Security benchmarks) which are freely available.
Use local firewalls on your Sage X3 servers to lock any IP port that is not needed for Sage X3 operation or user access. Typically, if all Sage X3 components are installed on a single server, Sage X3 only needs the http or https ports to function. For multiple-server installations, you need to open the ports (or ranges of ports) that Sage X3 components use to communicate with each other.
The architecture you implement is key to your security, especially if your system can be accessed from the public Internet. To connect your systems and make them available from the Internet, you have to decide:
This involves equipment such as:
The firewall is the guard at your DMZ’s "checkpoints".
Note: These recommendations only apply if you are setting up a Sage X3 instance that can be accessed from the public Internet. You do not need to set up a DMZ and external firewalls if you are using Sage X3 from your internal LAN only.
Sage X3 uses several components that communicate together through IP ports. The only port that actually needs to be accessed by users for Sage X3 to operate is the http or https port (8124 or 843 by default). All other ports can (and must) be protected from external access, especially if the server is accessible from the Internet. The MongoDB port (27017 by default) and the Elasticsearch port (9200 by default) are examples of ports that should not be available.
Ideally, your Sage X3 https port should not be reachable directly from the public Internet, but rather through a DMZ and reverse proxy, as shown in the example below:
Alternatively, you can expose the Web (Syracuse) server alone, with all ports protected except https, and with the strongest possible authentication service (not basic). All other servers should then be placed safely in your LAN.
Caution: Never open a server to the public Internet without filtering the ports using a firewall. Only allow the Sage X3 https port through.
Sage X3 supports several identity providers, such as:
This improves security by offloading the management of user credentials that do not transit through the ERP (when integrated with Oauth2 identity providers or with Sage ID). It also improves the user experience by providing a Single Sign-On (SSO) experience.
Note: You can securely store the credentials you generate in password managers such as KeePass.
You can use any of the authentication methods described above, but you should never use the basic authentication in production, as it is only intended for demos.
Once authenticated, users are connected to the platform with a user login account. Each user belongs to at least one group, and each group is associated with a role.
When logging in, the user can select the role to use among the list of authorized roles. This role is linked to a security profile which is associated with a level (0 to 99, 0 being the most powerful).
The security profile defines the privileges a user has on platform operations. Make sure you assign a set of roles with appropriate security profiles to each user. As the platform administrator, you can define as many roles and security profiles as necessary.
A security profile can grant twelve different privileges, of which the following are critical for security:
What we call a folder is the repository that contains business data related to one or more companies having one or more sites (each company is linked to a legislation code). A folder is identified as an endpoint on the platform. Groups specify the endpoints a user is allowed to connect to. This list is critical for security.
Caution: Make sure each user is only granted access to the appropriate list of folders.
A user who connects to the platform is identified by a user code in each folder. By default, the user code and the user login account are the same. However, it is possible to redefine the user code for each endpoint in the user administration page.
In each folder, it is possible to define access to the information at a very detailed level:
Thanks to these features, you can set up the access to critical data differently on each folder for a given user.
Caution: Make sure you maintain these rules over time. Keep them as simple as possible, without compromising the security policy you need to enforce.
For each folder, there is a main administrator user code. It is ADMIN by default, but you can change it by setting up the ADMUSR parameter. Only use this user code for tasks that require it.
As Sage X3 runs on multiple physical or logical servers connected through a server, the security of this network is very important. The best practices for network security are as follows:
Databases must be secured following the principles listed below.
The server on which the relational database is installed must not be exposed over the network.
Only the SAFE X3 server (application / run-time) and the report server can access RDBMS. Execution servers and report servers are proxies that get the data requested by external services.
Never set up the database connection to the platform with the database administrator account. This account is only required for some configuration steps, and it can be changed afterwards.
The servers on which the document database is installed must not be exposed over the network. Only the web server (node.js) needs access to the MongoDB database.
The servers on which Elasticsearch is installed must not be exposed over the network. It should only be accessible from the "node.js" servers. The Sage X3 platform sends the query to Elasticsearch with additional security filters, based on the privileges of the user. When you access the Elasticsearch server directly, you can bypass these security filters: this compromises security by returning all the relevant indexed data.
The filesystem security of the different servers should be implemented with the relevant tools (antivirus, network access security, etc.) at the right level. Make sure these tools do not cause performance issues. For example, avoid running a continuous antivirus scan on a database server.
On application and process servers, the SAFE X3 engine runs in a sandbox. This allows you to control the system commands that are launched, and the location where files can be read, created, modified, or deleted. This prevents malicious code written for the execution engine from running operating system commands (by using System instructions).
Setting up the sandbox is recommended, especially if you operate in a Cloud, or if the SAFE X3 code is supplied by external vendors.
Sage X3 is supplied with a developer workbench that allows bespoke development. This can bring additional security threats that you can address with the following best practices:
The SAFE X3 language includes ExecSql and Sql functions with an argument that can be evaluated. All data used to build SQL statements must be properly escaped.
This security issue can only happen when additional graphical components are added to the user interface. At the moment, the extensibility tool is only available for early adopters. Detailed security guidelines will be given to developers, but they are out of the scope of this document. A dedicated security audit will be done on additional components supplied by external providers to prevent this risk.
Sage X3 includes a set of tools that might be activated in production. This is a best practice after a period of operation, especially with the following tools:
Caution: Using some of these tools (especially the first two) can significantly impact performance. It is therefore recommended to use them only for a short period of time, and for a limited number of users, when applicable.