One of the great ironies involved in developing Confluence is the fact that we’ve put a lot of effort into giving our wiki software the flexible, but easy to use permissions model that an enterprise would demand, but I seem to spend just as much time trying to convince people not to use it.
Ward Cunningham’s original wiki, and many of the sites that followed it, have no security at all. The whole premise of ‘wiki’ is that anyone can edit everything, because the value of serendipitous contributions from well-meaning passers-by outweighs the cost of vandalism. This level of openness is unlikely to appeal to an enterprise looking for a wiki to deploy internally, but it’s important to keep the principle in mind: wikis are successful because they remove barriers, not because they erect them.
Case in point. A while back I made a news post to my Confluence personal space on the Atlassian extranet, just before I left the office for the day, but I mistyped a link. By the time I got in the next morning, someone from the San Francisco office who knew what I was really trying to point to had fixed the link for me. If I had restricted editing to myself, that couldn’t have happened nearly as easily.
Security is about managing risk. If you apply a security measure without understanding the risk you are attempting to mitigate, chances are you’re going to end up with bad security.
So what are the threats against a wiki? Generally in information security, we are protecting three things:
* Confidentiality – people should only be able to see information they have permission to see.
* Integrity – the information should be safe from unauthorised modification
* Availability – the information should be accessible when it’s needed
How you protect confidentiality (which spaces and pages you allow which people to view) depends entirely on your needs. If you’re a company with an Apple-like adherence to secrecy, you’re going to want to make sure that each team is working entirely in isolation, and nobody can view anyone else’s spaces. Some of our more ‘interesting’ customers will even buy multiple instances of Confluence or JIRA because their security regulations prohibit different teams sharing the same database.
On the other hand, if you don’t have such a strategic or regulatory interest in keeping the left hand from knowing what the right hand is up to, a more open wiki gives you the perfect platform for interested people in your company to keep up with what is going on elsewhere, and for ideas to spread across the entire enterprise.
Integrity and availability are the two areas most commonly thought of as vulnerable in a wiki. If anyone can just come along and change something, the line of thought goes, how can that information possibly be safe? This might be fine for the online social experiments that are public wikis, but to a risk-averse enterprise customer, it seems it’s best to make sure that the only people who can edit a page are those who can be implicitly trusted with it.
I have two locks on the front door of my apartment. This is one of the security compromises that anyone living in a reasonably-sized community will make, and while you quickly get used to them, there are significant disadvantages. Everyone who wants to get into the apartment must carry keys around with them. You can’t just get someone to grab something from your apartment on their way in to work because you forgot it earlier. If your keys are stolen, you have to get the locks changed. Occasionally you might get locked out. Or you may break up with your girlfriend and then wait three months for her to give you your spare keys back.
But what if I could be notified the moment something was taken from my apartment, identify with certainty who took it, and get the stolen goods back undamaged with almost no effort? Ignoring privacy issues (which take us back to confidentiality), would it now be worth my while to mess around with keys?
In an enterprise environment, where every contributor to the wiki is identifiable, and every change reversible, what value remains in restricting edit rights _a priori_?