Best Practices for Security

Article
11/12/2009

It is strongly recommended that you follow the best practices listed in this topic in order to ensure a secure Commerce Server installation.

Install Commerce Server using Windows Authentication.

If you do not accept the default installation options, and instead install Commerce Server using SQL Server Authentication, your deployment may contain security risks. For information about these security risks, and steps you must take to secure your site, see Important Security Notes.

It is recommended that you do not configure some Commerce Server resources to use SQL Server Authentication to access your databases and other resources to use Windows Authentication. All resources should use the same security method.

The following issues apply to specific configurations:
- If SQL Server is remote, and you are using Windows Authentication to access your databases, you must map the IIS anonymous account to a domain account.
  
  If you are using a remote SQL Server and Windows Authentication, you must map the IIS anonymous account (the default is IUSR_computer) to a domain account. You must then create a SQL Server login for the domain account that has full access to the Commerce Server run-time databases.
- If SQL Server is local, and you are using Windows Authentication to access your databases, you must assign SQL Server permissions for the account used for the IIS anonymous account.
  
  SQL Server requires the IIS anonymous account to have permissions to the data store.
  
  You might set up this configuration if, for example, you are a developer and you have installed all the required software on one computer.
Use detailed settings for accounts configured with CatalogReader.

When setting up user accounts configured with the CatalogReader security role, you must use specific, detailed user security settings. This practice will prevent users from viewing any data in the catalog database.
Set an owner password and a user password when saving a Model Builder DTS Task.

When saving a Model Builder DTS Task, it is recommended that you set an owner and user password for the package to protect the information in the package from unauthorized users. The owner password prevents an unauthorized user from modifying the package and embedding malicious code for execution. The owner password allows a user to open, view, and edit a package. The user password allows a user to execute a package—it does not allow a user to view or edit the package definition.

Note
- If you set the user password, you must also set the owner password. This option is available only for packages saved in SQL Server or saved as structured storage files.
For Business Desk users, configure IIS for Basic Authentication.

When Business Desk users run reports, they access data from the Analysis Services database. To use Analysis Services over HTTPS, Business Desk users should be authenticated using Basic Authentication (which passes Windows 2000 credentials).

When passing Windows 2000 credentials over the Web, use HTTPS to ensure that the Windows account and password are secured.

Note
- When Business Desk users run reports and access Analysis Services over HTTPS, their valid Windows 2000 user ID and password are stored in the HTML of the Business Desk. For more information, see Accessing the Analysis Server Over HTTPS.
In a multi-server deployment in which you use AuthFilter, you must use Microsoft SQL Server Authentication for the connection string to the Administration database.

This scenario is as follows:
- Deploy Commerce Server using Windows Authentication.
- Use SQL Server (instead of Microsoft Active Directory).
- Use AuthFilter.
- Change the connection string to the Administration database to SQL Server authentication.
When using AuthFilter in this scenario, you must change the connection string to the Administration database because the ISAPI filter (and hence AuthFilter) is running in the security context of the IIS process (inetinfo), known as LocalSystem. Therefore, AuthFilter tries to connect to the SQL Server on another computer, using credentials from LocalSystem, which is invalid; AuthFilter does not have the rights to make connections across a network. (If the Administration database is local, the connection would work, but you should never locate the Administration database on the Web server.)

This scenario does not apply if you use Internet Information Services 6.0.

For more information, see Using Windows Authentication in a Distributed Environment.
In environments with multiple sites, do not allow script uploading.

Unless the uploaded script is carefully monitored, there could be security risks in the uploaded script code.
Do not trust user input directly

You should never trust user input directly, especially if the user input is anonymous. For more information, see Do Not Trust User Input Directly.
Run with least possible privilege

Users and executable processes should run with the lowest level of privilege that is required to perform their tasks. For more information, see Running with Least Privilege.
Configure IIS to disallow access to files with a .PCF extension (Pipeline configuration).

In Commerce Server 2002, Pipeline configuration is stored in a file with a .PCF extension. For example, the basket pipeline may be Basket.pcf. For deployment purposes, these files are typically stored within the virtual directory for the Web site. For this reason, you should configure IIS to disallow access to files with a .PCF extension.
Configure Event Logs to support Rolling Event Logs.

The recommended configuration for Event Logs is Rolling Event Logs. If the Event Log has been re-configured to not support rolling event logs, the Event Log could fill up, potentially causing a denial of service for the server.

Best Practices for Security

See Also

Additional resources