Ну идея держать ключ на другом сервере не плоха. И выдавать его по запросу в память.shadow7256 wrote: ↑09 May 2021 17:32я немного не догоняю о каком пароле идет речь тутВот допустим решили клоуны эти хранить ключ шифрования на HSM. Наше приложение (веб приложение плюс виндовый сервис) должны иметь доступ к этому ключу постоянно, потому что дешифрация данных из базы идет постоянно. Ну шифрация происходит не так часто (добавление новых данных или изменение существующих). Можно ключ считать в память, но тогда при перезапуске приложения или сервиса нужно вставлять HSM, чтобы приложение заново считало ключ в память. Либо держать HSM все время подключенным к серверу. Вообщем они поняли что работа с HSM будет требовать от НИХ каких то усилий и трат денег, поэтому они отказались от этого..
Одним из критериев безопасности при шифровании данных в базе (когда шифрует само приложение) это хранить ключ шифрования на сервере отличном от сервера баз данных. Что мы и делаем. Если хотите поменять ключ, то извините, но придется поднять жопу и приложить какие то усилия (удалить старую инфу из базы, поменять ключ в файле и создать новые данные с новым ключом). А то хотят иметь 100% bullet proof систему и при этом ни хера не делать и не тратить деньги на это.
Тут же проблема совсем в другом. Во первых все строится так чтобы если _утащили данные_ то они были бы бесполезны. Причем утащили реальным методом. А то строят шифрование базы данных которое защищает только от _враги уперли ваши диски_ а от реальных +хакер вкинул код и код выполнил select * from users+ не защищают. То есть шифровать надо все таки уже на уровне приложения. А дальше, если ключ берется - дается - с соседнего сервера а еще лучше соседний сервер занимается дешифрацией (шифровать можно открытым ключем) то если мы влезли на соседний сервер - ну можем мы подслушать чуть чуть бегущих через него данных и все. Если влезли на сервер приложения - можем чуть чуть расшифровать данные запрашивая расшифровку. Но утащить все данные и расшифровать их не выйдет. Что и требуется.
Правда для сертификаций как раз нужна прозрачная шифрация в базе данных. Хотя это и потемкинская деревня.
С ключем который вводит человек. Ну можно а на фига спрашивается если у вас сервер который ключ выдает и так выдаст его лишь одному IP адресу а еще лучше сам и будет шифрацией заниматься. Чем тут собственно человек что то улучшит то? Если сервер УЖЕ занимается дешифрацией а его сломали то ключ там УЖЕ есть. Тут нужно чтобы кража данных была бесполезной без одновременной кражи и этого сервера. А так, если ключ где то там живет где и данные то его утащат. Можно конечно каждый раз за ключем ходить. Но не проще тупо давать расшифровать а не самим этим заниматься? Ключ то в памяти будет а вот если апп сервер сам не дешифрует то хоть ты его целиком упри, друому серверу данные не расшифруют.
В общем я не очень понимаю цимис _хранить ключ на другом сервере_. Он все равно у вас в памяти будет или его следы. Хотя такой подход лучше чем хранить у себя. Но не лучше ли тогда _а пусть этот другой и дешифрует_? А для тестирования - некоторые данные дешифровать через табличку (шифрованная строка, расшифрованная строка) а именно данные в тестовом аккаунте после чего тестеры смогуть работать без доступа к дешифрации.