Для ЛЛ: долго, дорого, не тиражируемо
У продуктов Microsoft есть WSUS (развитие прекращено, но про это я писал
Чего лишаемся в 2025 году внутри Microsoft
С продуктами (вторичными. Кто сдает продукт вторичный, тот снабжается отлично) в экосистеме Linux все гораздо хуже.
Причин несколько.
Первая, это сотрудники, имитирующие информационную безопасность.
Периодически такие эксперты показываются в диалогах, но в РФ (да и в мире) нет понятия «репутация», а должность нужно кем-то закрывать. Еще до 2022 года вменяемых специалистов по ИБ в РФ было «поштучно», и были они там, где речь шла о серьезном бизнесе серьезных парней. В этот бизнес, как показала практика, не входили МТС, Аэрофлот, СДЭК, и так далее по списку организаций, которых взломали. В том числе не входят фирмы по предоставлению ПО для информационной безопасности, которых взламывали для атаки на цепь поставок. И в РФ, и в мире.
Вторая, это суммарная сложность систем и совокупная стоимость владения.
Декларируется, но не подтверждается цифрами, что «экосистема Linux» это дешево. Практически это так же дорого, или дороже, чем в экосистеме Windows, но со своими нюансами.
Совокупно «так на так» и выходит, но есть и отличия.
Для того, чтобы понимать сложность, надо понимать устройство какого-то сервиса, сложнее сервиса печати.
Усредненный, сравнительно простой, продукт (программный комплекс) под Linux состоит из:
Ядра операционной системы и его окружения. С этим компонентом вопросов нет, хотите – убунта, хотите – дебиан, хотите – русифицированный дебиан, хотите – русифицированный RHEL \ CentOS.
Java поверх него. И это первая и очень большая неприятность. Под названием «несколько веток Java» - начиная с Oracle Java, OpenJDK, Microsoft Build of OpenJDK, и для РФ Axiom JDK
Они все не одинаковые. Конечно, на любой вы можете сделать
System.out.println("Hello, World");
Но чуть более сложные вещи могут работать не всегда. Или работать, только 2+ДВА у вас станет не 4, а ЧЕТЫРЕ.
Поверх операционной системы стоит сервер приложений. На выбор - Apache Tomcat, WildFly (JBoss), GlassFish и так далее.
Рядом с сервером приложений стоит сервер API . Или не стоит, а все крутится в контейнерах, и сервера приложений тоже нет.
Для Apache Tomcat - Spring Boot или Apache TomEE
Для WildFly не помню. Документация говорит «из коробки все самое лучшее». Почему-то вспоминается старый советский фильм с фразой "У барона Врангеля всё английское!".
Внутри сервера стоят драйвера для всего, в первую очередь для баз данных. И хорошо, если они работают, потому что под Java периодически не работает вообще ничего.
Над сервером стоит надстройка. Хорошо если это уже само приложение. Не так хорошо, если это очередная надстройка, чтобы делать надстройки, внутри которой надстройка для ИИ, в котором агентами накручено приложение на но-код платформе.
Из рассмотрения выкинута кластеризация и виртуализация аппаратной части (или кубер с талосом, если вы взрослая, зрелая организация), сетевой кластер с l3-L7 фильтрацией, кластер баз данных, со своим зоопарком и к нему зоокипером, кластер очередей, кластер логов, кластер мониторинга, прочие взаимодействия с внешними системами, и так далее. Выкинута вся цепочка CI-CD.
Проблемы видите?
Нет никаких проблем, если этот копролит работает, согласно названию, одним окаменевшим куском, а вы занимаетесь только ручным обновлением браузера на рабочих станциях.
Ну как, занимаетесь - в крон поставили apt update. Первой группе по 10м числам месяца, вторым по 20м. Назвали это все «разделением на группы обновлений», а тестирование представляет собой запуск пользователями своих ПК в виде «экран ввода логина появился, значит - все работает».
Или занимаетесь не автоматизацией тестирования, а сообщаете, что вы специалист и точно знаете, что автоматизация – зло, поэтому обновления проводятся вручную, специально обученным команде apt update сотрудником.
И все, кто говорит про автоматизацию - недоадминчики в рогах и копытах. Удобно.
Как только в организации приходят специалисты по имитации бурной деятельности (включая меня), они сразу пытаются обновить один компонент где-то в середине цепочки, отчего вся система подпорок и костылей падает с грохотом.
У вас или есть контур автоматизированного тестирования, то есть CI\CD на стероидах и ИИ, или его нет, и вы просто льете в прод, и молитесь. А если не молитесь, то вам бы следовало этим заняться
Построение тестового контура многократно описано в литературе.
Начиная с создания DEV и TEST контуров, создания снапшотов перед тестами, автоматизированного тестирования полученной выкатки, ручного тестирования полученной выкатки, и затем помолиться еще раз, сделать бекапы, и катить уже в прод.
Отдельные индивидуумы делают снапшоты СХД, подключают снапшоты к тестовым средам, и делают предварительное обновление прода и на нем тоже. Достаточно лишь простой американской (или китайской) системы хранения данных, которая может сделать снапшот данных, и подключить его к другой системе.
Но такая система не переносима между организациями, она не внедряется методом далее-далее-готово. Это и плюс, что и эксплуатировать такую систему может только человек, с ней знакомый. И минус, что на рынке каждая такая система уникальна, и метод работы с именно таким сценарием плохо переносится на другие системы.
Существует проблема ограниченного кругозора. Ряд персонажей, в том числе отвечающих за ИБ, воспринимают обновления безопасности как индивидульные обновления отдельных приложений. Когда приложение «всего лишь меняет цифру». Отсюда растет неприятие системы автоматических обновлений, поскольку система «просто ставит обновления, и ничего не делает».
Если у таких участников дискусии система автоматических обновлений, которую они, зачастую, не могут даже назвать, просто делает apt update,
- всем
- не выполняя никаких предварительных действий,
- делает это на пользовательском сегменте,
то, конечно, от такой «автоматизации» будут проблемы.
В нормальном случае нужно иметь и контуры обновления, и автоматизированную установку на контур тестов для обновлений, и систему снапшотов с откатом состояния, и автотесты после обновления даже тестовых пользовательских рабочих мест.
Но это дорого, тестировать сразу на пользователях дешевле.
Я не осуждаю такой вариант борьбы с роботами.
Для тех, кто дочитал.
Лукацкий выдал интересный пост:
Один из самых крупных и влиятельных венчурных фондов из Кремниевой долины, Andreessen Horowitz (он же a16z) показал тут интересные графики по кибербезу. Понятно, что это не их данные, а собранные из разных источников, но тут интересно, что такую тему поднял венчурный фонд в рассылке для своих клиентов:
Параболический рост числа критических и опасных уязвимостей, который произошел в этом году. Этому множество причин – от вайбкодинга и снижения качества кода до ускорения поиска уязвимостей с помощью ИИ.
Рост числа уязвимостей, эксплуатируемых в день раскрытия или даже до этого дня. За последний год рост составил около 60%. Термин 0-Day уходит в небытие и ему на смену приходит N-Hours. Не за горами X-Minutes.
Медианное время для эксплуатации уязвимостей сегодня составляет около одних суток. В следующем году эта цифра сократится до... 1 минуты. Насколько вы готовы к такой скорости использования дыр в вашей инфраструктуре?
Число CVE, которое остается непроэксплутированными в течение 1,5-3 месяцев, снижается до... нуля уже в этом году. То есть все, что находится, будет использовано плохими парнями. В 2022-м году число таких уязвимостей составляло 50%. То есть сейчас, если не вы нашли и устранили уязвимости, это обязательно сделает кто-то другой. И хорошо, если это будет не белый хакер в рамках кибериспытаний.
Последние два графика показывают интерес инвесторов к этой тематике, который превосходит такие темы, как облака, инфраструктура, ПО и т.п. Тут интерес a16z понятен – они зарабатывают на этом. Но все цифры проверяемы и на уровне ощущений понятны.
