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

[kostik78]

Встает вопрос где хранить encryption key ? Они предлагают два решения

1. Хранить его в файле на диске, и каким то образом сделать так, чтобы доступ к этому файлу имело только наше приложение. Как это сделать непонятно.
2. Хранить ключ внутри кода, но это не очень хорошо, тогда они не смогут его поменять без рекомпиляции приложения.

Вот интересно HSM можно использовать для хранения ключа как то?

А в чем проблема выставить file permissions? Root конечно будет иметь доступ но обычно root никому не разрешён а sudo разрешён только ограниченому списку людей

Второй вариант это классический пример как делать не надо

[Palych]

Напомните, на сервере только один instance крутится?
От кого защищаемся - только от доступа к данным помимо приложения, или от других пользователей внутри приложения?

[StrangerR]

Во первых все уважающие RDBMS имеют встроенную поддержку шифрования и во вторых, систему управления ключами (что кстати ещё важнее чем само шифрование). Поэтому не надо изобретать велосипед, а читать документацию.
Например: https://docs.microsoft.com/en-us/sql/re ... rver-ver15

ТОлку с этой поддержки нуль. Аппликухи имеют доступ к уже расшифрованным данным. Вся эта прозрачная шифрация гроша ломанного не стоит и нужна лишь для самоуспокоения _мол враг украдет диски и... а ничего не прочтет_. Но кто помнит случай когда враги _крали диски_? Враги впрыскивают код в приложение уже после того как оно ввело все ключи. И select * from users и усе, приехали, грубо говоря.

А вот если шифрует сама аппликуха то впрыснутый код ничего не даст.

[StrangerR]

Их продукты позволяют хранить пароли в vault и много ещё чего. Модная сейчас компания.

Главное, в то что хранится в ваульте подмешать еще что то свое. Чтобы кража ваульта или там передачи из оного (что в целом не так уж и нереально) дала нечто что само по себе бесполезно.

Вообще говоря, самопырки в случае шифрации могут (в сочетании с продакшен алгоритмами) быть понадежнее, чем тупо _взять продукт и заюзать_ - продукт наверняка знаком куче народу а вот его сочетание с самопыркой - не особо. Конечно, ГРУ или там CIS разберутся, но тупо кража данных хакерами станет невозможной. ВОобще говоря, общее правило - всегда иметь больше 1 уровня защиты - так как
_ любой уровеь можно сломать, забор перелезть, стену продолбить
_ любой взлом будет обнаружен за среднее время Т1
_ на слом следующей стены или что там накручено нужно среднее время Т2
_ Т1 должно быть заметно меньше чем Т2.

А любая одноуровневая защита вроде _супер пупер шифрации с каким то супер ваультом_ может быть взломана причем за весьма конечное время (ну еще есть способ называется _пистолет - и сам сознаешься_).

А так да. Хранить любой пусть несимметричный ключ. По этому ключу - его публичной частью зашифровать симметричный пароль и куда то сунуть. А приватным ключем расшифровывать и по полученному расшифровывать данные. А по пути в ключ еще что то свое подсунуть.

[shadow7256]

От кого защищаемся - только от доступа к данным помимо приложения, или от других пользователей внутри приложения?

да они сами толком не знают от кого они защищаются. Поэтому и толком не могут дать конкретные требования.

Пока ясно одно - хотят защититься от всего и забесплатно.

[Palych]

От кого защищаемся - только от доступа к данным помимо приложения, или от других пользователей внутри приложения?

да они сами толком не знают от кого они защищаются. Поэтому и толком не могут дать конкретные требования.

Пока ясно одно - хотят защититься от всего и забесплатно.

Мы однажды подключались к веб сервису 3-й стороны.
Там задумывалась TLS mutual authentication с сертификатами и проч.
Один очень влиятельный клиент не смог заставить это работать.
И предложил: "Мы не можем справиться с client authentication. Но ведь есть server authentication, Правильно?" Провайдеры сказали: "Правильно. Любой каприз за ваши деньги."

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

[kostik78]

От кого защищаемся - только от доступа к данным помимо приложения, или от других пользователей внутри приложения?

да они сами толком не знают от кого они защищаются. Поэтому и толком не могут дать конкретные требования.

Пока ясно одно - хотят защититься от всего и забесплатно.

Вопрос Палыча про инстансы важен (dedicated or shared server or containers) и также важно под каким юзверем запущено приложение. Если приложение крутится под выделенным юзверем то достаточно на файле выставить пермишены и не кто кроме root и этого юзера прочитать файл не смогут (для *nix, с Виндой последние 15 лет не общался так что не знаю как там шас)

[Flash-04]

От кого защищаемся - только от доступа к данным помимо приложения, или от других пользователей внутри приложения?

да они сами толком не знают от кого они защищаются. Поэтому и толком не могут дать конкретные требования.

Пока ясно одно - хотят защититься от всего и забесплатно.

У банков есть жуткий враг - регуляторы. Вот одно из их требований иметь зашифрованные данные в случае data breach. Это если вам в сеть пробрались враги и вытащили данные просто дампом файлов.

[Flash-04]

От кого защищаемся - только от доступа к данным помимо приложения, или от других пользователей внутри приложения?

да они сами толком не знают от кого они защищаются. Поэтому и толком не могут дать конкретные требования.

Пока ясно одно - хотят защититься от всего и забесплатно.

Мы однажды подключались к веб сервису 3-й стороны.
Там задумывалась TLS mutual authentication с сертификатами и проч.
Один очень влиятельный клиент не смог заставить это работать.
И предложил: "Мы не можем справиться с client authentication. Но ведь есть server authentication, Правильно?" Провайдеры сказали: "Правильно. Любой каприз за ваши деньги."

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

Не понял. Server authentication - стандартная вещь. Client authentication - вам выдали сертификат, вы его установили, сервер его проверяет. У нас есть такие сервисы. Так что не заработало?
Кстати был случай, когда используя DNS spoofing враги смогли получить некоторые сертификаты клиентов. Их потом перевыпускали.

[Palych]

Не понял. Server authentication - стандартная вещь. Client authentication - вам выдали сертификат, вы его установили, сервер его проверяет. У нас есть такие сервисы. Так что не заработало?

Честно говоря, не помню что там не заработало, но выделенное неверно.
И я, честно говоря, зарёкся объяснять почему.
Просто предлагаю всегда не использовать certificate based client authentication.

[shadow7256]

Вопрос Палыча про инстансы важен (dedicated or shared server or containers) и также важно под каким юзверем запущено приложение. Если приложение крутится под выделенным юзверем то достаточно на файле выставить пермишены и не кто кроме root и этого юзера прочитать файл не смогут (для *nix, с Виндой последние 15 лет не общался так что не знаю как там шас)

я понял теперь про какие инстансы тут говорят Система такая..

Есть ДВА компонента, которые будут иметь доступ к шифрованию/дешифрованию данных из базы данных. Первый модуль - Web Application (hosted in IIS). Запущено под тем юзером, под которым настроен Application Pool instance для этого приложения.

Приложение предоставляет интерфейс для настройки параметров SMTP cерверов (пользователь задает host, port, SMTP username, SMTP password, certificates, и другие параметры и сохраняет это в базе данных).

Второй модуль - Windows service, который собственно занимается отсылкой сообщений на SMTP cервер. Сервис тоже запущен под каким то аккаунтом (по дефолту под Local Account, но можно настроить под любым).

Оба модуля (и Web Application и Windows service) установлены на одном сервере.

[shadow7256]

Не понял. Server authentication - стандартная вещь. Client authentication - вам выдали сертификат, вы его установили, сервер его проверяет. У нас есть такие сервисы. Так что не заработало?

Честно говоря, не помню что там не заработало, но выделенное неверно.
И я, честно говоря, зарёкся объяснять почему.
Просто предлагаю всегда не использовать certificate based client authentication.

а почему неверно? Мы лично так наше WEB API защищаем.

API требует наличия client certificate в каждом запросе, считывает сертификат и делает валидацию (много способов, но один из способов тупо проверить стоит ли такой сертификат на машине сервера).

[shadow7256]

У банков есть жуткий враг - регуляторы. Вот одно из их требований иметь зашифрованные данные в случае data breach. Это если вам в сеть пробрались враги и вытащили данные просто дампом файлов.

да разве мы ж против ) мы им с самого начала так и предложили сделать, а именно шифровать sensitive data через AES-256. Шифровать самой базой им не подошло (я уже говорил про обезьяну из Индии). Извиняюсь, но они еб..т мозг какой месяц уже, наши менеджеры сказали что this project is set on hold for now.

[kostik78]

Вопрос Палыча про инстансы важен (dedicated or shared server or containers) и также важно под каким юзверем запущено приложение. Если приложение крутится под выделенным юзверем то достаточно на файле выставить пермишены и не кто кроме root и этого юзера прочитать файл не смогут (для *nix, с Виндой последние 15 лет не общался так что не знаю как там шас)

я понял теперь про какие инстансы тут говорят Система такая..

Есть ДВА компонента, которые будут иметь доступ к шифрованию/дешифрованию данных из базы данных. Первый модуль - Web Application (hosted in IIS). Запущено под тем юзером, под которым настроен Application Pool instance для этого приложения.

Приложение предоставляет интерфейс для настройки параметров SMTP cерверов (пользователь задает host, port, SMTP username, SMTP password, certificates, и другие параметры и сохраняет это в базе данных).

Второй модуль - Windows service, который собственно занимается отсылкой сообщений на SMTP cервер. Сервис тоже запущен под каким то аккаунтом (по дефолту под Local Account, но можно настроить под любым).

Оба модуля (и Web Application и Windows service) установлены на одном сервере.

В винде есть credentials manager который по идее может сделать похожее на то что я предлагал для *nix. Вроде как можно добавит credentials для системного юзверя и пользоваться ими. Этот вариант рассматривали ?

[shadow7256]

В винде есть credentials manager который по идее может сделать похожее на то что я предлагал для *nix. Вроде как можно добавит credentials для системного юзверя и пользоваться ими. Этот вариант рассматривали ?

Мне вот одно непонятно. Допустим я выставил permissions на этот файл (через windows credentials manager или еще как то) и допустим только юзер Вася Пупкин может этот файл открыть.

А что, если кто то утащит этот файл (тупо скопирует на другую машину), то этот файл будет невозможно открыть ?:)

[deev_a_v]

В винде есть credentials manager который по идее может сделать похожее на то что я предлагал для *nix. Вроде как можно добавит credentials для системного юзверя и пользоваться ими. Этот вариант рассматривали ?

Мне вот одно непонятно. Допустим я выставил permissions на этот файл (через windows credentials manager или еще как то) и допустим только юзер Вася Пупкин может этот файл открыть.

А что, если кто то утащит этот файл (тупо скопирует на другую машину), то этот файл будет невозможно открыть ?:)

Если только Вася Пупкин может открыть этот файл, то и скопировать его на другую машину сможет только он

[dama123]

Не понял. Server authentication - стандартная вещь. Client authentication - вам выдали сертификат, вы его установили, сервер его проверяет. У нас есть такие сервисы. Так что не заработало?

Честно говоря, не помню что там не заработало, но выделенное неверно.
И я, честно говоря, зарёкся объяснять почему.
Просто предлагаю всегда не использовать certificate based client authentication.

mutual TLS в этом и состоит: client authenticates server ( standard for HTTPs), and server authenticates client ( specific for mutual TLS) так что Flash прав. Правда сертификата мало, надо еше иметь private key.

[kostik78]

В винде есть credentials manager который по идее может сделать похожее на то что я предлагал для *nix. Вроде как можно добавит credentials для системного юзверя и пользоваться ими. Этот вариант рассматривали ?

Мне вот одно непонятно. Допустим я выставил permissions на этот файл (через windows credentials manager или еще как то) и допустим только юзер Вася Пупкин может этот файл открыть.

А что, если кто то утащит этот файл (тупо скопирует на другую машину), то этот файл будет невозможно открыть ?:)

В случае credentials manager никакого файла нет. Вы просто ложите туда свой enc/dec key. Доступ к этой записи будет только у админа и у юзверя.

[Palych]

Не понял. Server authentication - стандартная вещь. Client authentication - вам выдали сертификат, вы его установили, сервер его проверяет. У нас есть такие сервисы. Так что не заработало?

Честно говоря, не помню что там не заработало, но выделенное неверно.
И я, честно говоря, зарёкся объяснять почему.
Просто предлагаю всегда не использовать certificate based client authentication.

а почему неверно? Мы лично так наше WEB API защищаем.

API требует наличия client certificate в каждом запросе, считывает сертификат и делает валидацию (много способов, но один из способов тупо проверить стоит ли такой сертификат на машине сервера).

С точки зрения протокола TLS способ валидации один: проверить подписан ли клиентский сертификат у одной из CA в списке.

[dama123]

Не понял. Server authentication - стандартная вещь. Client authentication - вам выдали сертификат, вы его установили, сервер его проверяет. У нас есть такие сервисы. Так что не заработало?

Честно говоря, не помню что там не заработало, но выделенное неверно.
И я, честно говоря, зарёкся объяснять почему.
Просто предлагаю всегда не использовать certificate based client authentication.

а почему неверно? Мы лично так наше WEB API защищаем.

API требует наличия client certificate в каждом запросе, считывает сертификат и делает валидацию (много способов, но один из способов тупо проверить стоит ли такой сертификат на машине сервера).

С точки зрения протокола TLS способ валидации один: проверить подписан ли клиентский сертификат у одной из CA в списке.

Это очевидно не так: mutual TLS supports self-signed certificates
https://tools.ietf.org/html/rfc8705

[Palych]

Не понял. Server authentication - стандартная вещь. Client authentication - вам выдали сертификат, вы его установили, сервер его проверяет. У нас есть такие сервисы. Так что не заработало?

Честно говоря, не помню что там не заработало, но выделенное неверно.
И я, честно говоря, зарёкся объяснять почему.
Просто предлагаю всегда не использовать certificate based client authentication.

а почему неверно? Мы лично так наше WEB API защищаем.

API требует наличия client certificate в каждом запросе, считывает сертификат и делает валидацию (много способов, но один из способов тупо проверить стоит ли такой сертификат на машине сервера).

С точки зрения протокола TLS способ валидации один: проверить подписан ли клиентский сертификат у одной из CA в списке.

Это очевидно не так: mutual TLS supports self-signed certificates
https://tools.ietf.org/html/rfc8705

И что?
Механизм проверки тот же, не важно как сертификат подписан.

[StrangerR]

От кого защищаемся - только от доступа к данным помимо приложения, или от других пользователей внутри приложения?

да они сами толком не знают от кого они защищаются. Поэтому и толком не могут дать конкретные требования.

Пока ясно одно - хотят защититься от всего и забесплатно.

У банков есть жуткий враг - регуляторы. Вот одно из их требований иметь зашифрованные данные в случае data breach. Это если вам в сеть пробрались враги и вытащили данные просто дампом файлов.

Ну это да, но _вытащили файлы_ я такого даже и не слышал. Все вытаскивания _враги впрыснули в приложение SQL команду select * from users; _ ну и приложение счастливи им всю базу и расшифровало, само и добровольно.

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

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

(Интересно, кто нибудь слышал чтобы идиот хакер упер базу в форме дампа файлов? Или еще лучше упер диски со свалки? От всего остального TDE не защищает).

[StrangerR]

В винде есть credentials manager который по идее может сделать похожее на то что я предлагал для *nix. Вроде как можно добавит credentials для системного юзверя и пользоваться ими. Этот вариант рассматривали ?

Мне вот одно непонятно. Допустим я выставил permissions на этот файл (через windows credentials manager или еще как то) и допустим только юзер Вася Пупкин может этот файл открыть.

А что, если кто то утащит этот файл (тупо скопирует на другую машину), то этот файл будет невозможно открыть ?:)

В случае credentials manager никакого файла нет. Вы просто ложите туда свой enc/dec key. Доступ к этой записи будет только у админа и у юзверя.

Аксиома номер 1 - любой юзер может стать рутом или админом, если очень захочет. Поэтому трактовать надо юзеров как рутов. Все эти user level защиты - от случайных ошибок, от целенаправленного взлома защищают почти что никак. Дырочка найдется рано или поздно был бы желающий ее найти.

[kostik78]

В винде есть credentials manager который по идее может сделать похожее на то что я предлагал для *nix. Вроде как можно добавит credentials для системного юзверя и пользоваться ими. Этот вариант рассматривали ?

Мне вот одно непонятно. Допустим я выставил permissions на этот файл (через windows credentials manager или еще как то) и допустим только юзер Вася Пупкин может этот файл открыть.

А что, если кто то утащит этот файл (тупо скопирует на другую машину), то этот файл будет невозможно открыть ?:)

В случае credentials manager никакого файла нет. Вы просто ложите туда свой enc/dec key. Доступ к этой записи будет только у админа и у юзверя.

Аксиома номер 1 - любой юзер может стать рутом или админом, если очень захочет. Поэтому трактовать надо юзеров как рутов. Все эти user level защиты - от случайных ошибок, от целенаправленного взлома защищают почти что никак. Дырочка найдется рано или поздно был бы желающий ее найти.

Любая защита может быть взломана а хардварный ключ утащен

Далее по Вашей аксиоме никто не должен был использовать user level access and privileges. Но используется и много где более того во этот пунктик часто фигурирует в сертификация. P.S. На линухе все системные приложения обычно имеют уникального юзвера для каждого приложения и ничего работает как то десятки лет.

[Palych]

API требует наличия client certificate в каждом запросе, считывает сертификат и делает валидацию (много способов, но один из способов тупо проверить стоит ли такой сертификат на машине сервера).

Предлагаю приложить эту логику к basic authentication:

API требует наличия client user:password в каждом запросе, считывает password и делает валидацию (много способов, но один из способов тупо проверить есть ли такой пароль на машине сервера).

Не видим подвоха?