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.
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?
We use company-wide wiki. This is how we do it:
We use LDAP for storage for username and kerberos for authentication. MediaWiki has extension for using LDAP.
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.
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.
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
You need to make it clear what is appropriate and what isn't appropriate for posting if you're going to use something like MediaWiki. That's about all of the security that you're going to get.
If your business requirements mean that you need complex ACLs, you need to look at a solution designed for it. SharePoint, Traction, Alfresco and SocialText are all products that can do that.
It all depends on the organization... don't make policy based on the product that you decided to use for a random reason.
I had the exact same problem, and came to the same conclusion as Robert. Upon researching further, there are wikis that do have complex ACLs, giving you the benefit of both worlds. But in this case, its probably best that you keep your wiki, but have another tool for all the "secure" items.
We tried Mediawiki because of the idea that Wikipedia uses it, unfortunately maintaining it is harder than we expected, especially as we implemented more and more extensions. In the end, we wished that we used a different wiki engine that might not have been as ambitious, but with an easier maintenance cycle (and built in ACLs - although that goes against the wiki ethos).
If you perceive the problem to be a legitimate concern, then your focus should lie at the source, across any medium such as email, Facebook, etc. The problem domain is classified as Data Loss Prevention/Protection (DLP) and several security vendors provide solutions, including an open source project called OpenDLP.
You said:
You're asking the wrong question. You are not trying to secure MediaWiki - to quote the MediaWiki page on security issues,
What you really need is good company-wide policy about what is confidential, what constitutes a breach, how you manage confidential information, etc. This is a management issue. "Use (more) technology" is the wrong way to approach this until you have good policy and management.