 Thank you for making this, making so far in the mass scale track. I'm pretty sure by now it's not so early as in mass scale. My name is Marine Varadriya. I am working on security features of mass scale server and mass scale client. And my session today is about how you can improve the security of your database using the features available in mass scale 8.0. I'll focus on the hardening part of the security, not just the default part of it. Okay, so let's move on. As usual, there's the same hardware statement. Everything I say is just for information. Please don't make any business decision out of it. We'll cover some part of the motivation why security hardening is important for a database. And then we'll move to different aspects of security, including deployment, operational security, and backup security. So let's move on. Why? Why it's needed? Because of all this. So, databases are more frequent. They are bigger. They are getting bigger every day. And they are getting expensive with every single day passing. I'm not just talking about the value of the data that you're losing after the database or, let's say, the NILO service. I'm also talking about the steps you need to take to recover to get back to the same state. You have to spend resources to identify the cost. You have to mitigate those costs. You have to change the policies. You have to, you are obliged to, you know, fulfill the regulatory requirement and whatnot and not to forget the reputation. And the penalties for databases or the services are getting severe day by day, GDPR, PCI penalties, and it's growing. So it's really critical that you try to harden your database, or try to harden your application as much as possible so that you don't have to suffer through all these things. How does a database play a part in this scenario? So there are many aspects. You have a mission-critical database, but it has a poor configuration which allows certain unsafe operations. Or you are using overly privileged account which are not really meant for your application. Or you are using very weak access control. You are using two cores of, you know, coarse-grain permission, rather than a fine-grain access control over your tables or columns. Weak authentication, no auditing or monitoring, which will allow you to, you know, forensic value in your database. You have hardened your deployment, but your backup signs secure, so that's as good as losing your data. You are not using encryption. You are not using proper credential control or key management. Applications are poorly connected. There are literally hundreds of ways your database can be exposed and, you know, you can suffer data future in our service. So how not to do that? So let's jump in. Let's start with the deployment part because that's the first thing that you will do once you have a database product. Verify your package. You know, suddenly after working for a month, if you realize that there is a malware in your package, it's a lab. So verify your package, verify the signature, verify the keys, verify the hash, and then install the package. Always choose the right package. For example, in case of MySQL, we have various... I'm taking the example of, let's say, RPM packages. We have various RPM packages, which provide server binaries, client binaries, test databases, demo databases, header files for development of new plugins or components. Install only things that you need. Don't install more because if you're installing more, you are actually opening up the attack surface. You are actually allowing somebody malicious to go in and leverage on those points. Harden your configuration. Defaults are good, but analyze your own requirement and harden them as much as possible. There are useful plugins which are available with MySQL database. Use them. Use them to harden your passwords. Use them to make sure that brute force attacks are thwarted. And rely on package managers. Don't simply rely on Darjeet's install. I can understand that it is very easy to use the Darjeet's installers. But package management, like young or dead packages or Windows installers, they are smart installers. They provide a secure by default installation. They install useful plugins by default. It makes your life easier. What we did in MySQL, we started a story with MySQL 5.7. We are continuously doing this as a MySQL 8.0 and we will be doing it in the future as well. That we are making it secure by default while making sure that it's not hampering the usability. So we removed test and demo databases, put them in a separate package. All the tests are now in separate packages. There are no multiple accounts. There is only a single local root account, so database is not having a remote root which can be accessed from anywhere. By default, server and client supports encrypted connections. So your connection security aspect is covered. There are pre-configured locations for import and export of the data, which limits where you put your data and how accessible it is to everyone. We also make sure that MySQL Linux and MMR policies are also applied with MySQL and only the things which are needed are configured as well. Using package managers, it makes sure that extra security and sensitive plugins are already installed and we run as not as a pseudo or we run as a which is not very privileged which exposes the entire system. So, some part of the configuration that you probably need to model or complete a look at this, the location of the data for import and export operation. Configure it. If you are not using this operation, just disable it. Setting it to null will simply disable your data import and export operations. If you are not using it, just disable it. Don't use symbolic links. It's not advisable. It's off by default. You should keep it that way. General log and log root use it only for the debugging purposes if you are running into any issues, otherwise it's way too much of the information that you might use. If you are not going to have a network attached to your database, use skip networking. It will just allow you to work on the local worst and it's not exposing your database outside. Do use SSL. I cannot emphasize this on this option. It doesn't matter how secure your database is. It doesn't matter how secure your disk is. If your communication is not secure, it's of no use. So, please always use SSL. Always set up SSL with valid values. Last but not the least, always stay updated. Security patches are called security patches for the reason they improve the security. It's not just for the database, from OS point of view as well. So apply security patches, stay updated, follow the hardening guideline of the OS that you are using and make sure that you have everything that you need to secure your system as well as your database. Right. So let me move on. Operation security. What you can do to secure your running database server. First off is communication. Use non-default port. 3306 is known to everyone if a malicious user is looking to find out whether the database is running. MySQL database is running. They'll likely scan the 3306 and try to identify whether you have it running it or not. Once you have it running at that point, they'll try to, you know, get access to or probably try to do another service at that point. So use non-default port, but make sure that you have App Armor or a Celinux configured to allow those communication to those ports as well. Use SSL, proper certificates, use authorized CA to sign server certificates and use that. If you really want to disable, you know, unenlipped connection servers supported by requiring your transport, then basically make sure that either the connections are local, that is socket or shared memory or they have SSL element. From client point of view, when you're connecting to server, always use verifier identity. This will make sure that you are talking to the guy you're supposed to talk to and not do something else. And always use slater-stainless protocol. MySQL now supports slater-stainless.3 as well. It has a pain dot zero over 14. So use it. For replication point of view, change master and GR setup, configure your channels to use SSL. It underlines it uses Libmaskier clients so you can, you know, point them to use SSL, CAS, SSL certificate as usual. Third up, authentication. Use secure authentication. We have caching SHA-2 password which is by default in 8.0. It uses SHA-2-26, multiple rounds of SHA-2-26 hash with a sort. Even better, if you're using an enterprise edition of MySQL, you can actually configure MySQL to work with, let's say LDAP, which is configured in your organization. So use LDAP. Use password policy. MySQL provides you way to configure the complexity of a password, lifetime of a password, whether it can be UDU used after N number of, you know, N passwords or not. Those things are configurable. Use it. And when you're changing the password, use a secure channel because that's where you're sending your password to the server. If your applications are, you know, have cached the password in certain level, we support dual password now. So dual password, make sure that you change your password, but your old password still works till the time you discard it, so it allows you to allows your application to move over to the new password and then finally change the old password. For sensitive account, use TLS connection to verify client's identity. Ideally, you should use a non-default root account. When MySQL server installs, it creates root as the most powerful account. You should rename it to something else. Always monitor. We have MySQL Enterprise Monitor as well as various information schema views. Always monitor your user account even you're at the need of a user account. If you find a user account which is not being used, lock it or disable it. It's for your own safety. Right. Next part is authorization. MySQL 8.0 provides support for the roles. It's a very powerful tool to manage the authorization. You can group various privileges. You can create a role hierarchy and you can effectively manage your users to use these roles and have all the permissions that is required. So use the roles. Always follow principle of these privileges. If you don't require insert permission for an operation, don't grant user the insert permission as simple as that. Because if you grant permissions which are not required, chances are that those permission can be misused if your application or your database was exposed somehow. Do not use a single account for multiple applications. It's very tempting but separation of duty is very important. Sorry, that was no account probability. Separation of duty is all about trying to make sure that there is no single super user. You basically make sure that you have lesser admins which have some of part of the admin privileges and you just divide them between them. Don't do account overloading. Applications should have their own dedicated user that makes your life easier and it's meant for duty conferencing as well. And again, review and improve. Enterprise monitor information schema view. Always see what's going on and remove the unwanted privileges. Next up, encryption. MySQL currently has ability to encrypt your table data, your redo and undo log, your binary log, using key ring plugins. So use it for your sensitive data, use it for sensitive content with data. Use a proper key server which allows you to store keys, manage key, enforce a key rotation policy and everything. If your application relies on symmetric or asymmetric encryption, there is ASN script which is for symmetric encryption and on an enterprise server, we have enterprise encryption plugin which provides asymmetric encryption as well. It also allows you to sign and verify content if need be. And always keep your keys safe. That's good. With enterprise edition, MySQL also has masking and de-identification functions. So you have a string database, string-based data masking which will mask part of full content. There's specific masking like SSN masking, or payment card masking. And there is a dictionary-based management as well which will convert one of the values to certain coverage as well. Auditing is really important because it allows you to figure out what went wrong. So always use auditing, enable audit. Always audit sensitive account, always audit operations on sensitive objects. Very importantly, audit failures because failures are probably an indicator that somebody is trying to do something that they are not supposed to do. Your applications won't try to do one operation which is denied to your applications. You'll configure your account in such a manner. So audit your failures. It's very important when you're auditing to strike your values. So MySQL offers a really wide range of audit filters which you can use when you are auditing. You can configure it to make sure that only the sensitive operations are audited, not everything will be the right performance penalty for the same. And protect your audit loss. Maybe write them on only media, write once media and don't give DBAs access to those locations because then it defeats the purpose. If your DBA goes wrong you can't really protect your system against it. MySQL also provides a firewall which can learn the behavior of an application. It can detect an anomaly and it can actually deny which an application is not supposed to use. So if you want, you can go ahead and make it in learning mode. Start learning the behavior. Detect mode where it will just report the queries which an application is not supposed to file. And finally if you are satisfied you can just switch it on to protect mode and then it will start blocking the queries. It's a whitelist based and uses statement digest so it is not vulnerable to things like SQL injection. So make sure you use these features. These are by the way enterprise edition features. Last part, backup security. They are critical for your business continuity. It allows service to come to a sane state because you know after let's say a dinner service or you are migrating to another server or to your part of audit rate. Always get your backup. Put them in a protected media like once media or write once in many times media. And always delete your obsolete backup. You don't need it. There is no reason to keep it. But use a secure delete function. Just don't do an rm-rm which is simply annoying and I know it. And schedule mode store drills. This will help you manage the downtime. If your DBS are to restore the database to a sane state every now and then, in an actual event of a disaster, they will take less time to bring the server back up online. At the end, I would like to showcase the security architecture of MySQL and this is for the community version of MySQL where you have network encryption, you have strong authentication and login policies where you have access control and database event logging and file scaling as well. On an enterprise version, we have firewall, we have enterprise authentication support for enterprise audit and keyboard as well as enterprise monitor. With that, I am done. These are the resources you can take a look at to further identify where you can secure your database. There is a security guide, there is a secure deployment guide and some white papers which are useful as well as the blogs where we continuously put information which is relevant for internal security. Thank you all for being kind audits. If there are any questions, let me know. Thank you very much.