Блог

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

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

Мы подумали о шифровании / дешифровании конфиденциальных данных с помощью частной / общедоступной пары ключей, закрытый ключ которой зашифрован паролем пользователя, но обнаружили некоторые проблемы с безопасностью и реализацией: P

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

Чтобы дать некоторое дополнительное представление: этот проект еще не находится на стадии производства, поэтому еще есть время все исправить.

мы уже делаем некоторые базовые вещи, такие как

• обслуживание https
• принудительное использование https для сайтов, которые могут обрабатывать конфиденциальные данные
• хеширование соленых паролей
• некоторое усиление нашего сервера и служб на нем
• зашифрованные жесткие диски, чтобы кто-то не мог прочитать всю информацию о клиенте после кражи наших серверов / жестких дисков

но это все, кроме хэшей паролей, нет механизма, который остановил бы /, по крайней мере, затруднил бы кому-то, кому удалось проникнуть на (часть) сервера, чтобы получить все данные обо всех наших пользователях. Мы также не видим способа зашифровать пользовательские данные, чтобы отключить наше «я» от их чтения, поскольку нам нужны данные (иначе мы бы их не собрали) для какой-то части веб-сайта / функциональности, которую мы хотим, чтобы она предоставляла. Даже если нам, например, каким-то образом удалось (возможно, с помощью некоторого javascript), чтобы все данные попадали к нам в зашифрованном виде (с помощью браузера клиента), и мы предоставляем клиенту его приватный ключ, зашифрованный с помощью некоторой парольной фразы (например, его пароля для входа), мы не могли, например, сканировать загруженные пользователем файлы на наличие вирусов инравится. С другой стороны, может ли шифрование на стороне клиента, по крайней мере, с концепцией браузера / веб-сервера, оставить некоторые проблемы с безопасностью, по крайней мере, так, как мы себе это представляем (вы можете доказать, что я ошибаюсь), и, похоже, это похоже на изобретение колеса, и, возможно, поскольку этот проект в первую очередь касается не конфиденциальности, а конфиденциальностипредпочтительное свойство, для которого мы, возможно, не захотим изобретать велосипед. Я твердо верю, что я не первый веб-разработчик, думающий об этом, не так ли? Итак, что сделали другие проекты? Что вы сделали, чтобы попытаться защитить данные своих пользователей?

если это уместно, мы используем django и PostrgreSQL для большинства вещей и javascript для некоторых пользовательских интерфейсов

Распространенный способ решения этой проблемы — разделить (разделить) ваши данные.

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

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

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

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

Обновить:

Шифрование на стороне клиента может очень помочь, поскольку оно возлагает ответственность за шифрование на пользователя. Например, проверьте LastPass. Без выполнения шифрования на стороне клиента вы никогда не сможете доверять сервису. Аналогично со службами резервного копирования, где вы устанавливаете свой ключ локально, чтобы резервные копии никогда не могли быть разблокированы кем-либо на сервере — у них никогда не будет ключа.

Разделение является одним из основных методов для предприятий по защите сервисов, которые имеют компоненты, подключенные к Интернету. Как я уже сказал, как правило, защищенный сервер извлекает данные из менее защищенного, поэтому менее защищенный сервер никогда не сможет получить доступ к чему-либо более безопасному, даже если он полностью скомпрометирован. Действительно, будет брандмауэр, который предотвращает попадание любого трафика из DMZ (где расположена менее защищенная служба) в защищенную сеть. Разрешены только соединения с защищенной стороны, и они будут строго контролироваться процессами безопасности. В типичном банке или другой системе с высоким уровнем безопасности вы вполне можете найти несколько подобных уровней, каждый из которых имеет отдельные элементы управления безопасностью, все они отделены друг от друга, обеспечивая разделение данных и безопасности.

Надеюсь, это добавит некоторой ясности. Продолжайте спрашивать, если нет!

ОБНОВЛЕНИЕ 2:

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