There are a number of security considerations regarding implementing and deploying workflows, such as who should be able to access a workflow in the first place. For example, you may have a document library that includes multiple workflows but may want to limit who can access one particular workflow without affecting permissions on the document library itself.
Other considerations pertaining to workflow comments, which are stored as part of the workflow history. By locking down a workflow’s workflow history list, you could hide those comments from non-participants.
Notes from the Field: Workflow Security and Column Design Consideration
By default, Workflow columns are created and added to the default view of a document library for each respective workflow created within the document library. However, you can modify the library’s view or create new views specific to a workflow to avoid having multiple workflow instances showing up in the default view. First of all, when a library has multiple workflows—for instance, workflows set on the library itself and/or workflows on multiple content types added to the library—the default view will become somewhat cluttered and hard to read. Second, you may not want all users who have access to that document library to view the status of all workflows. Remember, the Workflow Status page is respective to each item (or document) within a document library and includes access to the workflow approval form. It also lists workflow history.
Users who are in the members group of a site can still access a Workflow Status page. Even if those users haven’t been designated as approvers for a workflow, they can access the respective workflow approval form. However, when they attempt to approve a workflow, they will receive an error page with the message Task update was not accepted. The failed attempt to approve a workflow will be logged in the workflow history (for example, Task rolled back, Task updated by <username> was rejected). Users who are in the visitors group of a site can access a Workflow Status page, but will be challenged if they attempt to approve a workflow.
Best practice is to lock down the security on a document library when you don’t want everyone with access to the parent site to access workflows and/or workflow statuses. For instance, you may have a special document library that includes workflows for patent documents. Individual documents are within the document library, but this form of storage mechanism becomes tedious when a document library contains many documents and you need to give multiple users access to a workflow created on a document. Another option is to lock down the designated workflow task list. This will prevent users in both the members and visitors site groups from accessing Workflow Status pages. When you have multiple workflows and may want to limit access to each respective workflow status, create different tasks lists for each workflow and then lock down each respective task list. You cannot apply workflows to a folder within a document library, so any permissions you add to workflows will need to be done at the document library and/or list level or the document/item level within a document library and/or list.
Remember, the default workflow history and task lists are accessible to all users who have Read access to the site where those lists reside. So, if you choose to stay with the default lists for workflow history and tasks rather than create additional history and task lists, then you will need to lock down those lists.
Kathy Hughes, Microsoft MVP, SharePoint Server 2007
18.116.238.69