Security

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:

Read more about the domain Security

Contents

 

Expose IFS Applications on the internet

The recommended way of exposing IFS application on the internet is over a Secure VPN connection. IFS Application should normally not be exposed to the internet but be accessed over the company's intranet. If parts of IFS needs to be exposed to customers and partners, a VPN solution should be used if possible. If a VPN solution is impractable a reverse proxy can be used.  The reverse proxy must be configured with SSL / TLS / HTTPS and with rules that prevent other URL access than intended e.g. https://company.com/partnerweb/b2b/*.

Network architecture and DMZ considerations

The network architecture and its impact should be considered. A secure DMZ deployment requires firewalls.

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 SSL / TLS and HTTPS are used. These protocols protect communication from alteration and eavesdropping. SSL / TLS may 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 Configuring SSL / TLS / HTTPS 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 considerations

Single Sign On (SSO)

IFS supports Single Sign On for Web Client and Access Providers using Microsoft Integrated Windows Authentication.

Integrated Windows Authentication is a "super protocol" supporting Kerberos / NTLM / NTLMv2 / LANMAN authentication for strong authentication and Single Sign On.

There are some considerations with Single Sign On using Integrated Windows Authentication:

Consult Configure Single-Sign-On for further information.

Database authentication

LDAP authentication