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