So toss this all in a big pot, put on simmer and you get a logical — if not three years too late — stew: Sun Microsystems intends to buy MySQL AB and its very popular open source database. The announcement comes Wednesday with a hefty price tag of $1 billion.

The MySQL purchase by Sun makes more sense than any other acquisition they have done since they botched NetDynamics 10 years ago. This could be what saves Sun.

Sun can make a lot of mischief with this one, by taking some significant oxygen out of its competitors’ core database revenues. Sun can package MySQL with its other software (and sell some hardware and storage, to boot), with the effect that the database can drive the sales of operating systems, middleware and perhaps even tools. Used to be the other way around, eh? Fellow blogger Larry Dignan sees synergies, too. And Tony Baer has some good points.

Who could this hurt if Sun executes well? IBM, Oracle, Microsoft, Sybase (SY), Red Hat (RHT), Ingres. It could hurt Microsoft and SQL Server the most. Sun could hasten the tipping point for the commercial relational database to go commodity, like Linux did to operating systems like Unix/Solaris. Sun could far better attract developers to a data services fabric efficiency than with its tools-middleware-Solaris stack alone. As we recently saw, with Microsoft buying Fast Search & Transfer, the lifecycle of data and content is where software productivity begins and ends.

Sun will need to do this right, which has its risks given Sun’s record with large software acquisitions. And Sun won’t get a lot of help ecology-wise, from any large vendors. This puts Sun on a solo track, which it seems to prefer anyway. I wonder if the global SIs other than IBM will grok this?

Yes, it makes a lot of sense, which makes the timing so frustrating. I for one — and I was surely not alone — told very high-up folks at Sun to buy and seduce MySQL three years ago (I also told them to merge with SAP (SAP), but that’s another blog). When Sun went and renamed it’s SunONE stack to the Java what’s-it-all, I warned them it would piss off the community. It did. I also told them Oracle was kicking their shins in. It did. I said: “Oracle has Linux, and you have MySQL.” Oh, well.

[Now, Oracle has BEA (BEAS), which pretty much dissolves any common market goals that Oracle and Sun once had as leaders of the anti-Microsoft coalition. The BEA acquisition by Oracle was a given, hastened no doubt to the close by the gathering gloom of a U.S. economic recession.]

I’m glad the Sun-MySQL logic still holds, but Oracle has already done the damage with Linux, we saw how that Unix-to-Linux transition put Sun on its knees, and on the defensive. And we know that Sun has only been able to get one leg up since then, albeit refraining from falling over completely. Now, with BEA, Oracle with its Linux and other open source strengths — not to mention those business apps — will seek to choke out the last light from Sun, and focus on IBM on the top end, and Microsoft on the lower end. As Larry Ellison said, there will be room for only a handful of mega-vendors — and we cannot be assured yet that Sun will meaningfully be one of them (or perhaps instead the next Unisys (UIS)).

Indeed, the timing may still have some gold lining …. err, silver lining. Sun has had to pay big-time for MySQL (a lot more than if they had taken a large position in the AB two years ago). And what do they get for the cool $1 billion? Installed base, really. Sun says MySQL has millions of global deployments including Facebook, Google (GOOG), Nokia (NOK), Baidu (BIDU) and China Mobile (CHL).

There’s more, though. The next vendor turf battles are moving up yet another abstraction. Remember the cloud thing? Sun in sense pioneered the commercialization of utility computing, only to have Amazon (AMZN) come out strong (and added a database service in the cloud late last year). IBM has cloud lust. Google and Microsoft, too. Sun’s acquisition of MySQL could also help it become a larger vendor to the other cloud builders, ie telecos, while seeding the Sun cloud to better rain down data services for its own users and developers.

And that begs the question of an Oracle-BEA cloud. Perhaps a partnership with Google on that one, eh? Then we have the ultimate mega-vendor/provider triumvirate: Apple-Google-Oracle. It’s what Microsoft would be if it broke itself up properly and got the anti-trust folks off of their backs (not to mention a reduction in internal dysfunction). And that leaves loose change in the form of Sun, IBM, Amazon, eBay (EBAY), and the dark horses of the telecos. Sun ought to seduce the telcos, sure, and they know it. Problem is the telecos don’t yet.

Surely if Sun can produce a full-service cloud built on Solaris-Intel (INTC)-Sparc that includes low-energy-use virtualized runtimes, complementary tools, and integrated database — and price it to win — well, the cloud wars are on. Sun might hang on for yet another day or two.

If you’re using MySQL, there are some easy things you can do to secure your systems and significantly reduce the risk of unauthorised access to your sensitive data.

The most valuable asset for technology-based organisations is usually the customer or product information in their databases. And so, a critical part of database administration in such organisations consists of securing these databases against outside attack and hardware/software failures.

In most cases, hardware and software failures are handled through a data backup regimen. Most databases come with built-in tools to automate the entire process, making this aspect of the job relatively painless and error-free. What’s not so simple, however, is the second half of the puzzle: making sure that outside hackers can’t get into the system and either steal or damage the information contained therein. And unfortunately, there usually isn’t an automated way to solve this problem; rather, it requires you, the administrator, to manually put in place roadblocks and obstacles to trip up would-be hackers and to ensure that your company’s data stays secure.

A common reason for not securing databases is that it is “difficult” and “complicated”. While this is certainly true, if you’re using MySQL, there are some easy things you can do to significantly reduce the risk you face. This tutorial lists six such items, but you can find many more in the MySQL manual and discussion forums.

Step 1: Remove wildcards in the grant tables

The MySQL access control system works through a series of so-called grant tables, which make it possible to define access levels for each user at the database, table or column level. While these tables do allow administrators to set blanket permissions for a user or set of tables using wildcards, doing so is inherently dangerous because a hacker could use a single compromised account to gain access to other parts of the system. For this reason, be precise when assigning users privileges and always ensure that users have only as much access as they need to perform their tasks. In particular, be wary of assigning the SUPER privilege to individual users, as this level allows users to manipulate basic server configuration and access all databases.Tip: Use the SHOW PRIVILEGES command for each user account to audit your grant tables and see if the use of wildcard permissions is appropriate.

Step 2: Require the use of secure passwords

User accounts are only as secure as the passwords used to protect them. For this reason, the very first thing you should do when you install MySQL is assign a password to the MySQL root account (empty by default). Once you’ve closed this gaping hole, the next step is to require that every user account must have a password and ensure that passwords do not use easily-recognisable heuristics such as birthdays, user names or dictionary words.Tip: Use the MySQL –secure-auth option to prevent the use of older, less secure MySQL password formats.

Step 3: Check the permissions of configuration files

Very often, to make server connections faster and more convenient, both individual users and server administrators store their user account passwords in their per-user MySQL options file. However, this password is stored in plain-text within the file and can easily be read. Therefore, it’s important to ensure that such per-user configuration files are not viewable by other users of the system, and are stored in non-public locations. Ideally, you’d want the per-user configuration to be stored in the user’s home directory with permissions 0600.

Step 4: Encrypt client-server transmissions

An important issue in the MySQL (and any) client-server architecture involves the security of data being transmitted over the network. If client-server transactions take place in plaintext, it is possible for a hacker to “sniff” the data packets being transmitted and thus gain access to sensitive information. You can close this hole either by enabling SSL in your MySQL configuration, or by using a secure shell utility like OpenSSH to create a secure encrypted “tunnel” for your data to pass through. Encrypting your client-server connection in this manner makes it extremely hard for unauthorised users to read the data going back and forth.

Step 5: Disable remote access

If your users don’t need to access the server remotely, you can significantly reduce the risk of a network attack by forcing all MySQL connections to take place via the UNIX socket file. This is accomplished by starting the server with the –skip-networking option. Doing this blocks TCP/IP network connections to MySQL and ensures that no user can remotely connect to the system.Tip: An enhancement to this would be to add the directive bind-address=127.0.0.1 in your MySQL server configuration, to force MySQL to bind to the IP address of the local machine and thus ensure that only users on the same system can connect to MySQL.

Step 6: Actively monitor the MySQL access log

MySQL comes with a number of different log files, which keep track of client connections, queries and server errors. Of these, the most important is the general query log, which logs each client connection and disconnection with a timestamp, and also records each query executed by a client. If you suspect unusual activity, such as that associated with a network break-in attempt, it’s a good idea to monitor this log to gain an understanding of the source of the activity.Protecting your MySQL databases is an ongoing task, and so you shouldn’t rest easy once you’ve done the steps above. Visit the MySQL manual and the MySQL forums for more security tips, and be proactive in monitoring and updating the security of your system. Good luck!