Если вы разработчик или манагер разрабов вы должны уязвимости отслеживать и устранять, как свои так и привнесенные с зависимостями. Если вы управляете процессами в компании этот софт использующей то вам нет смысла заниматься устранением уязвимостей - не ваша зона ответственности, вы должны строить процессы из предположения что весь ваш софт уязвим и ваша задача построить эксплуатацию так чтобы минимизировать ущерб. Определяете риски - потери данных, утечки данных, отказ сервисов и т.д. и придумываете способы минимизации ущерба... Ну и естественно, оцениваете затраты на минимизацию в сравнении с возможным ущербом.
Ваше руководство лопухнулось и речь придется вести с позиции руководителя, а не инженера. Не будем сейчас тут развивать про РБАК, оно и так понятно... но если у конторы нет денег на РБАК то будет как будет. Руководство назначило на должность не просто девопса или сисадмина, а фактически ему были делегированы полномочия кусочка CIO и CSO. И это ключевое!
Увольнение таких людей не готовится как "сменили пароли". Увольнение начинается с найма человека который медленно и печально входит в курс всех вопросов и перехватывает все задачи. Это дешевле выйдет чем случайные бекапы искать.
Были ли у вашего С. причины так поступить или просто человечек с червоточинкой здесь неважно, в данном случае это чистой воды просчет руководства конторы, а не результат недостатка бюджета.
Уже написаны 1100500 тысяч скриптов, переделывать их на токены это бессмысленные затраты времени т.к. ничего принципиально не изменится. Ключ не надо копировать, т.к. работа идет не просто так, а в уже готовом окружении. Там где такого окружения нет можно и используется авторизация по токену. Второе отличие - ssh это прежде всего пайпы, длительные сессии. Https это в основном запрос-ответ, поддержание сессий типа вебсокет это немного из другой оперы. По итогу ssh оказывается значительно менее ресурсоемким если мы выходим за пределы простого git clone\push\pull для всяческих комбайнов типа gitlab\github\jenkins
Есть вариант генерации сертификата и установки его в браузере с последующей аутентификацией и авторизацией по этому сертификату. Разница в ssh vs https в том, что ssh дает вариант удобной работы из консоли. https и его стандартные методы (как сертификат так и токены) не предполагает вариантов работы с консолью без серьезных костылей. Для чего надо работать из консоли? Гораздо больше вариантов автоматизации без особых затрат
Мне думается вы тут смешали две проблемы. 1. Практика разработки софта в конкретной конторое - 1с и что из этого вышло. 2. Архитектурное решение для бухгалтерской и ЕРП задач, реализованное 1с и последующее создание из него экониши. У меня есть серьезные претензии по 1му пункту. Криворукость там подтверждается массовыми утечками от самих разрабов и их начальников. Есть претензии и по 2му пункту, в части правильности избранной стратегии, но они скорее от послезнания чем результат который можно было получить тогда. В те годя я бы пошел тем же путем. Сейчас, с опытом, понимаю принципы заложенные и в САП в том числе.
Но это больше критиканство будет. Так что с точки зрения бизнеса в 1с-корпорации все сделано верно. Той же дорогой идет Сбер и не только он. Но будучи банком попадает под массу регуляторных ограничений и потому там это не развивается в жесткую херню но потуги были и есть.
В общем все зависит от того в какой роли вам приходится это все исполнять. Если вы просто исполнитель то вам всучили в зубы эту бумажку и пойдете вы ее реализовывать как есть, пофиг на ошибки. Если вы системный аналитик вы выкините нафиг эту фитюльку и для начала пойдете разбираться с бизнес-процессами клиента, после чего собрав полноценные требования, включая бизнес-требования (которые и дадут ответ на вопрос с часовыми поясами - а важны ли они вообще), вы начнете проектирование этого всего с нуля, и в зависимости от собранных требований вы реализуете проект таким образом, что и ЭЦП давшего разрешение будет, и ФИО агента будет выбрано из списка, и очередь проверки валидности сделок там возникнет так что отпадет потребность считать сколько и какие разрешения и кем выданы, отпадет. Если вы начальник всего этого балагана то вы задумаетесь о том кто и зачем это все наваял и что с ним делать. Если вы новый сотрудник фирмы то вы начнете с изучения того что контора уже делала по таким поводам чтобы быть в контексте и не лепить излишние сущности которые удорожают проект.
А форма... ну что форма... форма как форма.... точнее рыба.
producer\consumer мне как аналитику глубоко параллельно как называется объект который генерит события которые попадают в очередь и как называется объект который эти события из очереди выхватывает и обрабатывает. Сами эти термины ничего не дают и легко усваиваются при наличии понимания соответствующих сущностей аналитиком. Главное понимать для чего вообще существует такой логический элемент как очередь и в каких ситуациях ее надо лепить - мы покупаем минимизацию потери входящих сообщений и высокую вероятность того что они все будут обработаны за счет ресурсов, прежде всего оперативной памяти, а лепить ее надо в том случае если на входе мы имеем непостоянный но с хорошими пиками вход событий, которые нам надо обработать не потеряв, и не имея запаса мощности обработчиков хотя бы на порядок выше предполагаемого пика. Какой именно брокер - кафка или кролик поставить, решает в основном архитектор... ну либо если архитектора нет, то аналитик с разработчиками совместно решат
Прежде всего это попытка завернуть на себя рекламный трафик, пролоббированная яндексом и газпром(рутьюб).
Естественное желание получить бабла прикрывается благородными целями защитить неокрепшие детские умы от вражеской пропаганды секса и насилия. Хотя и эта цель тоже прослеживается, но на мой взгляд, составляет не более 20% от общего мотива.
Хотели бы от сечь от чего бы то ни было, отсекли бы, это вам здесь, на Хабре, любой админ подтвердит. У меня есть как минимум 3 варианты решения этой задачи "без рекламы и смс". И это будут решения без возможности обхода всякими ВПН и прочими анти-дпи.
Если вы разработчик или манагер разрабов вы должны уязвимости отслеживать и устранять, как свои так и привнесенные с зависимостями.
Если вы управляете процессами в компании этот софт использующей то вам нет смысла заниматься устранением уязвимостей - не ваша зона ответственности, вы должны строить процессы из предположения что весь ваш софт уязвим и ваша задача построить эксплуатацию так чтобы минимизировать ущерб. Определяете риски - потери данных, утечки данных, отказ сервисов и т.д. и придумываете способы минимизации ущерба...
Ну и естественно, оцениваете затраты на минимизацию в сравнении с возможным ущербом.
Ваше руководство лопухнулось и речь придется вести с позиции руководителя, а не инженера.
Не будем сейчас тут развивать про РБАК, оно и так понятно... но если у конторы нет денег на РБАК то будет как будет.
Руководство назначило на должность не просто девопса или сисадмина, а фактически ему были делегированы полномочия кусочка CIO и CSO. И это ключевое!
Увольнение таких людей не готовится как "сменили пароли". Увольнение начинается с найма человека который медленно и печально входит в курс всех вопросов и перехватывает все задачи. Это дешевле выйдет чем случайные бекапы искать.
Были ли у вашего С. причины так поступить или просто человечек с червоточинкой здесь неважно, в данном случае это чистой воды просчет руководства конторы, а не результат недостатка бюджета.
Уже написаны 1100500 тысяч скриптов, переделывать их на токены это бессмысленные затраты времени т.к. ничего принципиально не изменится.
Ключ не надо копировать, т.к. работа идет не просто так, а в уже готовом окружении.
Там где такого окружения нет можно и используется авторизация по токену.
Второе отличие - ssh это прежде всего пайпы, длительные сессии.
Https это в основном запрос-ответ, поддержание сессий типа вебсокет это немного из другой оперы.
По итогу ssh оказывается значительно менее ресурсоемким если мы выходим за пределы простого git clone\push\pull для всяческих комбайнов типа gitlab\github\jenkins
Есть вариант генерации сертификата и установки его в браузере с последующей аутентификацией и авторизацией по этому сертификату.
Разница в ssh vs https в том, что ssh дает вариант удобной работы из консоли. https и его стандартные методы (как сертификат так и токены) не предполагает вариантов работы с консолью без серьезных костылей.
Для чего надо работать из консоли? Гораздо больше вариантов автоматизации без особых затрат
Мне думается вы тут смешали две проблемы.
1. Практика разработки софта в конкретной конторое - 1с и что из этого вышло.
2. Архитектурное решение для бухгалтерской и ЕРП задач, реализованное 1с и последующее создание из него экониши.
У меня есть серьезные претензии по 1му пункту. Криворукость там подтверждается массовыми утечками от самих разрабов и их начальников.
Есть претензии и по 2му пункту, в части правильности избранной стратегии, но они скорее от послезнания чем результат который можно было получить тогда. В те годя я бы пошел тем же путем. Сейчас, с опытом, понимаю принципы заложенные и в САП в том числе.
Но это больше критиканство будет. Так что с точки зрения бизнеса в 1с-корпорации все сделано верно. Той же дорогой идет Сбер и не только он. Но будучи банком попадает под массу регуляторных ограничений и потому там это не развивается в жесткую херню но потуги были и есть.
В общем все зависит от того в какой роли вам приходится это все исполнять.
Если вы просто исполнитель то вам всучили в зубы эту бумажку и пойдете вы ее реализовывать как есть, пофиг на ошибки.
Если вы системный аналитик вы выкините нафиг эту фитюльку и для начала пойдете разбираться с бизнес-процессами клиента, после чего собрав полноценные требования, включая бизнес-требования (которые и дадут ответ на вопрос с часовыми поясами - а важны ли они вообще), вы начнете проектирование этого всего с нуля, и в зависимости от собранных требований вы реализуете проект таким образом, что и ЭЦП давшего разрешение будет, и ФИО агента будет выбрано из списка, и очередь проверки валидности сделок там возникнет так что отпадет потребность считать сколько и какие разрешения и кем выданы, отпадет.
Если вы начальник всего этого балагана то вы задумаетесь о том кто и зачем это все наваял и что с ним делать.
Если вы новый сотрудник фирмы то вы начнете с изучения того что контора уже делала по таким поводам чтобы быть в контексте и не лепить излишние сущности которые удорожают проект.
А форма... ну что форма... форма как форма.... точнее рыба.
producer\consumer
мне как аналитику глубоко параллельно как называется объект который генерит события которые попадают в очередь и как называется объект который эти события из очереди выхватывает и обрабатывает. Сами эти термины ничего не дают и легко усваиваются при наличии понимания соответствующих сущностей аналитиком. Главное понимать для чего вообще существует такой логический элемент как очередь и в каких ситуациях ее надо лепить - мы покупаем минимизацию потери входящих сообщений и высокую вероятность того что они все будут обработаны за счет ресурсов, прежде всего оперативной памяти, а лепить ее надо в том случае если на входе мы имеем непостоянный но с хорошими пиками вход событий, которые нам надо обработать не потеряв, и не имея запаса мощности обработчиков хотя бы на порядок выше предполагаемого пика. Какой именно брокер - кафка или кролик поставить, решает в основном архитектор... ну либо если архитектора нет, то аналитик с разработчиками совместно решат
Навелосипедили...
Возьмите скрипт бекапа от самого Хетцнера.
В качестве контроля бекапа проверяйте его этим же скриптом с командой list, она покажет дату и размер последнего бекапа.
Ну и тестовые раскрутки бекапа надо делать таки регулярно.
По поводу отпечатков ключей ... ничего не понял, у меня нет подобных проблем
Сделанное по этим докам проблем не имеет
https://community.hetzner.com/tutorials/install-and-configure-borgbackup
https://docs.hetzner.com/storage/storage-box/access/access-ssh-rsync-borg
Прежде всего это попытка завернуть на себя рекламный трафик, пролоббированная яндексом и газпром(рутьюб).
Естественное желание получить бабла прикрывается благородными целями защитить неокрепшие детские умы от вражеской пропаганды секса и насилия. Хотя и эта цель тоже прослеживается, но на мой взгляд, составляет не более 20% от общего мотива.
Хотели бы от сечь от чего бы то ни было, отсекли бы, это вам здесь, на Хабре, любой админ подтвердит. У меня есть как минимум 3 варианты решения этой задачи "без рекламы и смс". И это будут решения без возможности обхода всякими ВПН и прочими анти-дпи.
Просить что-то в данном контексте неверно. Для начала надо поинтересоваться, а каких именно положительных результатов вы добились блокировкой.
С точки зрения Гугла им глубоко пофиг на блокировку, потому что основной рекламный трафик это США, даже не Европа.
Автоматизируйте тесты - запрашивайте таблицу свотх анонсов у аплинка и сверяйте с оргиналом, если есть расхождения бейте в колокол.