More and more, organizations are looking to ensure that there is an appropriate level of encryption in their systems. That means using certificates for the encrypting of network connections (in other words, using SSL) as well as encrypting the information within a system (eg. encrypting databases or columns within a database). But, as more and more certificates are being used, it’s important to start to consider how you are going to manage all these certificates (and keys, if you are using them). So, to that end, I thought I provide some thoughts on design points for putting in place a PKI solution.
One very important thing to remember when talking about certificates is that you don’t necessarily need a PKI solution to generate them. When you put in place a Server or solution, you can often make use of self signed certificates (certificates that are generated by the system itself). This is a very valid way to deal with encryption and authentication of the system. But you have to remember one thing; certificates have expiry dates. And the more certificates that you have to deal with and manage, the higher the chance that you are going to forget one and the solution will fail.
This brings in PKI solutions. At it’s core, a PKI solution is meant to centralize the management of keys and certificates. Doing that allows you to ensure that you won’t have certificates expiring without knowing about it. It also allows for the security team to ensure that there is a consistent use of whatever your organization’s encryption policy is.
If you ask any Architect worth their salt, they will tell you that every solution will have 3 components; People, Process, and Technology. I chose to add a 4th which is governance. So let’s talk about each for this article.
First, let’s start with Technology since everyone only wants to talk technology. The things you need to think about are as follows:
- Certificate Authority Operating System – Most people will use a Windows Server as their base OS for the CA. But you’ll want to think about whether you have the capabilities in house or whether you want to use a cloud solution, of which there are a number of very good ones available (Verisign and Entrust come to mind right away but that’s only two of many).
- Certificate Authority (CA) structure – every PKI solution has a certificate authority, the system that “owns” the certificates that are generated. But because these are systems that are literally owning the keys to the kingdom, you have to be very careful about how you structure this. There will always be a Root CA, which is the CA at the top of the authority heap. Each CA in the structure will report to the Root CA. But you don’t necessarily want to have the Root CA doing all the work. You want to protect it. So you’ll create a Intermediate CA or an Issuing CA which does the actual key and certificate generation on behalf of the Root CA. So you want to think about what your CA structure looks like.
- Algorithms – Each certificate and key is generated based on an encryption algorithm. You decisions have to be along the lines of how many bits the certificates and keys need to be and the algorithm that is used to generate them.
- CA Database – this is where the CA will store the generated certificates and keys. Some organizations will use a HSM for the storage but you can use a standalone database just as easily that you can take offline with ease when NOT generating keys and certificates.
- Active Directory – Active Directory is used for the authentication of users that interact with the solution. At this point you want to be thinking about the types of roles interacting with the PKI solution.
Also think about how you are going to do backups and recovery of your Subordinate CA and whether you want to keep the Root CA offline. Plus, you may want to
You may also want to think about a technical component that you can use for managing the workflow of generating and managing the certificates and keys. So, rather than do this manually, if you get enough requests, you may want to put in this solution. Venafi is a vendor that provides this type of solution.
Next, let’s talk People. A PKI solution needs to be managed and that needs to have a clearly defined RACI. So, typically, I’ll have the following roles; System Owner, System Admin, Security Analyst, Requestor (of the keys/certs), Approver, and Auditor. Break down the various actions associated with the PKI and indicate which role will be involved each of those activities. Remember, there is a workflow associated with asking for, and receiving, keys and certificates so you want to define who can do what.
Finally, let’s talk about the actual processes. Things you want to be designing around are:
- the Request process – who receives the requests and how are they processed?
- the Approval process – who approves the requests and initiates the generation?
- The Creation process – who generates the keys/certificates and how do those generated keys/certificates get to the Requestor?
- The Management processes – who manages the PKI solution and the individual components? That’s not necessarily the same person that does the actual creation process.
- And, finally, the Governance process – who audits and ensure that the company PKI policies are being followed?
This is only some information that you can use for putting in a PKI solution. And PKI can be very complicated so you have to really map out how you want the PKI solution to look.
Hope this helps …