Eight essentials to make your account's security a priority
Security is and will always be a two-way street: it requires effort from both the user and the platform. Learn best practices to secure your account.
Ensuring the security of sensitive information is a top priority for any organization, particularly when it involves storing data on a server. In this regard, implementing encryption at rest for partitions containing application data can serve as a highly effective solution to safeguard valuable data against both external threats and internal breaches.
By combining encryption at rest with a secret manager, organizations can significantly enhance the security of their server-stored data. Encryption at rest provides an additional layer of protection by encrypting data at the storage level, while a secret manager facilitates centralized and secure storage and management of encryption keys.
This article aims to explain the numerous benefits of implementing encryption at rest for partitions housing application data on a server. We will emphasize the critical role played by a secret manager in effectively managing encryption keys. We will guide you through the process of implementing this solution on a server and how to seamlessly integrate it within an application environment.
To ensure that no unauthorized agents can access your files, it is crucial to have a clear understanding of your specific threat model. In this scenario, our primary objectives are to safeguard your data and mitigate potential risks, such as:
a. Protecting data against theft or loss.
b. Ensuring compliance with security rules.
c. Minimizing the risk of sensitive data disclosure.
Securing your data with encryption can be a daunting task, particularly when you lack built-in tools and resources. However, this article aims to showcase a straightforward approach to encrypting your data disk with minimal hassle. In this guide, we will walk you through the process of encrypting a data volume on an instance using Luks, ensuring your data remains protected. To enhance security further, we will securely store the encryption key in the Scaleway Secret Manager. By following these steps, you can establish a robust encryption solution without unnecessary complications.
Before we start, you'll need to understand how to create your Access Key, which we covered in our Eight essentials to make your account's security a priority article.
We need an instance and a data drive attached to it. We will encrypt this disk, not the boot one. We will also need a secret. For this hands-on demonstration, we will use the Scaleway CLI and some shell command lines.
For optimal secret management that aligns with your organization's security standards, it is advisable to consult your CISO first. They can provide valuable insights and guidance on creating a secret solution tailored to your specific requirements.
There are multiple ways to generate a secret; here are some examples:
Generate a key using openssl
openssl rand -base64 32
dd bs=32 count=1 if=/dev/random > keyfile
Use a password generator
curl -s --request POST --url https://vspg.tools.sa-scw.fr/v1/password --header 'content-type: application/json' --data '{
"number_of_words":"6",
"number_of_numbers":"14",
"separator":"0",
"language":"fr"
}' | jq ".result" -r > keyfile
To make your life simpler (and mine), I will use the name “encypted_drive” but you can use the disk ID as a Secret name, this will help you to automate the process.
% scw secret secret create name=encypted_drive
ID 8a55eea4-e989-4138-88a6-1c1457931702
ProjectID f04db921-03a2-48b3-99f0-105110e77db6
Name ba02dae4-a149-4e86-bea1-e30ae32993de
Status ready
CreatedAt now
UpdatedAt now
Region fr-par
VersionCount 0
Description -
Then, add a new version of the secret that contains the secret generated in the first step.
% scw secret version create secret-id=8a55eea4-e989-4138-88a6-1c1457931702 data="$(cat keyfile)"
SecretID 8a55eea4-e989-4138-88a6-1c1457931702
Revision 1
Status enabled
CreatedAt now
UpdatedAt now
Description -
The base64 version of the secret is now stored securely in the secret manager. Let’s check it using the API
% curl -s --request GET \
--url 'https://api.scaleway.com/secret-manager/v1alpha1/regions/fr-par/secrets/8a55eea4-e989-4138-88a6-1c1457931702/versions/latest/access' \
--header 'X-Auth-Token: 19b78691-35fb-40b6-b51f-658d22a701d7' \
| jq -r '.data' \
| base64 -d
UnmysticalnessDubbeltjeBasinasialAustralioidHarquebuseYobboes,7838909742353
We now have a secret stored securely and we know how to retrieve it.
Don’t forget to delete the keyfile
In order to provide the encryption key to the system, We will create a script that will take care of retrieving the secret. The script will be implemented in Bash for simplicity here. However, feel free to choose any programming language that best suits your specific needs and requirements.
First, we will create the file /etc/luks/data-key.sh
#!/bin/sh
set -e
# Request the secret from Scaleway Secret Manager
curl -s --request GET \
--url 'https://api.scaleway.com/secret-manager/v1alpha1/regions/fr-par/secrets/8a55eea4-e989-4138-88a6-1c1457931702/versions/latest/access' \
--header 'X-Auth-Token: 19b78691-35fb-40b6-b51f-658d22a701d7' \
| jq -r '.data' \
| base64 -d
Ensure the owner of this file is "root"
chown root:root /etc/luks/data-key.sh
Allow only root to read and execute the script
chmod 0500 /etc/luks/data-key.sh
Once again, follow your security best practices.
Depending of the systeme you are using, the package can be differents
On the CentOS, Fedora, family
yum install -y cryptsetup
On Ubuntu, Debian, …
apt install -y cryptsetup
Using lsblk
, we will find the data disk
# lsblk
NAME MAJ:MIN RM SIZE RO TYPE MOUNTPOINTS
sda 8:0 0 9.3G 0 disk
├─sda1 8:1 0 1M 0 part
├─sda2 8:2 0 1000M 0 part /boot
├─sda3 8:3 0 100M 0 part /boot/efi
├─sda4 8:4 0 4M 0 part
└─sda5 8:5 0 8.2G 0 part /home
/
sdb 8:16 0 39.1G 0 disk
zram0 252:0 0 7.7G 0 disk [SWAP]
In this example the data disk is sdb
, check carefully on your system, all the data will be whipped once you run the command below.
Let’s create the partition table
parted /dev/sdb mklabel gpt
parted -a opt /dev/sdb mkpart datadisk ext4 0% 100%
And go for the fun part we will secure the sdb1
partition, begin by encrypting it using LUKS. Next, create an ext4 volume within the encrypted partition and then securely close the encrypted volume.
During any commands that require a keyfile, make sure to use the /etc/luks/data-key.sh
script that was previously created, and instruct cryptsetup to read the keyfile from stdin.
Don’t forget to replace sdb1 with the correct partition on your system!
/etc/luks/data-key.sh | cryptsetup -d - -v luksFormat /dev/sdb1
Then let’s open the encrypted volume, and use the name "data"
/etc/luks/data-key.sh | cryptsetup -d - -v luksOpen /dev/sdb1 data
Create a filesystem on the encrypted volume
mkfs.ext4 -F /dev/mapper/data
Let’s check the partitions
# lsblk
NAME MAJ:MIN RM SIZE RO TYPE MOUNTPOINTS
sda 8:0 0 9.3G 0 disk
├─sda1 8:1 0 1M 0 part
├─sda2 8:2 0 1000M 0 part /boot
├─sda3 8:3 0 100M 0 part /boot/efi
├─sda4 8:4 0 4M 0 part
└─sda5 8:5 0 8.2G 0 part /home
/
sdb 8:16 0 39.1G 0 disk
└─sdb1 8:17 0 39.1G 0 part
└─data 253:0 0 39.1G 0 crypt
zram0 252:0 0 7.7G 0 disk [SWAP]
And close the encrypted volume
cryptsetup -v luksClose data
We have now a successfully encrypted data volume that lives in sdb1
.
It’s time to make it useful, by automatically un-encrypting and mounting it at the start of the server.
We continue to use lsblk
to find the volume uuid of sdb1
#lsblk --fs
sdb └─sdb1 crypto_LUKS 2 fc916938-a5c4-4128-a4a4-1b108b066297
In this example the UUID of sbd1
is fc916938-a5c4-4128-a4a4-1b108b066297
.
To establish a systemD unit that unlocks the encrypted device, save it as /etc/systemd/system/unlock-data-volume.service
. Be sure to modify the UUID in the command provided below to match the correct one for your device.
In this example the UUID of sbd1
is fc916938-a5c4-4128-a4a4-1b108b066297
.
[Unit]
Description=Open encrypted volume data
After=network-online.target
Wants=network-online.target
StopWhenUnneeded=true
[Service]
Type=oneshot
ExecStart=/bin/sh -c '/etc/luks/data-key.sh | /sbin/cryptsetup -d - -v luksOpen /dev/disk/by-uuid/fc916938-a5c4-4128-a4a4-1b108b066297 data'
RemainAfterExit=true
ExecStop=/sbin/cryptsetup -d - -v luksClose data
We also need to create a systemD unit for the mountpoint /mnt/data, save it as /etc/systemd/system/mnt-data.mount
.
Keep in mind that the name of the unit must correspond with the path of the mountpoint.
[Unit]
Requires=unlock-data-volume.service
After=unlock-data-volume.service
[Mount]
What=/dev/mapper/data
Where=/mnt/data
Type=ext4
Options=defaults,noatime,_netdev
[Install]
WantedBy=multi-user.target
And the last step: enable the systemD unit /etc/systemd/system/mnt-data.mount
systemctl enable mnt-data.mount
systemctl start mnt-data.mount
By running lsblk
, you should be able to see the new volume mounted /mnt/data
# lsblk
NAME MAJ:MIN RM SIZE RO TYPE MOUNTPOINTS
sda 8:0 0 9.3G 0 disk
├─sda1 8:1 0 1M 0 part
├─sda2 8:2 0 1000M 0 part /boot
├─sda3 8:3 0 100M 0 part /boot/efi
├─sda4 8:4 0 4M 0 part
└─sda5 8:5 0 8.2G 0 part /home
/
sdb 8:16 0 39.1G 0 disk
└─sdb1 8:17 0 39.1G 0 part
└─data 253:0 0 39.1G 0 crypt /mnt/data
zram0 252:0 0 7.7G 0 disk [SWAP]
Now to ensure that everything is working properly, reboot your server and check if your volume is properly decrypted.
Now that we have provided you with the necessary setup instructions, it is essential to understand the limitations and flow of this implementation.
Firstly, please note that the key required to access your volume is stored in plain text within your boot volume. While it is only accessible by the root user, it is important to consider your specific threat model. Depending on your security requirements, this aspect may present a potential concern.
Additionally, it is important to mention that this approach is not applicable to your root filesystem. To retrieve the encryption key, network access is required. This ensures that the necessary encryption key can be obtained securely through network connectivity.
Being aware of these limitations and implementation considerations will allow you to make informed decisions and take appropriate measures to address any potential security concerns.
In conclusion, implementing data volume encryption in a server using a secret manager is a straightforward endeavor. By harnessing the power of a secret manager, the encryption process becomes seamless and easily manageable.
The secret manager's robust security features greatly simplify encryption key management and guarantee confidentiality of sensitive data. This approach empowers server administrators to effortlessly incorporate data encryption, effectively protecting valuable information with minimal effort.
By embracing encryption with a secret manager, organizations can fortify their data security posture and mitigate potential risks.
Security is and will always be a two-way street: it requires effort from both the user and the platform. Learn best practices to secure your account.
We will expand our Compute range: from powerful GPU instances to new ARM-based processors. We're excited to share with you what we have in store for 2023.
Having an infrastructure that is not optimized is time and money consuming.I’m here to give you tips on how to plan your resource sizing.