The problem that the heartbleed attack demonstrates is that people's private keys are available to a server that is also available (via heartbleed) to the attackers.

Ideally you'd want your TLS keys to be stored in an HSM(hardware security module), where if your machine is compromised they cannot be extracted.   Usually this can be done via PKCS#11, an standard API for asking something else to do the crypto operations for you. This is plausible for client applications on devices with TPMs (eg Thinkpads), but the builtin TPMs are extremely slow, and are not usually available on servers. For example for storing things like client SSH keys, this is ideal.  (You don't need to use the Platform Configuration Registers which is the bit that most people object to, and ideally you'd get a "real" HSM, not just reuse the TPM as a HSM.).

Ideally what you want to do for a web farm is to have a software daemon that pretends to be a HSM, which runs as a separate user than your webserver.  When your webserver needs a crypto operation done that involves your private keys, it asks the software HSM to do the operation for it.  Thus, even if an attacker gains access to the user the webserver is running as (eg remote code execution), they cannot just read out the TLS keys, and probably also the password used to encrypt them from the config file!  If the softHSM running as a separate daemon in a second user account, they need to be able to access that second user (eg by exploiting bugs in the kernel etc) to get the keys, which is a much higher bar (and is not provided for by things like heartbleed).  The attacker, if they did get full access to the webserver account could ask the softHSM to do the operations for it, but when combined with Perfect Foward Security, this doesn't really buy the attacker much that they didn't get just by sniffing the unencrypted streams they already have access to.  If you wanted to later upgrade the security of your machine (eg, you have a TPM added to your server), you could swap out the software HSM's PKCS#11 driver library for your "real" HSM PKCS#11 driver, which is a small configuration change.

Unfortunately, at the moment all the softHSM's I've looked at operate as a shared library, and thus still have problems with key leakage.  I have also not been able to figure out how to get any of the webserver SSL configurations to actually use PKCS#11. So far they only seem to allow you to say "I want to use PKCS#11" but then don't let you configure anything that you need to such as ... which PKCS#11 module to use, or what the User PIN for the HSM is, or which slot, token or certificate to use within the HSM.  The current state of the art appears to recompiling to configure much of this.  Hopefully I'm wrong here.

Heartbleed is bad, but it's not going to be the last bug that we ever see that gives access to the webserver account.   There's going to be bugs in protocol handling (either TLS, or perhaps in new HTTP/2.0 implementations) and there's going to be bugs in websites that mean that file contents are leaked, or allow for varying degrees of remote code execution.  

The best fix here is to not expose your keys to the same process that is exposed to the Internet.  The best standard we have today for this is PKCS#11.  To do this we need a software daemon based PKCS#11 that can run as a separate user and a driver PKCS#11 module for it (communicating over, say, a unix domain socket, perhaps dbus or something), and we need to have webserver vendors support PKCS#11 as a first class citizen in their configuration.