Слияние встроенного шифрования / Форма шифрования

1843

мы запускаем установку слияния 4.2.3 в качестве нашей основной вики. Даже если мы используем права доступа к страницам и управление пользователями, мы все равно не можем хранить в вики данные определенного типа, такие как ключи шифрования, цены покупки и так далее.

Я много гуглял и видел разные плагины для безопасного хранения паролей, такие как плагин хранилища или плагин для отправки страницы, зашифрованной по электронной почте.

Это не то, что я ищу. Мне нужно что-то для хранения документа, который шифруется либо на стороне клиента, либо непосредственно на стороне сервера, чтобы администратор не мог получить эту информацию.

Я бы предпочел реализацию на стороне клиента, потому что если она зашифрована на сервере, она все равно может быть перехвачена администратором.

Конечно, шифрование может быть только симметричным, так как его может расшифровать любой, кто знает правильную фразу-пароль.

Все пользователи в настоящее время используют Firefox 10 (да, 10, как он сертифицирован Atlassian), и плагин для браузера тоже может подойти.

Позвольте мне перефразировать идею:

  • Типы пользователей «Цена автомобиля € 29.000» в текстовое поле
  • Плагин (специфичный для браузера или слияния) обнаруживает отправку формы
  • Плагин запрашивает пароль (или использует по умолчанию)
  • Плагин зашифровывает в 'Cevpr bs pne vf € 29.000' (надеюсь, не rot13;))
  • Плагин шифрует данные формы и отправляет зашифрованную форму на сервер
  • Сервер ничего не знает о шифровании и счастливо хранит данные
  • Админ не доволен, так как она не может читать конфиденциальную информацию из БД

Любые предложения и идеи очень приветствуются.

заранее спасибо

2

2 ответа на вопрос

0
Zac B

Lock the Text может помочь вам; он работает с любыми / всеми текстовыми полями в Firefox и требует от пользователя нажатия кнопки, но это намного лучше, чем копировать все значения в поле в какое-то другое окно для шифрования. Альтернативный плагин - CryptFire, но я его не использовал.

Тем не менее, я думаю, что ваши цели могут быть ошибочными. Это хороший способ сказать: это ужасная идея . Вот почему:

Вы правы, заметив, что Confluence - это вики, ориентированная на публичный доступ, и ее не следует использовать для хранения конфиденциальных вещей. Тем не менее, дать группе пользователей парольную фразу и доверить им шифрование данных на стороне браузера, IMO, еще менее безопасно, чем просто использование разрешений Confluence для блокировки пользователей, которые не должны иметь доступ к страницам с конфиденциальной информацией (не то чтобы я). Я предлагаю вам сделать это, это все еще очень небезопасно). Что происходит, когда пользователь использует браузер, отличный от предложенного FF10, и не шифрует данные? Или что, если кто-то поднимет ключ с рабочей станции пользователя (возможно, с гораздо меньшей физической и инфраструктурной безопасностью, чем сервер Confluence)? Или что, если пользователь просто ... Я не знаю, забудет зашифровать что-то конфиденциальное?

Реальное решение - использовать один из менеджеров паролей, который вы уволили; они являются подходящим инструментом для этой работы, и использование общедоступной вики для хранения данных, зашифрованных по принципу «согласие», «на пользователя» и «на браузер», кажется крайне опасным. Если вы хотите найти менеджер паролей, я предлагаю KeePassX . Он минимален, кроссплатформенен и делает именно то, что вам нужно; Не больше, не меньше.

Конечно, это игнорирует слона в комнате: если ваш внутренний вики-сервер не защищен на заднем плане, или вы обеспокоены тем, что «администраторы» могут попытаться получить документы после их получения, но до того, как они будут зашифрованы на на стороне сервера, вы, вероятно, должны серьезно пересмотреть свою внутреннюю сетевую безопасность и надежность своих администраторов.

Если вы беспокоитесь о конкретном хранении ключей шифрования и не хотите использовать универсальный менеджер паролей, существует ряд хороших кроссплатформенных утилит, специально предназначенных для хранения данных PGP в удобном для пользователя виде. -управление хранилищем / связкой ключей с мастер-паролем; просто спросите Google. Если управление ключами SSH, есть тонна централизованного управления-Utils там. Фаворитом может быть использование Puppet и ssh :: auth, но это очень большой молоток и требует много работы.

Привет Зак, спасибо за ваш отзыв. В целом мы доверяем нашим сотрудникам и администраторам, но есть вещи, которые не для их глаз. У нас будет такая же проблема на любой компьютерной системе, если кто-то может стать суперпользователем, она сможет прочитать данные. Так или иначе, нам понадобится шифрование. В этом случае мы смотрим на вики как на папку на файловом сервере. Даже там админ мог читать файлы. На этом этапе вы хотели бы защитить определенные данные. Мы не доверяем многим пользователям шифровать свои данные, но мы хотим иметь возможность защитить определенные данные для определенных пользователей. Мне нужно подумать об этом. 11 лет назад 0
Я думаю, что цель зашифрования ваших конфиденциальных данных и контроля доступа к ключу (а не к содержимому) - это хорошо. Я просто не думаю, что попытка взломать функциональность шифрования для чего-либо (Confluence), предназначенного для распространения, а не защиты, является хорошей идеей. Zac B 11 лет назад 0
Я отметил ваш ответ, потому что мы будем повторно сохранять конфиденциальные данные в месте слияния. Может быть, мы будем использовать контейнеры Truecrypt на томе сети 11 лет назад 0
Это хорошее решение. Если вам действительно нравится управление этими данными на основе вики / Интернета, вы можете сохранить файл для чего-то вроде tiddlywiki (google it) в зашифрованном томе / файле и расшифровывать его только при необходимости. Zac B 11 лет назад 0
0
Nicholas Muldoon