История страницы

Пользовательский сервис Skype. Модуль перехвата данного сервиса может генерировать события типа «Мессенджер»

.

Пользователь SDK может выбрать сервис из числа встроенных в Traffic Monitor или определить и зарегистрировать свой собственный. На основании «Протокола» объекта и идентификатора компании-производителя перехватчика реализуются политики лицензирования внутри Traffic Monitor. «Протокол» объекта представляет собой последовательность символов и определяется пользователем SDK.

Sv translation

language	ru

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

События перехвата передаются в Traffic Monitor в виде объектов «событие»;
Каждое «событие» имеет набор обязательных атрибутов, которые задаются пользователем программного интерфейса;
Каждое «событие» может иметь набор необязательных атрибутов, которые задаются пользователем программного интерфейса;
Каждое «событие» имеет «отправителя» и «получателя»;
Каждый «отправитель» и «получатель» может иметь связанный с ним список «контактов», которые позволяют уникальным образом идентифицировать отправителя и получателя;
Каждый «получатель» и «отправитель» может иметь связанный с ним набор атрибутов;
Каждое «событие» имеет связанные с ним «данные», т.е. последовательность байт и/или символов текста, которые представляют собой содержимое перехваченного события;
Каждый элемент «данных» может иметь связанный с ним набор атрибутов.

Все возможные «события», которые может принимать и анализировать Traffic Monitor, разбиты на группы – «типы» классы событий, которые объединены общими характеристиками. Тип Класс события определяет бизнес-логику обработки события, а также правила его отображения в консоли Traffic Monitor.
На данный момент поддерживаются следующие типы классы событий:

«Почта» – Почта – любые события обмена электронными письмами, включая вложения. Характеризуется списком персон-отправителей и персон-получателей, датой отправки, темой, телом и вложениями к письму;«Мессенджер» – . Включает в себя корпоративную почту (IMAP, POP3, SMTP, MAPI, NRPC) и Веб-почту (HTTP, HTTPS). Название сервиса в TM: Почта;
Беседа – любые события беседы, представляющие собой обмен текстовыми сообщениями или файлами в файлами в рамках одного приложения. Приложение может являться как тонким клиентом на рабочих станциях и мобильных устройствах, так и web-приложением. Характеризуется списком реплик. Для каждой реплики должна быть указана персона-отправитель, время отправления и текст сообщения. Примером событий такого типа может быть беседа в Skype или Telegram;«Принтер и МФУ» – Следующие сервисы уже предустановлены в этом классе: MS Lync, ICQ, Mail.ru, Jabber, Skype (перeдача SMS и обычных текстовых сообщений). Название сервиса в TM: Мессенджеры;
Печать, копирование и сканирование – события преобразования данных на «специализированных» специализированных устройствах ввода и вывода изображений/документов (например: Принтер, Сканер). Характеризуется персоной-отправителем и устройством-получателем, количеством копий, а также файлом с оригиналом документа/образом документа/заданием на печать. В рамках этого класса предустановлен сервис Принтер. Название сервиса в TM: Принтер и МФУ;
«ИнтернетИнтернет-активность» – активность – события формирования запросов из Web-браузеров и аналогичных программ, осуществляемое по протоколам http/httpsпротоколам HTTP, HTTPS. В событие данного типа попадают все данные, для которых не нашлось другого типа. Примером могут Примером может служить отправка веб-сообщения
Talk
id talk-5882
Talk
id talk-5900
Talk
id talk-5883
.
Talk
id talk-5901
Характеризуется сообщения . Характеризуется персоной-отправителем и ресурсом-получателем в случае POST-запросов или персоной-получателем и ресурсом-отправителем в случае GET-запросов, а также текстом "сырого" запроса. В рамках этого класса предустановлен сервис Интернет-приложение. Название сервиса в TM: Интернет-активность;
Фотосъемка – события фотосъемки с помощью камеры устройства. Характеризуется персоной-отправителем и устройством-получателем, а также перехваченным изображением. Название сервиса в TM: Запись мультимедиа;«Обмен файлами» –
Обмен файлами – любые события, связанные с передачей файлов между произвольными отправителями и получателями. Характеризуется персоной-отправителем и персоной-/устройством-/ресурсом-получателем, а также перехваченным файлом. Включает Включает в себя копирование на съемное USB-устройство, в облачное хранилище, на сетевые ресурсы, обмен файлами через терминальную сессию и по FTP-протоколу.Следующие сервисы уже предустановлены в этом классе: FTP, Съемное устройство, MS Lync, ICQ, Mail.ru, Jabber, Skype, Облачные хранилища, Терминальная сессия, Сетевые ресурсы. Название сервиса в TM: Мессенджеры (если отправители и получатели события являются персонами) или Обмен файлами (если хотя бы один отправитель или получатель события не является персоной);
Звонок – любое событие голосового или видеоразговора между людьми, который может происходить по мессенджеру или телефону. Характеризуется персоной-отправителем (инициатор звонка) и персонами-получателями, а также файлом и длиной записи разговора. Примером могут служить отправка/получение SMS и MMS или перехват разговоров в сотовых сетях. Следующие сервисы уже предустановлены в этом классе: MS Lync, Mail.ru, Jabber, Skype. Название сервиса в TM: Мессенджеры;
Запись мультимедиа – события создания аудио- и видеозаписи с помощью устройства. Характеризуются персоной-отправителем и устройством-получателем, а также перехваченным изображением. Примером могут служить записи с микрофонов/диктофонов или записи на видеокамеру, а также любые события, связанные с фотографированием потенциально конфиденциальных документов на камеру устройства. Название сервиса в TM: Запись мультимедиа;

Пользователь SDK должен обязательно определить «Тип» для своих перехваченных объектов и «Протокол» перехваченного объекта. «Протокол» определяет, что именно было перехвачено с точки зрения пользовательского сервиса, который использовал «отправитель» для передачи информации.

Информация

title	Пример:

Информация

title	Пример:

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

«Протокол» перехваченного события может задаваться как одно из условий в формировании «политики» Traffic Monitor и аналитических запросах.
У каждого «События» должны быть определены «отправитель(и)» и «получатель(и)».
Поддерживаются следующие типы «получателей» и «отправителей»:

«Персона» – представляет собой «пользователя», который определяется как создатель, отправитель или получатель перехваченного объекта. Для персоны можно определить набор «контактов» для её идентификации. Тип контакта можно выбрать из списка, который поддерживается SDK. В качестве примера типа контакта можно привести email, телефон или учётную запись Windows;
«Компьютеры» – представляет собой компьютер, мобильное устройство или терминальный сервер, на котором был «создан» перехваченный объект. Для данного типа «отправителя» можно определить список «контактов»;
«Ресурс» – представляет собой адрес в сети Интернет, на который были переданы данные;
«Устройство» – представляет собой устройство, которое получает данные при копировании файлов на съёмные носители;

Список контактов, связанных с «Персоной», позволяет идентифицировать её по любому её контакту. Таким образом, любые перехваченные действия «Персоны», в которых определён хотя бы один её контакт, позволяет идентифицировать конкретного пользователя в Traffic Monitor.
Интерфейс SDK позволяет связывать различные типы контактов между собой логическими связями, например, отправителя «Персону» с отправителем «Компьютеры». Это позволяет точно определить контекст перехватываемой операции, т.е. кто и где инициировал действие по передаче данных.
Добавление собственных «Протоколов» осуществляется через специальный файл заданного формата. Этот файл загружается в Систему через консоль Traffic Monitor и обновляет внутренние структуры данных. После этого новые «Протоколы» смогут принимать участие в создании правил и аналитических запросов.
Интерфейс SDK позволяет передавать данные в сеть по частям. Это позволяет внешним разработчикам самим определять стратегию ограничения нагрузки на сеть.
Общий алгоритм передачи события через интерфейс SDK выглядит так:

Создать объект «Событие» и установить его атрибуты;
Создать отправителей/получателей события, а также установить их контакты и атрибуты;
Создать данные события и установить его атрибуты;
Создать соединение с Traffic Monitor;
Проверить доступ к Traffic Monitor и лицензию плагина внешнего разработчика;
Передать «метаданные» события;
Передать по частям содержимое данных события;
Закрыть соединение;
Удалить объект «Событие».

Более подробно процесс передачи событий можно посмотреть в Примерах SDK.

As per the user service Skype, the interceptor of this service can generate events as a "Chat"

.

The SDK user can select a service from the list of services embedded in Traffic Monitor or define and register a custom service. The licensing policy in Traffic Monitor is implemented based on the object "

service

protocol" and the interceptor vendor identifier. The object "service" is a sequence of characters defined by the SDK user.

title

Example:

If SDK user has developed an interceptor for a Viber client, the user can define and register the service as "Viber". For each

"

service

"

of a single vendor, a separate license is issued.

The "service" of the intercepted object can take part in creating a "policy" in Traffic Monitor, as well as in various analytical queries.
For each "event", "sender(s)" and "recipient(s)" must be defined.
The following types of "senders" and "recipients" are supported:

A "person" is a "user" who is defined as a creator, a sender or a recipient of the intercepted object. For the person identification, a set of person's contacts can be defined. The contact type can be selected from the list which is supported by SDK. An example of the contact type can be email, phone number or a Windows account;
A "workstation" is a computer, a mobile device or a terminal server, where the intercepted object was "created". For this type of a "sender", a list of "contacts" can be defined;
A "resource" is an address on the Internet to which data is passed;
A "device" is a device that receives data when files are copied to removable devices.

The list of contacts associated with a "person" makes it possible to identify the person by the contact. So, any intercepted actions of a "person" where at least one contact of the person is defined, allows Traffic Monitor to identify a particular user.
The SDK interface allows you to create logical connections between different objects, for example, a

sender

sender Person

with

with a

sender

sender Workstation. This allows you to accurately determine the context of an intercepted operation, that is to determine who has initiated the data transferring and where.
For adding custom "services", a special file in a specific format will be used. This file will be loaded into the system through Traffic Monitor console and update internal data structures. Then, new services will be able to participate in creating rules and analytical queries.
The SDK interface enables sending data to a network in parts. It allows external developers to define, how to limit the load on the network.
A general algorithm of passing event the SDK interface looks like the following:

Create an "event" object and set its attributes;
Create senders/recipients of the event and specify their contacts and attributes;
Create the event data and set its attributes;
Establish connection with Traffic Monitor;
Check access to Traffic Monitor and a plugin license of an external developer;
Pass the event

"

metadata

"

;
Pass contents of the event data in parts;
Close the connection;
Delete the event object.

For more details on the process of passing events, see SDK Samples.

Sv translation

language	en

To configure sending events to Traffic Monitor, the following principles should be taken into consideration:

Interception events are passed to Traffic Monitor in the form of "event" object
Each "event" has a set of required attributes specified by the user of the programming interface
Each "event" may have a set of optional attributes specified by the user of the programming interface
Each "event" has a "sender" and a "recipient"
Each sender or recipient may have a list of associated "contacts" which are used to uniquely identify this sender/recipient
Each "sender" or "recipient" may have a list of attributes associated with this sender/recipient
Each "event" has associated "data", that is a set of bytes and/or text characters which represent the contents of the intercepted event
Each element of the "data" should have a set of data associated with this element

All possible "events" that can be received by Traffic Monitor and analyzed are divided into groups (event "classes") united by common characteristics. The event class defines the business logic of the event processing and how the event will be displayed in Traffic Monitor console.
For now, the following event classes are supported:

"

Email

" –

– any events of sending emails including emails with attachments. The event is characterized by a list of senders and recipients (persons), a sending date, a subject, a message body, and attachments. Includes corporate email (IMAP, POP3, SMTP, MAPI, NRPC) and webmail (HTTP, HTTPS). Service name in TM: E-mail;

"

Chat

" –

– any events of exchanging only text messages or files within a single application. The application can be either a thin client on workstations and mobile devices or a web application. The event is characterized by a list of remarks. For each remark, the sender (person), the time of sending, and the message text must be specified.

An example of this class is a Skype or Telegram chat;"Printers and MFPs" –

The following services are preinstalled in this class: Mobile communication, WhatsApp, Yahoo!, MS Linc, ICQ, Mail.ru, Jabber, Skype (SMS and text messages tranferring). Service name in TM: Messenger;
Printers and MFPs – events of data conversion on "specialized" devices for input/output of images and documents (e.g., printers, scanners). The event is characterized by a sender (person), a recipient (device), a number of copies, and a file with the original document/document image/print task. The class has a preinstalled service – Printer. Service name in TM: Printer and MFD;

"

Internet activity

" –

– events of sending requests from web browsers and similar programs via HTTP/ HTTPS protocols. Data for which no other class is selected also refers to this class. Sending a web message can be an example of an internet activity. The event is characterized by a sender (person) and a recipient (resource) for POST requests or a recipient (person) and a sender (resource) for GET requests. It is also characterized by the body of a "raw" request

;"File exchange" –

. The class has a preinstalled service – Internet application. Service name in TM: Web activity;
Photo – events of photographing using device camera. The event is characterized by a sender (person) and a recipient (device). It is also characterized by an intercepted image. The class has a preinstalled service – Photo camera. Service name in TM: Recording media;
File exchange – any event of transferring files between any senders and recipients. The event is characterized by a sender (person), a recipient (person/device/resource), and the intercepted file. Includes copying data to removable USB devices, cloud storage

, or network resource

, sharing files via FTTP protocol. The following services are preinstalled in this class: FTP, External device, Mobile communication, WhatsApp, Yahoo!, MS Linc, ICQ, Mail.ru, Jabber, Skype. Service name in TM: Messengers (if recipient and sender are persons) or File exchange (if at least one recipient or sender are not persons).
Call – any event of voice or video call via

a terminal session or FTTP protocol

messenger or phone. The event is characterized by a person-sender (call initiator) and persons-recipients. It is also characterized by a file and a record time. Example: sending/receiving SMS or MMS or intercepting calls in social media. The class has the following preinstalled services: Mobile communication, MS Lync, Mail.ru, Jabber. Service name in TM: Messenger;
Recording media – event of recording audio or video using a device. The event is characterized by a person-sender, a device-recipient, and an intercepted image. Example: microphone or dictaphone recordings, videocamera recordings and any events of photographing potentially confidential documents using device camera. Service name in TM: Recording media.

The SDK user should define a "class" of object intercepted by SDK

.
Besides, the SDK should define the

and a "service" of

the intercepted object

intercepted object.

The

"

service

Service" determines what exactly was intercepted from the point of view of the user service, which the "sender" used for transferring data

.

Информация

title	Example:

Информация

Show all results

Дерево страниц

Сравнение версий

Старая версия 5

Новая версия Текущий

Ключ