Компания Wizard

Компания Wizard Оказание услуг по консалтингу на рынке информационных

🔎 Как проверить, что сегментация действительно работаетНедостаточно посмотреть на схему и убедиться, что зоны нарисованы...
10/08/2026

🔎 Как проверить, что сегментация действительно работает

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

Нужно проверить, что между ними действительно нельзя пройти там, где доступ не предусмотрен.

Сегментация — это не картинка с VLAN, DMZ и контурами. Это набор фактических ограничений: правила межсетевых экранов, списки контроля доступа, маршруты, сервисные порты, административные доступы и журналы событий.

Что проверять в первую очередь:

⏺Правила межсетевых экранов
Какие разрешения активны, какие устарели, где есть широкие правила, есть ли владелец у каждого исключения.

⏺ Тестовые проходы между зонами
Можно ли попасть из пользовательской сети в серверный сегмент, из тестовой зоны в продуктив, из DMZ во внутренний контур.

⏺ Сервисные порты
RDP, SSH, SMB, базы данных, веб-интерфейсы, API и служебные подключения должны быть открыты только там, где это действительно нужно.

⏺ Административные доступы
Кто и откуда может управлять серверами, СХД, виртуализацией, сетевым оборудованием и средствами защиты.

⏺ Доступы подрядчиков
Внешние подключения, VPN, временные учётные записи и сервисные права должны иметь срок действия и процедуру отключения.

⏺ Журналирование
Если между зонами есть активность, её нужно видеть. Иначе потом сложно понять, кто, куда и зачем ходил.

⏺ Жизненный цикл исключений
У каждого временного правила должен быть владелец, причина, срок действия и дата пересмотра. Иначе “временно” быстро становится архитектурой.

📍 Главная проверка простая: совпадает ли фактический трафик с тем, что вы считаете разрешённым?

Если нет — сегментация существует только на схеме.

А значит, в момент инцидента она может не остановить распространение между зонами.

Подробнее — в нашей экспертной статье:
https://wizard.ru/press-center/segmentacziya-seti-kotoraya-sushhestvuet-tolko-na-sheme-pochemu-inczidenty-prohodyat-mezhdu-zonami/

🧱 Сеть разделена. Почему тогда инцидент проходит дальше?На схеме всё красиво: VLAN есть, DMZ есть, серверный сегмент отд...
05/08/2026

🧱 Сеть разделена. Почему тогда инцидент проходит дальше?

На схеме всё красиво: VLAN есть, DMZ есть, серверный сегмент отдельно, пользователи отдельно, критичные системы вынесены в свой контур.

И вроде бы можно выдохнуть. Но сегментация работает не на схеме. Она работает в реальных правилах доступа.

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

Формально сеть разделена. Фактически между зонами остаются проходы. Именно так инцидент может уйти дальше: из пользовательской сети к серверу, из тестового сегмента в продуктив, из DMZ во внутренний контур.

Не потому что сегментации совсем нет. А потому что она давно не совпадает с реальностью.

Самая опасная фраза здесь: “Это правило временное, потом закроем”. Потом часто наступает через год. Или после инцидента.

Сегментация должна отвечать не на вопрос “что нарисовано на схеме”, а на другой: какие соединения реально разрешены между зонами — и зачем?

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

🧾 Что должно быть в минимальной инвентаризации ИБВ прошлом посте говорили про самую неудобную уязвимость — неизвестный а...
31/07/2026

🧾 Что должно быть в минимальной инвентаризации ИБ

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

Теперь практический вопрос: что фиксировать, чтобы сервер, ВМ, тестовый стенд или сервисная учётная запись не превратились в “а это вообще чьё?”

Инвентаризация ИБ — это не таблица ради отчёта. Это базовый слой управления инфраструктурой.

Она должна отвечать на три вопроса:
что это за актив;
зачем он нужен;
кто за него отвечает.

Минимально по каждому активу стоит фиксировать:

⏺️ Владелец
Не абстрактное “ИТ”, а конкретный ответственный: технический владелец и владелец со стороны бизнес-процесса.

⏺️ Критичность
Что произойдёт при отказе или компрометации: простой сервиса, утечка данных, нарушение процесса, влияние на клиентов или производство.

⏺️ Сетевой сегмент
Где находится актив: серверный сегмент, DMZ, тестовая зона, пользовательская сеть или удалённая площадка.

⏺️ Открытые сервисы и порты
Какие интерфейсы доступны: RDP, SSH, веб-сервисы, API, служебные подключения. И главное — зачем они открыты.

⏺️ Доступы и учётные записи
Кто имеет права, есть ли сервисные учётки, внешние подключения, подрядчики и временные доступы.

⏺️ Срок жизни
Особенно для тестовых сред и временных ВМ. Если срок не определён, временное быстро становится постоянным.

⏺️ Статус в жизненном цикле
Актив используется, требует ревизии, готовится к выводу из эксплуатации или уже должен быть отключён.

⏺️ Порядок вывода
Закрыть доступы, отключить сервисы, проверить данные, обновить схемы, убрать актив из мониторинга и реестра конфигураций.

📍 Главная мысль простая: пока у актива нет владельца, критичности, срока жизни и понятного статуса, он остаётся зоной риска.

Даже если NGFW, EDR и мониторинг работают корректно. Потому что ИБ начинается не с нового инструмента.

ИБ начинается с понимания: что есть в инфраструктуре, зачем это нужно и кто за это отвечает.

Подробнее — в экспертной статье с Андреем Зюбровским: https://wizard.ru/press-center/inventarizacziya-aktivov-kak-bazovyj-sloj-ib-pochemu-ngfw-ne-spasaet-neizvestnuyu-infrastrukturu/

Самая неудобная уязвимость — неизвестный актив в сетиВ ИБ часто обсуждают NGFW, EDR, SIEM, сегментацию и Zero Trust. Но ...
29/07/2026

Самая неудобная уязвимость — неизвестный актив в сети

В ИБ часто обсуждают NGFW, EDR, SIEM, сегментацию и Zero Trust. Но базовый вопрос проще и неприятнее: что именно мы защищаем?

По данным Verizon DBIR, среди ведущих начальных векторов атак — использование скомпрометированных учётных данных и эксплуатация уязвимостей.

📍 А теперь представим актив, о котором никто не помнит. Когда-то для теста подняли сервер, временную ВМ или сервис в DMZ.

Проект закончился, команда переключилась, владелец сменил роль, а ресурс остался жить в сети. Год. Два. Иногда дольше.

На бумаге всё нормально: NGFW настроен, правила согласованы, мониторинг работает.

Но внутри инфраструктуры остаётся объект, который:

⏺️ не попал в реестр активов;
⏺️ не обновляется;
⏺️ не проходит сканирование на уязвимости;
⏺️ держит открытые доступы по RDP / SSH или веб-сервисы;
⏺️ связан со старой сервисной учётной записью;
⏺️ не имеет владельца и срока жизни.

Проблема неизвестного актива в том, что он выпадает сразу из нескольких процессов: патч-менеджмента / контроля доступов / мониторинга / резервного копирования / вывода из эксплуатации. На схеме его может уже не быть.

В эксплуатации его могут не помнить. А в сети он всё ещё отвечает на запросы. И здесь NGFW не спасает сам по себе.

Он защищает известный контур. Если в сети есть неучтённые серверы, забытые сервисы и ничейные учётки, защита становится фрагментарной.

ИБ начинается не с вопроса “что ещё купить”. ИБ начинается с вопроса: что у нас вообще есть в инфраструктуре — и кто за это отвечает?

В следующем посте разберём, что должно быть в минимальной инвентаризации.

22/07/2026

🏆 Компания ВИЗАРД вошла в число 500 крупнейших ИТ-компаний России

Аналитический центр TAdviser опубликовал новый рейтинг TAdviser500, в который вошли крупнейшие компании, работающие на российском ИТ-рынке. Компания ВИЗАРД заняла 210-е место ⭐️️

Ещё один важный результат — выручка компании по итогам года выросла более чем на 50%.

️️️️🪄 За этим ростом нет одного волшебного решения. Есть сильная команда / новые компетенции / сложные проекты / доверие клиентов / много работы, которая обычно остаётся за кадром.

32 года на ИТ-рынке — и мы не просто сохраняем позиции. Мы продолжаем расти.

Спасибо всем, кто идёт этот путь вместе с ВИЗАРД 🤝

15/07/2026

📼 32 года ВИЗАРД — это не только проекты, технологии и цифры

Это люди.

Люди, которые когда-то начинали с первых задач, первых поставок, первых сложных проектов и первых “надо срочно разобраться”.

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

Но кое-что осталось прежним.

⏺Команда, которая умеет собираться вокруг задачи
⏺Способность держать удар, когда проект идёт не по идеальному сценарию.
⏺И отношение к делу, которое невозможно прописать в регламенте, но очень хорошо видно в работе.

За 32 года у ВИЗАРД было много разных этапов: рост, изменения, новые направления, сложные проекты, большие победы и рабочие будни, из которых на самом деле и складывается история компании.

И если смотреть на старые фотографии, особенно хорошо видно: компания — это не логотип и не дата основания. Компания — это коллектив.

3️⃣2️⃣Нам 32. И, пожалуй, главный повод для гордости — не только в том, сколько лет мы на рынке.

А в том, что за эти годы у нас сложилась команда, с которой можно проходить сложные проекты, меняться, расти и оставаться ВИЗАРД.

Спасибо всем, кто был и остаётся частью этой истории❤️

🧭 Какая диспетчеризация действительно помогает эксплуатацииХорошая диспетчеризация — это не экран, на котором всё красив...
10/07/2026

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

Хорошая диспетчеризация — это не экран, на котором всё красиво разложено по цветам. Это система, которая помогает быстро понять: что произошло / где источник / что критично / кто реагирует / что делать дальше

Именно поэтому вопрос не в том, есть ли у объекта мониторинг. Вопрос в том, помогает ли он управлять ситуацией, когда что-то пошло не так.

Что важно проверить:

⏺️Правильные точки контроля
Датчики должны стоять не “где удобно”, а там, где реально возникает риск. Иначе система будет видеть среднюю картину, а не критичную зону.

⏺️ Пороги срабатывания
Если пороги заданы слишком широко — тревога придёт поздно. Если слишком узко — оператор утонет в ложных авариях. Нужен баланс между чувствительностью и здравым смыслом.

⏺️ Приоритеты аварий
Не все события одинаково важны. Одно требует немедленной реакции, другое можно разобрать планово, третье вообще является следствием первой проблемы. Без приоритетов дежурная смена видит шум, а не картину.

⏺️ Корреляция событий
Если один сбой запускает цепочку тревог, система должна помогать понять первопричину. Иначе оператор будет тушить “лампочки” по очереди, вместо того чтобы работать с источником проблемы.

⏺️ История аварий
Важно видеть не только текущий статус, но и динамику: когда началось отклонение, как развивалось, что уже происходило раньше и какие действия помогали.

⏺️ Сценарии реакции
У оператора должен быть понятный порядок действий: кого уведомить, что проверить, что можно сделать самостоятельно, когда подключать инженеров и когда эскалировать инцидент.

⏺️ Связка с ИТ-мониторингом
Инженерные системы и ИТ давно живут в одной реальности. Если инженерка видит одно, а ИТ — другое, объект управляется фрагментами. Нужна общая картина причин и последствий.

📍Сильная диспетчеризация не просто сообщает: “что-то не так”. Она помогает понять, насколько это критично, к чему может привести и какой шаг должен быть следующим.

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

🟢 На экране всё спокойно. На объекте — уже нетОдна из самых опасных иллюзий в инженерной эксплуатации — считать, что есл...
08/07/2026

🟢 На экране всё спокойно. На объекте — уже нет

Одна из самых опасных иллюзий в инженерной эксплуатации — считать, что если диспетчеризация “зелёная”, значит объект под контролем. На практике это не всегда так.

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

📍 Типовой сценарий: температура в системе ещё “в допуске”, тревоги нет, экран зелёный.
Но датчик установлен не в оптимальной зоне контроля, поэтому диспетчер увидит не начало проблемы, а её запоздалое отражение.

Бывает и хуже: аварии приходят без нормального приоритета. Оператор получает сразу несколько сигналов, но не понимает, что первично, а что уже следствие. В итоге внимание уходит не туда, а время теряется.

Например:
⏺️ сработал один датчик и потянул за собой ещё несколько событий
⏺️ система показала набор тревог, но без логики причин и последствий
⏺️ дежурная смена видит симптом, но не понимает источник
⏺️ ИТ уже замечает деградацию сервиса, а инженерка ещё не локализовала первопричину

И вот здесь становится понятно главное: диспетчеризация — это не просто красивый экран с показателями. Она должна помогать принимать решение, а не просто фиксировать факт отклонения.

Если система не показывает, что именно критично, где источник и какова последовательность реакции, это уже не контроль, а иллюзия контроля.

❗️“Зелёный экран” ещё не означает, что объект действительно управляем.

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

🧩 Что проверить в СКС до запуска ИИ-нагрузокЕсли под AI-проект уже закуплены серверы, GPU и коммутаторы, это ещё не знач...
03/07/2026

🧩 Что проверить в СКС до запуска ИИ-нагрузок

Если под AI-проект уже закуплены серверы, GPU и коммутаторы, это ещё не значит, что физическая инфраструктура действительно готова к работе под высокой нагрузкой.

Перед запуском важно проверить не только активное оборудование, но и всю кабельную систему. Именно она часто определяет, сможет ли кластер работать в расчётном режиме.

Что стоит проверить в первую очередь:

⏺️Оптику и коннекторы
Тип трансиверов, совместимость, класс оптики, состояние коннекторов и корректность сборки тракта. Ошибка здесь может дать ограничения даже при дорогом и современном оборудовании.

⏺️Трассы и длины линий
Важно понять, соответствуют ли длины требованиям под нужные скорости и не появляются ли ограничения на критичных участках.

⏺️Радиусы изгиба и физическое состояние линий
Для оптики это особенно чувствительный момент. Перегибы, натяжение, неправильная укладка и плотная коммутация могут влиять на стабильность и качество канала.

⏺️Измерения и протоколы тестирования
Линии должны быть не “на глаз нормальные”, а реально проверенные. Нужны результаты измерений, тесты и подтверждение, что физический уровень соответствует задаче.

⏺️Маркировку и кабельные журналы
Если в кластере десятки и сотни соединений, без нормальной маркировки и актуальной документации любое изменение потом превращается в отдельный квест.

⏺️Резерв портов и запас на масштабирование
ИИ-нагрузки редко заканчиваются на первой конфигурации. Если всё спроектировано “впритык”, следующий этап роста быстро упрётся уже не в вычисления, а в инфраструктуру.

⏺️Готовность к 100/400G
Важно смотреть не только на текущую скорость, но и на то, выдержит ли СКС следующий этап развития без полной переделки.

📍 На практике хороший вопрос звучит так: готова ли кабельная система не просто “подключить оборудование”, а обеспечить стабильную работу и дальнейший рост.

Потому что для ИИ-проектов СКС — это уже не фон, а полноценная часть вычислительной архитектуры.

➡️ Подробнее — в нашей статье: https://wizard.ru/press-center/sks-dlya-ii-nagruzok/

⚡️ Когда GPU-кластер упирается не в серверы, а в кабельную системуОдна из самых неприятных ошибок в проектах под ИИ — ду...
01/07/2026

⚡️ Когда GPU-кластер упирается не в серверы, а в кабельную систему

Одна из самых неприятных ошибок в проектах под ИИ — думать, что главные риски живут в серверах, GPU и коммутаторах. На практике всё может быть проще и обиднее: вычислительный кластер готов, сеть “по паспорту” быстрая, а производительность всё равно не та, на которую рассчитывали.

Причина нередко оказывается в кабельной системе.

Серверы поддерживают высокие скорости, коммутаторы тоже, но между ними остаются старые линии, неподходящая оптика, случайные патч-корды, некачественная коммутация или превышение допустимых длин.

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

📍 Типовая ситуация: кластер проектировали под высокоплотные ИИ-нагрузки, закладывали быстрый обмен между узлами и нормальный запас по сети. Но уже на этапе запуска выяснилось, что часть соединений работает не в расчётном режиме.

Причина — “унаследованные” участки СКС и неподходящие компоненты в тракте. В итоге узким местом стал не кластер, а физическая среда передачи.

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

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

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

В следующем посте разберём, что именно нужно проверить в СКС до запуска ИИ-нагрузок: оптику, коннекторы, трассы, измерения, маркировку, запас портов и готовность к масштабированию 🗓

Address

Нижняя 14с2
Moscow
125040

Opening Hours

Monday 10:00 - 19:00
Tuesday 10:00 - 19:00
Wednesday 10:00 - 19:00
Thursday 10:00 - 19:00
Friday 10:00 - 18:00

Website

Alerts

Be the first to know and let us send you an email when Компания Wizard posts news and promotions. Your email address will not be used for any other purpose, and you can unsubscribe at any time.

Shortcuts

Share

Category