Лучшая практика для шифрования на стороне клиента / на стороне сервера для данных формы - PullRequest
0 голосов
/ 26 октября 2011

Я планирую проект, который требует передачи конфиденциальных данных со стороны клиента на сторону сервера, а затем в хранилище AWS Simple Storage.

Это мой план:

  1. Используя SSL / HTTP (S), данные могут быть безопасно размещены через веб-форму, которая затем извлекается с помощью сценария PHPна моем веб-сервере.

  2. Как только данные получены сервером, PHP-скрипт немедленно отправит их в AWS, используя AWS SDK для PHP с директивой для шифрования данных на стороне сервера с помощью AES.-256- См. Шифрование AWS .

Проблема заключается в том, что между шагами 1 и 2 данные не будут зашифрованы, поскольку они должны попасть на мой веб-сервер.сначала для обработки.Я подумываю о том, чтобы скрипт записал данные в текстовый файл на сервере перед отправкой в ​​AWS, а затем сразу же удалил временный файл с сервера после его отправки.Есть ли риск в этом?Есть ли способ отправки потока файлов, а не фактического файла в корзину AWS Simple Storage, что позволяет избежать необходимости записи временного файла на сервер?

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

Ответы [ 2 ]

2 голосов
/ 26 октября 2011

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

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

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

Итак ... вопрос, который вы должны себе задать, это "какова моя модель угрозы"?И «какие данные я храню в этом файле?»

Если данные содержат номера кредитных карт, значит, вы уже нарушаете стандарты PCI - номер CC можно НИКОГДА не сохранятьв любом месте в текстовом / читаемом формате.

0 голосов
/ 26 октября 2011

Не эксперт по шифрованию, поэтому ничего не могу поделать, но ...

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

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

Принудительно использовать систему только ОЗУ без возможности записи на диск сложно и игнорирует тот факт, что кто-то с доступом с правами root может также (с трудом) считывать данные непосредственно из ОЗУ процесса веб-сервера, прежде чем он получитencrypyed.

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

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