Difference between revisions of "Data Encryption"
(→Data Store Encryption) |
|||
| Line 4: | Line 4: | ||
The major issue with whole disk encryption is that a reboot will require the entry of a password before the system is mounted. To be able to do this your provider would need to give access to the machine via a KVM, which allows remote access to a keyboard console as the machine boots. This is a non-standard setup and some providers may charge additional fees for it. | The major issue with whole disk encryption is that a reboot will require the entry of a password before the system is mounted. To be able to do this your provider would need to give access to the machine via a KVM, which allows remote access to a keyboard console as the machine boots. This is a non-standard setup and some providers may charge additional fees for it. | ||
| − | The significant benefit to whole disk encryption that if the machine is seized by outside parties they will have no access to the operating system or disk itself. | + | Advanced users using whole-disk encryption may set up the DropBear SSH daemon in their boot loader, which allows for the use |
| + | |||
| + | The significant benefit to whole disk encryption that if the machine is seized by outside parties they will have no access to the operating system or disk itself. This means that no data on the machine will be leaked in that eventuality. This also denies attackers the ability to modify most local system binaries to attempt to intercept passwords, provide backdoors or log user actions. | ||
<ol> | <ol> | ||
<li> | <li> | ||
| − | The [|Linux Unified Key System(LUKS)] also for both full and partial disk encryption | + | The [|Linux Unified Key System(LUKS)] also for both full and partial disk encryption. |
| − | An | + | An in-depth tutorial for LUKS setup can be found [https://wiki.archlinux.org/index.php/Dm-crypt/Encrypting_an_entire_system| here] and a simpler one can be found [http://www.hermann-uwe.de/blog/howto-disk-encryption-with-dm-crypt-luks-and-debian| here] |
</li> | </li> | ||
</ol> | </ol> | ||
==Data Store Encryption== | ==Data Store Encryption== | ||
| − | An alternative to whole disk encryption is to encrypt specific portions of the disk containing the most sensitive data that must be protected. | + | An alternative to whole disk encryption is to encrypt specific portions of the disk containing the most sensitive data that must be protected. Care should be taken to encrypt both data at rest (ie a database, MySQL etc.) and "scratch" or temporary data storage (search engine technologies such as Solr, Memcached data stores etc.). |
This removes the need for entry of a boot password on reboot but it does leave any elements of the disk not encrypted open to access if the machine is seized or compromised. | This removes the need for entry of a boot password on reboot but it does leave any elements of the disk not encrypted open to access if the machine is seized or compromised. | ||
| Line 20: | Line 22: | ||
<ol> | <ol> | ||
<li> | <li> | ||
| − | The tool [http://www.arg0.net/encfs| | + | The tool [http://www.arg0.net/encfs| encfs] runs in the user space and allows the creation of encrypted partitions. These partitions can be mounted once the system has been booted. The tool allows for very strict control over which users can access mounted information once a partition has been decrypted and is suited to applications where a specific user/process accesses the encrypted data. |
The encrypted partitions can be defined at variable sizes and the sensitive datastores and applications can be run from within them once the partition has been mounted. | The encrypted partitions can be defined at variable sizes and the sensitive datastores and applications can be run from within them once the partition has been mounted. | ||
| − | A guide for setting up | + | A guide for setting up <tt>encfs</tt> can be found [http://www.howtoforge.com/encrypt-your-data-with-encfs-debian-squeeze-ubuntu-11.10| here]. |
| + | </li> | ||
| + | <li> | ||
| + | The Linux kernel offers support for <tt>ecryptfs</tt> partitions. These partitions are mounted like any other local filesystem, but with the benefit of the device being encrypted while unmounted. These partitions are mounted like other filesystems and not in user space so they cannot be mounted by unprivileged users. | ||
</li> | </li> | ||
<li> | <li> | ||
| − | The LUKS tool can also be set to encrypted only specific partitions and mounted in a similar way to encfs. | + | The LUKS tool can also be set to encrypted only specific partitions and mounted in a similar way to <tt>encfs</tt>. |
</ol> | </ol> | ||
Revision as of 16:28, 18 May 2014
There are a number of options for data encryption for secure server hosting, however, for Shared Hosting or CPanel style hosts encryption options are very limited. For Dedicated/VPS hosting, administrator's have the option of encrypting the entire disk or encrypting portions where sensitive file data will be stored. We will explore both approaches, noting benefits and downsides for both.
Whole Disk Encryption
The major issue with whole disk encryption is that a reboot will require the entry of a password before the system is mounted. To be able to do this your provider would need to give access to the machine via a KVM, which allows remote access to a keyboard console as the machine boots. This is a non-standard setup and some providers may charge additional fees for it.
Advanced users using whole-disk encryption may set up the DropBear SSH daemon in their boot loader, which allows for the use
The significant benefit to whole disk encryption that if the machine is seized by outside parties they will have no access to the operating system or disk itself. This means that no data on the machine will be leaked in that eventuality. This also denies attackers the ability to modify most local system binaries to attempt to intercept passwords, provide backdoors or log user actions.
- The [|Linux Unified Key System(LUKS)] also for both full and partial disk encryption. An in-depth tutorial for LUKS setup can be found here and a simpler one can be found here
Data Store Encryption
An alternative to whole disk encryption is to encrypt specific portions of the disk containing the most sensitive data that must be protected. Care should be taken to encrypt both data at rest (ie a database, MySQL etc.) and "scratch" or temporary data storage (search engine technologies such as Solr, Memcached data stores etc.).
This removes the need for entry of a boot password on reboot but it does leave any elements of the disk not encrypted open to access if the machine is seized or compromised.
- The tool encfs runs in the user space and allows the creation of encrypted partitions. These partitions can be mounted once the system has been booted. The tool allows for very strict control over which users can access mounted information once a partition has been decrypted and is suited to applications where a specific user/process accesses the encrypted data. The encrypted partitions can be defined at variable sizes and the sensitive datastores and applications can be run from within them once the partition has been mounted. A guide for setting up encfs can be found here.
- The Linux kernel offers support for ecryptfs partitions. These partitions are mounted like any other local filesystem, but with the benefit of the device being encrypted while unmounted. These partitions are mounted like other filesystems and not in user space so they cannot be mounted by unprivileged users.
- The LUKS tool can also be set to encrypted only specific partitions and mounted in a similar way to encfs.
