Access control (#2: the signer)

Written by Roland van Rijswijk in category: Architecture, Policy, Procedures, Security

In a previous post we addressed access control on the network level. This post will focus on access control in various ways on the signer machine.

User access control

The most basic – but nevertheless important – way of controlling access is by determining which users need access to the signer machine and the potentially sensitive data stored on it. In our case, this is limited to two categories of human users:

  • System/application administrators – these need to access the system to keep it up-to-date and to troubleshoot potential problems
  • Backup officers – these need to access the system in order to tell OpenDNSSEC that a backup of key material has been performed (this is necessary before newly generated keys are taken into production, more on that in a later post)

Human users can only access the machine through SSH or on the console.

Apart from human users, there are also ‘application’ users. In our setup we have two application users:

  • SURFdomeinen – the SURFdomeinen system needs to be able to tell the signer if a new zone needs to be signed and other administrativia. This is achieved by having a user account with a very limited shell that is only accessible over SSH. The SURFdomeinen system can then interact with the signer using a very limited set of commands. Authentication of this user is achieved using public key authentication.
  • Backup users – a nightly backup of the signer system is performed using rsync; a special backup user requires access in order to be able to do this (more on backups below).

Protecting sensitive data on the signer

Most data stored on the signer is not sensitive in our case, but there is one piece of information that warrants special attention: the user PIN for the HSM.

Courtesy of Wikimedia commons

The user PIN grants access to all the key material stored on the HSM and can thus be misused to forge signatures. Although access to the signer is highly restricted, there is one other problem that we are facing: an evildoer could inspect the disks of the signer machine (if he or she managed to gain access) and in our case this problem is very real. We run our signers as virtual machines, which are running on large virtualisation platforms with centralized storage. It is possible to access the VM’s disks from outside the virtual machine, making it very easy to snoop the user PIN from the disk.

To prevent this from happening, we store all configuration files that contain the user PIN in encrypted form. We use Red Hat Enterprise Linux on our signers. A special encrypted file system comes package with that, called ecryptfs. One of the best features of ecryptfs is that it allows you to do ‘overlay’ mounts. Thus, we can remount a directory, replacing the encrypted version by the decrypted version from a user’s perspective. The encrypted volume is protected by a strong, randomly generated passphrase.

Finally, we have created a policy, which states that the encrypted volume must not be mounted automatically, but instead the passphrase needs to be entered manually by a system administrator during activation of the signer.

Security includes backups

One final note: always keep in mind that security includes backups. This has two sides to it:

  • Backups ensure that you can restore your system in case of catastrophic failure or hacking
  • Backups should never include sensitive data in the clear – thus – in our case – we must never create an rsync based backup that includes data from the mounted encrypted volume.