динамический скайбокс что это
Как создаются скайбоксы в играх — опыт художника World of Warcraft Статьи редакции
Из каких элементов состоит небо, и как применяется техника мэт-пэйнтинг.
Художник по окружению World of Warcraft Филипп Чжан рассказал изданию 80 Level о своём опыте создания скайбоксов для игр. Чжан дал несколько советов, а также подробно описал, из каких элементов обычно состоит небо в играх. Мы выбрали из текста главное.
В команде разработчиков World of Warcraft рабочий процесс устроен так, что художник самостоятельно создаёт ассет от начала до конца — сперва рисует концепт, затем моделирует и текстурирует. За время, проведённое в студии, Чжан успел поработать над разным контентом. Важный урок, который он вынес для себя — у каждого ассета есть своя история, личность и происхождение.
Например, орочьи ворота были бы сделаны из грубо обработанных досок, покрытых трещинами, и оформленных костями животных и металлическими шипами. У врат Ночных эльфов были бы пышные разросшиеся виноградные лозы и молодые деревья, украшенные дикими лесными цветами и плодами — эта раса стремится сохранять природу. Чжан считает, что художнику гораздо легче придумать интересный дизайн, если он чётко понимает историю каждого элемента.
Чжан рассказал, что в работе художника по окружению очень важно заботиться о впечатлении, которое производит вся сцена целиком. Красивое дерево может выглядеть прекрасно само по себе, но оно может испортить всю композицию, так как будет перетягивать всё внимание на себя. Художник по окружению должен постоянно думать о соотношении цвета и формы между всеми ассетами, чтобы вся сцена выглядела хорошо.
Когда Чжан создаёт скайбокс, он старается воспринимать его не только как отдельный фрагмент, который рассказывает историю, но и как фоновое изображение, которое сливается с остальной сценой.
В августе прошлого года он стал первым художником по окружению, который начал работать над Shadows of Argus. Чтобы проиллюстрировать разрушенный родной мир Эредаров, разработчики решили использовать мэт-пэйнтинг в скайбоксах World of Warcraft.
Чжан столкнулся с необходимостью рассказать игрокам историю мира Аргус, который тысячи лет назад был завоёван и сокрушён демоническим Пылающим Легионом.
Уже на этапе блокинга художник постарался показать последствия нападения — пейзажи разрушенных городов, демонические крепости, извергающиеся вулканы. Позже, когда другие художники и дизайнеры реализовали большую часть игрового пространства, Чжан убрал некоторые элементы, которые привлекали слишком много внимания. Затем он сделал скриншоты окружения, чтобы использовать их в мэт-пэйнтинге.
Небо в World of Warcraft — это изображение, которое простирается за пределы игрового пространства. Оно вызывает у игроков определённые эмоции при помощи света, теней и цвета. Скайбоксы сильно зависят от настроения, истории и климата каждого места. Также команда добавляет динамические погодные системы, такие как дождь и снег, чтобы сделать мир разнообразнее.
Синим цветом изображён основной меш скайбокса. Для него могут использоваться тайловые текстуры, например, звёзды, облака — всё, что способно передать определённое настроение.
Зелёным изображён меш с облаками, который постепенно поворачивается для имитации движения. Также он используется для создания удалённых объектов пейзажа — гор, полей.
Жёлтые прямоугольники олицетворяют отдельные объекты — единичные облака или парящие острова. Красным изображены визуальные эффекты — водопады, дым, огонь, энергия и так далее. Фиолетовым — земля, по которой ходит игрок.
По словам Чжана, процесс создания скайбоксов при помощи мэт-пэйнтинга не слишком отличается от обычного подхода. Вот как это выглядит.
Первое изображение — это фотография на 180 градусов, сделанная на крыше паркинга. На втором изображении зелёным показана игровая зона, по которой передвигается пользователь. Всё остальное — мэт-пэйнтинг скайбокс. Третье изображение — это устройство самого скайбокса со всеми элементами.
Синий цвет — фон. Травяной зелёный — несколько слоёв облаков, движущихся на разной скорости. Ярко-зелёный — мэт-пэйнтинг гор и деревьев. Жёлтый — мэт-пэйнтинг парящего города. Жёлто-коричневый — движущиеся космические корабли. Красный — огонь и дым от вулкана. Красно-коричневый — свет от маяка. Розовый — огонь от двигателей космических кораблей.
Когда вы решаете, какие элементы добавить в сцену, подумайте, что вы можете действительно перенести в неё. Например, гора с высокими соснами может простираться на сотни миль в мэт-пэйнте вашего скайбокса — это добавит окружению глубины.
Скайбокс — это фон сцены. Если они будут ощущаться отделёнными друг от друга, то это плохо скажется на погружении игроков. Цвета, формы и освещение в скайбоксе всегда должны перекликаться с элементами на переднем плане. Вы также должны учитывать, как работает человеческий глаз, когда он рассматривает окружение на расстоянии. Вещи, которые находятся дальше от человека, обычно менее контрастны по сравнению с тем, что он видит прямо перед собой. То же самое относится и к ассетам для скайбоксов.
По мнению Чжана, мэт-пэйнтинг отлично подходит для создания неба и пейзажей в играх. Чтобы сделать в 3D разрушенный древний город в джунглях или горящий корабль в небе, могут потребоваться тысячи часов. Но похожего эффекта можно достичь при помощи мэт-пэйнтинга, холста размером 2048×2048 пикселей и пары недель работы.
Создание неба для 3D-игр
Потрясающий художник Blizzard Филип Чжан поделился некоторыми техниками, которые помогут вам создавать более качественные и интересные скайбоксы.
Введение
Меня зовут Цзэянь Чжан, также я известен как Филип Чжан. Я художник по окружениям и в настоящее время работаю над World of Warcraft в Blizzard Entertainment. Я родился и вырос в Китае, и в детстве меня всегда восхищали рисунки и истории, что побудило меня заняться изучением цифровых медиа в Центральной академии художественных искусств в Пекине. После выпуска я переехал в США, чтобы продолжить обучение игровой графике в Laguna College of Art and Design.
После завершения обучения я получил первый опыт работы в Disney ABC Television Group в качестве интерна-художника по концептам в 2014 году. Несколько месяцев спустя я принял участие в Blizzard Student Art Contest и был принят интерном в команду World of Warcraft. С того времени я поработал над World of Warcraft: Warlords of Draenor и World of Warcraft: Legion.
Задачи
В процессе сотрудничества с командой разработки World of Warcraft я поработал с командой разработки пропсов и с разработчиками окружения. Прежде чем начать описывать процесс работы над скайбоксами, мне бы хотелось поделиться уроками, которые я извлёк при работе с этими командами.
В команде разработчиков World of Warcraft художник должен создавать концепты, модели и текстуры с нуля и до конца. Будучи интерном в команде по пропсам, я работал над множеством задач: наборы, соответствующие культурам различных рас, ресурсы с тематикой фракций для боевых арен и броня для разных классов. Самое важное, что я почерпнул из этого опыта — у каждого ресурса есть своя история; каждый ресурс — это уникальный персонаж со своей индивидуальностью и предысторией. Например, ворота орков сделаны из грубо обтёсанной древесины, поцарапанной и покрытой забрызганными кровью кожаными стяжками, звериными костями и металлическими шипами. На воротах ночных эльфов есть пышная лоза и побеги деревьев, украшенные лесными цветами и фруктами, потому что главной ценностью в их культуре является сохранение природы. По моему мнению, художнику намного проще создать интересный дизайн, если ему понятна история, которую он хочет рассказать.
Мой способ рассказывать историю через мои работы хорошо подошёл для команды разработки окружений. После завершения интернатуры я официально начал работать в Blizzard на должности художника по окружениям. Художники по окружениям создают деревья, растительность, скайбоксы и наборы тайлов текстур земли для зон. Наиболее важным уроком для меня стало то, что в первую очередь всегда создаётся общая картина сцены. Красивое дерево может само по себе выглядеть хорошо, но портить всю композицию, привлекая к себе слишком много внимания. Художник по окружениям всегда должен думать о соотношениях цвета и формы между всеми ресурами, чтобы они положительно влияли на общий вид сцены.
Когда я начинаю работать над скайбоксом, я стремлюсь визуализировать скайбокс не только как отдельный элемент, рассказывающий игрокам историю, но и как фоновое изображение, вписывающееся во всю сцену.
В августе я стал первым художником по окружениям, начавшим работу над Shadows of Argus (патч 7.3). Чтобы проиллюстрировать массу земли разрушенного родного мира эредаров, я с дизайнерами решили добавить в скайбоксы рисованные окружения World of Warcraft. Я начал делиться с игроками историей — Аргус когда-то был родным миром гордого народа эредар, и тысячи лет назад он был завоёван и разрушен демоническим Пылающим Легионом. На этапе эскизов я позволил своему воображению создать расколотую землю, демонические крепости, извергающиеся вулканы и руины городов эредаров. Позже, когда другие художники и дизайнеры создали образ большей части игрового пространства, я убрал некоторые из элементов, привлекавших слишком много внимания, и сделал скриншоты игрового рельефа и зданий, после чего добавил их в мои рисованные окружения, чтобы сцены выглядели целостными.
Структура
Скайбокс в World of Warcraft — это картинка, которая растянута над игровым пространством. Она воздействует на чувства игрока светом, тенями и цветами. Команда разработчиков окружений создаёт скайбоксы на основе характера, истории и климата каждой локации. Также мы создаём динамические погодные системы, такие как дождь или снег, чтобы добавить вариативности в игровой процесс. Вот более подробная информация о основной структуре скайбокса:
Процесс создания скайбоксов с рисованными окружениями не слишком отличается от создания обычного скайбокса. Вот пример:
Контент
При выборе добавляемых в сцену элементов логично начинать с выбора того, какие мы можем позаимствовать элементы переднего плана. Например, на рисованном окружении гора с высокими соснами может растянуться на сотни миль скайбокса. Добавив её, мы создадим глубину и сильное чувство атмосферности в этом окружении.
Текстуры синей планеты созданы Сервандо Лупини (бывшим 3D-художником Blizzard).
Скайбокс — это фон сцены. Игроки не смогут погрузиться в окружение, если игровое пространство и скайбокс будут находиться в диссонансе. Цвета и формы, используемые в скайбоксе, всегда должны быть отражением элементов переднего плана. Также стоит учитывать то, как работает глаз человека, рассматривающий окружение вдалеке. Отдалённые от человека объекты обычно кажутся менее контрастными, чем находящиеся рядом. То же самое относится и к ресурсам для скайбокса.
Создание скайбоксов с рисованным окружением может стать эффективным способом решения дизайнерских проблем. Иногда амбициозная концепция — например, древний город в джунглях или горящий космический корабль в небе — требует для воссоздания в 3D-пространстве тысяч часов работы художников и дизайнеров. Однако того же эффекта можно добиться, нарисовав за пару недель рисованное окружение на холсте размером 2048×2048 пикселей. Я считаю, что ключ к созданию успешного, связанного с историей окружения — эффективная коммуникация с командой, изложение видения с последующей его визуализацией в рисованных окружениях.
Особенности создания стилизованных скайбоксов
Старые мастера несколько веков назад разработали много эффективных способов создания потрясающих окружений. За последние два десятилетия появились сотни удивительных цифровых художников, вдохновлявшихся их работой. Я часто посещаю такие веб-сайты, как Blogger, ArtStation и Pinterest, чтобы набраться примеров и вдохновения. Вот некоторые из моих любимых художников:
Освещение
Освещение скайбокса должно соответствовать освещению сцены. После завершения скайбокса художник по окружениям должен внимательно проверить освещение в сцене и внести небольшие изменения, чтобы оно всё подходило идеально.
Купол неба Сервандо Лупини (бывшего 3D-художника Blizzard)
Купол неба Сервандо Лупини Lupini (бывшего 3D-художника Blizzard)
Советы
Знание традиционной живописи — учась в Laguna College of Art and Design, я много занимался живописью окружений. Хотя такой практики ни в коем случае не было бы достаточно для создания скайбокса World of Warcraft, она помогла мне освоить основы цвета, освещения и композиции. Это знание сильно помогло мне в создании скайбоксов с рисованными окружениями. Неважно, какого стиля стремится достичь художник — знание правил традиционной живописи всегда пригождается.
Рассказывайте историю с выдумкой — по сравнению с другими ресурсами окружений, скайбокс даёт художнику почти бесконечные возможности для самовыражения на своём 360-градусном холсте. Позвольте игрокам ощутить свои самые безумные художественные идеи!
Уделите внимание переходам между важными точками. На работе я часто общаюсь с дизайнерами уровней. Они много говорят о переходах между важными точками. Когда игроки переходят из одной локации в другую, географический переход должен казаться естественным и логичным. Я считаю, что то же самое относится и к рисованным окружениям скайбоксов. Например, в сцене, где есть льющиеся с гор потоки воды, эти потоки могут соединяться в реку. Река стекает в каньон и становится огромным водопадом. Это будет выглядеть намного убедительнее, чем водопад, появляющийся без источника. Соединение различных источников в окружении — ключевой момент в создании скайбокса с рисованным окружением.
Динамическое небо: Теория и практика
Привет! Меня зовут Брайан Адамс (Bryan Adams), мне 23 года, я родом из далёких земель Новой Зеландии. Я вырос на Южном острове, в краю сельхозугодий, завораживающих гор и восхитительного неба. В течение семи лет я изучал анимацию, визуальные эффекты, 3D-моделирование, а прямо сейчас делаю упор на игровую разработку. За годы учёбы у меня было много практики, включая работу в Новой Зеландии и за рубежом и даже преподавание. Сейчас я на последнем году обучения по специальности Game Art в Media Design School.
Мне всегда нравилось масштабное окружение, сначала в фильмах и анимации, потом и в играх. Всё началось года два назад, когда я встретился с Майком Портером (Mike Porter) в Окленде во время обыденной поездки, нацеленной на изучение дальнейших курсов. Три месяца спустя я посетил мастер-класс от Джейсона Сассмена (Jason Sussman) – на тот момент работающего старшим художником окружения, ответственным за внешний вид Марса в первой Destiny – в котором он рассказывал о специфике рабочего процесса в Bungie. В тот самый день я и влюбился в игровое окружение и с тех пор развиваю свои познания в UE4.
Когда я начал работать с окружением, меня сразу заинтересовали скайбоксы и то, как они передают эмоции и поддерживают историю. Специализированную информацию по скайбоксам найти было сложно, но в итоге мне попалась на глаза программа Vue от E-on Software, позволяющая создавать замечательные статичные скайбоксы:
Сейчас я пользуюсь отличным плагином для UE4 под названием Truesky, с ним можно создавать процедурные скайбоксы с объёмными облаками и погодными условиями. Я обожаю этот плагин за возможность экспериментировать с небом в реальном времени без необходимости в бейкинге и рендеринге:
Теория
Скайбоксы всегда занимают внушительную часть пространства вокруг вас, будь вы на Земле, на Марсе или на Конкорде (Halo 4). Вы можете и не задумываться об этом, но небеса рассказывают вам о мире и его атмосфере, и при разработке скайбокса следует учитывать множество факторов.
Одни из основных элементов, которые я беру в расчёт, принимаясь за новый скайбокс, это время, место, история, анимация и эмоции. Время суток, разумеется, многое значит для любого скайбокса, но когда речь идёт о динамических скайбоксах, важно думать и о том, как изменится небо со временем. Место также играет важную роль: в зависимости от того, где вы находитесь, окружение будет оказывать на разный эффект на игровой процесс. Например, вы стоите у моря в ветреный день – на воду может опуститься лёгкий туман, и освещение будет смягчено. Дальше идёт история данного места: как здесь проходит обычный день, происходит ли что-то особенное (вроде солнечной активности на карте Solace из Halo 4). Анимация важна, потому что она оживляет сцену и помогает проникнуться ей – посреди космоса вы можете не ощущать прямой причастности к окружению, но движущийся спутник или пролетающая мимо комета позволят игроку укрепить свою связь с этим местом, и так вам будет проще добиться задуманного эффекта. И последнее – но не по важности – эмоции. Что должен чувствовать игрок, глядя на горизонт? Умиротворённость, восхищение, испуг?
Всем, кто интересуется скайбоксами, рекомендую взглянуть, как Рик Нокс (Rick Knox) демонстрирует отдельные элементы, из которых он собирал скайбокс карты Longbow из Halo 4 – я был очень впечатлён, впервые увидев это небо.
Как создавать динамические скайбоксы в UE4?
Для создания динамичных скайбоксов в UE4 я пользуюсь плагином TrueSky, это превосходный инструмент, и работать с ним будет легко, если вы уже знакомы с той же Vue.
Я покажу простой пример скайбокса в Truesky и расскажу, как настроить объёмные облака, сохраняя определённую эстетику. В качестве основы для окружения я воспользовался World Machine, а при помощи Truesky менял оригинальный скайбокс. Также я подключил направленное освещение для симуляции Солнца и Луны.
В качестве отправной точки я выбрал базовую водную поверхность и простой меш из World Machine.
Обычно я первым делом повышаю плотность облаков, чтобы было, с чем работать.
В Truesky менять время суток проще простого, я выставил 6:30, чтобы добавить облакам немного цвета.
Чтобы избавиться от однообразия и слишком крупных форм, меняем плотность облаков и добавляем шум Уорли. Это делает сцену естественнее, и в Truesky много других настроек, повышающих реалистичность скайбокса.
Крупный план облаков: как видите, уже довольно правдоподобно.
Освещение
Освещение – важная часть работы над скайбоксом. Обычно я отключаю подгрузку текстур в UE4 и создаю серый проход рендеринга, чтобы сконцентрироваться только на освещении. Это помогает мне подобрать подходящее время суток, после чего я перехожу к облакам. Я обращаю внимание на такие вещи, как тип облаков, область покрытия, атмосферное освещение, отражённый свет/подсвечивание облаков, скорость затухания, второстепенные слои и движение. Разобравшись со всем этим, я включаю подгрузку текстур и могу использовать Post Process Volume для тонкой настройки нужных значений. На статичных скайбоксах я всегда меняю температуру цвета, добиваясь большего реализма и затем полагаюсь на постобработку для настройки до желаемого результата.
Как добавляются художественные штрихи?
Я думаю, важный аспект, которому часто не уделяют должного внимания – это движение. Сочетание листвы и движения облаков или объектов окружения может существенно повысить реализм и оживить мир. Второстепенные акторы на заднем плане, вроде животных/существ, городов или какого-либо рода движения, добавляют сцене глубины, масштабов и истории.
Можно украсить сцену и другими штрихами, и здесь лучше всего поможет обращение к работам людей, которые вас вдохновляют. Когда я был моложе, я постоянно смотрел на небо, и однажды у нас был северо-западный ветер, создающий невероятные цвета и формы. Знаете, как в кино, когда думаешь, будто в жизни такого не бывает. В некоторых играх я чувствовал нечто подобное – мне нравится окружение и скайбоксы в проектах Bungie, от первой Halo до Destiny 2, и думаю, что их скайбоксы многое добавляют сюжету и ощущениям от игры в целом. Очень важно искать источники вдохновения, подталкивающие к созданию чего-то нового, и для меня это Райан Уоткинс (Ryan Watkins), Мукул Соман (Mukul Soman), Ту Бси (Tu Bsi), Гёкхан Карадайы (Gökhan Karadayı) и Рик Нокс.
Хочу поблагодарить Бреда Аллена (Brad Allen) и Джейсона Сассмена за обучение и наставление на этот замечательный путь.
Примечание: TrueSky доступен для Unity и Unreal Engine.
Как управлять сетью — класс решений Firewall management. Часть 1. Skybox
Не можете разобраться, что происходит в сетевой инфраструктуре? Создание Access Control List (ACL) давно стало рутиной, но по-прежнему отнимает очень много времени? Приходится управлять несколькими межсетевыми экранами разных вендоров одновременно? Скоро придет аудитор, чтобы проверить, насколько написанные вами правила доступа соответствуют требованиям регулятора или отраслевому стандарту? Если вы узнали себя хоть в одном вопросе, этот текст для вас.
В общем, добро пожаловать под кат все ищущие унификации в анализе и контроле настроек межсетевых экранов (МСЭ) и сетевых устройств.
Это первая из трех статей цикла обзоров решений класса Firewall management, в котором мы рассмотрим решения Skybox Security, Tufin orchestration suite и AlgoSec.
В каждой более-менее крупной организации существуют (мне очень хочется в это верить) и даже иногда формализованы процессы управления состоянием сети (изменения на сетевых устройствах, изменения топологии сети, контроль доступности сервисов на уровне сети) и управления уязвимостями.
Однако администраторам ИБ и ИТ всё равно приходится сталкиваться с целым рядом проблем.
Проблема 1
Большое количество устройств и правил/политик
В настоящее время в ИТ-инфраструктуре большинства компаний эксплуатируется достаточно много сетевых устройств и межсетевых экранов. Общее количество правил фильтрации, списков контроля доступа и прочих настроек, связанных с обеспечением безопасности и контроля доступа к элементам инфраструктуры, исчисляется тысячами. Эти правила, списки и прочие объекты в процессе эксплуатации значительно разрастаются, начинают дублировать и перекрывать друг друга.
При этом управление оборудованием выполняется с помощью ряда консолей, что значительно усложняет получение единой наглядной картины эффективности действия правил доступа по всей сети. Поэтому оптимизация и анализ правил и прочих объектов в базах устройств доступа «вручную» совершенно неэффективны: через некоторое время вновь возникнет путаница.
Тут можно возразить, что ряд МСЭ проверяют правила до создания, чтобы найти «дублирующиеся» и «перекрывающие». А так на всех устройствах? А позволяют ли они пометить правило, которое специально создано как «дублирующееся» и «перекрывающее»?
Проблема 2 (тесно связана с проблемой 1)
Необходимо регулярно открывать новые доступы на существующих МСЭ, изменять настройки МСЭ
В целом после внедрения любого МСЭ и до момента его вывода из эксплуатации общий перечень выполняемых с этим МСЭ действий выглядит так:
Настройка правил доступа в процессе эксплуатации МСЭ.
Администрирование настроек МСЭ.
Оценка выполненных настроек и соответствия ACL требованиям отраслевых стандартов, лучшим практикам и рекомендациям вендоров МСЭ.
Ресертификация правил доступа (проверка «нужности» правила, продление срока его жизни или удаление).
Каждое действие требует определенного времени на выполнение, а самое главное — времени на трудоёмкий и порой непрозрачный процесс согласования изменений со всеми заинтересованными лицами. Очень часто процесс открытия доступов на сетевом оборудовании (даже если он не задокументирован) ведется в какой-либо внутренней тикет-системе, а это — плюс еще одна «консоль», в которой приходится работать ИТ- и ИБ-администраторам.
Проблема 3
Отсутствие актуальной схемы сети организации
Как бы сетевики ни старались, и как бы ИБэшники ни требовали, очень трудно поддерживать схему сети всей организации актуальной и в едином файле. Логичным выглядит внедрение какой-либо системы, которая сможет подключаться ко всем сетевым устройствам, считывать конфигурации и самостоятельно отрисовывать актуальную схему сети. Но вот найти такое решение, способное поддерживать все наиболее распространённые сетевые устройства, довольно трудно.
Проблема 4
Невозможно адекватно оценить риски изменения каких-либо настроек на сетевом оборудовании (как в правилах доступа, так и в настройках самого сетевого оборудования) ДО момента внесения этих настроек
Например, необходимо открыть доступ по определенному порту (ТСР:443) к определенному серверу (конкретный IP-адрес). Регламенты организации позволяют создавать такое правило, ИТ- и ИБ-администраторы не видят рисков, доступ открывается. Но никто не задумался, что, например, на целевом сервере стоит уязвимый IIS и открытие доступа к серверу по ТСР:443 создает дополнительный вектор для атак.
Проблема 5
Нет возможности проследить весь «путь» трафика
Если, когда нужно открыть доступы, между конечными устройствами (например, между двумя корпоративными серверами) находится больше 3-4 маршрутизирующих устройств, на которых помимо процессов маршрутизации выполняется еще и фильтрация трафика или даже его преобразование (NAT), после создания разрешающего правила требуется проверить, получили ли серверы нужные доступы или нет. И вот если этого доступа они не получили. сетевых администраторов ждёт головная боль: им придётся пытаться определить, на каком же сетевом устройстве трафик отбрасывается или направляется не в ту сторону.
Суммируя вышесказанное, для решения ежедневных задач ИТ- и ИБ-службам требуется инструмент, который позволит:
автоматизировать процесс управления политиками сетевого доступа;
проводить комплексный аудит конфигураций межсетевых экранов и сетевых устройств, в том числе проверять их на соответствие отраслевым стандартам и лучшим практикам информационной безопасности;
визуализировать и поддерживать в актуальном состоянии логическую карту сети организации (уровня L3 модели OSI);
и (опционально) аккумулировать информацию по уязвимостям ИТ-инфраструктуры, определять, насколько злоумышленник может использовать те или иные уязвимости ИТ-активов извне или из внутренней сети компании, а также управлять найденными уязвимостями;
моделировать изменения в существующей сетевой инфраструктуре.
Для решения подобного рода проблем существуют системы класса Firewall Management (FWM, хотя его еще называют Security Posture Management, Security Policy Management и даже Network Security Management).
Важно понимать, что FWM не является ни SIEM, ни NTA, ни Vulnerability scanner, ни чем-либо еще.
Решения этого класса модульные, в них каждый модуль выполняет свою функцию. Далее представлены модули, которые представляют собой основу всех решений направления FWM:
Модуль анализа МСЭ и сетевых устройств — основная неотъемлемая часть решений FWM — предназначена непосредственно для сбора и анализа конфигураций сетевых устройств и устройств безопасности всех основных производителей: Cisco, Check Point, Juniper, Palo Alto, Fortinet, McAfee, Forcepoint, VMware и др.
Сбор конфигураций осуществляется онлайн (информация собирается непосредственно с самих устройств) и/или офлайн (путем загрузки конфигурационных файлов сетевых устройств). При сборе онлайн производится ввод последовательности команд на просмотр (нет-нет, никаких изменений вноситься не будет) и вывод этих команд «забирается» FWM для дальнейшего разбора и анализа.
Также на основании полученных конфигураций строится динамическая карта сети. Эта карта позволяет увидеть, как устроена сеть, проверить доступность хостов между собой с отображением подробной информации, где и какие правила разрешают/запрещают доступ.
Анализ собранных конфигураций МСЭ позволяет:
Найти затененные и избыточные ACL: правила, которые не могут сработать из-за идентичного или более широкого правила, стоящего выше в ACL. Модуль позволяет обнаружить как простые случаи (широкое правило затеняет узкое), так и менее очевидные, когда оценивается влияние целой совокупности правил.
Провести анализ ACL МСЭ на соответствие тем или иным параметрам (например, ANY в двух и более полях правила).
Провести анализ конфигурации устройств на соответствие best practice от производителей.
Проверить соответствие настроенных правил стандартам и требованиям регуляторов (например, PCI DSS или NIST).
Все эти функции составляют некое «ядро» каждого решения класса FWM.
Модуль управления межсетевыми экранами позволяет автоматизировать процесс изменений на МСЭ на всех его этапах: формирования задачи, ее согласования, проектирования решения, внесения изменения, верификации результата. В итоге получаем тикет-систему, созданную специально для подобных задач. Например, на стадии согласования планируемых изменений сотрудник ИБ может запустить автоматическую проверку того, насколько эти изменения соответствуют настроенной политике ИБ, и на основании этого принимать решение о согласовании или отказе. На этапе проектирования администратор может получать рекомендации от модуля FWM о том, каким способом лучше выполнять изменение: на каком устройстве, какое правило добавить/изменить, и даже могут быть сформированы конкретные команды в терминах конечных устройств. К тому же есть возможность настроить систему и на автоматическое применение согласованных изменений на целевые МСЭ.
Но есть и принципиальные различия в назначении некоторых дополнительных модулей разных вендоров (т.е. эти модули не входят в «ядро» решений FWM, но обладают очень полезным сопутствующим функционалом):
Модуль управления приложениями (опциональный модуль) — предназначен для менеджеров корпоративных приложений. Модуль позволяет абстрагироваться от сетевых устройств и задать сетевые требования для распределенных приложений. Например, можно определить сегмент пользователей приложения, сервер приложения, сервер БД, сервер реплики БД, задать, по каким протоколам эти компоненты между собой общаются, и назвать эту конструкцию «интернет-магазин». Далее одним кликом можно сформировать заявку на предоставление необходимого доступа. В дальнейшем все изменения конфигураций сетевых устройств будут проверяться на предмет нарушения доступности приложения.
Модуль приоритизации уязвимостей (опциональный модуль) — обеспечивает контекстное управление уязвимостями. Этот модуль может «наложить» уязвимости на карту сети и определить, какие из найденных уязвимостей могут быть проэксплуатированы злоумышленником, а какие нет. Таким образом выполнится приоритизация уязвимостей, и администратор ИБ может ставить может ставить четкие задачи и адекватные сроки устранения уязвимостей для системных и сетевых администраторов, а не отправлять им необработанную «портянку» всех найденных в IT-инфраструктуре компании дыр.
В этом классе решений на российском рынке наиболее зрелые решения, по нашему скромному мнению, это AlgoSec, Skybox Security и Tufin. Есть и другие решения (из наиболее известных это FireMon Security Manager, ManageEngine Firewall Analyzer, RedSeal), но большого распространения в СНГ они пока что не получили.
Архитектура каждого из решений предельно проста:
коллекторы, выполняющие сбор информации с сетевых устройств и\или систем путем подключения к ним (ssh, telnet, API, подключение напрямую к базе данных и пр.) и выполнения необходимых команд (например, show conf, show routing и пр.). Всю собранную информацию коллекторы парсят и передают на сервер.
сервер, выполняющий сбор и аналитику информации от коллекторов, обеспечивающий интерфейс взаимодействия с администратором и выдающий отчетность.
Каждым решением можно управлять, используя браузер, в некоторых случаях потребуется устанавливать «толстый» клиент.
Схема лицензирования у вышеуказанных решений похожа: нужно лицензировать каждый загружаемый в решение актив (сетевое устройство, МСЭ и пр.).
Давайте теперь предметно разберём каждое из FWM-решений, обсудим специфику их работы и какие проблемы они позволяют решить ИТ и ИБ-администраторам.
Skybox Security
И чтобы эта статья не была похожа на мой диплом, полный воды, принесла как можно больше полезного, сразу предлагаю рассмотреть более детально решение Skybox Security.
Общая архитектурная схема Skybox Security
Skybox может взаимодействовать с большим количеством систем различных типов: межсетевые экраны, IPS, сетевые устройства уровня L3, балансировщики нагрузки, системы патч-менеджмента, системы Threat Intelligence, сканеры уязвимостей и пр. Актуальную информацию о возможных интеграциях Skybox можно найти тут. Обратите внимание, что Skybox умеет интегрироваться и с отечественными решениями: сканером уязвимостей MaxPatrol 8, криптошлюзами Dionix-NX, Континентом 3.9 ЦУС, а с недавних пор (немного похвастаюсь) при нашем содействии еще и с ViPNet Coordinator (for Linux и HW).
Функционал модулей Skybox Security
Network Assurance
Модуль Network Assurance (NA) предназначен для работы с сетевыми устройствами (L3) и может функционировать как самостоятельно, так и в комбинации с другими модулями. Он позволяет выполнять:
Сбор конфигураций со всех поддерживаемых сетевых устройств (L3) и автоматическое построение карты сети на основе данных из собранных конфигурационных файлов и сведений о маршрутизации (в том числе динамические протоколы!). Про карту сети в Skybox и ее назначение можно говорить долго и написать не одну статью. Если кратко, то каждая уважающая себя организация должна хорошо представлять, что она защищает (активы), а также какие есть уязвимые места в этих активах. Инвентаризация сети обычно выполняется CMDB-системами, информацию об уязвимостях приносят сканеры уязвимостей (например, MaxPatrol 8). Однако, чтобы понимать насколько те или иные уязвимости на конкретных активах ДЕЙСТВИТЕЛЬНО критичны, нужно знать может ли злоумышленник до них «дотянуться». Здесь как раз и может помочь Skybox – собрав всю информацию из CMDB (об активах), из сканеров уязвимостей (об уязвимостях на активах) и сетевого оборудования (маршруты, ACL, IPS-сигнатуры), Skybox может построить карту сети, наложить на нее найденные уязвимости в активах и подсказать какие уязвимости нужно закрыть в первую очередь (до которых потенциально может добраться нарушитель).
Пример карты сети в Skybox:
Контроль соответствия конфигураций сетевых устройств заданным стандартам конфигурирования и лучшим практикам производителей, включая локальные принятые правила конфигурирования (например, вы хотите убедиться, что ни на одном устройстве нет локальной учетной записи «administrator», или нужно убедиться, что на всех устройствах Cisco в сети организации установлен определенный NTP и т.д.);
Вычисление и визуализацию на карте сети возможных путей/маршрутов прохождения заданного типа трафика с демонстрацией разрешающих и запрещающих правил/настроек на всех промежуточных L3 устройствах сети для данного пути/маршрута (построив карту сети, Skybox может вычислить пути прохождения трафика самостоятельно и при соответствующем запросе пользователя может показать этот маршрут. При этом, если трафик где-то блокируется, Skybox укажет где именно трафик блокируется и каким именно ACL);
Создание политики сетевого доступа (сетевого сегментирования) и автоматический контроль ее исполнения как в масштабах всей модели сети, так и на уровне настроек отдельных устройств (например, у вас в сети есть сетевые зоны APP, DB, DMZ и другие, вам необходимо точно знать, что везде соблюдаются правила «Из DB в другие зоны запрещены исходящие подключения», «Из APP в DB разрешены исходящие подключения, но из APP в DMZ запрещены», «Из DMZ в APP разрешены исходящие подключения, но только по определенным портам» и пр. Можно эти формальные правила переложить в настройки (хоть регулярными выражениями, хоть обычным указанием зон и параметров взаимодействия этих зон) и внести в Skybox и далее он автоматизировано и регулярно будет выполнять проверку соответствия этим правилам). Пример политик на основе PCI DSS:
Firewall Assurance
Модуль Firewall Assurance (FA) предназначен для работы с межсетевыми экранами, и может функционировать как самостоятельно, так и в комбинации с другими модулями. Межсетевыми экранами для Firewall Assurance могут выступать как непосредственно сами МСЭ, так и другие поддерживаемые сетевые устройства, использующие списки доступа (ACL) и сигнатуры IPS. Модуль осуществляет постоянный мониторинг всех МСЭ на соответствие политикам, оптимизирует правила на этих МСЭ, осуществляет непрерывный мониторинг настроек межсетевых экранов. FA позволяет выполнять:
Автоматический сбор конфигураций МСЭ и непрерывный мониторинг настроек, включая отслеживание всех изменений на МСЭ;
Оптимизацию списков доступа в МСЭ:
2. Выявление редко используемых правил и объектов (если направить syslog из МСЭ в Skybox, на основе статистики использования тех или иных правил или объектов Skybox может выяснить какие именно объекты не используются на МСЭ. В том числе анализируется hitcount для каждого правила). Пример найденных неиспользуемых объектов;
Пример найденных редко используемых объектов:
3. Формирование рекомендаций по оптимизации правил (на основе собранной информации из hitcount каждого ACL и информации из syslog с МСЭ Skybox может предложить, как оптимизировать объект или правило или указать на то, что не используется вовсе);
Контроль соответствия конфигураций МСЭ заданным стандартам конфигурирования и лучшим практикам, включая локальные правила конфигурирования, а также указание причины несоответствия вплоть до конкретных правил на конкретных устройствах (аналогично похожему функционалу в модуле Network Assurance, но только для МСЭ);
Выявление правил, содержащих «any» в 2 или 3 полях, в поле «сервис» и т.д.;
Выявление настроек, противоречащих рекомендациям производителей с точки зрения безопасности;
Выявление настроек, разрешающих передачу паролей в открытом виде (подключение к CLI с использованием telnet) и т.д.;
Пример найденного нарушения политики «Any» в двух и более полях (всегда можно провалиться в каждое правило и увидеть его детали):
Пример встроенных политик написания ACL:
Change Manager
Change Manager (CM) является дополнением к модулю Firewall Assurance (FA), при этом количество лицензий CM всегда должно соответствовать FA. CM позволяет контролировать и автоматизировать процесс изменения правил доступа от заведения заявки до ее выполнения и гарантирует то, что все изменения произведены в полном соответствии с принятым регламентом предоставления сетевого доступа (Workflow). CM позволяет выполнять:
создание Workflow на изменение сетевого доступа за счет встроенной системы заявок или интеграции с внешними тикет-системами с использованием REST или SOAP API (Remedy, OTRS и пр.);
предоставление или изменение сетевого доступа;
периодический пересмотр правил сетевого доступа;
выявление изменений правил и настроек, выполненных без соответствующей заявки или согласования;
автоматическое выделение устройств, на которых необходимо произвести изменения;
формирование рекомендаций по вносимым изменениям конфигураций МСЭ при изменении сетевых доступов;
автоматическое применение планируемых изменений правил МСЭ (не для всех МСЭ, об этом ниже);
автоматическую оценку влияния планируемых изменений на политику сетевого доступа и безопасного конфигурирования, а также (в случае наличия модуля Vulnerability Control) на защищенность ИТ-активов (серверов, компьютеров, сетевых устройств) с точки зрения появления дополнительных уязвимостей, связанных с изменением.
Проще говоря, СМ позволяет визуализировать, оптимизировать процесс изменения ACL на МСЭ, формализовать процесс внесения изменений на МСЭ с отметками о согласовании всех заинтересованных лиц. Пример тикета в СМ (сверху как раз указан типовой Workflow: Request — Technical details — Risk Assessment — Implementation details — Verification. Таких Workflow может быть несколько — каждый под определенные задачи):
CM поддерживает изменение правил доступа на следующем оборудовании:
Добавление правила
Add Rule
Добавление объекта
Add Object
Изменение правила
Modify Rule
Изменение объекта
Modify Object
Удаление / отключение правила
Delete / Disable Rule
Управление глобальными объектами