IT в России и мире в реалиях мирового кризиса

Цитата: Oleg K. от 05.01.2023 08:02:02Для таких случаев вы всегда можете создать свои типы данных и реализовать операции над ними. В том числе и на C с использованием данных возможностей процессора.

Ну так я могу и делить на архитектуре, не поддерживающей деление, приходилось. Речь не об этом – речь об аппаратных возможностях и их использовании. Я помню те времена, когда компилятор имел три типа библиотек – использующую аппаратные возможности x87, эмулятор x87 и просто библиотеку подпрограмм, реализующую необходимую функциональность. "то были C иFortran для DOS и OS/2. И скажу я вам, что производительность первой и второй различались не в разы и даже не в сотни раз – в тысячи, а некоторые алгоритмы линейной алгебры выполнялись еще дольше.

Цитата: Oleg K. от 05.01.2023 08:02:02В криптографических операциях на сервере (на оборудовании, к которому отсуствует физический доступ у злоумышленника) использование аппаратных команд процессора вместо подпрограмм не несет никакой дополнительной защиты.

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

Цитата: adolfus от 05.01.2023 10:18:55Ну так я могу и делить на архитектуре, не поддерживающей деление, приходилось. Речь не об этом – речь об аппаратных возможностях и их использовании. Я помню те времена, когда компилятор имел три типа библиотек – использующую аппаратные возможности x87, эмулятор x87 и просто библиотеку подпрограмм, реализующую необходимую функциональность. "то были C иFortran для DOS и OS/2. И скажу я вам, что производительность первой и второй различались не в разы и даже не в сотни раз – в тысячи, а некоторые алгоритмы линейной алгебры выполнялись еще дольше.

Или я плохо описал, или вы неправильно поняли. Вы можете написать какой угодно программный код на C (хоть с аппаратными криптографическими ключами работайте, хоть с генератором случайных чисел, хоть с чем) и подключить его для использования внутри базы данных PostgreSQL. Данная база данных реализована с максимально доступными для расширения встроенными механизмами.

Цитата: adolfus от 05.01.2023 10:18:55Аппаратура генерирует и хранит ваш приватный ключ, плюс сеансовые ключи и вынуть их оттуда невозможно. Они там рождаются и там же остаются. Доступ есть только к публичному ключу. Плюс аппаратная реализация алгоритмов. Что касается "отсутствия физического доступа", то организовать это запредельно дорого.
Реальным хранилищем секретов сегодня является человек или камень. Чтобы добыть секрет в первом случае, достаточно получить к человеку доступ.  Во втором случае вы бессильны.

По-моему, вы несколько далеки от действительных проектов по защите информации. Данный комментарий не вяжется с реальными сценариями атак и прорабатываемыми методами защиты данных. EEPROM из камня тоже можно выпаять и прочитать - это даже иногда проще, чем "человека расколоть". Ну и в целом не понятно, при чем тут лицензия/исхдники и ваш текст выше...
Как бы то ни было, по теме работы с базой данных PostgreSQL я вроде достаточно написал (и по нашим компаниям, её дорабатывающим и использующим тоже).
Могу только добавить в части личных впечатлений. Одного из основателей PostgresPro - Олега Бартунова - часто вижу на конференциях (ещё с тех времен, когда PostgreSQL не был так широко распространен и держался по сути на голом энтузиазме) и могу рекомендовать как высококлассного специалиста, открытого для сотрудничества. Тот факт, что у него получилось с соратниками создать работающую структуру и, надеюсь, получится полностью вписать её в коммерческий рынок баз данных, иначе, как чудом назвать сложно. Например, в 2018 году (год примерно - пишу по памяти) попытки сформулировать и хоть как-то продвинуть в узком кругу формат финансирования работ по разработке и развитию баз данных упирался в глухую стену непонимания. Надеюсь, что теперь взлетит по-настоящему. Нужно ещё лет 5 поработать с этим и посмотреть - там уже станет понятна траектория.

Цитата: Oleg K. от 04.01.2023 02:37:49У PostgreSQL лицензия BSD - у сделанных на его основе программ исходники публиковать не обязательно.

Авторы PostgreSQL молодцы, выбрали правильную лицензию. Которую могут использовать все - любой бизнес, хоть малый, хоть средний, хоть корпорации.
Публикующие исходники под лицензией GNU GPL 3 - игграют на руку корпорациям. Их исходники по факту не может использовать малый или средний бизнес. Корпорации же при необходимости могут банально переписать код - деньги и ресурсы у них есть. Тое сть они на словах борясь за свободу кода, на практике поддерживают корпорации.и монополизацию.

Цитата: Podli от 02.01.2023 15:13:20Пользуем базёнки MySQL на 10+ терабайт данных и 10 000+ запросов в секунду. Работают, ломаются только вместе с железом, поднимаются после смерти хоста через ...дцать минут на реплике. Чего такого волшебного нам какой-нить другой скуль могёт предложить?

   
Детсадовские масштабы.
Тут можно было на Бейсике налабать самоделку, чтобы таблички обрабатывать...

   
Да, и как там с кластеризацией и прочей транзакционностью?

Цитата: adolfus от 05.01.2023 10:18:55Аппаратура генерирует и хранит ваш приватный ключ, плюс сеансовые ключи и вынуть их оттуда невозможно. Они там рождаются и там же остаются. Доступ есть только к публичному ключу. Плюс аппаратная реализация алгоритмов.

Я не понимаю, вам нужна промышленного уровня СУБД, или мега-секретное хранилище. Если второе - то милости просим SQL СУБД Линтер Бастион. Сертификат МО РФ прилагается.

ЦитатаФедеральный орган по сертификации средств защиты информации принял решение о продлении действия сертификата соответствия №1489 Министерства обороны на систему управления базами данных ЛИНТЕР БАСТИОН до 2 октября 2024 года.

Цитата: basilevs от 06.01.2023 10:48:53Я не понимаю, вам нужна промышленного уровня СУБД, или мега-секретное хранилище. Если второе - то милости просим SQL СУБД Линтер Бастион. Сертификат МО РФ прилагается.

ЦитатаФедеральный орган по сертификации средств защиты информации принял решение о продлении действия сертификата соответствия №1489 Министерства обороны на систему управления базами данных ЛИНТЕР БАСТИОН до 2 октября 2024 года.

Там проблема глубже. Даже безотносительно конкретной идеи БД.
Базы данных должны быть как-то совместимы. Но именно это упирается в стену безопасности информации.
Просто для примера. Телефонный справочник. В полку несекретный, В дивизии, армии ДСП, в округе секретный, выше СС. По требованиям ФСБ и МО недопустимо объединять в единую систему сегменты  разным уровнем безопасности. Единый телефонный справочник невозможен.
Есть ещё фишка. Удалённое хранение в зашифрованном виде. Вы можете сделать распределённую БД, но извольте в зашифрованном виде. Казалось бы нет проблем. Но они есть.
Первая проблема- регулярная смена ключевых документов, и, как следствие, перешифрование как самих удалённых кусков БД, так и удалённо хранящихся бэкапов.
Вторая проблема - компрометация ключевых документов. При компрометации ключа всё, что зашифровано этим ключом должно быть уничтожено как недоверенное.
Линтер сам по себе ничего не решает.

Цитата: ivan2 от 06.01.2023 12:51:23Там проблема глубже.

Протоколы безопасности рассчитаны на "бумажные" технологии и не учитывают современные средства.

Цитата: gvf от 06.01.2023 13:02:31Протоколы безопасности рассчитаны на "бумажные" технологии и не учитывают современные средства.

РД АС, РД СВТ. Временные требования ФСБ к АС и их составным частям, но они секретные ("Временные", это такой закидон, позволяющий в любое время их ужесточить). Какие ещё бумажные технологии и протоколы? Там про то, что разработчик должен обеспечить. Как, да без разницы. Надо уничтожать диски, да хоть стреляйте в них, хоть в кислоте растворяйте.

Цитата: ivan2 от 06.01.2023 13:09:20. По требованиям ФСБ и МО недопустимо объединять в единую систему сегменты  разным уровнем безопасности

зачем?
кто сказал что они должны быть шифрованы одни и тем же шифром и иметь те же параметры доступа несмотря на совместное хранение в одной логической базе?

Цитата: ivan2 от 06.01.2023 13:09:20Надо уничтожать диски, да хоть стреляйте в них, хоть в кислоте растворяйте.

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

Цитата: gvf от 06.01.2023 13:57:12зачем?
кто сказал что они должны быть шифрованы одни и тем же шифром и иметь те же параметры доступа несмотря на совместное хранение в одной логической базе?

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

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

Цитата: ivan2 от 06.01.2023 14:06:17Не надо наивной чукоткости.
Должна быть разработана модель нарушителя. Нельзя объединять системы с разными моделями нарушителей.
Должны быть модели защиты,...Нельзя объединять системы с разными...
Нет никаких "систем шифрования и правил обращения которые должны парировать риски.".

IT-шники часто заблуждаются считая, что информационная безопасность это информатика.

Цитата: ivan2 от 06.01.2023 12:51:23Есть ещё фишка. Удалённое хранение в зашифрованном виде. Вы можете сделать распределённую БД, но извольте в зашифрованном виде. Казалось бы нет проблем. Но они есть.
Первая проблема- регулярная смена ключевых документов, и, как следствие, перешифрование как самих удалённых кусков БД, так и удалённо хранящихся бэкапов.

А в чем такая уж проблема? Делайте бэкап с другим ключом, чисто для бэкапов.
Для параноиков - с двумя половинками ключа у разных людей, каждый из которых смотрит чтоб второй именно бэкапом занимался, а не рылся в базе на предмет интересного.

ЦитатаПри компрометации ключа всё, что зашифровано этим ключом должно быть уничтожено как недоверенное.

С какой стати? Вы так можете получить результат, что у противника ваша информация есть, а у вас самого - нет.

Цитата: Luddit от 06.01.2023 23:43:39А в чем такая уж проблема? Делайте бэкап с другим ключом, чисто для бэкапов.
Для параноиков - с двумя половинками ключа у разных людей, каждый из которых смотрит чтоб второй именно бэкапом занимался, а не рылся в базе на предмет интересного.

И как это решает проблему перешифрования по календарю, или уничтожения при компрометации?

Цитата: Luddit от 06.01.2023 23:43:39Цитата

ЦитатаПри компрометации ключа всё, что зашифровано этим ключом должно быть уничтожено как недоверенное.

С какой стати? Вы так можете получить результат, что у противника ваша информация есть, а у вас самого - нет.

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

Цитата: ivan2 от 06.01.2023 23:49:19И как это решает проблему перешифрования по календарю, или уничтожения при компрометации?

1 - вы восстанавливаете базу с бэкапным ключом и тут же зашифровываете её тем ключом, который нужен.
2 - если на момент бэкапа ключ не был скомпрометирован, то информация в бэкапе никакому чужому воздействию не подвергалась. Собственно это как раз то, для чего бэкап может пригодиться. Если же был, то возвращаемся к вопросу что там за информация. Возвращаясь к примеру с телефонным справочником - вам сильно поможет его уничтожение?

Цитата: Luddit от 06.01.2023 23:56:121 - вы восстанавливаете базу с бэкапным ключом и тут же зашифровываете её тем ключом, который нужен.
2 - если на момент бэкапа ключ не был скомпрометирован, то информация в бэкапе никакому чужому воздействию не подвергалась. Собственно это как раз то, для чего бэкап может пригодиться. Если же был, то возвращаемся к вопросу что там за информация. Возвращаясь к примеру с телефонным справочником - вам сильно поможет его уничтожение?

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

Цитата: Luddit от 06.01.2023 23:59:48Мне доводилось оппонировать разработчикам требований. И пусть со скрипом, но возвращать их на грешную землю в некоторых аспектах.

Можно в некоторых случаях достичь компромисса.
ФСО в обход ЗАС сдаёт телефонные каналы буквально с уличных телефонных автоматов в нужных случаях.
Но что позволено Юпитеру, непозволено коню.

Цитата: ivan2 от 07.01.2023 00:02:02Как Вы быстро думаете. Я даже удивляюсь.
Ну ка удалённо перешифруйте бекап... Слабо?
Не включайте дурака. Вам надо назад закачать бэкап, расшифровать, зашифровать и обратно вперёд закачать.

Накуя вам удалённо перешифровывать бэкап, если его ключ в порядке?
Если же не в порядке именно его ключ, то сделайте новый бэкап с новым ключом.
Если же вы проипли оба ключа, то вы редкостный долбоёпп.

Цитата: Luddit от 06.01.2023 23:59:48Мне доводилось оппонировать разработчикам требований. И пусть со скрипом, но возвращать их на грешную землю в некоторых аспектах.

Я понимаю, что предписание на эксплуатацию секретное.
Но вот поклянитесь, что честно выполнили все требования. а не сблюднули, ка это обычно делается.

Цитата: Luddit от 07.01.2023 00:11:35Накуя вам удалённо перешифровывать бэкап, если его ключ в порядке?
Если же не в порядке именно его ключ, то сделайте новый бэкап с новым ключом.
Если же вы проипли оба ключа, то вы редкостный долбоёпп.

Вы не понимаете.
Запрещено проверять удалённо. Т.е. не запрещено, но тогда это должен быть Ваш домен безопасности, тот админ безопасности должен подчинятся Вашему админу, а зарплату тому директору должен платить Ваш директор. Понимаете?