This is part 1 of a series of posts on server security from Inversoft's 2016 Guide to User Data Security. 

Server Security

The first step to securing user data is to secure the servers you will be running your applications and databases on. The process of securing servers revolves around a couple of core guidelines:

• Use the least privilege possible
• Prevent direct access when it isn’t required
• Automate security checks and constraints
• Send notifications for all activity
• Identify users that can access the server

Server Architecture

In order to illustrate our thinking around server security, we need to cover what type of servers we are talking about. Because this guide is specifically about user data security, we will focus on applications that use a server-side component and a database to store and manage user data. This application will allow users to register, login and perform various functions. A few examples of this type of application are:

• A web application where a user can login, access their account and perform various functions
• A mobile application that communicates with the server to manage user accounts and user data

Now that we know what type of servers and applications we will be securing, let's take a look at the server architecture we used for our to-do application and the server architecture we recommend you use for your applications.

In general, you will want to separate your Database Server from your Application Server. While securing two servers instead of one does require additional work, it will give you the flexibility to control access to each server separately. This also means that if a breach does occur, the hacker will have a couple more hoops to jump through in order to gain access to your user data (we'll discuss this later).

On the Application Server, you will install the server-side code for your application. On the Database Server, you will install the database that you will be using (MySQL, PostgreSQL, Mongo, Reddis, etc). Depending on your needs, you can horizontally scale either of these servers. You will want to use the exact same configuration and access controls on each server to ensure consistency. DevOps is out of scope for this guide, but there are numerous tools available to create server images and deploy multiple instances of them. Similarly, there are many tools you can use to make a configuration change to all servers without having to log into each one separately.

Find our Github project here: https://github.com/inversoft/2016-security-scripts. This project contains a set of scripts you can execute from your local computer to secure a remote server.