⚙️ Fio (Flexible I/O Tester)
— мощная утилита для бенчмаркинга и стресс-тестирования систем хранения. Она стала стандартом для измерения реальной производительности дисков, SSD и массивов хранения.

✔️ Что умеет?

— Тестирование различных паттернов доступа (seq/random read/write)
— Поддержка синхронных и асинхронных операций ввода-вывода
— Работа с разными блочными размерами и глубиной очереди
— Эмуляция реальных рабочих нагрузок (базы данных, файловые серверы)
— Детальная статистика по задержкам и пропускной способности

✔️ Ключевые параметры:

--rw: режим операции (read, write, randread, randwrite, randrw)
--bs: размер блока (например, 4k, 1M)
--size: общий объем данных для операции
--runtime: длительность теста в секундах
--numjobs: количество параллельных задач
--ioengine: механизм I/O (libaio, sync, io_uring)
--filename: файл или устройство для тестирования

✔️ Основное использование:

Базовый тест последовательной записи:

fio --name=seq_write --rw=write --bs=1M --size=1G --filename=./testfile

Тест случайного чтения (4K, типично для БД):

fio --name=rand_read --rw=randread --bs=4k --size=1G --filename=./testfile

Многопоточный тест с глубиной очереди:

fio --name=multithread --rw=randrw --bs=4k --numjobs=4 --iodepth=32 --size=1G --filename=./testfile --group_reporting

✔️ Ключевые метрики в отчёте:

— BW (Bandwidth) — пропускная способность (MB/s)
— IOPS — операции ввода-вывода в секунду
— latency — задержки (min, max, avg, 95th percentile)
— slat/clat — задержки на уровне системы и устройства

Вместо расплывчатого значения «диск медленный» fio показывает конкретные цифры: скажем, 1500 IOPS при random read 4K с задержкой 15 ms. По этим данным уже можно предметно искать проблемы в хранилище и сравнивать производительность разных систем.

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

🤓 Высоконагруженные приложения. Программирование, масштабирование, поддержка

Подробное руководство о том, как проектировать и развивать системы, работающие с большими объёмами данных: от выбора моделей и хранилищ до надёжной распределённой архитектуры.

🔎 Рассматривается:
— что такое data-intensive приложения и базовые требования к надёжности, масштабируемости и сопровождаемости;
— модели и хранение данных: реляционные, документные, графовые БД, внутреннее устройство движков, индексы, журналы, структуры данных вроде B-деревьев и LSM-деревьев;
— распределённые системы: репликация, шардирование, транзакции, согласованность, консенсус и компромиссы CAP/PACELC;
— обработка данных: batch- и stream-подходы, события и лог, конвейеры на базе Hadoop, Spark, Kafka, Flink;
— архитектурные решения: как трезво оценивать инструменты, читать документацию и строить системы, устойчивые к росту нагрузки и сбоям.

Полезно бэкенд-разработчикам, инженерам данных, архитекторам, DevOps- и платформенным командам, тимлидам и техническим руководителям, которые принимают решения о том, какие БД, брокеры и пайплайны данных использовать и как связать всё это в цельную систему.

Автор:
Мартин Клеппман.
Издательство:
СПб.: Питер, 2018. серия «Бестселлеры O’Reilly».

#книги

🦩 Argo CD или Flux?

Можно не выбирать, а использовать лучшее из двух решений!

➡️ Flamingo (Flux Subsystem for Argo)

Это пропатченный образ Argo CD, в котором под капотом работает Flux, а интерфейс и модель работы остаются на стороне Argo CD.

В этой связке Argo CD остаётся точкой входа и наблюдения за состоянием, а Flux отвечает за синхронизацию манифестов с кластером.

🟣 Что даёт такой подход инженерам:

— использование HelmRelease из Flux с визуализацией и управлением через Argo CD;

— поддержка OCI Repository и других возможностей, доступных только во Flux;

— интеграция Weave GitOps Terraform Controller — Terraform-вызовы становятся частью единой GitOps-цепочки;

— доступ к Flux-ресурсам (Kustomization, HelmRelease, Source и др.) напрямую из Argo CD, без переключения между несколькими инструментами.

🟣 Когда имеет смысл использовать Flamingo:

— инфраструктура уже управляется через Argo CD, но требуется функциональность Flux;

— нежелательно вводить отдельный дашборд ради HelmRelease, OCI или Terraform-контроллера;

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

#полезное

🤯 «Нас взломали!
На главной странице сайта висит реклама онлайн-казино. Подскажи что делать?»

Такое сообщение прилетело в личку одному нашему сотруднику отдела ИБ.

Безопасник зашел на сайт и сразу обнаружил проблему:
страница входа в админку висит в открытом доступе.

🤦‍♂️ Учётку просто забрутфорсили!

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

А ваши админки спрятаны?

P.S.👋С понедельником

⚠️ Типы атак на пароли

🔴 Атака на автозаполнение браузера (Browser Autofill Exploit)

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

🔴 Атака перебором / грубая сила (Brute Force Attack)

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

🔴 Атака повторным использованием учётных данных (Credential Stuffing)

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

🔴 Словарная атака (Dictionary Attack)

— подбор паролей по заранее подготовленному словарю распространённых слов и типовых комбинаций.

🔴 Атака на коллизии хэша (Hash Collision Attack)

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

🔴 Кейлоггинг (Keylogging)

— скрытая запись нажатий клавиш для перехвата пароля в момент ввода.

🔴 Атака посредника (Man-in-the-Middle Attack)

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

🔴 «Распыление» паролей (Password Spraying)

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

🔴 Фишинговая атака (Phishing Attack)

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

🔴 Атака с использованием радужных таблиц (Rainbow Table Attack)

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

🔴 Подсматривание через плечо (Shoulder Surfing)

— наблюдение за пользователем при вводе пароля визуально или с помощью камер.

🔴 Социальная инженерия (Social Engineering)

— манипуляции и обман, чтобы человек добровольно раскрыл пароль или другие конфиденциальные данные.

#проИБ #полезное

🛡 Четыре слоя защиты конфиденциальных данных

Конфиденциальные данные — это не только ПДн.
Под защитой — финансовая информация (счета, карты, отчёты), медицинские сведения, интеллектуальная собственность (чертежи, код, проекты), данные об обучении и работе, юридические документы и любые другие данные, за которыми готовы охотиться киберпреступники.

➡️ Шифрование и управление ключами

HTTPS по умолчанию, пароли только в виде хеша + salt, ключи — в KMS с раздельными ролями (заявитель, менеджер, аудитор).

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

➡️ Десенсибилизация данных
Анонимизация, маскирование, псевдонимизация — убираем прямые идентификаторы и разделяем пользовательские данные и ключи.

🟢 Помогает, когда:
— делимся данными с подрядчиками и внешними командами;
— даём аналитикам доступ к данным без «живых» ПДн.

➡️ Минимальные права доступа (RBAC)

Роли заданы, доступ выдаётся по принципу минимально необходимого, а не «на всякий случай».

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

➡️ Управление жизненным циклом данных

От заявки на доступ до продакшена: на dev/test — временные расширенные права, после запуска — пересмотр и отзыв.

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

#полезное

🪙 Кейс: Защита онлайн-сервиса от кибератак с помощью WAF CORTEL

Цель — сохранить непрерывность работы финансового сервиса и защитить его от целенаправленных сложных атак.

📞 Задача

— Обеспечить стабильную работу высоконагруженного веб-сервиса в режиме 24×7 без простоев.
— Усилить базовую защиту от DDoS для отражения сложных, целевых атак на веб-приложение.
— Минимизировать риски утечки персональных данных клиентов и регуляторных претензий.
— Внедрить решение без закупки «железа» и развёртывания собственной инфраструктуры.

⭐️ Этапы реализации

— Проанализировали текущий уровень защиты и зафиксировали рост интенсивности и длительности атак на сервис.
— Подключили облачную защиту от DDoS L7 и модуль облачного WAF.
— Провели пилотный период, отработали ложные срабатывания и утвердили рабочие профили безопасности.
— Организовали круглосуточный мониторинг, поддержку и регламенты взаимодействия с технической командой клиента.

🚩 Результат

— 0 минут простоя бизнес-критичных сервисов из-за кибератак.
— 100% доступность сервиса для легитимных пользователей даже в периоды атак.
— Усиленная защита от целевых и сложных атак на веб-приложения без увеличения собственной ИТ-инфраструктуры.
— SLA на сервис защиты и оперативное расширение функциональности по запросу заказчика.
— Персональный менеджер и техподдержка 24×7, быстрые реакции на инциденты и изменения в профиле угроз.

«После внедрения WAF мы стали увереннее в устойчивости сервиса: атаки не приводят к простоям, а риски для клиентов и бизнеса контролируемы», — директор по ИБ ВебЗайм.

➡️ Подробнее о проекте читайте здесь.

➡️ О защите веб-приложений — здесь.

#изПрактик

🎙 Вебинар про инфраструктуру и безопасное размещение ИСПДн

За последние месяцы всё чаще сталкиваемся с вопросами про размещение ИСПДн:
что можно, что нельзя, где проходит граница ответственности, если вы отдаёте данные наружу, как проходят проверки и почему у одних компаний всё запускается за неделю, а у других — превращается в бесконечный проект.

Поэтому делаем открытый вебинар, где спокойно и по делу разберём всё, что важно знать перед построением архитекруты или миграцией в облако под ФЗ-152.

🗓 Когда:
3 декабря
11:00 по МСК

🎙 О чём поговорим:
— Когда можно использовать облако для ИСПДн.
— Что такое аттестованный ЦОД и почему это важно.
— Как распределяются зоны ответственности.
— Типовые ошибки при организации инфраструктуры.
— Как проходит аттестация ИС в облаке.
— Какие документы нужны между сторонами, чтобы избежать штрафов и переделок.
— Как выбрать решение: реальные примеры и ключевые отличия.
— Как построить защиту с нуля: аудит, документы, модель угроз, ТЗ, проект, аттестация.
— Практические кейсы.

Ссылка на регистрацию тут.

Если тема актуальна — не пропустите 😊

🛡💻 Security Context в Kubernetes: контроль прав подов и контейнеров

Набор настроек, определяющих права доступа и ограничения для Pod и Container.

Эти настройки реализуют принцип наименьших привилегий и предотвращают несанкционированный доступ.

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

— Ограничить права контейнеров (принцип наименьших привилегий)
— Предотвратить доступ к ресурсам узла
— Соответствовать требованиям безопасности и compliance
— Защититься от escape-атаки из контейнера

💬 Основные настройки

На уровне Pod:

apiVersion: v1
kind: Pod
metadata:
  name: security-context-demo
spec:
  securityContext:
    runAsNonRoot: true    # Запрет запуска от root
    runAsUser: 1000       # UID для запуска
    runAsGroup: 3000      # GID для запуска  
    fsGroup: 2000         # GID для томов
  containers:
  - name: sec-ctx-demo
    image: busybox
    command: [ "sh", "-c", "sleep 1h" ]

На уровне Container:

containers:
- name: sec-ctx-demo
  image: nginx
  securityContext:
    allowPrivilegeEscalation: false  # Запрет повышения привилегий
    capabilities:
      drop: ["ALL"]                  # Удаляем все capabilities
      add: ["NET_BIND_SERVICE"]      # Добавляем только нужные
    readOnlyRootFilesystem: true     # ФС только для чтения
    seccompProfile:
      type: RuntimeDefault           # Стандартный seccomp профиль

💬 Ключевые параметры безопасности:

— runAsNonRoot — гарантирует не-root выполнение
— readOnlyRootFilesystem — защита от модификации системы
— allowPrivilegeEscalation — блокировка повышения прав
— capabilities — тонкий контроль Linux capabilities
— seccompProfile — фильтрация системных вызовов

💬 Security Context — это базовый инструмент для security-in-depth в Kubernetes. Он не заменяет сетевые политики и Pod Security Standards, но создаёт фундамент для безопасной работы приложений.

Подробнее про Pod Security Standards и конфигурации Security Context для подов или контейнеров в официальной документации kubernetes.

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

🪖 Безопасность Kubernetes

Подборка инструментов

💬 kube-bench
— инструмент для проверки кластера Kubernetes на соответствие стандартам CIS Benchmark.

💬 Kyverno
— native-инструмент для управления политиками безопасности Kubernetes без необходимости изучения Rego.

💬 Sigstore
— набор инструментов для безопасной поставки ПО, включая подпись образов, прозрачный журнал и верификацию.

💬 Falco
— система runtime-безопасности для детекции аномального поведения в контейнерах и хостах.

💬 Checkov
— статический анализатор для инфраструктуры как код, проверяющий конфигурации Kubernetes, Terraform и CloudFormation на безопасность.

#полезное

🛡 Fail2ban — система предотвращения атак brute-force, которая мониторит логи служб и автоматически блокирует подозрительные IP-адреса.

🔵 Как работает

— Мониторит логи служб (SSH, Apache, Nginx) в реальном времени
— Обнаруживает подозрительные паттерны (многократные неудачные попытки)
— Добавляет временные блокировки в iptables/nftables
— Автоматически разблокирует IP после истечения таймаута

🔵 Основное использование

Установка:

# Ubuntu/Debian
sudo apt install fail2ban

# CentOS/RHEL
sudo dnf install fail2ban

Базовые команды:

sudo fail2ban-client status      # статус блокировок
sudo fail2ban-client reload      # перезагрузка конфигурации

Конфигурация для SSH (/etc/fail2ban/jail.local):

enabled = true
port = ssh
logpath = /var/log/auth.log
maxretry = 3
bantime = 3600
findtime = 600

Параметры: 3 попытки за 10 минут → блокировка на 1 час

Пример фильтра для защиты от сканирования Nginx:

[nginx-404]
enabled = true
port = http,https
logpath = /var/log/nginx/access.log
maxretry = 5
findtime = 300

📊 Мониторинг и управление

# Просмотр заблокированных IP
sudo fail2ban-client status sshd

# Разблокировка конкретного IP
sudo fail2ban-client set sshd unbanip 192.168.1.100

# Блокировка конкретного IP
sudo fail2ban-client set sshd banip 192.168.1.120

🔵 Особенности

— Поддерживает различные бэкенды (iptables, nftables, firewalld)
— Гибкая настройка фильтров через регулярные выражения
— Возможность отправки уведомлений по email
— Интеграция с systemd journal

Fail2ban — первый рубеж обороны для любого интернет-экспонированного сервиса. Не заменяет комплексные системы безопасности, но эффективно отсекает базовые атаки перебором.

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

🛡 Администрирование системы защиты SELinux

Практическое руководство по тому, как превратить SELinux из «мешающего демона» в управляемый и предсказуемый инструмент защиты Linux-систем — от базовой настройки до тонкой доработки политик под вашу инфраструктуру.

🔎 Рассматривается:

— место SELinux среди стандартных механизмов безопасности Linux и его ключевые преимущества;
— базовая архитектура и включение SELinux, разбор логов и диагностика типичных ошибок;
— настройка и тюнинг политик доступа для файлов, процессов и сетевых сервисов;
— защита виртуализации и контейнеров (libvirt/sVirt, Docker) на практике;
— как писать и дорабатывать свои политики SELinux вместо того, чтобы отключать его.

Полезно администраторам Linux, инженерам эксплуатации, DevOps- и инфраструктурным командам, специалистам по информационной безопасности и архитекторам, которым важно системно повысить защищенность Linux-инфраструктуры и при этом сохранить устойчивость бизнес-сервисов.

Автор:
Свен Вермейлен.
Издательство:
ДМК Пресс, рус. изд., Москва, 2020.

#книги

🔎 Kubesec — утилита для Kubernetes, которая проверяет YAML-манифесты на рискованные настройки безопасности и возвращает score + список сработавших правил.

Инструмент помогает быстро находить небезопасные параметры (capabilities, root, privileged, отсутствие securityContext и т.д.) ещё до деплоя — локально или в CI/CD.

⚙️ Основной функционал:

— анализ манифестов (Deployment/Pod/DaemonSet и др.) с оценкой риска (score)
— детальный JSON-отчёт: что именно не так и почему
— просмотр правил оценки (за что начисляются/снимаются баллы)
— режим HTTP-сервиса: можно отправлять YAML на / scan
— интеграция в CI/CD: возможность блокировать сборку при низком score
— есть публичный endpoint, но чувствительные манифесты лучше не отправлять наружу (поднимать локально)

👉 Git
#полезное

🕵️‍♀️ С Наступающим Международным Днем Защиты Информации!

В преддверии такого важного дня напомним о предстоящем вебинаре 😉

📣Вероника Нечаева расскажет
ПРО ИНФРАСТРУКТУРУ для ИСПДн.

🎙 Поговорим:

— Когда можно использовать облако для ИСПДн.
— Что такое аттестованный ЦОД и почему это важно.
— Как распределяются зоны ответственности.
— Типовые ошибки при организации инфраструктуры.
— Как проходит аттестация ИС в облаке.
— Какие документы нужны между сторонами, чтобы избежать штрафов и переделок.
— Как выбрать решение: реальные примеры и ключевые отличия.
— Как построить защиту с нуля: аудит, документы, модель угроз, ТЗ, проект, аттестация.
— Практические кейсы.

⏰ 3 декабря в 11:00 по Мск

✏️ Зарегистрироваться

🔑 Шпаргалка: Session-cookie, JWT, SSO и OAuth 2.0

Наглядная схема от ByteByteGo: как работает вход через сессию и токены, где браузер хранит cookie, как устроен JWT, как SSO объединяет вход для нескольких сервисов и как OAuth 2.0 выдаёт доступ по токенам.

📍 WWW-Authenticate (логин/пароль)
Браузер отправляет логин и пароль на сервер, сервер проверяет и пускает в приложение. Базовая точка старта, но дальше нужно решить, как “держать” авторизацию между запросами.

📍 Session-cookie
Сервер создаёт сессию и хранит её у себя, а браузеру отдаёт cookie с Session ID. На каждом запросе браузер приносит cookie, сервер по Session ID находит сессию и понимает, кто пришёл.

📍 Token
Клиент хранит токен (часто тоже в cookie/хранилище приложения) и передаёт его в запросах. Сервер проверяет токен сам или через отдельный Token Validation Service и принимает решение о доступе.

📍 JWT
Стандартизированный формат токенов с цифровой подписью. Содержит все необходимые данные и подпись для проверки подлинности. Самодостаточен — не требует хранения состояния на сервере.

📍 SSO
Единый вход через центральный сервис аутентификации (CAS/SSO): пользователь проходит авторизацию один раз, а затем получает доступ к нескольким приложениям через доверие к этому центру.

📍 OAuth 2.0
Описывает, как выдавать ограниченный доступ к данным между сервисами без передачи паролей и выбирать подходящий flow под сценарий:

— Authorization Code — браузер + сервер (самый распространённый для веба)
— Client Credentials — сервер-сервер (без пользователя)
— Implicit Grant — исторический вариант для браузера
— Password Grant — устаревший сценарий

#полезное

🎧 Как выбрать площадку для ПДн?

ИСПДн — это любая система, в которой обрабатываются персональные данные: клиентов и сотрудников.

Контур состоит из приложения, базы данных, интеграции, доступов, резервных копий, логов и журналов событий и т.д.

➡️ При выборе площадки важно понимать не только место размещения, но и зоны ответственности.

📍 Вариант 1.
On-Premise (всё на стороне организации)

Инфраструктура и система находятся в периметре организации.

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

* подход даёт максимальный уровень контроля, но требует собственной экспертизы и постоянных затрат на поддержку и развитие.

📍 Вариант 2.
Площадка провайдера (ЦОД / выделенные ресурсы / colocation)

Размещение происходит на внешней площадке, но ИСПДн как система остаётся в зоне управления организации.

💬 Провайдер, как правило, отвечает за площадку:

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

💬 Организация отвечает за систему и данные:

— конфигурацию ИСПДн, администрирование, обновления;
— доступы, политики безопасности, сегментацию;
— резервные копии, журналы, контроль изменений;
— реагирование на инциденты и комплект документов.

* провайдер отвечает за площадку и её доступность, а за безопасность, настройки и эксплуатацию ИСПДн — отвечает организация.

📍 Вариант 3.
Облако провайдера (IaaS / PaaS)

Провайдер предоставляет инфраструктуру и, в зависимости от модели, часть платформенных сервисов. При этом ответственность за выполнение требований к защите ПДн и корректность настроек ИСПДн не «переезжает» в облако автоматически.

💬 Провайдер отвечает за свой слой:

— вычисления/хранилища/сети как сервис;
— доступность и работоспособность платформы на своей стороне;
— физическую среду размещения инфраструктуры.

💬 Организация отвечает за всё, что связано с данными и управлением ИСПДн от уровня ВМ:

— персональные данные и правила их обработки;
— пользователей и права доступа;
— сетевую конфигурацию и контуры доступа (в рамках облака);
— настройку логирования и резервного копирования (даже если это сервис провайдера — политика и контроль остаются на стороне организации);
— процессы реагирования и комплект документов между сторонами.

* в облаке провайдер отвечает за инфраструктурный слой и предоставленные механизмы защиты в пределах сервиса, а организация — за данные, настройки и соблюдение требований.

🟢 Хотите разобраться подробнее?

⏰ Приходите на открытый вебинар 3 декабря в 11:00 МСК.

Вероника Нечаева расскажет про облако и аттестованный ЦОД для ИСПДн, границы ответственности, аттестацию в облаке, документы между сторонами, типовые ошибки и кейсы.

➡️ Регистрация

🟡 Wazuh: мониторинг безопасности (SIEM/XDR)

Это open-source платформа для мониторинга безопасности инфраструктуры: собирает телеметрию и логи с серверов/ВМ/контейнеров, связывает события в цепочки, поднимает алерты и дает единое окно для расследований в дашборде.

Инструмент помогает навести порядок в событиях ИБ: от контроля изменений на хостах до обнаружения уязвимостей и базовых сценариев реагирования.

⚙️ Основной функционал:

— сбор логов и событий с хостов и сервисов, нормализация
— правила/корреляции, уровни критичности, оповещения и сортировка и приоритизации найденных уязвимостей
— контроль изменений: файлы, конфиги, ключевые директории (FIM)
— инвентаризация активов и ПО + сопоставление с уязвимостями
— проверки конфигураций и аудит под политики/требования
— реагирование по условиям (active response): блокировки/скрипты/автодействия
— веб-дашборды, поиск по событиям, отчёты и видимость по средам/сегментам

👉 Git
#полезное

⏳ 24 часа до вебинара

🕒 Уже завтра, 3 декабря, в 11:00 (МСК) Вероника Нечаева расскажет о безопасном размещении ИСПДн в соответствии с 152-ФЗ.


🎁 Бонус учасникам
— чек-лист выбора защищённого облака и проверки провайдера по ФЗ-152;
— персональная подборка материалов и методических рекомендаций;
— чек-лист из 36 пунктов подготовки к проверке РКН;
— возможность персональной консультации и разбора вашей архитектуры после вебинара.

🔗 Регистрация

🔐 RBAC в Kubernetes: best practices безопасности

Role-Based Access Control — стандартный механизм управления доступом в Kubernetes, обеспечивающий принцип наименьших привилегий и контроль над операциями в кластере.

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

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

✅ Ключевые принципы

🔘Минимальные привилегии:

# минимальные необходимые права
apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRole
metadata:
  name: pod-reader
rules:
- apiGroups: [""]
  resources: ["pods"]
  verbs: ["get", "list", "watch"]

🔘Разделение по namespace:

# Доступ только в конкретном namespace
apiVersion: rbac.authorization.k8s.io/v1
kind: Role
metadata:
  namespace: development
  name: deployment-manager
rules:
- apiGroups: ["apps"]
  resources: ["deployments"]
  verbs: ["get", "list", "create", "update", "delete"]

✅ Критически важные практики

🔘Ограничение сервисных аккаунтов:

# Автоматическое монтирование токена только когда нужно
apiVersion: v1
kind: ServiceAccount
metadata:
  name: my-app
automountServiceAccountToken: false

🔘 Регулярный аудит RBAC:

# Проверка прав текущего пользователя
kubectl auth can-i list secrets --all-namespaces

# Аудит всех ClusterRole и Role
kubectl get clusterroles,roles --all-namespaces -o yaml

🔘 Избегание wildcard-прав:

# ОПАСНО:
verbs: ["*"]
resources: ["*"]

# БЕЗОПАСНО:
verbs: ["get", "list"]
resources: ["pods", "services"]

👀 RBAC — фундамент безопасности Kubernetes. Правильная настройка предотвращает 90% инцидентов, связанных с несанкционированным доступом.

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

🤩 Через 30 минут откладываем все дела, наливаем вкусный чай и готовимся получать много полезной и важной информации от Вероники Нечаевой.

🎙 В 11:00 по Мск вебинар про инфраструктуру и безопасное размещение ИСПДн

➡️ Регистрация

🔼 Подборка по ПДН:

🔵 Административная ответственность и штрафы

🔵 Вся Нормативно-правовая база СЗ ПДн

🔵 Перечень документов по защите ПДн

🔵 Как создать политику по обработке ПДн?

🔵 Где конкретно в нормативно правовой базе написано про СЗ ПДн?

🔵 Реализация мер защиты каждого из УЗ ПДн

🔵 Что делать если часть СЗИ уже есть, но сертификата у них нет?

🔵 Как вообще защищать ПДН?

🔵 Роадмэп защиты ПДН с нуля

🔵 Как определять уровень защищённости ПДН

🔵 Как подтвердить выполнение требований

🔵 Аттестация информационной системы по требованиям ФСТЭК

🔵 Обработка и защита персональных данных: кто ответственный?

🔵 Тильда и персональные данные

🔵 Как выполнить требования к уровню защищённости ИСПДн

🔵 Проверки по защите персональных данных: Роскомнадзор, ФСБ, ФСТЭК

🔵 Отличие соглашения о поручении на обработку персональных данных от передачи ПДн

🔵 Трансграничная передача ПДн: как выполнить требования

🔵 Как подобрать нужный тип и класс сертифицированных СЗИ

🔵 Отличия 17 и 21 приказов ФСТЭК

🔵 Как выбрать класс СКЗИ

🔵 Как сообщить в Роскомнадзор об утечке персданных?

🔵 Как определить класс защищённости ГИС?

🔵 Как составить модель угроз для ИСПДн
🔵 Как составить модель угроз: подробно о методике ФСТЭК

🔵 Защита обработки персональных данных в облаке по 152-ФЗ

🔵 Как провести аудит защиты персональных данных: пошаговая инструкция