На GitHub опубликован код фреймворка SigPloit. Код выложил в открытый доступ исследователь информационной безопасности Лоай Абдельразек (Loay Abdelrazek). С помощью SigPloit можно проводить тестирования уязвимостей в телекоммуникационных протоколах. Появление проекта может серьезно изменить ситуацию в сфере информационной безопасности телеком-операторов.

Как работает система

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

Как заявлено создателями, цель фреймворка — дать возможность проводить анализ защищенности всех существующих протоколов, которые используются в инфраструктуре телеком-операторов, в их числе SS7,GTP (3G), Diameter (4G) и даже SIP для IMS и VoLTE, использующийся на уровне доступа и для инкапсуляции SS7-сообщений в SIP-T. В документации сообщается, что в процессе тестирования система будет также выдавать рекомендации по повышению защищенности конкретной сети.

Что это значит для телеком-компаний

Защищенность протоколов, которые используются телекоммуникационными компаниями, часто базируется на их специфичности. На практике это значит, что уровень защищенности телеком-инфраструктуры может быть недостаточным, однако компаниям удается избежать проблем из-за малого количества исследователей, разбирающихся в узкоспециализированных протоколах и тонкостях инфраструктуры. Фреймворк SigPloit может быть легко доработан до полного спектра атак на SS7.

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

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

Эксперты Positive Technologies неоднократно поднимали тему небезопасности сигнального протокола SS7 (раз, два, три). За последнее время атаки на него превратились из теоретических в практические и затрагивают большое количество пользователей — известны случаи, когда уязвимости SS7 позволяли злоумышленникам похищать деньги пользователей или взламывать их Telegram-аккаунты.

https://habrahabr.ru/post/331234/

КДПВ, ради хайпа, а не флейма.

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

Скажу сразу, статья не про системы контроля версий. Кто из вас кладет чертежи из САПРа в Git? А стомегабайтные графические файлы? Ежедневно? И не про облачные хранилища. Статья про реализацию конкретной потребности, которая была озвучена не раз знакомыми и коллегами, пользующихся обычной MS Windows, создающих что-то дома или в офисе.

Однажды осознаешь, что не стоило неделю назад удалять страницу в чертеже, или объединять слои в скетче. Допустим, бэкапы делались, даже инкрементальные. В этот момент меньше всего хочется разбираться, как достать файлы из контейнера, гуглить ключи командной строки и все это самое. Хочется самого простого — любым файловым менеджером найти свежайшую версию файла, или недельной давности, лучше по имени, а не хешу содержимого. Не тот файл? Может нужен двухнедельной давности?

Так появилась моя разработка. Назвал ее BURO. Никак не расшифровывается.

Вдохновителем была утилита rdiff-backup, но у нее был «фатальный недостаток». Написана она на python и хранит данные в текстовых пожатых файлах. Ждать по 20 минут, когда она отработает в конце рабочего дня, или готовясь отойти ко сну, для меня было не приемлемо. Не может оперировать очень длинными именами. Даже страшно подумать, как мне из резерва «отмотать» нужный файл на n правок/дней назад.

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

buro --backup --srcdir="путь к резервируемой папке" --dstdir="куда будем резервировать"

В папке, указанной как dstdir, будет создан файл buro.db и папка mirror, которая будет полной копией папки srcdir. В следующий раз, когда мы запустим ту же самую команду, в папке dstdir будет создана подпапка, названная меткой времени запуска резервирования, в которую будут перемещены модифицированные или удаленные файлы, по сравнению с предыдущим запуском. Выглядит это примерно так:

<2017-06-14T00-01-34.771>
<Отчеты о практике>
Отчет1.doc
<2017-06-15T00-57-35.858>
Список покупок.xls

<Отчеты о практике>
Отчет1.doc
Отчет2.doc
<Для мамы>
Vivaldi.mp3
Список покупок.xls
buro.db

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

Восстанавливаются файлы из резерва командой:

buro --restore --srcdir="откуда восстанавливаем" --dstdir="куда восстанавливаем"

Тут все просто. Если нужно состояние папки на определенную дату, то добавляем аргумент —timestamp и указываем дату в формате «YYYY-MM-DD HH:mm:SS.SSS», например:

buro --restore --srcdir="z:\backup" --dstdir="d:\documents" --timestamp=”2017-06-15 00:00:00.000”

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

Инкременты стали занимать много места? Руками удалять не нужно, есть команда purge. Пример:

buro --purge --srcdir="где лежит бэкап" --older="P30D"

Аргументом older указываем конкретную дату, либо период времени в формате ISO 8601 (P1Y2M3DT4H5M6S, в примере выше выбран период 30 дней).

Но ведь даже та самая Visual Studio каждый раз генерирует служебных файлов на многие мегабайты. Место не бесплатное. Настраивать маски файлов и папки для исключения? Пффф… Есть опция сжатия файлов! Команде --backup добавляем аргумент --compress и каждый файл будет преобразован в архив bzip2. К имени файлов также будет добавлено расширение ".bz2" Степень сжатия задается числом от 1 до 9 (по-умолчанию 5). Пример:

buro --backup --srcdir="d:\myprojects" --dstdir="g:\backup" --compress=9

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

Мой типичный сценарий бэкапа, под который и разрабатывалось Buro, это сохранение на съемный носитель или сетевой диск. Данные переносятся в слабо контролируемую среду, секретность не помешает. Шифрование съемных носителей, и тем более сетевых дисков, это всегда немножко грустная тема, особенно если с файлами планируется продолжить работу в другом месте. Но и тут есть решение! Встроенное шифрование. К команде --backup добавляется опция --password. К имени файлов добавляется расширение ".encrypted" Можно одновременно использовать сжатие и шифрование, расширение все равно будет ".encrypted"

Предположим, на предприятии неадекватная СБ, у которой могут возникнуть вопросы к происхождению файла «Зарплатная ведомость руководства.xls.encrypted». Для этого реализована опция шифрования имен --encodenames.

Пример. Каталог с файлами

<.github>




.gitignore
.travis.yml
Android.mk
ChangeLog.rst
CMakeLists.txt
CONTRIBUTING.rst
LICENSE.rst
README.rst


Превращается в:

<3kOFykh>




Au!U33x!41SS(8Ir
BuN0kVhe85aPkQh2$
fS1twqYhBCWCagGr
IKNW$LFo3$x9Mgb!rQd
nzSFA6G3RGfKkFA~XaXDZ
pWWMxno894zDuu0L!s3WY
rHtwmdKLrYxkWN~)NtKCuxH4Q
UiJ~)YM0zu01O8g52x~iAPIk


Если кому-то интересны технические детали реализации шифрования:

При использовании опции защиты паролем файл «buro.db» также шифруется. Движок БД — Berkeley DB, шифрует данные алгоритмом AES CBC 128bit, ключ получается из SHA1(пароль + соль). Моя утилита пропускает пароль пользователя через функцию Argon2, получает на выходе 256 бит данных, преобразует в текстовую строку, которая служит паролем к БД. Для шифрования файлов и имен используется алгоритм ChaCha20. Ключи генерируются случайно и сохраняются БД. Я поленился для каждого файла заводить свой ключ, пользуюсь одним. Чтобы нельзя было наложить друг на друга разные версии одного файла, для каждого генерируется свой NONCE, записываю его как первые 8 байт шифрованного файла. Имена файлов перед шифрованием сжимаются простым LZ-подобным алгоритмом, чтобы было труднее угадать длину исходного имени. Поправьте меня, если в чем-то ошибся.

Скучные подробности:

• Информационные сообщения выводятся в stdout, сообщения об ошибках в stderr;
• Чтобы видеть подробную информацию, что куда копируется и перемещается, используйте опцию --verbose;
• Чтобы добавить к сообщениям метку времени, используйте опцию --printtimestamp. Чтобы отобразить уровень логгирования, используйте --printloglevel;

Не стал добавлять контроль целостности данных контрольной суммой, ИМХО в процессе передачи данных и так идет контроль на многих уровнях. Если очень хочется, используйте опцию сжатия, там контроль есть, я так и делаю.

Для заинтересовавшихся ссылка на исходные коды и бинарники.

p.s. В процессе разработки Buro у меня скончался SSD. Какая ирония.

https://habrahabr.ru/post/331232/

17 июня 2017 года вышла в свет новая, девятая версия Debian под кодовым названием Stretch. Работа над Debian 9 длилась два с небольшим года, а если совсем точно — 26 месяцев. Она будет поддерживаться в течение ближайших пяти лет.

Новая версия посвящена памяти основателя проекта Debian Иэна Мёрдока, погибшего в конце 2015 года.

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

Кроме того, у нас есть ещё одна новость, не менее важная: образ Debian 9 уже доступен пользователям нашего сервиса Vscale, и вы можете познакомиться с ним поближе прямо сейчас.

Поддерживаемые архитектуры

Debian 9 поддерживает следующие архитектуры: i386, amd64, armel, armhf, mips, mipsel, ppc64el, s390x. Добавлена поддержка новой архитектуры — mips64el.

Как и в других популярных дистрибутивах Linux, поддержка PowerPC прекращена. Более подробно о поддерживаемых архитектурах можно прочитать здесь.

Ядро 4.9

В Debian 9 используется ядро последней LTS-версии — 4.9; в скором будущем ему на смену придёт ядро версии 4.14, выход которой запланирован на осень текущего года.

Обновление пакетного менеджера APT

Пакетный менеджер apt в Debian 9 был существенно усовершенствован по сравнению с предыдущими версиями. Не поддерживаются ненадёжные алгоритмы для вычисления контрольных сумм: так, SHA1 по умолчанию заблокирован.

В предыдущих версиях Debian при синхронизации зеркал иногда возникала oшибка hash sum mismatch. В Stretch она наконец-то исправлена благодаря использованию так называемой разбивки by-hash: файлы с метаданными загружаются по хэшу содержимого.

Ещё одно интересное нововведение, которое несомненно будет интересным для владельцев и администраторов зеркал: APT теперь может использовать SRV-запись в DNS, чтобы определить бэкенд для загрузки. Управлять бэкендами теперь можно с помощью DNS, не задействуя никаких дополнительных сервисов для обработки запросов. Именно так работает новое зеркало deb.debian.org.

Обновления ПО

В состав Debian 9 включены новейшие версии многих популярных средств разработки и системных приложений:

• Apache 2.4.25;
• GCC 6.3;
• Systemd 232;
• GnuPG 2.1;
• Golang 1.7;
• OpenJDK 8;
• Perl 5.24;
• PHP 7.0;
• Tomcat 8.5&

Вместо традиционного MySQL в Debian 9 по умолчанию используется его форк MariaDB. При обновлении с предыдущей версии MySQL 5.5 или 5.6 будет автоматически заменён на MariaDB 10.1.
Поддержка MySQL при этом будет сохранена. Подробнее об этом можно почитать здесь.

Новый подход к именованию сетевых интерфейсов

Вместо традиционной схемы, в соответствии с которой сетевые интерфейсы получают имена типа eth0, eth1, eth2, в Debian 9 используется совершенно иной подход — stateless persistent network interface names (постоянные имена без сохранения состояния). При именовании используются индексированные номера интерфейсов в BIOS, а также номера слотов PCI.

Интерфейс eth0, например, теперь называется ens0, a wlan0 — wlp3s0. При обновлении с предыдущей версии (Debian 8 Jessie) имена автоматически изменены не будут.

Как обновиться

Чтобы обновиться с Debian 8 Jessie до Stretch, нужно сначала обновить систему:

$ sudo apt-get update && apt-get upgrade
$ sudo apt-get dist-upgrade

Далее отредактируем файл /etc/apt/sources.list и добавить в него репозитории stretch. Это можно сделать при помощи одной команды:

$ sed -i 's/jessie/stretch/g'/etc/apt/sources.list

Затем выполняем по второму кругу:

$ sudo apt-get update
$ sudo apt-get upgrade
$ sudo apt-get dist-upgrade

Во время обновления система задаст следующий вопрос: Restart services during package upgrades without asking? Выбираем ответ Yes.

По завершении обновления перезагружаем систему:

$ sudo reboot

После перезагрузки выполним:

$ cat /etc/debian_version
9.0

Как видим, всё прошло успешно.

Если вы являетесь пользователем Vscale, то можете сделать всё гораздо проще и одним кликом создать виртуальный сервер под управлением Debian 9. А если вы ещё не в Vscale — скорее присоединяйтесь, и вы сможете оперативно (как правило, прямо в день официального релиза) получать свежие версии популярных дистрибутивов Linux.

Заключение

В этой статье мы проделали обзор нововведений, реализованных в Debian 9 Stretch. Пробуйте (в Vscale это совсем просто) и делитесь впечатлениями.

https://habrahabr.ru/post/331228/

Ранее, в статье рассказывалось о разработке метода распознавания, позволяющего осуществлять оптическое распознавание символов из видео «на лету». В качестве доказательства эффективности нового метода использовалась его реализация на устройстве, совершенно для этого не предназначенным — микроконтроллере esp8266. В ходе обсуждения возник вопрос: где можно использовать устройства с распознаванием на борту (считыватель)? Да еще и ценой менее $50. Понятно, что там же где и используются устройства подороже, но хотелось бы обсудить и другие варианты. Надеемся на помощь читателей в этом вопросе. А что видим мы?

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

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

По данным компании Ernst&Young пятнадцатилетний опыт эксплуатации умных счетчиков в Европе не привел к однозначным выводам об их эффективности, хотя все понимают, что в этом что-то есть. Основной эффект достигается за счет снижения затрат на съем показаний, в меньшей степени уменьшения ворованной энергии. Пилотный проект в нашей стране показал намного лучшие результаты — снижение потерь на 37% по Калининградской области, например. Остается вопрос, конечно, как убрать оставшиеся 63%.

1.1. С учетом того, что при оценочной стоимости отечественного умного счетчика в $500, срок его окупаемости составит 9 лет, представляется интересной следующая схема, позволяющая уменьшить срок окупаемости минимум в четыре раза:


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

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

Считыватель потребителя помимо непосредственно чтения показаний, может осуществлять взаимодействие с потребителем и поставщиком, а также с разъединителем сети. Этот считыватель может находиться в двух состояниях: 'отключение энергии запрещено/разрешено'. Переключение состояний возможно только в период оплаты по команде поставщика. Если оплата произведена поставщик переводит считыватель в состояние отключение запрещено и следующее переключение состояния возможно только в следующем периоде оплаты.

Запрет отключения служит для предотвращение ошибочных отключений/подключений (в том числе и со стороны третьих лиц). Отключение может произойти только в состоянии считывателя 'отключении энергии разрешено'.

Таким образом, считыватель потребителя работает как счетчик поколения AMI — поставщик получает от считывателя показания счетчика потребителя и информацию об отключении тока, а считыватель получает команды и сообщения о балансе. При этом и потребитель на основании команд также может получить информацию о показаниях своего счетчика и состоянии считывателя.

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

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


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

2. Идентификация номерного знака автомобиля

На сегодняшний день распознавание автомобильных номеров можно считать тривиальной задачей. Существует не только большое количество решений осуществляющих распознавание на сервере, но и камер с распознаванием на борту: итальянская Tattile, венгерская Arh, немецкая Siemens, британская Mav, китайские HIKVision и Dahua, отечественная Iris и многие другие.

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

2.1. Управление парковками. В настоящее время для отслеживания свободных парковочных мест используются различные датчики присутствия, монтируемые в поверхность под автомобилем или помещаемые над ним. Такие датчики позволяют определить свободное/занятое место, но не способны определить номер автомобиля, которое это место занимает. Добавление такой возможности позволило бы предложить клиентам новые виды сервиса, помимо идентификации автомобиля при въезде/выезде:

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

*стоп кадры были сделаны с видео указанного выше.

• введение дифференцированной оплаты, в зависимости от расположения места на
  парковке;
• организация интерфейса между автомобилем и парковкой при условии привязки
  номера телефона к номеру автомобиля;
• получение информации о сумме оплаты после освобождения места и оплата по карте,
  привязанной к телефону, привязанного к номеру автомобиля;

2.2. Управление заправками автомобиля. Возможность заправиться не выходя из машины (при наличии заправщика) по схеме:

• Определение номера автомобиля подъехавшего к колонке;
• Проверка наличия необходимых средств на карте, привязанной к телефону, привязанного к номеру автомобиля;
• Запрос на подтверждение заправки;
• Заправка;
• Автоматическая оплата;

*основа для изображения была взята с ресурса init-e.ru.

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

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

3. Инфраструктура

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

3.1. Для осуществления передачи по каналу используются различные беспроводные (Bluetooth, WiFi, GSM, GPRS, LPWAN,...) и проводные (PLC, xDSL) технологии или их комбинации. Выбор конкретной архитектуры зависит от решаемой задачи. Так как объем передаваемых данных небольшой, то наиболее удобной технологией для передачи на большие расстояния является LPWAN, к которым относятся Стриж, Sigfox, LoRaWAN, а также технологии на базе сотовых сетей LTE-M и NB-IoT.

3.2. В большинстве примеров считыватель работает с одним получателем данных — сервером системы, однако в системах сбора данных с приборов учета считыватель работает с двумя получателями — сервером системы и пользователем. Причем для пользователя, находящегося на близком расстоянии удобно использовать для передачи данных каналы с WiFi или Bluetooth.

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

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

https://habrahabr.ru/post/331226/

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

Введение

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

Сохраняем карму, недорого

Сервис Heedbook, о котором я расскажу сегодня, обладает одним очень крутым преимуществом перед другими способами оценки работы сотрудников с клиентами — это автоматическая оценка эмоций клиента в режиме реально времени. То есть, возвращаясь к моему другу, его толерантность не спасёт консультанта от реальной оценки работы. И волки сыты, и овцы целы, и карма друга тоже.

Как это работает:

1. Сотрудник фронт-линии банка (или аптеки, или МФЦ, или магазина, или тому подобных предприятий) в начале рабочего дня входит в систему через браузер.
2. К нему приходит клиент, например, мой друг.
3. Система получает и анализирует видеопоток с веб-камеры в режиме реального времени в фоновом режиме.
4. Информация обрабатывается системами интеллектуального распознания эмоций, речи и других параметров клиента.
5. По результатам анализа система предоставляет детальную аналитику по структуре эмоций и доле положительных/отрицательных эмоций клиента, вниманию клиента к сотруднику, содержание диалога, использование скрипта обслуживание или запрещенных фраз.
6. Руководитель офиса и сотрудники головной компании получают в детальную информацию о качестве клиентского сервиса в разрезе менеджеров и клиентов. (И тут мы видим, как наш консультант начинает нервничать. ))

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



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



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

Как это работает: глазами разработчика

Микросервисная архитектура Azure Functions

Мы вместе с Димой Сошниковым частично помогали ребятам в проектировании решения. Первое, что сделали — решили уйти от монолитной архитектуры и сделать систему построенную на микросервисах (как вы могли заметить по моим последним статьям, на мой взгляд это очень интересная тема). Для этого использовали Azure Functions. На самом деле мы также думали про WebJob, но у него есть ограничения по производительности и ценообразование идёт не от количества совершенных операций.

Основная среда разработки AF — онлайн редактор функций на портале Azure. Также с конца мая 2017 можно создавать AF с помощью Visual Studio 2017 UPD 3.

Так как AF — новый продукт Microsoft, по нему пока нет полной документации, поэтому ниже разберем пример одной AF проекта Heedbook. Это позволит сэкономить время, если вы решите построить микросервисную архитектуру на базе Azure.

Триггером запуска AF может стать Http запрос, появление Blob в Azure Blob storage, действия в OneDrive или просто таймер. В проекте реализованы практически все представленные выше варианты триггеры для AF. Также мы реализовали каскады AF, когда работа одной AF запускает другую, таким образом обеспечивая единый бизнес процесс анализа данных.

Пример нашей AF триггерится появлением блоба — картинки. При помощи данной AF мы с вами определим количество людей на картинке и их эмоции. Сделаем это с помощью когнитивного сервиса Microsoft Face API.

Сначала необходимо подключить необходимые библиотеки когнитивных сервисов. Для онлайн редактора AF сделать это придётся вручную, создав файл project.json и прописав туда все необходимые зависимости:

{
  "frameworks": {
    "net46":{
      "dependencies": {
        "Microsoft.ProjectOxford.Common": "1.0.324",
        "Microsoft.ProjectOxford.Face": "1.2.5"
      }
    }
   }
} 

В случае с созданием AF в Visual Studio 2017 UPD 3 просто подключаем необходимые зависимости с помощью Nuget.

Дальше нам нужно прописать триггер AF и выходные параметры. В нашем случае — это появление блоба в определенном контейнере и запись результатов распознания в таблицу Azure MsSql. Делается это в файле function.json:

{
  "bindings": [
    {
      "name": "InputFace",
      "type": "blobTrigger",
      "direction": "in",
      "path": "frames/{name}",
      "connection": "heedbookhackfest_STORAGE"
    },
    {
      "type": "apiHubTable",
      "name": "FaceData",
      "dataSetName": "default",
      "tableName": "FaceEmotionGuid",
      "connection": "sql_SQL",
      "direction": "out"
    }
  ],
  "disabled": false
}

Итак, сам код Azure Functions!

#r "System.IO"

using System.IO;
using Microsoft.ProjectOxford.Face;
using Microsoft.ProjectOxford.Common.Contract;

public static async Task Run(Stream InputFace, string name, IAsyncCollector FaceData, TraceWriter log)
{
    log.Info($"Processing face {name}");
    var namea = Path.GetFileNameWithoutExtension(name).Split('-');
    var cli = new FaceServiceClient();
    var res = await cli.DetectAsync(InputFace,false,false,new FaceAttributeType[] { FaceAttributeType.Age, FaceAttributeType.Emotion, FaceAttributeType.Gender});
    var fc = (from f in res
              orderby f.FaceRectangle.Width
              select f).FirstOrDefault();
    if (fc!=null)
    {
        var R = new FaceEmotion();
        R.Time = DateTime.ParseExact(namea[1],"yyyyMMddHHmmss",System.Globalization.CultureInfo.InvariantCulture.DateTimeFormat);
        R.DialogId = int.Parse(namea[0]);
        var t = GetMainEmotion(fc.FaceAttributes.Emotion);
        R.EmotionType = t.Item1;
        R.FaceEmotionGuidId = Guid.NewGuid();
        R.EmotionValue = (int)(100*t.Item2);
        R.Sex = fc.FaceAttributes.Gender.ToLower().StartsWith("m");
        R.Age = (int)fc.FaceAttributes.Age;
        await FaceData.AddAsync(R);
        log.Info($" - recorded face, age={fc.FaceAttributes.Age}, emotion={R.EmotionType}");
    }
    else log.Info(" - no faces found");
}
 
public static Tuple GetMainEmotion(EmotionScores s)
{
    float m = 0;
    string e = "";
    foreach (var p in s.GetType().GetProperties())
    {
        if ((float)p.GetValue(s)>m)
        {
            m = (float)p.GetValue(s);
            e = p.Name;
        }
    }
    return new Tuple(e,m);
}


public class FaceEmotion
{
    public Guid FaceEmotionGuidId { get; set; }

    public DateTime Time  { get; set; }

    public string EmotionType { get; set; }

    public float EmotionValue { get; set; }

    public int DialogId { get; set; }

    public bool Sex { get; set; }

    public int Age { get; set; }

}

В данном случае это асинхронная процедура в связке с Cognitive Services Face API. AF получает Stream блоба и передает его в CS:

  var res = await cli.DetectAsync(InputFace,false,false,new FaceAttributeType[] { FaceAttributeType.Age, FaceAttributeType.Emotion, FaceAttributeType.Gender});

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

     var fc = (from f in res
              orderby f.FaceRectangle.Width
              select f).FirstOrDefault();

И записывает результаты распознания в базу данных:

await FaceData.AddAsync(R);
 

Всё просто, не правда ли? Будущее за микросервисами. )

О проблемах

Ладно, не всё так просто, на самом деле.

AF, к сожалению, на текущий момент имеет ряд ограничений (не работает биндинг имен, есть конфликты библиотек). К счастью, в мире разработки на .Net всегда есть множество walkarround — и если у вас не получается решить проблему по базовому сценарию, можно найти несколько обходных вариантов.

Съемка видео и аудио в фоновом режиме

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

Видео- и аудиопоток от веб-камеры получаем с помощью GetUserMedia(). Далее мы должны записать полученный видео- и аудиопоток и извлекать оттуда данные для передачи на бэкенд. Это работает, если окно браузера будет постоянно активным, как только вы делаете закладку браузера неактивной — становится недоступным для записи данных. Наша задача была сделать систему, которая будет работать в фоновом режиме и не будет мешать сотруднику осуществлять свои прямые обязанности. Поэтому решением стало создание собственной стримовой переменной, куда мы записываем и извлекаем данные видео- и аудиопотока.

Качество распознания русского языка

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

Возвращаемся в реальность

На самом деле это решение — не просто сказки о будущем. В ближайшее время Heedbook начнёт работать в подмосковных МФЦ и крупнейшем банке страны.

Команда Heedbook будет признательна за комментарии по поводу их решения, а также будет рада сотрудничеству с профессионалами в области ML, анализа данных, SEO и работе с крупными клиентами. Пишите свои мысли в комментариях или на почту info@heedbook.com.

https://habrahabr.ru/post/330942/

Привет Хабр! Я тут взялся за изучение Appium. В числе прочего, попалась мне книжка Appium Essentials:


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

Местами, в книге будут комментарии от меня [вот в таких скобках]. Они будут небольшие, просто для уточнения контекста, где необходимо. И еще одно: иногда, редко, буду пропускать какие-то совсем уж очевидные вещи из разряда как прописать JAVA_HOME. Пропущенные куски буду обозначать.

А в целом, с удовольствием принимаю указания на неточности перевода (с потерей смысла).
Надеюсь, перевод будет полезен. Поехали!

Глава 1. Важные концепции.

В этой главе мы поговорим об архитектуре Appium, JSON wire protocol, сессиях Appium, а также получим представление о Desired capabilities для запуска Appium.

• Архитектура Appium
• Selenium JSON wire protocol
• Сессии Appium
• Desired capabilities
• Сервер Appium server и клиентские библиотеки

---

Архитектура Appium

Appium — это HTTP-сервер, написанный на Nodes, который создает и обрабатывает WebDriver-сессии. Appium придерживается того же подхода, что и Selenium WebDriver, который получает HTTP-запросы в формате JSON от клиентов и преобразует их в зависимости от платформы, на которой он работает.

Давайте обсудим, как Appium работает с iOS и Android.

Appium и iOS

На iOS-устройстве, Appium использует Apple's UIAutomation API, чтобы взаимодействовать с UI-элементами. UIAutomation — это JavaScript-библиотека, разработанная Apple для написания тестовых сценариев. Appium использует эти же библиотеки для автоматизации iOS-приложений.

Давайте посмотрим на архитектуру, которая представлена ниже:



Исполняемый скрипт предается HTTP-запросом Appium-серверу в виде JSON. Appium-сервер шлет команду инструментам (UIAutomation). Инструменты ищут файл bootstrap.js, который Appium-сервер передал iOS-устройству. Затем, команды, указанные в файле bootstrap.js исполняются окружением iOS-инструментов. Выполнив команду, клиент отправляет серверу отчет с деталями выполнения этой команды.

Похожая архитектура работает и в связке Appium-Android.

---

Appium и Android

На Android-устройстве, Appium использует UIAutomator, чтобы автоматизировать приложение. UIAutomator — фреймворк, созданный командой разработчиков Android для тестирования пользовательского интерфейса.

Давайте посмотрим на архитектуру, которая представлена ниже:



На диаграмме выше у нас представлен UIAutomator/Selendroid вместо инструментов Apple и, вместо bootstrap.js передается bootstrap.jar. Appium поддерживает Android версии 17 и выше. Для более ранних версий, используется Selendroid. Во время выполнения теста, Appium отправляет команды к UIAutomator или Selendroid, в зависимости от версии Android. Здесь, bootstrap.jar играет роль TCP-сервера, который мы можем использовать, чтобы отправлять команды. Команды, в свою очередь выполняются на Android-устройстве средствами Selendroid или UIAutomator.

Selenium JSON wire protocol

JSON wire protocol (JSONWP) — механизм, созданный командой разработчиков WebDriver. Этот протокол представляет собой набор четко определенных стандартизированных конечных точек (endpoints), открытых через RESTful API. Предназначение WebDriver и JSONWP — автоматизировать тестирование сайтов через браузер таких как Firefox driver, IE driver, Chrome driver и т.д.

Appium реализует Mobile JSONWP — расширение Selenium JSONWP — и контролирует различное поведение мобильных устройств, например установка/удаление приложения за сессию.

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

• /session/:sessionId
• /session/:sessionId/element
• /session/:sessionId/elements
• /session/:sessionId/element/:id/click
• /session/:sessionId/source
• /session/:sessionId/url
• /session/:sessionId/timeouts/implicit_wait

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

AppiumDriver.getPageSource();

Этот метод вызовет HTTP-запрос, и получит ответ от конечной точки [можно, я дальше буду писать «эндпоинта»? Сил уже нет] из API. Конкретно в этом примере, эндпоинт, который обрабатывает метод getPageSource, выглядят так:

/session/:sessionId/source

Драйвер выполнит тестовый скрипт, который приходит в JSON-формате от AppiumDriver сервера, чтобы получить source страницы. Назад вернется page source в формате строки. В случае не-HTML платформ (нативные приложения), Appium вернет XML-документ, представляющие иерархию UI-элементов. Структура документа может отличаться, в зависимости от платформы.

---

Сессии Appium

Сессия — среда, в которой происходит отправка команд конкретному приложению; команда всегда исполняется в контексте текущей сессии. Как мы видели в предыдущем разделе, клиент использует идентификатор сессии — параметр sessionId — до выполнения самой команды. Клиентская библиотека шлет запрос серверу на создание сессии. Затем, сервер возвращает sessionId, который используется в последующих командах для взаимодействия с тестируемым приложением.

---

Desired capabilities

Desired capabilities [желаемые возможности] — JSON-объект (набор пар ключ-значение), отправленный клиентом серверу. DC описывает особенности создаваемой сессии.

Давайте рассмотрим все имеющиеся возможности. Сперва, мы увидим возможности для Appium-сервера:
Необходимо импортировать библиотеку org.openqa.Selenium.remote.DesiredCapabilities [пример для Java], чтобы работать с DC.

Возможность	Пояснение
automationName	Используется, чтобы определить исполнителя команд. Если вы хотите работать с Android SDK версии ниже 17, нужно указать значение Selendroid. Иначе, по дефолту будет установлено значение Appium. Пример: DesiredCapabilities caps = new DesiredCapabilities(); // создали объект caps.setCapability("automationName","Selendroid"); // установили значение Также можно определять возможности, используя библиотеку Appium. Нужно импортировать библиотеку io.appium.java_client.remote.MobileCapabilityType: caps.setCapability(MobileCapabilityType.AUTOMATION_NAME,"Selendroid"); В случае работы с iOS эту возможность использовать не нужно.
platformName	Указывает операционную систему на мобильном устройстве. Допустимые значения: iOS, Android и FirefoxOS. Пример: caps.setCapability("platformName","Android"); Или с использованием библиотеки Appium: caps.setCapability(MobileCapabilityType.PLATFORM_NAME, "Android");
platformVersion	Определяет версию операционной системы. Пример: caps.setCapability("platformVersion","4.4.4"); Или с использованием библиотеки Appium: caps.setCapability(MobileCapabilityType.PLATFORM_VERSION, "4.4.4");
deviceName	Устанавливает тип устройства или эмулятора, например iPhone Simulator, iPad Simulator, iPhone Retina 4-inch, Android Emulator, Moto x, Nexus 5 и так далее. Пример: caps.setCapability("deviceName", "Nexus 5"); Или с использованием библиотеки Appium: caps.setCapability(MobileCapabilityType.DEVICE_NAME,"Nexus 5");
app	Абсолютный путь до файла или URL для скачивания файла в формате .ipa, .apk, или .zip. Appium сначала установит приложение на соответствующее устройство. Отметим, что если для Android определить возможности appPackage и appActivity (о них рассказывается ниже), то app указывать не нужно. Пример: caps.setCapability("app","/apps/demo/demo.apk or http://app.com/app.ipa"); Или с использованием библиотеки Appium: caps.setCapability(MobileCapabilityType.APP,"/apps/demo/demo.apk or http://app.com/app.ipa");
browserName	Используется при тестировании веб-приложений на мобильном устройстве. Определяет браузер для тестирования. Пример: caps.setCapability("browserName", "Safari"); Или с использованием библиотеки Appium: caps.setCapability(MobileCapabilityType.BROWSER_NAME, "Safari");
newCommandTimeout	Appium ждет новую команду от клиента в течение некоторого времени, после чего [если команд не поступало], решает, что клиент выключен и завершает сессию. Значение по умолчанию 60 [секунд]. Пример: caps.setCapability("newCommandTimeout", "30"); Или с использованием библиотеки Appium: caps.setCapability(MobileCapabilityType.NEW_COMMAND_TIMEOUT,"30");
autoLaunch	Устанавливает автозапуск тестируемого приложения. По дефолту стоит значение true. Пример: caps.setCapability("autoLaunch","false");
language	Устанавливает язык на эмуляторе. К примеру fr, es и так далее. Пример: caps.setCapability("language","fr");
locale	Устанавливает локаль на эмуляторе. К примеру fr_CA, tr_TR и так далее. Пример: caps.setCapability("locale","fr_CA");
udid	Уникальный идентификатор девайса (unique device identifier) обычно используется для идентификации конкретного iOS-устройства. Представляет собой строку в 40 символов (например, 1be204387fc072g1be204387fc072g4387fc072g). udid указывается при автоматизации приложений на реальных iOS-устройствах. Udid устройства можно легко получить через iTunes, кликнув на Serial Number в инфо об устройстве. Пример: caps.setCapability("udid", "1be204387fc072g1be204387fc072g4387fc072g");
orientation	Устанавливает ориентацию устройства при работе с эмулятором. Допустимые значения: LANDSCAPE и PORTRAIT. Пример: caps.setCapability("orientation", "PORTRAIT");
autoWebview	Если вы тестируете гибридное приложение и хотите взаимодействовать с Webview, вам нужно установить такую возможность; по умолчанию стоит значение false. Пример: caps.setCapability("autoWebview", "true");
noReset	Сбрасывать текущее состояние приложения перед стартом сессии. Дефолт: false. Пример: caps.setCapability("noReset", "true");
fullReset	Для iOS: удалит всю папку симулятора. Для Android: вместо удаления всего из папки приложения, можно удалить само приложение, чтобы сбросить состояние. Также, приложение будет удалено по окончанию жизни сессии. По умолчанию false. Пример: caps.setCapability("fullReset", "true");

Android capabilities

Возможность	Пояснение
appPackage	Определяет, какой Java-пакет должен быть запущен. Например: com.android.calculator2 или com.android.settings caps.setCapability("appPackage", "com.android.calculator2"); Или с использованием библиотеки Appium: caps.setCapability(MobileCapabilityType.APP_PACKAGE, "com.android.calculator2");
appActivity	Определяет, какую Activity необходимо запустить из указанного пакета. Например: MainActivity, .Settings, com.android.calculator2.Calculator caps.setCapability("appActivity", "com.android.calculator2.Calculator"); Или с использованием библиотеки Appium: caps.setCapability(MobileCapabilityType.APP_ACTIVITY, "com.android.calculator2.Calculator");
appWaitActivity	Определяет, какую Activity, при запуске, нужно дождаться. caps.setCapability("appWaitActivity","com.android.calculator2.Calculator"); Или с использованием библиотеки Appium: caps.setCapability(MobileCapabilityType.APP_WAIT_ACTIVITY,"com.android.calculator2.Calculator");
appWaitPackage	Определяет, какую пакет Android-приложения, при запуске, нужно дождаться. caps.setCapability("appWaitPackage","com.example.android.myApp");
deviceReadyTimeout	Определяет, таймаут (в секундах), в течение которого ожидается готовность девайса. По дефолту 5. caps.setCapability("deviceReadyTimeout","10"); Или с использованием библиотеки Appium: caps.setCapability(MobileCapabilityType.DEVICE_READY_TIMEOUT,"10");
enablePerformanceLogging	Активирует Chrome driver performance logging. Доступно только при работе с Chrome и WebView. По умолчанию значение false caps.setCapability("enablePerformanceLogging", "true");
androidDeviceReadyTimeout	Устанавливает таймаут в секундах, сколько ждать, пока девайс станет готовым после включения. caps.setCapability("androidDeviceReadyTimeout","20");
androidDeviceSocket	Используется для установки DevTools socket name. Необходимо только когда приложение — Chromium-embedding browser. Браузер открывает сокет и ChromeDriver подключается к нему как DevTools client. Например, chrome_DevTools_remote caps.setCapability("androidDeviceSocket","chrome_DevTools_remote");
avd	Задает имя avd [Android virtual device] для запуска. caps.setCapability("avd","AVD_NEXUS_5");
avdLaunchTimeout	В миллисекундах задает время на ожидание запуска указанного avd. По умолчанию 120000. caps.setCapability("avdLaunchTimeout","230000");
avdReadyTimeout	В миллисекундах задает время на ожидание, когда закончатся анимации запуска avd. По умолчанию 120000. caps.setCapability("avdReadyTimeout","240000");
avdArgs	Позволяет передать дополнительные параметры при запуске avd [startup options]. caps.setCapability("avdArgs","netfast");
autoWebviewTimeout	Задает время ожидания (в миллисекундах), в течение которого ожидается WebView context, прежде чем, переключиться на него. По умолчанию 2000 caps.setCapability("autoWebviewTimeout","3000");
intentAction	Intent action обычно используется, чтобы запустить activity. По дефолту: android.intent.action.MAIN caps.setCapability("intentAction","android.intent.action.VIEW");
intentCategory	Определяет категорию Intent для запуска activity. По дефолту: android.intent.category.LAUNCHER caps.setCapability("intentCategory","android.intent.category.APP_CONTACTS");
intentFlags	Флаги, используемые при запуске Activity. По дефолту: 0x10200000 caps.setCapability("intentFlags","0x10200000");
intentFlags	Разрешает ввод юникода. По дефолту: false caps.setCapability("unicodeKeyboard","true");
resetKeyboard	Сбрасывает клавиатуру до ее исходного состояния. По дефолту: false caps.setCapability("resetKeyboard","true");

iOS capabilities

Возможность	Пояснение
calendarFormat	Задает формат календаря для симулятора iOS. Пример: caps.setCapability("calendarFormat"," Gregorian");
bundleId	Используется для запуска приложения на реальном девайсе. Пример: caps.setCapability("bundleId"," io.appium.TestApp");
launchTimeout	Задает время ожидания (в миллисекундах) инструментов. По истечению времени, Appium решает, что там все повисло и сессия закрывается. caps.setCapability("launchTimeout","30000");
locationServicesEnabled	включает location Services caps.setCapability("locationServicesEnabled","false");
locationServicesAuthorized	Используется в симуляторе. Если значение true, в приложении не будет всплывать поп-ап с запросом доступа к location services. Для использования требуется явно указывать bundleId. По дефолту: false caps.setCapability("locationServicesAuthorized","true");
autoAcceptAlerts	Автоматически разрешаются доступы приложению к фото, контактам, камере т.д. По дефолту: false caps.setCapability("autoAcceptAlerts","true");
nativeInstrumentsLib	Подключает библиотеку native instruments caps.setCapability("nativeInstrumentsLib","true");
nativeWebTap	При работе с Safari имитирует событие tap. По дефолту: false. Работает не идеально и зависит от viewport's size/ratio caps.setCapability("nativeWebTap","false");
safariAllowPopups	Используется только на симуляторе. Позволяет открывать в Safari новые окна средствами JavaScript caps.setCapability("safariAllowPopups","false");
safariIgnoreFraudWarning	Используется только на симуляторе. Запрещает Safari показывать сообщения, что сайт мошеннический. caps.setCapability("safariIgnoreFraudWarning","false");
safariOpenLinksInBackground	Используется только на симуляторе. Позволяет Safari открывать новые вкладки. caps.setCapability("safariOpenLinksInBackground","true");
keepKeyChains	Используется только на симуляторе. Позволяет хранить связки ключей при запуске/отключении сессии. caps.setCapability("safariOpenLinksInBackground","true");
processArguments	Позволяет передавать аргументы при использовании instruments. caps.setCapability("processArguments","myflag");
interKeyDelay	Задает в миллисекундах длительность нажатия на элемент. caps.setCapability("interKeyDelay","100");

---

Сервер Appium server и клиентские библиотеки

Appium-сервер используется для взаимодействия с разными платформами (iOS и Android). Он создает сессию, чтобы взаимодействовать с мобильными приложениями. Это — HTTP-сервер, написанный на NodeJS и использует ту же идею, что и Selenium Server, который определяет HTTP-запросы от клиентских библиотек и шлет свои запросы соответствующим платформам. Чтобы запустить Appium-сервер, необходимо скачать исходники или установить из npm. Также у Appium есть GUI-версия сервера. Ее можно скачать с официального сайта http://appium.io. В следующих главах мы рассмотрим GUI-версию подробнее.

Одним из плюсов Appium является то, что это — просто REST API. И код, с помощью которого вы взаимодействуете с этим API, может быть написан на разных языках, таких как Java, C#, Ruby, Python и других. Appium расширяет библиотеку WebDriver и добавляет команды для работы с мобильными устройствами. Он предоставляет клиентские библиотеки, поддерживающие расширения Appium для протокола WebDriver. Именно из-за этих расширений важно использовать клиентские библиотеки, специфичные для Appium, чтобы писать автоматизированные тесты или процедуры вместо общих клиентских библиотек WebDriver.

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

---

Заключение

К концу главы, у нас должно появиться понимание архитектуры Appium, JSON wire protocol, desired capabilities и как ими пользоваться. мы также узнали об Appium-сервере и клиентских библиотеках на разных языках программирования.

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

В следующей главе, мы посмотрим, что необходимо, чтобы начать работу с Appium работу с Appium

https://habrahabr.ru/post/331224/

Совсем недавно мы опубликовали первую часть интервью с ведущими специалистами из компаний РТ ЛАБС, Git in Sky, Postgres Professional, Avito и EnterpriseDB. Если сейчас вы решаете, стоит ли связывать свою жизнь с профессией DBA, то вам придется очень кстати вторая часть советов от спикеров PG Day’16. А если вопросы еще останутся, то вы можете задать их докладчикам текущего года с 5 по 7 июля на PG Day’17 Russia.

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

Александр Чистяков: Читайте планы запросов. Думайте быстрее, чем люди, которые эксплуатируют то, что вы написали. Занимайтесь спортом, хорошо спите по ночам.





Антон Бушмелев: Надо знать свою предметную область. Если работаешь с ORM, как обычно у нас происходит: я “наг*внокодил”, как оно будет работать с базой, мне не важно! Не надо так абстрагироваться. Если что-то не знаешь, можно подойти, спросить. Потраченные пять минут времени сильно сэкономят время в будущем. Не надо стесняться, я тоже много чего не знаю. Если есть эксперты, с которыми можно посоветоваться, надо общаться.


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


Михаил Тюрин: Здесь все очень серьезно, никаких шуток, разработчикам приложений надо понимать, что работа с данными – это одна из основных задач, которая должна ими решаться. Надо подключать ДБА на ранних этапах.

Мы сейчас все “заражены” современными моделями управления (agile и прочие вещи). Надо и ДБА, и devops-ов как можно раньше подключать к процессу принятия окончательного решения, потому что ошибиться в данных может оказаться очень дорого.

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


Брюс Момжан: Я могу ответить относительно Постгреса: нужно проводить исследования и узнавать его разносторонние возможности. Многие, приходя из других СУБД, пользуются им по привычке: «Я всегда делал это так, буду делать как привык». В этом нет ничего плохого, но Постгрес – это намного больше, чем хранилище данных. Не обязательно использовать Постгрес так, как вы использовали БД до этого, изучайте современные нестандартные функции, относящиеся к консистентности данных, моделированию данных, они сделают ваше приложение проще и чище.

Место ДБА в процессе разработки и эксплуатации IT-систем?

Александр Чистяков: ДБА – это человек, который находится на обеих сторонах моста – разработка и эксплуатация. Человек, который смотрит за тем, чтобы не происходило чего-то непредвиденного. Он должен концентрировать в себе знания о том, как работает база данных, и передавать их другим.

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

Дмитрий Васильев: Как я уже говорил, база данных – это сердце и кровеносная система, поэтому обсуждение и архитектурное построение должно происходить при участии ДБА. Это одно из ключевых мест участия в разработке, не только как devops решать проблемы приложения.

Михаил Тюрин: Одно из центральных мест.


Брюс Момжан: ДБА – не просто люди, которые стоят между приложением и ОС, они занимаются производительностью, надежностью хранилища данных, задержками ответов сети. То есть гораздо больше завязаны на аппаратное обеспечение и его производительность. Запросы к базе данных могут быть как очень простыми, так и очень сложными – тут сложно предсказать. ДБА участвуют в выборе аппаратного обеспечения, типа хранилища и видят картину в целом, ведь требования к производительности могут меняться.

Чем определяется продвинутость какой-то СУБД относительно других?

Александр Чистяков: Это – субъективная вещь. На конференции по Постгресу я считаю, что PostgreSQL – продвинутая, а если бы здесь была конференция по MySQL – извините, ребята…

Антон Бушмелев: Коммьюнити и обучение. Обучение по постгресу страдает. В Oracle все расписано по частям. Есть отдельные курсы для тех, кто занимается бэкапами, тех, кто занимается производительностью, и, собственно, “джобстартом”.

Коммьюнити и обучение – без этого никак. База, может быть, очень продвинулась, но с ней никто не работает, и никто не поможет, если возникнут какие-то проблемы.

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

Михаил Тюрин: Продвинутость – это же довольно субъективное понятие. Если у вас хорошо получается делать вашу работу, то ваша технология продвинутая. У меня получается делать хорошо свою работу на Постгресе, поэтому я считаю ее продвинутой.

Но есть и объективные стороны, такие как открытость комьюнити. В открытом комьюнити заложены, культивируются и воспроизводятся те принципы, понятия и идеи, которые могут быть эффективны. Хоть Stonebraker и ругается сейчас и перечеркивает все, что он когда то сделал, все это было сделано неплохо. Stonebraker – это человек, который получил только что премию Тьюринга, он в свое время заложил архитектурные основы в том числе и Постгреса.

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

Какой бы вы совет дали молодым специалистам, которые хотят заниматься базами данных?

Александр Чистяков: Читайте классику, смотрите вокруг себя, ходите на конференции.


Антон Бушмелев: Следить за мониторингом. Мониторинг – наше все. Повесить основные триггеры на мониторинг, чтобы потом спать спокойно. Вместо того, чтобы каждый полчаса делать health checks, можно все это подать на мониторинг, а самому заниматься саморазвитием.

Дмитрий Васильев: Изучайте, не бойтесь пробовать, обязательно экспериментируйте. Я не говорю об экспериментах на “продакшне”, это оборачивается изменением зарплаты. Ищите что-то новое и неизведанное!

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

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

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

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

Брюс Момжан: Быть открытым ко всему новому. Когда я занимался консалтингом, были люди, которые специализировались на самом популярном на тот момент программном обеспечении. Они знали всё об MS DOS и Windows, это было самое актуальное ПО, и они на нём выезжали. Через 2-3 года приоритеты сменились, другое ПО стало актуальным, а за ним другое. Многие смотрят на эту смену приоритетов, и думают: «Всё приходит и уходит, я просто буду заниматься тем, чем занимаюсь». Но если присмотреться, можно понять, какие технологии будут оставаться жизнеспособными долгое время, а какие – просто милые мимолетные идеи.

Какое технологическое достижение/изобретение в мире баз данных вы считаете наиболее прорывным и почему?

Александр Чистяков: Появление баз данных NoSQL.


Антон Бушмелев: Оракловый кластер пока что еще никто не повторил, это штука специфическая, но хорошая. Особенно в 12 версии. Прорывные технологии, которые сейчас используются – это in-memory. Это отсутствие индексов, меньше блокировок, соответственно. Отсутствие индексов – это уже большой плюс.

Дмитрий Васильев: Наверное, самое большое изменение, которое произошло в базах данных за последние десятки лет – это column-oriented базы.

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

Брюс Момжан: Если говорить об аппаратном обеспечении, то самым главным изменением стало появление SSD. До этого всё хранилось на магнитных носителях, которые вращались, и доступ к этим данным был очень медленным. Использование SSD существенно улучшило производительность.

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

Какие недостатки есть у PostgreSQL и Open Source вообще?

Александр Чистяков: У open source в принципе нет недостатков, это единственный живой workflow, который может существовать. Еще до того как появилось слово open source, люди обменивались исходниками, это было всегда в научном сообществе. Атомную бомбу передали нам. Это же сделали не из-за денег, а из-за убеждений.

Касательно PostgreSQL – недостатки вполне преодолимы. Это отсутствие должного количества рабочих рук. Единственный вариант бороться с этим – это увеличивать visibility, доносить свою мысль до людей, который хотят участвовать. Я думаю, что open source в конечном итоге – это единственный живой путь. Все то, что является closed source, просто не успевает за open source.

Антон Бушмелев: Огромное количество костылей. С самого начала – это одни костыли сплошные, нет единого решения – все пилят под себя. Куча оберток, все это сложно поддерживать. С PostgreSQL для меня конкретно проблема – это бэкап больших баз. Невозможно определить, на чем конкретно висит сессия, нет дебага. Дебаг есть, но он на всю базу. Смысла читать двухгиговую “портянку” логов, когда мне нужно что-то выяснить по конкретной сессии, я не вижу.

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

Михаил Тюрин: Если сравнивать подобные сообщества по количеству участников – может показаться, что постгресовое комьюнити менее представлено.

Имеет ли Постгрес недостатки как продукт? Нет, я так не считаю. Может быть, можно произвести работу по интеграции с другими комьюнити. У постгрес есть своя ниша, многие компании эффективно его используют.

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

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

Какой бы вы выделили top современных СУБД и почему он именно такой?

Александр Чистяков: У меня есть два личных топа – есть то, что я люблю, и есть то, что я делаю. Я люблю Постгрес, я меньше люблю MySQL. Еще меньше я люблю Firebird, потому что я никогда с ним не работал, но я люблю людей, которые его делают. А все остальное я не знаю. В плане бизнеса, я очень много делаю MySQL. Новые проекты, которые хоть какое то отношение имеют к процессингу денег, я делал на PostgreSQL, а больше ничего нет. Кроме PostgreSQL и MySQL больше ничего нет.

Антон Бушмелев: Oracle, так как я с ней работаю уже 7 лет. Постгрес – потому что большой потенциал. MySQL – потому что в России это 1С. 1С очень хорошо работает с MySQL, хоть и пытаются доказать, что Постгрес там как-то шевелится. Но буквально на той неделе видел инсталляцию на 7 терабайт, и на MySQL это все работает.

Дмитрий Васильев: Oracle, PostgreSQL, MS SQL, DB2.


Михаил Тюрин: Oracle, Постгрес, решения Microsoft и IBM – это все развитые системы. У них есть свои плюсы и минусы, истории применения. MySQL, конечно.

Из современных новых систем я бы выделил Redis, MongoDB. Из специализированных решений – системы Vertica, Cassandra. Есть и другие подобные вещи, такие как Kafka. Есть специализированные решения по распределенному хранению, такие как Zoo Keeper.

Брюс Момжан: Естественно, для меня на первом месте будет Постгрес, потому что я с ним работаю. Это отличная СУБД общего назначения, он также подходит для работы с непоследовательными рабочими нагрузками и с каждой версией становится лучше по многим параметрам.

Oracle продолжает лидировать при очень больших объемах. Постгрес на данный момент может покрыть 95-98% рабочих нагрузок, но остаются эти 2%.

Плюс Microsoft SQL в том, что он интегрирован с окружением Windows. DB2, на мой взгляд, недооценивают. Это очень хорошая система, но из-за тесной привязки к аппаратному обеспечению IBM, она кажется очень негибкой, и это многих отталкивает.

Про NoSQL. Несколько лет назад считалось «благородным» не использовать SQL и не иметь необходимости в администраторе баз данных. Но примерно полтора года назад всё изменилось, потому что, несмотря на простоту развертывания NoSQL, стала ощущаться нехватка многих функций. Сейчас зачастую используют смесь Постгреса и NoSQL и добиваются потрясающих результатов. Так что NoSQL – не последнее испытание для реляционных БД, но они существуют уже 30 лет, развиваются, адаптируются, и я думаю, так будет продолжаться и дальше.

MySQL остался позади около пяти лет назад, когда Постгрес стал делать всё то же, что и MySQL, только лучше. Но потребовалось время, чтобы индустрия это осознала. Многие продолжают пользоваться MySQL по привычке, но новые компании его уже не выбирают. Это нормально. Когда-нибудь и Постгрес уйдет в небытие, но надеюсь, меня тогда уже не будет.

https://habrahabr.ru/post/331148/

Расскажем о том, как устроен поиск похожих треков среди всех аудиозаписей ВКонтакте.

Зачем всё это надо?

У нас действительно много музыки. Много — это больше 400 миллионов треков, которые весят примерно 4 ПБ. Если загрузить всю музыку из ВКонтакте на 64 ГБ айфоны, и положить их друг на друга, получится башня выше Эйфелевой. Каждый день в эту стопку нужно добавлять еще 25 айфонов — или 150 тысяч новых аудиозаписей объёмом 1.5 ТБ.

Конечно, далеко не все эти файлы уникальны. У каждого аудио есть данные об исполнителе и названии (опционально — текст и жанр), которые пользователь заполняет при загрузке песни на сайт. Премодерации нет. В результате мы получаем одинаковые песни под разными названиями, ремиксы, концертные и студийные записи одних и тех же композиций, и, конечно, совсем неверно названные треки.

Если научиться достаточно точно находить одинаковые (или очень похожие) аудиозаписи, можно применять это с пользой, например:

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

Пожалуй, первое, что приходит в голову — это ID3-теги. У каждого mp3-файла есть набор метаданных, и можно принимать во внимание эту информацию как более приоритетную, чем то, что пользователь указал в интерфейсе сайта при загрузке трека. Это самое простое решение. И оно не слишком хорошее — теги можно редактировать вручную, и они совсем не обязательно соответствуют содержимому.

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

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

Кажется, кто-то уже это делал?

Поиск похожих аудио — довольно популярная история. Ставшее уже классическим решение используется всеми подряд, от Shazam’а до биологов, изучающих вой волков. Оно основано на акустических отпечатках.

Акустический отпечаток — это представление аудиосигнала в виде набора значений, описывающих его физические свойства.

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

Мы начали с попытки использовать одно из готовых решений на C++ для генерации акустических отпечатков. Прикрутили к нему свой поиск, протестировали на реальных файлах и поняли, что для значительной части выборки результаты плохие. Один и тот же трек успешно «маскируется» эквалайзером, добавлением фонового шума или джинглов, склейкой с фрагментом другого трека.

Вот как это выглядит (в сравнении с исходным треком):



Лайв-исполнение



Эхо



Ремикс

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

Генерация отпечатка

Что ж, у нас есть аудиозапись в виде mp3-файла. Как превратить его в компактный отпечаток?

Нужно начать с декодирования аудиосигнала, который в этот файл упакован. MP3 представляет собой цепочку фреймов (блоков), в которых содержатся закодированные данные об аудио в формате PCM (pulse code modulation) — это несжатый цифровой звук.

Чтобы получить PCM из MP3, мы использовали библиотеку libmad на С и собственную обертку для неё на Go. Позднее сделали выбор в пользу прямого использования ffmpeg.

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

Аудиосигнал

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

Мы хотим знать, какие частоты есть в нашем сигнале, а особенно — какие из них наиболее «характерны» для него. Прибегнем к каноническому способу получения таких данных — быстрое преобразование Фурье (FFT).

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

В нашей реализации используется пакет GO-DSP (Digital Signal Processing), а именно github.com/mjibson/go-dsp/fft — собственно FFT и github.com/mjibson/go-dsp/window — для оконной функции Ханна.

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

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

Например:

Спектрограмма эталонной дорожки

По оси X отсчитывается время, ось Y представляет частоту, а значение амплитуды обозначается интенсивностью цвета пикселя. На иллюстрации приведена спектрограмма для «эталонного» сигнала с равномерно повышающейся частотой. Для обычной песни спектрограмма выглядит, например так:



Спектрограмма обычной дорожки

Это довольно подробный «портрет» аудиодорожки, из которого можно (с определённой аппроксимацией) восстановить исходный трек. С точки зрения ресурсов, хранить такой «портрет» полностью невыгодно. В нашем случае это потребовало бы 10 ПБ памяти — в два с половиной раза больше, чем весят сами аудиозаписи.

Мы выбираем ключевые точки (пики) на спектрограмме, основываясь на интенсивности спектра, чтобы сохранять только самые характерные для этого трека значения. В результате объём данных сокращается примерно в 200 раз.



Ключевые значения на спектрограмме

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

Сравнение отпечатков

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

Каждый отпечаток — массив значений. Попробуем сравнивать их поэлементно, сдвигая треки по временной шкале относительно друг друга (сдвиг нужен, например, чтобы учесть тишину в начале или в конце трека). На одних смещениях совпадений в отпечатках будет больше, на других — меньше. Выглядит это примерно так:



Треки с общим фрагментом и разные треки

Похоже на правду. Для треков с общим фрагментом этот фрагмент нашелся и выглядит как всплеск числа совпадений на определённом временном смещении. Результат сравнения — «коэффициент сходства», который зависит от числа совпадений с учетом смещения.

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

Теперь надо встроить всё это в нашу инфраструктуру и посмотреть, что получится.

Архитектура

Движки генерации отпечатков и индексирования/поиска в архитектуре ВК

Движок для генерации отпечатков работает на каждом сервере для загрузки аудио (их сейчас около 1000). Он принимает на вход mp3-файл, обрабатывает его (декодирование, FFT, выделение пиков спектра) и выдаёт акустический отпечаток этого аудио.

Нагрузка распараллеливается на уровне файлов — каждый трек обрабатывается в отдельной горутине. Для средней аудиозаписи длительностью 5-7 минут обработка занимает 2-4 секунды. Время обработки линейно растет с увеличением длительности аудио.

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

Он хранит данные об отпечатках в виде обратных (инвертированных) индексов:


Обратный индекс

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

Вместо того, чтобы хранить соответствие «трек» -> «отпечаток», мы разбиваем каждый отпечаток на хэши и храним соответствие «хэш» -> «список треков, в отпечатках которых он есть». Индекс прореженный, и 20 ТБ отпечатков в виде индекса займут около 100 ГБ.

Как это работает на практике? В движок поиска приходит запрос с аудиозаписью. Нужно найти похожие на неё треки. Из хранилища скачивается отпечаток для этого аудио. В индексе выбираются строчки, содержащие хэши этого отпечатка. Из соответствующих строк выбираются часто встречающиеся треки, для них скачиваются отпечатки их хранилища. Эти отпечатки сравниваются с отпечатком исходного файла. В результате возвращаются самые похожие треки с соответствующими совпавшими фрагментами и условным «коэффициентом сходства» для этих фрагментов.

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

Итак, вся логика готова. Давайте соберем отпечатки всей музыки, проиндексируем и начнём с ними работать. Кстати, сколько времени это займёт?

Мы запустили индексацию, подождали пару дней и оценили сроки. Как оказалось, результат будет примерно через год. Такой срок неприемлем — нужно что-то менять.

Внедрение sync.Pool везде, где только можно, выкроило 2 месяца. Новый срок: 10 месяцев. Это всё ещё слишком долго. Надо лучше.

Оптимизируем тип данных — выбор треков по индексу был реализован слиянием массива. Использование container/heap вместо массива обещает сэкономить половину времени. Получаем 6 месяцев выполнения. Может, можно ещё лучше?

Затачиваем container/heap под использование нашего типа данных вместо стандартных интерфейсов, и выигрываем ещё месяц времени. Но нам и этого мало (то есть много).

Правим stdlib, сделав собственную реализацию для container/heap — ещё минус 2 месяца, итого остаётся 3. В четыре раза меньше первых оценок!

И, наконец, обновление версии Go с 1.5 на 1.6.2 привело нас к финальному результату. 2.5 месяца потребовалось в итоге на создание индекса.

Что получилось?

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



Ускоренная дорожка

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

Чтобы это исправить, мы добавили немного преобработки. Заключается она в поиске наибольшей общей подпоследовательности (Longest Common Subsequence) в двух отпечатках. Ведь амплитуда и частота не меняются, меняется в этом случае только соответствующее значение времени, а общий порядок следования точек друг за другом сохраняется.


LCS

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

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

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



Совпадения фрагментов треков

Мы раскладываем результат сравнения по времени и смотрим на число совпадений для каждой секунды трека. На картинке выше как раз пример любительской записи поверх минуса в сравнении с исходным треком этого минуса. Интервалы с отсутствием совпадений — вокал, пики совпадений — молчание (т.е. чистый минус, который аналогичен исходной дорожке). В такой ситуации мы считаем число фрагментов с совпадениями и вычисляем условный «коэффициент сходства» по числу самих совпадений.

После кластеризации похожих треков отдельные кластеры оказались значительно больше остальных. Что там? Там — интересные ситуации, в которых не очень понятно, чем их правильно считать. Например, всем известная Happy Birthday to You. У нас есть несколько десятков вариантов этой песни, которые отличаются только именем поздравляемого. Считать их разными или нет? То же касается и версий трека на разных языках.

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

P.S. Это первая статья из цикла давно обещанных нами историй про техническую сторону ВКонтакте.

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

https://habrahabr.ru/post/330988/

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



Мы проводим целые часы на Facebook, Twitter и Snapchat в условиях полностью цифровой среды социального общения. На смартфонах мы играем в игры с дополненной реальностью, такие как Ingress, позволяющие нам взаимодействовать с компьютерными персонажами на фоне окружающей нас объективной реальности. А кроме того, в последнее время мы начали погружаться в полностью вымышленные миры с помощью VR-шлемов.

Интерес потребителей к дополненной или виртуальной реальности велик как никогда. По прогнозам Citi GPS, рынок дополненной и виртуальной реальности к 2025 году может вырасти до 692 млрд долларов. Согласно исследованию другого международного консалтингового авторитета IDC, количество проданных в 2021 году AR и VR шлемов достигнет 99 млн единиц.

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

Тема будущего AR и VR устройств вызывает немало споров, однако конечный успех этих технологий будет определен их востребованностью у потребителей.

Для понимания того, как основная масса покупателей относится к AR и VR, консалтинговая компания Worldpay провела опрос 16 тыс. потребителей из 8 стран и пришла на его основании к выводу о наличии видимых преград, стоящих на пути широкого распространения технологий.

По данным опроса, дополненная и виртуальная реальности вызывают у потребителей живой интерес, и рассматриваются ими как платформы, способные изменить способы взаимодействия людей друг с другом и с бизнесами. Более половины (55%) респондентов из самых разных стран мира, выразили мнение, что технологии AR и VR в ближайшие годы станут так же популярны, как и смартфоны. Тем не менее беспокойства по поводу конфиденциальности распространяемых в виртуальных средах данных, говорят о том, что мерчантам, вероятно, будет непросто продвигать убедительные пользовательские кейсы, особенно на рынках развитых стран.

Готовы ли мы к виртуальной коммерции?

Потребители по всему миру высказывают различные беспокойства по поводу VR-платежей, однако больше всего тревог по этому поводу возникает на западных рынках. Всего лишь 35% покупателей в Великобритании и 30% в Нидерландах готовы попробовать на практике схемы покупки продуктов в виртуальной или дополненной реальности.

Совсем иная ситуация складывается в Китае, где 50% потребителей утверждают, что уже пользуются VR или AR как минимум раз в неделю. Это обусловлено тем, что китайские покупатели очень сильно ориентированы на мобильный опыт и такой редкий для потребителей большинства других развитых стран тип мышления делает их открытыми ко многим другим видам взаимодействия с мерчантами, выходящим за пределы традиционных цифровых каналов взаимодействия.

Потребители самых развитых экономик более скептически относятся к изменениям и потому на этих рынках появление первых платежных сценариев в VR потребует больше времени. Лишь 23% голландских потребителей верят, что VR-устройства безопасны для проведения платежей, тогда как среди китайских покупателей этот показатель составляет 59%. Схожее количество (57%) голландских потребителей, напротив, считают десктопы и ноутбуки безопасными устройствами для совершения оплаты.

Следует отметить, что масштабные продажи становятся возможны в результате достижения правильного баланса инноваций, своевременных операционных решений и потребности в новых технологиях. Баланс этот разнится от рынка к рынку. Если в большинстве стран мира лишь 18% респондентов характеризуют себя как первопроходцев в деле применения новых технологий, то в Китае этот показатель достигает целых 44%.

Потребители желают, чтобы бренды более тесно взаимодействовали с ними в цифровом пространстве. Около 60% участников опроса Worldpay желают, чтобы ритейлеры предоставляли им AR и VR опыт в качестве составной части более крупного процесса шоппинга. Как бы то ни было, для глобального и успешного распространения этих технологий, потребуется нечто большее чем просто интерес к инновациям. Люди должны испытать истинную потребность в применении виртуальной реальности в повседневной жизни, и задача подогрева этого интереса с помощью качественных и привлекательных пользовательских кейсов ложится на плечи производителей устройств и бизнесов.

Устранение преграды в виде стоимости

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

Самые передовые модели шлемов от Oculus и Vive по-прежнему стоят более 700 долларов, в результате для мерчантов, и без того изо всех сил борющихся за защиту своей маржи, их приобретение в дорогостоящую азартную игру для потребителей они превращаются просто в малодоступный товар. Примерно около трети респондентов опроса Worldpay признают, что высокая стоимость удерживает их от покупки VR-шлема.

Более дешевые альтернативы вроде Samsung VR Gear и еще более дешевый Google Cardboard, действительно снискавшие большую популярность, серьезно отстают от своих передовых аналогов по части эффекта полного погружения из-за ограничений угла обзора и низкого разрешения видео.

Оптимальный сценарий внедрения технологии будет разным для разных отраслей. Геймеры будут более склонны вложиться в покупку высококачественных шлемов, по сравнению со среднестатистическим потребителем, только решившим, к примеру, попробовать VR «на вкус». Как бы то ни было, одна постоянная величина характерна для всех сегментов: пользователи хотят получить от новинки очевидную практическую пользу.

Поиски приложения, которое превратит VR в технологию первой необходимости, продолжаются

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

Не менее важен и непосредственный опыт использования. Как говорит журналист ZDNet Джеймс Кендрик: «Возможность выбрать гаджет и начать пользоваться им без необходимости напрягаться по поводу того, как он работает не просто отличная. Это нечто такое, чего ожидают все покупатели». Всего лишь спустя 10 лет после того, как смартфон был представлен широкой публике, малые дети уже учатся обращаться с девайсами своих родителей еще до того, как начинают говорить. Именно это поколение, повзрослев, станет пользоваться VR в повседневной жизни.

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

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

В любом случае интересы потребителей должны быть превыше всего при разработке VR-услуг. Без наличия «must have» приложений или убедительных причин использования VR на регулярной основе, люди будут продолжать относиться к технологии как к некой новинке, как это уже не раз происходило с другими подобным изобретениями в прошлом.

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

VR-технологии на рынках розничных продаж

В условиях высокой конкуренции и большого количества игроков на розничном рынке как VR, так и AR могут помочь компаниям создать глубокий и уникальный мир, прочно ассоциирующийся с их брендами. Более половины (55%) участников исследования Worldpay считают VR-шоппинг более увлекательным опытом, нежели онлайн-шоппинг. Покупатели готовы погрузиться в этот опыт глубже. Ритейлерам всего лишь необходимо добавить такой опыт к своим услугам.

Преимущества, предоставляемые AR и VR для покупателей очевидны. Тридцать восемь процентов респондентов считают, что дополненная и виртуальная реальности помогут им сэкономить время, которое они тратят на совершение покупок. Когда речь заходит о способе применений технологий, 63% хотели бы, чтобы VR и AR были интегрированы в шопинговые приложения, а 59% хотят пользоваться VR в магазинах. По мере того как люди и бренды движутся навстречу новых практик омниканального взаимодействия, VR и AR сыграют огромную роль в дальнейшем улучшении уровня интеграции различных каналов взаимодействия покупателей и брендов.

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

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

Предложенные ранее розничные VR-приложения делают куда больший акцент на привлечении внимания к бренду, нежели на покупательский опыт, используя новые технологии как средство тактики. Один из примеров такого подхода — Balenciaga, люксовый бренд, предоставивший своим поклонникам возможность наблюдать за дефиле с помощью VR-показов на youtube. Другой пример — американский гигант ритейла Gap, недавно представивший AR-приложение, позволяющее покупателям еще до заказа оценить, как будет выглядеть виртуальный образец одежды на дому. Тем не менее ни один игрок еще не воплотил на практике стратегический потенциал VR, позволяющий покупателям упростить процесс совершения покупок или воспользоваться их импульсами к покупке.

Следующий логический шаг для AR и VR в ритейле — введение возможности проведения оплаты в виртуальной среде. В настоящее время 61% покупателей считают высокую цену шлемов самым главным препятствием для совершения виртуальных платежей. В то же время 42% более всего обеспокоены вопросом безопасности таких оплат. Однако если падение стоимости виртуальных девайсов — процесс естественный и необратимый, то поиск способов обеспечения ощущения безопасности в виртуальных средах должен стать приоритетом как для брендов, так и для платежных систем.

Вполне закономерным видится повышенный интерес к VR и AR со стороны молодых поколений: 67% респондентов из возрастной группы 25–34 лет выразили желание взаимодействовать с брендами с помощью этих новых технологий. Уровень интереса также сильно варьируется от рынка к рынку. Если в целом в различных странах мира лишь каждый четвертый покупатель признает, что был бы более склонен к принятию сиюминутных решений о покупке, то в Китае этот показатель вырастает до 49%. Уровень распространения на некоторых рынках также заметно мал, однако подобно ситуации с мобильными технологиями, VR-платежи вскоре также станут вполне обычным явлением.

Совершенствуя VR-платежи

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

Проведенное ранее исследование Worldpay на тему онлайн-платежей, посвященной тому, как брендам следует создавать сайта электронной коммерции показало, что более всего клиенты хотят быть уверены в безопасности проводимых ими транзакций. То же справедливо и для совершаемых в AR или VR средах покупок: безопасность и спокойная уверенность превыше всего.

Однако в данный момент уверенность покупателей в комфортности VR невелика. Беспокойства по поводу безопасности AR и VR платежей — второе по размеру препятствие, удерживающее потребителей от совершения покупок с помощью этих технологий, уступающее только высокой стоимости VR-устройств.

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

Задача, которую предстоит решить в ближайшее время — сделать так, чтобы потребители чувствовали себя безопасно, совершая VR-платежи.

Методы могут быть похожими на те, что применяются сегодня при совершении онлайн-покупок, однако механизм ввода данных потребует тщательной настройки. К примеру, как будут покупатели заносить в систему свои платежные данные для завершения транзакции? Очевидно, что они не могут проговаривать их во всеуслышание, поскольку не могут знать наверняка, что рядом никого нет, когда на голову покупателя надет VR-шлем. Еще один вариант — ввод данных с помощью виртуальной клавиатуры, однако этот процесс по-прежнему происходит очень медленно по сравнению с вводом на обычном компьютере или смартфоне.

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

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

https://habrahabr.ru/post/322796/

Интернет уже довольно давно стал некоторым подобием Дикого Запада: каждый отвечает сам за себя, а некоторые вещи из сумеречных областей морали, вроде сбора персональных данных, регулируются только тогда, когда это кому-то выгодно (да-да, мы все знаем, какие законы стоит вспомнить тут).

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



Итак, в один прекрасный день моей знакомой пришло сообщение, предлагающее ознакомиться с линейкой продуктов яхт-клуба. Формулировка «Некоторое время назад, вы были гостем нашего сайта» особенно привлекает внимание. Поэтому пора засучить рукава и окунуться в мир интернет-сталкинга и хотя бы немного разобраться в том, как же всё устроено.

В чём же суть?

Компании вроде Google и Яндекс довольно строго подходят к хранению персональных данных, позволяющие однозначно идентифицировать пользователя в сети (а именно, Google запрещает передачу подобных данных через свои сервисы Google Analytics и Google Tag Manager. Невыполнение этих правил ведёт к предупреждению или блокировке аккаунтов нарушителей), однако это справедливо не для всех. Есть некоторые общепринятые «правила» хранения данных, но подобно пиратскому кодексу — это не строгие законы, а лишь набор рекомендаций. Все мы знаем, что сталкинг — это плохо, но когда за подобные вещи неплохо платят, то у некоторых возникает повод если не сразу заняться этим, то как минимум немного призадуматься.

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



Окей, есть отклонение от стандартного набора из кодов Analytics и Метрики. Есть и подозреваемый!

Следующим логичным шагом будет поискать по исходникам сочетание «vk», которым могли бы обозначить участок кода, отвечающий за идентификацию пользователя на сайте. Сделаем это в файле «pixel/index.php?img=»:



Итак, видим, что указана некоторая ссылка на приложение VK. Будет логично предположить, что с его помощью как раз и происходит опознание профиля посетителя, если, разумеется, он был залогинен. Адрес приложения передаётся в функцию vkPr(link), её код приведён ниже:

    function vkPr(link)
    {
        var vkprimg = (window.Image ? (new Image()) : document.createElement('img'));
        vkprimg.onload = function()
        {
            setCookiePr('XFZDGF1FQEpQVV5cSh1DRw==', link);
        }
        vkprimg.onerror = function()
        {
        	getOther();
        }
        vkprimg.src = 'https://vk.com/login?u=2&to=aW1hZ2VzL2ljb25zL2hlYWRfaWNvbnMucG5n';
    }

Тут видим, что происходит установка пикселя и куки. Пиксель при этом логинится в аккаунт посетителя, а на этом этапе должен происходить деанон пользователя. Далее, исследуем файл из папки callback и найдём в нём обращение к vk_id и установку кук со страшными префиксами «hunter». Набор данных весьма богат: от номера телефона до email и идентификатора VK.

Охота началась:



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



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



В нём указана страница разработчика приложения и было бы интересно перейти на неё тоже.



Тут мы видим пустой аккаунт, который, очевидно, создан как сервисный и заполнен ровно настолько, чтобы не привлекать внимания. Последний вход был совершён в 21:17, что заставляет задуматься об очень долгом рабочем дне в компании, создавшей это приложение.

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



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

{
"exitWeTreasure": {
"head-name": "— #{name}, подождите уходить,",
"head": "— Подождите уходить,",
"text-free": "для вас есть персональное предложение! Давайте мы перезвоним и обсудим цену для вас?",
"text_worktime": "для вас есть персональное предложение! Давайте через 
#{countdown} ((секунду|секунды|секунд)):countdown обсудим цену для вас?",
"text_off": "для вас есть персональное предложение! Уточните, когда вам перезвонить.",
"action_callLater": "Выбрать время звонка",
"action_call": "ОК, созвонимся!",
"action_text": "Написать письмо"
},
"didCallSucceed": {
"head-name": "— #{name},",
"head": "— Скажите,",
"text-name": "скажите, вам удалось начать разговор с менеджером?",
"text": "вам удалось начать разговор с менеджером?",
"action_yes": "Да",
"action_no": "Нет"
}
}

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



На этом часть, посвящённая непосредственно коду заканчивается. Далее, просто поищем в Гугле URL, с которого подгружались js-файлы.

Кто же меня преследует?

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



Тут на оригинальном изображении (пришлось замазать названия этих сервисов, чтобы никому не показалось, что это такой оригинальный способ продвижения) уже видим знакомое сочетание слов с наличием vk, а в заголовке название компании-разработчика охотника за головами трекера.
Дальнейшие поиски привели к тому, что выяснилось, что эта компания существует с 2015-го года и предоставляет услуги множеству клиентов, среди которых есть и весьма известные с хорошей репутацией: от банков, до сотовых операторов. За свою долгую историю интернет-сёрфинга в неанонимном режиме, мне ни разу не писали боты с предложениями ознакомиться с каталогом товаров, так что это выглядит довольно сомнительно, но я могу и ошибаться.

Что же дальше?

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

В «Политике конфиденциальности Вконтакте» в пункте 5.1.4 указано, что:

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

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

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

Действия таких третьих лиц (разработчиков) регулируются официальным документом Администрации Сайта Условиями размещения приложений.

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

2. Работа с данными
2.1. Запрещается собирать и хранить пользовательские данные, включая идентификатор пользователя (User ID), в целях, не связанных с функционированием приложения. Запрашиваемые данные должны использоваться только в контексте приложения.
2.2. У приложений, размещенных на vk.com, должна быть политика конфиденциальности. Если ее нет, используется типовая политика конфиденциальности ВКонтакте.
2.3. Запрещается передавать любые пользовательские данные, автоматизированно полученные через API (включая User ID), сторонним сервисам (например, рекламным) как напрямую, так и через посредников.
2.4. Запрещается использовать пользовательские данные в любых рекламных объявлениях.

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

Вместо завершения

В целом, сбор данных о пользователях сайтов не является чем-то плохим. Даже если не анонимно, то можно просто просить спросить разрешение у пользователя, можно ли его деанонимизировать. Конечно, разумно было бы просто предложить всем путешествовать по сети в анонимном режиме и не испытывать подобных проблем, но это не будет решением проблемы. Анонимные же данные позволяют получить представление о своей аудитории и более эффективно построить свой бизнес и его продвижение. И самое весёлое в этой истории то, что был явный промах мимо своей целевой аудитории, т.к. обычные студенты 20-25 лет навряд ли располагают возможностями для покупки яхты.

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



На этом я закончу свой рассказ о том, как можно найти многих из нас на просторах сети без нашего же ведома. Stay safe, stay strong.

https://habrahabr.ru/post/331222/

Начинаем публиковать материалы с форума «Совместная безопасность облачных решений для бизнеса», который мы провели совместно с «Лабораторией Касперского» и HUAWEI 31 мая в Москве. Одноименная пленарная сессия оказалась центральным событием и мы решили начать с нее. Участники дискуссии представили свои решения по обеспечению безопасности в облаке, а присутствующие потребители услуг оценили их по существу. Что получилось в итоге — читайте, смотрите.

Участники:

Модератор дискуссии: Никита Цаплин, управляющий партнер RUVDS
Владимир Островерхов, эксперт поддержки корпоративных продаж «Лаборатория Касперского»
Михаил Сергеев, директор по корпоративным коммуникациям ГАРС телеком
Данила Чежин, директор по продажам Variti
Сергей Слукин, руководитель отдела DMA и алгоритмической торговли АО «ФИНАМ»
Станислав Погоржельский, продакт менеджер HOSTKEY
Александр Мисюрев, директор по развитию AIG
Александр Миляр, эксперт по информационной безопасности HUAWEI
Франк Харцхайм, CEO, Deltalis
Лидия Шрейдер-Стрюб, руководитель продаж Deltalis

Видеозапись:




Пригласив спикеров, дискуссию открыл модератор, Никита Цаплин, Управляющий партнер RUVDS

Для начала я хотел бы, опять же, провести некоторую параллель с прошлогодним форумом, там в преддверье форума обсуждалось то что американский банк J.P. Morgan заявил о переносе части своих сервисов в публичное облако и мы обсуждали, как раз таки на форуме, на сколько возможны такие сценарии для российского рынка информационных услуг. А вот за несколько месяцев до проведения текущего форума, технический директор J.P. Morgan, господин Дизи провёл рабочий завтрак на котором он уже продемонстрировал результаты переноса нескольких приложений в публичное облако Amazon. То есть мы видим, что тенденции по переносу в облако, они действительно  сбываются. И при том что J.P. Morgan — это финансовое учреждение, это крупнейший банк по активам в мире. А финансовые учреждения они наиболее чувствительны для переносов в облака и даже по самым оптимистичным прогнозам, не более 15% данных финансовых компаний к девятнадцатому году могут быть перенесены в облако. В то время как, например, такие компании как Джонсон и Джонсон заявляют о готовности перенести 85% в течении ближайших двух лет. То, что мы видим — это как бы действительно сильный тренд. Он конечно же происходит… Локомотив всего этого — это конечно западный рынок. Мы как бы видим что там всё хорошо, мы за них рады, но мы хотели бы поговорить больше о ситуации в России непосредственно. О ситуации как осуществляется подобные прогнозы в России, по переносам в облако и насколько предложения вендоров соответствуют ожиданиям потребителей здесь. Я хотел бы что бы мы поговорили не о таких крупных компаниях как J.P. Morgan, здесь, а о тех компаниях которые составляют наш рынок, которые создают спрос — это компании малого и среднего бизнеса, на которые мы, как провайдеры и наши коллеги из других провайдеров которые здесь присутствуют, вендоров, ориентируются. Поэтому я бы хотел что бы мы поговорили именно о данном секторе.
— Поскольку вектор для дискуссии задан, в плане масштаба по компаниям малого и среднего бизнеса, я хотел бы спросить у присутствующих здесь вендоров, в первую очередь оборудования — насколько для вас этот сегмент, малого и среднего бизнеса, для вашей компании значим? Что ваша компания предлагает подобным клиентам и готовы ли вы отвечать на запросы данных компаний, или они ещё довольно малы для того что бы задавать какой-то специфический спрос, как вы считаете?



Александр Миляр, эксперт по информационной безопасности HUAWEI:
— Добрый день, коллеги. Меня зовут Миллер Александр. Я занимаюсь информационной безопасностью компании HUAWEI. И если ответить, то если мы говорим в разрезе тонких клиентов и когда у нас инфраструктура в облаке, включая пользователей, то всё равно, необходимо соблюдение корпоративной политики. В том числе и доступа в интернет. Если у нас, например, межсетевые экраны, прокси-сервера, которые находятся у нас в компании, мы на них настраиваем политики, то что будет в облаке? На самом деле — тоже самое. Наши продукты готовы как для применения в облаке, так и для локальных… Здесь для себя, в предприятиях. Они одни и те же, разница лишь в том, что настаивается либо администраторами здесь, либо в облаке. И мы подключаем все наши те же самые ресурсы, которые используем здесь, то есть — политика доступа в интернет, защита серверов, которые находятся в облаке, при помощи IPS, URL-фильтрации, идентификации приложений, гранулярный доступ к интернету так же и в облаке. С точки зрения малого бизнеса, как мы рассматривали сегодня кейс по… Если малый бизнес готов идти в облако, то для них всё сохраняется, с этой точки зрения. HUAWEI видит, что малый бизнес будет использовать облако немного иначе. То есть будет использовать больше как подписка к управлению локальными девайсами. То есть не устанавливать себе решения локально по управлению множество, допустим коммутаторов или WI-FI сетей, то всё это мы видим что уйдёт в облако. К примеру, к 20-му году, у нас есть понимание что более половины точек доступа которые сейчас будут продаваться, будут управляться из облака. И 35% коммутаторов и маршрутизаторов будут использовать облачное управление. То есть не только наши десктопы уйдут в облако но и локальные сети, которые мы строим, управление всеми политиками, устройствами, конфигурациями, всё так же будет происходить из облака. Если мы говорим про малый бизнес, то малый бизнес в частности хочет, это размеры от, допустим, 10ти человек, которые в компании и до 500. Вот это, грубо говоря, наш малый бизнес. Хотя у нас часто говорят, малый бизнес 500 — это уже средний бизнес, но на самом деле — нет. Это всё-таки относятся к сегменту малого бизнеса. И когда у нас есть филиальная сеть, нам нужно управлять, допустим, настройками, нужно использовать администраторов у себя в штате, которые разбираются — как построить VPN-ы, как соединить наши сети, как построить доступ в интернет. Через облако это реализуется через VM-интерфейс, то есть идёт и упрощение к настройке и использованию ресурсов структуры предприятий.

Никита Цаплин (Модератор): — Спасибо. Теперь я хотел бы задать похожий вопрос представителям хостинг-провайдеров, но прежде давайте не много расскажу про нашу компанию и наших клиентов. Для проекта RUVDS  90% клиентов — это физический лица и лишь 10% юридические лица. Правила 20 на 80, где 20% клиентов делают 80% прибыли, нашей компанией не выполняется. Между тем мы видим сегмент малого и среднего бизнеса очень важным для нас в плане дальнейшего масштабирования и развития технологий. Я хотел бы спросить у Станислава, как у нашего коллеги по цеху — какая ситуация, насколько ваша компания следует запросам малого и среднего бизнеса и на сколько для вас важен этот сегмент, и есть ли какие-то специфические запросы с их стороны?


Станислав Погоржельский, продакт менеджер HOSTKEY:
— Добрый день, меня зовут Станислав. Я представляю компанию HOSTKEY. Что касается малого и среднего бизнеса, вот этих клиентов кто приходит к нам. Для нас это очень интересный сегмент. И мы стараемся привлечь их как можно больше в свою сторону, собственно говоря почему. Наша цель — дать клиенту инфраструктуру. Это как обычно — железо, сервера, так и виртуализация облака. При чём важный момент, облака максимально автоматизированы, то есть клиент приходит на сайт, клиент сам регистрируется, клиент там сам себе двигает ползунки, купил услуги и радуется, сам оплачивает, мы даже фактически с ним не общаемся, только в случае крайней необходимости технической помощи. Отвечаю на ваш вопрос, дословно, что малый и средний сегмент нам очень интересен. Это самостоятельные люди, это компании которые ценят финансовые затраты и им требуются обычно услуги вот сейчас. Вот они зашли на сайт и им нужно услуги прямо сейчас купить. Они готовы оплатить своей карточкой и они это у нас и получают. Очень актуально.

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

Станислав Погоржельский: — Я понял вопрос, да, вопрос отличный, хороший. На самом деле самым первым уровнем оценки хостинг-компании с точки зрения клиента, они смотрят — а где будут размещаться данные. И смотрят, в каком дата-центре размещается хостинг-провайдер. Был замечательный дата-центр презентовал до этого презентацию. Вот есть как бы клиенты которые хотят размещать там свои данные, потому что им так хочется. В нашем же случае они смотрят где мы размещаемся, мы размещаемся в хорошем дата-центре, сертификацией TIER в Москве, это локация в России и есть локация в Нидерландах. Собственно все достойные. В первую очередь клиент спрашивает — в каком центре размещаетесь? Дальше он смотрит — а как мои данные размещаются на ваших серверах? Как мы это обеспечиваем, а мы обеспечиваем следующим образом. Данные клиента они именуются цифирным значением. Системный администратор наш, который управляет облаком, они не имеют привязки конкретно взятого клиента и отдельного вот этого сторожа хранилища пользователя. Они не знают чьи это данные. Наши данные размещаются на многих серверах в нашем дата-центре. В тоже время есть система хранения данных. То есть целенаправленно системный администратор не может залезть в данные клиента и нарушить безопасность, требования. Плюс, мы можем рекомендовать клиентам такую услугу как поставить их персональное сетевое оборудование и сделаем только там вход, линки через это оборудование. Например,  CISCO K9 или ещё какое то шифровальное оборудование.

Никита Цаплин (Модератор): — Я так понимаю речь идёт об индивидуальных решениях, они не предлагаются всем клиентам в качестве какого-то пакета.

Станислав Погоржельский: — Да, абсолютно верно, дополнительный контур сетевой безопасности строится в эксклюзивном варианте, когда есть запрос от клиента. Самый главный вопрос безопасности людей, компаний которые к нам приходят и хотят автоматизированного облака, они спрашивают — где данные будут размещаться? Всё, это всё что их волнует в первую очередь. Эта информация доступна сразу из сайта. Клиент может с нами не общаться и не получать лично от нас информацию.

Никита Цаплин (Модератор): — По поводу расположения дата-центра всё понятно. Это вопрос номер 1 и всё же хотелось бы понять, возможно есть какие-то услуги для безопасности клиентов в облаке, если среди этих услуг защита от DDoS-атаки, антивирусная защита, что-то такое? И на сколько они востребованы? Вот по опыту нашей компании, эти инновационные решения, они медленно распространяются, в целом рынок хочет, но это точечные решения, которые не могут быть массовой тенденцией. Хотелось бы узнать, какие услуги безопасность в облаке вы предлагаете и  насколько они востребованы?

Станислав Погоржельский: — Начнём с первого который вы назвали — защита от DDoS, вообще я считаю что это стандартная услуга которая должна предоставляться хостинг-провайдером. Потому что, когда клиент размещается на серверах компании, любой DDoS может затронуть соседнего клиента, в этом же канале связи. Поэтому защита DDoS как базовая услуга. Если клиент хочет персонально, я не знаю, чистить его канал связи, и он целенаправленно знает, что у него будет DDoS. Когда, естественно эта услуга предоставляется, но это отдельно. В базовом варианте DDoS защита есть и если мы увидим DDoS-атаку, мы говорим клиенту — у тебя проблемы с безопасностью, у тебя идёт атака, давай придумаем что то хорошее и правильное и такой опыт есть. Если говорим об антивирусной защите, запросов больших нету, но я слежу за рынком, люди в принципе хотят, но не понимают до конца эту услугу. У людей есть виртуальная машина, они поставили себе какой-то антивирус, они понимают, они отчёт получили — столько-то вирусов и всё хорошо. А вот по нашему антивирусу они считают, что данные будут сканированы  и это уязвимость безопасности. Это мнение людей с которыми я общался. Поэтому эту услугу мы предоставляем только в кастомном варианте.  

Никита Цаплин (Модератор): —  Защита от DDoS-атаки предлагается всем клиентам как встроенная услуга?

Станислав Погоржельский: — Она есть в любом случае.

Никита Цаплин (Модератор): —  Часто бывают атаки? Есть какая-то закономерность, что пострадавшие фирмы или физические лица больше?

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

Никита Цаплин (Модератор): —  Часто ли приходится сталкиваться с новыми видами атак? У нас изобретательные клиенты, они регулярно придумывают что-то новое.

Станислав Погоржельский: — Интересный вопрос. Но так как мы предоставляем только инфраструктуру, мы только можем видеть верхнеуровневый трафик. А тот трафик что пришёл заказчику, на его сервер, он сам анализирует. Мы даём инфраструктуру, а именно глубокий анализ того что приходит клиенту это всё доп услуги.
 

Никита Цаплин (Модератор): —  Понятно. Спасибо. Мне кажется было бы интересно услышать вендоров по безопасности которые здесь присутствуют. Начнём с вопроса к Даниле, компания VARITY. Кто ваши основные клиенты, приобретающее защиту от DDoS-атак, продукты в этом направлении, планируете ли вы их расширять?
 

Данила Чежин, директор по продажам Variti:
— Добрый день коллеги, меня зовут Данила. Отвечаю за взаимодействие с клиентами и за работу с партнёрами компании. Пару слов о нас. Мы разработали собственную технологию защиты от своевременных угроз.  Мы это делаем не на уровне, как многие привыкли защищаться на уровне каналов и защищать периметр сети или контур информационной безопасности, как здесь прозвучало. Мы защищаем конкретные сервисы и это сервисы которые приносят бизнесу деньги. Вот мои коллеги с компании HUAWEI, компании HOSTKEY, да и многие другие сидящие рядом, они продают свои сервисы путём регистрации своих клиентов, само регистрацией в своих личных кабинетах. Всё это вэб. И мы фокусируемся как раз на защите вэб-сервисов, и в отличии от привычного подхода, когда многие покупают защиту на уровне каналов, мы защищаем помимо инфраструктурного уровня L3-L4, мы защищаем и на прикладном уровне. Мы хорошо разбираемся в http, https, и это даёт ряд технологических преимуществ, мы это делаем немного по-другому. В целом если отвечать на вопрос. Мы компания тоже молодая, нам меньше даже чем компании RUVDS, и мы так же сталкиваемся с тем что клиенты не готовы сразу перейти на облачные сервисы, будь то инфраструктура или сервис очистки, фильтрации DDoS- атак, здесь имеет место такой подход клиента, когда у них не было таких случаев и мы заниматься не будем. Есть подход когда люди понимают, что то что они делают это важно для бизнеса и если это интернет-магазин, то веб это для них основной источник выручки и прибыли и они понимают, что помимо того что бы этот ресурс просто работал, он должен работать хорошо. И он должен давать возможность любому человеку, даже если ресурс под атакой, и даже если устройство человека в этот момент атакует ресурс, защита должна дать возможность этому человеку всё равно зайти и заплатить какие-то деньги за сервис или за товары. Мы это умеем, нам приходится это рассказывать и объяснять и в рамках встреч, конференций и силами наших партнёров, которые продают технологии, мы вас здесь хорошо понимаем, и если я что-то упустил, давайте…

Никита Цаплин (Модератор): —  Появился другой вопрос. Давайте представим, у нас хостинг-провайдер, если у нас, например, есть какой либо сбой, по нашей вине то есть соглашение по которому мы возвращаем средства. Например, происходит DDoS-атака,  которая всё равно, не смотря на подключенную услугу защиты, прервала работу вэб-сервиса, что в таком случае делает вендор?

Данила Чежин: —  Мы как все игроки на этом рынке предлагаем определённый уровень обслуживания и мы готовы нести ответственность в рамках этого SLA и это может быть какой то типовой вариант, у нас есть ряд тарифов, которые зависят от гарантированной доступности нашего сервиса, но мы готовы обсуждать и индивидуально в рамках каких то отдельных проектов, какие-то отдельные условия. Но нам было бы интересно изучить и ваш опыт, когда вы работали с компанией AIG, и вот…

Никита Цаплин (Модератор): —  Я к этому и веду. Какие-то сбои, они происходят у всех вендоров, что бы они там не говорили. Вопрос — как эти ситуации обрабатывать? Понятно что есть SLA, но мало кого устроит что возместят стоимость услуг за месяц, при этом потери пострадавшей стороны могут превышать значительно стоимость этих услуг, по сколько мы видим тенденцию снижения цен на подобные услуги. То данная компенсация, она не устроит клиента. Клиент уйдёт, это сложная и не приятная ситуация. Мы начали думать над тем что придумать в данном направлении и тут как раз мы с нашими партнёрами с AIG,  придумали такое решение, точнее они его придумали задолго до нас, потому что программа CyberEdge существует толи с 2007, толи с 2008 года. Мы с партнёрами с кампании AIG разработали данную программу страхования рисков и я хотел бы что бы Александр поделился некоторым опытом со стороны своей компании по страховке рисков потери данных, прерывании работы сети по причине DDoS-атак, или влияния извне.
 

Александр Мисюрев, директор по развитию AIG:
— День добрый. Меня зовут Александр. Отвечаю за развитие бизнеса в компании AIG, Никита, опытом всегда интересно делится, его очень много, может есть смысл рассказать не много о самом продукте, как он устроен, либо как то конкретизировать?

Никита Цаплин (Модератор): —  Мы вот обсуждали конкретную ситуацию. Вот происходит DDoS-атака, она такой силы что защита по каким то причинам не выдержала. Какие есть предложения у компании AIG, я бы хотел, чтобы вы рассказали зрителям, мы то это знаем. По тому что можно с этим сделать, что можно предложить и как можно получить компенсацию сверх SLA.

Александр Мисюрев: — Теперь задача более понятна. Как сказал Майк Тайсон — «У вас всегда есть хороший план до первого удара в челюсть». Действительно сейчас все провайдеры предоставляют какие-то SLA, предоставляют гарантии, кто-то возмещает стоимость обслуживания за месяц. Но гражданский кодекс и вообще возмещение по законодательству никто не отменял, и плюс ко всему у вас ещё существует такой риск, когда происходит DDoS-атака, это перерыв в производстве. Это если вы представляете интернет-магазин, скажем, либо ваша критическая инфраструктура построена на каких-то it решениях и это всё падает и вы не можете обслуживать клиентов, то вы неминуемо теряете деньги, как бы вы этого не хотели. Что здесь делает AIG. Мы занимаемся в мире этим порядка 15 лет, в Россию в 2013 году этот продукт принесли и он называется CyberEdge, он по факту делится на 3 составляющие. Первая составляющая — это расходы на, она называется сервисная, расходы на специалистов, которые помогают вам посмотреть и минимизировать возможный убыток, потому что Cyber — это в первую очередь защита данных, и всё что с этим связано. То есть когда произошла DDoS-атака, привлекается некие специалисты, это могут быть специалисты из компании Касперский, это могут быть специалисты из компании Group-IB, какие-то другие специалисты, которые помогают отследить, что же произошло, какое количество информации утекло, куда это всё ушло, и как с этим дальше работать что бы в дальнейшем не получить претензию по второй секции. Потому что вы как компании которые обрабатываете данные ваших клиентов, вы за эти данные отвечаете. И не зависимо от того, кому бы вы эти данные не передавали, вы можете отдать в любой клауд или ещё, если я работаю с вами как с компанией, покупаю эту услугу, я приду к вам за требованием и буду от вас просить компенсацию а не от кого то. Здесь очень важно подумать о том какую ответственность вы по-настоящему несёте, не зависимо от того как вы выстроили всю инфраструктуру, и отдали ответственность другим подрядчикам.

Стоит не забывать такой момент, что разработчики разрабатывают очень защищённые инструменты и оборудование каждый раз всё защищеннее и защищеннее, есть ребята которые помогают, дают правильную консультацию, как правильно построить защиту. Но самым уязвимым являются ваши сотрудники и социальный инженерия и хакеры в целом, они всегда на шаг вперёд вас. Мы всегда опаздываем, потому что мы боимся делится данными, мы боимся обмениваться опытом. Кто расскажет как у кого построена безопасность в этой студии, я сомневаюсь что все секреты сейчас расскажете. Использование страховщика позволяет привлечь специалистов, которые помогают преодолеть этот кризис и помогают заплатить суму того требования которое к вам придёт если данные вашего пользователя утекут, то есть данные утекли, скажем из-за DDoS-атаки. К вам приходит какое то количество клиентов, это могут быть физические, юридические лица и предъявляет вам требования. Это требование необходимо по законодательству оплатить. И третья часть это перерыв в производстве. Если ваша компания не работает из-за DDoS-атаки неделю или 3 дня, не важно. Вы терпите убытки, вот эта сумма убытка может быть компенсирована по полюсу CyberEdge, в рамках условий которые предусмотрены по договору. Один из хороших примеров где, казалось бы, ничего не могло произойти. Всё знают авиаперевозчика Дельта. В прошлом году из-за технических сбоев они не могли обслуживать клиентов на протяжении 2 или 3 дней. Хотя казалось что это авиакомпания которая должна лучше всего заботится о своих данных, так же как и Yahoo, больше 1 миллиона учётных записей утекло. Я думаю что там явно не дураки работают в этих компаниях и они выстаивают свою систему безопасности. Но тем не менее у того же Yahoo, например, 4.86 миллиарда долларов сделка, она не сорвалась, она отложилась до выяснения обстоятельств. Они потратили больше 10 миллионов долларов только на то что бы пройти первичную стадию кризиса, понять что произошло, уведомить своих клиентов ну и понести дополнительные расходы.

Никита Цаплин (Модератор): —  Ну а всё же, мы говорим про какие-то такие крупные компании. Среди покупателей полисов CyberEdge, среди ваших клиентов кто преобладает, кто эти покупатели. Мы стали первым провайдером в России кто застраховал свою ответственность, но программа довольно не новая и у неё как бы много различий есть, просто хотелось бы, чтобы вы рассказали кто ваши клиенты по этой программе, всё-таки это предприятие среднего бизнеса или более крупные игроки. Покупают они коробочные решения или какая то кастомизация требуется?

Александр Мисюрев: — Я не отвечу на вопрос, наверное, если скажу что наши клиенты — это  все наши клиенты которые работают с данными. Кто их покупает и кто активно интересуется. Ну конечно финансовые учреждения. Потому что они больше всего данных обрабатывают. Их информация наиболее критична. У нас есть клиенты, которые являются разработчиками софта, и в силу контрактных обязательств они этот полис покупают. У нас есть клиенты, которые являются интернет магазинами. Это небольшие интернет магазины, скажу сразу- это компании с оборотом в 100 миллионов рублей условно, это копейки по сравнению с онлайн бизнесом. Так как AIG глобальный страховщик, у нас есть глобальные клиенты, которые в Россию начинают адаптировать свои международные программы.

Скажем сеть гипермаркетов международная, европейская они имеют этот полис в России в том числе. Вот когда была атака WannaCry, они обратились к нам, у них перестали работать платёжные терминалы, например. То есть это один из кейсов. Есть так же обычные ритейлеры, которые уже по полису Cyber заявляли такие убытки как например шантаж. То есть к ним приходит письмо по факсу, что если вы не заплатите мне деньги, я сделаю вашу жизнь адом, я скомпрометирую вашу отчётность, я проведу вам проверку, и всё будет у вас ужас. Это как раз покрытие, виртуальное вымогательство, оно покрывается по Cyber’у. Поэтому решения разные, у нас есть коробочные решения, которые мы разработали для малого и среднего бизнеса с лимитом до 3 миллионов долларов, извините, мы привыкли всё считать в долларах, поэтому 3 миллиона долларов. И в принципе это решение начинается от 500 долларов за полис годовой, если это небольшая компания. Ну а дальше увеличивается, полис для банка будет стоить уже сотни тысяч долларов.

Никита Цаплин (Модератор): —  Спасибо. Я думаю все зрители ознакомились с программой CyberEdge. В конце после пленарной сессии вы сможете задать вопросы. Сейчас я хотел бы задать вопрос Владимиру Островерху из «Лаборатории Касперского». Я  хотел спросить, какие продукты вы предлагаете помимо антивирусной защиты, начнём с других продуктов. И какие продукты вы предлагаете вашим клиентам, предприятиям малого и среднего бизнеса в области обеспечения безопасности? И в чём их преимущество перед другими вендорами данных решений.


Владимир Островерхов, эксперт поддержки корпоративных продаж «Лаборатория Касперского»:
— Всем добрый день. Меня зовут Владимир Островерхов, «Лаборатория Касперского». По поводу списка продуктов. У нас сейчас их порядка 40 видов. Все перечислим или…

Никита Цаплин (Модератор): —  Я Думаю начнём с самых востребованных. Хотел бы узнать что востребовано у предприятий малого и среднего бизнеса? Что они покупают?

Владимир Островерхов: —  У малого и среднего бизнеса виртуальные технологии, они выходят в облака, соответственно здесь есть резервная защита для конкретной индустриализации для конкретных технологий. Малый и средний бизнес потихоньку перетекает в хранение информации на специализированное хранение данных. Есть специализированная система хранения данных. Есть огромное количество сервисов, которые предлагаем. По расследованию инцидентов, по выявлению инцидентов, сервисы по рекомендации безопасности, огромное количество продуктов. Та же самая DDoS защита, тоже предлагается с нашей стороны.

Никита Цаплин (Модератор): —  А если говорить о защите систем виртуализации, кто в данном сегменте основные потребители? Всё равно есть какие-то тенденции, либо это крупные компании которые владеют своими цодами, либо это провайдеры, либо это могут быть не большие предприятия которые не могут позволить себе свой цод, но хотят обезопасить свой сервер находящейся в каком-то дата центре, либо виртуальный сервер, кто ваш клиент?

Владимир Островерхов: —  На данный момент по тенденции именно, наиболее популярный и используемые решение для защиты и виртуализации приходится на компании которые осознали себя в этой индустрии, осознали себя в рынке виртуализации, поняли что они активно пользуются облаками, поняли что они активно мигрируют туда, поняли что сервис-провайдеры это крупные компании со своими центрами обработки данных. Для рынка СМБ не могу сказать что это инновация, года три назад сказал бы, что только появилось. Сейчас это переходит на формат обязательного тренда, потому что все переезжают, все строят себе виртуальный цод, Все начинают потихоньку пользоваться виртуальными машинами и все начинают понимать что традиционные антивирусы, поставленные внутрь виртуальной машины, часто выступает дополнительным условием угрозы и дополнительным уровнем угрозы.

Никита Цаплин (Модератор): —  Вот расскажите в чём именно угроза, если например я арендовал виртуальный сервер и поставил на него обычный десктопный антивирус?

Владимир Островерхов: —  У меня впереди будет презентация на эту тему как раз.

Никита Цаплин (Модератор): —  Тогда давай без спойлеров.

Владимир Островерхов: —  Без спойлеров, если очень коротко — это огромное количество потребления данных и не правильный их анализ в том плане что требуется рассчитывать их, требуется защищается внутри каждой из виртуальных машин, без общения нескольких антивирусов между собой, без предоставления информации другому антивирусу. Соответственно каждая виртуальная машина защищает сама себя. Это очень сильно просаживает ресурсы. У нас есть пара кейсов, в телеком провайдерах крупных, в телеком провайдерах Европы, порядка 60-70 тысяч виртуальных машин одновременно которые пришли к нам после того как у них был негативный опыт использования традиционного антивируса. Не буду говорить о конкурентах, называть бренды, но без наличия вирусной атаки у них упала половина инфраструктуры, просто спасибо антивирусу. Надо понимать тенденцию о том что, вопрос есть ресурсы или нет их, уходит на второй план. Сейчас о том на сколько просадка может повлиять на способности инфраструктуры целиком без вирусов, без атаки. Ну и о наболевшем- это WannaCry.

Никита Цаплин (Модератор): —   Если говорить о защите виртуализации, каких основных конкурентов вы видите на этом рынке?

Владимир Островерхов: —  Основные конкуренты защиты виртуализации, наверное хакеры.

Никита Цаплин (Модератор): — Я о компаниях, хакеры всегда с другой стороны конкуренты.

Владимир Островерхов: — Они с обеих сторон. Сейчас очень активно в мире представляется hack-as-a-service. Сейчас любая компания которая заинтересована во взломе соседней компании может обратиться в некоторые компании, которые предоставляют взлом, DDoS, разрушение баз данных, компрометации за определённую сумму.

Никита Цаплин (Модератор): — Интересная бизнес модель. Это как software-as-a-service, только специфический software. Какой порядок цен на подобные услуги?

Владимир Островерхов: — Да смешной. Берём DDoS, о которых говорили, минимальный DDoS компании стоит 200 долларов.

Никита Цаплин (Модератор): — 200 долларов, понимаете, за 200 долларов сервис может остановится как я понимаю

Владимир Островерхов: — Задедосить Пентагон можно тысячи за 4 долларов.

Никита Цаплин (Модератор): — Сбор средств на DDoS Пентагона начнётся чуть позже.

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

Никита Цаплин (Модератор): — Почему так дёшево получается? Надо обладать определённой инфраструктурой для этого.

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

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

Владимир Островерхов: — Да но здесь есть бдительность и мнительность сотрудников, её надо развивать и повышать, потому что сколько кейсов было что левая страничка фэйсбука приходит на почту со словами от какого то знакомого, который даже не знает об этой почте, все открывают, смотрит, стандартный, легальный фэйсбук, прошедший все фаерволы, запретов нету, но в ней какая то ссылка есть. Фейсбук разрешён, значит ссылка разрешена, давайте посмотрим. И начинается эпидемия. Тот же WannaCry так же зашёл.

Никита Цаплин (Модератор): — Интересно узнать на счёт защиты виртуализации, есть ли какие-то конкуренты у «Лаборатории Касперского», либо это какое-то уникальное решение?

Владимир Островерхов: — Конкуренты всегда есть. Но все мы думаем по-разному, подходим к защите с разных сторон. У нас есть на наши технологии свои патенты, у конкурентов свои патенты. Из основных вендоров, это из самых крупных, но на российском рынке кроме нас не представлены, это Trend Micro, Symantec, которые действительно интересны нам, с которыми интересно сталкиваться и соревноваться в развитии технологий, решений.
 
Никита Цаплин (Модератор): — Возможно есть какие-либо преимущества ваших решений перед конкурентами?

Владимир Островерхов: — А о них уже на презентации.

Никита Цаплин (Модератор): — Ладно не будем забегать вперёд, если суммировать то что мы услышали от Владимира, то что невозможно защитить от человеческого инжиниринга. Но здесь на помощь может прийти AIG, и компенсировать эти риски.

Владимир Островерхов: — Надеюсь.

Никита Цаплин (Модератор): — Теперь хотелось бы спросить другого вендора безопасности, по факту это провайдер цод, Франк Хаймхарф, он выступил с докладом, это провайдер цод но в какой-то степени этот дата-центр таков, что по факту это провайдер безопасности. И я хотел бы спросить у Франка, кто ваши клиенты, традиционный вопрос, кто больше всего обеспокоен безопасностью данных, это какие-то международные холдинговые компании, или это не большие, локальные игроки, что вы предлагаете им, что не могут предложить конкуренты?


Франк Харцхайм, CEO, Deltalis (перевод с английского): — Наши клиенты это как международные компании, так и швейцарские клиенты конечно. Любая ИТ-инфраструктура требует хранения данных, места, где эти данные будут храниться физически. Не существует ничего виртуального в природе. Существуют физические сервера и они должны где-то размещаться. Мы, простыми словами, предлагаем лучшее место для их размещения, наиболее защищенное, которое вы можете себе представить, в лучшей стране для этого. Многие люди и компании начинают беспокоиться насчет безопасности размещения своих ИТ-платформ и данных, и это как раз является предметом нашей компетенции.

Любой международный клиент нуждается надежной защите своих данных, и такими являются наши клиенты, если вы посмотрите на список наших клиентов- там будут компании из Среднего Востока, США, Южной Америки, Европы, конечно Швейцарии- таким образом довольно широкий круг. Услуги, которые мы предлагаем- это очень гибкие услуги по предоставлению инфраструктуры. Мы не соприкасаемся с данными наших клиентов, например, сервера RUVDS, размещенные у нас в дата-центре- только сотрудники RUVDS имеют доступ к гермозоне, где они расположены. Мы заботимся о физической безопасности, электричестве, охлаждении- все, чтобы вы не заботились о внешних факторах- это наша работа.

Никита Цаплин (Модератор): — По поводу доступности дата-центров действительно не стоит сомневаться, я там был, действительно, это выдолбленный в горе бункер, предназначенный для вооружённых сил Швейцарии, был на боевом дежурстве, теперь она находится в распоряжении клиентов Deltalis обеспечен по всем стандартам Тier 4, пожалуй, действительно самый центр который я видел. Но тем не менее, интересен вопрос юридической стороны. Случалось ли такое, что по каким-то из ваших клиентов интересуются государственные службы других стран, как в таком случае происходит обработка запросов? На сколько мне известно расположение Швейцарии, оно обеспечивает некоторую юридическую защиту, хотелось бы узнать подробнее об этом.

Франк Харцхайм, CEO, Deltalis (перевод с английского): — В Швейцарии у нас страна с очень строгими законами и правилами по защите данных. Государственные структуры не имеют права доступа к какой-либо информации, находящейся на серверах в этой стране, до вступления соответствующего законного решения местных властей. Если вы являетесь подозреваемым и существует решение суда по запросу информации — тогда данные будут запрошены, но данный запрос должен быть отправлен самому клиенту, не нам. В данном случае дата-центр никак не является посредником в этом вопросе и не в праве предоставлять данные клиента, не вступает в сотрудничество с правоохранительными органами. У нас в Швейцарии очень строгие законы по защиет конфиденциальной информации и данных, поэтому нет такой процедуры, чтобы правительственные структуры запрашивали данные у дата-центров или провайдеров без ведома клиента.

Никита Цаплин (Модератор): —  Я так понимаю что для того, чтобы был предоставлен доступ к данным кроме клиента к серверу, то Швейцарское правительство должно признать клиента в какой то мере виновным по Швейцарскому законодательству, правильно? Если, например, приходит запрос. Представим ситуацию, находится у вас клиент, гражданин РФ или Великобритании, а ещё лучше США, он располагает там своё оборудование и размещает какие-то сервисы, которые в стране его гражданства признаются незаконными. Я так понимаю, что бы вы предоставили доступ к оборудованию, Швейцария должна признать факт виновности данного человека или как?

Франк Харцхайм, CEO, Deltalis (перевод с английского): — Правильно.

Никита Цаплин (Модератор): — Расскажите подробнее, какая процедура, чтобы вы предоставили доступ к дата-центру, я  видел, я был в этом дата-центре, туда так просто нельзя попасть. Но понятно, что если будет ордер локальных властей… Хотелось бы понять как это может произойти.

Франк Харцхайм, CEO, Deltalis (перевод с английского): — У нас очень защищенный дата-центр. Очень безопасное место. Никто не будет хранить свои данные в небезопасном месте разумеется. И многие провайдеры и дата-центры это предлагают, но мы предоставляем нечто большее. У нас модульная система защита, многопараметрическая, точки входа, права доступа, несколько периметров безопасности, фиксация всех действий гостей и персонала, идентификация по  венам рук- более надежная чем отпечатки пальцев, строгие регламенты безопасности, сертифицированные ISO, все системы аудируются ежегодно. Это не так, что сделано один раз и все- мы проходим сертификацию ежегодно и у нас есть доказательства этого, что все соответствует стандартам, что все процессы проходят правильно, все сотрудники проходят обучены и сертифицированы- сотрудники это очень важная часть.

Никита Цаплин (Модератор): — Здесь понятно, я всё таки хотел узнать, я попробую задать вопрос на английском, прошу прощения за мой английский.

Никита Цаплин (перевод с английского): — В каких случаях дата-центр должен предоставить доступ локальным правоохранительным органам или международным доступ к серверам клиента?

Франк Харцхайм, CEO, Deltalis (перевод с английского): — Это возможно только в случае если будет доступ к этим серверам и наличие решения местных властей, только при решении соответствующих органов власти. Никакие другие запросы, от каких-либо правоохранительных органов других стран, включая США, не признаются. У нас Швейцарская компания и мы не имеем каких-либо обязательств по выполнению распоряжений каких-либо властей, включая международных, за исключением швейцарского правительства.

Никита Цаплин (Модератор): — Я думаю это было как раз интересно, когда  человек размещает данные в такой стране как Швейцария. Спасибо большое, я теперь хотел бы перевести вопросы с вендоров на потребителей. Сегодня у нас здесь нет непосредственно потребителей услуг среди спикеров. Но есть представители потребителей, здесь среди нас. Присутствует Сергей из компании ФИНАМ, которая активно предлагает своим клиентам облачные услуги на основе VPS-серверов, среди нас есть и представитель компании HOSTKEY, также представитель ГАРС телеком- Михаил, которые в своём перечне своих услуг имеют услуги VPS/VDS. Вот я хотел бы задать вопрос им. Насколько те решения, которые мы сейчас обсуждали, нужны клиентам. Начнём с Михаила.


Михаил Сергеев, директор по корпоративным коммуникациям ГАРС телеком:
— Здравствуйте, Михаил Сергеев – ГАРС телеком. ГАРС телеком с 99 года оказывает услуги  корпоративным клиентам и наши сети объединяет все точки обмена данными плюс более 30 дата центров только в столице, поэтому понятно, что облако не облако, без канективити, поэтому рано или поздно вы все приходите к нам. Я хотел обратить снимание на первый вопрос, который задавали нашему коллеге из Швейцарии, этот вопрос же, давайте честно, про маски шоу. Я хотел внести новую струю, понимаете какая история, в России по-своему относятся к понятию безопасности, маски шоу остаётся чуть ли не приоритетным у собственников и первых лиц бизнеса, когда речь идёт о безопасности. Мы за 20 лет обслуживания клиентов, предоставления конективити, про это знаем многое, например, курьёзный случай, но это живой кейс и этот кейс не один. Наш клиент, крупная инвестиционная компания в топ-10 заказала следующий сервис, они очень беспокоились что придут и будут обыскивать и тд. И хотя, казалось бы, кейсу меньше 10 лет, то есть было уже куда отправить данные, можно было арендовать что то за границей, но нет — своя рубашка ближе к телу. У нас на территории одного из наших офисов был организован полноценный дата центр на одну стойку. Задублирована электроэнергия, охлаждение, всё серьёзно. В стойке был один сервер. Перед дата-центром стоял стул, стол, на столе телефон. Это было рабочее место сотрудника. Это был когда-то кадровый офицер ФСБ, явно с высшим образованием с хорошими физическими данными. Его работа была в том, что он приходил и сидел за столом. Телефон никогда не звонил, работа заключалась в том, что если телефон зазвонит, он быстро должен вскочить, вынуть сервер и очень быстро убежать. Это смешно, но это очень у многих в нашей стране про безопасность так. Этот несчастный человек, было видно, что человек с высшим образованием, делать было нечего, читать газеты было нельзя, он брал бумагу и вспоминал что-то, какие-то формулы, было видно, что в голове что-то есть. У нас лет пять где-то он просидел.

Никита Цаплин (Модератор): — Эту услугу вы предоставили клиенту получается?  

Михаил Сергеев: —  Клиент сказал — мне нужна безопасность, вы сможете мне обеспечить безопасность моего сервера. Мы говорим — а как вы хотите? А вот мы так хотим. У нас Швейцария вроде близко,  но, как мы знаем, у нас в Москве есть 2 точки: в районе Киевской есть дата-центр, который выдерживает прямое попадание атомной бомбы, и дата-центр в при Курчатовском институте, который для нашего менталитета может поспорить с этими возможностями доступа, потому что в Курчатовский институт маски шоу прийти может, но нужно за неделю подать заявления вот- заказать пропуск. Поэтому те, кто говорят, в Швейцарии не надёжно, они спокойно в Курчатовке ставят и им кажется, что хорошо. Я хочу завершить свой спич тем что безопасность- она в голове. Если у нас жёлтые тараканы, то у нас такая безопасность, если она зелёные, то чуть иная, и мне кажется, что так будет всегда. Поэтому хочешь- не хочешь, менталитет никуда не денется.

Никита Цаплин (Модератор): —  Согласен. Как в фильме, что предоставили швейцарские коллеги прозвучала фраза «Its all about the trust», вопрос безопасности- это вопрос того, доверяете вы или не доверяете компании. Но хотелось бы подробнее узнать насколько, кроме вопросов физического доступа к оборудованию, какие вопросы безопасности: DDoS- атаки или какие-то вирусные атаки беспокоят клиентов. Вопросы частые или это редкость? Бывает, что клиент приходит и говорит — я хочу облако. Вы – хорошо, вот. Он говорит — я боюсь, тогда не пойду.  

Михаил Сергеев: —  Я не просто так про маски шоу сказал, в принципе получить качественный сервис – вообще не проблема. Я считаю, что уровень инфраструктуры, который обеспечиваете и сервис сегодня, который предлагаете вы, да ещё и начав работать вместе во Швейцарцами и Касперким- это планка, которой вполне достаточно. Я не помню, чтобы кто-то говорил — ой, знаете нам такого мало. Всё достаточно хорошо, более того, к счастью рынок облачного дошёл до такого уровня технологического развития, что конкуренции как таковой нет, все используют существующее решения. И у нас на практике не было случаев, когда клиент говорил, знаете, меня тут задедосили, мне недостаточен тот уровень инфраструктуры, который  вы предоставляете. Как то всё идет спокойно, но может надо перекрестится.

Никита Цаплин (Модератор): —  Спасибо за комментарий. Также я хотел спросить у Сергея. Сергей- представитель компании ФИНАМ, помимо прочих брокерских услуг она предоставляет клиентам также услуги  VPS-серверов для торговли, то есть именно там, на стыке тех технологий, где любая секунда простоя может принести прямой финансовый убыток. Вот я хотел спросить, на сколько ваши клиенты чувствительны к вопросам безопасности? Или когда мы говорим о финансовых компаниях, тут важна надёжность, в плане сбоев по техническим причинам. Всё-таки вопросы безопасности более актуальны?


Сергей Слукин, руководитель отдела DMA и алгоритмической торговли, АО «ФИНАМ»:
— Добрый день, меня зовут Сергей. Я руковожу отделом торговли в ФИНАМ — это самый большой брокер в России по количеству клиентов. У нас есть представительство в каждом крупном городе России. Несколько десятков тысяч клиентов России и за рубежом. Наш отдела помогает клиентам строить собственную структуру, для того что бы их алгоритмы работали успешно, что бы они зарабатывали деньги. В том числе мы предоставляем клиентам железные решения, то есть предоставляем клиентам свои сервера, покупаем сервера, если им это нужно, представляем облака в партнерстве с компанией RUVDS. Как с точки зрения подключения в интернет в московской бирже, так и в периметре московской зоны локации биржи Dataspace. По поводу безопасности, на самом деле если говорить о периметре интернета, то  и о клиентах, которые пользуются виртуальными машинами, то те услуги безопасности что сейчас предоставляются, их достаточно. Если говорить о периметре локации то это не много другой круг клиентов и их требования выше. Но мы не ограничиваемся только тем что нам даёт провайдер. Мы используем симбиоз облачных и наших собственных биржевых решений, стоят наши фаерволы и фаерволы биржи. Разрешаем доступ с определённых статических ip. Мы мониторим трафик, биржа тоже мониторит трафик на своём периметре, мы относимся серьёзно к безопасности, это в первую очередь волнует клиентов. Но если говорить о том, что важнее безопасность или устойчивость, это на одном уровне.

Никита Цаплин (Модератор): —  Это синонимы, согласен. А случалось ли, когда клиенты подвергались взлому, атаке, в таком плане?  Или это не про вашу категорию клиентов.

Сергей Слукин: — Это не про этих клиентов. Мы видим? что иногда прилетают пакеты из Китая, видим что пытается проводить DDoS’ы и пытается положить каналы, серваки. Естественно ничего не получается потому что опять же из-за симбиоза систем защиты. Если бы у нас всё было в облаке, тогда, наверное,  у этих клиентов были бы проблемы. В этом плане, мы пока не готовы переносить всю инфраструктуру в облако, здесь еще долгое время будет работать симбиоз решений.

Никита Цаплин (Модератор): —  Как я и говорил что финансовый сектор- самый тяжёлый для переноса, потому что там взаимодействие напрямую с финансовыми потоками. Хотелось бы услышать ваше мнение о  AIG, насколько интересно вашим клиентам страхование на случай, если клиент фонд — который управляет средствами, подвергнется DDoS-атаке, например, и будет невозможно осуществлять сделки.  Кто-то получит не санкционированный доступ к серверу, который управляет транзакциями- в результате чего могут быть получены колоссальные убытки.

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

Никита Цаплин (Модератор): —  Мы говорим не о недополученной прибыли.

Сергей Слукин: — Явно речь идёт не о недополученной прибыли. Если клиент говорит — у меня упал сервак, у меня висит заявка я не смог её вовремя снять у меня убыток миллион рублей, это сложно доказать и тд. Если речь о краже какого-то алгоритма то тоже сложно, потому что невозможно оценить в судебном порядке стоимость алгоритма клиента. С точки зрения базовых функций, если доказано. что с сервера клиента что-то украдено, что-то слито или, что его сервер подвергся атаке, и он не смог торговать, то если страховая компания может возместить больше, чем нам предлагает SLA, то это будет интересно.

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

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

Никита Цаплин (Модератор): —  А что думаете о инструктуре Швейцарии? Швейцария является столицей банковского дела. Это близкий вопрос к финансовым рынкам,  понимаю, что территориально это не лучшее расположение с точки зрения скорости доступа к финансовым рынкам, но насколько вы видите интересным предложение по размещению клиентских сервисов вот в таком безопасном месте, где невозможно событие запроса локальных властей. Насколько интересна юридическая безопасность клиентам? Я знаю, что большинство фондов, которые оперируют в том числе и на московской бирже, они не принадлежат российской юрисдикции, и тем не менее, размещая оборудование в нашей стране, они несут риск локальных властей. Насколько этот вопрос интересен клиенту?

Сергей Слукин: — Зависит от типа клиента, если клиент готов, иностранный фонд готов иметь инфраструктуру в России, 90-99% будет размещаться в биржевой локации, в России. Швейцария- это хорошо, но с точки зрения торговли это не совсем хорошо применимо именно к клиенту, которому важна скорость доступа. С той же Швейцарии сигнал будет идти несколько десятков миллисекунд. А клиенты уже соревнуются по наносекундам. Если клиент может сэкономить 200 наносекунд, то это уже большой плюс. Если речь о хранении данных бэкофиса, какую-то маркет дату, то да это может быть интересно, но если сервисы, которые принимают решения, обрабатывают маркет дату, то они должны находиться там, где  торговая площадка. Но я не вижу ничего такого в разделении сервисов клиента. Когда сервис здесь, а бэк и база данных в другом месте.

Никита Цаплин (Модератор): —  Спасибо. Сейчас я хотел бы опять вернутся с вопросом к Александру из AIG. Есть ли у вас опыт взаимодействия с компаниями из ИТ-сектора по вопросам страхования. Есть какие-то проекты или кейсы? Я понимаю, что эта область она конфиденциальная и, как и в случае с Deltalis, они не могут показывать своих клиентов, потому что, во многом, клиенты туда идут именно за конфиденциальностью. Но тем не менее, может есть интересные кейсы взаимодействия с ИТ-компаниями, о которых можно было здесь рассказать? Как провайдер, мы первые, кто застраховался от этих рисков, но возможно есть какие-то другие проекты, тех же компаний-вендоров по безопасности? Мне кажется страхование это единственный выход. Вопрос доверия — понятно.  Вопрос физической безопасности, надёжности, всё это так или иначе решается,  защита DDoS. Но всё равно может случится какой-то сбой, и в любом случае и от него можно защитится только страховкой и никак больше, по этому такой вопрос к вам.


Александр Мисюрев, директор по развитию AIG:
Про клиентов рассказывать не буду, потому что всё-таки это конфиденциальная информация. Так как я занимаюсь адаптацией тех или иных продуктов, в России, самое сложное — кто ваши клиенты, кто покупает? И все привыкли что как правило все российские страховщики показывают в своих презентациях миллион логотипов, вот все они купили. У нас другой подход, у нас, мы изначально работаем с корпоративными клиентами, крупными, сейчас развиваем малый и средний бизнес. Если говорить о том, где Cyber есть как встроенный продукт, который позволяет защищаться клиентам, и в этом видим большую перспективу с точки зрения развития, когда существует не только финансовое решение как страхование, финансовая защита страхование, но и ещё некая сигнализация на ваше оборудование. Вот с нашим партнёром, Group-IB, мы сделали продукт, который называется Group-IB TDS и CyberEdge, этот продукт как раз о том что Cyber даёт свой сенсор клиенту, а дальше если сенсор не справляется со своей задачей, работают определённые части нашего полиса. Из интересных ИТ- решений, могу сказать,  что порядка трех провайдеров, которые предоставляют защиту от DDoS-атак- мы ведем с ними переговоры в этой части. Изначально идея появилась из этого, когда DDoS все же проходит и компания несёт убытки, тогда должна работать страховка, понятно что мы стремимся предоставить 99.9% защиты, поскольку под 100% защиты я сомневаюсь, что кто-либо подпишется, это нереально. Но вот после того как вышел наш пресс-релиз с RUVDS, Никита, к нам ещё один клауд-сервис обратился- раз это можно страховать, давайте работать.

Никита Цаплин (Модератор): —  Вопрос в том что многие не знают, что такое можно страховать. У нас есть представитель компании по защите от DDoS. Насколько вы считаете, что дострахование услуг защиты целесообразно предлагать клиентам? Или вы придерживаетесь парадигмы, что мы обеспечиваем 100% защита и не можем допустить мыли о том, что может что-то произойти? Есть такая точка зрения, действительно, что не хотят предлагать страховку, потому что это ломает парадигму, вносит сомнение, что может что-то сломаться.


Данила Чежин, директор по продажам Variti:
— Всё что создаётся человеком, человек несовершенен и, к сожалению, кто-то рано или поздно какие-то ошибки допускает, это видно из утечек постоянных каких то. Какие-то дырки в самом разнообразном ПО находятся. И они находятся спустя достаточно длительное время. Уязвимости в SSL, например, которые несли достаточно серьёзную угрозу. И всё это говорит о том, что какое количество девяток после запятой вы у себя в вебсайте не написали, что бы вы не написали в контракте- всё равно, конечно же, вероятность того что что-то случится она есть. Вопрос в том какое количество ресурсов злоумышленник должен потратить на достижение цели.

Никита Цаплин (Модератор): —  Владимир заверил, что суммы доступные.

Данила Чежин: —  Мы такие атаки видим, они выглядят в форме прямоугольника, на графиках- это эффект каналов полки. У атаки есть четкие параметры, как правило, атаки выскакивают высокочастотные, это какой-то флуд, и такие дешёвые атаки они как правило заказываются, я предполагаю, не знаю сам не заказывал, но если раз сработало, почему бы ещё раз не повторить если недорого. Есть другой подход, когда заказывают атаки не просто с какими-то параметрами по объёму и длительности, а есть заказ на результат. Не думаю что 200 долларов для каких-то хороших ресурсов, это совсем другие деньги. И здесь злоумышленник, он совсем в творчестве никак не ограничен, он думает, это мы видим в том числе по графикам, пробует разные методы уходит покурить, возвращается, пробует что-то еще, опять не получатся и тд. Там тоже живые люди и поскольку у них задача выполнить заказ, они прикладывают максимальные усилия. Если я скажу, что мы от всего всегда будем защищать, что бы ни случилось, мне кажется, это будет некоторым допущением и не очень честным по отношению к клиенту, поэтому то, что предлагает AIG, это интересно. Здесь всегда вопрос баланса, потому что есть страховая премия, она понятна, и есть стоимость страховки для конечного клиента. И если мы говорим о каком то не очень большом бизнесе, новом, на фоне Morgan Stanley многие будут небольшими. Для бизнеса в тех реалиях, в которых мы живем, в той стране в которой мы живём, для него любые дополнительные затраты, они тяжёлые. У населения уже достаточно длительное время падает покупательская способность. У бизнеса та же ситуация. У них нет заказов, становится меньше, они получают меньше прибыли, и естественно тот бюджет расходов который имеют, они стараются как то оптимизировать. И покупая страховку у AIG, очевидно мы будем перекладывать как-то на клиента, закладывать в стоимость, если будет существенное увеличение услуг, это просто не будет востребованным у такого небольшого бизнеса. Для корпораций это будет востребованным, это то, что они хотят видеть. Действительно они говорят, что компенсация SLA за месяц-два, это всё не для нас.


Александр Мисюрев, директор по развитию AIG:
 
— Верно, на самом деле как бы это не парадоксально не звучало, мы не стремимся продать наши решения, мы стремимся помочь нашим клиентам и здесь нужно найти золотую середину на самом деле. Все попались на КАСКО на таких вещах, когда нам предлагали — ребята, давайте страховаться без франшизы, а когда случился скачок валюты, определенное количество убытков- все резко начали  страховать с франшизой что бы удержать премию, потому что стоимость страховки, она колоссальна. Вот тот месседж, который я хочу донести до клиента, когда мы общаемся: что страхование должно помогать в сложной ситуации, с лёгкими чихами, с простудой, вы сами можете справится, страховка должна помогать бизнесу там где есть угроза, когда происходят такие вещи как WannaCry, когда всё падает, здесь и должна помогать страховка. Но и плюс ещё добавлю, вот мы с Владимиром из Лаборатории Касперского по поводу промышленной безопасности общались: есть уже определенное количество решения и библиотека знаний, как закрыть уязвимости. И стоит не забывать, что котиков лайкают все, и приходят такие сообщения, сколько бы не выстраивали техническую безопасность. Вам не стоит забывать работать с вашими сотрудниками, проводить тесты, рассылать сообщения,  в которых будет ссылочки, что угодно, что будет не так опасно для организации, но будет выявлять те слабые звенья, которые в дальнейшем смогут принести определенных проблем.


Данила Чежин, директор по продажам Variti:
— Мы тут говорим с одной стороны о DDoS, потом об утечках информации- это все-таки немного разные истории. Я просто что хотел уточнить: насколько я понимаю, бизнес любой страховой компании он построен на эффективной оценке рисков, рисков наступления страхового события, и если говорить о DDoS, то на мой взгляд стоимость полиса должна зависеть от оттого есть там защита или нет. Бизнес, наверное, может застраховаться и не имея подобной защиты, может прийти к вам и сказать, я хочу застраховаться от потери данных, от недоступности. И вы как эксперты должны посмотреть, что у клиента с защищенностью, провести аудит. Или просто посмотрев на договор с вендором защиты и увидя какое-то название знакомое сказать и какой-то уровень SLA, сказать «окей, тебе это будет стоить на 40% дешевле, потому что у тебя хорошее решение по защите». Есть ли у вас подобные подходы, как вы обычно действуете здесь?

Александр Мисюрев: — Конечно, как и при продаже любого полиса, всегда есть процедура андеррайтинга, то есть некое коробочное решение, которое базируется на допущении и коробка, как любой финансовый продукт, она дороже стоит, потому что базируется на допущении. Конечно, мы просим заполнить вопросник, если  это крупный клиент или финансовые учреждения, то мы проводим предстраховой сюрвей, привлекаем специалистов, которые смотрят, как всё это устроено. Это всё присутствует. И возвращаюсь к нашему решению с Group-IB, мы, прежде чем запустить какие-либо решения, мы понимаем тот эффект, который даёт их решение, и за счёт этого можем предоставить более выгодные условия, которые включены в этот совместный продукт. Поэтому андеррайтинг очень важен для страховщика, но куда важнее то, как клиент будете работать и действовать, если нас не будет. Если вы будете действовать разумно и целесообразно, то для вас премия будет явно дешевле, если у вас никаких степеней защиты нет, а вы хотите купить полис, мы его вам просто не продадим.

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


Шевченко Андрей, HOSTKEY:
— Добрый день, Шевченко Андрей компания HOSTKEY. Хотел бы немножко шаг в сторону сделать, если можно. Если мы говорим про облачные решения и можно ли там вообще обеспечить какую-ту безопасность, я бы, наверное, сказал, а можно ли вообще обеспечить эту безопасность на своей инфраструктуре? Приведу банальный пример. 152 ФЗ. Все его знают, все его понимают. Закон становится немного жёстче. И мы понимаем, что в своей инфраструктуре сделать правильное решение тяжело.  Далеко не у всех есть лицензии ФСБ, ФСТЭК, чтобы поставить криптографию, да. Но на рынке присутствуют облачные решения за приемлемые деньги, которые вплоть до первого уровня- все позволяют перекрыть. Это может быть частное облако, может приватное облако- но всё можно решить. Второй момент, который тоже хотел сказать — относительно DDoS’ов-  полностью соглашусь с к

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

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

Примечательно, что многие девушки из ИТ не замечают в работе гендерных различий: мужчины и женщины могут быть в равной степени эмоциональны и рациональны, важны личностные характеристики — способности концентрироваться, решать сложные задачи, быстро обучаться. Компетентность не имеет пола – интересно, так считают только сами девушки?
Этот мировой тренд поддерживают крупнейшие корпорации: IBM, Facebook и Twitter. Различные организации и сообщества, такие как Women Who Code, Django Girls, Black Girls Code, Girl Develop It, She Codes и др., регулярно проводят программы обучения и хакатоны, летние стажировки для девушек в ИТ. Организация Girl Geek объединяет девушек из разных технических специальностей, а ее основательница Тэмми Батоу проводит в Нью-Йорке Girl Geek Dinners, где айти-девушки могут в неформальной обстановке пообщаться и обменяться контактами.
 
Не остаются в стороне и российские компании — появляется все больше сообществ, поддерживающих девушек-кодеров. Например, Ladies Code организует обучение для девушек, которые хотят развиваться в сфере ИТ. На муниципальном уровне в ряде регионов рассматриваются стратегические решения в пользу развития женского кодинга. С каждым годом количество поступающих на технические специальности девушек увеличивается. В крупнейших отечественных компаниях отмечают, что все больше женщин приходит на технические позиции. Сотрудницы делятся личным опытом, отмечая, что особых гендерных различий в ИТ нет, случается, что девушки сами боятся идти в профессию программиста из-за силы предубеждения о гендерном неравенстве.

Как вы считаете, в чем причины?

В светском обществе сегодня у женщин наравне с мужчинами есть все возможности обучения технической профессии: получение необходимых знаний как в теории, так и на практике в ходе стажировки в ведущей компании, воспитание личностных качеств, таких как сила характера, целеустремленность, гибкость и умение достигать результата.
 
Скептики возразят, что даже в случае успешного прохождения собеседования для большинства девушек в ИТ возможности роста в компании скромнее, а карьерный потолок ниже, чем у мужчины на аналогичной позиции.
 
Как вы считаете, утверждение о том, что добиться успеха и сделать карьеру руководителя женщине практически невозможно, истинно или очередной гендерный стереотип?
 
Мы уверены, что увлеченный и неравнодушный профессионал, обладающий нужными компетенциями с отличными личными качествами сможет добиться успеха и карьерного развития в любой отрасли. Так, например, в команде Программы «Единая фронтальная система» немало примеров, когда девушки показывают отличный результат в направлениях разработки, тестирования и проектирования.
 
В профессию девушки приходят из любопытства, с интересом к технологиям и желанием узнать, как устроены цифровые механизмы. Многими движет желание творчества – ИТ находит свое отражение сегодня во всех отраслях и сферах современной жизни, здоровые амбиции ищут реализации в креативных проектах. Немаловажный фактор — возможность сразу увидеть результат своей работы.
 
Современное поколение меняется и меняет окружающие устои: уровень развития профессиональной культуры дает надежду на то, что разделение коллективов по принципу мужской/женский – пережиток, который становится вчерашним днем.
 
А вы согласны с этим утверждением? Давайте пообщаемся в комментариях, нам интересен ваш опыт.
 
Возможно, среди наших читателей или подписчиков есть девушки–кодеры со своей историей?
 
Нам интересно узнать ваше мнение, как будет развиваться тренд женского кодинга, надо ли что-то менять и, если надо, как это сделать.

https://habrahabr.ru/post/331194/

31 мая Moscow Data Science Meetup собрал в нашем офисе более 200 участников. На встрече мы поговорили о градиентном бустинге, бейзлайне на ConvAI.io и разобрали кейс, получивший 7-е место из 419 команд на конкурсе Dstl Satellite Imagery Feature Detection. Предлагаем вашему вниманию видеозаписи и презентации трёх докладов, представленных на встрече.

Алексей Натекин (DM Labs, OpenDataScience): «Градиентный бустинг: возможности, особенности и фишки за пределами стандартных kaggle-style задач»

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

Валентин Малых (Лаборатория нейронных систем и глубокого обучения МФТИ): «Как перестать бояться и начать решать convai.io»

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

Евгений Некрасов (Mail.Ru Group): «Решение задачи Dstl Satellite Imagery Feature Detection (Kaggle)»

В соревновании Dstl Satellite Imagery Feature Detection участникам была поставлена задача сегментации мультиспектральных спутниковых изображений. В докладе будет разобрано решение этой задачи на основе сверточных нейронных сетей, которому присудили 7 место из 419 команд.

https://habrahabr.ru/post/331074/

Человек человеку — друг, товарищ и переводчик. И особенно тот переводчик товарищ, который работает с локализацией. Как правило, проще всего локализировать мобильные приложения: объем текста небольшой, специальных терминов мало. Это если языков перевода немного, скажем, десять. А вот мы недавно делали локализацию на 35 (!) языков.

О том, как искали исполнителей, преодолевали трудности и какие были забавные моменты, — эта статья.

Предисловие

Мы – небольшая ИТ-компания, занимаемся разработкой приложений и дополненной реальностью. Отдел локализации работает в основном на внутренних проектах либо делает переводы для клиентских заказов. До недавнего времени мы работали с основными европейскими языками (английский, немецкий, французский, испанский, итальянский) и некоторыми азиатскими (китайский, японский). И этого списка вполне хватало.

В один прекрасный день одно мобильное приложение понадобилось перевести на 35 языков. Как менеджер отдела локализации, могу сказать, что проще организовать перевод 1000 страниц на английский за неделю: сделать глоссарий, поделить между переводчиками и спокойно их контролировать. Тут же пришлось делать работу фактически с нуля: искать переводчиков, тестировать их, погружать в тематику работы, принимать переводы, считать статистику, контролировать выплаты. Но чем сложнее, тем интереснее: я просто в восторге от языкового разнообразия и от того, насколько один язык может отличаться от другого (да, я фанат, и если можно было бы бесконечно изучать различные виды письменностей и грамматических структур…) В общем, заказ получился интересным и очень ценным в плане опыта.

Немного статистики

Время выполнения: около месяца. Сроки позволяли не торопить процесс. Больше всего времени было потрачено на поиск переводчиков.

Языки:

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

монгольский немецкий нидерландский норвежский польский португальский (европейский) португальский (бразильский) сербский тайский турецкий украинский финский французский хинди хорватский чешский шведский эстонский японский

Поиск переводчиков

Как найти переводчика? Казалось бы, проще простого: есть сайты фрилансеров, есть даже своеобразные биржи толмачей. Но все не так просто.

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

Хороший эффект дало размещение объявления о поиске переводчиков в профильной группе в соцсети, так мы закрыли шесть языков.

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

Все косячат

Есть два неутешительных закона: «Все косячат» и «Если задание может быть сделано как-то не так, оно будет сделано как-то не так».



На выполнение перевода отправлялся документ MS Word с таблицами в три колонки: русский, английский и язык перевода. Кто-то умудрялся сделать перевод сплошным текстом. Кто-то делал в сплошном тексте фразовое соответствие: строчку на русском – строчку на иностранном. Кто-то скопировал всю огромную таблицу из гугл-таблиц (которая отправлялась исключительно для справки) и сделал перевод в ней (вай-вай, там же больше сорока колонок в каждом листе).

Еще встречались недопереводы, потерянные строки и абзацы. Ладно, в европейских языках это заметить довольно просто. А как быть, к примеру, с хинди? Языковое чутье (чего-то тут явно не хватает) и гугл-транслейт. Переводчики – народ, конечно, в большинстве своем ответственный, но от ошибок никто не застрахован. В общем, доверяй, но проверяй.

Забавные моменты

Работа с людьми – это всегда какие-то неожиданности. Иногда веселые. Наш новый переводчик арабского после получения задания куда-то исчез. Пришлось писать, искать. В ответ пришло письмо следующего содержания: «Простите, не предупредила, у меня на этих выходных свадьба. Про перевод помню. Как выйду замуж, сразу сделаю». Переводчик – как солдат, всегда в строю.



Некоторые переводчики ведут себя очень странно. Кто-то отказывается принимать «виртуальные деньги» (денежные переводы или PayPal), проживая заграницей. Кто-то откровенно обижается, увидев в документе рядом с колонкой русского текста его английскую версию, и заявляет, что он с английского на свой язык переводить не будет. Кто-то очень подозрителен: высылает скрин перевода, просит оплату и только потом шлет сам перевод. Но без таких моментов работа стала бы однообразной и скучной.

Так есть ли разница между индонезийским и малайским?

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

Самый неконкретный язык

Мне всегда казалось, что язык накладывает отпечаток на человека. Даже если он неродной. Где-то так оно и есть. Самыми неконкретными исполнителями были переводчики французского. Кто-то брал перевод и зависал на неделю («Да, сделаю, но позже. Если это уже не надо, сделаю другое…»), кто-то отвечал на электронные письма по нескольку дней. От владеющих немецким или, скажем, японским никогда такого не дождешься. У этих ребят все четко: перевод – подтверждение заказа – сдача в срок или раньше.

Самый сложный и дорогой язык

Таким оказался, как ни странно, венгерский. Сначала были сложности с поиском переводчика: русскоязычные толмачи то отказывались, то не отвечали. Пришлось искать в паре английский-венгерский. И тут сначала тоже была тишина. Потом многие были плотно заняты (казалось бы, неужели так много работы с венгерским?). В конце концов, исполнитель был найден, сделал работу хорошо, но и взял по хорошим среднеевропейским ставкам.

Так сколько зарабатывают переводчики?

Раз уж речь зашла о деньгах, могу сказать, что заработок переводчика зависит прежде всего от языковых пар и страны проживания. Русскоязычный рынок платит мало (украинцы демпингуют, специалистов много, конкуренция большая). Самый дешевый язык (он же самый распространенный) – английский. Можно найти переводчика по ставке 180-250 рублей за 1800 знаков с пробелами. Чуть дороже обойдутся другие европейские языки: французский, немецкий – 300-400 рублей. Восточные языки (китайский, японский, арабский) поднимают ставки еще на 200-300 рублей. Ну а самыми дорогими считаются так называемые «редкие» языки (список, как правило, размыт, там могут быть фарси, индонезийский, датский; на усмотрение самого переводчика) – ставки от 700 рублей. Мы назвали нижние границы ставок, все может меняться: с переводческими компаниями фрилансеры работают еще дешевле, с прямыми клиентами – дороже.

Да, что это за цифра такая – 1800 знаков с пробелами? Это стандартная переводческая страница. Считается, что специалист выполняет в среднем перевод одной такой страницы в час (за исключением сложных текстов технических тематик, чертежей и т.п.). То есть ставки за страницу примерно обозначают сумму денег, зарабатываемых за час.

Ситуация на переводческом рынке Индии схожа со странами СНГ: носители хинди, телугу, малаялама и других подобных языков выучили английский и конкурируют с друг другом по цене. А вот в европейских странах многие переводчики имеют свои сайты и не работают по выходным. А в Малайзии, например, есть понятие минимального заказа: даже если вам нужно перевести два предложения, надо заплатить 25 долларов.

Вместо выводов

Забег с 35 языками завершился, и это было очень здорово. Благодаря ему мы нашли классных специалистов по тем языкам, с которыми раньше не работали. Некоторые оказались настоящими «кладами» для нашей компании. Узнали много нового о языковых тонкостях перевода. Поработали с очень разными людьми и их мировосприятием. И повеселились, что тоже неплохо.

https://habrahabr.ru/post/330968/

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

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

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

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

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

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

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

Предлагаете ли вы самый лучший способ оплаты, чтобы выгодно отличаться от конкурентов?

Осуществление платежей

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

Страница оплаты, конечно, важна, но она — не единственное, на что нужно обратить внимание. Вот несколько советов, которые вам помогут.

Пять способов улучшить процесс осуществления платежей онлайн:

1. Информировать клиентов о том, какие способы оплаты предлагает поставщик услуг на главной странице сайта, чтобы они сразу знали, что смогут использовать свой любимый метод оплаты.
2. Позволить клиентам выбрать предпочитаемую валюту, так как 25% посетителей не станут завершать процесс оплаты, если их родная валюта при оплате будет недоступна.
3. Создать удобные страницы проведения платежей — уменьшить количество полей, в которые необходимо вводить данные, и настроить автоматическое заполнение данных по мере возможности.
4. Внушить больше доверия своим клиентам, разместив сертификаты безопасности платежной системы и высылая уведомления о статусе платежа / подтверждение оплаты на электронную почту после успешной или неудачной транзакции. 97% людей сказали нам, что рассчитывают получить электронное письмо после проведения платежа.
5. В случае возникновения проблем, оптимизируйте восстановление корзины, если платеж не прошел, и организуйте решение вопросов, связанных с оплатой.

Мобильность — это революционный шаг

Благодаря 4G, бесплатному Wi-Fi и дешевому роумингу, мобильные телефоны стали лучшими друзьями путешественников, которые используют их не только для поиска информации, но и для мгновенной оплаты дополнительных туристических услуг.

«Ориентация на мобильность» уже давно стала мантрой в секторе розничной торговли, но туроператоры все еще не успевают за инновациями. Азия сегодня возглавляет мобильную революцию в индустрии туризма — согласно недавнему опросу Worldpay, каждый третий китайский путешественник бронирует свою поездку со смартфона, тогда как в Германии это делает лишь каждый сотый.

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

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

Пять способов улучшить процесс осуществления платежей онлайн:

1. Оптимизировать свои страницы оплаты для мобильных устройств и минимизировать количество данных, которые необходимо вводить.
2. Находить баланс между риском и удобством пользователя и периодически отключать проверку 3D Secure для транзакций с низкой стоимостью или постоянных клиентов.
3. Если вы предлагаете альтернативные способы оплаты, то убедитесь, что их использование оптимизировано для мобильных устройств.
4. Позвольте клиентам хранить свои платежные реквизиты в своем профиле, выбрав эту опцию во время проведения первого платежа — это позволит оплачивать любые последующие покупки без повторного введения данных.
5. Лояльность к вашему сайту повысится, если путешественники смогут совершать оплату на ходу одним касанием экрана телефона. Если же вы будете перенаправлять своих клиентов к стороннему провайдеру для совершения бронирования и оплаты, то уровень конверсии снизится, потому что это создает неудобства для пользователей.

Как оптимизировать процесс оплаты:

1. Найти баланс между противодействием мошенничеству и удобством пользователя для максимизации уровня одобрения платежей. Например, настроить динамическое отключение 3D Secure в зависимости от стоимости транзакции, профиля путешественника и канала бронирования.
2. Выбирать между локальным и международным эквайрингом, чтобы найти баланс между расходами и уровнем одобрения платежей.
3. Предоставлять также данные 2-го и 3-го уровня — помечать транзакции, чтобы помочь повысить показатели уровня одобрения платежей и снизить межбанковские комиссии.

Онлайн-туристические агентства (OTA)

Как работает эта модель:

• Путешественник А бронирует семейный отпуск на сайте ОТА
  За 2 дня до вылета они предлагают ему парковку в аэропорту и доступ в зал ожидания повышенной комфортности через приложение на мобильном телефоне.
• Во время отпуска мобильное приложение OTA рекомендует отправиться в сплав по реке на основе прогноза погоды, — Путешественник A оплачивает его своим отпечатком пальца.
• Путешественник А хочет продлить свой отпуск еще на один день. Его отель и рейс автоматически обновляются одним кликом.
• Онлайн-туристические агентства (OTA) обычно рассматриваются как «универсам путешествий». Клиенты совершают единовременный платеж за пакет туристических услуг, и все будет готово с момента их отъезда в аэропорт до их возвращения.

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

Авиакомпании

Как работает эта модель:

• Путешественник Б бронирует рейс на сайте авиакомпании.
• Он приезжает в аэропорт с опозданием, поэтому ему предлагается услуга ускоренного сопровождения через зону досмотра с помощью сохраненных данных карты.
• Путешественник Б видит в самолете рекламу билетов в театр и покупает их на борту
• Когда он приземляется, авиакомпания отправляет ему push-уведомление о трансфере в отель с помощью GPS — он оплачивает его в один клик.

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

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

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

Отели

Как работает эта модель:

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

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

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

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

Подтверждение бронирования может быть выполнено «одним кликом, и гости смогут автоматически зарегистрироваться, когда будут подъезжать к зданию отеля, используя сохраненные платежные реквизиты.

Это также позволит гостю изменять и отменять отдельные услуги в своем бронировании без необходимости проведения переговоров с несколькими сторонами.

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

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

Рынок туристических продуктов

Как работает эта модель:

• Путешественник Г заказывает такси через приложение и оплачивает поездку одним кликом.
• Такси прибывает по GPS-координатам.
• Путешественник Г прибывает в пункт назначения, и оплата автоматически обрабатывается.

То, что кажется клиенту легким, простым и невидимым, скрывает за собой сложный мир инфраструктуры платежей с тремя основными составляющими:

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

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

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

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

Резюме

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

Компаниям следует:

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

https://habrahabr.ru/post/319750/

В этой статье мы хотим рассказать о нашем продукте TOTPRadius. Это RADIUS сервер, спроектированный для применения в системах двухфакторной аутентификации. Помимо стандартного для этого протокола фунционала, TOTPRadius предоставляет несколько дополнительных функций, одной из которых является восзможность организации самостоятельной регистрации второго фактора для рядовых пользователей

RADIUS для двухфакторной аутентификации

RADIUS — это стандартный протокол принятия и обработки запросов проверки подлинности. Помимо обычной (однофакторной) аутентификации, многие системы используют протокол RADIUS для двухфакторной аутентификации, чаще всего для проверки подлинности второго фактора. Принцип довольно простой: если взять в качестве примера алгоритм TOTP, в котором для генерации одноразового пароля (one-time password- OTP) используется текущее время и секретный ключ, то OTP, введенный пользователем, передается RADIUS серверу, который, в свою очередь, и проверяет его подлинность. Конечно, и секретный ключ и текущее время должны совпадать с генератором OTP. RADIUS для двухфакторной аутентификации используется, например, в VMWare View/Horizon, Citrix NetScaler, Fortinet VPN и др.

Самостоятельная регистрация и зачем она нужна

Очень часто возникает необходимость предоставить пользователям возможность активировать второй фактор самостоятельно. Стандартные реализации такой возможности не дают, и это понятно: в обычной имплементации двухфакторной аутентификации она или есть, или ее нет, третьего не дано. Это может привести к сложностям — например, при миграции большого количества пользователей регистрация второго фактора должна быть централизована. В случае, если используется софт-токен (например, приложения типа Google Authenticator или Token2 Mobile OTP) на персональных мобильных устройствах, логистику миграции даже сложно себе представить.
В этом случае может помочь самостоятельная регистрация. Идея такая: пользователям без активного второго фактора (иными словами, без записи в базе данных сервера RADIUS) пускать в систему один раз (ну или два, если допускать возможность что в первый раз что-то может пойти не так) – и далее предоставить им возможность самостоятельно запустить процесс регистрации второго фактора (создания профиля TOTP в приложении). Token2 TOTPRadius представляет возможность организовать такую регистрацию через простой RESTful API. В упрощенном виде, это запрос в формате

https://Адрес-Сервера/api?username=[имя_пользователя]&api-key=[ключ-для-подключения]

где ответом от сервера при успешном выполнении запроса будет сгенерированный для данного пользователя секретный ключ в текстовом и QR-code формата.

Пример интеграции: TOTPRadius с Citrix NetScaler + Storefront

Связка Citrix Netscaler + Storefront применяется для осуществления доступа к продуктам Citrix XenApp и XenDesktop. NetScaler из коробки поддерживает использование RADIUS сервера в качестве источника аутентификации второго фактора. Дополнительной интеграцией в данном случае будет только реализация самостоятельной активации TOTP профиля софт-токена в интерфейсе Storefront посредством RESTful API. Процесс подключения довольно прост и описан в этом документе. Как это выглядит глазами конечного пользователя показано на видео:

Дополнительные возможности

Помимо готовых скриптов интеграции со Storefront, TOTPRadius также легко интегрируется с Wordpress и Drupal (с использованием плагинов Token2). Мы будем также рады помочь с интеграцией с любыми другими системами.

Спасибо за внимание!

https://habrahabr.ru/post/331210/

VoIP — это термин-зонтик. Набор технологий, протоколов и просто buzzword'ов, которые относятся к передаче голоса (и видео!) по компьютерным сетям (локальным или интернет) вместо телефонных. И да, большая часть телеком-провайдеров всё ещё использует для передачи голоса собственные сети вместо интернет. С недешевыми коробочками, куда втыкаются T1 и E1 провода.

Чаще всего, для айтишников, не работающих в телекоме, VoIP – это связка RTP/RTCP для передачи голоса/видео плюс SIP – для договориться, кому и как передавать. Именно это связка позволяет подключить офисные «SIP телефоны» к Bitrix24 или Asterisk. Оба протокола могут работать как по TCP, так и по UDP. С передачей голоса по RTP вопросов нет: за редчайшим исключением используется UDP протокол, а кодеки компенсируют потерянные пакеты, так что собеседник почти не «квакает» даже не на самом лучшем канале связи. А вот с SIP история более печальная.



Вообще, SIP — это такой HTTP для телефонии. Про него на Хабре есть замечательный двухсерийный пост. Если кто интересуется, очень рекомендую. Ключевое отличие от HTTP, что SIP должен работать в обе стороны всегда. Задача «отправить сообщение с сервера на клиент» решалась в HTTP очень много лет, пережила AJAX, WebSockets, и сейчас наконец-то стабилизировалась в виде HTTP/2. А в SIP эту задачу нужно было решать сразу: не только телефонный аппарат отправлял запрос «вот он я, готов принимать звонки», но и сервер должен был иметь возможность в любой момент сообщить клиенте «а вот тебе и звонок, принимать будешь?».

А у TCP, при всех его достоинствах, есть и недостатки. Например, соединения могут «протухать». Если не поставить маленький keep-alive (а SIP был создан в 1996-м году) и постоянно не отсылать пинги, то «подключение» может оборваться с одной стороны, а вторая сторона этого не заметит. Хорошо, если оборвалось со стороны клиента — он это заметил и переподключился. А если оборвалось со стороны сервера? Нужно ждать, пока у клиента случится keep alive или какой-нибудь другой таймаут и он переподключится. А в это время клиенту звонок.

А еще 20 лет назад, когда это всё создавалось, был очень печальный вопрос переподключения. Для UDP версии SIP клиентам достаточно время от времени (раз в час) посылать пакеты REGISTER, говоря «вот он я, готов принимать звонки». В случае перезагрузки или выключения сервера другой сервер за тем же IP-адресом может работать со всеми этими клиентам. А вот в случае TCP клиентам нужно будет переподключаться. Десять тысяч телефонов здания (обычная ситуация) пошли переподключаться и убили сервер…

В общем, все ждали, что SIP будет по TCP. А он стал по UDP. Сейчас, 20 лет спустя, все больше компаний переключаются на «только по tcp». Тем не менее, огромный парк устройств, клиентов и инфраструктуры ходили по UDP, ходят по UDP и ближайшие несколько лет ходить будут.

А в комбинации «SIP и UDP» есть беда. Собственно, этот пост про нее. Беда называется «фрагментация». Сама по себе фрагментация сетевых пакетов почти безвредна: есть настроенный для сетевой карты MTU, максимальный размер передаваемого за раз пакета. В большинстве случаев это 1500 байт. Для TCP и подавляющего большинства UDP протоколов это никак не влияет: они просто никогда не шлют пакеты больше MTU и используют внутренние механики, чтобы передавать большие объемы данных по кусочкам, терять эти кусочки и пересылать их повторно, если надо.

А SIP — он как HTTP. Текстовый. И в последние годы к простым командам вроде «я тут» и «тебе звонок» добавилась куча дополнительных полей и всяких XML/JSON в пайлоадах. Размер получающихся пакетов стал регулярно выходить за пределы MTU. Начиная с этого момента история становится совсем печальной.



Современный интернет — он, на самом деле, не очень хорошо приспособлен к фрагментированным сетевым пакетам. Производители оборудования и авторы софта резонно полагают, что большинству софта такие пакеты слать не нужно. TCP фрагментирует сам, UDP — это realtime команды, видео и звук. Им не нужно быть больше MTU. Если потеряются, ничего страшного не произойдет. И не очень заморачиваются, насколько хорошо их решения поддерживают фрагментированные пакеты. Свичи могут крешится. «Корпоративные» железки, делающие свои надстройки поверх ethernet/ip, не могут фрагментацию и молча игнорируют пакеты. А у некоторых железок буфер на сборку фрагментированных пакетов — на целых 200 штук. Переполняется он на удивление легко.

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

Сейчас все стараются использовать SIP по TCP, но проблема отставания инфраструктуры за последние несколько лет встала очень остро. Все больше видео и голосовых звонков совершаются через браузеры (чего стоит только недавно вышедший «Skype для веб»). С какой скоростью развивается веб, мы с вами прекрасно знаем: набежавшие разработчики принесли с собой привычные JSON и XML пайлоады, а видеоконференции на 20-30 человек перестали быть уделом крупных компаний, где бородатые админы могли неделями настраивать циски, «чтобы работало».

Вывод: увидите SIP и UDP в одном месте — будьте осторожны. И при первой возможности переключайте на TCP!

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

А картинка для привлечения внимания — вот отсюда

https://habrahabr.ru/post/331132/

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

Материал подготовлен на базе лекции соучредителя и креативного директора компании Playdisplay Андрея Сударикова, которая проходила на конференции VR-Today в рамках нашей образовательной программы «Менеджмент игровых проектов» в ВШБИ. Конспект под катом.



Компания Playdisplay появилась 6 лет назад и была одной из первых в сфере дополненной реальности. Её соучредитель и креативный директор Андрей Судариков занимался графическим дизайном 20 лет.
Название Playdisplay состоит из двух слов — “играть” и “показывать”.

Всё начиналось с карточек дополненной реальности с применением технологии ARToolKit. Они были квадратными чёрно-белыми, похожими на QR-коды. В то время не было возможности воспринимать маркеры абсолютно любого вида. С помощью этих карточек был сделан проект для детской Гайдаровской библиотеки. Не было мобильной дополненной реальности и Playdisplay делали её для стационарных компьютеров с внешней веб-камерой.

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

Одним из первых крупных проектов была инсталляция для музея “Гараж”. Она в наглядном виде показывала как выглядела временная архитектура в Парке Горького. Было сделано мобильное приложение дополненной реальности, которое демонстрировало утерянную архитектуру парка при наведении мобильного устройства на карту. Этот проект увидел Дмитрий Медведев.

Один из клиентов Playdisplay — холдинг “Аэропорты Регионов”. Компании требовались инсталляции для выставок в разных городах и странах. На авиационном форуме в Чикаго присутствовал СЕО аэропорта Changi из Сингапура, которому она очень понравилась инсталляция PlayDisplay. Спустя 2 года сотрудники Changi обратились в PlayDisplay с просьбой сделать похожую инсталляцию в Сингапуре.

Чуть позже компания презентовала свои разработки Владимиру Путину на форуме Селигер.

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

Еще один из кейсов Playdisplay — музей в Астане. В пустом пространстве с помощью шлема виртуальной реальности можно рассматривать различные экспонаты. Контакты, которые компания наработала на этом проекте, привели её к Нурсултану Назарбаеву. PlayDisplay получила заказ на создание инсталляции для новой ледовой арены. За 8 суток работы команда смогла сделать шестиминутное мэпинг-шоу с отображением истории казахского хоккея, а также создать инсталляцию с дополненной реальностью. Зритель видел на экране себя, а на столе — трёхмерную модель в дополненной реальности. Представитель заказчика спросил за сутки до презентации: “А зачем я здесь вижу себя? Господину президенту это может не понравиться”, и пришлось за одну ночь переделывать проект, устранив из него алгоритм дополненной реальности.



Есть нюансы, которые можно понять только с опытом. К примеру, во время одной из проверок объекта ФСО обнаружила, что наклейка на столе-экспонате выполнена из высокотоксичного пластика и это едва не угробило весь проект. Важно понимать, что проект — это не только код, который выполняется на том или ином устройстве, а весь опыт, который происходит при соприкосновении с вашим продуктом.

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

Уникальное предложение

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

В чем же состоит уникальность Playdisplay?

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



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

Стейкхолдеры

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

• PlayDisplay
• Компания-заказчик
• Менеджер компании-заказчика
• Руководитель менеджера
• Акционеры заказчика
• Администраторы площадки мероприятия
• Администрация президента
• Команда президента
• ФСО
• Президент
• Обыватели

Все это выглядит как хаос. Существуют не две точки соприкосновения: заказчик — исполнитель. На самом деле их гораздо больше. Учитывая все эти действующие лица, мы можем продумывать решение так, чтобы оно отвечало интересам заказчика, а не менеджера, например. Чтобы оно соответствовало требованию президента, но не противоречило требованиям ФСО.

Цикл сделки

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

PR (сарафан, выставки, сайт, SMM) — Знакомство — Коммерческое предложение 1 версия — Конкурс — Коммерческое предложение 2 версия — Согласование — Коммерческое предложение 3 версия — Тендер — Контракт — Техническое задание — Разработка — Сдача — Презентация — Повторные обращения



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

Этапы разработки

Их должны знать и уметь правильно преподносить клиенту ваши сотрудники:

Для чего вы этим занимаетесь?

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



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

Осенью у нас начинается обучение на нашей образовательной программе «Менеджмент игровых проектов», приглашаем 28 июня на день открытых дверей!

https://habrahabr.ru/post/331200/

С появлением application programming interface или, если кратко, API, жизнь программистов стала несколько легче, чем раньше. За минимальное время теперь можно добавить в свое приложение определенные функции, структуры, процедуры, предоставляемые другим приложением, операционной системой или сервисом. API своих сервисов и приложений сейчас открывают многие разработчики.

В 2013 году компания IBM открыла сразу три API когнитивной системы Watson в рамках “The Watson Ecosystem” — экосистемы, которая на то время включала более 40 различных технологий. Благодаря этим API разработчики получили возможность встраивать в собственные приложения и сервисы возможности, предлагаемые IBM Watson. Сейчас открытых компанией IBM API гораздо больше, чем три, да и сами сервисы стали более функциональными. В продолжении — описание существующих API различных сервисов, к которым может получить доступ разработчик.

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

Группа «Язык»

В эту группу входит семь различных сервисов с открытыми API:
• AlchemyLanguage;
• Conversation;
• Document Conversion;
• Language Translator;
• Natural Language Classifier;
• Natural Language Understanding;
• Personality Insights;
• Retrieve and Rank;
• Tone Analyzer.

AlchemyLanguage


Сюда входит целый набор API, который позволяет научить свое приложение или сервис «понимать» чувства, ключевые слова и фразы, высокоуровневые абстракции и прочее. Этот сервис можно применить для того, чтобы проанализировать общие настроения покупателей определенного продукта. Что думают о вашем товаре или услуге фолловеры в Twitter или друзья из Facebook? Это важная информация, которая позволит улучшить взаимодействие со своей целевой аудиторией.

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

Доступ к API можно получить здесь. Дополнительная информация доступна по этой ссылке.

Conversation


Watson Conversation помогает разработчику создать бота или виртуального ассистента в виде приложения для мобильного устройства, веб-сервиса или даже робота «во плоти», способного общаться с людьми. В рамках сервиса разработчикам предоставляется визуальный редактор диалогов, благодаря которому разработчик может наладить канал общения со своими посетителями. Никакие особенные навыки программирования здесь не требуются.

Доступ к API здесь, подробная информация здесь.

Document Conversion

Этот сервис позволяет преобразовывать различные форматы документов в формат, который используется одним из сервисов Watson. Document Conversion — вспомогательный сервис, который используется наряду с другими возможностями когнитивной системы.

Доступ к API здесь, подробная информация здесь.

Language Translator

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


Сервис самообучающийся. Так что если где-то была допущена ошибка, и ее исправили, то эта ошибка больше не появится. Кроме того, сервис «запоминает» специфические названия продуктов, имена людей и термины для того, чтобы перевод был максимально корректным.

Доступ к API здесь, подробная информация здесь.


Natural Language Classifier


Этот сервис классифицирует контент по его тематике. Например, он позволяет «объяснить» компьютеру, что вопросы вроде «Какая сегодня погода», «Жарко ли сегодня», «Можно ли будет отправиться на море» имеют отношение к погоде и температуре. Соответственно, разработанный бот сможет «понять», о чем спрашивает пользователь и дать релевантный ответ.

Доступ к API здесь, подробная информация здесь.

Natural Language Understanding

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

Доступ к API здесь, подробная информация здесь.


Personality Insights

Этот сервис позволяет оценить некоторые аспекты личности автора определенного текста (например, делового сообщения). Анализ ведется по содержимому написанному и тому, как составлено послание или документ. Для того, чтобы сервис работал корректно, рекомендуется загружать тексты, содержащие не менее 1200 слов.

Доступ к API здесь, подробная информация здесь.

Retrieve and Rank

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

Доступ к API здесь, подробная информация здесь.

Tone Analyzer

Сервис IBM Watson Tone Analyzer использует лингвистический анализ для определения тона сообщения. Он помогает сразу оценить эмоциональную составляющую контента, чтобы быстрее сориентироваться в том, как нужно отвечать. Сервис может использоваться и для анализа социальных медиа — например, странички социальной сети с отзывами о продукции или сервисе компании. Также с ним можно работать при общении с клиентами.

Доступ к API здесь, подробная информация здесь.

Группа «Речь»

Сюда входят такие сервисы, как
• Speech to Text;
• Text to Speech.

Speech to Text


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

Доступ к API здесь, подробная информация здесь.

Text to Speech

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

Доступ к API здесь, подробная информация здесь.

Группа «Обработка изображений»

В этой группе пока только один сервис:

Visual Recognition


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

Доступ к API здесь, подробная информация здесь.

Группа «Работа с данными»

А в эту группу входят сервисы, которые позволяют провести подробный анализ данных любых сложных документов различной тематики:
• AlchemyData News;
• Discovery;
• Discovery News.

AlchemyData News

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

Доступ к API здесь, подробная информация здесь.

Discovery


Структурирование данных из проанализированных новостей с выделением основного содержания. Сервис работает, преимущественно, с английским языком. Каждый день этот сервис анализирует более 300 тысяч новостных заметок и блог-записей из 100 000 источников. Сервис позволяет искать и анализировать в полученной информации отзывы по определенному продукту или услуге с определением частоты упоминания различных названий и выполнять с данными прочие действия.

Доступ к API здесь, подробная информация здесь.

Discovery News

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

Доступ к API здесь, подробная информация здесь.

Как работать со всеми этими инструментами?

Для того, чтобы начать работу с IBM Watson и его сервисами, необходимо выполнить следующие действия:
1. Получить бесплатную учетную запись на платформе Bluemix. Первый месяц работы с этой платформой бесплатен;
2. Настроить аккаунт, указав данные и настроив окружение. В этом поможет мастер;
3. Найти необходимый сервис, который нужен именно вам. На самом деле, Bluemix предлагает гораздо больше сервисов, чем указано выше. Начать работу с ними очень просто;
4. Создать инстанс. Для этого нужно выбрать сервис Watson и затем нажать кнопку Create;
5. Получить необходимые данные для встраивания в свое приложение.
6. Создать собственный сервис или приложение.

Сейчас Watson API используют тысячи партнеров компании, в их числе как крупнейшие корпорации, вроде японской компании Softbank, так и независимые разработчики. Оценить возможности когнитивной системы IBM Watson можно совершенно бесплатно.

https://habrahabr.ru/post/331206/

Угрозы совершенствуются, вредоносные программы становятся все более сложными, а техники атаки — все более изощренными. Жертвы уже не выбираются случайно, атаки стали направленными, скоординированными и использующими различные направления. Также изменился мотив: он уже не связан с признанием — только экономическая прибыль.

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

Для максимального укрепления финансовой системы Евросоюз впервые планирует выполнить проверку всей европейской банковской системы на предмет наличия необходимых систем для защиты от самых современных известных кибер-атак. Эти проверки будут похожи на так называемые «стресс-тесты». Европейская банковская организация (EBA) также хочет запустить ряд инициатив для обеспечения безопасности цифрового банкинга.

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

Введение

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

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

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

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

А теперь вопрос на миллион долларов: где находятся крупные суммы денег? Без сомнения, они находятся в финансовых организациях, например, банках.

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

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

Чтобы собрать все требуемые данные для осуществления такой атаки, требуются серьезные инвестиции. Хотя, конечно, все эти усилия окупятся, если хакер сможет успешно провести свою атаку «на миллион долларов».

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

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

Законодательство

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

Новые правила в Европе: GDPR

Действующее европейское законодательство не адаптировано ни к новым кибер-преступлениям, ни к потребностям, появляющимся в результате использования новых технологий и систем ИТ-управления.

Общий регламент Европейской комиссии по защите данных (General Data Protection
Regulation, GDPR) вступает в силу 25 мая 2018 года, и он будет регулировать то, как компании собирают и обрабатывают персональные данные жителей всего Европейского союза.

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

Чтобы работать безопасно, безопасность банковских систем требует постоянного обслуживания. При этом следует иметь в виду, что одна из самых больших проблем, с которой сталкивается финансовый сектор в наши дни, — это защита персональных данных
от брешей безопасности, поэтому крайне важно иметь четко спланированный и отработанный план действий на случай кибер-атаки. GDPR требует прозрачности, и Panda Security рекомендует европейским организациям привести свои бизнес-операции в соответствии с новыми требованиями как можно быстрее.

Миграция в облако

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

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

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

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

Отсутствие формальных руководящих принципов для облачных сервисов является препятствием для адаптации облачных вычислений в качестве «драйвера» для инноваций, хотя они широко пропагандируются Еврокомиссией в качестве таковых при формировании единого цифрового рынка.

Случаи миллионных кибер-краж

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

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

Банк Бангладеш

Одним из наиболее ярких примеров этому стала кража в Центральном банке Бангладеш, когда группа хакеров успешно заразила системы банка с помощью вредоносной программы, специально созданной для данной атаки, и попыталась совершить серию операций на общую сумму в 951 миллион долларов США. Эта сумма могла быть найдена на счете Банка Бангладеш в Федеральном резервном банке Нью-Йорка. К счастью, большинство операций было заблокировано, но хакеры смогли украсть «только» 81 миллион долларов США. Но это не единственный случай.

Tien Phong Bank

Коммерческий вьетнамский банк Tien Phon Bank пережил подобную атаку в четвертом квартале 2015 года. Хакеры снова попробовали сделать операции через сеть SWIFT, но банк во время заметил эти операции и сумел заблокировать операции на сумму более 1 миллиона долларов США.

Banco del Austro

Ранее, в январе 2015 года эквадорский банк Banco del Austro также столкнулся с подобной атакой, в результате чего из банка было украдено порядка 9 миллионов долларов США.



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

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

Эта группа хакеров ответственна за все эти три кражи, и на сегодняшний день все доказательства указывают на КНДР. В декабре 2016 года стало известно, что SWIFT отправил своим клиентам предупреждение o том, что стали возникать новые случаи атак. По словам Руководителя программы безопасности пользователей в SWIFT Стефана Джилдердейла, о чем он заявил в Reuters, банки, использующие сеть SWIFT, будь то центральные банки стран или коммерческие банки, были многократно атакованы после случая с кибер-кражей в Банке Бангладеш. Причем в 20% случаев хакеры смогли успешно своровать деньги.

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

Мы в антивирусной лаборатории PandaLabs проанализировали различные атаки, совершенные специально разработанными для них вредоносными программами, такими как PunkeyPOS, когда хакеры скомпрометировали заведения в США.

POS-терминалы, пострадавшие от PunkeyPOS



Информация о других вредоносных программах, ориентированных на POS- терминалы, такие как Multigrain или PosCardStealer.

Тенденции в финансовых кибер- преступлениях

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

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

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

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

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



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

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

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

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

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

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

1. Бразильские
(Banbra, Banker, Bancos и пр.)

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

2. Русские
(Bankolimb, Zeus, Sinowal, SpyEye, Citadel, Dyreza и пр.)

Они нацелены на клиентов из банков Европы и США. Они всегда являлись и являются самыми сложными с технической точки зрения.

Многие из них имеют очень много сходств, потому как во время их расцвета был опубликован исходный код Zeus, из которого потом возникло множество других семейств: SpyEye, Citadel, Ice IX, Ramnit, Zberp, Kins, Murofet, GameOver (Zeus P2P ) и пр.



Однако в последние годы мы видим, как криминальные группы диверсифицируют свои направления работы, выискивая новые места для получения денег:

POS-терминалы, контролируемые компьютером

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

Банкоматы

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

Банки

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

Рекомендации банкам во избежание кибер-краж

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

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

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

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

Итак, как ПО для обеспечения ИБ должно относится к данным, которые хранятся в облаке, чтобы максимально эффективно соответствовать законодательным нормам?

Информация под грифом «секретно»: облачный сервис не должен иметь доступ к конфиденциальной персональной информации или информации, которая имеет высокий уровень защищенности в соответствии с законодательством о защите персональных данных, или классифицируемой банками как «секретная информация». Единственный возможный нюанс — косвенный сбор данных, связанных с использованием компанией своих ИТ-ресурсов в результате активности пользователей. Данная информация может быть включена в виде ограничения во внутренние правила поведения, и быть доступна только ограниченному кругу лиц (операторы защиты и персонал банка).

Информация под грифом «конфиденциально»: сервис имеет доступ к информации пользователей с более низкими уровнями защищенности. Например, данные пользователя для входа в систему (но не пароль, который никогда не должен собираться), название устройства и его IP-адрес, если они однозначно идентифицируют пользователя. Эти данные необходимы для корректной работы облачного сервиса, а потому понятно, что провайдеры сервиса могут быть авторизованы для доступа к таким данным.

Эти два качества лежат в основе модели безопасности Adaptive Defense 360 — первого облачного сервиса информационной безопасности с функциями расширенной защиты, сочетающего защиту устройств следующего поколения (NG EPP) и технологии обнаружения и реагирования на атаки (EDR) с возможностью классификации 100% запущенных процессов.

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

Это одна из наиболее ценных функций в финансовом секторе. Adaptive Defense 360 получает данные и передает их в SIEM- систему, которая позволяет получить полную видимость всех процессов на каждом конечном устройстве.

В дополнение к этому, а также к способности обнаруживать и блокировать любые виды атак (включая неизвестные), направленные против системы, Adaptive Defense 360 позволяет обнаруживать и закрывать уязвимости в системе и ее приложениях, а также предотвращать использование нежелательных программ, таких как навигационные панели, рекламное ПО или дополнения и расширения.

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

https://habrahabr.ru/post/331204/