CORTEL

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

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

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

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

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

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

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

#статья

⁉️ВАЖНО

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

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

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

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

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

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

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

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

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

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

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

🎙 За неделю

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

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

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

🖥 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 для ресурсов.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

#статья

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

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

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

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

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

#видео

🖥 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 закрывает большую часть задач первичной диагностики на уровне железа и драйверов.

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

🔥 Топ-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.

#полезное

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

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

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

#статья

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

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

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

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

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

👩‍💻 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: потерял соединение — потерял всё. С ним процессы живут независимо от терминала, а рабочее пространство можно разбить под любую задачу — логи, мониторинг, деплой — всё в одном окне.

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

💠 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 получаем полный контроль над тем, где именно запускаются поды.

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

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

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

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

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

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

#полезное

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

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

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

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

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

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

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

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

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

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

#ИТиЗАКОН

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

💬 Как работает?

Iperf работает по схеме «клиент–сервер»:

— На одной стороне запускается сервер (ждёт подключения)
— На другой — клиент (генерирует трафик и меряет скорость)
— Умеет работать по TCP (показывает максимальную полосу с учётом окон и потерь) и по UDP (показывает потери, джиттер, скорость)

После теста выдаёт отчёт: пропускную способность в Mbit/Gbit, объём данных, а для UDP — сколько пакетов потеряно.

💬 Основные аргументы iperf3

🔵 Клиентский режим и серверный:
— -s — запустить в режиме сервера
— -c <адрес> — режим клиента, подключиться к серверу

🔵 Параметры теста:
— -p <порт> — порт (по умолчанию 5201)
— -t <сек> — длительность теста (по умолчанию 10 секунд)
— -i <сек> — интервал вывода промежуточных результатов
— -P <n> — количество параллельных TCP-потоков (нагружает сильнее)

🔵 Полезные опции:
— -R — reverse mode: клиент принимает, сервер отправляет (проверяет обратный канал)
— -f <k/m/g> — формат вывода (Kbits, Mbits, Gbits)
— -J — вывод в JSON (для скриптов и автоматизации)

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

Базовый TCP-тест

Сервер:

iperf3 -s

Клиент:

iperf3 -c 192.168.1.10

Через 10 секунд появиться что-то вроде 940 Mbits/sec — это реальная пропускная способность гигабитной сети.

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

💻 kube-apiserver: мозг и шлюз Kubernetes-кластера

В Kubernetes всё крутится вокруг API.
Центральный компонент control plane, с которым общаются все остальные — kubectl, kubelet, scheduler, контроллеры и внешние системы — это kube-apiserver.

👀 Что он делает?

— Единая точка входа
Все операции (создание, чтение, обновление, удаление ресурсов) проходят через API-сервер. Другие компоненты не общаются друг с другом напрямую.

— Аутентификация и авторизация
Проверяет, кто делает запрос (сертификат, токен, OIDC) и имеет ли он права.

— Валидация и мутация
При создании или изменении ресурса API-сервер проверяет корректность манифеста и может изменять его через admission webhooks.

— Хранение состояния
Единственный компонент, который общается с etcd — распределённым хранилищем кластера. API-сервер кэширует данные и обеспечивает согласованность.

— Механизм watch
Клиенты могут подписаться на изменения ресурсов через long polling. Это позволяет мгновенно реагировать на события без постоянных опросов.

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

➡️ Пользователь выполняет kubectl create deployment nginx --image=nginx
➡️ kubectl преобразует команду в HTTP-запрос (JSON) и отправляет его на kube-apiserver.
➡️ API-сервер аутентифицирует пользователя (например, по сертификату из kubeconfig).
➡️ Проверяет права через RBAC: есть ли разрешение на создание deployment в указанном namespace.
➡️ Запускается цепочка admission controllers: валидация (нет ли синтаксических ошибок), мутация (применяются политики по умолчанию).
➡️ API-сервер сериализует объект в Protobuf/JSON и записывает в etcd.
➡️ Возвращает клиенту успешный ответ.
➡️ Событие о создании deployment’а через watch-механизм получает kube-controller-manager, который создаёт ReplicaSet, а тот — поды. Scheduler назначает поды на ноды, а kubelet их запускает.

Пример

kubectl get pods -v=8

В выводе будут видны HTTP-запросы к /api/v1/namespaces/default/pods. API-сервер аутентифицирует запрос, проверяет RBAC, затем загружает данные из etcd (или из своего cache), сериализует в JSON и возвращает.

kube-apiserver — это не просто «REST API».
Это центральная нервная система Kubernetes, которая совмещает роль шлюза, диспетчера, хранителя состояния и механизма оповещений.

Понимание его работы помогает диагностировать 80% проблем с кластером: от отказа в доступе до зависших ресурсов.

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