⚖️ Законы для ИТ

📃 Для КИИ опубликован закон о штрафах за нарушение требований.
Вступает в силу 20 апреля 2026 года и вводит отдельную ответственность за несоблюдение правил работы с критической информационной инфраструктурой.

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

📃 Для ИИ всё заметнее формируется отдельный регуляторный трек. Обсуждаются правила применения, распределение ответственности и общие требования к использованию таких систем.

📃 10 апреля 2026 года подписано распоряжение о продолжении федерального финансирования информатизации региональных систем здравоохранения. Это сохраняет спрос на государственные цифровые контуры, интеграции и сопровождение медсистем.

#ИТиЗАКОН

🧬 Каналы по 100 Гбит/с между ЦОДами в Новосибирске

Для регионального ИТ-рынка это важный шаг: отдельные площадки начинают работать как единая инфраструктурная среда.

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

Это основа для резервирования, переноса данных и стабильной работы ИТ-систем без лишних ограничений.

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

📇 Инфраструктура под ПДн: с чего начать

Если вы обрабатываете персональные данные, разбираться в требованиях к инфраструктуре придётся в любом случае.

Неважно, где размещены системы: в собственном контуре, в ЦОДе или в облаке.
У многих возникает одна и та же проблема: инфраструктура выбрана, договор подписан, данные размещены — а где проходят границы ответственности и какие требования нужно закрывать именно со своей стороны, понимают не до конца.

В вебинаре разбираем:
— что считается ЦОДом по 152-ФЗ;
— чем отличается собственная и сторонняя инфраструктура;
— что должно быть в договоре с провайдером;
— как распределяется ответственность между оператором и поставщиком услуг;
— какие ошибки чаще всего допускают при проектировании защиты ПДн.

Смотреть на любых удобных площадках:
▶️ Rutube
▶️ YouTube
▶️ VK Видео

#полезное

💠 Taints и Tolerations в Kubernetes: отсекаем лишних, пропускаем своих

🟣Taint — это метка на ноде, которая сразу отсекает неподходящие поды при планировании.

Формат taint: key=value:effect

Навесить taint на ноду

kubectl taint nodes node1 gpu=true:NoSchedule

Снять taint (добавить - в конец):

kubectl taint nodes node1 gpu=true:NoSchedule-

Три эффекта (effect)

— NoSchedule — планировщик не будет размещать новые поды без нужного toleration. Уже запущенные поды остаются.

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

— NoExecute — самый жёсткий: новые поды не планируются, а уже запущенные без toleration вытесняются с ноды.

🟣 Toleration — это правило в манифесте пода, которое разрешает ему размещаться на нодах с определённым taint.

Важно понимать: toleration не гарантирует, что под попадёт именно на эту ноду — он лишь снимает запрет.

Чтобы направить под на конкретную ноду, нужен nodeSelector или nodeAffinity.

apiVersion: v1
kind: Pod
metadata:
  name: gpu-app
spec:
  tolerations:
  - key: "gpu"
    operator: "Equal"
    value: "true"
    effect: "NoSchedule"
  containers:
  - name: app
    image: nvidia/cuda:12.0-base

Equal — ключ и значение должны совпасть.
Exists — достаточно наличия ключа, значение не проверяется. Удобно, когда нужно допустить под на ноды с любым значением ключа:

tolerations:
- key: "gpu"
  operator: "Exists"
  effect: "NoSchedule"

Если не указать key совсем — toleration сработает для любого taint на ноде.

Проверить taints на ноде

kubectl describe node node1 | grep Taints

Taints и Tolerations — это способ жёстко сегментировать кластер: выделить ноды под GPU, CI-воркеры, stateful-нагрузки или вообще зарезервировать их для конкретной команды. В паре с nodeAffinity получаем полный контроль над тем, где именно запускаются поды.

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

👩‍💻 Tmux — несколько терминальных сессий в одном окне

Tmux (Terminal multiplexer) — позволяет создавать несколько независимых терминальных сессий внутри одного подключения, разбивать экран на панели и — самое главное — отключаться от сессии, не прерывая запущенные в ней процессы.

Незаменим при работе по SSH: упал коннект — процессы продолжают работать, переподключился — всё на месте.

➡️ Основные концепции

— Session — независимая рабочая сессия. Живёт на сервере даже после отключения клиента.
— Window — вкладка внутри сессии. Аналог вкладки в браузере.
— Pane — панель внутри окна. Окно можно разбить на несколько панелей.

Все команды в tmux начинаются с префикса Ctrl+B (по умолчанию).

➡️ Работа с сессиями

# Создать новую сессию
tmux

# Создать сессию с именем
tmux new -s work

# Показать список сессий
tmux ls

# Подключиться к последней сессии
tmux attach

# Подключиться к конкретной сессии по имени
tmux attach -t work

# Переименовать сессию
tmux rename-session -t work devops

# Завершить сессию
tmux kill-session -t work

Отключиться от сессии (не завершая): Ctrl+B, затем D (detach)

➡️ Работа с окнами

Все комбинации после нажатия Ctrl+B:
c — создать новое окно
, — переименовать текущее окно
n — следующее окно
p — предыдущее окно
0-9 — переключиться на окно по номеру
& — закрыть текущее окно
w — список окон с предпросмотром

➡️ Работа с панелями

Разбить экран на панели — удобно для одновременного просмотра логов и выполнения команд:

% — разбить вертикально (left | right)
" — разбить горизонтально (top / bottom)
←→↑↓ — переключаться между панелями
x — закрыть текущую панель
z — развернуть панель на весь экран / свернуть обратно
{ — переместить панель влево
} — переместить панель вправо

Tmux решает главную боль работы по SSH: потерял соединение — потерял всё. С ним процессы живут независимо от терминала, а рабочее пространство можно разбить под любую задачу — логи, мониторинг, деплой — всё в одном окне.

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

🔒 Базовые технические меры защиты ПДн

С Вероникой Нечаевой обсудили, какой базовый минимум нужен бизнесу, чтобы снизить риск утечек: доступы, пароли, учётные записи, антивирус, бэкапы, рабочие устройства и контроль выгрузок.

Поговорили про:
— почему происходят утечки персональных данных;
— что делать с доступами после увольнения;
— чем опасны выгрузки из CRM и 1С;
— как проверять, работают ли бэкапы;
— что можно сделать для защиты данных без больших затрат.

Смотрите подкаст на наших площадках
▶️ YouTube
▶️ VK Видео
▶️ Rutube

#проИБ #инфобез

😵 Тупик масштабирования

❎Кластер виртуализации работает под полной нагрузкой.
❎Запаса вычислительных ресурсов нет.
❎Резерва под N+1 и плановые работы тоже нет.
❎Расширение нужно провести без остановки бизнес-сервисов, но любое изменение в текущей конфигурации повышает риск инцидента.

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

#статья

🔥 Топ-5 TUI-утилит для DevOps инженера

Подборка консольных интерфейсов, которые ускоряют повседневную работу — без ухода в браузер или IDE.

🔵k9s
— TUI для управления Kubernetes: навигация по ресурсам, логи, exec в поды, редактирование манифестов — всё по горячим клавишам и без длинных kubectl-команд. Фактически стандарт для ежедневной работы с кластером в терминале.

🔵 lazygit
— Интерактивный интерфейс для Git: стейджинг по строкам, interactive rebase, разрешение конфликтов, работа с ветками — всё через хоткеи.

🔵 gh dash
— Расширение для GitHub CLI, превращающее терминал в дашборд с PR и issue. Секции настраиваются под нужные репозитории и фильтры.

🔵 gping
— ping с графиком задержек прямо в терминале. Поддерживает несколько хостов одновременно — наглядно видно, где именно теряются пакеты и у какого узла растёт latency.

🔵 glances
— Кроссплатформенный системный монитор: CPU, память, диски, сеть, процессы, сенсоры, Docker-контейнеры — всё в одном экране. Умеет работать в режиме клиент-сервер и отдавать метрики по REST API или экспортировать в InfluxDB, Prometheus, Graphite.

#полезное

🖥 dmesg (diagnostic message) — команда для чтения буфера сообщений ядра Linux.

Ядро постоянно пишет в кольцевой буфер (ring buffer) всё, что происходит на уровне железа и драйверов: загрузку, подключение устройств, ошибки, предупреждения.

➡️ dmesg — окошко в этот поток.

💬 Когда это нужно?

— При подключении диска — dmesg покажет, увидело ли его ядро и под каким именем (sdb, nvme0n1).
— При аварийной остановке ядра — в буфере останется след причины.
— Флешка не монтируется — dmesg скажет, какой драйвер назначен и есть ли ошибки.
— После загрузки — проверить, всё ли инициализировалось корректно.

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

➡️Удобный просмотр с временны́ми метками

dmesg -H -T

➡️Только ошибки и предупреждения

dmesg --level=err,warn

➡️Следить за новыми сообщениями в реальном времени

dmesg -w

➡️Поиск информации о конкретном диске

dmesg | grep sdb

dmesg — первое место, куда в первую очередь смотрят, когда система ведёт себя нестабильно: не видит диск, не понимает железо, упала при загрузке.
Это прямой доступ к сообщениям ядра — без прослоек и интерпретаций.

В связке с grep, tail закрывает большую часть задач первичной диагностики на уровне железа и драйверов.

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

🦸‍♂️ 10 суперспособностей сильного ИТ-директора

Недавно обсуждали с коллегами, сколько же компетенций вмещает в себе хороший ДИТ?!

💪 Оказалось, что очень много!

Решили не останавливаться на размышлениях и ... сняли видео 📸😎

Смотрите в наших каналах:
▶️ Rutube
▶️ YouTube
▶️ VK Видео

#видео

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

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

С 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 с автоматической проверкой заданий.