Protect It while you Build It

A long while back I typed up a post about test environments. For the same reasons, I need to explain how you can help prevent giving yourself and your users some headaches. Another contractor working SharePoint—I’d rather not call him a SharePoint developer even though it is his title—with a client has a production version of his application on an existing 2010 farm, but it isn’t functioning yet on Office 365 because of all of his coded customization (stuff we should have done out of the box with SharePoint). People continue to hit the site and request elevated rights over the read rights they already have. If they had no rights to the site, this would not be a problem.

The permissions mess is a much longer post, but I need to explain how you build your sites and apps. I immediately remove all permissions from a site, list, or library when I create it to give me time to build it correctly before exposing it to the rest of the users. Why?—

  • People shouldn’t see anything under construction, especially when there is a production version running elsewhere. It leads to mass confusion.
  • It allows you to screw everything up without others noticing. No one knows everything when it comes to SharePoint, and you may want to try a web part you haven’t used before. Do you really want everyone else to take notice that your web parts are all funky?
  • Rarely, should you have the exact same permissions on a site, list, or library that mirror the parent exactly, so you should be breaking inheritance anyway. Like all other basic IT security rules you should know, we want to grant rights based on the on the principle of least privilege. That means that you trim away access for people who don’t need it. People could need contribute rights to all of the other lists on a site, but if their role determines they should not be adding to the list you are making, you grant only read to the role they are in.
  • It really can help with testing purposes. You might need to cycle your testing folks through different permission groups separately before you go live, and it is just way easier to kill all of the other permissions until you are ready to go.

So please just stop. Think about what you are doing. Every setting in your list should have been addressed, and you should have made a conscious decision as to how you would configure that setting before you allow anyone access.

Author: Scott

Scott Brewster works for Data Analytics Solutions. He is got his Certified Knowledge Manager (CKM) credentials through the Knowledge Management Institute (KMI), and he has been working on both the farm administration and front end solution architecture of SharePoint since 2008.