Tenemos una wiki que utiliza más de la mitad de nuestra empresa. En general ha tenido una acogida muy positiva. Sin embargo, existe una preocupación por la seguridad: no permitir que la información confidencial caiga en manos equivocadas (es decir, de la competencia).
La respuesta predeterminada es crear una matriz de seguridad complicada que defina quién puede leer qué documento (página wiki) en función de quién lo creó. Personalmente creo que esto resuelve principalmente el problema equivocado porque crea barrerasdentrola empresa en lugar de una barrera al mundo exterior. Pero a algunos les preocupa que las personas en el sitio de un cliente puedan compartir información con un cliente que luego pasa al competidor.
La administración de una matriz de este tipo es una pesadilla porque (1) la matriz se basa en departamentos y no en proyectos (ésta es una organización matricial), y (2) porque en una wiki todas las páginas son por definición dinámicas, por lo que lo que hoy es confidencial podría ser una pesadilla. mañana no será confidencial (¡pero el historial siempre será legible!).
Aparte de la matriz de seguridad, hemos considerado restringir el contenido de la wiki a cosas que no sean súper secretas, pero, por supuesto, eso debe ser monitoreado.
Otra solución (la actual) es monitorear las vistas e informar cualquier cosa sospechosa (por ejemplo, se informó que una persona en el sitio de un cliente tenía 2000 vistas en dos días). Nuevamente, esto no es ideal porque no implica directamente un motivo equivocado.
¿Alguien tiene una solución mejor? ¿Cómo se puede hacer que un wiki de toda la empresa sea seguro y aún así mantener su PVU de umbral bajo?
Por cierto, utilizamos MediaWiki con Lockdown para excluir a parte del personal administrativo.
Respuesta1
Utilizamos wiki para toda la empresa. Así es como lo hacemos:
Usamos LDAP para almacenamiento de nombre de usuario y kerberos para autenticación. MediaWiki tiene una extensión para usar LDAP.
Bloqueamos esa dirección IP de modo que nuestras oficinas en Canadá y EE. UU. tengan acceso a la wiki, realizada en nuestro firewall. Aunque el wiki está en una dirección IP externa, el firewall solo permite el acceso desde dentro de las oficinas y desde cualquier persona que tenga VPN.
En LocalSettings.php (archivo de configuración wiki), lo hicimos de tal manera que no pueda leer páginas a menos que haya iniciado sesión. Sin embargo, permitimos que se pueda acceder a algunas páginas sin iniciar sesión.
También utilizamos la extensión 'accesscontrol' para restringir páginas. Tenemos algunas páginas que solo el equipo de administradores de sistemas puede ver, por lo que si alguien de NOC intenta ver esa página, obtendrá la página "acceso denegado". Todo esto se maneja con la extensión AccessControl.
Antes de comenzar, necesita saber cómo se administran los usuarios en su oficina. Tenemos todo en LDAP. Nosotros, grupos como administradores de sistemas, desarrolladores, NOC, etc., y los usuarios estamos asignados a esos grupos. Por lo tanto, es más fácil dar o quitar acceso según el grupo en el que se encuentren.
-F
Respuesta2
Un punto obvio, o eso me parece a mí, es que si quieres algo que esté muy estrictamente bloqueado, ¿estás seguro de que realmente quieres un Wiki? ¿No es una gran parte del espíritu de una wiki que sea lo más abierta posible? Una vez que se ha alejado lo suficiente del propósito original, ¿no sería mejor, tarde o temprano, probar una herramienta diferente que se ajuste mejor para empezar, en lugar de forzar la que tiene totalmente fuera de forma?
Respuesta3
Debes dejar claro qué es apropiado y qué no es apropiado para publicar si vas a utilizar algo como MediaWiki. Esa es toda la seguridad que obtendrá.
Si los requisitos de su negocio implican que necesita ACL complejas, debe buscar una solución diseñada para ello. SharePoint, Traction, Alfresco y SocialText son productos que pueden hacer eso.
Todo depende de la organización... no hagas políticas basadas en el producto que decidiste utilizar por un motivo aleatorio.
Respuesta4
Si percibe que el problema es una preocupación legítima, entonces su atención debe centrarse en el origen, a través de cualquier medio como correo electrónico, Facebook, etc. El dominio del problema está clasificado como Prevención/Protección de pérdida de datos (DLP) y varios proveedores de seguridad brindan soluciones, incluido un proyecto de código abierto llamadoAbiertoDLP.