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

[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 и делает валидацию (много способов, но один из способов тупо проверить есть ли такой пароль на машине сервера).

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

[kostik78]

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

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

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

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

Данный способ вполне можно использовать с SSL mutual authorization. Последнее обычно используется для предотвращения Man-in-the-middle attack и это всё-таки работает на уровне транспорта. Так что одно не заменяет другое а вполне дополняет.

[dama123]

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

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

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

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

Можно не говорить загадками? Решение с сертификатом - не очень, ничем не лучше чем basic authentication. В mutual TLS, кроме сертификата проверяется наличие private key, который соответствует public key из сертификата.

[Palych]

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

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

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

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

Можно не говорить загадками? Если передавать сертификат по открытому каналу, то решение не очень, ничем не лучше чем basic authentication. В mutual TLS, кроме сертификата проверяется наличие private key, который соответствует public key из сертификата.

Первый подвох в том, что сертификаты (и пароли в данном примере) не привязаны к пользователю. Например, если у кого-то сертификат протух - от может одолжить/украсть сертификат другого пользователя, и провайдера этого не заметит.
Фундаментальный подвох в том что результатом аутентификации является true/false, есть доступ или нет.
А должно быть - аутентичное имя пользователя, в данном случае подтвержденное сертификатом и подписавшим его CA.
Особенно коварно получается когда начальство решает что self signed certificates - не серьёзно для солидной системы, и добавляет какой-нибудь публичный CA. Тогда доступ открывается полностью.

[kostik78]

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

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

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

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

Можно не говорить загадками? Решение с сертификатом - не очень, ничем не лучше чем basic authentication. В mutual TLS, кроме сертификата проверяется наличие private key, который соответствует public key из сертификата.

Извините конечно но в чем по Вашему заключается проверка сертификата ? Просто Вы утверждаете про private key и public key и что они как то отдельно от сертификата и это выглядит сильно странно.

[Flash-04]

А кто-то предлагает без пароля? Это как бы разные уровни проверки авторизации пользователя. Вначале покажи аусвайс, потом ещё и пароль. Каждый этап затрудняет вражеский доступ.
Оффтоп: вот что меня реально напрягает, так повсемесиный переход с Hardware RSA токен на софтовый. Копируй сколько хочешь.