1) HSMs are certified, and are relatively robust against individual employees (if configured that way). With anything else, administrators of the system are likely to be able to get access to key material. But a pain to work with, and expensive.
2) Offline key management -- e.g. a laptop in a safe -- was the low end solution for a long time. However, there are a lot of reasons why you want an online CA now
3) Just keeping a key in memory on a machine (doing nothing special) obviously exposes you to several risks:
a) Administrator (can be remote; incl compromise of laptop of admin)
b) Anyone who gains root on the box
c) Application-level security issues (ranging from key leakage to just compromising the application.
d) Physical-access cold boot (which can be more exciting in a virtualized environment)
There are a bunch of ways to improve #3, although it will remain worse than #1 or #2.
a) Simply run the keys in a different process; this protects you against some minimal things, and if you use a PKCS 11 interface, makes upgrading to an HSM later easier.
b) Different user, with a defined interface
c) Different VM
d) Physically separate machines communicating over a bidirectional link (you could do this as two ethernet connections)
e) Two one-way links bound to specific programs (e.g. serial); much harder to compromise both this way. You'd need to compromise the "send commands" program, and "receive commands" program, and the "send response" program. They can be very limited in what they do.
Limiting admin access to physical-presence, or at the very least via a secure pathway which isn't direct to the machine (e.g. a console server which logs) goes a long way, too.
2) Offline key management -- e.g. a laptop in a safe -- was the low end solution for a long time. However, there are a lot of reasons why you want an online CA now
3) Just keeping a key in memory on a machine (doing nothing special) obviously exposes you to several risks: a) Administrator (can be remote; incl compromise of laptop of admin) b) Anyone who gains root on the box c) Application-level security issues (ranging from key leakage to just compromising the application. d) Physical-access cold boot (which can be more exciting in a virtualized environment)
There are a bunch of ways to improve #3, although it will remain worse than #1 or #2.
a) Simply run the keys in a different process; this protects you against some minimal things, and if you use a PKCS 11 interface, makes upgrading to an HSM later easier.
b) Different user, with a defined interface
c) Different VM
d) Physically separate machines communicating over a bidirectional link (you could do this as two ethernet connections)
e) Two one-way links bound to specific programs (e.g. serial); much harder to compromise both this way. You'd need to compromise the "send commands" program, and "receive commands" program, and the "send response" program. They can be very limited in what they do.
Limiting admin access to physical-presence, or at the very least via a secure pathway which isn't direct to the machine (e.g. a console server which logs) goes a long way, too.