Многопользовательский доступ к зашифрованным данным - PullRequest
1 голос
/ 11 июля 2009

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

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

Это безопасный способ хранения и передачи данных или есть лучшее решение этой проблемы?

Обновление: если следовать предложению Сёрена сохранить копию ключа AES в зашифрованном виде с использованием открытого ключа каждого клиента, не будет ли это включать ключ, который будет храниться где-то для добавления дополнительных клиентов, или он может быть сгенерирован каким-либо образом?

Ответы [ 3 ]

3 голосов
/ 11 июля 2009

Безопасный от чего? Вам нужно более четко определить свои цели.

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

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

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

3 голосов
/ 18 июля 2009

Сначала вы должны определить свойства безопасности, которые вы хотите предоставить, например:

  1. Можно ли предоставить разным пользователям доступ к одному и тому же секретному ключу? Ака, если File1 AES зашифрован ключом K, это проблема, если пользователь Алиса и пользователь Боб оба получают K.

  2. Как отозвать пользователей из системы? (Оказывается, Боб из сценария 1 на самом деле является китайским шпионом, работающим на нашу компанию, как мне безопасно выгнать его из системы).

  3. Нужно ли искать зашифрованные данные, сохраненные в базе данных? (Эта проблема хорошо изучена и ее трудно решить!)

  4. Сколько (если таковые имеются) и какие незашифрованные данные будут помещены в базу данных, чтобы помочь ее организовать? Базы данных ожидают, что данные будут иметь уникальные ключи, связанные с ними. Вы должны убедиться, что эти ключи не пропускают информацию, но достаточно полезны для последующего извлечения данных.

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

  6. Что происходит, когда 2 пользователя изменяют одни и те же данные одновременно? Сможет ли база данных справиться с этим без изменений?

Есть много других.

Если сервер не является доверенным и никогда не должен видеть данные в незашифрованном виде, то вот общий обзор возможного решения.

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

0 голосов
/ 11 июля 2009

Это действительно общий подход, например, также используется для шифрования файлов NTFS.

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