Skip to content


This page is to be read when planning an installation which has security requirements, implied or explicit. This document is to be used by presale, installation technicians, customers, etc. Taking these considerations before installing may save time/money and prevent misunderstandings.

This document provides help to identity security requirements which:

  • impact on architectural choices; may require additional hardware / software.
  • requires processes which may take more time than expected and cause delays, such as certificate request processes.
  • has impact on operating system choice.
  • has impact on third party software configuration.
  • which may be incompatible with some IFS components.

Network architecture

The network architecture and its impact should be considered. Are all or part of the application exposed to internet? IFS Cloud has the capability to listen to two system urls. One system url could be used to access the system from withing the corporate network, normally with no end-point restrictions. The Second URL could be used to expose some or all end-point to public internet (with optional IP allow listing in the external fronting proxy)

For more information of how to expose IFS Cloud on the internet see Exposing IFS Cloud to the Internet.

For security (and performance) reasons, you should place all or most IFS Applications servers in the same server environment, connected by a network with low latency and great bandwidth. Utilize firewall rules to allow only necessary communication and preventing forged packets will increase security a substantially.

Secure network communication considerations

To secure networks, network security protocols like TLS and HTTPS are used. These protocols protect communication from alteration and eavesdropping. TLS may be applied between server and client.

Installation of network security protocols requires Digital Certificates, which are obtained from a Certificate Authority (usually a commercial vendor). It is a good idea to request a certificate in due time, since a Certificate Authority may require weeks to process a request.

Consult Secure Communication and Certificate handling for further information.

Auditing considerations

Audit trails such as log files and audit tables are essential for keeping track of what is happening in the system, which often is required by policies and laws which applies to various enterprises, markets and regions.

Audit logs serve two purposes. One is to keeping track of normal users do using normal functionality, for example "It was user XXX who transferred the money".  This type of auditing is useful to detect questionable actions (such as embezzlement) by users, or to just keep track of how and why changes in the system is made.

Other audit logs serve to detect suspicious use. For example, it is possible configure audits which may indicate that a single person is using several user accounts. Another example is to make use of access and error log files to search for evidence of attacks against web servers.

Identify which Auditing demands exists, and configure IFS, Oracle and/or third party software to perform Auditing. Keep in mind that some auditing data, such as web server logs, may not be configured to automatically delete old information. Processes to manage log files should be created, which may be manual or by third party software.

Consult Auditing Guide for further information.

Authentication & Authorisation considerations

Read more about Access Security