CORTEL

⛔️️️️ГЛАВНАЯ ОШИБКА ПРИ СОСТАВЛЕНИИ МОДЕЛИ УГРОЗ На практике всё едет в тартарары не туда ещё до отбора самих угроз. Гораздо раньше, на этапе, где нужно ответить на вопрос: что именно мы защищаем? То есть определить границы информационной системы, состав объекта защиты и исходные данные. Если границы ИС определены неверно, дальше некорректным становится всё — от состава компонентов до выводов по достаточности защиты. Нельзя корректно определить угрозы для системы, если непонятно, где эта система начинается и где заканчивается. Качественная Модель угроз начинается с описания: 1. Что является объектом защиты. 2. Где проходят границы ИС. 3. Как выглядит архитектура. 4. Какие есть исходные данные. 5. Какие допущения приняты. И только после этого можно переходить к нарушителям, уязвимостям и угрозам. Если вы хотите сделать МУ вместе с Вероникой Нечаевой в прямом эфире по готовому шаблону, то не откладывайте. Места в группу заканчиваются, а стартуем уже через неделю, 28 мая. 👉 ХОЧУ С ВАМИ, РЕГИСТРИРУЮСЬ 👈

▶️ GitHub расследует возможный взлом внутренних репозиториев. По данным ИБ-сообщества, хакерская группа TeamPCP заявила, что получила доступ примерно к 4 тыс. приватных репозиториев GitHub и выставила данные на продажу — от $50 тыс. Предварительно, точкой входа могло стать скомпрометированное расширение для VS Code. Сегодня разработческая среда — это доступ к репозиториям, токенам, CI/CD, облакам, секретам, внутренним пакетам и production-инфраструктуре. Одно расширение в IDE может стать входной дверью в компанию.

💻 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 #заметкиИнженера

Ваши отзывы 🥰 Да, после практикума по модели угроз у вас точно не останется вопросов. Вы можете задавать всё по вашей ситуации как в эфире, так и после – мы на связи. В этот раз программа обновлена: будет ещё больше полезного, конкретного и актуального на реалии 2026. Повторов не планируем! Давайте побережем ресурс нашей Вероники Нечаевой и не станем откладывать до следующего раза. Стартуем уже в следующий четверг🔥 👉 РЕГИСТРАЦИЯ 👈

🧬 Инциденты виртуализации, которые стоили бизнесу данных и миллионов рублей Сбой в слое виртуализации быстро отражается на работе всей инфраструктуры. Под ударом оказываются не отдельные виртуальные машины, а сервисы, базы данных, внутренние системы и процессы, которые от них зависят. Скорость восстановления в такой ситуации зависит от того, насколько инфраструктура заранее готова к отказам, атакам и ошибкам в эксплуатации. Инциденты последних лет показывают, что слабое место не всегда находится в самом гипервизоре. Причиной может стать архитектура кластера, резервное копирование, доступы, DR-план или зависимость от одной платформы. Поэтому отказоустойчивость виртуализации — это про готовность компании восстановить критичные системы в допустимые сроки и не потерять больше данных, чем бизнес может себе позволить. 👉 В новом материале разобрали реальные инциденты: что стало причиной сбоев, к каким последствиям они привели и какие выводы стоит учесть при построении устойчивой инфраструктуры. #статья

🎬Только для вас - отрывок из прошлого практикума по моделированию угроз! 30 секунд из 8+ часов контента. Вероника Нечаева вместе с вами возьмёт шаблон МУ (да, его предоставим) и пойдёт по порядку - так, чтобы у вас получился готовый, качественный документ, по которому вы не только построите систему защиты, но и будете готовы ко всем проверкам регуляторов. Не откладывайте регистрацию! Стартуем менее чем через 2 недели и берём ОГРАНИЧЕННОЕ количество участников, чтобы уделить время каждому. 👉РЕГИСТРАЦИЯ👈

🖥 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 — один из тех инструментов, которые отделяют «работает» от «работает под нагрузкой». Дефолты ядра рассчитаны на универсальность, а реальные задачи почти всегда требуют тонкой настройки. #линуксятина

Перезапуск подов в 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. #заметкиИнженера

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

А для тех, кто уже разобрался в теории и хочет перейти к практике, Вероника Нечаева проведёт МАСТЕР-КЛАСС ПО МОДЕЛИ УГРОЗ В 2 ЧАСТЯХ. Выше - лишь часть отзывов с прошлого МК. 8+ часов контента, только практика, реальные кейсы, ответы на ВСЕ вопросы, юмор Вероники и полезные бонусы. Никто не уйдёт без ответов и готовой модели угроз. Первая встреча пройдёт уже 27-28 мая. ⁉️Места ограничены, поэтому успевайте. 👉ЗАРЕГИСТРИРОВАТЬСЯ👈

П-пятница-полезное! 😘 Друзья, если вы ещё не приступали к модели угроз или сомневаетесь в той, что есть, то этот пост - для вас! Модель угроз - обязательный документ для всех операторов ПДн, ровно как согласие на обработку и политика конфиденциальности. Чтобы понять, что это такое и с чем это едят используют, читайте 2 подробных гайда в нашем блоге: 1️⃣Модель угроз для информационных систем персональных данных: кто ответственный, когда и как составлять, с чего начинать и на что опираться. В общем, база. 2️⃣Подробно о методике ФСТЭК для МУ: углубляемся, разбираем нюансы, шаги и примеры.

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

📝 Обучающие материалы по модульной платформе Kubernetes Совсем недавно мы делились изменениями в релизе nxs-universal-chart v.3.0. В первой статье из серии обучающих Пётр, DevOps-инженер компании Никсис, рассказал о том, как развернуть полностью готовый Inference контур в Kubernetes на основе KServe и Istio Gateway. Из первой части вы разберете: • 5 слоев inference-контура и функции каждого компонента; • полный values.yaml файл на примере ai-inference-mesh и всё, что под капотом; • рекомендации по настройке полноценного мониторинга моделей и правил безопасности Приятного чтения и продуктивной недели! #Хабр #статья_Никсис #kubernetes

💻 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 точно доставляет своих куда нужно. #заметкиИнженера

Вань, а сложно прикрутить в видео обложку ? Где-то в каком-то редакторе?

⚠️ Замена VMware не так проста, как кажется, особенно если речь про филиалы. На первый взгляд да, задача выглядит просто: выбрали отечественную платформу, мигрировали ВМ-ки — и всё готово. ❗️Но при эксплуатации возникают нюансы: 🔵нужен запас мощности, стабильные каналы связи, хранение данных, обновления, поддержка и чёткий план реагирования на сбой; 🔵если филиал небольшой, всё становится сложнее: ресурсов мало, специалистов на месте нет, а любая ошибка может остановить работу сервисов; 🔵всё это напрямую влияет на стоимость проекта — потому что платить приходится не только за платформу и железо, но и за эксплуатацию, доработки, простой и переделки. ➡️ Проект не заканчивается миграцией. После переноса ВМ важно, чтобы инфра стабильно работала: работала стабильно, расширялась при необходимости и не превращала каждый сбой в пожар для всей команды. 👉 Почему импортозамещение виртуализации в филиалах часто выходит дороже, чем кажется, — разобрали на реальных примерах в новом материале. #статья

⁉️ВАЖНО Модель угроз сама по себе не является «магическим щитом» от штрафа.Но если произошёл инцидент или пришла проверка, именно документы по защите информации показывают, что оператор: 🔵понимает, что защищает; 🔵определил актуальные угрозы; 🔵выбрал меры защиты осознанно; 🔵может обосновать архитектурные и организационные решения. И наоборот: формальная или устаревшая Модель угроз усугубляет положение оператора и показывает РКН, что защиты, как таковой, нет. На практикуме «Модель угроз безопасности информации: от теории к практике» мы разберём, как подготовить документ и защиту, которые выдерживают любые проверки. 👉 ЗАРЕГИСТРИРОВАТЬСЯ 👈

МОДЕЛЬ УГРОЗ В 2026: ГЛАВНОЕ Если вы обрабатываете персональные данные, то при проверке регулятор спросит у вас не только полный пакет ОРД, но и проектную документацию: 🔵модель угроз 🔵техническое задание 🔵технический проект Закон №152-ФЗ говорит, что безопасность ПДн достигается, в том числе, определением угроз безопасности персональных данных при их обработке в ИСПДн. Нет грамотной Модели угроз — нет нормального обоснования системы защиты. ⁉️Что будет, если не делать Модель угроз? Проблемы начинаются, когда: 🔴нужно пройти согласование 🔴приходит проверка и нужно объяснить, почему выбраны именно такие меры защиты 🔴проводится аттестация 🔴меняется архитектура 🔴появляется инцидент При этом проверяют не сам факт наличия файла с названием «Модель угроз». Проверяют логику и соответствие реальной защиты с угрозами в документе.

🎙 За неделю 🔰 6 млн рублей — столько может стоить один веб-инцидент крупному бизнесу Злоумышленники все чаще идут не в массовые атаки, а в точечный доступ к базам данных, корпоративным порталам и файловым хранилищам. Основные потери складываются из простоя, расследования и восстановления инфраструктуры после атаки. 🔰 Рынок Рунета вырос до 38,4 трлн рублей В 2025 году экономика Рунета выросла на 28,1%, но его рост замедляется и рынок постепенно подходит к более зрелой стадии. Теперь компаниям важнее не просто наращивать цифровые сервисы, а повышать их эффективность, удерживать аудиторию и контролировать стоимость развития. 🔰 С 27 мая изменятся правила параллельного импорта компьютерной техники Минпромторг исключил из перечня параллельного импорта часть компьютеров, ноутбуков и накопителей ряда зарубежных брендов. Для компаний это значит, что закупки техники могут стать менее предсказуемыми: стоит заранее проверять доступность оборудования, сроки поставок и возможные альтернативы.