Как создать веб-приложение, в котором у меня нет доступа к данным?

Question

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

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

Сценарий I: Ограничить таблицу в действующей базе данных так, чтобы только администратор SQL мог получить к ней доступ напрямую.
Hack 1: Я внедряю изменение, которое отправляет данные в другую таблицу для последующего просмотра. Кроме того, администратор SQL может видеть данные, что нарушает требование.

Сценарий II: Шифрование данных, поэтому для расшифровки требуется пароль. Этот пароль будет известен только пользователям. Это потребуется при каждом создании новой записи, а также при каждом извлечении данных из старой записи. Шифрование / дешифрование происходит в JavaScript, поэтому пароль никогда не будет отправлен на сервер, где его можно было бы зарегистрировать или прослушать.
Hack II: Внесите изменения, которые регистрируют нажатия клавиш в javascript и отправляют их обратно на сервер, чтобы я мог восстановить пароль. Или разверните изменение, в котором просто хранятся незашифрованные данные в скрытом поле, которое можно опубликовать на сервере для последующего просмотра.

Сценарий III: Сделайте то же самое, что и Сценарий II, за исключением того, что шифрование / дешифрование происходит на веб-сайте, который мы не контролируем. Этот волшебный веб-сайт позволит пользователю ввести пароль и зашифрованные или текстовые данные, а затем использовать JavaScript для расшифровки или шифрования этих данных. Затем пользователь может просто скопировать зашифрованный текст и вставить поле для новых записей. Им также пришлось бы использовать этот сайт для просмотра простого текста старых записей.
Hack III: Помимо установки полноценного регистратора ключей в их системе, я не знаю, как его сломать.

Итак, Сценарий III выглядит многообещающе, но неудобно для пользователей. Есть ли другие возможности, которые я могу упускать из виду?

Answer 1

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

Разве эти проблемы обычно не решаются с помощью элементов управления:

1. Всем программистам необходим определенный уровень допуска и проверки данных
2. Они обучены понимать, что выкатывание кода для доступа к данным является пожароопасным или худшим преступлением
3. Каждое изменение в определенных областях требует своего рода подписи

Например - нет JavaScript на странице без подписи.

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

Answer 2

Я думаю, что вы все еще можете создать приложение следующим образом:

1. Создайте базу данных разработчиков и настройте для нее пользователя.
2. Спросите их: тип данных, размер и имя каждого поля, которое должно быть на экране.
3. Настройте экраны, создайте столбцы в базе данных, которые принимают указанный тип данных и размер.
4. Развертывание приложения в рабочем состоянии, подключенное к пустой базе данных. Попросите кого-нибудь с разрешением (не вас) войти и установить пароль для пользователя базы данных и установить пароль для пользователя БД в веб-приложении.
5. После этого авторизованные пользователи могут делать все, что хотят, и вы никогда не видели, как выглядят какие-либо данные.

Конечно, поддержание приложения и отладка будут очень сложными!

- в ответ на комментарии:

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

7. Предотвращение любых исходящих пакетов с аппарата, за исключением набора авторизованных рабочих станций - поэтому вы не можете установить шпионское ПО.

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

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

10. Если сервер когда-либо нуждается в отладке, выбросьте его в корзину, купите новый и начните с # 1.

А если серьезно - это неразрешимая проблема. Лучший ответ на этот вопрос:

Скажите им, что у них не может быть заявления. Напишите свои вещи на бумаге. Поместите это в папку. Запереть его в хранилище. Тяга, повтори.

Answer 3

Попросите клиента предоставить Соглашение о неразглашении, чтобы вы подписали его, подписали и посмотрели столько данных, сколько хотите.

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

Единственный способ, с помощью которого я могу придумать, где вы не будете смотреть на данные или делать с ними что-либо, - это простая форма сопоставления таблиц с параметрами CRUD. Если вы знаете, в каком формате будут поступать данные, вы сможете развернуть что-то с помощью RoR, простого скина, вставить SSL в набор и развернуть его. Протестируйте с фиктивными данными в том же формате, и все готово.

Фактически, ваш клиент не может предоставить фиктивные данные для тестирования? Если они могут, то ваша жизнь проста, так как все, что вы делаете, - это «устанавливаете» и говорите им, как редактировать файл конфигурации.

Answer 4

Я думаю, что я просто скажу им, что они либо должны доверять нескольким из нас, чтобы иметь доступ (а не смотреть на это), либо они не получают проект.

Спасибо за ответы. Не стесняйтесь отправлять больше мыслей, если они у вас есть.

Answer 5

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

Вы можете создать свою веб-страницу для безопасной динамической загрузки потока данных XML и отформатировать ее в веб-страницу с помощью сценария XSLT на клиенте.

См. http://www.w3schools.com/xsl/xsl_client.asp для примеров

Таким образом, вы создаете код, но у вас никогда нет доступа к данным. Только пользователь имеет доступ к своим данным.

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

Answer 6

Я должен сказать, что мне действительно не нравится идея использовать JavaScript на клиенте для расшифровки данных. Это огромная дыра, поскольку любой скрипт (хакер, GreaseMonkey, IE7Pro и т. Д.) Может получить доступ к DOM и получить данные со страницы.

Кроме того, очень трудно обойти проблему с регистраторами нажатий клавиш. Если вы бросите их в микс, то ваши возможности ограничены. В этот момент вам нужен защитный FOB, такой как RSA (обычно используется с корпоративными VPN), для генерации действительно случайных ПИН-кодов. Это, вероятно, будет дорого, и это больно, и я видел, как он используется только с VPN, но я предполагаю, что он может работать и с веб-сайтами.

Что касается веб-сайта, я бы использовал HTTPS и нашел бы способ шифрования / дешифрования через WebServer вместо того, чтобы полагаться на JavaScript. Трафик SSL не очень подвержен анализу (очень трудно расшифровать), поэтому шифрование и дешифрование происходит на стороне сервера, что (IMHO) более безопасно.

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

Answer 7

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

Answer 8

Разве сценарий 3 просто не предоставляет все данные волшебному веб-сайту? Это не похоже на решаемую проблему (по крайней мере, я не могу придумать решение).

Answer 9

Есть много вариантов, основанных на том, какова их цель на самом деле, но меня смущает их паранойя, э, намерение:

• Являются ли эти их (и данными конечного пользователя), которые они хотят, чтобы личные данные или данные конечного пользователя оставались конфиденциальными для всех?
• Это просто что ваша (или любая контрактная) компания является подозреваемой?
• Они боятся слежки по проводам?
• Боятся ли они доступа к DOM через плагины JavaScript или браузера?

Они планируют поэтапное развертывание? В этом случае вы работаете на тестовом сервере / dev без реальных данных, но не имеете доступа к производственному серверу с реальными данными, а правила ведения журнала DNS и / или правила брандмауэра не позволяют всем вашим хакам работать незамеченными.

В конечном итоге, если данные хранятся в БД, программист и администратор БД могут, работая вместе, получить их. Период. Хороший аудит должен раскрыть это, хотя.

Answer 10

(Они хотят, чтобы я сохранил его, не видя его никогда).

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

Их идея не будет работать по той же причине, по которой DRM не работает: цепочка доверия по своей сути скомпрометирована. В примерах шифрования часто используются Алиса, Боб и Чарли, где Алиса пытается общаться с Бобом без прослушивания Чарли. С DRM цепочка доверия скомпрометирована, потому что Боб и Чарли - один и тот же человек. В вашей ситуации Чарли - парень, который пишет программное обеспечение, которое Алиса и Боб используют для общения. Существует подразумеваемое доверие, потому что, если вы не доверяете Чарли, вы также не можете доверять программному обеспечению Чарли.

В этом корень проблемы: доверие. Если они не могут доверять программисту, игра заканчивается до ее запуска.