Data Security / Encryption

Assuming it's on site, the best thing you can do is make it so that the database and web server are 2 different boxes.  Make the web server public, but firewall the crap out of the SQL server only accepting connections on port 3306 from the web server.  Even better, change the default 3306 port to something else.  Disable remote login as root and set a new user in MySQL that is only accepted from the IP of your webserver (which should be on the same network).  Then only grant it privilege for the sugar database it needs.  Dont give that user full access.  

Also set the SQL server firewall to only accept SSH connections from the IP you choose, or even better, disable SSH entirely and require a KVM to it or at the very least, dont leave it at port 22.  If you must leave SSH open, use a local ip or jump box of some sort.  This prevents file system access where an attacker could just download the MySQL folders locally and brute force it offsite.  

This does 2 things.  It hides your SQL server from the public and only allows Sugars web server to talk to it from a specific IP and ONLY to the table that holds sugar data. That keeps it out of the users table etc. There's not much need in my opinion to enrypt the SQL data after that.  Sugar's web server at that point should be the only vulnerability point and if Sugar is vulnerable, well, there's not a ton you can do about that except stay on the most recent version.

Just remember, your security is only as strong as the weakest link.  If someone can get on your web server then they can get to you DB server no matter where it is or how hardened it is.  It might be that obfuscation would be more helpful than encryption at the web server.

Agreed.  Pretty much everything I said about hardening the SQL server and keeping it private would apply to the web server as well.  HTTPS and only accept port 443.  Block port 80.  Same with SSH/FTP.  Only allow SSH/FTP on the private network  and get it off of port 22.  Pretty much one of the first, easiest and best steps you can take is restricting access by IP and changing the default ports on everything. Unless you are under a direct attack, just changing the port numbers bypasses the global port scanners that move from one IP to the next.  Changing port 22 to say, 2357 will thwart automated port scanners and make you less of a target.  I blocked everything about my instance except port 443 on the incoming.  I cant even SSH into it.  I have to VPN to a specific box on my companies LAN as a jump box to get to my web server, and the port isnt 22.    

Agreed.  Pretty much everything I said about hardening the SQL server and keeping it private would apply to the web server as well.  HTTPS and only accept port 443.  Block port 80.  Same with SSH/FTP.  Only allow SSH/FTP on the private network  and get it off of port 22.  Pretty much one of the first, easiest and best steps you can take is restricting access by IP and changing the default ports on everything. Unless you are under a direct attack, just changing the port numbers bypasses the global port scanners that move from one IP to the next.  Changing port 22 to say, 2357 will thwart automated port scanners and make you less of a target.  I blocked everything about my instance except port 443 on the incoming.  I cant even SSH into it.  I have to VPN to a specific box on my companies LAN as a jump box to get to my web server, and the port isnt 22.    

Regarding ssh I would like to add:

• disable password authentication, use public key authentication
• don't use RSA/DSA keys, as far as I can see in my logfiles, atm brute force attack ssh bots only support connections with RSA/DSA keys
• If you have to use passwords, then also use 2FA (libpam google authenticator)