July 17, 2013

Security Notes for Replica Servers


security lockFrom time to time, people ask me how replica servers affect the security of their Perforce installation.

The good news is that, properly deployed and configured, a replica server is just as secure as your main Perforce server.

It's usually the case that your Perforce server is the most important and valuable server in your entire organization: after all, this is where you are storing everything that you have developed, and everything that your team values! So I'm pleased that you are thinking about security and wondering how replica servers fit into your security process.

If you're just getting started with replica servers, now is a great time to get off on the right foot, and ensure that your replica servers don't introduce any new security issues into your installation.

Here are a few notes to keep in mind as you plan for replica server deployments:

A replica is a server, too.

Unlike proxies and brokers, a replica server is a complete Perforce server instance, with its own metadata database and (usually) its own set of archive files.

Your replica server's database contains an exact copy of the users, user groups, and protections that you have defined for your master server, and the replica enforces these protections identically, since it is after all a complete Perforce server.

When deploying a replica server, you should use the same standard practices that you use for your master Perforce server, including:

  • Ensure the physical security of the machine. Deploy your replica server to a machine which is as physically secure as your master server. Non-privileged users should not have direct access to the replica server machine (keep it in a locked room), nor should those users routinely log on to the replica server. Your users can use the same tools (P4V, P4Web, the P4 command line, etc.) to access the replica server as they use to access your master server. Keep your replica checkpoints and journals as secure as you keep the checkpoints and journals from your master server.
  • Enable server logs, retain them, and monitor them. Your replica server should be configured with the same level of access logging that you use for your master server. Retain your replica logs for an appropriate period of time, and inspect them, just like you would with your master server logs. For example, when you check your master server logs to look for unusual patterns of login command failures, to see if some unauthorized users might be trying to access your master server, ensure that you make the same checks of your replica server logs.
  • Run your replica server at the same security level as your master server. If your installation has grown to the point where you are deploying replica servers, you have become a large enough organization that you should be running all your servers at security level 3. A simple p4 configure set security=3command specifies that your master server and all replica servers should use this setting.

The great thing about replica servers is that, since they are normal Perforce servers, all of the techniques, skills, and processes that you have developed for securing your master server apply equally to all of your replica servers.

So you're already fully prepared to secure your replica servers!

Use Service Users

Your replica server needs to communicate directly with your master server. Server-to-server connections, such as those used by the replica's pullthreads, should be secured to ensure that only an authorized replica server has access to your master server.

The steps for configuring service users are clearly described in the System Administrator's Guide.

Give each replica server its own service user account, and monitor your servers regularly to ensure that the service user configurations are being used as you intended.

Use SSL Connections

It's not uncommon to deploy replica servers into remote sites in your organization. Depending on your organization's network configuration, these remote sites may have highly secure communications pathways back to your master server, such as that provided by a Virtual Private Network (VPN).

If you have concerns about the network security between your replica server and your master server, you can (and should) enable SSL network security for the server-to-server communications between the replica and the master.

Using SSL for replica-to-master connections is straightforward:

  1. Enable SSL connections on your master server
  2. Issue the p4 trustcommand on your replica so that it knows it can trust the master's SSL footprint
  3. Specify the ssl:prefix in your replica's P4TARGETsetting.

That's it! For the full step-by-step instructions, see this great article.


We're here to help

If any of these notes concern you, or if you think you've got special considerations and would like to talk them over with us, don't hesitate to contact Perforce Technical Support. We're glad to explain all the details, and help you ensure that your Perforce server is safe and secure.

Remain Vigilant

As with any computer security situation, maintaining the security of your Perforce server is an ongoing process. Security is, unfortunately, not a simple "set it and forget it" type of thing, but rather something that you should always be thinking about when you are managing a server as valuable as your Perforce server.

So configure your servers carefully, stay vigilant, and enjoy Perforce!