전사적 위키를 보호하는 최적의 방법은 무엇입니까?

전사적 위키를 보호하는 최적의 방법은 무엇입니까?

우리 회사의 절반 이상이 사용하는 Wiki가 있습니다. 일반적으로 매우 긍정적인 평가를 받았습니다. 그러나 보안에 대한 우려가 있습니다. 기밀 정보가 잘못된 손(예: 경쟁업체)에 넘어가는 것을 방지하는 것입니다.

기본 대답은 문서를 만든 사람에 따라 누가 어떤 문서(위키 페이지)를 읽을 수 있는지 정의하는 복잡한 보안 매트릭스를 만드는 것입니다. 개인적으로 나는 이것이 장벽을 만들기 때문에 주로 잘못된 문제를 해결한다고 생각합니다.이내에외부 세계에 대한 장벽이 아닌 회사. 그러나 일부 사람들은 고객 사이트의 사람들이 정보를 고객과 공유한 후 경쟁사로 전달될 수 있다는 점을 우려하고 있습니다.

그러한 매트릭스의 관리는 (1) 매트릭스가 프로젝트가 아닌 부서를 기반으로 하기 때문에 악몽입니다(이것은 매트릭스 조직입니다). 그리고 (2) Wiki에서는 모든 페이지가 정의상 동적이므로 오늘날 기밀인 내용은 내일은 기밀로 유지하지 마십시오(그러나 기록은 항상 읽을 수 있습니다!).

보안 매트릭스와 별도로, 우리는 위키의 콘텐츠를 극비밀이 아닌 내용으로 제한하는 것을 고려했지만 물론 모니터링이 필요합니다.

또 다른 해결책(현재)은 조회수를 모니터링하고 의심스러운 사항을 보고하는 것입니다(예: 고객 사이트에서 이틀 동안 조회수가 2000회를 기록한 한 사람이 보고되었습니다). 다시 말하지만 이는 잘못된 동기를 직접적으로 암시하는 것이 아니기 때문에 이상적이지 않습니다.

누구든지 더 나은 해결책이 있습니까? 회사 전체의 위키를 어떻게 안전하게 보호하면서도 낮은 기준 USP를 유지할 수 있습니까?

그런데 우리는 일부 관리 직원을 제외하기 위해 잠금 기능이 있는 MediaWiki를 사용합니다.

답변1

우리는 전사적인 위키를 사용합니다. 이것이 우리가 그것을 행한 방법이다:

  1. 사용자 이름 저장에는 LDAP를 사용하고 인증에는 Kerberos를 사용합니다. MediaWiki에는 LDAP 사용을 위한 확장 기능이 있습니다.

  2. 우리는 캐나다와 미국에 있는 우리 사무실이 위키에 접근할 수 있도록 방화벽을 통해 해당 IP 주소를 잠갔습니다. 위키가 외부 IP 주소에 있더라도 방화벽은 사무실 내부와 VPN을 사용하는 사람의 액세스만 허용합니다.

  3. LocalSettings.php(wiki conf 파일)에서는 로그인하지 않으면 페이지를 읽을 수 없도록 만들었습니다. 그러나 실제로 로그인하지 않고도 일부 페이지에 액세스할 수 있도록 허용했습니다.

  4. 또한 페이지 제한을 위해 'accesscontrol' 확장을 사용합니다. 시스템 관리자 팀만 볼 수 있는 페이지가 있으므로 NOC의 누군가가 해당 페이지를 보려고 하면 '액세스 거부' 페이지가 표시됩니다. 이것은 모두 AccessControl 확장으로 처리됩니다.

시작하기 전에 사무실에서 사용자가 어떻게 관리되는지 알아야 합니다. LDAP에는 모든 것이 있습니다. 우리는 시스템 관리자, 개발자, NOC 등과 같은 그룹을 갖고 사용자는 해당 그룹에 할당됩니다. 따라서 자신이 속한 그룹에 따라 액세스 권한을 부여하거나 박탈하는 것이 더 쉽습니다.

-에프

답변2

내가 보기에 한 가지 분명한 점은 매우 엄격하게 잠겨 있는 것을 원한다면 실제로 Wiki를 원하는지 여부입니다. 가능한 한 개방적이라는 것이 위키 정신의 큰 부분을 차지하지 않나요? 원래 목적에서 충분히 벗어나면 조만간 모양이 완전히 벗어난 도구를 긴장시키는 것보다 시작하기에 더 잘 맞는 다른 도구를 사용해 보는 것이 더 나은 아이디어가 되지 않습니까?

답변3

MediaWiki와 같은 것을 사용하려면 게시에 적합한 것과 적절하지 않은 것을 명확히 해야 합니다. 그것은 당신이 얻게 될 모든 보안에 관한 것입니다.

비즈니스 요구 사항에 따라 복잡한 ACL이 필요한 경우 이를 위해 설계된 솔루션을 살펴봐야 합니다. SharePoint, Traction, Alfresco 및 SocialText는 모두 이를 수행할 수 있는 제품입니다.

그것은 모두 조직에 달려 있습니다. 임의의 이유로 사용하기로 결정한 제품을 기반으로 정책을 만들지 마십시오.

답변4

문제가 정당한 문제라고 인식되면 이메일, Facebook 등과 같은 모든 매체에서 소스에 초점을 맞춰야 합니다. 문제 도메인은 DLP(데이터 손실 방지/보호)로 분류되며 여러 보안 공급업체에서 제공하는 라는 오픈 소스 프로젝트를 포함한 솔루션오픈DLP.

관련 정보