Welcome to Gazzang’s Video Training where today we will learn how to set up an Amazon EC2 Server, install ezNcrypt on it, create a process based ACL rule, encrypt a MySQL database and test it.

ezNcrypt, is a Transparent Data Encryption solution for any data used by virtually any application running on Linux.  Our customers encrypt their sensitive data, like PCI, HIPAA, IP and more.

And all this happens without making any changes to those applications or the data.

Let’s go set up our Amazon EC2 Server now.

First, log in to the AWS Management Console and launch a new Amazon EC2 server instance.  

Select an appropriate AMI that meets the needs of your project.  Don’t forget to take ezNcrypt System requirements into account.  ezNcrypt requires a Linux kernel of 2.6.19 or newer, or if you’re using RedHat or CentOS, then you’ll need a kernel version of 2.6.18-192 or newer.  

As a side note, these kernel version requirements for ezNcrypt are driven by the need for eCryptFS, the embedded encryption module that comes with the Linux distributions ezNcrypt supports.

Finish up the Advanced image configurations like Key Pair and selecting or creating your security group.

Finally, get ready to launch your new server instance by checking over the configuration summary.   If everything is correct, click launch.  You will see a confirmation that your instance is launching, and soon after you will be able to access your server.

Now, we’re ready to run through the installation of ezNcrypt.

To download ezNcrypt, you first need a Product key and Activation code.  The fastest way to obtain these is by going to www.gazzang.com and clicking on the green “Try Now” or “Try ezNcrypt for FREE” links.   

Complete the form and almost immediately you will receive an email with download instructions.  Here we’re using the ftp site to obtain the current release of ezNcrypt.

Once you have the appropriate file for your system architecture (either 32 bit or 64 bit), run tar –xf to expand the file.  

What you’ll end up with is a README, our install shell script, an ezNcrypt installer, and an ezNcrypt config tool.  You are able to run the ezNcrypt installer first, and then configure it with the config tool independently of each other, or run the install shell script and it will attempt to do the install and configuration in one step.

Running the install wizard will present the license agreement, scroll through the entire agreement, then to continue, select YES to accept it.   

The default Installation Directory is /opt/ezncrypt, but you can specify the directory you like depending on your requirements.  

The install wizard will check for underlying dependencies to see if they are installed.  You can stop the install wizard and take care of the missing components manually, or, let the wizard take care of it automatically for you.

Select the encryption cipher you want to use.  We recommend AES 256, the default option, but you can configure ezNcrypt to use any of the options you see listed here.

Next select your KSS Connection settings.  

Now it’s time to enter your product key and Activation code.  These were in that email you received after requesting a trial or purchasing ezNcrypt.

When that’s done, set your Passphrase and OPTIONAL SALT.  We designed this to provide very strong security by having dual authentication for when manual decryption is necessary.  

With one person knowing the passphrase and another knowing the SALT, no single person would be able to decrypt the information protected by ezNcrypt.   Please refer to the User Guide for how to use an RSA Key File as your master key.

THIS IS IMPORTANT:  Please record your passphrase (and optional salt) and keep them in a safe, secure location so you will always be able to decrypt your data.

Once the installation is complete, it’s time to run the ezNcrypt config tool, which helps to create trusted applications using ezNcrypt’s process based ACL Rules.   At the time this video was made, the ezNcrypt config tool was able to help create ACL rules for MySQL, Apache and PostgreSQL.

Remember, it is possible to create other ACL rules for virtually any application running on Linux.  You are not in any way limited to the applications covered by this config tool.

Here we’ll focus on creating the process based ACL rules for MySQL.   If your installer did not pull up the config tool automatically, go ahead and run the ezncrypt-config-tool script as seen here.

You can choose which components you want to configure, but we’ll just select MySQL and for now, and skip Apache and PostgreSQL by selecting “NO” for each of them.

When asked “What type of credentials you want to use?” you’ll need to choose the same credential type, either Passphrase or RSA Key File, that you set up during the initial install of ezNcrypt.

Now you’re ready to set the specific configuration for your installation of MySQL.  The config tool will check the “typical” locations and configurations and present those back as the default input settings for your server.  It will look for your MySQL start command, the stop command, the path to mysqladmin, and it identifies your MySQL executable, and the data directory.

Once these parameters have been identified, it’s time to create the actual process based ACL rule.  These rules are relatively simple, a little bit like a firewall rule.   Set the Type of rule (ALLOW or DENY), the Category (this is actually a name or a label for your rule and is used to link the rule to the data that you will encrypt later on), Path (this sets a boundary of what directories the rule CAN be applied to, most of the time you will just use an astrix wildcard so that the rule COULD be applied to any directory on your system) and finally, the exact file and it’s full path that runs your “trusted process”.  Select Yes or No to set up a log encryption rule, and it will configure your ACL rules for you.

Please see the User Guide for more information on the process based ACL rules and their settings.

To finish up, let’s encrypt a MySQL database called “employees” and see what happens to the data once it’s protected with ezNcrypt.  

Before we do that, let’s open up one of the tables in our database using a text editor.   I’ve navigated to /var/lib/mysql/employees and then using vi, opened up the table called Titles.  As you can see, the contents of this table contains various titles of our employees in plain text, such as Engineer, Staff, Senior Engineer, etc...  

To encrypt the database, we use a special command that ezNcrypt has for encrypting MySQL databases and it’s called ezncrypt-mysql.   This command automatically stops the mysql process before encrypting the files and then restarts it upon completion.

We encrypt the employees database.  ezNcrypt asks for MySQL root credentials.  It contacts the KSS to retrieve the master encryption key, stops the mysql process and encrypts the database.
 
What happens now is the files are relocated to the /var/lib/ezncrypt/ directory and the data is encrypted as it is written to this new location.  

Once this is done, if you go back and list the contents of /var/lib/mysql, the original data location, there is a symbolic link now pointing to the new location of the data, /var/lib/ezncrypt.  If we follow the link and try to list the files of the employees database, we get a Permission Denied message.  This is part of the security that ezNcrypt provides.

What’s really going on is, the encrypted files are physically located in a hidden directory called /var/lib/ezncrypt/.encrypted_private.  Now, when we try to open the “TITLES” table from this location with our text editor like we did before, you will see that the data is garbled and useless to anyone trying to exploit the sensitive information we’ve stored there.

That covers the basic procedure for how to set up an Amazon EC2 Server, install ezNcrypt on it, create a process based ACL rule, encrypt a MySQL database and then test it.   

We will be adding other installments of Gazzang’s Video Training in the near future.

Click here to view the video.

Backup is a very important component of data that is way too often misunderstood or ignored altogether. At least that's been my experience for several years now. From a security standpoint a backup – especially transportable “export/import” type backups that all databases offer in some form or another – presents an easy target for data theft.  Often that theft goes unnoticed or unreported. 

Just as many open source products, databases and data stores fail to offer transparent data encryption (TDE) to protect all the data in the database, so too do backups. “Unified Transparent Encryption” with Gazzang zNcrypt provides effective data encryption and key management for backup and recovery.

Last October, I wrote a blog called, Running a Secure (Encrypted) MySQL Backup Using mysqldump on Linux. The idea was to help zNcrypt users take some simple steps to protect their mysqldump jobs – securing the user/password credentials and the back files as well.  The blog grabbed the attention of MySQL guru and Oracle ACE Director Ronald Bradford, who wrote about it his latest book, MySQL Backup and Recovery Essentials.

Most often, a combination of backup types are needed to fully provide the high availability and disaster recovery needs. Fortunately, the benefits of Unified Transparent Encryption go beyond export/import or other native database backup utilities. Its also applicable to operating system and file-oriented methods.  With zNcrypt in place, applications read and write data in the same format as always – that’s the transparent encryption part. This is provided by a stack virtual filesystem.  The OS users can see these files, which are encrypted and secure.  Those files can safely be copied (backed up) and restored on another system. If that system has zNcrypt installed and the same key is configured, that data can once again be accessed via transparent encryption.

With this, data can be transferred in its encrypted form safely.  From enterprise to cloud, cloud to cloud, cloud to enterprise.  We’ve provided an example of this in prior blog. A number of Gazzang customers use this method via Zmanda based backups.

Taking this a step further, with something like DRDB or R1soft backup products that backup and synchronize at the block level, all the blocks are encrypted, the data is protected and as long as zNcrypt is installed with the same key on backup and recovery servers, it all works. 

Unified Transparent Encryption is very popular with Gazzang customers running big data. Value, flexibility, and ease of use are important for those big data architectures or search solutions like SolR where the same challenges exist. We’ll save those details for another blog, but certainly reach out if you need is imminent and we can share the secure data lifecycle as well with you.

Again, sensitive data is at risk anywhere it’s stored, backed up, exported, or imported.  Proper IT security involves mapping your data’s lifecycle and finding and remediating risks .  Encryption is a great security tool, but it can be hard to code and create on your own. Gazzang’s zNcrypt customers use the product day in day out to solve these challenges with simple and elegant Unified Encryption. If you’ve got a challenge that’s got you stumped, I’d be happy to have a look. Its amazing what Unified TDE can do.

MySQL Cluster usage has certainly continued to spread and recently accelerate well beyond its initial telco vertical roots into Healthcare, Financial Services, SaaS and more. With those additions it certainly becomes desirable for many to provide transparent encryption on the NDB nodes where the data, logs, checkpoints that write to disk. I'll not go into all those reasons in this blog, but certainly there are plenty, visit our whitepapers section for more information, especially if you are running within hosted, managed, or cloud environments platforms.

The solution for ndb in a nutshell was straight forward:

1. Set up Gazzang ezNcrypt Flex Platform
2. Stop the ndb process prior to encrypting the ndb_data directory
3. Encrypt the ndb_data directory
   ezncrypt -e @ndbdata /home/mysql/my_cluster/ndb_data
4. Add a Flex ACL Rules granting ndbd access to the encryption keys.
   ezncrypt-access-control -a "ALLOW @ndbdata * /home/mysql/mysql-cluster-gpl-7.1.18-linux-i686-glibc23/bin/ndbd"
5. Restart ndb

Note: if you setup a single node test environment or if for some reason want to run it for you will also need to add a rule for ndb_mgmd then also add -

ezncrypt-access-control -a "ALLOW @ndbdata * /home/mysql/mysql-cluster-gpl-7.1.18-linux-i686-glibc23/bin/ndb_mgmd”

Certainly there are many more things you can do to protect MySQL Cluster data on Linux - and I will follow through with those details or details on usage in specific environments, but this is a good start and shows how easy this is to accomplish, and Gazzang adds key management, process, access, monitoring, and many other benefits aside from the encryption itself. For more ideas around that see our EMA paper or schedule an overview with us.

With the release of of our 2.2.2 product coming in February of 2012 you will see that we have added ndb to our supported engines list to MySQL. Gazzang's platform is simple and easy to install as you can see here. If you are interested just Try it out.

If a DBA needs to reset the mysql root password – one method of doing this is to run mysqld with -skip-grant-tables as a command line parameter. This is a bad practice for many reasons and as a DBA friend of mine says – it’s a lot like locking your door with the window open. If you are using mysql for especially secure data you should consider your options.

One option, and likely preferred, is to replace the default mysql from various sources with one built with this feature disabled – see http://dev.mysql.com/doc/refman/5.1/en/source-configuration-options.html#option_configure_disable-grant-options

I am not aware of any distro’s that are built with this option – but seems like a fair number of folks out there would appreciate having a build like this.

But some either still want to be able to somehow reset roots password, or don’t wish to compile mysql on their own, so the second option is to use Gazzang ezncrypt. Beyond the advantages of the Transparent Encryption which provides encryption for table data, config files, backup data and more, you can also use ezNcrypt to prevent use of –skip-grant-tables.  This “closes the window” and will also let you still change the root password if needed. This is accomplished by transparently encrypting the mysqld executable, and adding a simple wrapper executable that will detect and remove the  –skip-grant-tables. It can also optionally send a signal to mysqld to force loading the privileges.

If and when you need to change the root password for mysql, you can still do this – but you will need to have and use the proper RSA key and password or Passphrase and Salt, which is protected and only known to a select few in your administration.

Here’s the how-to for skip-grant-table protection

1. Encrypting mysqld process.

# ezncrypt -e @protected /usr/sbin/mysqld

2. Create and compile mysqld wrapper (called mysqld.secure) that calls mysqld process

g++  -o  /usr/sbin/mysqld.secure  mysqld.secure.cpp

Note: we wrote just a few lines of C++, but you could use a script or perl or php … etc. as the hashes and fingerprinting prevents alternation.

3. Add the following rules using ezncrypt-access-control

# -  Type  Category   Path              Process

1 EE ALLOW @mysql     *                 /var/lib/ezncrypt/ezncrypted/protected/usr/sbin/mysqld

2    ALLOW @protected /usr/sbin/mysqld   /usr/sbin/mysqld.secure


Note: if mysqld.secure is changed SHA-256 hashing and other fingerprinting detect that it is tainted and permissions will be denied.
4. Edit my.cnf

[mysqld_multi]
mysqld = /usr/sbin/mysqld.secure

And that’s it.

When you call:

#  mysqld_safe start

or

#  mysqld_multi start


This will call mysqld.secure with all arguments and mysqld.secure will remove any –skip-grant-table found, and it will call /usr/sbin/mysqld without it, and again mysqld can’t be started on its own with –skip-grant-table – unless you have the encryption key.