Temos um wiki que é usado por mais da metade da nossa empresa. Geralmente foi recebido de forma muito positiva. Contudo, existe uma preocupação com a segurança – não deixar que informações confidenciais caiam em mãos erradas (ou seja, concorrentes).
A resposta padrão é criar uma matriz de segurança complicada definindo quem pode ler qual documento (página wiki) com base em quem o criou. Pessoalmente, penso que isto resolve principalmente o problema errado porque cria barreirasdentro dea empresa em vez de uma barreira para o mundo externo. Mas alguns estão preocupados que as pessoas nas instalações de um cliente possam compartilhar informações com um cliente que depois vão para o concorrente.
A administração de tal matriz é um pesadelo porque (1) a matriz é baseada em departamentos e não em projetos (esta é uma organização matricial), e (2) porque em um wiki todas as páginas são por definição dinâmicas, então o que é confidencial hoje pode não será confidencial amanhã (mas a história é sempre legível!).
Além da matriz de segurança, consideramos restringir o conteúdo da wiki a conteúdos não supersecretos, mas é claro que isso precisa ser monitorado.
Outra solução (a atual) é monitorar as visualizações e relatar qualquer coisa suspeita (por exemplo, uma pessoa nas instalações de um cliente que teve 2.000 visualizações em dois dias foi denunciada). Novamente – isso não é o ideal porque não implica diretamente um motivo errado.
Alguém tem uma solução melhor? Como um wiki de toda a empresa pode ser protegido e ainda assim manter seu limite baixo de USP?
Aliás, usamos MediaWiki com Lockdown para excluir alguns funcionários administrativos.
Responder1
Usamos o wiki de toda a empresa. É assim que nós fazemos:
Usamos LDAP para armazenamento de nome de usuário e Kerberos para autenticação. MediaWiki possui extensão para uso de LDAP.
Bloqueamos esse endereço IP para que nossos escritórios no Canadá e nos EUA tenham acesso ao wiki, feito em nosso firewall. Mesmo que o wiki esteja em um endereço IP externo, o firewall só permite o acesso de dentro dos escritórios e de qualquer pessoa com VPN.
Em LocalSettings.php (arquivo conf wiki), fizemos com que você não pudesse ler páginas a menos que estivesse logado. No entanto, permitimos que algumas páginas fossem acessíveis sem realmente fazer login.
Também usamos a extensão 'accesscontrol' para páginas restritas. Temos algumas páginas que apenas a equipe sysadmin pode ver, portanto, se alguém do NOC tentar ver essa página, obterá a página de 'acesso negado'. Tudo isso é tratado com a extensão AccessControl.
Antes de começar, você precisa saber como os usuários são gerenciados em seu escritório. Temos tudo em LDAP. Nós, grupos como sysadmin, desenvolvedores, NOC, etc, e os usuários são atribuídos a esses grupos. Assim, é mais fácil conceder ou retirar acesso com base no grupo em que se encontra.
-F
Responder2
Um ponto óbvio, ou pelo menos é o que me parece, é que se você deseja algo que esteja totalmente bloqueado, então tem certeza de que realmente deseja um Wiki. Uma grande parte do espírito de um wiki não é ser o mais aberto possível? Depois que você se afastar o suficiente do propósito original, mais cedo ou mais tarde não será uma ideia melhor tentar uma ferramenta diferente que tenha um ajuste mais próximo para começar, em vez de forçar aquela que você está totalmente fora de forma?
Responder3
Você precisa deixar claro o que é apropriado e o que não é apropriado para postagem se for usar algo como o MediaWiki. Isso é toda a segurança que você obterá.
Se os seus requisitos de negócios significam que você precisa de ACLs complexas, você precisa procurar uma solução projetada para isso. SharePoint, Traction, Alfresco e SocialText são produtos que podem fazer isso.
Tudo depende da organização... não faça políticas baseadas no produto que você decidiu usar por um motivo aleatório.
Responder4
Se você perceber que o problema é uma preocupação legítima, seu foco deve estar na origem, em qualquer meio, como e-mail, Facebook, etc. O domínio do problema é classificado como Prevenção/Proteção contra perda de dados (DLP) e vários fornecedores de segurança fornecem soluções, incluindo um projeto de código aberto chamadoOpenDLP.