У нас есть вики, которой пользуется более половины нашей компании. В целом, она была принята очень позитивно. Однако есть опасения по поводу безопасности — не допустить попадания конфиденциальной информации в чужие руки (т. е. к конкурентам).
Ответ по умолчанию — создать сложную матрицу безопасности, определяющую, кто может читать какой документ (страницу вики) на основе того, кто его создал. Лично я думаю, что это в основном решает неправильную проблему, потому что создает барьерыв пределахкомпания, а не барьер для внешнего мира. Но некоторые обеспокоены тем, что люди на сайте клиента могут поделиться информацией с клиентом, которая затем попадет к конкуренту.
Администрирование такой матрицы — это кошмар, потому что (1) матрица основана на отделах, а не проектах (это матричная организация), и (2) потому что в вики все страницы по определению динамичны, поэтому то, что является конфиденциальным сегодня, может не быть конфиденциальным завтра (но историю всегда можно прочитать!).
Помимо матрицы безопасности, мы рассматривали возможность ограничения контента вики только не сверхсекретной информацией, но, конечно, за этим нужно следить.
Другое решение (текущее) — отслеживать просмотры и сообщать обо всем подозрительном (например, было сообщено об одном человеке на сайте клиента, который имел 2000 просмотров за два дня). Опять же — это не идеально, потому что это не подразумевает напрямую неправильный мотив.
Есть ли у кого-нибудь лучшее решение? Как можно сделать вики-сайт для всей компании безопасным и при этом сохранить низкий порог УТП?
Кстати, мы используем MediaWiki с функцией Lockdown, чтобы исключить часть административного персонала.
решение1
Мы используем общекорпоративную wiki. Вот как мы это делаем:
Мы используем LDAP для хранения имени пользователя и kerberos для аутентификации. MediaWiki имеет расширение для использования LDAP.
Мы заблокировали этот IP-адрес, так что наши офисы в Канаде и США имеют доступ к wiki, что сделано на нашем брандмауэре. Несмотря на то, что wiki находится на внешнем IP-адресе, брандмауэр разрешает доступ только из офисов и тех, кто подключен через vpn.
В LocalSettings.php (файл конфигурации wiki) мы сделали так, что вы не сможете читать страницы, если не войдете в систему. Однако мы разрешили доступ к некоторым страницам без фактического входа в систему.
Мы также используем расширение 'accesscontrol' для ограничения страниц. У нас есть некоторые страницы, которые может видеть только команда системных администраторов, поэтому, если кто-то из NOC попытается просмотреть эту страницу, он получит страницу 'доступ запрещен'. Все это обрабатывается расширением AccessControl.
Прежде чем начать, вам нужно знать, как управляются пользователи в вашем офисе. У нас все есть в LDAP. У нас есть группы, такие как sysadmin, developers, NOC и т. д. и т. п., и пользователи назначаются в эти группы. Таким образом, проще предоставлять или отнимать доступ на основе группы, в которой они находятся.
-Ф
решение2
Один очевидный момент, или мне так кажется, если вы хотите что-то очень жестко запертое, то уверены ли вы, что вам действительно нужна Wiki. Разве большая часть духа Wiki не в том, чтобы быть максимально открытым? Как только вы достаточно далеко отошли от изначальной цели, то не станет ли рано или поздно лучшей идеей попробовать другой инструмент, который подходит вам больше, чем напрягать тот, который у вас полностью вышел из строя?
решение3
Вам нужно четко указать, что уместно, а что нет для публикации, если вы собираетесь использовать что-то вроде MediaWiki. Это все, что касается безопасности, которую вы получите.
Если ваши бизнес-требования подразумевают, что вам нужны сложные ACL, вам нужно рассмотреть решение, разработанное для этого. SharePoint, Traction, Alfresco и SocialText — все это продукты, которые могут это сделать.
Все зависит от организации... не создавайте политику на основе продукта, который вы решили использовать по случайной причине.
решение4
Если вы считаете, что проблема вызывает обоснованное беспокойство, то вам следует сосредоточиться на ее источнике, на любом носителе, например, на электронной почте, Facebook и т. д. Область проблемы классифицируется как предотвращение/защита от потери данных (DLP), и несколько поставщиков услуг безопасности предлагают решения, включая проект с открытым исходным кодом под названиемOpenDLP.