Server Clusters: Security Best Practices, Windows 2000 and Windows Server 2003, General Assumptions

Applies To: Windows Server 2003 with SP1

Published: January 1, 2003

Also In This White Paper

Server Clusters: Security Best Practices, Windows 2000 and Windows Server 2003, Deployment and Operations

General Assumptions

There are a number of general assumptions and operational best practices that should be in place for the infrastructure to ensure a secure environment in which to run server clusters.

  1. Servers and storage are in physically secure locations.

  2. Practical security implementations to detect irregular traffic, such as firewalls, network probes and management tools, are in place.

  3. Best practices/common sense in terms of security are adhered to in areas like administration, storage of logs, backup and restore etc.

  4. Platform level security best practices are adhered to in terms of assigning administrative permissions, ACLing resources, and other housekeeping roles.

  5. The network infrastructure services such as Active Directory, DNS, DHCP, WINS etc. must be secure. Any compromise of these infrastructure services can lead to a compromise of the cluster service itself.

  6. The cluster administrator must ensure that applications that call the cluster APIs (ClusAPI) are run from trusted computers. Any compromise on the computers on which the applications are executing (that the cluster administrator runs) can compromise the cluster. For example, if there are untrusted users with elevated privileges on the workstation from where the administration tools are run, untrusted or malicious code can be run against the cluster by the cluster administrator without the cluster administrator realizing.

  7. Access to the set of objects created and maintained by the cluster service must not be compromised by adjusting the default settings placed on these objects to a less restrictive setting. The cluster service utilizes a set of objects in the operating system such as files, devices, registry keys etc. These objects have a default security setting that ensures non-privileged users cannot impact the cluster configuration or the applications running on the cluster. Changing these security settings to less restrictive security settings can lead to the cluster being compromised and the application data being corrupted.