Network / Security Considerations

This page addresses components and characteristics of a typical Unanet installation. Unanet does not recommend the use of any particular configuration, but provides this information to assist you in your planning process.

Components and Characteristics of a Typical Unanet Installation

An external firewall between the Internet and the DMZ, configured to allow access via port 80 to the Unanet server

A Unanet server on the DMZ with:

A servlet engine (e.g., Tomcat)

Optionally a web server (e.g., IIS or Apache)

The Unanet software

An internal firewall between the DMZ and the internal network, configured to allow connections to the database server on the appropriate port (usually either 1433 or 1521) only from the Unanet server

A database server with either SQL Server or Oracle on the internal network

Multi-Web Server Considerations:

Should you decide to scale your platform for performance or redundancy reasons, consider running with multiple front end web servers. When doing so, keep the following in mind:

Keep all front end servers up to date regarding Unanet versions (including having them on the same point release)

Make sure your property file settings are consistent across the front end servers as well (unless you specifically want to have a setting different on a particular server).

Keep the server clocks synchronizedacross all front end servers.

When considering a load balancing solution for multi-front ends, you'll want to be sure to utilize a 'sticky' option (server affinity), that is, take measures to ensure that when a user is serviced by a particular server, they stick with that server. This is necessary for certain features in the system, for example, when you attempt to export a file, the temporary file is created on a particular server and thus you'll want to make sure that the user's subsequent request to download that file is serviced by the same front-end server.

Ensure email is configured on all front end servers

Ensure the scheduler is enabled on only one front end machine. You may consider disabling the scheduler via unanet.properties entries on all but one machine, such that controlling whether the scheduler is enable can be done via the UI on one front end server only. Having multiple schedulers running against the same database instance can produce unpredictable results.

Security Considerations in a Typical Unanet Installation

This section provides additional information on security.

Security considerations of setting up Unanet in DMZ or SSL

Securing your Unanet system should be treated the same as securing any webserver on your network.

If the webserver and the database server are the same machine, you may want to allow a connection to the database server only from localhost.

If the webserver and the database server are separate machines, the webserver should be the only machine configured to communicate to the database server through the port specified. This would depend on the database platform used (SQL Server default 1433, Oracle default 1521).

Setting up your Unanet system in a DMZ

If a hacker were able to break into your webserver, it would be possible for them to see your database.properties file. If they had the ability to get that far, they would be able to see the password that is set for your database. Thus, the database.properties file should have the minimal permissions set for the servlet engine to read the file. You may want to configure SQL Server such that the Unanet login ID (e.g., "unanet") can only access the unanet database and no other database on the SQL Server machine.

Setting up your Unanet system to use SSL

Some points to think about when considering the usage of SSL:

Additional cost obtaining and maintaining an SSL certificate

Increased overhead will result in a slight performance reduction

Using SSL may not provide any protection against a compromise of the machine. This is especially true if port 80 is still open.

If your site is to be configured for exclusive access via SSL, you should enable the unanet.cookie.secure for added security.

Security Note: Usually, the reason for encrypting data is to avoid having hackers sniff packets going across the internet connection.