Keeping Dangerous People Away from Physical Servers

If you’re hosting your IT infrastructure on-premise or off, ensure that all server rooms are restricted and guarded. For instance, as a data center provider we go to great lengths to ensure that only authenticated and trustworthy personnel are allowed into the facility. And that even trustworthy people are closely monitored so that customers can be assured their actions won’t have negative repercussions.

Beyond just monitoring and protecting the physical environment, it’s obviously important to monitor and audit user access. This can be done through logs such as network services logs, website access logs, database server logs, and operating system logs. These should ideally be stored in a segregated area that are protected from tampering, and be monitored and checked regularly for unusual behavior that could be evidence of an attack.

Limiting Access Through Permissions

File and network services permissions play a vital role in security because malicious users can exploit privileges to execute malicious code or steal data. It is therefore important to always assign the least privileges to each specific network service, as well as each user.

Manage Anonymous User Permissions

Authenticated users have a user account on the server and can be provided with specific privileges, however, there is often an option of accessing a server via a guest account as an anonymous user. In some cases, you may want to disable this account. In other cases, such as with a public-facing website, these anonymous users are your site visitors, and they should be assigned a minimal permissions.

Don’t Allow Employees to Share Accounts

Even if you think two employees should have the same server access, multiple people should never share accounts. Authorized individuals should be granted their own accounts so that their activities can be audited separately. To make permissions management simpler, they can often be put into a group or role with appropriate privileges. And remind employees never to share login and password details.

Distinguish Between Development, Testing, and Production Environments

Today, we often have separate development, testing and production environments. This makes it so that instead of developing and testing applications directly on the production servers where early-stage applications (with vulnerabilities that could easily be discovered and exploited by a malicious user) they have a development environment where private resources that can only be accessed by developers.

Ideally, development and testing of web applications should always be done on servers isolated from the internet, and should never use or connect to real life data and databases. Keeping production and testing in an internal network keeps privilege limited only to those who should have access.

While it might be clear that the company’s accountant shouldn’t have access to, say, development servers, there is considerably more debate around whether developers should have full access to production servers, which will be discussed in the next section.

Limit Developer Access to Production Servers

Years ago, StackExchange’s director of site reliability Kyle Brandt made an excellent case for the fact that developers generally shouldn’t have full access to the production server environment.

This might be frustrating for developers who might see sys-admins as a bottleneck, but there are some really good reasons why developers shouldn’t have direct access, and wouldn’t want it anyways.

For one, if administrators must install the code and make changes, this forces developers and sys-admins to communicate. If the sys-admin isn’t quick or knowledgeable enough to respond to requests from developers, then this is a problem with the sys-admins not with production server permissions.

Also, by making sys-admins install code, it encourages developers to create an install or release process that’s easy and effective, giving sys-admins a simple way to install the software. And this well-packaged code means that the production environment can be rebuilt quickly and properly in a disaster recovery situation.

This should also make developers happy since they get to write new code as opposed to spending time deploying and installing code. Of course, they would also not have to think about account privileges, file permissions, web server configuration, which should be a sys-admin responsibility.

If an error happens (even at midnight), the system administrator will be the one responsible for any changes that are made. This maintains order, and means that developers don’t step in and commit quick changes that hinder the troubleshooting effort. It’s important that the sys-admin is in control of the situation. They can ask for assistance from developers when it’s needed, but they’ve got the ultimate control when it comes down to server changes.

What you’re aiming for is to build a process that lets people focus on what they’re good at. This should result in a more reliable and secure production environment.

It’s important to remember that limiting access to individuals (including staff members) doesn’t mean they’re unimportant – it just means that their role in the organization is clear.

Make Sure New Accounts are Setup the Right Way

It’s important that organizations have clear policies around how they handle new accounts – including an approval process and a procedure for adding users to Access Control Lists for applications and storage spaces. Make sure those users who are able to create accounts are well versed in how to properly give new users the permissions they need to do their job, but nothing more.

If you deal with third party suppliers, your organization might want to have a procedure in place to authorize those providers and ensure that they don’t create more security weaknesses. In general, external suppliers should have minimal access to servers.

Make Sure Connections are Secure

To ensure that remote user connections to servers are not hijacked, it’s important that sessions are encrypted and automatically locked after being inactive for a period of time (say, 10 minutes) before requiring re-authentication.

Disable and Delete Unused Accounts


Unused accounts with privileges can be used by an attacker or even a former employee to access a server. It’s a good idea to do an audit of all accounts on the server, and consider deleting ones that appear to be unused. We’d recommend first disabling an account to see if this causes any problems before deleting it.

Embodying The Principle of Least Privilege

It’s tempting to think that you’re empowering employees by giving them server privileges, yet not being careful about who has access to servers can endanger the organization, and make it difficult to trace problems. And at the same time, good permission management reinforces organizational roles and ultimately makes for a stronger, safer and more resilient organization.

We highly recommend you periodically take a look at your IT permissions and attempt to truly understand who has access to what – and, especially, what privileges can be taken away.