我们有一个由我们公司一半以上使用的wiki。 一般来说，它一直非常积极地接受。 然而，人们担心安全问题 – 不要让机密信息落入坏人手中（即竞争对手）。
默认的答案是创build一个复杂的安全matrix，定义谁可以根据创build者来读取哪个文档（wiki页面）。 我个人认为这主要是解决了错误的问题，因为它在公司内部造成了障碍，而不是对外部世界的障碍。 但有些人担心，客户现场的人可能会与客户分享信息，然后再与竞争对手分享信息。
这样一个matrix的pipe理是一个噩梦，因为（1）matrix是基于部门而不是项目（这是一个matrix组织），和（2）因为在维基的所有页面定义上是dynamic的，所以今天什么是保密的明天不要保密（但历史总是可读的！）。
除了安全matrix之外，我们考虑将wiki上的内容限制在非超级秘密的内容中，但是当然这需要加以监控。
另一种解决scheme（当前）是监视视图并报告任何可疑的情况（例如，报告在两天内有2000个视图的客户站点的一个人）。 再次 – 这不是理想的，因为这并不直接暗示错误的动机。
有没有人有更好的解决scheme？ 一家公司的维基如何能够获得安全，并保持低门槛USP？
顺便说一句，我们使用MediaWiki和Lockdown来排除一些pipe理人员。
我们使用公司范围的wiki。 这是我们的做法：
我们使用LDAP存储用户名和Kerberos进行身份validation。 MediaWiki具有使用LDAP的扩展。
我们locking了这个IP地址，以便我们在加拿大和美国的办公室可以访问我们的防火墙上的wiki。 即使维基是在外部IP地址，防火墙只允许从办公室内任何人进入。
在LocalSettings.php（wiki conf文件）中，我们做了这样的事情，除非你已经login，否则你不能阅读页面。但是，我们确实允许一些页面访问，而不需要实际login。
我们还使用“访问控制”扩展来限制页面。 我们有一些只有系统pipe理员团队可以看到的页面，所以如果NOC的某个人尝试看到那个页面，他们将会得到“访问被拒绝”的页面。 这全部用AccessControl扩展处理。
在开始之前，您需要知道用户如何在办公室进行pipe理。 我们拥有LDAP中的所有内容。 我们像sysadmin，开发人员，NOC等组等，用户分配给这些组。 所以，根据他们所在的组织来分配或者取消访问会更容易。
-F
一个明显的问题，或者我认为是，如果你想要一个非常紧密的东西，那么你确定你确实需要一个Wiki。 是不是一个维基的大部分精神，它是尽可能开放的？ 一旦你远离了原来的目标，那么不是迟早会尝试一种更紧密合适的不同工具来开始，而不是把你已经完全变形的工具拉紧了。
你需要明确什么是适当的，什么是不适合发布，如果你要使用像MediaWiki的东西。 这就是你将要获得的所有安全性。
如果您的业务需求意味着您需要复杂的ACL，则需要查看为其devise的解决scheme。 SharePoint，Traction，Alfresco和SocialText都是可以做到的产品。
这一切都取决于组织…不要根据您决定使用的产品随机原因制定策略。
我也有同样的问题，并得出了和罗伯特一样的结论。 经过进一步的研究，确实有复杂ACL的维基，给你两个世界的利益。 但在这种情况下，可能最好保留你的wiki，但为所有的“安全”项目提供另一个工具。
我们尝试了Mediawiki是因为维基百科使用它的想法，不幸的是维护比我们预期的更困难，特别是当我们实现了越来越多的扩展。 最后，我们希望我们使用了一个可能不那么雄心勃勃的维基引擎，但维护周期更短（并且内置在ACL中 – 尽pipe这违背了维基百科的理念）。
如果您认为这个问题是一个合理的问题，那么您的重点应放在电子邮件，Facebook等任何媒介上。这个问题领域被归类为数据丢失防护（DLP），一些安全厂商提供解决scheme，包括一个名为OpenDLP的开源项目。
你说：
担心安全 – 不要让机密信息落入坏人之手
你问的是错误的问题。 您不是在保护MediaWiki – 引用MediaWiki页面的安全问题 ，
MediaWiki不是为了保护敏感数据而devise的。 相反，它的devise是尽可能开放的。
你真正需要的是关于什么是保密的，什么构成违规，如何pipe理机密信息等，在公司范围内的良好策略。 这是一个pipe理问题。 “使用（更多）技术”是一个错误的方法，直到你有良好的政策和pipe理。