What is the optimum way to secure a company wide wiki?

We have a wiki which is used by over half our company. Generally it has been very positively received. However, there is a concern over security - not letting confidential information fall into the wrong hands (i.e. competitors).

The default answer is to create a complicated security matrix defining who can read what document (wiki page) based on who created it. Personally I think this mainly solves the wrong problem because it creates barriers within the company instead of a barrier to the external world. But some are concerned that people at a customer site might share information with a customer which then goes to the competitor.

The administration of such a matrix is a nightmare because (1) the matrix is based on department and not projects (this is a matrix organisation), and (2) because in a wiki all pages are by definition dynamic so what is confidential today might not be confidential tomorrow (but the history is always readable!).

Apart from the security matrix, we've considered restricting content on the wiki to non super secret stuff, but of course that needs to be monitored.

Another solution (the current) is to monitor views and report anything suspicious (e.g. one person at a customer site having 2000 views in two days was reported). Again - this is not ideal because this does not directly imply a wrong motive.

Does anyone have a better solution? How can a company wide wiki be made secure and yet keep its low threshold USP?

BTW we use MediaWiki with Lockdown to exclude some administrative staff.


Solution 1:

We use company-wide wiki. This is how we do it:

  1. We use LDAP for storage for username and kerberos for authentication. MediaWiki has extension for using LDAP.

  2. We locked down that IP address such that our offices in Canada and US has access to wiki, done on our firewall. Even though the wiki is on external IP address, the firewall only allows access from within offices and whomever vpn-ed in.

  3. In LocalSettings.php (wiki conf file), we made it such that you can't read pages unless you are logged in. However, we did allow some pages accessible without actually logging in.

  4. We also use 'accesscontrol' extension for restrict pages. We have some pages that only sysadmin team can see, so, if someone from NOC try to see that page, they will get 'access denied' page. This is all handled with AccessControl extension.

Before you start, you need to know how users are managed in your office. We have everything in LDAP. We groups like sysadmin, developers, NOC etc etc and users are assigned to those groups. So, it is easier to give or take away access based on the group they are in.

-F

Solution 2:

One obvious point, or so it seems to me, is if you want something that's very tightly locked down then are you sure you actually want a Wiki. Isn't a large part of the ethos of a wiki that it's as open as possible? Once you've moved far enough away from the original purpose then doesn't it sooner or later become a better idea to try a different tool that has a closer fit to start with rather than straining the one you have totally out of shape?