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

[Palych]

3. Конкретно: поскольку сертификат не привязан к пользователю - невозможно узнать кто вошёл, что ему можно делать, и что он сделал.

в нашем случае у кастомера несколько сотен клиентских станций, которые будут обращаться к API. Если какая то станция в HTTP запросе прикрепит сертификат, которого нет на стороне сервера, то сервер даст тут же отлуп. Запишет в лог, с какого IP пришел запрос и отлупит.

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

В а чем отличие передачи правильного сертификата от передачи username + password? Юзернеймы и пароли где то хранятся (в базе например).. ну а сертификат хранится в Certificate store. И все таки сертификат подделать явно сложнее чем юзернейм и пароль.. нет?

Допустим вы отключили одного из клиентов.
Он одолжил сертификат у другого клиента, поставил его себе, и продолжает работать.
Как вы отловите сей неприятный факт?
Допустим вы это обнаружили. Начальство требует почистить транзакции совершенные нарушителем...
Ваши действия?

А вообще - этот метод вполне годный, главное понимать его ограничения.

[kostik78]

3. Конкретно: поскольку сертификат не привязан к пользователю - невозможно узнать кто вошёл, что ему можно делать, и что он сделал.

в нашем случае у кастомера несколько сотен клиентских станций, которые будут обращаться к API. Если какая то станция в HTTP запросе прикрепит сертификат, которого нет на стороне сервера, то сервер даст тут же отлуп. Запишет в лог, с какого IP пришел запрос и отлупит.

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

В а чем отличие передачи правильного сертификата от передачи username + password? Юзернеймы и пароли где то хранятся (в базе например).. ну а сертификат хранится в Certificate store. И все таки сертификат подделать явно сложнее чем юзернейм и пароль.. нет?

Допустим вы отключили одного из клиентов.
Он одолжил сертификат у другого клиента, поставил его себе, и продолжает работать.
Как вы отловите сей неприятный факт?
Допустим вы это обнаружили. Начальство требует почистить транзакции совершенные нарушителем...
Ваши действия?

А вообще - этот метод вполне годный, главное понимать его ограничения.

Если сертификат именной то проблем нету. В этом случае сервер не только проверяет валидность сертификата но вытаскивает кому принадлежит и далее таже схема что и традиционными username + password. Только стадия проверки пасворда сведена к проверки валидности и то что сертификат не отозван
Практически весь DRM сделан на такой схеме с именными сертификатами и ничего работает. Все взломы DRM происходят уже после получения ключиков декриптования контента.

Опять же я говорю про mutual SSL когда оба: клиент и сервер проверяют сертификаты друг дружки. Уточняю на всякий случай а то тут в топике уже разные схемы мелькали

[Palych]

Если сертификат именной то проблем нету. В этом случае сервер не только проверяет валидность сертификата но вытаскивает кому принадлежит и далее таже схема что и традиционными username + password.

Вот об этом я и говорю. Я никогда не видел чтобы выделенное делалось.
Возможно я ломлюсь в открытую дверь, и мой опыт не типичный. Тогда извиняюсь что намутил воду.

[kostik78]

Если сертификат именной то проблем нету. В этом случае сервер не только проверяет валидность сертификата но вытаскивает кому принадлежит и далее таже схема что и традиционными username + password.

Вот об этом я и говорю. Я никогда не видел чтобы выделенное делалось.
Возможно я ломлюсь в открытую дверь, и мой опыт не типичный. Тогда извиняюсь что намутил воду.

Ну я это вижу повсеместно и применяеться это обычно в случаях когда тебуеться passwordless именная auth при этом ещё хочется чтобы MitM не возник.

Вы говорите скорее всего про server to server mutual SSL. Там любят прикрутить self-sign один на всех что есть глупо. По нормальному даже если делать selfsign то с CA и intermediates с разными subj по которым можно определять уровни доступа кому куда можно, чтобы не получилась так - сперли сертификат с одного микросервиса а получили доступ ко всей платформе

[shadow7256]

Допустим вы отключили одного из клиентов.

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

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

Как вы отловите сей неприятный факт?

бывают случаи, когда какая то станция вдруг начинает присылать данные которые не соответствуют тому формату, который ожидает API, но это не из за того, что кто то пытается взломать что то, а просто из за misconfiguration и сам же заказчик это быстро обнаруживает и просит нас посмотреть логи, потому что его станция не получает ответ от нашей API. мы быстро посмотрим и объясним заказчику "почему Володька сбрил усы".

Допустим вы это обнаружили. Начальство требует почистить транзакции совершенные нарушителем...
Ваши действия?

весь софт, и клиентские станции и серверная часть находятся полностью на серверах заказчика. Если они напортачили чего то, то звонят в наш customer support и они им помогут.

А вообще - этот метод вполне годный, главное понимать его ограничения.

ограничения мы понимаем, главное чтобы это понимал заказчик

[dama123]

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

Я правильно понимаю, что mutual SSL connection на основе сертификата _не_ устанавливается? Если это так, то использование сертификата в данном случае - security theater и ничем не лучше пароля. Безопасность основанная на том, что кто-то не знает "кучу других деталей" вызывает улыбку.

[StrangerR]

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

Я правильно понимаю, что mutual SSL connection на основе сертификата _не_ устанавливается? Если это так, то использование сертификата в данном случае - security theater и ничем не лучше пароля. Безопасность основанная на том, что кто-то не знает "кучу других деталей" вызывает улыбку.

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

[Palych]

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

Я правильно понимаю, что mutual SSL connection на основе сертификата _не_ устанавливается? Если это так, то использование сертификата в данном случае - security theater и ничем не лучше пароля. Безопасность основанная на том, что кто-то не знает "кучу других деталей" вызывает улыбку.

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

Одно дело когда эти детали придумал разработчик Вася, использовать сборник анекдотов в качестве ключа.
Другое дело - когда детали в том что стандартные инструменты используются неправильно.
И особенно - когда это распространённая практика.

[StrangerR]

Соглашусь но в другой формулировке - проблема возникает когда неплохой в целом замок ставят грубо говоря внутренней стороной наружу, и считают что защитились, при том что удивленный вор увидав такое - быстренько его открутит и влезет. Так и с софтом. Беда даже не в том что неправильно а в том что при этом думаюти что _правильно_

[Palych]

Справедливости ради стоит отметить что есть пожалуй один пример когда такой подход оправдан:
Если у сервиса ровно один клиент по дизайну.
И такая ситуация вполне распространёна.
P.S. при условии что будут использоваться только self signed certificates.

[deev_a_v]

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

Я правильно понимаю, что mutual SSL connection на основе сертификата _не_ устанавливается? Если это так, то использование сертификата в данном случае - security theater и ничем не лучше пароля. Безопасность основанная на том, что кто-то не знает "кучу других деталей" вызывает улыбку.

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

Security by obscurity
https://en.wikipedia.org/wiki/Security_ ... #Criticism

[StrangerR]

Оная СБО уменьшает нагрузку на объекты интереса в сотни если не тысячи раз. Но конечно, вражий шпиен прорвется. Если такой шпиен найдется.

[shadow7256]

С Client certificate разобрались наконец.

Объяснили им про mutual SSL и про то, где сертификаты будут и как они проверятся будут и что в любой момент они могут revoke Client certificate (они сами будут делать сертификаты, у них своя PKI), выпустить новый сертификат и прочее прочее.. Они довольны наконец.

Теперь насчет data encryption, они согласны, что надо использовать AES-256. Ключ вроде хотят хранить в файле на диске, но просят показать механизм защиты этого ключа.. а именно "we need to have Encryption key compromise plan to be in place as a part of mitigation strategy". Что они имеют в виду? Если ключ сопрут, то что им делать в этом случае? Или как лучше всего защитить файл с ключом?

[Flash-04]

Уже говорили, HSM иметь.
А если его нет, то хранить его зашифрованным и вводить пароль вначале (как для зашифрованным сертификатов делается), а пароль в конвертике в сейф.

Вообще говоря, если это банк, то стыдно не иметь HSM в наши дни.
С ними вообще просто: смарт карта с мастер ключом иницилизируется в двух экземплярах и кладётся в сейф.
Все остальные ключи генерятся на его основе и HSM их распределяет. Мастер ключ никогда ни при каких обстоятельствах HSM не покидает.

В последнем сезоне Mr Robot посмотрите, там наглядно показано как такая железка работает. Прям как в жизни.

[shadow7256]

Уже говорили, HSM иметь.
А если его нет, то хранить его зашифрованным и вводить пароль вначале (как для зашифрованным сертификатов делается), а пароль в конвертике в сейф.

Чтобы система работала с HSM нужно чтобы этот HSM все время был воткнут в сервер, на котором наше приложение крутится. Приложение шифрует данные редко (при записи в базу данных), но дешфирует очень часто - каждый раз когда нужно извлечь зашифрованную запись из базы данных данных. То есть постоянно нужен доступ к ключу шифрования.

Какой пароль вводить? Модуль который дешифрует данные в нашем случае выполнен как Windows service, он крутится себе без всякого User Interface. Дергает данные из базы данных, дешифрует и пользует. Куда пароль здесь вводить?

Вообще говоря, если это банк, то стыдно не иметь HSM в наши дни.

этот банк уже все мозги проел. Вообще это забота security отдела, чтобы к какому то серверу (на котором наше приложение крутится) не было простого доступа.

[Flash-04]

Пароль вводится один раз при старте приложения. Потом ключ кешируется и держится в памяти. У вас же не одноразовый пароль.
Понятно что настройка системы неспроста и HSM стоит $$$.
Для него ещё и специально обученный человек нужен.

[Flash-04]

По поводу сервисов. Мне надо вас учить как делать GUI приложение которое с сервисом общается?

[shadow7256]

Понятно что настройка системы неспроста и HSM стоит $$$.
Для него ещё и специально обученный человек нужен.

для этого вонючего банка все, что касается траты денег на какой то проект то это сразу "не подходит". Они говорили что то про HSM, но почему то отказались от этой идеи. Наверное по той же причине почему отказались от Always encrypted в базе данных.. от CyberArk.. ну и теперь от HSM. Они хотят чтобы все для них сделали бесплатно без всяких трат с их стороны. А.. и еще чтобы их клоуны не обучались чему то новому.

[Flash-04]

Ничего, регуляторы очень быстро и эффективно мотивируют на материальные траты. Штрафы на сотни миллионов тянут если что не так.

[shadow7256]

Ничего, регуляторы очень быстро и эффективно мотивируют на материальные траты. Штрафы на сотни миллионов тянут если что не так.

Ну так пусть тогда регуляторы и скажут, что конкретно они хотят. А то вот какая интересная вещь получается. Этот барклай так сильно переживает, что вдруг кто то получит доступ к его серверам, так может быть стоит сосредоточится на том, чтобы этот "кто то" не получил такой доступ. Более того, у них стоит SMTP сервер, который наше приложение использует для отправки emails в разные агенства (то есть наше приложение не отправляет письма напрямую на почтовые сервера агенств, а использует SMTP сервер, который стоит у барклая). Так вот оказалось, что этот ихний SMTP сервер не имеет НИКАКОЙ авторизации. То есть наше приложение подключается к нему без всякого юзернейма и пароля. Это барклай так настроил, не мы так сделали. Так вопрос.. какого хера вы трахаете мозги каким то шифрованием, если шифровать то нечего.

Зато ихние дебилы индусы обезьяны присылают умные письма и просят объяснить в деталях, что мы собираемся делать в случае если data is compromised.

Тут не мы должны делать, а вы должны делать. Нахер тогда такие security нужны в компании.

[kostik78]

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

[Flash-04]

Мдас... Тяжело вам. Но я предлагаю не суетиться и расслабиться. Как только случится breach (это только вопрос времени) сразу найдутся люди и деньги.

[shadow7256]

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

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

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

[shadow7256]

Мдас... Тяжело вам. Но я предлагаю не суетиться и расслабиться. Как только случится breach (это только вопрос времени) сразу найдутся люди и деньги.

у них уже был breach.. погуглите насчет Barclay's bank.

[Flash-04]

Тогда ждите следующего.