Зашифровать данные в базе данных

[StrangerR]

Объясните им что без HSM в случае рестарта сервиса нужно всегда вводит пароль в данной схеме, то бишь fault tollerance зависит от доступности правильного человека и насколько быстро от подорвёться восстановить сервис. Я так понимаю что у них 24/7 NOC отсутсвует

я немного не догоняю о каком пароле идет речь тут Вот допустим решили клоуны эти хранить ключ шифрования на HSM. Наше приложение (веб приложение плюс виндовый сервис) должны иметь доступ к этому ключу постоянно, потому что дешифрация данных из базы идет постоянно. Ну шифрация происходит не так часто (добавление новых данных или изменение существующих). Можно ключ считать в память, но тогда при перезапуске приложения или сервиса нужно вставлять HSM, чтобы приложение заново считало ключ в память. Либо держать HSM все время подключенным к серверу. Вообщем они поняли что работа с HSM будет требовать от НИХ каких то усилий и трат денег, поэтому они отказались от этого..

Одним из критериев безопасности при шифровании данных в базе (когда шифрует само приложение) это хранить ключ шифрования на сервере отличном от сервера баз данных. Что мы и делаем. Если хотите поменять ключ, то извините, но придется поднять жопу и приложить какие то усилия (удалить старую инфу из базы, поменять ключ в файле и создать новые данные с новым ключом). А то хотят иметь 100% bullet proof систему и при этом ни хера не делать и не тратить деньги на это.

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

Тут же проблема совсем в другом. Во первых все строится так чтобы если _утащили данные_ то они были бы бесполезны. Причем утащили реальным методом. А то строят шифрование базы данных которое защищает только от _враги уперли ваши диски_ а от реальных +хакер вкинул код и код выполнил select * from users+ не защищают. То есть шифровать надо все таки уже на уровне приложения. А дальше, если ключ берется - дается - с соседнего сервера а еще лучше соседний сервер занимается дешифрацией (шифровать можно открытым ключем) то если мы влезли на соседний сервер - ну можем мы подслушать чуть чуть бегущих через него данных и все. Если влезли на сервер приложения - можем чуть чуть расшифровать данные запрашивая расшифровку. Но утащить все данные и расшифровать их не выйдет. Что и требуется.

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

С ключем который вводит человек. Ну можно а на фига спрашивается если у вас сервер который ключ выдает и так выдаст его лишь одному IP адресу а еще лучше сам и будет шифрацией заниматься. Чем тут собственно человек что то улучшит то? Если сервер УЖЕ занимается дешифрацией а его сломали то ключ там УЖЕ есть. Тут нужно чтобы кража данных была бесполезной без одновременной кражи и этого сервера. А так, если ключ где то там живет где и данные то его утащат. Можно конечно каждый раз за ключем ходить. Но не проще тупо давать расшифровать а не самим этим заниматься? Ключ то в памяти будет а вот если апп сервер сам не дешифрует то хоть ты его целиком упри, друому серверу данные не расшифруют.

В общем я не очень понимаю цимис _хранить ключ на другом сервере_. Он все равно у вас в памяти будет или его следы. Хотя такой подход лучше чем хранить у себя. Но не лучше ли тогда _а пусть этот другой и дешифрует_? А для тестирования - некоторые данные дешифровать через табличку (шифрованная строка, расшифрованная строка) а именно данные в тестовом аккаунте после чего тестеры смогуть работать без доступа к дешифрации.

[shadow7256]

У нас так и есть сейчас. База данных на одном физическом сервере "А", наше приложение на другом физическом сервере "Б". Само наше приложение и шифрует и дешифрует данные, которые хранятся в базе.

Если базу сперли, то нужен ключ, чтобы расшифровать данные. Тот же SELECT тоже выдаст зашифрованные данные, опять нужен ключ.

Ключ будет хранится на сервере "Б", где стоит наше приложение (поближе к тому месту где и происходит шифрование/дешифрование). Хранить ключ клиент хочет в файле на диске и при этом поставив на файл уровни доступа для разных аккаунтов (через Access Control List). Хранится ключ будет в открытом виде, потому что потом клиент захочет поменять его на другой... так может хранить его в Windows Registry в какой нибудь ветке?

[Davidmenk3]

I now understand what instances they are talking about here . The system is like this..

There are TWO components that will have access to encryption/decryption of data from the database. The first module is Web Application (hosted in IIS). It is launched under the user under which the Application Pool instance is configured for this application.

The application provides an interface for configuring SMTP server parameters (the user specifies the host, port, SMTP username, SMTP password, certificates, and other parameters and saves this in the database).

The second module is Windows service, which is actually engaged in sending messages to the SMTP server. The service is also launched under some account (by default under Local Account, but can be configured under any).

Both modules (Web Application and Windows service) are installed on the same server.

Got it! The setup here involves two components accessing encrypted data: a web application hosted on IIS (using the Application Pool instance's credentials) for configuring SMTP settings, and a Windows service that sends messages to the SMTP server. Both are on the same server. If you need reliable dedicated server hosting to support this type of structure, HostNoc has great options to consider.