Security Considerations with Team Project Collections
The decision to store team projects (TPs) in separate team project collections (TPCs) has implicit security aspects to it. Separating projects into multiple collections promotes security. To understand this, one must understand TFS’s topology.
Figure 1: TFS Logical Hierarchy
In TFS 2008 all of the team projects were stored in the same database. In 2010 this has changed; team projects are stored in team project collections, and each collection is stored in its own database.
This is often stated as a disadvantage of splitting projects into multiple collections, due to the fact that application-wise, you cannot cross the collection boundary. You cannot branch or merge code, query or link work-items, share project templates (though you obviously can clone definitions from one collection to the other). Also, Visual Studio can only connect to one collection at a time.
These disadvantages have a silver lining though: Security through isolation. Each collection runs in its own sandbox, and information in one collection doesn’t run the risk of leaking into another. Say, for example, that you split your TPCs along the lines of customers (each customer has his own collection). As a client, you’d want to be sure that work items and code will not be available to other clients – imagine what would happen if a client could gain information through the web-access or SharePoint portal!
Beyond the security afforded at the application level by the aforementioned “limitations”, and the fact that each collection has its own security and permission management (as does each project), the security can be further tightened by constraining access to the data at the database level, or even storing each collection on physically separate database altogether.
To summarize, separating projects into different collections, isolates them and thus promotes the security of the information stored there.
Tags: ALM TFS Team System Architecture