Русский
Русский
English
Статистика
Реклама

Utm

2. FortiAnalyzer Getting Started v6.4. Подготовка макета

06.10.2020 08:16:20 | Автор: admin


Приветствуем на втором уроке курса FortiAnalyzer Getting Started. Сегодня мы поговорим про механизм административных доменов на FortiAnalyzer, также обсудим процесс обработки логов понимание принципов работы данных механизмов необходимо для первоначальных настроек FortiAnalyzer. И после этого мы обсудим макет, который будем использовать в ходе курса, а также проведем начальную конфигурацию FortiAnalyzer. Теоретическая часть, а также полная запись видеоурока находятся под катом.

Для начала еще раз поговорим про административные домены. Есть несколько вещей, которые необходимо про них знать, перед тем, как начать использовать:

  1. Возможность создания административных доменов включается и отключается централизованно.
  2. Для регистрации любых устройств, кроме FortiGate, необходим отдельный административный домен. То есть, если вы хотите зарегистрировать на устройстве несколько устройств FortiMail, вам необходим отдельный административный домен для этого. Но это не отменяет того, что для удобства группировки устройств FortiGate можно создавать различные административные домены.
  3. Максимальное число поддерживаемых административных доменов зависит от модели устройства FortiAnalyzer.
  4. При включении возможности создания административных доменов необходимо выбрать режим их работы Normal или Advanced. В режиме Normal нельзя добавлять различные виртуальные домены (или по другому VDOMы) одного FortiGate в различные административные домены устройства FortiAnalyzer. В Advanced режиме такое возможно. Режим Advanced позволяет обрабатывать данные различных виртуальных доменов и получать по ним отдельную отчетность. Если вы забыли, что такое виртуальный домены, посмотрите второй урок курса Fortinet Getting Started, там это рассказано довольно подробно.

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

Теперь поговорим о механизме записи и обработки логов, поступающих на FortiAnalyzer.
Логи, поступающие на FortiAnalyzer, сжимаются и сохраняются в log файл. Когда этот файл достигает определенного размера, он перезаписывается и архивируется. Такие логи называются архивированными. Они считаются оффлайн логами, поскольку их невозможно проанализировать в реальном времени. Для просмотра они доступны только в raw формате. Политика хранения данных в административном домене определяет, сколько такие логи будут храниться в памяти устройства.
В это же время логи индексируются в базе данных SQL. Данные логи используются для анализа данных с помощью механизмов Log View, FortiView и Reports. Политика хранения данных в административном домене определяет, сколько такие логи будут храниться в памяти устройства. После того, как данные логи будут удалены из памяти устройства, они могут остаться в виде архивированных логов, но это зависит от политики хранения данных в административном домене.

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



На нём вы видите 6 устройств FortiGate, FortiMail, FortiAnalyzer, контроллер домена, компьютер внешнего пользователя и компьютер внутреннего пользователя. FortiGate и FortiMail необходимы для генерации логов различных устройств Fortinet, чтобы на примере рассмотреть аспекты работы с различными административными доменами. Внутренний и внешний пользователи, а также контроллер домена необходимы для генерации различного трафика. На компьютере внутреннего пользователя установлена ОС Windows, а на компьютере внешнего Kali Linux.
В данном примере FortiMail работает в режиме Server, то есть является отдельным почтовым сервером, с помощью которого внутренний и внешний пользователи могут обмениваться электронными сообщениями. Необходимые настройки, такие как MX записи, сконфигурированны на контроллере домена. Для внешнего пользователя DNS сервером является внутренний контроллер домена это осуществлено с помощью проброса портов (или по другому технологии Virtual IP) на FortiGate.
Эти настройки не рассматриваются в ходе урока, поскольку они не относятся к теме курса. Будут рассмотрены развертывание и начальная конфигурация устройства FortiAnalyzer. Остальные составляющие текущего макета были подготовлены заранее.

Системные требования, предъявляемые к различным устройствам, представлены ниже. У меня данный макет работает на заранее подготовленной машине в виртуальной среде VMWare Workstation. Характеристики данной машины также указаны ниже.
Устройство RAM, GB vCPU HDD, GB
Контроллер домена 6 3 40
Внутренний пользователь 4 2 32
Внешний пользователь 2 2 8
FortiGate 2 2 30
FortiAnalyzer 8 4 80
FortiMail 2 4 50
Машина для макета 28 19 280
Системные требования, приведенные в данной таблице, являются минимальными в реальных условиях обычно необходимо выделять больше ресурсов. Дополнительную информацию по системным требованиям можно найти на данном сайте.

В видеоуроке представлены теоретический материал, рассмотренный выше, а также практическая часть с начальной конфигурацией устройства FortiAnalyzer. Приятного просмотра!


На следующем уроке мы подробно рассмотрим аспекты работы с логами. Чтобы не пропустить его, подписывайтесь на наш Youtube канал.

Также можете следить за обновлениями на следующих ресурсах:

Группа Вконтакте
Яндекс Дзен
Наш сайт
Телеграм канал
Подробнее..

3. FortiAnalyzer Getting Started v6.4. Работа с логами

13.10.2020 08:16:54 | Автор: admin


Приветствуем вас на третьем уроке курса FortiAnalyzer Getting Started. На прошлом уроке мы развернули макет, необходимый для выполнения лабораторных работ. На этом уроке мы рассмотрим основные принципы работы с логами на FortiAnalyzer, познакомимся с обработчиками событий, а также рассмотрим механизмы защиты логов. Теоретическая часть, а также полная запись видеоурока находятся под катом.

Для того, чтобы собирать логи с устройств, их необходимо зарегистрировать на FortiAnalyzer. Существует два варианта регистрации:
Первый вариант на регистрируемом устройстве активируется опция отправлять логи на FortiAnalyzer и указывается его IP адрес. После этого, на FortiAnalyzer отправляется запрос на регистрацию данного устройства. Администратор должен подтвердить или отклонить полученный запрос. Если технология административных доменов активирована, FortiGate можно добавить как в основной ADOM (который называется root, с ним мы работали в прошлом уроке), так и в собственноручно созданный ADOM, который предназначен для устройств FortiGate.
Второй вариант так называемый Device Registration Wizard. Регистрация устройства происходит на самом FortiAnalyzer. Для регистрации необходима информация о регистрируемом устройстве серийный номер, IP адрес, тип устройства, и версия операционной системы. Если верификация данных проходит успешно устройство добавляется в список FortiAnalyzer. Если технология административных доменов активирована, устройство автоматически зарегистрируется в подходящем административном домене. Если у вас создано несколько подобных административных доменов, в таком случае необходимо зарегистрировать устройство с того административного домена, в который вы хотите его добавить.

Каждое устройство генерирует логи различных типов. Основные типы логов, которые могут генерировать устройства компании Fortinet, представлены на рисунке ниже.



Про начальную обработку логов мы уже говорили на прошлом уроке, но думаю стоит освежить память. Логи, поступающие на FortiAnalyzer, сжимаются и сохраняются в log файл. Когда этот файл достигает определенного размера, он перезаписывается и архивируется. Такие логи называются архивированными. Они считаются оффлайн логами, поскольку их невозможно проанализировать в реальном времени. Для просмотра они доступны только в RAW формате. Политика хранения данных в административном домене определяет, сколько такие логи будут храниться в памяти FortiAnalyzer.
В это же время логи индексируются в базе данных SQL для поддержки аналитики. Данные логи анализируются в FortiAnalyzer в режиме реального времени с помощью механизмов Log View, FortiView и Reports. Политика хранения данных в административном домене определяет, сколько такие логи будут храниться в памяти FortiAnalyzer. После того, как данные логи будут удалены из памяти FortiAnalyzer, они могут остаться в виде архивированных логов, но это зависит от политики хранения данных в административном домене.
Схематично процесс обработки логов представлен на рисунке ниже.



Когда логи поступают на устройство, их проверяют обработчики событий. Они позволяют отследить интересующие события с помощью преднастроенных условий. Условия устанавливаются к параметрам, содержащимся в логах RAW формата. В системе для каждого административного домена существует набор предустановленных событий, однако при необходимости можно создавать собственные обработчики событий. Основная польза обработчиков событий в том, что при возникновении интересующих событий система может отсылать уведомления на email или syslog сервера также через SNMP. Это позволяет довольно быстро реагировать на события, происходящие в сети.



Теперь поговорим о защите логов. Поскольку в логах хранится важная информация о происходящем в сети, их нужно защищать как от возможной потери в результате различных сбоев, так и от внешней компрометации. Первая технология, которая поможет защитить логи в случае различных сбоев, это RAID. Она позволяет разбить пространство из доступных дисков на несколько логических сегментов таким образом, чтобы при выходе из строя одного или нескольких дисков (в зависимости от типа RAIDа) данные не потерялись. Основные типы RAID, которые можно использовать в FortiAnalyzer, представлены на рисунке ниже.



  • RAID 0 распределяет информацию на 2 или более диска. Главная цель скорость и производительность. При выходе одного или нескольких дисков из строя пострадает весь дисковый массив;
  • RAID 1 распределяет копии информации на 2 или более диска. Если один диск выйдет из строя дисковый массив продолжит работать в обычном режиме;
  • RAID 5 распределяет информацию по нескольким дискам, и также в каждой так называемой цепочке информации выделяет один диск под данные для восстановления. При выходе одного диска из строя дисковый массив продолжит работать в обычном режиме;
  • RAID 6 действует похожим образом, только под данные для восстановления выделено уже два диска;
  • RAID 10 объединяет опции RAID 0 и RAID 1. С помощью этого можно будет продолжать работу с информацией, если выйдут из строя 2 диска (по одному из каждого рейда, иначе считать информацию будет невозможно);
  • RAID 50 комбинирует функционал RAID 0 и RAID 5. В таком случае стабильная работа с информацией продолжится, даже если в каждом RAID 5 выйдет из строя один диск;
  • RAID 60 комбинирует функционал RAID 0 и RAID 6. В таком случае стабильная работа с информацией продолжится, даже если в каждом RAID 6 выйдут из строя 2 диска.

Следующий механизм бэкапы логов. Есть несколько вариантов бэкапов из меню Log View, где можно использовать определенный фильтр для сохранения необходимых логов, или Log Browse, откуда можно скачать записанные log файлы. Также есть возможность сделать бэкап логов на внешние сервера с помощью CLI интерфейса.

Еще один механизм, позволяющий защитить важную информацию, содержащуюся в логах избыточность. Здесь также есть несколько вариантов:
Первый, при котором устройства шлют логи сразу на 2 FortiAnalyzerа один из них основной, другой резервный.
Второй метод мы уже обсуждали на прошлом уроке один FortiAnalyzer работает в режиме коллектора и собирает логи с различных устройств. По расписанию собранные логи отправляются на FortiAnalyzer, который работает в режиме Analyzer. В случае выхода второго из строя, коллектор сможет переслать логи на другой FortiAnalyzer.
И третий вариант передача логов с FortiAnalyzerа на внешние сервера, например на Syslog. В таком случае передача логов будет происходить в реальном времени.



Для защиты логов от компрометации используются два основных механизма:

  1. Шифрование канала передачи данных между FortiAnalyzerом и остальными устройствами;
  2. Защита логов от модификации путем добавления контрольной суммы.




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



На следующем уроке мы подробно рассмотрим аспекты работы с отчетами. Чтобы не пропустить его, подписывайтесь на наш Youtube канал.

Также можете следить за обновлениями на следующих ресурсах:

Группа Вконтакте
Яндекс Дзен
Наш сайт
Телеграм канал
Подробнее..

4. FortiAnalyzer Getting Started v6.4. Работа с отчетами

20.10.2020 08:07:37 | Автор: admin


Приветствую, друзья! На прошлом уроке мы изучили основы работы с логами на FortiAnalyzer. Сегодня мы пойдем дальше и рассмотрим основные аспекты работы с отчетами: что из себя представляют отчеты, из чего они состоят, каким образом можно редактировать существующие и создавать новые отчеты. Как обычно, сначала немного теории, а после поработаем с отчетами на практике. Под катом представлена теоретическая часть урока, а также видеоурок, включающий в себя как теорию, так и практику.

Основная цель отчетов объединить большие объемы данных, содержащихся в логах, и на основе имеющихся настроек представить всю полученную информацию в читабельном виде: в виде графиков, таблиц, диаграмм. На рисунке ниже приведен список предустановленных отчетов для устройств FortiGate (в нем поместились не все отчеты, но, думаю, уже из этого списка видно, что даже из коробки можно построить множество интересных и полезных отчетов).



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

Главные составляющие отчетов это чарты. Каждый отчет состоит из одного или нескольких чартов. Чарты определяют, какую информацию необходимо извлечь из логов, и в каком формате ее представить. За извлечение информации отвечают датасеты SELECT-запросы в базу данных. Именно в датасетах точно определяется, откуда и какую именно информацию необходимо извлекать. После того, как в результате запроса появляются необходимые данные, к ним применяются настройки формата (или отображения). В результате полученные данные оформляются в таблицы, графики или диаграммы различного типа.

В SELECT-запросе используются различные команды, с помощью которых задаются условия к извлекаемой информации. Самое важное, что стоит учесть данные команды должны применяться в определенном порядке, именно в таком порядке они приведены далее:
FROM единственная из команд, которая является обязательной в SELECT-запросе. Она указывает на тип логов, из которых необходимо извлекать информацию;
WHERE с помощью этой команды задаются условия к логам (например, определенное имя приложения/атаки/вируса);
GROUP BY эта команда позволяет сгруппировать информацию по одному или нескольким интересующим столбцам;
ORDER BY с помощью этой команды можно упорядочить вывод информации по строкам;
LIMIT Ограничивает количество возвращаемых запросом записей.

FortiAnalyzer содержит предустановленные шаблоны для отчетов. Шаблоны являются так называемым макетом отчета они содержат текст отчета, его чарты и макросы. С помощью шаблонов можно создавать новые отчеты, если в предустановленных требуются минимальные изменения. Однако предустановленные отчеты нельзя редактировать и удалять можно их склонировать, и над копией производить необходимые изменения. Также есть возможность создавать собственные шаблоны для отчетов.



Иногда можно столкнуться со следующей ситуацией: предустановленный отчет подходит под задачу, но не полностью. Возможно, в него нужно добавить какую-нибудь информацию, или, наоборот удалить. В таком случае есть два варианта: склонировать и изменить шаблон, или же сам отчет. Здесь нужно опираться на несколько факторов:
Шаблоны являются макетом для отчета, они содержат чарты и текст отчета, не более того. Сами отчеты, в свою очередь, помимо так называемого макета содержат различные параметры отчета: язык, шрифт, цвет текста, период генерации, фильтрация информации и так далее. Поэтому, если необходимо внести изменения только в макет отчета, можно использовать шаблоны. Если необходима дополнительная конфигурация отчета, можно редактировать сам отчет (а точнее его копию).
На основе шаблонов можно создавать несколько однотипных отчетов, поэтому если предстоит сделать множество похожих друг на друга отчетов, то предпочтительнее использовать шаблоны.
В том случае, если предустановленные шаблоны и отчеты вам не подходят, можно создать как новый шаблон, так и новый отчет.



Также на FortiAnalyzer существует возможность настроить пересылку отчетов отдельным администраторам на электронную почту или их выгрузку на внешние сервера. Делается это с помощью механизма Output Profile. В каждом административном домене настраиваются отдельные Output Profiles. При конфигурации Output Profile определяются следующие параметры:

  • Форматы отсылаемых отчетов PDF, HTML, XML или CSV;
  • Место, куда будут отсылаться отчеты. Это может быть электронная почта администратора (для этого необходимо привязать FortiAnalyzer к почтовому серверу, это мы рассматривали на прошлом уроке). Также это может быть внешний файловый сервер FTP, SFTP, SCP;
  • Можно указать, что делать с локальными отчетами, которые остались на устройстве после пересылки оставить их или удалить.

При необходимости есть возможность ускорить генерацию отчетов. Рассмотрим два способа:
При создании отчета FortiAnalyzer строит чарты из предварительно скомпилированных данных кэша SQL, известных как hcache. Если данные hcache не созданы при запуске отчета, система должна сначала создать hcache, а затем построить отчет. Это увеличивает время формирования отчета. Однако если новые логи для отчета не получены, при повторной генерации отчета время его генерации значительно уменьшится, поскольку данные hcache уже скомпилированы.
Чтобы повысить производительность генерации отчетов, можно включить автоматическое создание hcache в настройках отчета. В этом случае hcache автоматически обновляется при поступлении новых логов. Пример настройки приведен на рисунке ниже.
Этот процесс использует большое количество системных ресурсов (особенно для отчетов, требующих длительного времени для сборки данных), поэтому после включения необходимо наблюдать за состоянием FortiAnalyzer: сильно ли возросла нагрузка, присутствует ли критическое потребление системных ресурсов. В случае, если FortiAnalyzer не справляется с нагрузкой, данный процесс лучше отключить.
Также следует отметить, что автоматическое обновление данных hcache по умолчанию активировано для запланированных отчетов.

Второй способ ускорить генерацию отчетов группировка:
Если одни и те же (или похожие) отчеты генерируются для различных устройств FortiGate (или других устройств Fortinet), можно значительно ускорить процесс их генерации путем группировки. Группировка отчетов может уменьшить количество таблиц hcache и ускорить время автоматического кэширования, вследствие чего ускорить генерацию отчетов.
В примере, приведенном на рисунке ниже, отчеты, в названии которых содержится строка Security_Report, группируются по параметру Device ID.



В видеоуроке представлен теоретический материал, рассмотренный выше, а также рассматриваются практические аспекты работы с отчетами от создания собственных датасетов и чартов, шаблонов и отчетов до настройки пересылки отчетов администраторам. Приятного просмотра!



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

Также можете следить за обновлениями на следующих ресурсах:

Группа Вконтакте
Яндекс Дзен
Наш сайт
Телеграм канал
Подробнее..

5. FortiAnalyzer Getting Started v6.4. Сопровождение и лицензирование

27.10.2020 08:18:20 | Автор: admin

Всем привет! Добро пожаловать на заключительный урок курса FortiAnalyzer Getting Started. Данный урок будет чисто теоретическим: в нем мы рассмотрим все моменты, которые связаны с сопровождением устройства и по каким-то причинам не попали в прошлые уроки. Также мы рассмотрим схему лицензирования FortiAnalyzer. Под катом представлен материал данного урока в виде статьи, а также в форме видеоурока.

В зависимости от инфраструктуры может появиться необходимость распределить административные задачи между разными пользователями. В таком случае на FortiAnalyzer можно создать несколько административных учетных записей. Но стоит понимать, что каждый новый администратор увеличивает риск нарушения безопасности сети.

Для увеличения уровня защищенности сети можно использовать несколько методов контроля административного доступа:

  • Профили администраторов;

  • Доверенные хосты;

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

Рассмотрим каждый из этих методов подробнее.

При создании различных учетных записей администраторов не следует давать им больше привилегий, чем необходимо для выполнения их задач. Для данной цели FortiAnalyzer использует механизм профилей администраторов. Каждый профиль содержит список привилегий, доступных администратору. В системе имеется три преднастроенных профиля администратора:

SuperUser - предоставляет доступ ко всем системным привилегиям и привилегиям на управление устройствами;

StandartUser - предоставляет доступ к привилегиям на управление устройствами, без системных привилегий;

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

Также можно создавать собственные профили администраторов со своим набором привилегий. К каждой учетной записи администратора должен быть применен один из существующих профилей.

В дополнение к профилям администраторов для контроля доступа можно настроить доверенные устройства для каждой учетной записи администратора. Они позволяют обеспечить доступ администратора только с конкретных IP-адресов - устройств или подсетей. К примеру, если настроить одно доверенное устройство с IP-адресом 192.168.232.10, то данный администратор сможет подключаться к FortiAnalyzer только с этого IP-адреса, с других доступ будет запрещен.

Причем, контроль через доверенные устройства распространяется как на Web интерфейс, так и на CLI интерфейс при доступе через SSH.

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

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

Вместо создания администраторов локально к FortiAnalyzer можно привязать внешние серверы аутентификации. Для верификации внешних администраторов могут использоваться LDAP, RADIUS, TACATS+, и PKI. При использовании нескольких серверов аутентификации каждый сервер необходимо привязывать отдельно.

С помощью различных механизмов мониторинга можно отслеживать поведение администраторов, а также выполнение текущих действий. В поле System Settings > Admin > Administrators можно увидеть сессии администраторов: кто сейчас активен, а также их доверенные устройства. По умолчанию только администраторы с профилем Super_User имеют доступ к данному списку.

Отследить активность администраторов можно с помощью меню System Settings > Event Log. Здесь указываются различные действия администраторов, такие как изменения конфигурации, а также удачные или неудачные попытки входа в систему.

В меню System Settings > Task Monitor можно отслеживать статус и прогресс задач, выполняемых на FortiAnalyzer.

Зарегистрированные устройства можно перемещать между административными доменами. Однако не стоит этого делать, пока в этом нет строгой необходимости. Как один из примеров - в одном административном домене содержатся несколько устройств, и некоторые из них генерируют слишком много логов, а другие - наоборот - мало логов. В такой ситуации рекомендуется устройства с высоким уровнем генерации логов поместить в один административный домен, а устройства с низким - в другой. Такой подход способствует эффективному управлению доступным пространством в каждом административном домене.

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

Заметим, что при обновлении операционной системы FortiGate нет необходимости перемещать его в новый административный домен.

Перед тем, как перемещать устройство в другой административный домен, необходимо учесть несколько моментов, особенно если перемещаемое устройство уже собирало логи в старом административном домене:

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

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

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

Остальные моменты, связанные с сопровождением устройства, в том или ином виде обсуждались на прошлых уроках. Поэтому перейдем к лицензированию FortiAnalyzer. Для удобства элементы, составляющие годовую стоимость владения, отмечены зеленым цветом. Существует 5 вариантов покупки устройства:

Первый вариант - физическое устройство и пакет подписок, содержащий также техническую поддержку - в одном артикуле. Удобно при первоначальной покупке. Ежегодной стоимостью владения является уже отдельный пакет подписок, включающий в себя техническую поддержку. Также отдельно можно купить сервис RMA, в таком случае его цена также будет входить в стоимость ежегодного владения. Отметим, что для железного устройства FortiAnalyzer 200F сервис SOC недоступен.

Второй вариант - отдельный артикул на физическое устройство, а также отдельный артикул на пакет подписок, включающий в себя техническую поддержку. Обычно выходит дороже первого варианта. Ежегодной стоимостью владения также является пакет подписок, включающий в себя техническую поддержку. Также отдельно можно купить сервис RMA, в таком случае его цена также будет входить в стоимость ежегодного владения.

Третий вариант - отдельный артикул на физическое устройство, а также отдельные артикулы на каждый вид подписки (IOC или SOC), также отдельные артикулы на техническую поддержку и RMA. В таком случае выбранные отдельные артикулы на сервисы, техническую поддержку и RMA будут составлять ежегодную стоимость владения, если при продлении не будет меняться их состав.

Четвертый вариант - отдельный артикул для базовой виртуальной машины, а также опциональный отдельный артикул на расширение памяти, он также является единоразовым, далее артикулы на техническую поддержку и сервисы IOC и RMA. Ежегодную стоимость владения в данном случае составляют сервис технической поддержки и выбранные сервисы IOC и RMA.

И последний вариант - отдельные артикулы на базовую виртуальную машину и расширение памяти, отдельный артикул с пакетом подписок, включающим в себя техническую поддержку и сервисы IOC и SOC. Также опциональный артикул - сервис RMA. Ежегодная стоимость владения в данном случае считается как цена подписки, и цена RMA, если он также выбран для покупки.

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

Ниже представлен ролик, в котором вся приведенная выше информация представлена в видеоформате:

На этом мы хотим закончить данный курс. Как и отмечалось в его начале, курс получился не слишком объемным, мы постарались вкратце описать основные принципы и возможности продукта FortiAnalyzer. Надеемся, что данный курс будет полезен тем, кто только знакомится с продукцией компании Fortinet, и с FortiAnalyzer в частности. Периодически мы выпускаем статьи, видео, и курсы по различным продуктам компании Fortinet. Чтобы их не пропустить, следите за обновлениями на наших ресурсах:

Youtube канал

Группа Вконтакте

Яндекс Дзен

Наш сайт

Телеграм канал

Подробнее..

Utm-метки в сквозной аналитике особенности и проблемы

20.01.2021 14:20:49 | Автор: admin

Utm-разметка для систем сквозной аналитики тёмный лес или страшный кошмар специалиста?

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

Иречь идёт неотом, имеютсяли укомпании правила разметки для любого изканалов коммуникации. Речь отом, чтобы связать эти каналы воедино ииметь прозрачную структуру utm-меток вовсех каналах сразу. Иэто действительно важная задача.

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

Что такое сквозная аналитика

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

Главной особенностью сквозной аналитики является учёт реально полученной прибыли. Лиды здесь всего лишь промежуточный этап. Нас интересуют реальные продажи сихстоимостью. Тогда при оценке каждого канала, кампании идаже конкретного объявления/письма можно оценить ихэффективность отношение затрат кприбыли.

Рассмотрим пример. Запускаем две рекламных кампании водной рекламной системе. Вличном кабинете мывидим такую статистику:

Затраты

Количество лидов

Стоимость лида

Кампания 1

1000

100

10

Кампания 2

2000

250

8

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

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

Рассматривая данные из CRM в разрезе этих двух кампаний, мы бы увидели вторую и более важную часть, которая ранее не была доступна:

Затраты

Количество лидов

Стоимость лида

Количество продаж

Конверсия впродажу

Кампания 1

1000

100

10

50

50%

Кампания 2

2000

250

8

25

10%

Оказывается, большинство лидов изкампании 2холодные, абольшую прибыль принесла нам кампания 1.

Иэто самый примитивный пример пользы отсквозной аналитики. Насамом деле возможностей оптимизировать затраты иработу открывается куда больше. Можно найти узкие места воронки продаж, усовершенствовать клиентский путь, определить для своего бизнеса наиболее прибыльные каналы продвижения имногое другое.

Вкачестве источников информации выступают всевозможные каналы коммуникации исистемы отслеживания:

  • рекламные кабинеты,

  • социальные сети,

  • коллтрекинг,

  • системы веб-аналитики,

  • сайт,

  • CRM,

  • email-маркетинг,

  • другие источники.

UTM-метки иихцель

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

http://www.example.com/?utmsource=google&utmmedium=cpc&utmcampaign=BF&utmterm=blackfriday&utm_content=toplink

Существует 5основных меток иобщепринятые варианты значений.

Utm_source

Используется для обозначения источника перехода.

Возможные варианты:

yandex/google/facebook/vkontakte

Придерживайтесь единого формата: facebook, Facebook иfb это разные метки ивитоге статистика содного источника будет разбросана нанесколько записей, что усложняет аналитику.

Utm_medium

Используется для обозначения канала или типа рекламного трафика.

Возможные варианты:

cpc/cpa/social/email/sms

Utm_campaign

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

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

utm_campaign=20112020|lal|black-friday

Разделители могут быть практически любыми (кроме & ониспользуется для соединения нескольких utm-меток). Главное условие: разделители смысловых групп ислов внутри группы обязательно должны быть разными.

Ктомуже необходимо придерживаться единого формата записи: если передаётся дата, товсегда вформате ddmmyyyy, если время, товформате hhmmss итак далее.

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

Например, вырешили вкачестве разделителя смысловой группы использовать длинное тире :

utm_campaign=20112020lalblack-friday

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

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

Utm_term

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

Utm_content

Ещё одна дополнительная метка, которая позволяет идентифицировать содержимое, если все предыдущие метки одинаковы. Еёможно использовать вA/B-тестах или определить сеёпомощью наиболее эффективное месторасположение ссылки.

Основные правила сбора меток

Необходимо:

  • соблюдать синтаксис меток;

  • использовать единые стандарты для одинаковых типов значений;

  • соблюдать регистр;

  • корректно разделять при необходимости смысловые группы взначениях меток;

  • незадавать слишком длинные названия для utm-меток (неболее 8Кб).

Подробнее оutm-метках читайте внашей статье.

Счего начать формировать utm-метки всквозной аналитике

Обязательно определите цели изадачи, которые должна решать сквозная аналитика. Выберите необходимые срезы для анализа данных. Спроектируйте кампании таким образом, чтобы они удовлетворяли выше установленным требованиям. Исходя изэтого продумайте utm-разметку.

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

Многие компании построили омниканальную коммуникацию сосвоими клиентами. Аэто значит, что необходимо объединять данные сдесятков источников.

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

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

Чтобы избежать ошибок ипутаницы вразметке, атакже обезопасить свои процессы при смене ЛПР или агентств, япредлагаю наначальных этапах построения utm-разметки регламентировать работу. Для каждого типа канала создайте документ, вкотором детально пропишите правила формирования значений utm-меток. Обязательно проверяйте соответствие значений меток между системами.

Пример регламента для email/push-канала:

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

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

Динамические параметры utm-меток всквозной аналитике

Многие сервисы предоставляют возможность использовать динамические параметры при формировании utm-меток. Укаждого сервиса собственный набор возможных значений динамических параметров, которые позволяют автоматически подставлять вutm-метку соответствующее значение.

Документация для некоторых сервисов:

Яндекс.Директ

Фейсбук

ВКонтакте

Польза для маркетологов неоценима: динамические utm-метки помогают сократить ручной труд иуменьшают вероятность ошибок из-за человеческого фактора.

Аваналитике всё нетак радужно.

Динамические utm-метки всквозной аналитике могут создавать ряд проблем

Нет возврата динамических параметров

Как правило, такие сервисы невозвращают значения динамических параметров через собственное API.

Рассмотрим любой рекламный сервис. Для сквозной аналитики необходимо знать затраты наэтот канал истатистику пообъявлениям. Эти данные хранятся врекламном кабинете.

Вобъявлениях как значения меток используются динамические параметры:

http://www.example.com/?utmsource={source}&utmmedium={medium}&utmcampaign={campaignname}

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

Нопри попытке получить статистику срекламного кабинета поэтим объявлениям API возвращает метки без подстановки. Чтобы обойти эти ограничения, потребуется самостоятельно подставлять значения динамических параметров. Это легко сделать сосновными динамическими значениями: названием кампании, idкампании, названием групп объявлений или конкретных креативов итак далее.

Сложность возникает при использовании таких динамических параметров, которые вообще непередаются поAPI. Для Яндекс.Директа одно изтаких значений {position} позиция объявления вблоке, для Фейсбука {placement} название плейсмента или {sitesourcename} краткое обозначение источника. Внекоторых случаях можно воспользоваться ручной подстановкой меток или включить значения этих параметров вдругие utm-метки. Например, для Фейсбука значение параметра {sitesourcename} можно записать вназвании кампании при условии, что внутри данной кампании реклама будет транслироваться науказанный источник.

Значения динамических параметров неизменяются при редактировании данных

При создании объявления сдинамическими метками система запоминает ихзначения ииспользует для подстановки. Вдальнейшем, если вносить какие-либо изменения вэто объявление (поменять название объявления или кампании итак далее), тозначения динамических параметров останутся первоначальными.

Изэтого следует очень важное правило для построения сквозной аналитики: нельзя редактировать никакие креативы, содержащие динамические параметры. Только создавать новые. Этоже правило касается email-рассылок сдинамическими параметрами.

Что ещё стоит помнить про utm-метки всквозной аналитике

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

  2. Одинаковые метки для разных кампаний/объявлений приведут кудвоению данных.

  3. Частые ошибки вutm-разметке ведут кувеличению затрат насквозную аналитику, т.к. требуют более частого вмешательства аналитиков.

  4. Изменения вutm-разметке влекут изменения впроцессе сквозной аналитики.

Подробнее..

Облачное хранилище компонентов новый этап в развитии Интернет-шлюза ИКС

24.02.2021 16:18:54 | Автор: admin

Начало


Популярность современных UTM-решений, связана в первую очередь с их многофункциональностью. Возможность быстро решить все ИТ-задачи компании, да еще и из одного веб-интерфейса привлекает многих сисадминов.

Наше решение, Интернет Контроль Сервер, также относится к классу UTM-продуктов, объединяя в себе функции защиты сети, управления Интернет-подключениями, контентной фильтрации и многие другие.

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

С этой точки зрения более интересным продуктом является шлюз UTM, который может быть построен самим пользователем, исходя из реальных задач компании.

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

Исторически сложившаяся экосистема FreeBSD нас устраивала и была достаточно хорошо изучена. В качестве наиболее подходящего метода дистрибуции пакетов мы выбрали традиционную утилиту установки пакетов во FreeBSD pkg. В нашем облаке собирается репозиторий, а на клиенте прописывается доступ к нему в традиционном конфиге pkg.

Что мы планировали сделать


Система должна представлять собой конструктор в виде ядра, на которое нанизываются компоненты. Пользователь получает дистрибутив, в который входят только минимально необходимые плагины (router, fierwall и т.д.). Остальное устанавливается по мере необходимости.

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

  • система модифицированное ядро FreeBSD
  • core специальный пакет с настройками продукта, являющийся родительской зависимостью для всех плагинов
  • плагины каждый из них это собранный пакет, который штатным образом устанавливается утилитой pkg

Структура плагинов


Как уже говорилось, плагин это обычный пакет. Он может быть установлен утилитой pkg.
Для того, чтобы поддерживать обратную совместимость, решили, что новая мажорная версия плагина будет отдельным пакетом, не связанным с предыдущей мажорной версией. Например plugin-v1 и plugin-v2. Причина у них могут быть совершенно разные зависимости, возможно даже противоречащие друг другу.

У минорной версии просто меняется номер версии пакета, тут все как обычно.

Работа с плагинами


Для того, чтобы система работала так, как нам нужно, была создана утилита-надстройка над pkg.

Основным инструментом для работы будут команды pkg query и pkg rquery.

Первая собирает информацию по установленным в системе плагинам, вторая обращается к репозиторию.

Для того, чтобы утилита контролировала корректность выполнения команд в системе, выполнение каждой команды проверяется на код возврата. Если получен код возврата 0, значит команда выполнилась, если что-то иное, значит возникла ошибка. Таким образом можно отследить, к примеру, проблемы с сетевым соединением.

Здесь возник интересный нюанс. Если выполнить например поиск всех пакетов по шаблону:



то в случае, если ни один установленный пакет не попадает под условие шаблона, возвращается ошибка 69 без сообщения об ошибке. Разработчики утилиты посчитали, что если поиск ничего не вернул, то это ненормальное поведение. Ну, ОК. Пришлось обрабатывать такой случай специальным образом.

Проблемы обновления


Дальше начинаются проблемы с версионностью при обновлении плагинов.

Во-первых, утилита pkg при выполнении команды pkg upgrade <pkg_name> также обновляет ВСЕ прямые зависимости пакета, такое поведение заложено разработчиками. Но в нашем случае это включает в себя обновление и core, если для него вышла минорная версия, что нежелательно, поскольку core меняет системные параметры, а также требует перезагрузки системы после обновления.

То есть, если у нас в системе установлены 2 пакета pkg-1 и pkg-2, и в зависимостях pkg-1 указан pkg-2, то если мы выполним команду pkg upgrade pkg-1, то обновится также и pkg-2.

Пойдем другим путем.

Построим дерево зависимостей пакета вверх и вниз.
Находим имена всех пакетов, от которых зависит наш пакет:

pkg rquery %rn <pkg_name>

Теперь всех пакетов, которые зависят от нашего пакета:

pkg rquery %dn <pkg_name>

Удалим все зависимые от пакета сущности. Далее начнем удалять сущности, от которых зависит наш пакет вверх по дереву до тех пор, пока не окажемся в core (его удалять не будем конечно). Теперь можно восстановить дерево, установив последние минорные версии всех пакетов в нем.



Например, на рисунке выше мы видим, что пакет ics-plugin-a-v1 зависит от плагина ics-plugin-b-v1. Если нам нужно обновить пакет до версии ics-plugin-v2 то это повлечет и обновление пакета ics-plugin-b-v1, для которого существуют 2 мажорные версии ics-plugin-b-v2 и ics-plugin-b-v3. При этом ни одна из них не поддерживает плагин ics-plugin-c-v1. То есть, при обновлении сначала будет установлен пакет ics-plugin-b-v2 или -v3, затем ics-plugin-a-v1, а ics-plugin-c будет удален и установлен не будет.

Кроме того мажорная версия может быть у core, в этом случае весь состав плагинов должен быть обновлен для соответствия.



Для установки пакета ics-plugin-a, который зависит от ics-core-v2 нужно обновить ics-core, после чего установятся только пакеты мажорных версий, которые зависят от ics-core-v2.

Резервное копирование базы


При работе с репозиторием возможна ситуация, когда во время обновления пропадет связь (возникает системная ошибка код 70 или 3). Кроме того, для того, чтобы корректно удалить плагин, системе необходима действующая база pkg в системе. При выполнении команды pkg update, если нет связи, база сообщает об ошибке и даже локально не выполняет свои функции пока апдейт не выполнится корректно.

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

pkg backup -d <backup_dir>

Если операция завершилась некорректно, возвращаем базу на место:

pkg backup -r <backup_dir>

Ядро


Тут пока все достаточно просто. Если вышло обновление для ядра, то:

  1. скачиваем новый образ ядра в архиве
  2. создаем новый датасет в zfs
  3. монтируем датасет в систему
  4. распаковываем образ
  5. устанавливаем специальный пакет с нужными опциями ядра для нормальной работы
  6. прописываем новый образ как загрузочный
  7. ???

Profit?


Пока еще нет.

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

Но (как всегда) есть нюанс.
У нас еще не установлено ядро будущей версии, а установить плагин для другой версии мы не можем. Если же мы загрузим систему с нового образа, то не сможем получить доступ к репозиторию (по исторически-техническим причинам маршрутизация это тоже плагин).

Что делать?

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

Затем наша утилита сгенерирует файл конфига репозитория с указанием пути до папки с распакованным архивом.

Для FreeBSD это будет файл <repo_name>.conf в папке /usr/local/etc/repos или /etc/repos. Здесь стоит обратить внимание, что путь пишется следующим образом: url: file:///path_to_repo (3 слэша!)

Сохраняем данные об установленных плагинах и проверяем их совместимость с будущей версией ядра (если есть несовместимые, сообщим об этом пользователю).

Вот теперь можно перезагружаться.

Последнее


После обновления системы утилите pkg требуется инициализация (bootstrap). Поэтому если выполнить любую команду, возникнет запрос на нее. В нашем случае, утилита-обвязка не поймет, что он нее хотят и посчитает что операция выполнена некорректно.

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

pkg -y

Pkg делает бутстрап, и дальше можно работать в штатном режиме.

Итого


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

Описанная технология будет применяться в новых разработках Интернет Контроль Сервер, делая его еще более удобным для использования в корпоративных сетях компаний. Скачать и протестировать самую актуальную версию ИКС можно по ссылке.

Триал-период, бесплатная версия на 9 пользователей, демо-онлайн и отзывчивая техподдержка.

Следите за новостями и оставайтесь с нами!
Подробнее..

Категории

Последние комментарии

  • Имя: Макс
    24.08.2022 | 11:28
    Я разраб в IT компании, работаю на арбитражную команду. Мы работаем с приламы и сайтами, при работе замечаются постоянные баны и лаги. Пацаны посоветовали сервис по анализу исходного кода,https://app Подробнее..
  • Имя: 9055410337
    20.08.2022 | 17:41
    поможем пишите в телеграм Подробнее..
  • Имя: sabbat
    17.08.2022 | 20:42
    Охренеть.. это просто шикарная статья, феноменально круто. Большое спасибо за разбор! Надеюсь как-нибудь с тобой связаться для обсуждений чего-либо) Подробнее..
  • Имя: Мария
    09.08.2022 | 14:44
    Добрый день. Если обладаете такой информацией, то подскажите, пожалуйста, где можно найти много-много материала по Yggdrasil и его уязвимостях для написания диплома? Благодарю. Подробнее..
© 2006-2024, personeltest.ru