MySQL provides password-reuse capability, which allows database administrators to determine the number of unique passwords a user must use before they can use an old password again.
MySQL provides password-expiration capability, which enables database administrators to require that users reset their password.
The other day on a call, a client asked me an interesting question. We were discussing some testing they were doing in Amazon Relational Database Service (RDS). The question came up “since RDS is managed, how can I prove to my security team that the data is actually encrypted?” We’ve all read whitepapers and blogs that talk about encryption in the cloud, but it is something I’ve not needed to validate before. Instead, I just enable encryption when I create an RDS instance and move along to the next steps of the setup. This discussion really got me thinking – what is the best way to enable and test encryption at rest in my RDS instance?
Encryption at Rest – MySQL Fundamentals
Before getting too far into the RDS specifics, I wanted to cover the basics of encryption at rest in MySQL. There are essentially two ways to encrypt data at rest:
- Full disk encryption (filesystem/block …
MySQL has the capability of generating random passwords for user accounts, as an alternative to requiring explicit administrator-specified literal passwords.
Then secretary of Defense Donald Rumsfeld popularized the terms: “known knowns”, “known unknowns”, and “unknown unknowns.” With the ever-increasing number of data breaches and vulnerabilities, database operation teams have to account for every possibility. Visualizing your audit data allows you to look for the “unknowns”, those access patterns or connections that you’d otherwise overlook.
Although enabling an audit log and shipping it off to a vault may meet security and regulatory requirements, you will lose an important opportunity to protect your customer and employee information.
The following dashboard demonstrates the type of information that audit logs can reveal:
- Who is connecting to my database (IP address, location, username..)
- Who is trying to connect to my database but getting access errors?
- Which tables are being accessed and by whom? …
In this blog, we will test a new security feature added in ProxySQL 2.0.9. Since a time ago, we have had the ability to block queries using mysql_query_rules table matching a group of queries using reg exp like a blacklist. Check out a previous blog for how to config “ProxySQL Firewalling” using the mysql_query_rules table.
You can improve a whitelist using the mysql_query_rules table, but it is difficult if you have hundreds of queries.
ProxySQL 2.0.9 introduces two new tables for the firewall whitelist algorithm:
Admin> SELECT name AS tables FROM main.sqlite_master WHERE type='table' AND name IN ('mysql_firewall_whitelist_rules','mysql_firewall_whitelist_users') ORDER BY name; +--------------------------------+ | tables | …[Read more]
Data security plays a major role in current age. Privacy matters a lot. Data masking is one of the Key Features when comes to security.
- In MySQL community versions if you want to mask your data, You can go with a Maxscale load balancer.
- They introduced a new masking filter on the Maxscale 2.1 version.
- My colleague Prasanth written about column-level data masking. For reference click here Column Level Data Masking.
- In MySQL 8.0 Enterprise they have introduced a new security feature called data masking.
- This feature was introduced in MySQL 8.0.13 Enterprise Edition and it provides data masking and de-identification capabilities.
What is Masking ?
- Transformation of existing data to mask it and remove …
There are many users of MySQL in Cloud environment regions. It’s ideal that those MySQL instances are implemented with only private-ips in the respective Subnet. No public-ips. For that matter, all cloud infrastructure resources are ideally placed behind networks that provision only private-ips. This limits any front-end attack surface for an application stack. Certainly the… Read More »
In the last blog post of this series, we discussed in detail how Master Key encryption works. In this post, based on what we already know about Master Key encryption, we look into how Master Key rotation works.
The idea behind Master Key rotation is that we want to generate a new Master Key and use this new Master Key to re-encrypt the tablespace key (stored in tablespace’s header).
Let’s remind ourselves what a Master Key encryption header looks like (it is located in tablespace’s header):
From the previous blog post, we know that when a server starts it goes through all encrypted tablespaces’ encryption headers. During that, it remembers the highest KEY ID it read from all the encrypted tablespaces. For instance, if we have three tables with KEY_ID = 3 and one table with KEY ID = 4, it means that …[Read more]
We will have a look at a new feature in MySQL 8.0 called binlog encryption. This feature is available from the MySQL version 8.0.14 or above.
The binary log records changes made to the databases so that it can be used to replicate the same to the slaves and also for the point in time recovery (PITR). So, it means that if someone has access to the binary logs, they can reproduce our entire database in many forms. As a DBA, we need to make sure that the binary log files are protected from users who are having access to the file system and also, log files need …[Read more]