Qual é a melhor maneira de proteger um wiki de toda a empresa?

Question

Nós temos um wiki que é usado por mais da metade da nossa empresa. Geralmente foi recebido de forma muito positiva. No entanto, há uma preocupação com a segurança - não permitir que informações confidenciais caiam nas mãos erradas (por exemplo, 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, acho que isso resolve principalmente o problema errado porque cria barreiras dentro da empresa em vez de uma barreira para o mundo externo. Mas alguns estão preocupados que as pessoas em um site do cliente possam compartilhar informações com um cliente que, em seguida, vai para o concorrente.

A administração de tal matriz é um pesadelo porque (1) a matriz é baseada em departamento e não em projetos (isto é uma organização matricial), e (2) porque em um wiki todas as páginas são dinâmicas por definição confidencial hoje pode não ser confidencial amanhã (mas a história é sempre legível!).

Além da matriz de segurança, consideramos a restrição de conteúdo no wiki para coisas não super secretas, mas é claro que isso precisa ser monitorado.

Outra solução (a atual) é monitorar visualizações e relatar qualquer coisa suspeita (por exemplo, uma pessoa em um site do cliente com 2000 visualizações em dois dias foi relatada). Novamente - isso não é ideal porque isso não implica diretamente um motivo errado.

Alguém tem uma solução melhor? Como um wiki de toda a empresa pode ser seguro e, ainda assim, manter seu baixo limite USP?

BTW usamos o MediaWiki com o Lockdown para excluir alguns funcionários administrativos.

    

Answer 1

Nós usamos o wiki para toda a empresa. É assim que fazemos:

1. Usamos o LDAP para armazenamento de nome de usuário e kerberos para autenticação. MediaWiki tem extensão para usar o LDAP.

2. Nós bloqueamos esse endereço IP de modo 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 quem quer que esteja dentro.

3. Em LocalSettings.php (arquivo conf do wiki), fizemos isso de modo que você não pode ler as páginas, a menos que esteja logado. No entanto, permitimos algumas páginas acessíveis sem realmente efetuar login.

4. Também usamos a extensão 'accesscontrol' para restringir as páginas. Temos algumas páginas que somente a equipe do sysadmin pode ver, então, se alguém do NOC tentar ver essa página, ela receberá a página '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. Nós temos tudo no LDAP. Nós grupos como sysadmin, desenvolvedores, NOC etc etc e os usuários são atribuídos a esses grupos. Assim, é mais fácil dar ou tirar o acesso com base no grupo em que estão.

-F

    

Answer 2

Um ponto óbvio, ou assim parece-me, é se você quer algo que é muito bem fechado, então você tem certeza que você realmente quer um Wiki. Não é uma grande parte do ethos de um wiki que é tão aberto quanto possível? Uma vez que você se afastou o suficiente do propósito original, não será mais cedo ou mais tarde uma idéia melhor para tentar uma ferramenta diferente que tenha um ajuste mais adequado para começar do que forçar a que você está totalmente fora de forma? / p>     

Answer 3

Você precisa deixar claro o que é apropriado e o que não é apropriado postar se você for usar algo como o MediaWiki. Isso é sobre toda a segurança que você terá.

Se os seus requisitos de negócios significam que você precisa de ACLs complexas, é necessário analisar uma solução projetada para isso. SharePoint, Traction, Alfresco e SocialText são todos produtos que podem fazer isso.

Tudo depende da organização ... não faça uma política baseada no produto que você decidiu usar por um motivo aleatório.

    

Answer 4

Eu tive exatamente o mesmo problema e cheguei à mesma conclusão que Robert. Ao pesquisar mais, existem wikis que possuem ACLs complexas, dando a você o benefício de ambos os mundos. Mas neste caso, é provavelmente melhor que você mantenha seu wiki, mas tenha outra ferramenta para todos os itens "seguros".

Nós tentamos o MediaWiki por causa da idéia de que a Wikipedia o usa, infelizmente a manutenção é mais difícil do que esperávamos, especialmente à medida que implementamos mais e mais extensões. No final, desejamos que usássemos um mecanismo de wiki diferente que talvez não fosse tão ambicioso, mas com um ciclo de manutenção mais fácil (e construído em ACLs - embora isso contrarie o ethos do wiki).

    

Answer 5

Se você perceber que o problema é uma preocupação legítima, o 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 chamado OpenDLP .

    

Answer 6

Você disse:

there is a concern over security - not letting confidential information fall into the wrong hands

Você está fazendo a pergunta errada. Você não está tentando proteger o MediaWiki - para citar a página do MediaWiki sobre questões de segurança ,

MediaWiki is not designed to be a CMS, or to protect sensitive data. To the contrary, it was designed to be as open as possible.

O que você realmente precisa é de uma boa política em toda a empresa sobre o que é confidencial, o que constitui uma violação, como você gerencia informações confidenciais etc. Esse é um problema de gerenciamento. "Usar (mais) tecnologia" é o caminho errado para abordar isso até que você tenha uma boa política e gerenciamento.