Благодарю, я правильно понимаю, что стремиться нужно к тому, чтобы вообще обходиться без регулярного VACUUM FULL?
C pg_repack знаком, по нему есть вопрос — могут ли быть подводные камни при работе с 1с? Смутил вот такой ответ на форуме 1с:
pg_repack не входит в состав расширений, публикуемых нами в сборке postgres.
postgres не тестируется с pg_repack у нас, не обеспечивается или конктролируется его совместимость.
Другими словами, мы не учитываем особенности pg_repack в разработке.
В списке наших планов есть вопрос рассмотрения поддержки pg_repack или каких-то аналогов, но до этой задачи пока не добрались.
Использовать pg_repack можно только на свое усмотрение, осознавая риск, что это может привести к проблемам, которые не будут воспроизводиться без использования pg_repack. У нас рекомендации использовать pg_repack нет.
Не понятно, что там может быть особенного, но ответ сотрудника насторожил.
Спасибо за отличный доклад и расшифровку.
Вопрос такой — есть ли общие рекомендации по проведению регламентов, в частности для OLTP и VACUUM FULL ANALYZE? Слышал мнение, что достаточно частый VACUUM FULL может иметь больше негативных последствий, чем пользы. Допустим, есть регламентное окно ночью, когда в базу не ходят клиенты и за это время успевает проходить VACUUM FULL. Есть смысл гонять каждую ночь, при прочих равных?
Да я верю, что используют, ну ССЗБ. К слову о стойкости пароля локального админа, вот ли не пофигу какой пароль, если можно загрузиться с флешки или по РХЕ со своего ноута, при залитых эпоксидкой ЮСБ и ПСИ разъемах, обкусанных штырьках на материнке и установить любой пароль? К чему возня с радужными таблицами? В остальном, повторюсь, статья годная, но много допущений, когда адммин малоопытный и меняет даже дефолтные настройки, снижая безопасность.
Имея физический доступ к машине, при отсутствии шифрования, получить локального админа труда не составляет. Ну и как бы всё. Кто в здравом уме использует пароль локального админа рабочих станций на серверах?
В остальном статья хорошая, есть интересные фичи.
Некрокомментарий 2. Яндекс для Организаций сильно изговнякался. Теперь оно само себя обновляет через службу и таск менеджер, как делает Хром. И самое противное, что на сайте для развертывания лежит всегда устаревшая версия. Фу таким быть. Через ВСУС уже не зарулить.
Зачем менять пароль от учетки службы если оно надо 3 раза в жизни: (1)сохранить уникальный в менеджере паролей, (2)ввести при установке и (3)повторить?
Меня поражает эта ерунда со сменой паролей ради смены паролей.
Чет вы вообще всё в кучу собрали. При чем тут тонкие клиенты, VLAN и http? В статье конкретно показаны узкие места обеспечения безопасности при развертывании 1с с СП хоть в домене, хоть без. Статья правильная, дает абсолютный минимум за исключением того, что забыли админа центрального сервера.
В общем и целом, я бы сказал, что 1с тут не при чем, любой СП может подвергнуться таким болячкам, но вот именно потому, что 1с как СП там распространен, болезнь может быть страшнее.
Вы во многом правы, да и собственно в статье прописные истины озвучены. Но хотелось бы уточнить пару моментов.
Если у логина SQL, который использует сервер предприятия только public и db_owner, то сервер не сможет видеть и убивать соединения. Как правильно сказали выше — приходится давать processadmin
Это начиная с какой версии 1с/MSSQL?
«запросто выгрузит базу в .DT», ага, незаметно выгонит пользователей, незаметно остановит работу на несколько часов
Вечером задержался и выгрузил. Не вижу противоречий.
А в целом статься грамотна и верна. Дает базовый уровень защиты при использовании 1с и MSSQL. Не хватает, как минимум постгри, но хоть так.
Байпас изучил. А что мешает выполнить код злостному юзеру из temp без всякой фигни? Смит не знает про командную строку? Тем более, regsvr прокси не обойдет. Чет сложно у вас.
Не берусь говорить за VBA32, не знаю что он из себя представляет, но тот же каспер стал комбайном, в нем тебе и управление доступом к устройствам и проверка на уязвимости и деплой апдейтов на ОС и софт, и админка, и отчеты и, фактически, инвентаризация. Хорошо это или плохо — каждый решит сам, но я считаю, что лично мне стало удобнее. Это комплекс по обеспечению мер безопасности, хоть и использую далеко не все.
Сейчас уже миф. Шлейф, который за ним тянется из 2000х.
И ещё раз повторю, я за 4-5 лет всего 2-3 раз попадал в ситуацию, что запустил какой-то файл, и он нагадил
Вы выше написали, что у вас целый комплекс мер, когда сдуру что-то запускаете.
Уж не обижайтесь, но с высокой вероятностью, вы — бот. Не тот, который в комментариях поддержку/хейт пишет, а тот, который этериум майнит.
Все верно, но речь о том, чтобы сначала выполнить этот код. Если вы посмотрите выше по ветке комментариев, то поймете, что речь о уязвимости в продукте/системе не идет.
Точно так же можно словить VBS в «плохом» .xls, который наделает делов.
C pg_repack знаком, по нему есть вопрос — могут ли быть подводные камни при работе с 1с? Смутил вот такой ответ на форуме 1с:
Не понятно, что там может быть особенного, но ответ сотрудника насторожил.
По п.5 изучаю The Internals of PostgreSQL
Вопрос такой — есть ли общие рекомендации по проведению регламентов, в частности для OLTP и VACUUM FULL ANALYZE? Слышал мнение, что достаточно частый VACUUM FULL может иметь больше негативных последствий, чем пользы. Допустим, есть регламентное окно ночью, когда в базу не ходят клиенты и за это время успевает проходить VACUUM FULL. Есть смысл гонять каждую ночь, при прочих равных?
В остальном статья хорошая, есть интересные фичи.
Меня поражает эта ерунда со сменой паролей ради смены паролей.
В общем и целом, я бы сказал, что 1с тут не при чем, любой СП может подвергнуться таким болячкам, но вот именно потому, что 1с как СП там распространен, болезнь может быть страшнее.
Это начиная с какой версии 1с/MSSQL?
Вечером задержался и выгрузил. Не вижу противоречий.
А в целом статься грамотна и верна. Дает базовый уровень защиты при использовании 1с и MSSQL. Не хватает, как минимум постгри, но хоть так.
Да.
Любой юзер по дефолту имеет права на запись в %windir%/temp
геморазащиты — нелишний. Спасибо. Чересчур сложной защиты (для защитника) не бывает, если понимаешь как её обойти.По поводу наколенных приблуд см пункт 2) по ссылке из комментария.
ss -nlpt|grep 443
ss -nlpt|grep apache2
Откуда вы знаете?
Сейчас уже миф. Шлейф, который за ним тянется из 2000х.
Вы выше написали, что у вас целый комплекс мер, когда сдуру что-то запускаете.
Уж не обижайтесь, но с высокой вероятностью, вы — бот. Не тот, который в комментариях поддержку/хейт пишет, а тот, который этериум майнит.
Точно так же можно словить VBS в «плохом» .xls, который наделает делов.