Какую систему вы используете для шифрования файлов для группы людей (предпочтительно независимо от ОС)?

Question

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

Какие значения вы бы использовали для «шифрования»?Как бы вы хранили ключи?Как бы вы организовали доступ к ключам?

В настоящее время я склоняюсь к следующей реализации:

• значение поля «шифрование» содержит имя ключа, возможно, также обозначающее используемый алгоритм
• каждый пользователь имеет доступ к связке ключей.Это может быть определено ролями, которые пользователь имеет в структуре, подобной LDAP/ActiveDirectory, или это могут быть просто файлы в безопасном каталоге в профиле пользователя/домашнем каталоге.
• при просмотре файла программа просмотра (я пытаюсь создать систему управления документами) проверяет ключи пользователя и расшифровывает файл, если найден соответствующий ключ.

Какое шифрование вы бы использовали?Симметричный (AES)?Или асимметричные (какие хорошие)?

Использование асимметричных ключей даст дополнительное преимущество, заключающееся в разнице между чтением и записью файла:Доступ к закрытому ключу необходим для записи файла, доступ к открытому ключу (только полуоткрытому, поскольку доступ к нему имеют только определенные роли) позволит прочитать файл.Я здесь совершенно ошибаюсь?

Какие общие системы для решения этих проблем используются в малом и среднем бизнесе?

РЕДАКТИРОВАТЬ:Кажется, универсальных решений не существует.Итак, я сформулирую проблему, которую пытаюсь решить, немного более четко:

Представьте себе систему управления документами, которая работает распределенно:Каждый документ копируется на различные узлы в частной P2P-сети (контролируемой компанией).Алгоритм обеспечения избыточности документов используется для обеспечения резервного копирования всех документов (включая редакции).Эта система работает как сервис/демон в фоне и перелопачивает документы туда-сюда.

Это означает, что пользователи в конечном итоге получат документы, которые, вероятно, не предназначены для просмотра на их локальной рабочей станции (компьютер, контролируемый компанией, или ноутбук, или что-то еще - настройки таковы, что ИТ-специалист малого и среднего бизнеса настраивает все это и контролирует, кто является частью P2P-сети).

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

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

Answer 1

Шифрование здесь не самое сложное.Понимание потребностей бизнеса и особенно того, от каких угроз вы пытаетесь защититься, является сложной задачей.Управление ключами — нетривиальная вещь.

Очень рекомендую книгу»Прикладная криптография", чтобы помочь вам лучше понять проблемы на уровне протокола.

Answer 2

Это жесткий проблема.Если это что-то действительно серьезное, не стоит пользоваться советами криптографов-любителей в Интернете.

Answer 3

Тем не менее, вот мои размышления:

Я бы зашифровал каждый файл случайным симметричным ключом с использованием AES.Это шифрование будет выполняться в течение ночи, поэтому ключ меняется в одночасье.

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

Если кто-то потеряет доступ к файлам, он не сможет прочитать новые копии на следующий день (у него все еще могут быть локальные копии старых версий).

Я бы использовал gpg (благополучно работает почти на всех ОС).

Вы неправильно понимаете асимметричную криптографию.Открытый ключ дается каждому, закрытый ключ вы оставляете себе.Если Алиса что-то зашифрует открытым ключом Боба, только Боб сможет это расшифровать.Если Боб что-то зашифровал своим секретным ключом, каждый может это расшифровать, и все знают, что это пришло от Боба, потому что только у него есть его секретный ключ.

РЕДАКТИРОВАТЬ:Однако, если вы проигнорировали все, что я сказал, и пошли другим путем и дали каждому ФАЙЛУ свою собственную пару ключей pub/priv...тогда вы будете полагаться на то, что открытый ключ будет доступен ТОЛЬКО тем, кого вы хотите прочитать файл, а закрытый ключ будет доступен тем, кого вы хотите прочитать/записать.Но это немного сложнее и во многом зависит от того, что люди не могут распространять ключи.Ночные задания по смене ключей могут смягчить эту проблему, но тогда возникает проблема распространения новых ключей среди пользователей.

Answer 4

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

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

Answer 5

Сложность этой проблемы заключается в том, что многие компании по умолчанию используют решения для конкретных ОС, такие как Active Directory.

Для независимости от ОС вам придется заново создать множество средств управления пользователями, которые уже созданы конкретными поставщиками ОС и/или сети.

Но это может быть сделано.Что касается самого шифрования, используйте ответ AviewAnew.

Answer 6

Здесь я должен согласиться с Марком:

Понимание потребностей бизнеса и особенно того, от каких угроз вы пытаетесь защититься, является сложной задачей.

Например;Вы обеспокоены тем, что неавторизованные пользователи могут получить доступ к конфиденциальным файлам?Вы можете использовать контроль доступа на уровне файлов практически в любой операционной системе, чтобы ограничить доступ пользователей или групп к файлам/каталогам.

Вы обеспокоены тем, что авторизованные пользователи могут скопировать файлы локально, а затем потерять свой ноутбук?Существует ряд средств шифрования на уровне операционной системы, которые обеспечивают различную степень защиты.Лично я рекомендую TrueCrypt для флэш-накопителей и других портативных носителей, а Windows Vista теперь включает BitLocker, который обеспечивает другой уровень защиты.

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

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

Answer 7

Что вам нужно, так это шифрование с открытым ключом с использованием сертификатов OpenPGP или X.509.В обоих случаях вы можете зашифровать один блок данных для нескольких «получателей», используя их ключи OpenPGP или сертификаты X.509 соответственно.В X.509 стандартами шифрования данных таким способом являются PKCS#7 и CMS (определено в каком-то RFC, я забыл номер).Вам нужно будет использовать некоторую проверку отзыва ключей, чтобы предотвратить доступ для тех людей, которым был предоставлен доступ раньше, но нет его сейчас.