Уже голову сломал как это реализовать. Задача по команде ( например из планировщика) отправлять некий файл/архив(1-2гб) в облако(yandex disk/ google disk итп) при этом, постоянного доступа к этому облаку пк не должен иметь. Поясню если сервер подхватит шифровальщика и будет установлено ПО для синхронизации от яндекса( и др.), то файл в облаке просинхронизируется зашифрованной копией.
По теме из базы знаний
- Рекомендации по организации резервного копирования для систем с Windows Server / Windows SQL Server
- Конфигурация для создания резервных копий баз на сервере 1С: предприятие (SQL)
- Бесплатный митап “1С в облаке: возможности и риски, решения и кейсы”
- Готовое облако или выделенный сервер? Экономика владения 1С
- Как перенести 1С в облако без простоя: пошаговая инструкция
Ответы
Подписаться на ответы
Инфостарт бот
Сортировка:
Древо развёрнутое
Свернуть все
(2) AlexInqMetal,
Пока лучшее что сумел найти это создать батник:
Соединяемся
Переходим в нужную папку
копируем файл "
Переходим на свой диск
Отключаемся
Но хотелось бы нормальное ПО с мониторингом. Оповещением если копия не была скопирована
Пока лучшее что сумел найти это создать батник:
Соединяемся
net use Y: \\webdav.yandex.ru@SSL\backup /USER:Логин парольПереходим в нужную папку
cd /d y:\backupкопируем файл
copy "C:\yadisk\1234.7zПереходим на свой диск
c:Отключаемся
net use /delete Y:Но хотелось бы нормальное ПО с мониторингом. Оповещением если копия не была скопирована
(1) corbenSG,
Из собственного опыта: Пользую дроп диск. Из полезных опций у него есть поддержка версии файла. Допустим произошел прицидент и архивы зашифровались в служебной папке. Заходим в личный кабинет на сайт дропбокс, и восстанавливаем первую копию файла.
Считаю достаточно написать батник, копирования в служебную папку. А защита от шифрования уже встроена в сервис.
Поясню если сервер подхватит шифровальщика и будет установлено ПО для синхронизации от яндекса( и др.), то файл в облаке просинхронизируется зашифрованной копией.
Из собственного опыта: Пользую дроп диск. Из полезных опций у него есть поддержка версии файла. Допустим произошел прицидент и архивы зашифровались в служебной папке. Заходим в личный кабинет на сайт дропбокс, и восстанавливаем первую копию файла.
Считаю достаточно написать батник, копирования в служебную папку. А защита от шифрования уже встроена в сервис.
Я пользуюсь Дроп-диском. Он распознается на компе как локальный, хотя сам находится в облаке. Никакого логина-пароля не надо для доступа (весь контроль в софтине, которую надо установить при создании Дроп-диска). Делать архивы можно очень простым бат-файлом и планировщиком
Как вариант создать отдельного пользователя на компе специально для архивации, права на папку Яндекс диска дать только этому пользователю.
В программе архиваторе (бесплатный Кобиан например умеет) в задании указать, что исполнять архивацию в папку под этим пользователем...
В общем сделать так, чтоб у вируса прав не хватило записать в эту папку.
В программе архиваторе (бесплатный Кобиан например умеет) в задании указать, что исполнять архивацию в папку под этим пользователем...
В общем сделать так, чтоб у вируса прав не хватило записать в эту папку.
(10) Diego_Iv, Проблема способа в том что, как я понимаю, файл в облаке будет подменятся. И толк от запрета шифровать что то в папке Яндекс диска на компе нет, кобиан сам подхватит уже зашифрованый вирусом файл и подменит им нормальный файл в облаке.
Тут я вижу недостаток информации при постановке задачи. Что за файл, в какой момент времени он подвержен атаке, какова частота желаемой отправки в облако?
И если уж сильно заморочиться, то файлик держать на виртуальной машине, которую бекапить в облако снапшотами, и в случае проблем с файлом откатиться до нужного момента. Не самый верный вариант но при недостатке вводных самый универсальный.
Тут я вижу недостаток информации при постановке задачи. Что за файл, в какой момент времени он подвержен атаке, какова частота желаемой отправки в облако?
И если уж сильно заморочиться, то файлик держать на виртуальной машине, которую бекапить в облако снапшотами, и в случае проблем с файлом откатиться до нужного момента. Не самый верный вариант но при недостатке вводных самый универсальный.
крайних шифровальщикв видел, которые пакостят только в отношении выбранных расширений, так что бэкапам ещё меняю расширение на ".backupchik" и тп. "Облако" свое, проплатил белый ИП, теперь крутится фтп сервак, с правами только на запись файла, тоесть пользователь/контора могут скинуть файлик с бэкапом, но ни удалить, ни переименовать его не смогут.
Вариант с кобианом тоже пользовался в паре мест, сделано было так... у кобиана же есть доп действия... при выполнении операции запускается яндекс-дисковская софтина, снимается копия, софтина выключается taskkill'ом. Бэкап не по расписанию, пользователь сам должен запустить его.
Вариант с кобианом тоже пользовался в паре мест, сделано было так... у кобиана же есть доп действия... при выполнении операции запускается яндекс-дисковская софтина, снимается копия, софтина выключается taskkill'ом. Бэкап не по расписанию, пользователь сам должен запустить его.
(17) vitalyok, Причем тут файловая база? В сабже достаточно ясно сказано, что речь именно о безопасности архивов. Вопрос безопасности при работе напрямую с файловой базой 1С никогда не стоял. Ее нет как класса. Как и надежности. Единственный выход - работа через веб-сервер или переход на клиент-сервер.
(18) herfis, я вас прошу показать пример защиты правами от шифровальщика файловой базы, и возможность безопасно хранить её резервные копии в облаке.
Пусть здесь речь не о файловой базе. Но вы не знаете каким образом происходит изменение объекта защиты. архивы можно сколько угодно слать куда угодно, но есть ли толк от такого подхода который избрал автор? Ведь по начальной логике автора видно что он перезаписывает архивную копию. И получит он нешифрованый архив в облаке с обработаным зловредами файл. и узнает он об этом только тогда, когда попытается из архива восстановиться.
(1) corbenSG, вы анализировали в какое время шифровальщик может атаковать файл который резервируете в облако?
нынешние зловреды имеют привычку расставлять приоритеты, фото и доки первые в очереди, потом базы данных, а потом если достаточно времени все подряд что не подходит по маске легко восстанавливаемых (*.exe;*.dll;*.ini;*.inf;*.cpl;*.tmp и т.д. и т.п)
Возможно я зря слишком углубляюсь, но, возможно, эти мысли помогут автору избежать непредвиденных трудностей и разочарований в будущем.
Пусть здесь речь не о файловой базе. Но вы не знаете каким образом происходит изменение объекта защиты. архивы можно сколько угодно слать куда угодно, но есть ли толк от такого подхода который избрал автор? Ведь по начальной логике автора видно что он перезаписывает архивную копию. И получит он нешифрованый архив в облаке с обработаным зловредами файл. и узнает он об этом только тогда, когда попытается из архива восстановиться.
(1) corbenSG, вы анализировали в какое время шифровальщик может атаковать файл который резервируете в облако?
нынешние зловреды имеют привычку расставлять приоритеты, фото и доки первые в очереди, потом базы данных, а потом если достаточно времени все подряд что не подходит по маске легко восстанавливаемых (*.exe;*.dll;*.ini;*.inf;*.cpl;*.tmp и т.д. и т.п)
Возможно я зря слишком углубляюсь, но, возможно, эти мысли помогут автору избежать непредвиденных трудностей и разочарований в будущем.
В облаке я собираюсь хранить несколько копий с временными метками. Записал новую в облако удалил 3 дневной давности. Моя тема на сайте это больше перестраховка. На сервере у меня делается бэкапы по дням неделям и месяцам. Плюс теневое копирование каждые 2 часа храниться 3 дня. Пока вроде бы шифровальщики не могут добраться до теневых копий. облако для меня единственный путь обезопаситься от пожара-наводнения-апокалипсиса. К какие еще облачные решения поддерживают версии файлов? Дроббокс не рассматриваю он для меня мал.
(24) Bedazzled, шифровать архив полезным шифровальщиком, заранее убедившись что он не зашифрован зловредным ))).
(23) herfis, жаль что не видите... я считаю единственно возможным защититься, держать файлик всегда открытым. Также можно хранить бд на шаре вируалной машины и снапшотить вм в шару с настроеными правами. но тут начинаются либо костыли либо деньги... привычный мне esxi (бесплатная версия) не умеет делать снапшоты, и поэтому приходится использовать стороние скрипты типа mksbackup. Плюсы: надежность, бесплатность, стабильность. Минусы: можно не заиметь всех плюсов, бекапов, но заиметь много проблем с тестированем и наладкой скрипта, всё зависит от умения и желания читать доки
(23) herfis, жаль что не видите... я считаю единственно возможным защититься, держать файлик всегда открытым. Также можно хранить бд на шаре вируалной машины и снапшотить вм в шару с настроеными правами. но тут начинаются либо костыли либо деньги... привычный мне esxi (бесплатная версия) не умеет делать снапшоты, и поэтому приходится использовать стороние скрипты типа mksbackup. Плюсы: надежность, бесплатность, стабильность. Минусы: можно не заиметь всех плюсов, бекапов, но заиметь много проблем с тестированем и наладкой скрипта, всё зависит от умения и желания читать доки
я считаю единственно возможным защититься, держать файлик всегда открытым
Это вообще ни разу не защита, потому как невозможно это гарантировать. Рано или поздно он освободится. А для шифрации заголовка хватит мгновений.
В принципе невозможно "по уму" защитить файлы в сетевой шаре с полным доступом. Тут в консерватории ошибка. Только защищенные бэкапы. Этого вполне достаточно с точки зрения цена/качество.
Кому нужна более высокая степень защищенности, те на файловой через сетевую шару не работают. При работе с файловой через сетевую шару больше вероятность поймать крах базы, чем проблемы с шифровальщиком.
corbenSG
если вам всё еще это интересно то я проверил , работает...немного фантазии и вечеров и у вас полноценноя программа для бекапов под ваши нужды:)
а еще идея можно ваш .bat ник засунуть в cobian backup у него есть там запуск стороней програмы до и после выполнения задания, и там вроде и лог настроить можно
например: копировать будет сам cobian, до копировнаия будет запускаться .bat и монтировать сетевой диск, по окончанию копирования будет запускаться .bat отмонторовать , и вот вам программа с кучей настроек:)
если вам всё еще это интересно то я проверил , работает...немного фантазии и вечеров и у вас полноценноя программа для бекапов под ваши нужды:)
а еще идея можно ваш .bat ник засунуть в cobian backup у него есть там запуск стороней програмы до и после выполнения задания, и там вроде и лог настроить можно
например: копировать будет сам cobian, до копировнаия будет запускаться .bat и монтировать сетевой диск, по окончанию копирования будет запускаться .bat отмонторовать , и вот вам программа с кучей настроек:)
Попробуйте BitTorrent Sync . — сервис для синхронизации файлов и резервного копирования по протоколу BitTorrent между произвольными устройствами.
BitTorrent Sync был разработан для того, чтобы решить фундаментальные вызовы синхронизации данных: ограничения на скорость, размер и пространство; ограничения на безопасность файла и зависимость от облачной инфраструктуры. С BitTorrent Sync можно синхронизировать файлы любых размеров. Трансферы происходят в зашифрованном виде, и информация не сохраняется на каком-либо сервере или в облаке. Ваше содержимое принадлежит вам, и остается на устройстве по вашему выбору.
Вообще отличая вещь я бэкапы через нее раскидываю между удаленными офисами.
BitTorrent Sync был разработан для того, чтобы решить фундаментальные вызовы синхронизации данных: ограничения на скорость, размер и пространство; ограничения на безопасность файла и зависимость от облачной инфраструктуры. С BitTorrent Sync можно синхронизировать файлы любых размеров. Трансферы происходят в зашифрованном виде, и информация не сохраняется на каком-либо сервере или в облаке. Ваше содержимое принадлежит вам, и остается на устройстве по вашему выбору.
Вообще отличая вещь я бэкапы через нее раскидываю между удаленными офисами.
не доверяю сторонним самодельным приложениям, поэтому написал бэкапилку на CMD :)
с ротацией локальных бэкапов, проверкой размера, упаковкой и шифрованием, отправкой в яндекс.диск, а заодно мониторингом свободного места на дисках, нагрузки проца (можно добавить что угодно), и отправкой результатов на почту. если что-то пошло не так, ставится высокий приоритет письма, в телефоне сразу отображается красным
кусок про заливку на я.диск выглядит примерно так:
net use Y: %davp% /user:%davu%
...
xcopy %way1%\%bname% Y:\ /c /h /y /z /j /q /v
set res=%errorlevel%
в переменной res остаётся результат случившегося, на основании которого стряпается лог для почты
с ротацией локальных бэкапов, проверкой размера, упаковкой и шифрованием, отправкой в яндекс.диск, а заодно мониторингом свободного места на дисках, нагрузки проца (можно добавить что угодно), и отправкой результатов на почту. если что-то пошло не так, ставится высокий приоритет письма, в телефоне сразу отображается красным
кусок про заливку на я.диск выглядит примерно так:
net use Y: %davp% /user:%davu%
...
xcopy %way1%\%bname% Y:\ /c /h /y /z /j /q /v
set res=%errorlevel%
в переменной res остаётся результат случившегося, на основании которого стряпается лог для почты
Подниму тему, так как она все еще актуальна.
Выше правильно написали, копирование на дропбокс решает проблему без плясок.
Там есть встроенные копии файлов в теч 30 дней. Т.е. сегодня скопировал, завтра изменил или удалил, потом открываешь историю, находишь более старую версию файла и восстанавливаешь ее. Бэкап бэкапа :)
Т.е. если зашифрованная база и перезапишется из истории можно поднять прошлый бэкап, до перезаписи.
Некоторые другие облачные хранилища тоже так умеют.
Выше правильно написали, копирование на дропбокс решает проблему без плясок.
Там есть встроенные копии файлов в теч 30 дней. Т.е. сегодня скопировал, завтра изменил или удалил, потом открываешь историю, находишь более старую версию файла и восстанавливаешь ее. Бэкап бэкапа :)
Т.е. если зашифрованная база и перезапишется из истории можно поднять прошлый бэкап, до перезаписи.
Некоторые другие облачные хранилища тоже так умеют.
Для получения уведомлений об ответах подключите телеграм бот:
Инфостарт бот