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

если вам страшно хранить данные в атласе, потому что вы боитесь что монговцы или %имя_облачного_провайдера% будут иметь доступ к вашим данным, то не храните там данные

возьмите сейф побольше, поставьте в него ups и сервер, поднимите там entersprise монгу с encryption on rest ($15k в год за ноду), придумайте как сделать airgap прямо в монговский протокол и у вас будет защищенный контнейр с монгой

данные это _никак_ не защитит

потому что у вас скорее всего будет пользователь с правами на чтение всего хранилища, который будет доступен широкому кругу лиц ;)

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

так _нельзя_ делать

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

Хранить данные кастомеров в атласе звучит как-то безответственно, разве нет?

нет

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

но это всё зависит от того, чего вы боитесь

Всем привет,при запуске теста phpunit выдает ошибку MongoDB\Driver\Exception\BulkWriteException: 24: Too many open files . С чем это связано и как это исправить?

ребят, а подскажите, куда ткнуться, чтобы посмотреть версию монги в атласе?

все, нашел, спасибо

но с ним есть проблема: вы лишаетесь поиска по этим полям

допустим зашифрованный пароль (qwerty) будет: k1h4i12urh21duid12h&1%$765$ Как я себе представляю аутентификацию: пользователь вводит свой пароль: «qwerty» => отправляет данные в body POST-запроса на сервер => сервер берет req.body.password и используя тотже process.env.CRYPRO_KEY преобразует «qwerty» в «k1h4i12urh21duid12h&1%$765$» и делает поиск по этому полю и находит данный документ. Так можно будет сделать?

допустим зашифрованный пароль (qwerty) будет: k1h4i12urh21duid12h&1%$765$ Как я себе представляю аутентификацию: пользователь вводит свой пароль: «qwerty» => отправляет данные в body POST-запроса на сервер => сервер берет req.body.password и используя тотже process.env.CRYPRO_KEY преобразует «qwerty» в «k1h4i12urh21duid12h&1%$765$» и делает поиск по этому полю и находит данный документ. Так можно будет сделать?

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

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

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

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

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

Добрый всем, человек помог статистикой: 10:43:29 [kom] > select count(*) from population_points; ┌─────────┐ │ count │ ├─────────┤ │ 1981984 │ └─────────┘ (1 row) Time: 34,953 ms 10:43:31 [kom] > update population_points set minute = minute+1; UPDATE 1981984 Time: 22091,047 ms (00:22,091) 10:44:07 [kom] > update population_points set minute = minute-1; UPDATE 1981984 Time: 21912,022 ms (00:21,912) Может кто-либо дать метрики по приблизительному updateMany для 2 миллионов документов?

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

Ну я и ищу по полю email всегда. А нужно иначе как то делать? Подскажите, буду рад советам

допустим зашифрованный пароль (qwerty) будет: k1h4i12urh21duid12h&1%$765$ Как я себе представляю аутентификацию: пользователь вводит свой пароль: «qwerty» => отправляет данные в body POST-запроса на сервер => сервер берет req.body.password и используя тотже process.env.CRYPRO_KEY преобразует «qwerty» в «k1h4i12urh21duid12h&1%$765$» и делает поиск по этому полю и находит данный документ. Так можно будет сделать?

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

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

Зачем md5 когда есть sha?

Md5 не безопасный

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

Мне советовали crypto-js/aes

Там есть и шифрование и дешифрование. Мне это подходит, думал

Мне советовали crypto-js/aes

Тоже можно

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

И да двойной мд5 с солью достаточно зпщищен

И да двойной мд5 с солью достаточно зпщищен

с ним можно и шифровать и дешифровывать или там только хешировать

с ним можно и шифровать и дешифровывать или там только хешировать

Хэшировать только, конечно

допустим зашифрованный пароль (qwerty) будет: k1h4i12urh21duid12h&1%$765$ Как я себе представляю аутентификацию: пользователь вводит свой пароль: «qwerty» => отправляет данные в body POST-запроса на сервер => сервер берет req.body.password и используя тотже process.env.CRYPRO_KEY преобразует «qwerty» в «k1h4i12urh21duid12h&1%$765$» и делает поиск по этому полю и находит данный документ. Так можно будет сделать?

^ тогда для описанной мною процедуры это не подойдет похоже

Хэшировать только, конечно

^

А зачем тебе шифрование-то?

И да двойной мд5 с солью достаточно зпщищен

Плюсом всегда фиксированная длинна, которая будет меньше по байтам занимать, чем aes или sha)

Но это так лирическое отступление, которое к данной ситуации отношения не имеет

А зачем тебе шифрование-то?

Задачу такую поставили

А зачем тебе шифрование-то?

Предположу что пресловутый gdpr

Там есть такие нормы

Задачу такую поставили

В монго энтерпрайз есть encrypted storage

Задачу такую поставили

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

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

так вот я и хочу быстро сделать с crypro/aes

Задачу такую поставили

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

В монго энтерпрайз есть encrypted storage

просто нужно чтобы в документах вместо { login: «vasya», password: «123», email: «vasya@123.com» } Лежало: { login: «cryptedLogin», password: «cryptedPassword», email: «cryptedEmail» }

просто нужно чтобы в документах вместо { login: «vasya», password: «123», email: «vasya@123.com» } Лежало: { login: «cryptedLogin», password: «cryptedPassword», email: «cryptedEmail» }

А для чего пароль расшифровывать?

А для чего пароль расшифровывать?

Это небезопасно

А для чего пароль расшифровывать?

Ну хорошо, пароль расшифровывать не нужно, а логин допустим, нужно. Пользователь введет емайл-пароль, ему с запроса должен вернуться логин «vasya» (закинуть логин в редакс-стор)

Логин вроде под gdpr не попадает, а мыло хэшировать и все

Логин вроде под gdpr не попадает, а мыло хэшировать и все

мыло нужно пользователю отображать в ЛК по запросу

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

Мне отличные дали советы (спасибо 🙏) , как делать правильно в серьезном продукте, сейчас же у меня демо-прототип, и нужно сделать быстро

мыло нужно пользователю отображать в ЛК по запросу

Он сказал онли про логин

Ну хорошо, пароль расшифровывать не нужно, а логин допустим, нужно. Пользователь введет емайл-пароль, ему с запроса должен вернуться логин «vasya» (закинуть логин в редакс-стор)

а какая у вас версия монги?

а какая у вас версия монги?

mongoDB atlas 4.0.13

Мне отличные дали советы (спасибо 🙏) , как делать правильно в серьезном продукте, сейчас же у меня демо-прототип, и нужно сделать быстро

Ну так любой крипто библиотекой шифрую на бэке перед инсертом/апдейтом и при файнде расшифровывай.

mongoDB atlas 4.0.13

Атлас зашифрован

По умолчанию

Ну так любой крипто библиотекой шифрую на бэке перед инсертом/апдейтом и при файнде расшифровывай.

Спасибо, ок, работаю!

Сам сторейдж

Защитить доступ к нему сертификатом и получится что и доступ и данные зашифрованы

Зачем извращаться

mongoDB atlas 4.0.13

не реально до 4.2 апнуть? вчера @dd_bb правильно писал, что в вашем случае самое быстрое решение это использовать field level encryption и не парится, пусть база сама шифрованием занимается

Сам сторейдж

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

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

Ору, ладно

Тогда так как я сказал

не реально до 4.2 апнуть? вчера @dd_bb правильно писал, что в вашем случае самое быстрое решение это использовать field level encryption и не парится, пусть база сама шифрованием занимается

4.2 недавно вышла? я регистрировался полтора месяца назад, думал автоматом стоит последняя

Ору, ладно

Не я придумывал)

4.2 недавно вышла? я регистрировался полтора месяца назад, думал автоматом стоит последняя

18 октября, как следует из шапки чата последний релиз)

18 октября, как следует из шапки чата последний релиз)

Теперь ясно

4.2 недавно вышла? я регистрировался полтора месяца назад, думал автоматом стоит последняя

Она доступна только на платных планах сейчас

Она доступна только на платных планах сейчас

Отпадает(

всем денб добрый! вопросик (не пинайте) база растет, один сервер думаю как далее быть бюджет не велик, но производительности хочется реплики помогут? взять 3 сервера: - primary - secondary - arbiter настроить между собой и получить реплика сет такой вариант будет лучше в производительность? или все также останется по сути и только в надежности выигрыш будет?

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

или я не правильно понимаю? можно скажем читать и с primary и secondary? а писать только в primary?

по сути же в репликах можно будет читать и с primary и с secondary серверов тем самым понятно что производительность выше будет

или я не правильно понимаю? можно скажем читать и с primary и secondary? а писать только в primary?

да

Репликации не добавляет ёмкости в кластер

Она добавляет копии данных для отказоустойчивости

с реплик можно читать

и писать при шардировании

только нужно получше почитать конфигурацию реплик