CMS Installation Security

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 Servers

CMS servers, especially production servers, must be hardened to protect them from potential attack. When you build them, consider applying the following:

• Windows 2000 high security template: There is a CMS version of a high security template that can be installed from the CMS installation CD. If you use a standard Windows 2000 high security template, after the template has been applied, make sure you manually grant the account that the ASP.NET worker process runs under rights to the %temp% folder. For example, the Publishing API relies on this account's rights to the %temp% folder.

• CMS-customized version of the IIS Lockdown Tool and URLScan: To customize the IIS Lockdown Tool for CMS, replace the iislockd. ini and urlscan_cms.ini files in the IIS Lockdown Tool with the files with the same names that are provided on the CMS installation CD. The CMS version of the IIS Lockdown Tool removes support for File Transfer Protocol (FTP), Simple Mail Transport Protocol (SMTP), and Network News Transfer Protocol (NNTP). It disables the following services: Index Server Web Interface, server side includes, Internet Data Connector, Internet Printing, HTR Scripting, and Web Distributed Authoring and Versioning (WebDAV). It also removes MSADC, IIS Admin, and IIS Help.

  The CMS IIS Lockdown Tool enables URLScan. URLScan screens HTTP requests and can reject them based on specific criteria, thus reducing the exposure to possible attacks.

• Microsoft Baseline Security Analyzer (MBSA): MBSA is a general tool that scans your system for common security configuration problems, missing patches, and hotfixes. It is not CMS-specific.

Enabling IPSec

A 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 IPSec

If 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 Certificates

If 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 Account

As 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:

• Read rights for the AD domains where members of CMS rights groups are located.

• The db_datareader and db_datawriter database roles assigned on the CMS database. Using an import function in site deployment also requires a db_ddladmin role. In this case, SQL trusted authentication is used.

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:

• Access this computer from the network

• Log on as a batch job

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 farm

Setting Up Web Entry Points

To 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 Components

To 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.