Появилась тут одна мыслишка, навеянная недавними событиями. Хотел запостить в ИБ, по поскольку тема холиварная — напишу сюда.

Отсутствие обновлений — это плохо. Есть практические примеры серьезного ущерба из-за этого — например, СДЭК.
Обновления — это тоже плохо. Есть практические примеры серьезного ущерба из-за этого — например, Crowdstrike.

А что, если замутить какой-то гибридный вариант релизации какой-то важной системы? Типа, какой-то шлюз для доступа к системе извне, развернутый на машине, получающей последние обновления. И основная бизнес-логика, развернутая на машине с отключенными обновлениями и устроена по принципу "работает — не трогай". Доступ к бизнес-логике происходит через шлюз. И постоянно происходит мониторинг доступности: если шлюз навернется, до переключается режим доступа — и бизнес-логика становится доступна напрямую.
Пока я это представляю в очень общих чертах. Но в принципе такая штука может ли быть жизнеспособной? Может ли быть полезной в плане повышения безопасности и надежности? Или, может быть, подобная схема уже где-то реализована?

Здравствуйте, klopodav, Вы писали:

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

K> Или, может быть, подобная схема уже где-то реализована?

failover clustering?

K>> Или, может быть, подобная схема уже где-то реализована?

M>failover clustering?

А как failover clustering?

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

M>>failover clustering?
K>А как failover clustering?

поставщик Вашего решения по кластеризации обычно предоставляет инструкции и руководства на этот счёт.
(неважно, коммерческое это решение или freeware).

Здравствуйте, klopodav, Вы писали:

K>А что, если замутить какой-то гибридный вариант релизации какой-то важной системы? Типа, какой-то шлюз для доступа к системе извне, развернутый на машине, получающей последние обновления. И основная бизнес-логика, развернутая на машине с отключенными обновлениями и устроена по принципу "работает — не трогай". Доступ к бизнес-логике происходит через шлюз. И постоянно происходит мониторинг доступности: если шлюз навернется, до переключается режим доступа — и бизнес-логика становится доступна напрямую.
K>Пока я это представляю в очень общих чертах. Но в принципе такая штука может ли быть жизнеспособной? Может ли быть полезной в плане повышения безопасности и надежности? Или, может быть, подобная схема уже где-то реализована?

Загрузка по сети со своего сервера

M>поставщик Вашего решения по кластеризации обычно предоставляет инструкции и руководства на этот счёт.
M>(неважно, коммерческое это решение или freeware).

Я, конечно, не много руководств к решениям по кластеризации видел и не от корки до корки их читал. Но там, где видел — этот вопрос как-то обходился стороной (в кровавом энтерпрайзе как-то традиционно считалось, что официальных обновлений боятся только параноики, и лишь недавно появился очень убедительный контрпример). Или теперь руководства станут более качественными, и этому вопросу тоже будет уделено внимание?

K>Я, конечно, не много руководств к решениям по кластеризации видел и не от корки до корки их читал. Но там, где видел — этот вопрос как-то обходился стороной (в кровавом энтерпрайзе как-то традиционно считалось, что официальных обновлений боятся только параноики, и лишь недавно появился очень убедительный контрпример). Или теперь руководства станут более качественными, и этому вопросу тоже будет уделено внимание?

Для отказоустойчивого кластера тема обслуживания (железа и софта) никак обойдена быть не может.
Вот примеры по MS Windows Failover Clustering:
How to update Windows Server failover clusters
https://learn.microsoft.com/en-us/troubleshoot/windows-server/high-availability/windows-server-failover-clusters-service-packs-hotfixes
Cluster-Aware Updating overview
https://learn.microsoft.com/en-us/windows-server/failover-clustering/cluster-aware-updating
Cluster-Aware Updating requirements and best practices
https://learn.microsoft.com/en-us/windows-server/failover-clustering/cluster-aware-updating-requirements

Правда там в основном инструкции типа, смените активную ноду, обновите неактивную, убедитесь что все OK и повторите процедуру для других нод. Плюс автоматизация этого дела.
Но MS WFC это достаточно универсальная платформа.
Для более специфического кластера (какая-нибудь БД или веб-сервер), будут более специфичные инструкции.

Здравствуйте, klopodav, Вы писали:

K>А что, если замутить какой-то гибридный вариант релизации какой-то важной системы? Типа, какой-то шлюз для доступа к системе извне, развернутый на машине, получающей последние обновления.

А толку? Раз есть обмен данными (через шдюз или нет) — значит есть возможность для взлома. Коду на сишечке всегда можно передать что-то такое что сорвет ему крышу.

Здравствуйте, klopodav, Вы писали:

Сначала тестировать, потом уже накатывать массово? Да ну, глупость какая-то.

Здравствуйте, klopodav, Вы писали:

K>А что, если замутить какой-то гибридный вариант релизации какой-то важной системы?
На линухе ты можешь просто тупо разрешить только обновления безопасности и всё будет работать.
Но до того момента пока не придется заюзать программу с новой glibc. В линухах нынче тоже старательно наступают на все те грабли, по которым мелкомягкие топчутся уже 20 лет.

Здравствуйте, klopodav, Вы писали:
K>Пока я это представляю в очень общих чертах. Но в принципе такая штука может ли быть жизнеспособной? Может ли быть полезной в плане повышения безопасности и надежности? Или, может быть, подобная схема уже где-то реализована?
Пока не видно особой полезности. В случае "убийственного обновления" ляжет шлюз, и ваша "работает — нетрогай" система окажется недоступной. Единственное, от чего это спасёт — от обновления, которое не просто выведет рабочую систему из доступности, а ещё и испортит её данные.