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.
The post MySQL Security - Password Reuse Policy first appeared on dasini.net - Diary of a MySQL expert.
MySQL provides password-expiration capability, which enables database administrators to require that users reset their password.
The post MySQL Security – Password Expiration Policy first appeared on dasini.net - Diary of a MySQL expert.
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:
MySQL has the capability of generating random passwords for user accounts, as an alternative to requiring explicit administrator-specified literal passwords.
The post MySQL Security - Random Password Generation first appeared on dasini.net - Diary of a MySQL expert.
Early on in the MySQL 8.0 Release series there were a couple of key items related to our everyday use. They are MySQL-Shell‘s establishing the “Pluggable Password Store” in 8.0.12, and its super enhance API Command Line Interface in 8.0.13… which the Pluggable Password Store also adopted. Sadly, most content highlighting the API CLI capability when it came… Read More »
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:
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.
What is Masking ?
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 up coming MySQL… 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]