⚠️ КИИ по новым правилам.

Требования к защите становятся конкретнее: появляются типовые отраслевые объекты, усиливается роль доверенного ПО и ПАК, меняются сроки и требования к взаимодействию с ГосСОПКА.

С 20 апреля 2026г вступил в силу закон, который вводит отдельную административную ответственность за нарушение правил эксплуатации объектов КИИ и правил доступа к ним.

Нужно не просто иметь документы, а понимать, какие системы входят в контур, насколько актуально категорирование и какие меры защиты нужно пересмотреть.

⚠️ Что стоит проверить уже сейчас

🔴Какие ИС, ИТКС и АСУ попадают под типовые отраслевые объекты.

🔴Актуально ли категорирование и не появились ли новые признаки значимости.

🔴Обновлены ли сведения по объектам КИИ: домены, IP-адреса, границы, владельцы, документы.

🔴Есть ли понятный план перехода на доверенное ПО и ПАК.

🔴Настроено ли взаимодействие с ГосСОПКА и НКЦКИ.

🔴Готовы ли процессы эксплуатации: доступы, изменения, журналы, реагирование на инциденты.

🔴Собрана ли доказательная база на случай проверки.

🔜 Подробнее разобрали в обновлённом материале.

#статья

СОЗДАЁМ МОДЕЛЬ УГРОЗ В РЕАЛЬНОМ ВРЕМЕНИ

Вы просили — мы сделали!
28 мая Вероника Нечаева проведёт обучающий практикум: «Модель угроз безопасности информации: от теории к практике».

Более 8 часов контента, ответы на все ваши вопросы и готовая модель угроз в двух частях практикума:
🔴 27-28 мая
🔴 10-11 июня

Вас ждёт пошаговый разбор процесса подготовки Модели угроз:
🟢определение границ и состава информационной системы;
🟢формирование описания объекта защиты;
🟢характеристика нарушителей и их возможностей;
🟢взаимосвязь уязвимостей, угроз и мер защиты;
🟢детализация необходимых разделов;
🟢ответы на ВСЕ вопросы и разбор ваших ситуаций.

В результате вы подготовите полноценную Модель угроз и уйдёте с полной ясностью, что и как делать деальше.

⁉️ ВНИМАНИЕ
Уровень сложности продвинутый, для тех, кто умеет рисовать схемы ИС, знает, как определить уровень защищённости и умеет чинить принтеры.

Количество мест ограничено.
Участие платное, по предварительной регистрации.

👉ЗАРЕГИСТРИРОВАТЬСЯ👈

🖥 chroot (change root) — системный вызов и одноимённая утилита в Unix-подобных системах, появившаяся ещё в 1979 году в Version 7 Unix.

Позволяет запустить процесс с подменённым корневым каталогом /, ограничивая ему видимость файловой системы.

🤓 Это самый базовый и древний механизм изоляции в Linux — предок современных контейнеров.

➡️ Как это работает?

— Ядро меняет для процесса значение корневого каталога на указанную директорию
— Процесс и все его дочерние процессы видят эту директорию как /
— Доступ к файлам выше нового корня становится невозможным
— Изоляция работает только на уровне файловой системы — процессы, сеть, PID и пользователи остаются общими с хостом

‼️ chroot — это не песочница и не средство безопасности в полном смысле.

Root-процесс внутри chroot может выйти из него через системные вызовы. Для настоящей изоляции используются namespaces, cgroups и контейнеры.

➡️ Базовый синтаксис

chroot [параметры] КАТАЛОГ [КОМАНДА [АРГУМЕНТЫ]]

Если команда не указана — запускается ${SHELL} или /bin/sh.

➡️ Основные параметры

— --userspec=USER:GROUP — выполнить от имени указанного пользователя/группы
— --groups=G_LIST — задать список дополнительных групп
— --skip-chdir — не делать cd / после смены корня

1️⃣ Пример
Минимальное окружение для bash

# Создаём структуру
mkdir -p /mnt/user/{bin,lib,lib64}

# Копируем bash
cp /bin/bash /mnt/user/bin/

# Копируем зависимости
ldd /bin/bash | grep -o '/lib.*\.[0-9]*' | xargs -I {} cp {} /mnt/user{}

# Запускаем chroot
sudo chroot /mnt/user /bin/bash

Внутри уже работает только bash — никаких ls, cat и прочего.

2️⃣ Пример
Запуск от имени конкретного пользователя

sudo chroot --userspec=1000:1000 /mnt/user /bin/bash

➡️ Где chroot пригодится:

— Восстановление системы — починка загрузчика, сброс паролей, обновление пакетов с LiveCD
— Сборка пакетов и ПО — изолированное окружение нужной версии дистрибутива (классика для debootstrap, pbuilder, mock)
— Тестирование — проверка установочных скриптов на чистой системе
— Хостинг устаревшего ПО — запуск приложений со старыми зависимостями без конфликтов
— DNS/FTP-серверы — bind9 и vsftpd исторически умеют сами себя помещать в chroot для ограничения области поражения при компрометации

chroot — простой, но мощный инструмент, лежащий в основе многих современных технологий. Понимание его принципов помогает осознать, как устроена изоляция в Docker, LXC и systemd-nspawn — там просто к смене корня добавлены namespaces для PID, сети, IPC и cgroups для ресурсов.

#линуксятина

🎙 За неделю

🔰 6 млн рублей — столько может стоить один веб-инцидент крупному бизнесу
Злоумышленники все чаще идут не в массовые атаки, а в точечный доступ к базам данных, корпоративным порталам и файловым хранилищам. Основные потери складываются из простоя, расследования и восстановления инфраструктуры после атаки.

🔰 Рынок Рунета вырос до 38,4 трлн рублей
В 2025 году экономика Рунета выросла на 28,1%, но его рост замедляется и рынок постепенно подходит к более зрелой стадии. Теперь компаниям важнее не просто наращивать цифровые сервисы, а повышать их эффективность, удерживать аудиторию и контролировать стоимость развития.

🔰 С 27 мая изменятся правила параллельного импорта компьютерной техники
Минпромторг исключил из перечня параллельного импорта часть компьютеров, ноутбуков и накопителей ряда зарубежных брендов. Для компаний это значит, что закупки техники могут стать менее предсказуемыми: стоит заранее проверять доступность оборудования, сроки поставок и возможные альтернативы.

МОДЕЛЬ УГРОЗ В 2026: ГЛАВНОЕ

Если вы обрабатываете персональные данные, то при проверке регулятор спросит у вас не только полный пакет ОРД, но и проектную документацию:

🔵модель угроз
🔵техническое задание
🔵технический проект

Закон №152-ФЗ говорит, что безопасность ПДн достигается, в том числе, определением угроз безопасности персональных данных при их обработке в ИСПДн.

Нет грамотной Модели угроз — нет нормального обоснования системы защиты.

⁉️Что будет, если не делать Модель угроз?
Проблемы начинаются, когда:
🔴нужно пройти согласование
🔴приходит проверка и нужно объяснить, почему выбраны именно такие меры защиты
🔴проводится аттестация
🔴меняется архитектура
🔴появляется инцидент

При этом проверяют не сам факт наличия файла с названием «Модель угроз». Проверяют логику и соответствие реальной защиты с угрозами в документе.

⁉️ВАЖНО

Модель угроз сама по себе не является «магическим щитом» от штрафа.Но если произошёл инцидент или пришла проверка, именно документы по защите информации показывают, что оператор:
🔵понимает, что защищает;
🔵определил актуальные угрозы;
🔵выбрал меры защиты осознанно;
🔵может обосновать архитектурные и организационные решения.

И наоборот: формальная или устаревшая Модель угроз усугубляет положение оператора и показывает РКН, что защиты, как таковой, нет.

На практикуме «Модель угроз безопасности информации: от теории к практике» мы разберём, как подготовить документ и защиту, которые выдерживают любые проверки.

👉 ЗАРЕГИСТРИРОВАТЬСЯ 👈

⚠️ Замена VMware не так проста, как кажется, особенно если речь про филиалы.

На первый взгляд да, задача выглядит просто: выбрали отечественную платформу, мигрировали ВМ-ки — и всё готово.

❗️Но при эксплуатации возникают нюансы:

🔵нужен запас мощности, стабильные каналы связи, хранение данных, обновления, поддержка и чёткий план реагирования на сбой;
🔵если филиал небольшой, всё становится сложнее: ресурсов мало, специалистов на месте нет, а любая ошибка может остановить работу сервисов;
🔵всё это напрямую влияет на стоимость проекта — потому что платить приходится не только за платформу и железо, но и за эксплуатацию, доработки, простой и переделки.

➡️ Проект не заканчивается миграцией.

После переноса ВМ важно, чтобы инфра стабильно работала, расширялась при необходимости и не превращала каждый сбой в пожар для всей команды.

👉 Почему импортозамещение виртуализации в филиалах часто выходит дороже, чем кажется, — разобрали на реальных примерах в новом материале.

#статья

💻 Node Affinity в Kubernetes: притягиваем поды к нужным нодам

В прошлый раз разобрали Taints и Tolerations: отсекаем лишних, пропускаем своих

Есть еще обратная сторона — Node Affinity.

Это правила в манифесте пода, которые говорят планировщику: «Хочу попасть на ноду с такими-то метками».
Своеобразная эволюция nodeSelector: та же идея, но с гибкой логикой, операторами и уровнями строгости.

💬 Чем отличается от Taints и Tolerations?

Taints & Tolerations работают от ноды: нода отталкивает всех, кто не имеет нужного toleration.
Node Affinity работает от пода: под сам тянется к нодам с нужными метками.

💬 Режимы работы

requiredDuringSchedulingIgnoredDuringExecution — жёсткое требование. Нет подходящей ноды — под уходит в Pending. Работает как nodeSelector, но с выразительным синтаксисом.

preferredDuringSchedulingIgnoredDuringExecution — мягкое предпочтение. Планировщик постарается найти нужную ноду, но если не найдёт — разместит на любой доступной. Задаётся с weight от 1 до 100: чем выше — тем приоритетнее.

IgnoredDuringExecution в обоих случаях означает одно: если метки на ноде изменились после запуска пода — под продолжает работать, пересчёта нет.

⭐️ Пример манифеста

affinity:
  nodeAffinity:
    requiredDuringSchedulingIgnoredDuringExecution:
      nodeSelectorTerms:
      - matchExpressions:
        - key: disk-type
          operator: In
          values:
          - ssd
    preferredDuringSchedulingIgnoredDuringExecution:
    - weight: 80
      preference:
        matchExpressions:
        - key: zone
          operator: In
          values:
          - ru-east-1a

Под обязан попасть на ноду с disk-type=ssd и предпочтительно в зону ru-east-1a.

⭐️ Операторы

In / NotIn — значение входит или не входит в список.
Exists / DoesNotExist — ключ есть или отсутствует на ноде.
Gt / Lt — числовое сравнение значений меток, только для nodeAffinity.
NotIn и DoesNotExist дают поведение anti-affinity — отталкивание через правила самого пода, без taint на ноде.

💬 Когда что использовать?

— Жёстко изолировать ноды под GPU, CI-воркеры или конкретную команду → Taints + Tolerations
— Направить под на ноды с нужными характеристиками: SSD, зона, архитектура → Node Affinity
— Полный контроль над планированием → оба механизма вместе

В связке Taints держат чужих подальше, а Node Affinity точно доставляет своих куда нужно.

#заметкиИнженера

🔝 Топ-5 постов #линуксятина

🔜 Вредоносное ПО в Linux
Разбор штатных утилит для обнаружения и устранения угроз: от анализа процессов и сетевых соединений до проверки учётных записей и логов. Никаких сторонних сканеров — только то, что уже есть в системе.

🔜 KVM + QEMU — виртуализация на Linux
Как запустить полноценную виртуальную машину с аппаратным ускорением: быстрый старт через qemu-system-x86_64 и управляемые ВМ через virt-install + virsh. Два подхода под разные задачи.

🔜 Загрузчики Linux
Обзор трёх способов загрузки системы: мощный GRUB для большинства случаев, минималистичный systemd-boot для UEFI и прямая запись в прошивку через efibootmgr — для тех, кто хочет убрать лишнее.

🔜 Netplan
Современный декларативный способ настройки сети через YAML-файлы. Пришёл на смену скриптам в /etc/network/interfaces и стал стандартом в Ubuntu Server и облачных образах Debian.

🔜 LabEx
Браузерная среда с полноценным терминалом Ubuntu — без виртуалок и доступа к реальному серверу. Готовые лабораторные работы по Linux, сети, Docker и DevOps с автоматической проверкой заданий.

П-пятница-полезное! 😘

Друзья, если вы ещё не приступали к модели угроз или сомневаетесь в той, что есть, то этот пост - для вас!

Модель угроз - обязательный документ для всех операторов ПДн, ровно как согласие на обработку и политика конфиденциальности.

Чтобы понять, что это такое и с чем это едят используют, читайте 2 подробных гайда в нашем блоге:

1️⃣Модель угроз для информационных систем персональных данных: кто ответственный, когда и как составлять, с чего начинать и на что опираться. В общем, база.

2️⃣Подробно о методике ФСТЭК для МУ: углубляемся, разбираем нюансы, шаги и примеры.

А для тех, кто уже разобрался в теории и хочет перейти к практике, Вероника Нечаева проведёт МАСТЕР-КЛАСС ПО МОДЕЛИ УГРОЗ В 2 ЧАСТЯХ.

Выше - лишь часть отзывов с прошлого МК.
8+ часов контента, только практика, реальные кейсы, ответы на ВСЕ вопросы, юмор Вероники и полезные бонусы.

Никто не уйдёт без ответов и готовой модели угроз.

Первая встреча пройдёт уже 27-28 мая.

⁉️Места ограничены, поэтому успевайте.

👉ЗАРЕГИСТРИРОВАТЬСЯ👈

⬆️ Как выбрать ИТ-инфраструктуру и не переплатить

Чаще начинают с технических параметров: серверов, облака, SLA и стоимости.

На практике начинать лучше с того, на чём держится бизнес:
— онлайн-продажи и клиентские сервисы;
— обработка заказов, логистика, документооборот;
— 1С, CRM, ERP и внутренние системы;
— интеграции с внешними площадками.
И определить требования к этим системам:
— RTO — сколько система может быть недоступна после сбоя;
— RPO — сколько данных можно потерять без критичных последствий.

Так становится понятнее, куда вообще двигаться: в паблик, частное облако, гибрид, выделенную инфраструктуру или резервную площадку.

В итоге компания платит за нужный уровень надёжности, производительности и резерва, а не за лишнюю сложность в архитектуре.

👉 Как выбрать ИТ-инфраструктуру под задачи компании и не переплатить за лишнюю сложность — разобрали в новом материале.

#статья

Перезапуск подов в Kubernetes.

Есть четыре разных перезапуска:

— Перезапуск контейнера — процесс убит и пересоздан, объект пода остался. UID и IP не меняются, restart count +1.
— Пересоздание пода — объект удалён, создан новый. UID новый, IP новый, restart count сбрасывается в 0.
— Rolling update — новый ReplicaSet поднимает новые поды, старые завершаются. Тоже новые UID и IP.
— In-place resize (1.35 GA) — cgroups обновляются, процесс не трогается. UID и IP неизменны.

Простой тест:
Изменился ли UID пода?
Если да — это пересоздание, а не перезапуск.
Если нет — тот же объект пода продолжил жить, перезапустился только процесс внутри.

➡️ Что часто упускают

kubelet следит за спецификацией пода — а не за ConfigMap'ами, Secret'ами или CRD Istio. Если вы обновили ConfigMap, но spec пода не изменился — kubelet ничего не сделает. Изменение для kubelet попросту невидимо.
Этот факт объясняет большую часть расследований «почему мой конфиг не обновился?» в проде.

💬 Что вызывает перезапуск, а что — нет?

— ConfigMap/Secret через env var — процесс читает переменные один раз при execve(). POSIX-контракт: никто извне не может их менять. Нужен явный rollout restart.
— ConfigMap/Secret как volume — kubelet делает атомарную подмену симлинка. Срабатывает IN_CREATE на ..data, а не IN_MODIFY на файле — большинство наивных реализаций reload этот момент пропускает. Приложение должно само перечитать файл.
— Смена образа — всегда пересоздание пода через rolling update. Новый ReplicaSet, новый UID, новый IP. Это не перезапуск.
— CPU/Memory в 1.35 GA — резайз без пересоздания пода. UID и IP не меняются. Контейнер перезапускается только если так указано в resizePolicy.
— Istio VirtualService / DestinationRule — никогда не перезапускает. Istiod пушит конфиг через xDS gRPC прямо в Envoy, в память. Файлов на диске нет.
— NetworkPolicy — никогда. CNI агент обновляет eBPF/iptables на ноде, поды не трогаются.

💬 Команды для проверки

Перезапуск или пересоздание?

 kubectl get pod <pod>  -n <namespace> -o custom-columns="NAME:.metadata.name,UID:.metadata.uid,IP:.status.podIP,RESTARTS:.status.containerStatuses[0].restartCount"

События в поде

kubectl describe pod  <pod>  -n <namespace>  | grep -A 20 "Events:" 

Понимание этих сценариев экономит время в инцидентах. Фраза «под перезапустился» слишком общая: сначала смотрим на UID и restart count. Так сразу видно, пересоздался сам pod или перезапустился только контейнер внутри.

С hot-reload сложнее. Он удобен, но не всегда даёт явный сигнал об ошибке: приложение может принять кривой конфиг, а проблема проявится позже и в другом месте. Пересоздание pod дороже, зато честнее: если что-то сломано, это быстрее станет видно по статусам, readiness и rollout.

#заметкиИнженера

🖥 sysctl — утилита для чтения и изменения параметров ядра во время работы системы, без перезагрузки.

Под капотом это интерфейс к виртуальной файловой системе /proc/sys/, где каждый параметр представлен отдельным файлом.

Полезно, когда нужно подкрутить сеть, память, лимиты или поведение ядра под конкретную нагрузку — БД, k8s-нода, прокси, файловый сервер.

💬 Как устроено?

Все настройки лежат в /proc/sys/ и сгруппированы по разделам:
— net.* — сетевой стек (TCP/IP, маршрутизация, ARP)
— vm.* — управление памятью и swap
— kernel.* — параметры ядра (PID, dmesg, core dump)
— fs.* — файловые системы (inotify, лимиты файловых дескрипторов)

💬 Основные команды

Посмотреть все параметры:

sysctl -a

Прочитать конкретный параметр:

sysctl net.ipv4.ip_forward

Изменить параметр на лету (до перезагрузки):

sudo sysctl -w net.ipv4.ip_forward=1

💬 Как сделать настройки постоянными?

Изменения через -w живут до первого ребута. Чтобы параметры применялись при загрузке — необходимо добавить их в конфиг.

Главный файл: /etc/sysctl.conf
Дополнительные: /etc/sysctl.d/*.conf

💬 Пример
создание дополнительного конфига:

sudo nano /etc/sysctl.d/99-custom.conf

Добавляем в файл следующие строки

# Включить форвардинг пакетов
net.ipv4.ip_forward = 1

# Увеличить лимит открытых файлов
fs.file-max = 2097152

# Уменьшить агрессивность swap
vm.swappiness = 10

Применить без перезагрузки:

sudo sysctl --system        # применить все конфиги из /etc/sysctl.d/
sudo sysctl -p              # применить /etc/sysctl.conf
sudo sysctl -p /etc/sysctl.d/99-custom.conf  # конкретный файл

sysctl — один из тех инструментов, которые отделяют «работает» от «работает под нагрузкой».
Дефолты ядра рассчитаны на универсальность, а реальные задачи почти всегда требуют тонкой настройки.

#линуксятина

🎬Только для вас - отрывок из прошлого практикума по моделированию угроз!
30 секунд из 8+ часов контента.

Вероника Нечаева вместе с вами возьмёт шаблон МУ (да, его предоставим) и пойдёт по порядку - так, чтобы у вас получился готовый, качественный документ, по которому вы не только построите систему защиты, но и будете готовы ко всем проверкам регуляторов.

Не откладывайте регистрацию!
Стартуем менее чем через 2 недели и берём ОГРАНИЧЕННОЕ количество участников, чтобы уделить время каждому.

👉РЕГИСТРАЦИЯ👈

🧬 Инциденты виртуализации, которые стоили бизнесу данных и миллионов рублей

Сбой в слое виртуализации быстро отражается на работе всей инфраструктуры.

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

Инциденты последних лет показывают, что слабое место не всегда находится в самом гипервизоре. Причиной может стать архитектура кластера, резервное копирование, доступы, DR-план или зависимость от одной платформы.

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

👉 В новом материале разобрали реальные инциденты: что стало причиной сбоев, к каким последствиям они привели и какие выводы стоит учесть при построении устойчивой инфраструктуры.

#статья

Ваши отзывы 🥰

Да, после практикума по модели угроз у вас точно не останется вопросов.

Вы можете задавать всё по вашей ситуации как в эфире, так и после – мы на связи.

В этот раз программа обновлена: будет ещё больше полезного, конкретного и актуального на реалии 2026.

Повторов не планируем! Давайте побережем ресурс нашей Вероники Нечаевой и не станем откладывать до следующего раза.

Стартуем уже в следующий четверг🔥

👉 РЕГИСТРАЦИЯ 👈

💻 Pod-Level Resource Managers — новая альфа-функция Kubernetes 1.36

Она расширяет работу Topology Manager, CPU Manager и Memory Manager в kubelet: теперь они умеют работать с ресурсами, заданными на уровне всего пода через .spec.resources, а не только по отдельным контейнерам.

🔵 Зачем это нужно?

Раньше менеджеры ресурсов в kubelet работали строго по контейнерам — каждому выделялись свои CPU и память, NUMA-выравнивание делалось индивидуально. Для типовых нагрузок это нормально, но для производительных приложений возникают проблемы:

— ML-тренировки с main-контейнером и sidecar'ами, которым нужен общий NUMA-узел
— Базы данных, где shared-память и кэш CPU должны быть выровнены для всего пода

В таких сценариях нужны эксклюзивные NUMA-выровненные ресурсы для всего пода как единого целого, а не для каждого контейнера по отдельности.

🔵 Пример использования

apiVersion: v1
kind: Pod
metadata:
  name: tightly-coupled-database
spec:
  # Pod-level resources establish the overall budget and NUMA alignment size.
  resources:
    requests:
      cpu: "8"
      memory: "16Gi"
    limits:
      cpu: "8"
      memory: "16Gi"
  initContainers:
  - name: metrics-exporter
    image: metrics-exporter:v1
    restartPolicy: Always
  - name: backup-agent
    image: backup-agent:v1
    restartPolicy: Always
  containers:
  - name: database
    image: database:v1

'Здесь 8 CPU и 16Gi памяти выделяются на весь под целиком. Kubelet через Topology Manager выровняет их по одному NUMA-узлу, а CPU Manager закрепит эксклюзивные ядра на уровне пода.

🔵 Что с CPU-квотами?

Меняется и работа CPU-квот в cgroup.
Раньше каждый контейнер получал свою квоту (cpu.max), и неиспользованный CPU одного контейнера не передавался другому. Теперь квота задается на родительском cgroup пода — контейнеры внутри могут брать из общего пула, пока не упрутся в общий лимит пода. Это удобно, когда основной контейнер периодически просит дополнительный CPU, а sidecar'ы работают неравномерно.

Pod-Level Resource Managers — логичный шаг в эволюции управления ресурсами k8s. Они закрывают старую боль с распределением CPU и памяти между контейнерами одного пода и делают кластер удобнее для чувствительным к производительности нагрузкам. Пока это альфа — нужно включать feature gate, и для прода рановато, но для тестов уже можно попробовать.

👉 Подробнее в официальном блоге Kubernetes

#заметкиИнженера

▶️ GitHub расследует возможный взлом внутренних репозиториев.

По данным ИБ-сообщества, хакерская группа TeamPCP заявила, что получила доступ примерно к 4 тыс. приватных репозиториев GitHub и выставила данные на продажу — от $50 тыс.

Предварительно, точкой входа могло стать скомпрометированное расширение для VS Code.

Сегодня разработческая среда — это доступ к репозиториям, токенам, CI/CD, облакам, секретам, внутренним пакетам и production-инфраструктуре.
Одно расширение в IDE может стать входной дверью в компанию.