скайбокс что это такое
Как создаются скайбоксы в играх — опыт художника World of Warcraft Статьи редакции
Из каких элементов состоит небо, и как применяется техника мэт-пэйнтинг.
Художник по окружению World of Warcraft Филипп Чжан рассказал изданию 80 Level о своём опыте создания скайбоксов для игр. Чжан дал несколько советов, а также подробно описал, из каких элементов обычно состоит небо в играх. Мы выбрали из текста главное.
В команде разработчиков World of Warcraft рабочий процесс устроен так, что художник самостоятельно создаёт ассет от начала до конца — сперва рисует концепт, затем моделирует и текстурирует. За время, проведённое в студии, Чжан успел поработать над разным контентом. Важный урок, который он вынес для себя — у каждого ассета есть своя история, личность и происхождение.
Например, орочьи ворота были бы сделаны из грубо обработанных досок, покрытых трещинами, и оформленных костями животных и металлическими шипами. У врат Ночных эльфов были бы пышные разросшиеся виноградные лозы и молодые деревья, украшенные дикими лесными цветами и плодами — эта раса стремится сохранять природу. Чжан считает, что художнику гораздо легче придумать интересный дизайн, если он чётко понимает историю каждого элемента.
Чжан рассказал, что в работе художника по окружению очень важно заботиться о впечатлении, которое производит вся сцена целиком. Красивое дерево может выглядеть прекрасно само по себе, но оно может испортить всю композицию, так как будет перетягивать всё внимание на себя. Художник по окружению должен постоянно думать о соотношении цвета и формы между всеми ассетами, чтобы вся сцена выглядела хорошо.
Когда Чжан создаёт скайбокс, он старается воспринимать его не только как отдельный фрагмент, который рассказывает историю, но и как фоновое изображение, которое сливается с остальной сценой.
В августе прошлого года он стал первым художником по окружению, который начал работать над Shadows of Argus. Чтобы проиллюстрировать разрушенный родной мир Эредаров, разработчики решили использовать мэт-пэйнтинг в скайбоксах World of Warcraft.
Чжан столкнулся с необходимостью рассказать игрокам историю мира Аргус, который тысячи лет назад был завоёван и сокрушён демоническим Пылающим Легионом.
Уже на этапе блокинга художник постарался показать последствия нападения — пейзажи разрушенных городов, демонические крепости, извергающиеся вулканы. Позже, когда другие художники и дизайнеры реализовали большую часть игрового пространства, Чжан убрал некоторые элементы, которые привлекали слишком много внимания. Затем он сделал скриншоты окружения, чтобы использовать их в мэт-пэйнтинге.
Небо в World of Warcraft — это изображение, которое простирается за пределы игрового пространства. Оно вызывает у игроков определённые эмоции при помощи света, теней и цвета. Скайбоксы сильно зависят от настроения, истории и климата каждого места. Также команда добавляет динамические погодные системы, такие как дождь и снег, чтобы сделать мир разнообразнее.
Синим цветом изображён основной меш скайбокса. Для него могут использоваться тайловые текстуры, например, звёзды, облака — всё, что способно передать определённое настроение.
Зелёным изображён меш с облаками, который постепенно поворачивается для имитации движения. Также он используется для создания удалённых объектов пейзажа — гор, полей.
Жёлтые прямоугольники олицетворяют отдельные объекты — единичные облака или парящие острова. Красным изображены визуальные эффекты — водопады, дым, огонь, энергия и так далее. Фиолетовым — земля, по которой ходит игрок.
По словам Чжана, процесс создания скайбоксов при помощи мэт-пэйнтинга не слишком отличается от обычного подхода. Вот как это выглядит.
Первое изображение — это фотография на 180 градусов, сделанная на крыше паркинга. На втором изображении зелёным показана игровая зона, по которой передвигается пользователь. Всё остальное — мэт-пэйнтинг скайбокс. Третье изображение — это устройство самого скайбокса со всеми элементами.
Синий цвет — фон. Травяной зелёный — несколько слоёв облаков, движущихся на разной скорости. Ярко-зелёный — мэт-пэйнтинг гор и деревьев. Жёлтый — мэт-пэйнтинг парящего города. Жёлто-коричневый — движущиеся космические корабли. Красный — огонь и дым от вулкана. Красно-коричневый — свет от маяка. Розовый — огонь от двигателей космических кораблей.
Когда вы решаете, какие элементы добавить в сцену, подумайте, что вы можете действительно перенести в неё. Например, гора с высокими соснами может простираться на сотни миль в мэт-пэйнте вашего скайбокса — это добавит окружению глубины.
Скайбокс — это фон сцены. Если они будут ощущаться отделёнными друг от друга, то это плохо скажется на погружении игроков. Цвета, формы и освещение в скайбоксе всегда должны перекликаться с элементами на переднем плане. Вы также должны учитывать, как работает человеческий глаз, когда он рассматривает окружение на расстоянии. Вещи, которые находятся дальше от человека, обычно менее контрастны по сравнению с тем, что он видит прямо перед собой. То же самое относится и к ассетам для скайбоксов.
По мнению Чжана, мэт-пэйнтинг отлично подходит для создания неба и пейзажей в играх. Чтобы сделать в 3D разрушенный древний город в джунглях или горящий корабль в небе, могут потребоваться тысячи часов. Но похожего эффекта можно достичь при помощи мэт-пэйнтинга, холста размером 2048×2048 пикселей и пары недель работы.
10 июня поставщик спутниковых карт и фотоснимков Skybox сообщил о сделке с Google ценой полмиллиарда долларов. Редакция Mashable разобралась, почему крупная ИТ-компания выложила такие деньги за стартап, о котором мало кто слышал.
Команда Skybox
Беркеншток на тот момент уже три года как получал PhD в области инженерии в Стэнфорде. Он собрал группу студентов, нашел нескольких инвесторов и решил стать участником этого необычного соревнования.
Создание первого образца заняло у них год, как вспоминает Хуан Алонсо, профессор аэронавтики из Стэнфорда. Предпринимательский дух и умение «гореть идеей» выделяли Дэна Беркенштока среди сверстников.
Но всё пошло не совсем так, как было задумано. В 2008 году случился экономический кризис, и те, кто вкладывал в разработки, связанные с Луной (в том числе — и в Стэнфорде), вынуждены были отказаться от финансирования программ: деньги были нужны всем, и не для покорения космоса. В 2013 году Беркеншток вспомнил об этой ситуации в ходе одного из семинаров как важном уроке для всех, кто тогда занимался тем «космическим» стартапом.
Но молодой предприниматель и ученый не стал опускать руки. Он объединил свои усилия с двумя другими стэнфордскими студентами — Джоном Фенвиком (который успел отслужить в ВВС США) и Джулиан Мэнн (основатель Astronautical Development). Чуть позже к ним присоединилась Чинг-Ю Ху, работавшая аналитиком в J.P. Morgan. Вместе они запустили проект Skybox. Произошло это в начале 2009 года.
Основатели Skybox (слева направо): Дэн Беркеншток, Чинг-Ю Ху, Джулиан Манн и Джон Фенвик. Фото: INC
Изначально основатели планировали запускать маленькие дешевые спутники на орбиту для получения с них информации из космоса. Оригинальный проект компании представлял собой небольшие аппараты CubeSats. Их разработали в Стэнфорде в 1999 году, запуск на орбиту должен был быть дешевым. В процессе работы и регулярных испытаний команда перешла к спутникам весом 90 кг. На такие спутники можно было устанавливать компьютерное и телескопическое оборудование для получения качественных фотоснимков и передачи их из космоса на Землю.
В проекте Skybox не было ничего, что могло бы заинтересовать традиционных венчурных капиталистов, а риски были достаточно велики при том, что область применения разработки была нишевая.
Даже несмотря на эту маленькую победу, никто не воспринимал перспективы Skybox всерьез до ноября 2013 года. Именно тогда первый спутник частного производства SkySat-1 был запущен на орбиту и начал передавать снимки и данные из космоса. Целью разработчиков было создание не просто спутников, а работающего сервиса, который бы аккумулировал собранные данные и фотографии для последующей продажи их клиентам, готовым платить. Сфера применения была достаточно обширная — от наблюдений за сбором урожая до исследования поведения потребителей в конкретных географических регионах.
Запуск спутника и первые результаты его работы впечатлили потенциальную аудиторию. К команде стартапа начали обращаться первые клиенты. Особенно заинтересовались новинкой аэрокосмические и спутниковые компании, ряд ИТ-фирм. Источники, близкие к Skybox, утверждают, что среди тех, кто связывался с командой стэнфордского стартапа, были представители Facebook и Amazon (активно вкладывающих средства в дроны и беспроводной доступ в интернет), а также Apple (больше интересовались возможностями спутниковой фотосъемки для своего картографического сервиса).
И хотя Google не была единственной компанией, заинтересованной в покупке Skybox, сделка с ней выглядела вполне логичным шагом. Корпорация стала одним из ранних покупателей услуг Skybox. Сам стартап разместил свои производственные мощности в Маунтин-Вью, неподалеку от штаб-квартиры Google.
Сделка с Google давала доступ команде стартапа к обширным финансовым и кадровым ресурсам. Для Google покупка Skybox означала улучшение качества карт и расширение возможностей для организации беспроводного доступа в интернет.
Некоторые из венчурных инвесторов, которые вкладывали деньги в проект еще в 2009 году, не очень довольны, что всё обернулось продажей. Стартап, который занимается космическими технологиями, встречается не так уж часто, говорят такие инвесторы. Но что сделано, то сделано.
В блоге команда Skybox утверждает, что продажу воспринимает, не как самоцель, а как новый вызов своим возможностям, ведь в составе Google задач и целей будет намного больше.
Как управлять сетью — класс решений 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
Управление глобальными объектами