NOTE: This series of articles are written as introduction to complex subjects. They are general in nature and highly condensed. They are not intended to be legal advice or counseling in individual cases and cannot substitute for consultation with a knowledgeable attorney or other competent adviser.
| |
Part 1: Introduction
|
|
|
Part 2: Separation of Duties
|
| |
Part 3: Documentation
|
| |
Part 4: Approvals
|
| |
Part 5: Testing
|
| |
Part 6: Auditing
|
| |
Part 7: Summary and Review
|
In part 1 of this series, we looked at Section 404 of the Sarbanes-Oxley Act of 1999 and how it impacts IT departments. In this section, we'll look at the security requirements of SOX and how to configure user and role security and permissions for the TFS server, individual team projects, Windows SharePoint Services, SQL Server Reporting Services, and Windows. We'll also take a look at the Team Foundation Server Administration Tool and the TFS Permission Manager, both of which can help centralize and manage security administration.
Separation of Duties is a cornerstone of SOX, requiring that no one individual have control of every aspect of a business process. Responsibilities should be assigned to individuals in such a way as to encourage checks and balances within the system and minimize the opportunity for unauthorized access and fraud.
Team Foundation Server is well grounded on the principles of security: Identification, Authentication and Authorization through the use of Users, Groups and Permissions. By default, Team Foundation uses NTFS authentication, and can also use basic or digest authentication as well as SSL and ISAPI filters.
Permission delegation in team Foundation Server is multifaceted and complex because Team Foundation Server is not an application, it is a platform. In this installment of our series on SOX 404 compliance, we'll take a look at security, permissions, and recommended settings at the server and project levels, as well as source control, areas and iterations, work items, Team Build, and finally SharePoint Project Portals and SQL Server Reporting Services. In closing, we will take a look at the tools available to manage security both within Team Foundation and across the platform.
Server Security
The first step is to properly secure Team Foundation at the server level. Out-of-the-box, Team Foundation Server provides a good baseline for defining separation of duties at the server level with global groups and permissions.
Default Groups
Team Foundation Server is installed with three default security groups:
- Team Foundation Valid Users
- Team Foundation Administrators
- Service Accounts
The Group Membership dialog allows for the creation and deletion of the server-level groups, as well as the ability to define groups and users within the global groups. It is important to remember that groups can be defined in a hierarchical manner. The hierarchy for the first two levels is:
These default groups largely suffice in creating a high-level separation of responsibility: administrators are allowed to administer the server; and users are allowed to use the server.
For a full list of the default groups and assigned permissions within Team Foundation Server, visit the Team Foundation Server Default Groups, Permissions, and Roles article on the Microsoft Web site.
Permissions
Team Foundation facilitates setting permissions assigned to global users and groups. The permissions include the ability to create new projects, edit server-level information, and administer the data warehouse. These permissions along with the default settings are:
|
Valid Users
|
Administrators
|
Service Accounts
|
|
Administer shelved changes
|
|
|
|
|
Administer warehouse
|
|
|
|
|
Administer workspaces
|
|
|
|
|
Alter trace settings
|
|
|
|
|
Create a workspace
|
|
|
|
|
Create new projects
|
|
|
|
|
Edit server-level information
|
|
|
|
|
Manage process template
|
|
|
|
|
View server-level information
|
|
|
|
You may wish to evaluate your organizational process, and create additional global groups to further segregate the administrative duties assigned by these permissions. For example, you may want to limit Alter Trace Settings rights to systems administrators, and Create New Projects rights to Project Managers. To do this, since the Administrators rights cannot be modified, you would create new groups to assign users and roles to.
How to Define Permissions
Server level permissions can be defined in Team Explorer by right-clicking on the server node and choosing Settings | Security, or by using the TFSSecurity command line tool which is discussed in Utilities section later in this chapter.
For more information, visit the Team Foundation Server Permissions on the Microsoft Web site.
Suggested Permissions
The following table outlines suggested permissions and roles at various project levels in Team Foundation Server. This is only meant to be a guide, and should be tailored to your specific organization.
Project Security
The second and more granular level of security is the team project level. The project-level groups are implemented in the process template, and users and permissions can be set on a per-project basis. One exception is any user who is a member of a global server group will automatically become a member of all team projects.
Default Groups
Team projects are created with four default groups which are members of the Valid Users group:
- Readers
- Project Administrators
- Contributors
- Build Services
For true separation, and because these groups are also used to secure areas, iterations, and source control, more descriptive groups are required. Microsoft provides suggested group names for both the Agile and CMMI templates at the bottom of the Team Foundation Server Default Groups, Permissions, and Roles article on the Microsoft Web site. While this is a good generalization, and the CMMI suggested groups are used below for the suggested permissions, it is further suggested to evaluate your internal process and the roles already defined within your organization when creating groups in Team Foundation Server. This not only tailors the groups to your structure, but simplifies the understanding and traceability of Team Foundation Server across your team and entire organization.
Once the groups have been determined, the process template should be updated to both record this decision, and prevent manual group creation effort every time a new team project is created. We will discuss setting default groups in the project template in the next section.
Permissions
Permissions assignable to these groups:
- Administer a build
- Delete this project
- Edit build quality
- Edit project-level information
- Publish test results
- Start a build
- View project-level information
- Write to build operational store
Separation of Projects
When a user or group is added to a TFS group, the user is automatically added to the Valid Users server group, which has View Project Level Information by default. What this means is that any user will be able to see any project. If your organization requires user/project restriction, you must remove the View Project Level Information right from the Valid Users server group manually for each project that is created.
Areas
Areas in Team Foundation are used to represent various pieces of the solution. The recommended approach is to use leaf nodes to represent project deliverable, and non-leaf nodes to represent project competencies. Area-level permission can be set in Team Explorer or through the TFSSecurity utility. Note however that areas cannot be required fields for work items, however.
Suggested Permissions
The following table outlines suggested permissions and roles at various project levels in Team Foundation Server. This is only meant to be a guide, and should be tailored to your specific organization.
Iterations
Iterations are used to represent a project's timeline breakdown. Iteration-level permission can be set in Team Explorer or through the TFSSecurity utility. Note however that iterations cannot be required fields for work items.
Suggested Permissions
The following table outlines suggested permissions and roles at various project levels in Team Foundation Server. This is only meant to be a guide, and should be tailored to your specific organization.
Project-Level Suggested Permissions
The following table outlines the rights available at the project level and suggested roles and rights assignments. This is only meant to be a guide, and should be tailored to your specific organization.
Process Template
Team Foundation Server is a process agnostic lifecycle platform which uses process templates to define a specific development process. Two process templates are installed by default; Agile, which defines a lightweight, low-ceremony process; and CMMI, which defines a more document-centric, high-ceremony process. While these two templates contain well-defined process definitions, most teams find the Agile template to be too relaxed and the CMMI template to be too restrictive. The real value in these templates is through customization to adapt to your existing process.
We are going to look at two areas of the process template related specifically to security: groups and permissions and source control. Work items, which are also an integral part of a process template, and compliance in general, will be discussed in the Approvals part of this series.
Groups and Permissions
In the Project Security section above, we looked at groups and permissions on a project-by-project basis. In the process template, however, you can define default users, groups and permissions to be applied to each new project when it is created. Along with having to perform less manual effort for each team project, defining groups and permissions in a process template also helps to promote reusability and transparency.
For each group, there are a set of permissions and areas where the permissions apply. Detailed descriptions of these permissions and areas can be found in the Groups and Permissions Process Template Plug-In article on the Microsoft Web site.
Suggested Permissions
The following table outlines the rights available in the Groups and Permissions section of a project template and suggested roles and rights assignments. This is only meant to be a guide, and should be tailored to your specific organization.
One thing to remember with project-level permissions is that the PROJECT DELETE_TEST_RESULTS, PROECT CHECK_IN, NAMESPACE MANAGE_EVERYONE_GROUP, and NAMESPACE CHECK_IN are not valid for the Agile or CMMI included process templates.
Source Control
Source control permissions can be set on files and folders from within Team Explorer or from the Tf command line utility. While it is not possible to set default source control permissions from the Process Template Editor, you can manually edit the 'Version Control\ Version Control.xml' file in the process template.
Along with setting default permissions, it is also suggested to evaluate your source control tree at various stages of development to determine if any additional rights should to be applied to a particular source tree node. For instance, you may only want users who are members of the Testers group to be able to check-in and check-out code from a test project.
Suggested Permissions
The following table outlines suggested permissions and roles at various project levels in Team Foundation Server. This is only meant to be a guide, and should be tailored to your specific organization.
SharePoint Project Portals
Windows SharePoint Services (WSS) is utilized by Team Foundation Server as a collaboration portal to house project documents such as requirements, designs, Excel spreadsheets, and more.
Roles and Permissions
SharePoint portals are created with four default roles and permission levels
- Administrator (Full Control) – has browse access to the project portal.
- Web Designer (Design) – can add new content to existing document libraries and lists.
- Contributor (Contribute) – Can create new document libraries and lists, as well as customize pages.
- Reader (Read) – Has full access to the project portal.
Suggested Permissions
The following table outlines suggested permissions and roles for Windows SharePoint Services. This is only meant to be a guide, and should be tailored to your specific organization.
Reporting Services
All data for Team Foundation Server is stored in a SQL Server data warehouse. This makes it ideal to use SQL Server Reporting Services to create and provide reports based on the stored data.
Roles
There are two site-wide and four project-level roles built-in to SQL Server Reporting Services.
Site-Wide Roles
- System Administrator
- System User
Project-Level Roles
- Browser
- Content Manager
- My Reports
- Publisher
- Report Builder
Permissions
Permissions (Reporting Services tasks) are granted to the predefined roles outlined in the previous section.
Suggested Permissions
The following table outlines suggested permissions and roles for SQL Server Reporting Services. This is only meant to be a guide, and should be tailored to your specific organization.
Service Accounts
In a compliance environment, it is important to regulate service accounts in addition to users and groups. For more information about managing service accounts, visit the Managing and Resetting Service Accounts and Passwords page on the Microsoft Web site.
Utilities
There are several utilities that can assist in creating and modifying users, groups, and rights.
Microsoft
- TFSSecurity – A command line utility installed with Team Foundation.
- Tf – A command line utility installed with Team Foundation for working with source control.
Microsoft Israel
- TFS Permission Manager – A graphical utility to administer permissions across all three platforms: Team Foundation Server, SharePoint and SQL Reporting Services.
CodePlex
- TFSAdmin - A graphical utility to administer permissions across all three platforms: Team Foundation Server, SharePoint and SQL Reporting Services.
More Information
For more information about the topics discussed in this chapter, please visit the following resources.
Resources