Есть необходимость шифровать некоторые данные которые хранятся в БД.
На данный момент склоняюсь к стеку БД cassandra и шифрование RSA 2048
Например есть таблица пользователей id, name, phone. Цель зашифровать данные из колонки phone.
И тут у меня 2 варианта:
1) напрямую в таблице пользователей в колонке phone вписать шифрованные данные
2) выделить отдельную таблицу id, keyId, value (keyId - идентификатор ключа шифрования, value - хеш) и в колонке phone хранить id шифрованных данных.
Собственно почему такие 2 варианта.
1 вариант в лоб простой.
2 вариант позволит менять ключи шифрования путем расшифровки значения, создания новой строки с хешем от нового ключа шифрования и просто перезаписать id строки поле phone. Так же это позволит вынести шифрование\дешифрование на отдельный сервис с отдельным доступом к БД.
Остается еще вопрос с поиском по зашифрованным данным, если есть мысли - поделитесь :)
Так же не откажусь от критики по поводу стека
Мысль такая: шифрование данных на сервере, которому эти самые данные нужны расшифрованными, подобно хитрому замку, рядом с которым на гвоздике висит ключ.
Стойким считается алгоритм, успешная атака на который требует от атакующего обладания недостижимым на практике объёмом вычислительных ресурсов или перехваченных открытых и зашифрованных сообщений либо настолько значительных затрат времени на раскрытие, что к его моменту защищённая информация утратит свою актуальность
иными словами: имея алгоритм шифрования как долго будет подбираться ключ
writer_2159, цимес как раз в том, что ключ должен лежать тут же, на сервере, раз вы собрались на нем же делать расшифровку. И вся затея лишается смысла.
Adamos, логично. можно запрашивать у отдельного сервиса который хранит ключи (первое что пришло в голову), но это не решает того что его можно слить "до кучи"
writer_2159, лучше просто не хвататься за первое, что пришло в голову, и не разводить шифрование там, где вы же сами будете вынуждены его похерить ради поиска по этому полю.
Навешивание замков - это не безопасность. Безопасность - это когда удобно всем, кому можно, и невозможно тем, кому нельзя. Про первую часть слишком часто забывают, и это приводит к тому, что старательно выстроенное исключительно по второй - не работает.
лучше бабки на безопасность пилить не на костыли, а заняться безопасностью самой инфраструктуры. Ваша проблема не в том, будет ли БД битая при сливе, а в том, что её вообще можно слить. Как и с любой болезнью организма - нужно личить причину а не устранять симптомы делая вид что всё хорошо.
Сложный
Простой
Простой
