Самый простой пример. Требуется хранить в базе данных номера кредитных карт. В случае утечки этой базы будет полный П.
Ок. Храним данные карт в зашифрованном виде. Ключом шифрования например будет пароль пользователя или его производная.
Пароль хранится в базе в виде хэша, поэтому просто так вытащить его из базы и расшифровать данные карт не получится.
Какие best practice по хранению зашифрованной информации на сервере и расшифровке на клиенте (браузере)?
При этом, в памяти сервера будут в любом случае появляться данные в расшифрованном виде. Т.е. сняв дамп памяти, можно откопать там данные. Но для этого нужен рутовый доступ к серверу.
Re: Как защитить данные пользователей веб-приложения?
Здравствуйте, Yodo, Вы писали:
Y>Самый простой пример. Требуется хранить в базе данных номера кредитных карт. В случае утечки этой базы будет полный П.
Y>Ок. Храним данные карт в зашифрованном виде. Ключом шифрования например будет пароль пользователя или его производная. Y>Пароль хранится в базе в виде хэша, поэтому просто так вытащить его из базы и расшифровать данные карт не получится.
Y>Какие best practice по хранению зашифрованной информации на сервере и расшифровке на клиенте (браузере)?
Y>При этом, в памяти сервера будут в любом случае появляться данные в расшифрованном виде. Т.е. сняв дамп памяти, можно откопать там данные. Но для этого нужен рутовый доступ к серверу.
А не нужно хранить у себя номера кредитных карт. Вам процессинговый центр, через который вы обрабатываете платежи должен предоставить информацию по работе. И требования по передаче информации к ним.
BE>А не нужно хранить у себя номера кредитных карт. Вам процессинговый центр, через который вы обрабатываете платежи должен предоставить информацию по работе. И требования по передаче информации к ним.
А по существу есть что сказать?
Есть много других данных кроме кредитных карт. Например, можно хранить ключи/доступы к соц. сетям для постинга через API.
Доступ к API банка для извлечения данных, и т.д.
Самый простой пример — email клиент онлайн, который обязан хранить пароли к вашим ящикам чтобы на них авторизовываться и вытягивать почту.
Re[3]: Как защитить данные пользователей веб-приложения?
Здравствуйте, Yodo, Вы писали:
Y>Самый простой пример — email клиент онлайн, который обязан хранить пароли к вашим ящикам чтобы на них авторизовываться и вытягивать почту.
Он не хранит пароли. Он хранит access и refresh-токены.
Почитайте про организацию авторизации, скажем на примере identity server: Welcome to IdentityServer4 (latest)
Y>Самый простой пример — email клиент онлайн, который обязан хранить пароли к вашим ящикам чтобы на них авторизовываться и вытягивать почту.
Почему нельзя хранить пароли на самом клиенте? Зачем тут сервер?
Ну а если (например, в банковской системе) особо важные данные приходится хранить на сервере, то тут не обойтись без физической защиты. Сервер должен быть в защищённом помещении, под надёжной охраной, чтобы никто не мог снять дамп. Плюс особые меры информационной защиты (TPM, data diode и многое другое).
Re[4]: Как защитить данные пользователей веб-приложения?
Здравствуйте, Yodo, Вы писали:
Y>Потому что клиент — браузер.
Y>Другой пример — делаем сервис, который подключается к 4 соц сетям и мониторит сообщения. Y>Опять же надо хранить API ключи к соц-сетям на сервере.
В этом случае в куке браузера вы храните acces-токен для своего сервиса.
А ключи к соц. сетям вы храните на своем сервере и на клиента (в браузер) вам их отдавать не нужно.
Ну да, тут сервер нужен свой и админам платить, что б у них не было желания базы сливать.
Вообще ключи к соц. сетям — это не данные платежных карт. Достаточно поле в бд зашифровать как по мне.
BE>Вообще ключи к соц. сетям — это не данные платежных карт. Достаточно поле в бд зашифровать как по мне.
Еще пример. Сейчас много платформ предоставляют ключи API. Например, Amazon AWS. Если будут скомпроментированы ключи, от вашего аккаунта можно начать майнить на тысячи долларов мощностей.
И это возможно даже хуже чем потерять на кредитке какие-то деньги.
Еще. API ключ к криптобирже или просто бирже, по которому работает торговый робот.
Однозначно эти данные надо шифровать, если держим в базе. Вопрос — где хранить ключ дешифрования.
Предлагается архитектура с хранением ключа дешифрования на клиенте.
1. Сервер решил получить доступ к соц сети по REST и воспользоваться ключом.
2. Сервер запросил у клиента ключ по защищенному протоколу
3. Клиент передал ключ по защищенному протоколу
4. Сервер использовал ключ, расшифровал им API key в базе, получил данные из соц сети и обнулил ссылку на объект ключа.
key = null;
5. Сборщик мусора удалит из памяти ключ через некоторое время. А если и не удалит String, то даже по дампу сложно будет понять к чему этот ключ относился.
По аналогии с ключами на флэш-носителях. Пока носитель вставлен в USB разъем, все работает. Вытащили — не работает.
Так и здесь, сервер может обращаться к сторонним ресурсам до тех пор пока клиент залогинен в сервисе и разрешает серверу использовать ключ.
Недостаток вижу только один. Если серверу необходимо делать что-то cron-ом периодически, а клиент отвалился, то сервер не может двигаться дальше, т.к. ожидает ключа от клиента.
Re[7]: Как защитить данные пользователей веб-приложения?
Y>Еще пример. Сейчас много платформ предоставляют ключи API. Например, Amazon AWS. Если будут скомпроментированы ключи, от вашего аккаунта можно начать майнить на тысячи долларов мощностей. Y>И это возможно даже хуже чем потерять на кредитке какие-то деньги.
Secure, store and tightly control access to tokens, passwords, certificates, encryption keys for protecting secrets and other sensitive data using a UI, CLI, or HTTP API.
Здравствуйте, Yodo, Вы писали:
Y>Самый простой пример. Требуется хранить в базе данных номера кредитных карт. В случае утечки этой базы будет полный П.
Самый простой способ — выделить под оплату отдельный физический сервер и крутить на нем микросервис, который по токену аутентификации пользователя что-то там оплачивает. Номера кредиток хранятся на этом сервере и никогда его не покидают. И, конечно, секьюрити затянуть — файрволл, отдельный ключ для ssh, ограничить кол-во людей, у которых есть доступ и т.д.
Или можно хоститься в облаке, там есть свои способы обеспечения безопасности.
