We have an Ioncube encoded script running on an Apache web server which stores customer confidential information in a MySQL database. We have configured the script to run under its own account using suphp. As usual the script reads the database credentials from a 'config.php' file. We'd like to mitigate the risk of the database contents being exposed through a zero day exploit. The web server OS, Apache and MySQL have been hardened. Is there anything we can do to lock down this script further. For example, if someone did exploit the script, I assume they would end up with the same privileges as the suphp account that the script runs as - Would they attempt to mysqldump the database? Should we be restricting access to all the mysql binaries?
You didn't mention MYSQL injection attacks in your list of precautions. Also you could reduce the permissions of the mysql user for the database. Usually people give the user all rights but you can restrict the mysql user's ability to do ALTER, CREATE, CREATE ROUTINE, CREATE TEMPORARY TABLES, CREATE VIEW, DELETE, DROP, EXECUTE, INDEX, INSERT, LOCK TABLES, REFERENCES, SELECT, SHOW VIEW, TRIGGER, and UPDATE. Only give the mysql user permission that are needed to run your script.
A defense in depth approach is to plan on failure and to limit what privileges you give to your application and to your administrators.
That being said Ioncube protected scripts are a joke, all code obfuscation is very easy to undermine in PHP using runkit. If you are relying upon this as a means of protecting some kind of password then you have a very serious problem on your hands. An 0-day isn't required because you are not doing anything to protect your secrets.
No amount of cryptography can solve this problem. It is never acceptable to allow an attacker to connect to your database. You must implement an API that limits the access accessible to the client.