Wir haben ein Wiki, das von über der Hälfte unseres Unternehmens genutzt wird. Im Allgemeinen wird es sehr positiv aufgenommen. Es gibt jedoch Sicherheitsbedenken – vertrauliche Informationen dürfen nicht in die falschen Hände (z. B. Konkurrenten) gelangen.
Die Standardantwort besteht darin, eine komplizierte Sicherheitsmatrix zu erstellen, die definiert, wer welches Dokument (Wiki-Seite) lesen kann, basierend darauf, wer es erstellt hat. Persönlich denke ich, dass dies hauptsächlich das falsche Problem löst, weil es Barrieren schafftinnerhalbdas Unternehmen und nicht als Barriere zur Außenwelt. Manche befürchten jedoch, dass Mitarbeiter vor Ort beim Kunden Informationen an den Kunden weitergeben könnten, die dann an die Konkurrenz gelangen.
Die Verwaltung einer solchen Matrix ist ein Albtraum, weil (1) die Matrix auf Abteilungen und nicht auf Projekten basiert (es handelt sich um eine Matrixorganisation) und (2) in einem Wiki alle Seiten per Definition dynamisch sind, sodass das, was heute vertraulich ist, morgen möglicherweise schon nicht mehr vertraulich ist (der Verlauf ist jedoch jederzeit lesbar!).
Abgesehen von der Sicherheitsmatrix haben wir erwogen, den Inhalt des Wikis auf nicht streng geheime Dinge zu beschränken, aber das muss natürlich überwacht werden.
Eine andere (aktuelle) Lösung besteht darin, die Aufrufe zu überwachen und alles Verdächtige zu melden (z. B. wurde gemeldet, dass eine Person auf einer Kundensite in zwei Tagen 2000 Aufrufe hatte). Auch dies ist nicht ideal, da dies nicht direkt auf ein falsches Motiv schließen lässt.
Kennt jemand eine bessere Lösung? Wie kann ein unternehmensweites Wiki sicher gemacht werden und trotzdem sein niedrigschwelliges Alleinstellungsmerkmal behalten?
Übrigens verwenden wir MediaWiki mit Lockdown, um einige Verwaltungsmitarbeiter auszuschließen.
Antwort1
Wir nutzen ein unternehmensweites Wiki. Und so geht’s:
Wir verwenden LDAP zur Speicherung des Benutzernamens und Kerberos zur Authentifizierung. MediaWiki verfügt über eine Erweiterung für die Verwendung von LDAP.
Wir haben diese IP-Adresse gesperrt, sodass unsere Büros in Kanada und den USA über unsere Firewall auf das Wiki zugreifen können. Obwohl das Wiki eine externe IP-Adresse hat, erlaubt die Firewall nur den Zugriff innerhalb der Büros und von Personen, die sich per VPN angemeldet haben.
In LocalSettings.php (Wiki-Konfigurationsdatei) haben wir festgelegt, dass Sie Seiten nur lesen können, wenn Sie angemeldet sind. Allerdings haben wir den Zugriff auf einige Seiten auch ohne Anmeldung zugelassen.
Wir verwenden auch die Erweiterung „AccessControl“, um Seiten einzuschränken. Wir haben einige Seiten, die nur das Sysadmin-Team sehen kann. Wenn also jemand von NOC versucht, diese Seite anzuzeigen, wird ihm die Seite „Zugriff verweigert“ angezeigt. Dies alles wird mit der Erweiterung „AccessControl“ gehandhabt.
Bevor Sie beginnen, müssen Sie wissen, wie Benutzer in Ihrem Büro verwaltet werden. Wir haben alles in LDAP. Wir gruppieren beispielsweise Sysadmin, Entwickler, NOC usw. und Benutzer werden diesen Gruppen zugewiesen. So ist es einfacher, Zugriff zu gewähren oder zu entziehen, je nachdem, zu welcher Gruppe sie gehören.
-F
Antwort2
Ein offensichtlicher Punkt, so scheint es mir jedenfalls, ist, wenn Sie etwas wollen, das sehr streng abgeschottet ist, sind Sie dann sicher, dass Sie wirklich ein Wiki wollen? Besteht ein großer Teil des Ethos eines Wikis nicht darin, dass es so offen wie möglich ist? Wenn Sie sich erst einmal weit genug vom ursprünglichen Zweck entfernt haben, ist es dann nicht früher oder später eine bessere Idee, ein anderes Tool auszuprobieren, das besser passt, als das vorhandene völlig zu überstrapazieren?
Antwort3
Wenn Sie beispielsweise MediaWiki verwenden, müssen Sie klarstellen, was beim Posten angemessen ist und was nicht. Das ist so ziemlich die gesamte Sicherheit, die Sie erhalten.
Wenn Ihre Geschäftsanforderungen komplexe ACLs erfordern, müssen Sie sich nach einer dafür geeigneten Lösung umsehen. SharePoint, Traction, Alfresco und SocialText sind alles Produkte, die das können.
Es hängt alles von der Organisation ab. Erstellen Sie keine Richtlinien auf Grundlage des Produkts, für dessen Verwendung Sie sich aus einem beliebigen Grund entschieden haben.
Antwort4
Wenn Sie das Problem als berechtigtes Anliegen ansehen, sollten Sie sich auf die Quelle konzentrieren, und zwar über alle Medien wie E-Mail, Facebook usw. Der Problembereich wird als Data Loss Prevention/Protection (DLP) klassifiziert und mehrere Sicherheitsanbieter bieten Lösungen an, darunter ein Open-Source-Projekt namensOpenDLP.