в С++ сейчас много Чудовищного... но выход есть! все еще можно легко и красиво, когда выбросишь чепуху:
предупреждаю: Ваш взгляд на Мир C++ уже не останется прежним! Дело в том, что я нашел изящное решение Большой Проблемы. Но оно сотрясает Основы... https://ders.by/cpp/norefs/norefs.html
Теперь стало понятнее, что именно вас смущает - вас гложет "проблема нулевого пароля", и вам кажется, что решения нет.
меня не смущает) я ТОЧНО знаю, что решения НЕТ.
это как если вы мне принесете способ точного построения правильного семиугольника с помощью циркуля и линейки - я даже не стану его смотреть.
Допустим вы запускаете ваше приложение в контейнере кубернетес. При запуске внутрь контейнера может быть помещен jwt, с помощью которого можно аутентифицироваться в Сервисе секретов
а почему бы сразу не аутентифицироваться в Сервисе БД? Vault не нужен.
Дополнительно можно настроить, чтобы jwt был выписан на короткий срок, поэтому аутентифицироваться с ним в СервисеСекретов можно только сразу
все то же самое можно сделать и в Сервисе БД. Vault не нужен.
Другой вариант - помещать рядом с приложением wrapped secret для подключения к СервисуСекретов.
...и для подключения к Сервису БД. Vault не нужен.
Из коробки базы данных (в нашем примере) не поддерживают одноразовые пароли
вот, это уже хоть как-то похоже на аргумент. но тут вполне очевидно, что:
нет никаких проблем поддержать эту чепуху сразу в самом Сервисе БД.
если одноразовых паролей нет, то в БД вы заходите с многоразовым и этот пароль может уплыть куда не надо! безопасность не улучшилась ПО СУТИ: ваше слабое звено так и осталось слабым.
Ну и вообще никто не утверждал, что "секрет от сервиса секретов" вообще не существует. Он существует...
мы ходим по кругу!
если он существует, то вам нужен СервисСекретов2.
а если не нужен, то не нужен и СервисСекретов1.
инжектирует секреты из СервисаСекретов прямо в env ПРОЦЕССА с приложением
я надеюсь вы шутите.
секреты в env ПРОЦЕССА - это ДИКАЯ ДИЧЬ!!! никогда так не делайте!
скажу сразу: статья полезная! ее лучше читать, чем не читать :) но вот в деталях...
прежде всего, ОЧЕНЬ много опечаток!! может кто-то считает, что для программиста это нормально, но... 100% такое же будет и в коде ;((
нарушает локальность данных в кэше, первые несколько обращений к данным вектора (обычно 10-15) пока внутренние структуры CPU не адаптируются к новому паттерну, проходят "вхолодную"
это как ТАКОЕ возможно?! что, первые несколько обращений CPU не загружает данные в кэш?!?! жесть.
Однако за убогость и всеядность приходится платить производительностью
Интересный вывод. А можете пояснить, почему "обязательно"? И что вообще в этом плохого?
да, вывод чуть-чуть сотрясает. но на то есть Причины.
а для начала отметим, что ОБЪЕМЫ вашего ответа трясут не меньше :) и это прекрасный образчик security through obscurity!
на всякий случай, сразу уточню: In security engineering, security through obscurity is the practice of concealing the details or mechanisms of a system to enhance its security. This approach relies on the principle of hiding something in plain sight, akin to a magician's sleight of hand or the use of camouflage. It diverges from traditional security methods, such as physical locks, and is more about obscuring information or characteristics to deter potential threats... да-да, я тоже умею бросать простыню ;)
а теперь к Делу.
если у нас есть Клиент, которого не пускают к СерверуБД без пароля, то это значит, что он "обязательно" обязан предъявить пароль! из соображений БЕЗОПАСНОСТИ.
Клиент также должен где-то пароль хранить, но не в конфигурационном файле! из соображений БЕЗОПАСНОСТИ.
что предлагают продавцы СервисаСекретов? они ему предлагают хранить пароль в СервисеСекретов. но очень не любят сказать, а где же несчастному Клиенту хранить пароль для самого СервисаСекретов ;)
ведь если в СервисСекретов безопасно ходить без пароля, то точно так же безопасно ходить без пароля сразу же в СерверБД.
а если к СервисуСекретов нужен пароль, то Клиенту необходим СервисСекретов2 для паролей СервисаСекретов. а еще потом СервисСекретов3 для паролей СервисаСекретов2... тут только успевай платить ;))
надеюсь теперь понятно, почему клиенты СервисаСекретов платят за кашу из топора. понятно клиентам, естественно.
ЗЫ а дополнительные фишки аудита и ротации - это уже потом. когда закрыта ГЛАВНАЯ ПРОБЛЕМА безопасности! а она у вас не закрыта.
Уже больше двух лет мы развиваем Deckhouse Stronghold — решение для безопасного управления жизненным циклом секретов
ну анекдот же, ребята!
Дано: "Для безопасного управления жизненным циклом секретов", вы храните секреты для приложений в СервисеСекретов. Вопрос: А где вы храните секреты для самого СервисаСекретов?
не трудитесь с ответом ;) если вам обязательно нужен СервисСекретов для приложений, то вам обязательно нужен СервисСекретов2 для СервисаСекретов1...
Действительно, когда у вас есть контейнеры или функции их легко почти мгновенно масштабировать и нет большой разницы, на какой именно машине это делать.
спасибо, повеселили!
для начала, встряхнем Основы:
“Вы не влипнете в недостаток ресурсов“ -- блестящая фраза! Деньги тоже ресурс, и вы обязательно влипнете.
Почему? Они все время "забывают" вам сказать, какой сервер стоит масштабировать... И какой точно нет!
Ага, значит гуглим какой сервер масштабировать и... Вот поэтому была написана эта статья.
упрощая детали, шифрование - это использование алгоритма. и только у НЕКОТОРЫХ алгоритмов есть ЕЩЕ ключ! в этом случае (неявно) предполагается, что алгоритм уже известен аналитику и осталось "только" угадать ключ.
так вот.
в случае тысячи школьников алгоритм уже НЕ известен! т.к. изменение любого бита зашифрованного блока сразу же портит весь блок. и все, что идет за ним.
вы не будете бегать за тысячей школьников => зашифрованный текст перестал АВТОМАТИЧЕСКИ взламываться...
Пусть расцветают сто цветов: Пришел конец былой работе криптоаналитиков! Ни больше ни меньше.
"Никогда не пишите свою собственную криптографию" -- говорили они. Но сейчас любой школьник с удовольствием перетасует байты зашифрованного файла -- и вот вам "новый алгоритм"!
Помните, что абсолютно все современные операционные системы, доступные обывателю, являются шпионами. Их главная обязанность -- фильтровать доступную информацию и автоматически отправлять кому следует.
Сервис секретов предназначен для хранения настроек к вашим приложениям
Дано. Для "повышения безопасности", вы храните в СервисеСекретов "настройки" для приложений. Вопрос: Где вы храните "настройки" для самого СервисаСекретов?
Дано. Для "повышения безопасности", вы храните в ПровайдереСекретов Секреты для доступа к Серверам. Вопрос: Где вы храните Секреты для доступа к самому ПровайдеруСекретов?
как видно из текста статьи:
секрет в конфиге для доступа к PostgreSQL - аяяй плохо!
но секрет в конфиге для доступа к Vault - вах хорошо!
Указание полей секции [goconfig.vault] и [goconfig.vault.auth] это только один из способов сконфигурировать и авторизовать vault клиент.
я открою вам Страшную Тайну: безопасно хранить пароли для доступа к Vault1 можно только в Vault2. а к нему тоже надо пароли...
а что если зашифровать pdf файл при помощи программы Adobe (естественно на Windows)
а что, если не маяться дурью и сразу зашифровать свой файл надежной программой? яко же все официально одобренные государством шифровальщики имеют дупло. любым государством.
и как я уже много раз говорил, не стесняйтесь после шифрования пройтись по результату своей собственной наивной программой (те самые 200 каких-либо бит в начале файла). вы тем самым поможете Злым человекам стать немного Добрее ;))
Получил ключ от дяди? Инвертируй в нем половину каких-либо бит. Потом используй.
Зашифровал файл? Инвертируй 200 каких-либо бит в начале. Потом высылай.
ЗЫ "вы не будете бегать за тысячей школьников" https://habr.com/ru/companies/selectel/articles/909792/comments/#comment_28335438
Итак: фундаментально новый алгоритм сортировки DerSort https://ders.by/alg/dersort/dersort.html
о! актуальная тема)
я скоро выложу новый алгоритм сортировки. Фундаментально новый.
НЕ ИСПОЛЬЗУЙТЕ ССЫЛКИ и вы избежите почти всех проблем! (ц)
в С++ сейчас много Чудовищного... но выход есть!
все еще можно легко и красиво, когда выбросишь чепуху:
меня не смущает) я ТОЧНО знаю, что решения НЕТ.
это как если вы мне принесете способ точного построения правильного семиугольника с помощью циркуля и линейки - я даже не стану его смотреть.
а почему бы сразу не аутентифицироваться в Сервисе БД? Vault не нужен.
все то же самое можно сделать и в Сервисе БД. Vault не нужен.
...и для подключения к Сервису БД. Vault не нужен.
вот, это уже хоть как-то похоже на аргумент.
но тут вполне очевидно, что:
нет никаких проблем поддержать эту чепуху сразу в самом Сервисе БД.
если одноразовых паролей нет, то в БД вы заходите с многоразовым и этот пароль может уплыть куда не надо! безопасность не улучшилась ПО СУТИ: ваше слабое звено так и осталось слабым.
мы ходим по кругу!
если он существует, то вам нужен СервисСекретов2.
а если не нужен, то не нужен и СервисСекретов1.
я надеюсь вы шутите.
секреты в env ПРОЦЕССА - это ДИКАЯ ДИЧЬ!!! никогда так не делайте!
скажу сразу: статья полезная! ее лучше читать, чем не читать :) но вот в деталях...
прежде всего, ОЧЕНЬ много опечаток!! может кто-то считает, что для программиста это нормально, но... 100% такое же будет и в коде ;((
это как ТАКОЕ возможно?!
что, первые несколько обращений CPU не загружает данные в кэш?!?! жесть.
вот тут не поспоришь!
на коленке сделанная int_map сразу работает в несколько раз быстрее std::unordered_map<int, int>. это конечно позор.
https://www.linkedin.com/pulse/do-you-still-trust-stl-sergey-derevyago-bzenf
а знали не только лишь все: https://ders.by/cpp/norefs/norefs.html#4.1
ай, ну кто так ругает? детский сад.
да, вывод чуть-чуть сотрясает. но на то есть Причины.
а для начала отметим, что ОБЪЕМЫ вашего ответа трясут не меньше :) и это прекрасный образчик security through obscurity!
на всякий случай, сразу уточню: In security engineering, security through obscurity is the practice of concealing the details or mechanisms of a system to enhance its security. This approach relies on the principle of hiding something in plain sight, akin to a magician's sleight of hand or the use of camouflage. It diverges from traditional security methods, such as physical locks, and is more about obscuring information or characteristics to deter potential threats... да-да, я тоже умею бросать простыню ;)
а теперь к Делу.
если у нас есть Клиент, которого не пускают к СерверуБД без пароля, то это значит, что он "обязательно" обязан предъявить пароль! из соображений БЕЗОПАСНОСТИ.
Клиент также должен где-то пароль хранить, но не в конфигурационном файле! из соображений БЕЗОПАСНОСТИ.
что предлагают продавцы СервисаСекретов?
они ему предлагают хранить пароль в СервисеСекретов. но очень не любят сказать, а где же несчастному Клиенту хранить пароль для самого СервисаСекретов ;)
ведь если в СервисСекретов безопасно ходить без пароля, то точно так же безопасно ходить без пароля сразу же в СерверБД.
а если к СервисуСекретов нужен пароль, то Клиенту необходим СервисСекретов2 для паролей СервисаСекретов. а еще потом СервисСекретов3 для паролей СервисаСекретов2... тут только успевай платить ;))
надеюсь теперь понятно, почему клиенты СервисаСекретов платят за кашу из топора. понятно клиентам, естественно.
ЗЫ а дополнительные фишки аудита и ротации - это уже потом. когда закрыта ГЛАВНАЯ ПРОБЛЕМА безопасности! а она у вас не закрыта.
ну анекдот же, ребята!
Дано: "Для безопасного управления жизненным циклом секретов", вы храните секреты для приложений в СервисеСекретов.
Вопрос: А где вы храните секреты для самого СервисаСекретов?
не трудитесь с ответом ;) если вам обязательно нужен СервисСекретов для приложений, то вам обязательно нужен СервисСекретов2 для СервисаСекретов1...
клиенты ваши платят за кашу из топора.
Уже множество лет программировать лезут животные. С появлением ChatGPT, программировать лезут растения.
к сожалению, вы и близко не представляете НАСКОЛЬКО все плохо!
"80% more" - вдумайтесь!!
спасибо, повеселили!
для начала, встряхнем Основы:
и немного добавим про Функции:
без понимания Сути, вы бесконечно кормите всю эту саранчу...
вы не поняли сути.
упрощая детали, шифрование - это использование алгоритма. и только у НЕКОТОРЫХ алгоритмов есть ЕЩЕ ключ! в этом случае (неявно) предполагается, что алгоритм уже известен аналитику и осталось "только" угадать ключ.
так вот.
в случае тысячи школьников алгоритм уже НЕ известен! т.к. изменение любого бита зашифрованного блока сразу же портит весь блок. и все, что идет за ним.
вы не будете бегать за тысячей школьников => зашифрованный текст перестал АВТОМАТИЧЕСКИ взламываться...
https://ders.by/crypt/derscrypt2/derscrypt2.html
https://ders.by/crypt/derscrypt2/derscrypt2.html
Богатыми становятся только те, "кто надо" (кто по крови принадлежит к Хозяевам Жизни)
а если кто-то не тот вдруг получил много денег - это деньги ничейные. и первый "кто надо" их заберет.
и снова каша из топора...
Дано. Для "повышения безопасности", вы храните в СервисеСекретов "настройки" для приложений.
Вопрос: Где вы храните "настройки" для самого СервисаСекретов?
заходи и бери, что хочешь??
о! любимая тема не тонет)
как видно из текста статьи:
секрет в конфиге для доступа к PostgreSQL - аяяй плохо!
но секрет в конфиге для доступа к Vault - вах хорошо!
я открою вам Страшную Тайну:
безопасно хранить пароли для доступа к Vault1 можно только в Vault2. а к нему тоже надо пароли...
а что, если не маяться дурью и сразу зашифровать свой файл надежной программой? яко же все официально одобренные государством шифровальщики имеют дупло. любым государством.
и как я уже много раз говорил, не стесняйтесь после шифрования пройтись по результату своей собственной наивной программой (те самые 200 каких-либо бит в начале файла). вы тем самым поможете Злым человекам стать немного Добрее ;))