Security spans multiple layers in a CMS installation, from the operating system to the CMS Web application. Configuring security for a CMS site involves many configuration options on different levels. In this section, we will consider the settings that contribute to the security of the CMS installation. These settings apply to all CMS sites. Hardening Your ServersCMS servers, especially production servers, must be hardened to protect them from potential attack. When you build them, consider applying the following:
Enabling IPSecA CMS installation usually involves multiple servers communicating with each other. A simple example is when the CMS server and the SQL server hosting the CMS database are installed on different machines (Figure 20-1). Figure 20-1. Using IPSecIf you are using multiple machines, consider enabling Internet Protocol Security (IPSec) to encrypt traffic between them. Using IPSec does not require any changes to existing applications; IPSec provides IP-level security and is therefore transparent to applications. Using SSL and Obtaining CertificatesIf you want parts of your site to be HTTPS-enabled, you need to obtain certificates to be installed on the server side. For intranet sites, the certificates may be obtained from an internal certification authority (CA); for Internet sites, the certificates must be obtained from a globally recognized CA; for extranet sites, the CA may be internal, but it must be recognized by other partner companies that participate on the extranet. You need to install a server certificate on IIS, enable SSL on port 443, and then enable secure communications for directories where you need HTTPS. The SSL-enabled CMS site should use a separate Web entry point. CMS System AccountAs we discussed in Chapter 18, the CMS system account is used for Active Directory (AD) communication and for accessing data stored in SQL Server, on the file system, and in the registry. Because CMS services run under the CMS system account, any problems that this account encounters may, and probably will, cause a disruption in CMS services. The CMS system account may be a domain account or a local account. The best practice is to use an account with the least privileges. Don't use a domain administrator account or an IIS anonymous account as the CMS system account. Refer to Chapter 18 for instructions on setting up the CMS system account. The CMS system account must have:
NOTE: For CMS database access, you can use either SQL trusted authentication or SQL authentication. It is recommended that you use SQL trusted authentication so that the CMS database is accessed with the CMS system account security context. However, in certain scenarios, your company policy may prohibit propagation of a security context between applications installed on different machines and separated by a firewall. If this is the case, you need to specify the SQL server account to be used with the CMS database. If you use a local account as the CMS system account, then you must ensure that there is a matching local account on the SQL machine with a synchronized password. It is this local account, not the CMS system account, that requires permissions on the CMS database. In this case, SQL authentication is used. It is not advisable to use this account on any other databases on the same SQL server. On the SQL server machine, this local account must have the following privileges:
If your CMS site is deployed in a Web farm (Figure 20-2) and you want to avoid using a domain account as a CMS system account, make sure that each machine has identical local accounts, with synchronized passwords, set up as the CMS system account. In turn, this account must match the local account on the SQL machine. Figure 20-2. CMS Web farmSetting Up Web Entry PointsTo minimize the surface of a potential attack, consider separating the CMS production sites from the authoring site. On the production sites, configure the IIS virtual site as a read-only CMS Web entry point. On the authoring site, configure the IIS virtual site as a read/write CMS Web entry point. If your authoring and production sites share the same machine, consider using two network interfaces. For example, the production site can be installed on the IIS site using an external interface with an external IP number, while the authoring site can be installed on the IIS site using an internal interface with an internal IP number. The first site should be configured as a read-only CMS Web entry point, and the second site as a read/write CMS Web entry point. You can also consider using a port other than 80 for a read/write CMS Web entry point. Refer to Chapter 18 for details on configuring CMS Web entry points. Removing ComponentsTo minimize the surface of a potential attack even more, consider removing unnecessary authoring and management CMS components from the production servers as follows: Web Author, Authoring Connector, Site Manager, and Site Deployment. To uninstall these components, run the setup program and remove them from the list on the Custom Setup page. We discussed in Chapter 18 that each CMS server must have the SCA installed for configuration purposes. However, once the server has been configured, you can stop the Web site where the SCA has been installed. When you need to change configuration settings using the SCA, restart this Web site, make the changes, and then stop it once again. |