-1

Some specific questions beyond this:

1) What are your most critical security considerations? I feel like I've secured the data in transit with encryption/https, data at rest by encrypting sensitive data that I don't need access to, set up a firewall to access phpmyadmin, changed root passwords, etc., but I'm not confident that I've 'checked all the boxes' so to speak. Is there a robust guide to securing mysql/php applications out there somewhere? Perhaps a pen test is the only way to get confidence to some degree?

2) What are your backup considerations? I've got a master/slave relationship set up for the mysql database in two different datacenters, and weekly backups of the production server itself. The code is all in source control, but I have some uploaded documents that I'd lose if the whole thing crashed on Day 6 after backups. Any ideas on that one? Considering moving the document storage to a different server and backing it up nightly, or asynchronously just saving the document on initial upload to two separate servers. They are not large docs, and volume isn't high yet, but, is that scalable?

T L
  • 53
  • 4

1 Answers1

0

I feel like I've secured the data in transit with encryption/https

It's not really clear from this how far you have gone, so forgive me if you have already addressed the following.

Obviously https secures the transmission of data between the client to your webserver but it should not be confused with an encrypted connection between your application and the database. Admittedly the risk factor of data being intercepted here is much lower, but it depends how sensitive the data is. Information on setting up encrytped database connections can be found here. As you are replicating between data centres you should consider setting up replication to use encrypted connections also.

Replication and backing up are not the same thing, once you have replicated the data from the master to the slave you still need to back up the slave. You can use mysqldump but the caveat is mysqldump creates a logical backup not a physical one so restore functions are slow and it's not good for scaleability. There's a good post here with solutions for making a physical backup instead.

Apart from that there are the usual kind of security measures you should implement with any system:

  • Create and assign separate user accounts for each process with the minimum level of access permissions needed to perform their function.
  • Create an admin account with a non generic admin type username. Remove root account and any others that are likely to get you pwned like admin etc
  • Only encrypt data if you need to be able to decrypt it again. Salt and hash sensitive data which is only needed for validation (passwords etc) and save the resulting value in the database. Validate user inputs against the hash.

Depending upon your use case you may also consider:

  • In /etc/mysql/my.cnf within the mysqld section you can disallow connections from anywhere except the local machine by adding bind-address = 127.0.0.1
  • Disable loading files into MySQL from the local filesystem for users without file level privileges by adding local-infile=0
  • Implementing stored procedures for common database tasks. These have several benefits (as well as some drawbacks) but are good from a security point of view as you can grant user accounts permissions on stored procedures without granting any permissions on the tables which they utilise.
  • Using database views to restrict access to some columns within tables while still allowing access to other columns within the same table. As with stored procedures there are pros and cons for views.

There are probably a million other things which someone who understands MySQL much better than I do could reel off to you without even thinking about it, but that's all I've got.

miknik
  • 5,748
  • 1
  • 10
  • 26