Архитектура: DevOps "умер"? Встречаем Platform Engineering

Если вы освоили Ansible и Kubernetes, вы — DevOps. Но какой следующий шаг?

В англоязычном IT все говорят о Platform Engineering (Инженерия Платформ).

DevOps: Строит "двигатель" (CI/CD, Kubernetes, Terraform).

Platform Engineer: Строит "автомобиль" (всю платформу) и отдает разработчику только ключ зажигания и руль.

Суть: Platform Engineering создает Internal Developer Platform (IDP) — внутренний продукт (как "Heroku" или "Vercel" внутри вашей компании).

Разработчик не знает про kubectl apply, helm или Ansible. Он просто пишет в config.yml: app: my-app, replicas: 3, deploy: true -> нажимает git push -> и его приложение в "проде".

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

#architect #devops #sre #platformengineering #career #стратегия #гайд

Проект на выходные: Запускаем Windows VM... внутри Kubernetes. Знакомство с KubeVirt

Проблема: Ваша компания перешла на Kubernetes. 90% сервисов — контейнеры. Но у вас остался "старый, добрый" монолит на Windows Server (например, 1С или старый IIS-апп), который нельзя контейнеризировать.

Решение: Не держать "зоопарк" (Kubernetes + Proxmox/VMware). А запустить эту VM внутри Kubernetes.

KubeVirt — это проект CNCF, который позволяет управлять Виртуальными Машинами (VM) так же, как и контейнерами.

Как это работает: Вы пишете YAML-манифест так же, как для Deployment, но с типом VirtualMachineInstance.
YAML

apiVersion: kubevirt.io/v1
kind: VirtualMachine
metadata:
  name: my-windows-vm
spec:
  template:
    spec:
      domain:
        devices:
          disks:
            - name: containerdisk
              disk:
                bus: virtio
        # ...и т.д.

Взгляд архитектора: Это "Единый Оркестратор". У вас ОДИН инструмент (kubectl) и ОДНА "панель управления" (Kubernetes) для всех ваших нагрузок — и современных (контейнеры), и "легаси" (VM). Это упрощает сеть, хранилище и мониторинг.

#linux #kubernetes #kubevirt #devops #virtualization #architect #гайд

RKN получает "root-доступ" к Рунету. Что это меняет для инженеров?

Новость, которая напрямую влияет на нашу работу. С 1 марта 2026 года Роскомнадзор получает беспрецедентные права на управление российским сегментом интернета.

Если коротко, РКН сможет:

Отдавать обязательные команды операторам связи.
Перенаправлять трафик через свои тех. средства (ТСPU).
Менять маршруты передачи данных.
В случае "угрозы" (критерии неясны) брать ручное управление всей сетью.

Формально это объясняется "устойчивостью и безопасностью". Фактически — это полная централизация управления сетью.

Взгляд архитектора: Что это значит для нас?

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

"Черный ящик" в маршрутизации: traceroute и mtr могут стать менее информативными. Мы получаем "черный ящик" (ТСPU) в середине маршрута, который может резать, фильтровать и замедлять трафик. Диагностика проблем с "тормозами" до AWS или Azure станет в разы сложнее.

Хрупкая избыточность: Ваша отказоустойчивая схема с двумя разными ISP (например, "Ростелеком" и "Билайн") теряет смысл, если РКН в "ручном режиме" направит трафик обоих провайдеров через один и тот же "бутылочное горлышко".

Риск изоляции: Доступ к критически важным внешним ресурсам (GitHub, Docker Hub, PyPI, apt-репозитории) может быть ограничен в любой момент по щелчку, если их сочтут "опасными".

Новый DR-план: В наших Disaster Recovery планах должен появиться новый сценарий: "Полная изоляция Рунета". Что будет делать ваш бизнес, если внешние API и SaaS-сервисы (включая ваш Cloud) просто исчезнут на N часов/дней?

Это новый вызов для каждого, кто отвечает за uptime и availability. Мы вступаем в эру, где сетевая связность перестает быть данностью и становится управляемым риском.

#security #networking #architect #sre #devops #russia

Windows: Охота на "невидимых". Скрипт для поиска WMI-персистентности

Боль: Ваш EDR/антивирус молчит, но сервер "тормозит" и генерирует странный трафик. Вы не находите .exe или подозрительных служб. Вероятно, вы столкнулись с "бесфайловой" (Fileless) атакой.

Один из любимых методов хакеров — WMI Event Subscription. Злоумышленник "говорит" WMI: "Когда любой пользователь залогинится, пожалуйста, запусти этот powershell -enc ...". Это невидимая автозагрузка.

Реакция админа: Переустановить ОС.
Реакция архитектора: Найти и удалить подписку.

Этот PowerShell-скрипт (на CIM) сканирует "сердце" WMI (`root\subscription`) и показывает вам все активные WMI-подписки.

Код скрипта:
PowerShell

Write-Host "--- Начинаю поиск постоянных (Permanent) WMI-подписок ---" -ForegroundColor Cyan

# Мы ищем три компонента, из которых состоит атака:
# 1. __EventFilter: "За каким событием следить?" (e.g., "logon")
# 2. __EventConsumer: "Что запустить?" (e.g., "powershell.exe ...")
# 3. __FilterToConsumerBinding: "Как они связаны?"

$Namespace = "root\subscription"

Write-Host "`n[+] 1. Поиск Фильтров (__EventFilter):" -ForegroundColor Yellow
$Filters = Get-CimInstance -Namespace $Namespace -ClassName "__EventFilter"
$Filters | Select-Object Name, Query

Write-Host "`n[+] 2. Поиск 'Потребителей' (__EventConsumer):" -ForegroundColor Yellow
$Consumers = Get-CimInstance -Namespace $Namespace -ClassName "__EventConsumer"
$Consumers | Select-Object Name, __CLASS

Write-Host "`n[+] 3. Поиск Связей (Binding):" -ForegroundColor Yellow
$Bindings = Get-CimInstance -Namespace $Namespace -ClassName "__FilterToConsumerBinding"
$Bindings | Select-Object Filter, Consumer

Write-Host "`n--- Проверка завершена ---"
Write-Host "Задача: Вручную проверьте все, что не является 'Microsoft' или вашим ПО (e.g., 'Dell')."

Взгляд архитектора: Это — проактивный Threat Hunting. 99% админов никогда не заглядывают в WMI-подписки. Вы должны. Если вы видите здесь что-то "неродное", особенно CommandLineEventConsumer — вы, скорее всего, нашли активную угрозу.

#windows #powershell #security #threat_hunting #wmi #cybersecurity #скрипты #architect

AD: "Путь к Domain Admin". Аудит путей атаки с PowerShell

Боль: Вы запустили BloodHound и увидели 50 "красных" путей к правам Domain Admin. Вы в ужасе. Что делать дальше?

Реакция админа: "Закрою 1-2 самые очевидные дыры".
Реакция архитектора: Начать систематический аудит "Control Paths" (путей контроля).

Атака BloodHound — это не магия. Это злоупотребление "опасными" правами (ACL), которые вы сами раздали. Самые опасные — GenericAll , GenericWrite , WriteDacl .

Этот PowerShell-скрипт (на модуле ActiveDirectory ) — оборонительный BloodHound . Он найдет, кто имеет "опасные" права на ваш самый ценный объект — группу "Domain Admins".

Код скрипта:
PowerShell

Import-Module ActiveDirectory

Write-Host "--- Начинаю аудит 'опасных' ACL на группе 'Domain Admins' ---" -ForegroundColor Cyan

$DAMinGroupDN = (Get-ADGroup "Domain Admins").DistinguishedName
$ACLs = (Get-Acl "AD:$DAMinGroupDN").Access

# Список "смертельных" прав, которые дают полный контроль
$DangerousRights = @(
    "GenericAll",
    "GenericWrite",
    "WriteDacl",
    "WriteProperty",
    "WriteOwner"
)

# Ищем всех, у кого есть эти права, КРОМЕ "ожидаемых" (Админы, SYSTEM...)
$SuspiciousACLs = $ACLs | Where-Object {
    ($_.ActiveDirectoryRights -in $DangerousRights) -and
    ($_.IdentityReference -notin @("NT AUTHORITY\SYSTEM", "BUILTIN\Administrators", "CORP\Domain Admins"))
}

if ($SuspiciousACLs.Count -gt 0) {
    Write-Host "`n[!!!] ОБНАРУЖЕНЫ КРИТИЧЕСКИЕ ПУТИ АТАКИ:" -ForegroundColor Red
    $SuspiciousACLs | Format-Table IdentityReference, ActiveDirectoryRights, AccessControlType
} else {
    Write-Host "`n[OK] 'Лишних' прав на группе Domain Admins не найдено." -ForegroundColor Green
}

Взгляд архитектора: Вы не "ищете" уязвимость. Вы валидируете вашу Admin Tier Model. Этот скрипт — ваш первый шаг к "очистке" AD-безопасности.

#windows #security #activedirectory #powershell #bloodhound #architect #скрипты #musthave

Windows: `Perfmon` — это не 'топ'. `ETW` — вот настоящий 'eBPF'

Боль: `Perfmon` (Системный монитор) показывает 100% I/O на диске, но не говорит, КАКОЙ процесс и КАКОЙ файл это вызвал. Вы "слепы".

Решение: ETW (Event Tracing for Windows) ETW — это "черный ящик" ядра Windows. Это самый низкоуровневый и производительный (почти 0% оверхеда) механизм трассировки всего: I/O, Registry, Network, CPU...

PerfView — это бесплатный инструмент от Microsoft для "чтения" ETW.

Как найти "пожирателя" I/O (на пальцах):

1. Скачайте PerfView.exe (один файл, не требует установки).

2. Запустите сбор:
* PerfView.exe collect
* Оставьте на 30-60 секунд, пока идет "торможение".
* Нажмите "Stop Collection".

3.Анализируйте *.etl.zip файл:
* Откройте файл.
* Найдите "File I/O".
* БИНГО: Вы видите таблицу, где Process Name (sqlservr.exe), File Name (C:\DB\data.mdf) и IO_Time (ms) (90% всего времени).

Взгляд архитектора: Sysmon — это "что случилось". Perfmon — это "как сильно". ETW / PerfView — это "ПОЧЕМУ". Это ваш "микроскоп" для SRE-диагностики, который дает неопровержимые данные о том, какая функция в каком процессе "убивает" вашу систему.

#windows #sre #performance #diagnostics #etw #perfview #architect #гайд

AD Security: Kerberoasting — это "вход". Pass-the-Ticket — это "движение"

Боль: Мы уже говорили, как хакеры "вытаскивают" хэши сервисных учеток (Kerberoasting). Но что они делают дальше?

Реакция админа: "Я просто сменю пароль уязвимой учетке SQL-Service". Реакция архитектора: "Я пойму, куда он мог с ней пойти, и закрою этот путь".

Pass-the-Ticket (PtT) — это техника Lateral Movement (бокового смещения).

Как это работает:
1. Атакующий (через Kerberoasting) получил Kerberos-билет (TGS) для службы SQL-Service. Пароль ему не нужен.
2. Он "инжектит" этот билет в свою сессию (mimikatz, Rubeus).
3. Теперь он — SQL-Service.
4. Он смотрит, куда SQL-Service имеет права (например, SQL-Service — локальный админ на FILE-SRV-01).
5. Он "прыгает" на FILE-SRV-01 (через PsExec или WMI) с правами SQL-Service и повторяет цикл.

Взгляд архитектора: Это доказывает, почему Admin Tier Model и Принцип Наименьших Привилегий (PoLP) — это не "бюрократия", а фундамент защиты.
* Ваша SQL-Service (Tier 1) не должна быть админом на FILE-SRV-01 (Tier 1).
* Ваша HelpDesk (Tier 2) не должна иметь прав на серверах (Tier 1).

Компрометация одной учетки не должна приводить к компрометации всего домена.

#security #windows #activedirectory #kerberos #cybersecurity #architect #гайд

Windows (Security): JEA — "PowerShell-тюрьма" для админов

Боль: Вам нужно дать HelpDesk-у право только перезапускать службу MyWebApp на 10 серверах.
Реакция админа: Дать ему RDP и права локального админа. (Итог: он "случайно" перезагружает весь сервер).
Реакция архитектора: Внедрить JEA (Just Enough Administration).

JEA — это не "права". Это "PowerShell-бункер".
Вы создаете специальный, изолированный PowerShell-endpoint (конечную точку), к которому подключается админ.

Как это работает:

1. Вы декларативно описываете "роль" в файле .psrc (Role Capability).
2. В этом файле вы разрешаете ТОЛЬКО одну команду: Restart-Service -Name "MyWebApp".
3. Админ подключается: Enter-PSSession -ComputerName SRV-01 -ConfigurationName JEA_Endpoint
4. Результат: Он может выполнить Restart-Service, но если он наберет Get-Process или reboot — он получит "команда не найдена".

Взгляд архитектора: Это абсолютный Zero Trust. Вы не "даете права" на сервер. Вы предоставляете безопасное API к нему. Это "золотой стандарт" для делегирования полномочий, который делает атаки Lateral Movement практически невозможными.

#windows #security #powershell #jea #zerotrust #architect #гайд #musthave

Linux: htop врёт. Куда на самом деле уходит память? Вскрываем pmap

Боль: Вы запускаете htop. Он показывает: VIRT: 25.0G, RES: 500M. Вопрос: Куда "делись" 24.5 ГБ? Почему VIRT (виртуальная) такой огромный, а RES (физическая) — маленький?

Реакция админа: "Наверное, это кэш. Перезагружу".
Реакция SRE: "Я посмотрю карту памяти процесса".

pmap (Process Memory Map) — это "рентген" для процесса. Он показывает каждый регион памяти, который процесс "попросил" у ядра.

Как это читать:
1. Найдите PID (например, pidof java -> 1234).
2. Запустите pmap с флагом -x (расширенный):
Bash

pmap -x 1234

Что вы увидите:
*Сотни строк с .so файлами (это shared libraries — общие библиотеки).
* [ anon ]: Это "анонимная" память — то, что malloc() выделил в "куче" (heap). Если эта цифра растет — у вас 100% утечка памяти (memory leak).
* [ stack ]: Стек процесса.

"Убийца"-команда (показать итог):
Bash

# Показать только ИТОГО (Total)
pmap -x 1234 | tail -n 1
# Вывод: total ---- 25165824K

Бинго! Вот ваши 25 ГБ. Это не "утечка", а 1000+ .so-библиотек, которые "раздули" виртуальное адресное пространство.

Взгляд архитектора: Вы перестаете "гадать" по htop. Вы видите корень проблемы. pmap — это ваш микроскоп для диагностики утечек памяти и "раздутых" приложений.

#linux #sre #performance #diagnostics #pmap #команды #гайд #architect

Windows (Security): "Крепость" внутри AD. Внедряем Authentication Silos

Боль: Ваш Domain Admin залогинился на ноутбук HelpDesk ( Tier 2 ), чтобы "быстро что-то поправить".
Хакер, сидящий на этом ноутбуке, ворует его Kerberos-билет и через 5 минут захватывает Контроллер Домена (атака Pass-the-Ticket ).

Реакция админа: "Я больше так не буду".
Реакция архитектора: "Я сделаю так, чтобы этот билет был бесполезен".

Authentication Silos (Хранилища Аутентификации) — это ваш "ядерный бункер" внутри AD.
Это контейнер, который привязывает высокопривилегированные учетки (как Domain Admins ) только к высокопривилегированным хостам (как Domain Controllers ).

Как это работает:
1. Вы создаете "Silo" (Хранилище) и "Policy" (Политику).
2. Вы помещаете в "Silo" своих Domain Admins и свои Domain Controllers.
3. Kerberos (KDC) теперь выдает непередаваемые (non-forwardable) билеты. TGT (билет), выданный для Domain Admin'а, не может быть использован для доступа ни к чему, кроме хостов из этого же "Silo" (то есть, к другим DC).

Взгляд архитектора: Это реальное, техническое принуждение для вашей Admin Tier Model. Вы не "надеетесь", что админ не залогинится на ПК. Вы гарантируете, что если он это сделает, его украденный билет будет просто бесполезным мусором для хакера.

#windows #security #activedirectory #kerberos #zerotrust #architect #гайд #musthave

🛡️ Windows (Архитектура): "NTFS-права" мертвы. Будущее — это Dynamic Access Control (DAC)

Боль: У вас 50 файловых шар. Вам приходит задача: "Дать доступ к папке Finance_Reports только менеджерам из отдела Sales , которые находятся в Казахстане".

Реакция админа: Создать еще одну AD-группу KZ_Sales_Managers_Finance_Access и вручную добавить в нее 10 человек. (Через год в AD будет 5000 групп).

Реакция архитектора: Использовать Dynamic Access Control (DAC).

DAC (динамический контроль доступа) — это "умные" NTFS-права. Вы даете доступ не "пользователю", а "по правилу".

Как это работает:
1. Классификация: Вы "маркируете" файлы (через FSRM): file.Confidentiality = High.
2.Атрибуты: Вы используете существующие атрибуты AD: user.Department = "Sales", user.Country = "KZ".
3. Политика (в GPO): Вы пишете одно правило для папки:
* Allow: Read
* IF: (user.Department == "Sales")
* AND: (user.Country == "KZ")
* AND: (file.Confidentiality == "High")

Взгляд архитектора: Вы переходите от "управления 1000 групп" к "управлению 10 политиками". Это Policy as Code для данных.

#windows #security #activedirectory #dac #zerotrust #architect #гайд

🚀 Windows (Архитектура): "Split-Brain" DNS мертв. Встречаем Политики DNS

Боль: У вас есть сервис app.local, который должен резолвиться в 10.0.0.1 для внутренних клиентов (IT) и в 192.168.0.1 для всех остальных (Users).

Реакция админа (старая): Поднять два DNS-сервера (Split-Brain DNS), управлять двумя зонами, мучиться с репликацией.

Реакция архитектора: Использовать DNS Resolution Policies (в Windows Server 2016+). Это "умный" DNS, который отдает разные A-записи в зависимости от того, кто спрашивает.

План внедрения (на пальцах):

# 1. Определяем "зону" клиентов (например, IT-подсеть)
Add-DnsServerClientSubnet -Name "IT_Subnet" -IPv4Subnet "10.0.10.0/24"

# 2. Создаем политику: "Если запрос из IT_Subnet..."
Add-DnsServerQueryResolutionPolicy -Name "IT_Policy" -ClientSubnet "eq,IT_Subnet"

# 3. Добавляем A-запись, которая видна ТОЛЬКО этой политике
Add-DnsServerResourceRecord -ZoneName "app.local" -Name "www" -A -IPv4Address "10.0.0.1" -Policy "IT_Policy"

# 4. Добавляем A-запись "по умолчанию" (для всех остальных)
Add-DnsServerResourceRecord -ZoneName "app.local" -Name "www" -A -IPv4Address "192.168.0.1"

Готово. Теперь ваш DNS-сервер сам "маршрутизирует" ответы.

Взгляд архитектора: Вы переходите от управления железом (два сервера) к управлению кодом (Policy as Code). Это централизация, упрощение и основа для Geo-DNS и балансировки нагрузки на уровне DNS.

#windows #powershell #dns #networking #architect #гайд #musthave

🛡️ Windows (Security): Новое в Server 2025 — Защита LDAP по умолчанию

Боль: В 2025 году 90% AD-доменов до сих пор разрешают LDAP Simple Bind (простая привязка) — то есть, отправку паролей по LDAP (порт 389) в открытом тексте.

Реакция админа: "У меня внутренняя сеть, она доверенная". (Нет).
Реакция архитектора: "Весь трафик аутентификации должен быть зашифрован. Без исключений".

Microsoft меняет правила игры в Windows Server 2025.

Что нового:

1. LDAPS по умолчанию: LDAP-сервер больше не будет принимать Simple Bind (открытый текст), если соединение не зашифровано (через TLS/SSL, порт 636, или через StartTLS).

2. Шифрование Kerberos: Внедряется AES-SHA256/384, что делает Kerberos еще надежнее.

3. TLS 1.3: LDAP теперь поддерживает TLS 1.3 "из коробки".

Взгляд архитектора: Это "Security by Default" (Безопасность по умолчанию). Microsoft принудительно закрывает "дыры", которые админы игнорировали десятилетиями. Ваша задача — не ждать 2025 года. Запускайте LDP.exe, проверяйте свои DC на Simple Bind и внедряйте LDAPS (порт 636) уже вчера.

#windows #security #activedirectory #ldap #windowsserver #architect #гайд

🔬 Linux (SRE): Ваш Prometheus — "слепой". Встречаем Parca

Боль: Ваш Prometheus + Grafana показывают: "CPU spike at 14:30". И что? Вы знаете, что был всплеск, но вы не знаете, ПОЧЕМУ. Какая функция в вашем Python/Go/Rust-коде "съела" CPU?

Реакция админа: "Перезапущу pod, наверное, 'глюк'".
Реакция SRE: "Мне нужен непрерывный профилировщик".

Parca — это "Prometheus для профилирования". Он построен на eBPF и непрерывно (с почти нулевым оверхедом) сканирует CPU и память всех ваших процессов в системе.

Киллер-фича: Вы можете выбрать "спайк" CPU на Grafana, а затем "провалиться" в Parca и увидеть "Flame Graph" (огненный граф) — точную карту, показывающую, что function: process_payment() заняла 45% CPU в этот момент.

Взгляд архитектора: Вы переходите от "Мониторинга" (знать, что сломалось) к "Observability" (понимать, почему сломалось). Parca — это ваш "микроскоп", который находит "раковую опухоль" в коде, а не просто измеряет "температуру".

#linux #sre #ebpf #parca #observability #performance #architect #гайд

🛡️ Windows (Security): "Убить" Mimikatz. Включаем LSA Protection (PPL)

Боль: Хакер получил права админа на 1 сервере. Он запускает mimikatz.exe -> sekurlsa::logonpasswords -> и "вытаскивает" из памяти процесса lsass.exe все пароли/хэши, включая Domain Admin'а, который логинился туда 2 часа назад. Игра окончена.

Реакция админа: "Мой EDR/Антивирус поймает mimikatz". (А если нет?)
Реакция архитектора: "Я сделаю lsass.exe неприкосновенным".

LSA Protection (PPL - Protected Process Light) — это "спящий" режим защиты в Windows (начиная с 8.1 / Server 2012 R2), который запрещает любым процессам (даже с правами SYSTEM) читать память lsass.exe.

Как включить (1 ключ реестра):

# Запускаем PowerShell от имени Admin
$RegPath = "HKLM:\SYSTEM\CurrentControlSet\Control\Lsa"
Set-ItemProperty -Path $RegPath -Name "RunAsPPL" -Value 1

(Требуется перезагрузка для применения)

Результат: mimikatz (и другие "дамперы") просто выдаст ERROR kuhl_m_sekurlsa_acquireLSA ; Process Protection Error! (0x00000005). Доступ запрещен.

Взгляд архитектора: Это фундаментальное "укрепление" (Hardening). Вы не "надеетесь" на EDR, вы используете встроенный механизм ОС, чтобы сделать компрометацию lsass.exe невозможной.

#windows #security #mimikatz #lsass #cybersecurity #architect #гайд #musthave

🛡️ Фишинг: Почему "тренировка" — это полдела, а "Zero Trust" — это всё

Боль: 90% всех кибератак начинаются с одного: фишинг. Админ "тренирует" пользователей не нажимать на ссылки. Архитектор исходит из того, что пользователь уже нажал на ссылку.

Обучение пользователей (Layer 😍 — это наш первый, но самый "хрупкий" рубеж обороны.

1. Обучаем (Ресурсы): Вот подборка топ-ресурсов, которые помогут вам и вашим пользователям научиться распознавать угрозы:

KnowBe4 (Лидеры в Security Awareness)
https://www.knowbe4.com/phishing
IT Governance UK (5 способов детекта)
https://www.itgovernance.co.uk/blog/5-ways-to-detect-a-phishing-email
CheapSSLSecurity (10 примеров)
https://cheapsslsecurity.com/blog/10-phishing-email-examples-you-need-to-see/
Google Phishing Quiz (Проверь себя)
https://phishingquiz.withgoogle.com/

2. Строим "бетонную комнату" (Взгляд архитектора): Наша настоящая работа — минимизировать "взрывную волну" после клика. Хакер, получив Initial Access, должен "приземлиться" в изоляции.

Именно поэтому мы внедряем:

* LAPS (чтобы он не украл локального админа).

* AppLocker (чтобы он не запустил свой .exe из Downloads).

* MFA (чтобы он не использовал украденный пароль).

* Admin Tier Model (чтобы он не "прыгнул" на DC).

#security #phishing #cybersecurity #zerotrust #гайд #architect

Windows (Storage): Убейте "Mapped Drives". Внедряем DFS Namespaces

Боль: У вас есть файловый сервер \\OLD-SRV. Вы купили новый, мощный \\NEW-SRV. Теперь вам нужно перенастроить GPO, скрипты и (самое страшное) переучить 500 пользователей, которые привыкли к "Диску Z:".

Решение: DFS Namespaces (DFSN) Это слой абстракции. Вы создаете виртуальное дерево папок, которое не зависит от физических имен серверов.

Как это выглядит для пользователя: \\Corp.local\Data\Docs

Как это выглядит для админа: \\Corp.local\Data\Docs -> ссылается на -> \\SRV-01\Share

Когда SRV-01 устареет, вы скопируете данные на SRV-02 и просто переключите ссылку в консоли DFS. Пользователи даже не заметят подмены.

Настройка (PowerShell):

# 1. Устанавливаем роль
Install-WindowsFeature FS-DFS-Namespace, RSAT-DFS-Mgmt-Con

# 2. Создаем корень пространства имен (Namespace Root)
# \\Corp.local\Public
New-DfsnRoot -Path "\\Corp.local\Public" -TargetPath "\\FILE-SRV-01\PublicRoot" -Type DomainV2

# 3. Создаем папку (ссылку) внутри
# \\Corp.local\Public\Sales -> ведет на реальную шару
New-DfsnFolder -Path "\\Corp.local\Public\Sales" -TargetPath "\\FILE-SRV-01\SalesData"

Взгляд архитектора: Никогда не привязывайтесь к именам "железа". Абстракция — это ключ к миграции без простоев. DFSN позволяет вам менять бэкенд (серверы), не меняя фронтенд (пути доступа пользователей).

#windows #dfs #storage #sysadmin #powershell #architect #гайд

Security (Infrastructure): Смерть authorized_keys. Переходим на SSH-сертификаты

Боль: У вас 100 серверов и 10 админов. Вы копируете их публичные ключи (id_rsa.pub) в файл ~/.ssh/authorized_keys на каждый сервер.

Проблема 1: Админ уволился. Нужно удалить его ключ со 100 серверов.

Проблема 2: Админ потерял ноутбук. Его ключ скомпрометирован навсегда.

Решение: SSH Certificate Authority (CA) Netflix, Facebook и Uber не используют статические ключи. Они используют сертификаты. Это встроенная функция OpenSSH, о которой мало кто знает.

Как это работает:

Вы создаете CA: Генерируете "мастер-ключ" (храните его в сейфе/Vault).

На серверах: В sshd_config прописываете одну строчку: "Доверяй всем ключам, подписанным этим CA". (Файл authorized_keys больше не нужен!).

Вход админа:

Админ кидает свой pub-ключ в ваш Vault (или подписывающий сервис).

Вы (или SSO) проверяете его личность.

Вы подписываете его ключ своим CA со сроком жизни 1 час.

Админ заходит на серверы.

Через час: Сертификат "протухает". Доступа нет.

Взгляд архитектора: Это переход от статического доступа к эфемероному. Вам больше не нужно "ротировать" ключи или чистить серверы. Доступ выдается Just-in-Time (JIT).

#security #ssh #linux #zerotrust #architect #vault #гайд

Linux (Архитектура): Почему epoll устарел? Революция io_uring

Боль: Высоконагруженные базы данных (PostgreSQL, Redis) и веб-серверы тратят до 30% времени CPU просто на "общение" с ядром (System Calls). Старый механизм асинхронного ввода-вывода (epoll) требует постоянных переключений контекста.

Революция: io_uring Это новый интерфейс ядра Linux (появился в 5.1, стал стандартом сейчас), который меняет всё.

В чем суть (на пальцах):

epoll: Приложение: "Ядро, есть данные?" -> Ядро: "Нет" -> Приложение ждет -> Ядро: "Есть" -> Приложение: "Дай". (Куча системных вызовов).

io_uring: Приложение и Ядро создают два кольцевых буфера (Ring Buffers) в общей памяти.

Приложение кладет запрос в буфер "Submission".

Ядро забирает его, делает работу и кладет результат в буфер "Completion".

Ноль системных вызовов (Zero Syscall overhead).

Взгляд архитектора: Если вы видите, что ваш Nginx или MySQL после обновления ядра стали работать на 20-40% быстрее — это io_uring. Архитектор должен знать: для I/O-intensive задач (файловые хранилища, БД) выбор дистрибутива с новым ядром (5.10+) — это бесплатный прирост производительности.

#linux #kernel #performance #iouring #epoll #architect #highload

🗄️ Storage: Почему локальные диски умерли. Встречаем S3 (MinIO)

Боль: Ваше приложение (на PHP, Python, Go) позволяет пользователям загружать аватарки.

* Вариант 1: Сохранять в папку /var/www/uploads. (Проблема: Как масштабировать на 2 сервера? Нужен NFS или rsync — это медленно и сложно).

* Вариант 2: Сохранять в базу данных (BLOB). (Проблема: БД раздувается, бэкапы становятся огромными).

Решение: Object Storage (S3 API). Архитектор отделяет хранение (Storage) от вычислений (Compute).

MinIO — это самый популярный self-hosted S3-совместимый сервер.

Почему это круто:

1. Стандарт: S3 API поддерживают все (Veeam, Terraform, все языки программирования).

2. Масштабируемость: MinIO легко собирается в кластер.

3. Простота: Одно приложение для всех файлов.

Запуск (Docker):

docker run -d \
  -p 9000:9000 -p 9001:9001 \
  --name minio \
  -v /mnt/data:/data \
  -e "MINIO_ROOT_USER=admin" \
  -e "MINIO_ROOT_PASSWORD=SuperSecretPassword" \
  minio/minio server /data --console-address ":9001"

Теперь ваше приложение просто шлет PUT запрос на http://minio:9000. И ему всё равно, на каком сервере оно запущено.

Взгляд архитектора: Использование локальной файловой системы для данных приложения — это антипаттерн в современном IT (12-Factor App). Переход на S3 API делает ваши приложения Cloud Native (готовыми к облаку) сразу.

#devops #storage #s3 #minio #docker #architect #гайд