Всем привет! Думаю как бы так сделать, чтобы если злоумышленник даже если и проник на сервер, не смог бы сделать плохо бекапам баз, понятно защитить базы мы не можем(или можем?). Но можно что-то придумать с бекапами. На данный момент делаются бекапы, которые хранятся на сервере и отдельно в файловом хранилище. Допустим злоумышленник все таки проник на сервер. Он зашифровал базы и стер или зашифровал бекапы и на этой машине и там куда они копируются. Если мы можем писать в удаленное хранилище, то и он может тоже. Какие у нас есть варианты:
1. Там куда копируется данные должны версионироваться. То есть он стер все или зашифровал. Мы восстановили из истории версий файла и поехали дальше. Пока непонятно как реализовать. Смотрю на яндекс диск. У него есть версионирование, но они говорят что это не для ком использование и не оф клиентам режут скорость. На сервер клиент яндекс диска ставить не хочу(может даже и не получится). Может еще какие варианты есть?
2. На сервере должен быть поднят сервис куда будет стучаться скрипт со стороны и забирать бекапы. Тогда будет зашифрован только один бекап - последний. Вообще непонятно куда смотреть и как решать.
Какие у вас варианты?

а что на это говорит сисадмин?

(0) то есть вариант не хранить бекапы на том же сервере не рассматривается?

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

(2)Какая разница хранятся ли они на том же сервере или нет, если они хранятся где-то еще, помимо него.
(3)Слишком длинный лаг. Можно потерять данные за ощутимый период времени. Много ручной не нужной работы которую могут забыть сделать.

(0) скидывать свежие архивы например на сервер sftp

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

(4) разница в деталях. Потерять бекап можно и на диске лежащем в сейфе. По-этому важно подходить к хранению исходя из угроз. Место для хранения сейчас стоит неприлично дешево, что мешает хранить бекапы в нескольких местах: файловый сервер в сети офиса для быстрого доступа и тестирования, 1-2 облачных хранилища в разных ДЦ для минимизации рисков потери данных. Все хранилища доступны из вне только на чтение, а может и вовсе не доступны и доступ только по VPN с доступом на ключах и тд

1. Поднимаешь на своем сервере FTP.
2. На него кладешь бэкап
3. арендуешь сервер в Австралии, который стучится на твой FTP и забирает с него файлы.
----для эстетов-----
4. сервер в Австралии в свою очередь кладет файлы на свой FTP.
4. арендуешь сервер в Швеции.
5. Он берет бэкап с Австралии и кладет на свой FTP
6. Ну а в подвале конторы стоит замурованный сервер, который никак не связан с конторой и берет бэкапы из Швеции и хранит у себя.

(5)Если делать вручную, то можно и себе на комп. Не имеет смысла ибо (4). Если автоматически то пароли придется хранить на сервере а это как бы сразу теряет смысл, потому, что их получит злоумышленник.
(6)Согласен с каждым словом. Никак не противоречит(4). Возможно тебе стоит перечитать(0). Там как раз про это вопрос.

(7) причем в подвале стоит электромеханическая релюшка, которая включает интернет только в определенные часы, на время достаточное для обмена данными. Часы включения задаются механически, при помощи диэлектрического диска с прорезями на циферблате будильника.

(7)ФТП сервер, на своем сервере. Хорошо. Вариант. Надо подумать как обойтись без сервера в Австралии.

(8) так если ты эту схему понимаешь, тогда в чем проблема? Разобраться и сделать самому или пригласить того кто сделает

(10) обойтись можно без чего угодно. из чего будет система состоять зависит только от того, какой уровень безопасности планируется достичь

(9) Месье знает толк )

(0) не реклама, сам использую: посмотреть в сторону 1с обновлятор, он не только умеет обновлять но и архивировать и складывать куда угодно.

(11)> так если ты эту схему понимаешь, тогда в чем проблема?
Спрашиваю как реализуется подобное у тех кто делал. Какое ПО, инструменты и пр. Может быть есть какие-то специализированные решения.

(14) да, хорошо работает, но для больших баз его я бы не стал использовать. все таки там лучше делать средствами SQL серверов и обязательно автоматизировать тестирование получающихся бекапов

(10) а почему нельзя мапить диск на время бекапа? Причем не весь диск а пустую папочку из которой файлы после бекапа будут скопированы
Даже если пароль и будет скомпрометирован, то злоумышленник получить доступ к пустой папке

(15) для ответа на этот вопрос нужно тебе сесть и описать модель угроз, возможные потери при срабатывании угрозы. Потом просчитать необходимые ресурсы в зависимости от того сколько и в скольки местах нужно бекапы хранить исходя из модели угроз и понять есть ли на это бюджет. Какого-то универсального ПО с кнопкой сделать хорошо нет

У нас бакапы сливаются на отдельный сервер под линуксом. Закачиваются на сервер бакапов под пользователем, у которого есть доступ только к песочнице. Далее нкрон на сервере бакапов перекладывает бакап в папку, не доступную этому пользователю. Версии тоже есть, проверка бакапов тоже. Чтобы зашифрованные бакапы не вытеснили нормальные

(17) можно, но хранить все равно лучше в сильно разных местах. А при передаче между местами хранения обязательно контролировать контрольную сумму архива, потому как и при передаче можно получить битый легко

(16) Согласен, для больших баз надо думать что то другое, хотя возможности обновлятора расширяют скрипты, а так же может архивировать и складывать не только базы.

По опыту, клиенты имеющие "большие ИБ" имеют соответствующих специалистов, уровнем выше чем "спрошу на форуме"

(21) я иногда в шоке от уровня специалистов клиентов с такими ЗП, что дурно становится

(16) Обновлятор умеет и средствами скуля бекап делать, в чем проблема то

(23) проблема что обновлятор то сделает. Но этого не достаточно, потому как большие бекапы нужно переносить с контролем, тестировать и разворачивать для тестирования. А значит что уже прийдется делать эту стистему, и в принципе сам бекап уже в ней и будет делаться и обновлятор не сильно нужен

(0) У нас это реализовано так.
все бэкапы скидываются в папку CurrentBackup на линуксовой машинке.
Затем папка CurrentBackup переименовывается в Backup_18092024 (т.е. соответсвущая дате бэкапа) и создается новая папка CurrentBackup. Папка с датой делается readonly, соответственно, даже вирус шифровальщик ее никак не зашифрует

(19) 👍

(25) но это не спасет от железной неисправности. А по редонли странно что вирусы еще не научились ее снимать. Если на сервер и проникли, то дальше при желании можно очень много чего натворить

(23)К обновлятору нет вопросов. Но единственная функция которая имеет смысл в данном контексте: создание бекапа, складывание бекапа куда либо. Ни с первым, ни с вторым нет проблемы.

(25)Очень хорошо. На эту тачку извне не попадешь. Только в одну папку. Которая текущая. Но если держать отдельно тачку под бекапы, надо возможно тогда бекапить не только архивы баз. Возможно нужен какой-то агент, что-то типа бакулы возможно.
(27)>но это не спасет от железной неисправности. Железная неисправность слабо волнует. Считаем, что одновременно умереть и база и отдельный диск с бекапами на этой машине и отдельностоящая машина под бекапы не могут. Что-то одно из трех в любом случае выживет. Даже скорее всего два из трех.

Мы пришли к такому решению. Поставили TrueNAS Scale, нарезали на нем “Dataset” для бэкапов, файлопомоек для юзеров и т.д. Датасеты расшариваешь как душе угодно (FTP, SMB, ISCSI).
На стороне NAS уже настраиваешь “Data Protection” тут доступны: снимки, репликации, синхронизации с облаками, корзины мусорные, теневые копии и т.д.
Бонусом из этого “Data Protection” для юзеров вытекает версионирование их файлопомоек. Юзер сам может посмотреть свои предыдущие версии файлов, не мучая админов с просьбами что-то восстановить из архива.

Один из хороших вариантов, прочитал где-то на просторах интернета.

Локально бекапы делаются как вам удобно и хранятся. Далее есть удаленная машина, не подключенная к домену/сети(постоянно) с своим Админ\Паролем, которая просыпается выкачивает локальные бекапы проверяет их там и засыпает. Из локальной структуры доступов к этой машине, конечно не должно быть. Особые люди даже удаленный доступ на такой машине отключают, тоесть чтобы что-то сделать иди за клаву/мышь.

Даже если вам всю сетку поломают получат доступ до всего, то та машина вне этой структуры выживет.

(0) Стратегия 3-2-1 не подходит?

(27)
Его не снять без пароля рута под Линуксом.
Если его нету то никак.

(33) Как правило если было проникновение, то и привелегий вирус получил много. Ибо без привелегий само проникновение не имеет особого смысла

(30) Звучит шикарно. И выглядит. Запишем.

(34) Это про винду справедливо. Про линукс я такого даже не слышал ни разу.

(34)Если он проник на сервер с базой, это не значит, что у него получилось проникнуть на сервер с бекапами. Если мы не храним конечно на сервере с базой, ключи от сервера с бекапами.

(36) давай по рассуждаем. Любой процесс в линуксе должен запуститься под тем или иным пользователем с определенными привелегиями. В случае вируса эти привелегии должны быть весьма высокими или он толком ничего не сможет сделать в системе, потому как к примеру к файлам БД имеет доступ или группа root/админы или пользователь, под которым стартует сервер БД. Пытаться получить права на пользователя сервера нет особого смысла, так как кроме файлов БД никуда доступа не будет. Куда логичнее получать доступ сразу к максимально возможной группе (по-этому и есть практика отключения root). А если доступ получен, то и ридонли поснимать не проблема, но пока на практике такого не видел

(37) я сейчас не про конкретно сервер с чем, а про в принципе то, что нужно хранить в нескольких местах не связанных при этом между собой на постоянной основе и никакое ридонли не спасет, как и не примонтированный раздел, ничего же не мешает вирусу промониторить устройства и попробовать их примонтировать

(39)Мы рассматриваем вариант когда злоумышленник попал на сервер с базой. Можно конечно придумать, что он попав на наш сервер еще сломал сервер с линуксом по дороге. Но чот это выглядит как пример из области фантастики.

Ну так и разверни ту же Bacula или Bareos (его клон).
Самое простое ssh сервер на сервере с базами, с бэкапного подключатся клиентом. Забирать.
Но по мне, конторе без админа достаточно и флешки.

(40) Опять же может зависеть от цели злоумышленника. Просто залетные да, а вот если это целенаправленная атака, то будут пытаться добраться до всего, вообще всего.

(0) У вас админ должен знать, как настроить правильный бэкап. Это должна быть специальная система/сервис (ЯД - детский сад).
Если рассмотреть распространенные случаи: обычно злоумышленник/вирус-шифровальщик получает привилегии на сервере и доступ к файловой системе, затем шифровальщик распространяется по всей сети, заражая в том числе и бэкапы, которые зачастую хранятся на расшаренной папке, куда имеет доступ администратор домена и, соответственно, вирус.
В итоге, сервис для бэкапа не должен зависеть от привилегий на рабочих серверах, и должен быть достаточно защищен от вторжений внутри сети.
Криво написал, не админ, но пару таких ситуаций наблюдал достаточно близко. Один раз поймали червя, второй раз через фишинг злоумышленник получил доступ и права администратора домена, и зашифровал вообще все (решение вопроса стоило 0,07 BTC).

Вообще мало что понял.
делается бэкап.
чем обеспечивается то, что сделанный бэкап не зашифрован еще до выкладки куда-нибудь?
(многие делают бэкапы, не проверяя их разворачиванием)

(40) если проникновение происходит через уязвимость, то как правило будет просканирована вся сеть и через эту же уязвимость могут быть взломаны и другие сервера

(0) Как-то мы составляли список требований к серверу бэкапов. Пришли к таким пунктам:

1. Сервер бэкапов должен находиться в отдельном здании.
2. Доступ к серверу бэкапов должен быть ограничен. Как физически, так и программно.
3. Желательно размещать где-то под землей.
4. Обязательное требование, в разы повышающее безопасность сервера: он должен быть выключен.

(0) все не читал, ибо лениво.
но я вообще не понимаю сути вопроса. Допустим, злоумышленник проник на сервер. Ну и ладно, проник и проник.
У тебя проблема в понимании процессов. Вот это, извини, выглядит не очень умно:

это глупость. Мы не должны писать в удаленное хранилище. Наоборот, удаленное хранилище должно само забирать бэкапы с сервера. То есть мы никоим образом не должны с сервера иметь доступ к удаленному хранилищу. От слова совсем. А вот удаленное хранилище должно иметь доступ к серверу, чтобы прочитать (скопировать) оттуда бэкапы. И тогда злоумышленник пусть хоть обшифруется на сервере, а на удаленное хранилище ему как попасть то? Если удаленное хранилище само подключилось, само забрало копии и тут же отключилось от сервера.

Фраза мы можем писать в удаленное хранилище вообще не должна иметь право на существование.

(45) В разных ОС разные уязвимости. Злоумышленники взломали рабочие серверы на винде, не значит что автоматом будут взломаны серверы бакапов на линуксе. тем более если там другое пользователи/пароли

(0) Можно попробовать спрятать бэкапы от вируса с помощью какой-нибудь утилиты. Например можно отформатировать диск так, что операционной системе будет доступна только половина емкости диска, а вторая половина форматируется нестандартным способом и потом туда прячутся файлы. Что-то подобное делали в институте, но это было во времена DOS-a и FAT-16, не знаю возможно ли такое в виндовc. Возможно найдутся умельцы, которые напишут такую утилиту...

(49) времена сейчас такие, что все серверы и не только уже не на винде

(50) когда коту делать нечего, он всякими непотребствами занимается. Вот такие костыли из этой области

(47) ну заберет удаленное хранилище с сервера уже зашифрованный бэкап...

(53) Ну восстановят из предыдущего, незашифрованного.
В любом случае давать серверу доступ к удаленному хранилищу - не нужно. Незачем.

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

бекапы разностные и делаются на ленточки.

раз в месяц ставится новая лента.

потерять можно только период после даты порчи до даты когда это обнаружили.

(0) Вместо борьбы с последствиями гораздо лучше сделать проникновение на сервер невозможным 99,9999% хакеров.Ну может 0,0001% смогут взломать,но не будут,им это не интересно.

(43)Все правильно говоришь. Тоже исхожу из этого
(44)Исходим из текущего тренда. Злоумышленнику нет смысла, оставлять боевую базу рабочей а бекапы зашифрованными, он рискует быть раскрытым если я захочу поднять бекап для проверки или тестовой копии. Если, произошел взлом, то упало все и в один момент. Ну и нет смысла пытаться защититься, если система уже инфицирована.
(47)>все не читал, ибо лениво.
Судя по ответу, ты и (0) стал читать не стал. Как минимум п.2
(48)Вполне себе может иметь. Например в папку назначения я могу только только писать новые файлы. Но не могу удалять или изменять. Ротацией занимается получатель бекапов самостоятельно.
(56)Прикольно. Даже не знал, что это живая технология.
(57)Мы приняли меры. Но в текущей ситуации, я считаю, что они недостаточны. Но пока сделать ничего не могу с этим, по независящим от меня причинам. Я работаю над этим. Так же я пока не понимаю, как защитить боевой сервер, если машина пользователя имеющего доступ с админ правами на боевой сервер по РДП будет инфицирована. Исключать подобное нет возможности.

(58) а защищать надо критические данные, сам по себе боевой сервер защищать смысла нету. ну образ виртуалки рабочей где-то держать, чтоб быстро развернуть. А, забыл выше в (25) написать, что линуксовая машина с копиями в сеть не светит, и доступ к ней каждый раз монтируется непосредственно в момент перед бэкапом, демонтируется сразу после.

(57) 100% гарантия что сервер не смогут взломать - это не включать сервер. Так что нужно подстраховываться с разных сторон

(57) имея доступ к обычной учетной записи домена специалисту достаточно недели, чтобы вывернуть кверху мехом всю инфраструктуру.

не пожалейте пары миллионов, закажите pentest.

(9) слышал историю про одного админа, который логи выводил параллельно на матричный принтер с рулоном бумаги - если злоум не знает о такой схеме, то затрет только программные логи и не догадается, что надо еще рулон бумаги затереть )

(61) нет смысла кормить дормоедов, увере тут у 98% проникнуть как 2 пальца, просто тут действует принцип неуловимого Джо.

(40) ты далек от этого, поэтому это для тебя фантастика, поверь, ты даже не успеешь пикнуть, когда узнаешь что тебя взломали. Пока они не получат доступы ко всему, они себя не раскроют, а потом за 10 минут вся сеть уже будет не ваша.
линуксы, виндовсы и т.д. не важно, на всё есть уязвимость и поэтому шансы есть только у грамотного админа, который понимает что нужно сделать чтобы уменьшить вероятность взлома.

(0) подходящий варик уже тебе писали, покупай ВПСку в ДЦ, на бэкапере поднимай SSH сервер, настраивай юзера по сертификату и забирай ВПСкой бэкапы с сервера.

(63)"ты даже не успеешь пикнуть, когда узнаешь что тебя взломали. Пока они не получат доступы ко всему, они себя не раскроют, а потом за 10 минут вся сеть уже будет не ваша."

в живую это выглядит пипец как страшно :)

а потом тебе дают отчет на 100 страниц со скринами рабочих столов юзеров, содержимого AD и прочее...

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

Еще понравилось вот это:

Больше пафоса, богу пафоса. Надо было так:

(66) от "не нужен" и "вскроют как консерву" полшага всего :)

(66) Одно необдуманное действие ЛПР и ты уже в зоне риска пятой точки. А в некоторых конторах с новыми законами натянут   ответственного за инф. безопасность и представь это не ГД теперь =)

Старый добрый DVD R и одноразовые диски уже предлагали? Записанные файлы имеют статус только для чтения для пользователя с любыми правами. не страшны любые скачки напряжения. кому мало 4-8 гб можно сторону блюрея посмотреть. есть бекапы за все дни бекапов.

(69) у меня в месяц бекапится примерно на 5 тб... это около 1000 дисков....

(69) проще USB-флешку с защитой от записи, там и гигабайт будет побольше, чем в блюрее
https://www.wildberries.ru/catalog/170439950/detail.aspx

(70) или там бэкапится дофига лишнего или контора может позволить себе нормального админа который все организует по уму. Это для мелкого бизнеса решение, где нужно надежно просто со 100% гарантией и которое сможет настроить специалист начального уровня 1 раз настроил и забыл без всяких дополнительной поддержки.

(71) умерших флешек после скачков напряжения, и еще непонятно чего у меня наверное больше 10 уже. и я небылбы так уверен что каким нибуть хитрым путем прошивки загрузщика флешки нельзя ее или убить или убрать эту защиту.

(73) Вы "небылбы"? Кто это?
Кстати, пишется "каким-нибудь", а не "каким нибуть"

[мимо проходил]
В 2 ночи сервер пишет бэкап; в 3 часа ночи "умная розетка" включает напряжение внешнего NAS; при запуске NAS, скрипт считывает с сервера "к себе" бэкап и завершает работу; "умная" розетка отключает напряжение NAS... Если мы можем писать в удаленное хранилище, то и он может тоже

(75) в этой схеме умная розетка - слабое и ненужное звено....

NAS - главное что-бы не имел доступа из основной сети на сетевом уровне, то есть он имеет доступ к шаре сервера, а со стороны сервера все порты закрыты.
А когда нужно востановить бекап в NAS вставляется флешка и с ЛОКАЛЬНОЙ КОНСОЛИ на нее переписываем, что надо...

(76) Мне кажется пофик кто к кому цепляется: рабочий сервер к серверу бакапов или наоборот, если доступ к серверу бакапов нормально настроен. Просто в таком случае будут эксплуатировать уязвимость сервера бакапа, а ее использование уже не зависит от настроек администратора. Можно все закрыть, и доступы и файрволы, но тк уязвимость - это ошибка самой системы, то все эти настройки не сработают

(0) Оказываем услугу хранения теневых бекапов

(76) Не вижу смысла держать NAS круглосуточно включенным ради раз в сутки работы на 10-15 минут.