Ну как бы "разблокировка емкости батареи" примерно из этой же серии действий? Не на всех моделях и прошивках... :-) Т.е. для jailbreak законодатели (разных стран) хотят "узаконить" права пользователя на любые действия пользователя с приобретенным физическим устройством и считать это вполне законным действием (вопреки тому что там производитель в собственных лицензионных требованиях написал). Иначе не понятно, почему "разбить" приобретенное устройство/машину пользователем считается законным, а "разблокировать" незаконно и преследуется "по закону"? :-)
Я как бы и пытаюсь объяснять, что TDE проблемы защиты утечки базы "чистых данных" глобально не решает, тогда казалось бы "зачем упираться и тратить ресурсы на реализацию + производительность" (если что с TDE, что без него "защита идет уже внешними организационно-техническими средствами, с помощью аудита и т.п. "). Поскольку "внешние средства защиты" и без TDE работают "как с TDE", и использование шифрованной FS (с правильной раздачей прав в OS) "по факту" дает ровно такую же "защиту" как и TDE (без "гемороя" с собственным изобретением велосипеда). :-) Видимо лавры изобретателей собственного велосипеда кому то "щекочут самолюбие" и приносят неплохой доход.... :-)
Я и не сомневаюсь что все архитектурные и технологические выборы сбера проходили "архитектурные и экспертные советы во всех подразделениях", но есть факты того что сбер каждые 5-7 лет "меняет направление развития своих технологических платформ". Я понимаю что часть данных изменений реально связаны с изменением внешних технологических условий, но так же и вижу что основная их часть это просто бездумное и не обоснованное ничем (исключая реальную материальную выгоду отдельных персон) "следование за новыми и модными течениями в IT", и не более. :-) Про +5% - вполне возможно, но вот вопрос, что взамен получили? И "стоит ли полученное" этих процентов? Или у вас есть возражения что TDE (в вашей реализации) не защищает чистые данные базы (и ключи криптации) от OS пользователей с правами root и "владельца базы"? Тогда готов выслушать возражения вас или ваших экспертов... :-)
Не является, но "прикручивали" типа "вместо" ... InMemory это и https://www.tadviser.ru/index.php/Продукт:GridGain_In-Memory_Data_Fabric и Apache Ignite Я и говорю "идей много"... :-) Пилят и "на крипте", и на "биг дата", и на "микросервисах", не говорю уже наверно о давно забытой IBM MQ...
PCI DSS - 1. Сейчас как бы "не в моде" 2. Меняется/развивается регулярно 3. Довольствуется "компенсационными мерами" 4. TDE конечно "принимает", но "требует шифрования на уровне приложения" - что дико влияет на производительность БД.
1) Описываемая вами реализация TDE по затратам/трудоемкости (и багам реализации) не сравнима с "допиливанием" шифрованной FS для взаимодействия с HSM для шифрованных файлов или файловых систем. 2) Сетевой обмен и его защита - "отдельная песня" и готовых "не самопальных" решений в данной области хватает (у вас же не только репликация по сети идет но и прикладной обмен с БД). 3) Чем же плох backup/реплика БД на шифрованной FS? 4) Какая бы система хранения ключей у вас не использовалась, ключи для дешифровки TDE/репликации/backup root извлечет из памяти сервера. Ну а после этими же ключами дешифрует данные, так от кого тогда TDE? Только от админа БД. :-) Который впрочем dump памяти "своих" процессов скорее всего сделать сможет (вместе с "чистыми данными в пользовательских процессах БД" и "чистыми ключами") что так же ему даст доступ к TDE данным. В сбере уже столько этих "центров экспертиз и разработок" было и будет, а "где карту получали - туда и идите!" не истребимо... Разработчикам может и не плохо "деньги мыть" при таком подходе нанимателя (оплата работы "для интереса"), но "оплачивают то банкет" клиенты самого банка...
Чем "изобретать свой велосипед" с TDE (наверно для кого то круто и доходно это делать) можно просто использовать шифрованную фс практически с тем же эффектом но без лишних затрат(максимум монтирование с получением ключей из HSM)? Хранить любые ключи в самописных софтовых хранилищах примерно из этой же серии, хотя HSM это делают надежнее (надеюсь что это не требует аргументов и доказательств).
Я в этих "баталиях" не понимаю главного.... 1) У клиента/человека есть договор с банком на финансовое обслуживание. 2) У клиента есть договор с сотовым оператором на обслуживание и сервисы связи. Какое отношение между собой имеют данные договора и по какому праву или необходимости банк в своем договоре с клиентом принудительно "связывает" свой договор с договором клиента на обслуживание у оператора сотовой связи (номером сотового телефона)? Ведь каждый договор предусматривает (ну или должен по логике предусматривать) только отношения между клиентом и той организацией что оказывает услуги? Причем тут финансовые сервисы и номер сотового телефона? Почему имея N договоров с сотовыми операторами и X договоров с банками на текущий момент я обязан банкам сообщать свой сотовый номер? В законодательстве для банков прописаны обязательные документы для идентификации клиента, и как бы номера сотового я там не видел... Плохие банки без наличия сотового вообще не идентифицируют клиента. Если клиента сотового оператора не устраивают его условия он же может разорвать договор с ним и остаться в принципе совсем без номера сотового телефона или заключить договор с другим сотовым оператором (причем с тем с которым "не работает" банк, к примеру оператором другой страны с которым невозможна процедура сохранения сотового номера). Так на какой же правовой основе банки сейчас в обязательном порядке требуют наличия у клиента номера сотового телефона?
1) Поле/поля (а впрочем и таблицы приложения) при смене версии могут быть не только добавлены или изменены, но и удалены... Т.е. "по логике" именно "новая версия" приложения просто должна "знать и уметь" работать с несколькими "версиями/структурами" БД (особенно в распределенных БД). Начиная с того что в определенный момент времени БД находится в "промежуточном" состоянии (часть структур "новая", а часть "старая"), а приложение работать должно безотказно. 2) Вариант "отката без простоя" должен быть предусмотрен "по определению" (углубляться в эту тему наверно не стоит)...
:-) Осталось "так же легко" решить еще несколько "проблем" обновления... 1) Штатный откат на "старую установленную версию" (app и db) без downtime 2) Установка обновления (app и db) не с предыдущей версии, а с какой-то более старой (2-3 версии "назад")
Ответ OK послать недостаточно... :-) Он может и не дойти...
Нужно в следующем "обмене" получать результат предыдущего... :-)
Все что нужно знать о машинном обучении и результатах его работы, вы можете оценить по текущим прогнозам погоды... :-)
Ну как бы "разблокировка емкости батареи" примерно из этой же серии действий? Не на всех моделях и прошивках... :-)
Т.е. для jailbreak законодатели (разных стран) хотят "узаконить" права пользователя на любые действия пользователя с приобретенным физическим устройством и считать это вполне законным действием (вопреки тому что там производитель в собственных лицензионных требованиях написал). Иначе не понятно, почему "разбить" приобретенное устройство/машину пользователем считается законным, а "разблокировать" незаконно и преследуется "по закону"? :-)
Про Apple и Jailbreak упоминать не стоит? :-)
Я как бы и пытаюсь объяснять, что TDE проблемы защиты утечки базы "чистых данных" глобально не решает, тогда казалось бы "зачем упираться и тратить ресурсы на реализацию + производительность" (если что с TDE, что без него "защита идет уже внешними организационно-техническими средствами, с помощью аудита и т.п. "). Поскольку "внешние средства защиты" и без TDE работают "как с TDE", и использование шифрованной FS (с правильной раздачей прав в OS) "по факту" дает ровно такую же "защиту" как и TDE (без "гемороя" с собственным изобретением велосипеда). :-)
Видимо лавры изобретателей собственного велосипеда кому то "щекочут самолюбие" и приносят неплохой доход.... :-)
Я и не сомневаюсь что все архитектурные и технологические выборы сбера проходили "архитектурные и экспертные советы во всех подразделениях", но есть факты того что сбер каждые 5-7 лет "меняет направление развития своих технологических платформ". Я понимаю что часть данных изменений реально связаны с изменением внешних технологических условий, но так же и вижу что основная их часть это просто бездумное и не обоснованное ничем (исключая реальную материальную выгоду отдельных персон) "следование за новыми и модными течениями в IT", и не более. :-)
Про +5% - вполне возможно, но вот вопрос, что взамен получили? И "стоит ли полученное" этих процентов? Или у вас есть возражения что TDE (в вашей реализации) не защищает чистые данные базы (и ключи криптации) от OS пользователей с правами root и "владельца базы"? Тогда готов выслушать возражения вас или ваших экспертов... :-)
Не является, но "прикручивали" типа "вместо" ...
InMemory это и https://www.tadviser.ru/index.php/Продукт:GridGain_In-Memory_Data_Fabric и Apache Ignite
Я и говорю "идей много"... :-)
Пилят и "на крипте", и на "биг дата", и на "микросервисах", не говорю уже наверно о давно забытой IBM MQ...
Про Tarantool и InMemory забыли?
PCI DSS -
1. Сейчас как бы "не в моде"
2. Меняется/развивается регулярно
3. Довольствуется "компенсационными мерами"
4. TDE конечно "принимает", но "требует шифрования на уровне приложения" - что дико влияет на производительность БД.
Про обоснованность есть хороший анекдот, заканчивающийся словами - "Жаль, а у меня было еще столько идей!"
1) Описываемая вами реализация TDE по затратам/трудоемкости (и багам реализации) не сравнима с "допиливанием" шифрованной FS для взаимодействия с HSM для шифрованных файлов или файловых систем.
2) Сетевой обмен и его защита - "отдельная песня" и готовых "не самопальных" решений в данной области хватает (у вас же не только репликация по сети идет но и прикладной обмен с БД).
3) Чем же плох backup/реплика БД на шифрованной FS?
4) Какая бы система хранения ключей у вас не использовалась, ключи для дешифровки TDE/репликации/backup root извлечет из памяти сервера. Ну а после этими же ключами дешифрует данные, так от кого тогда TDE? Только от админа БД. :-) Который впрочем dump памяти "своих" процессов скорее всего сделать сможет (вместе с "чистыми данными в пользовательских процессах БД" и "чистыми ключами") что так же ему даст доступ к TDE данным.
В сбере уже столько этих "центров экспертиз и разработок" было и будет, а "где карту получали - туда и идите!" не истребимо... Разработчикам может и не плохо "деньги мыть" при таком подходе нанимателя (оплата работы "для интереса"), но "оплачивают то банкет" клиенты самого банка...
А можете "открыть секрет" сколько "целевых реляционных СУБД" сменилось в банке с 2000 года? :-)
Чем "изобретать свой велосипед" с TDE (наверно для кого то круто и доходно это делать) можно просто использовать шифрованную фс практически с тем же эффектом но без лишних затрат(максимум монтирование с получением ключей из HSM)? Хранить любые ключи в самописных софтовых хранилищах примерно из этой же серии, хотя HSM это делают надежнее (надеюсь что это не требует аргументов и доказательств).
TDE не запрещает root "сдампись"/прочитать память процесса OS где все прочитанные данные уже расшифрованы....
Я в этих "баталиях" не понимаю главного....
1) У клиента/человека есть договор с банком на финансовое обслуживание.
2) У клиента есть договор с сотовым оператором на обслуживание и сервисы связи.
Какое отношение между собой имеют данные договора и по какому праву или необходимости банк в своем договоре с клиентом принудительно "связывает" свой договор с договором клиента на обслуживание у оператора сотовой связи (номером сотового телефона)?
Ведь каждый договор предусматривает (ну или должен по логике предусматривать) только отношения между клиентом и той организацией что оказывает услуги?
Причем тут финансовые сервисы и номер сотового телефона? Почему имея N договоров с сотовыми операторами и X договоров с банками на текущий момент я обязан банкам сообщать свой сотовый номер? В законодательстве для банков прописаны обязательные документы для идентификации клиента, и как бы номера сотового я там не видел...
Плохие банки без наличия сотового вообще не идентифицируют клиента.
Если клиента сотового оператора не устраивают его условия он же может разорвать договор с ним и остаться в принципе совсем без номера сотового телефона или заключить договор с другим сотовым оператором (причем с тем с которым "не работает" банк, к примеру оператором другой страны с которым невозможна процедура сохранения сотового номера). Так на какой же правовой основе банки сейчас в обязательном порядке требуют наличия у клиента номера сотового телефона?
1) Поле/поля (а впрочем и таблицы приложения) при смене версии могут быть не только добавлены или изменены, но и удалены... Т.е. "по логике" именно "новая версия" приложения просто должна "знать и уметь" работать с несколькими "версиями/структурами" БД (особенно в распределенных БД). Начиная с того что в определенный момент времени БД находится в "промежуточном" состоянии (часть структур "новая", а часть "старая"), а приложение работать должно безотказно.
2) Вариант "отката без простоя" должен быть предусмотрен "по определению" (углубляться в эту тему наверно не стоит)...
:-) Осталось "так же легко" решить еще несколько "проблем" обновления...
1) Штатный откат на "старую установленную версию" (app и db) без downtime
2) Установка обновления (app и db) не с предыдущей версии, а с какой-то более старой (2-3 версии "назад")