134 Релиз (0)

134.01 Пилотный проект "Самозанятые".

В рамках перехода компании на более прозрачную схему оплаты труда дилеров Store реализован масштабный проект "Самозанятые".

В ходе работы над этой задачей был добавлен новый функционал в раздел “Профиль“ приложения Store. А именно: был добавлен новый статус в профиле пользователя “Статус самозанятого: Не подтвержден\Подтвержден“. В случае, если пользователь не зарегистрирован в Store, как самозанятый, ему будет предложено зарегестрироваться:

”Безлимит" предлагает своим партнерам новую возможность - работайте официально! Зарегистрируйтесь самозанятым, заполняйте паспортные данные клиентов при активации номеров - получайте тройные бонусы за активацию номеров! Стать самозанятым просто, скачайте приложение "Мой налог", пройдите простую процедуру регистрации по паспорту или по учетной записи в Госуслугах. Если вы клиент Сбербанка или банка Тинькофф то зарегистрироваться самозанятым можно в их приложениях. Став самозанятым можете перейти к процедуре регистрации в Store:”

Следующим этапом самозанятый дилер регистрируется в Store, посредством ввода ИНН, банковских реквизитов, паспортных данных.

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

За полное внесение паспортных данных самозанятые дилеры буду получать дополнительные бонусы которые составляют 100% от тарифа активированного им номера.

Для активации бонуса должны соблюдены 2 условия:

1. Загружены 2 фотографии паспорта;
2. Паспортные данные заполнены и подтверждены в биллинге;
   

На предоставление паспортных данных дилерам предоставляется 3 дня с момента активации номера.

Если дилер не внес ПД при бронировании номера, то он может сделать это позже в разделе мои активации нажав на кнопку "Внести ПД"

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

134.02 Заявка на ТТ в Билайн - в Битрикс.

В рамках переноса процесса постановки задач колл-центра в Битрикс был добавлен функционал передачи заявки на ТТ в Билайн.

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

Задача инициирована отделом внедрения CRM-системы Битрикс.

134.03 Создание роли canDoUpdateBookingPhone.

Реализована роль canDoUpdateBookingPhone. При отсутствии данной роли недоступно производить изменения параметров на забронированом номере в Store и брони в Биллинге:

1. Дата активации;
2. Дата изменения статуса блокировки;
3. Срок годности;
4. Контактное лицо;
5. Дилер;
6. Статус блокировки;
7. Запрет разблокировки;
8. Фродоопасный запрет блокировки;
9. Признак номера;
10. Ресурс реализации номера;
11. Признак номера в Store;
12. Удалить номера (Чекбокс);
13. Установить флаг замены сим(Чекбокс);
14. Изменить поле «Новый номер SIM-Карты»(Чекбокс);
15. Флаг первичной активации(Чекбокс);
16. Очистить все платежи и начисления(Чекбокс);
17. Очистить ПД(Чекбокс);

При попытке произвести изменения на забронированном номере будет отображаться информация о забронированном номере.

При наличии роли canDoUpdateBookingPhone брони можно производить изменения по забронированному номеру.
Задача инициирована отделом теста и необходима для надежной активации номеров у дилеров в Store.

134.04 Создание бота-уведомлений для Jira.

Создан telegramm бот jira для получения информации о всех событиях в задачнике.

Jira бот предоставляет следующую информацию:

1) Создание задач;

2) Изменение задач;

3) Удаление задач;

4) Комментарии в задаче;

Задача инициирована отделом разработки и теста.

134.05 Сортировка для виджета "Активаций" на "Главной" биллинга.

В рамках задачи была добавлена возможность детально просматривать виджет "Активации" на "Главной странице" биллинга.
По нажатию на кнопку "обновить" в виджетах "Активации: текущий период" и "Активации: сегодня", разворачиваются столбцы с параметрами:
- Категория номера
- Бан
- Абонентская плата наша
- Абонентская плата Билайн
- Количество;

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

Задача инициирована отделом разработки и теста.

134.06 Ручное внесение "дат" при заполнении паспортных данных.

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

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

134.07 Баги по правам доступа и маршрутам.

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

Удален маршрут:

/phone/phone/update-field - Карточка номера - Номер - смена статуса, обновление свойства.

Добавлены маршруты:

/phone/attribute/change-status - Карточка номера - Номер - смена статуса, обновление свойства, БЕЗ ОБРАБОТКИ.

/phone/attribute/change-now_nachislenie_wdone - Отчеты - 16 отчет - редактирование свойства "меры".

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

134.08 Доработка отчета СДЭК.

В рамках задачи был добавлен новый функционал к отчету СДЭК.
Теперь раз в сутки в отчете обновляется информация о статусе точек для самовывоза и доставки - открыто/закрыто.

Кроме того, теперь, если произошла замена адреса у точки СДЭК, в отчете отразится это изменение.

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

134.09 Переезд на таблицу phone_params_client.

В рамках переезда создана и заполнена таблица , а также добавлены тригеры в phone_params_client. В base_models добавлена модель ClientParams и в модель PhoneEntity добавлена реляция getClientParams. Переезд на данную талицу необходим для группировки признаков номера а также созданы следующие колонки:

1. phone_number;
2. passport_id;
3. passport_id_date;
4. full_name;
5. full_name_date;
6. info;
7. info_date;
8. birthday;
9. birthday_date;
10. secret_key;
11. secret_key_date;

Данная задача инициирована it отделом в рамках задачи "История ПД (бесконечное логирование изменений)".

134.10 Рефакторинг таблицы тарифов по умолчанию.

В рамках данной задачи была произведена переработка кода таблицы тарифов по умолчанию.

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

134.11 Задачи категории "Автосмена ТП".

В рамках данной задачи произведено отключение формирования задач с категорией «Автосмена ТП».
Пример задачи:

https://bill.bezlimit.ru/task/task/view?id=8577943
Данная задача реализована по просьбе аналитического отдела.

134.12 Удалить из биллинга старую систему безнала.

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

134.13 Модернизация работы hot-billing`a.

В рамках данной задачи произведена оптимизация процесса и модернизирована процедура подгрузки hot-billing`a.
Задача носит технический характер, но сильно повлияет на работу. Пользователи и операторы смогут получать более актуальную информацию по остаткам пакетов, а Биллиг будет защищен от дублирования записей хота.
Задача инициирована it отделом.

134.14 Автоматизация загрузки выручки/Спорт Мобайл, Альгена.

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

134.15 Полный отказ от модели app\models\Phone.

В ходе работы над этой задачей была проведена оптимизация приложения Биллинга на уровне моделей.
Была удалена старая, редко используемая модель Phone.
Все вызовы этой модели в рамках задачи были изменены на основной пакет моделей base models.
Задача носит технический характер, была инициирована it отделом.

134.16 Отображение остатков USSD и LK.

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

Проверка производилась по получаемой информации по USSD запросу: *966*99#

И получаемой информации в ЛК Безлимит на номере: 9685911112.

В ходе тестирования задачи выявлены ошибки из-за которых передача информации по расходу трафика производилась некорректно. Данные ошибки были устранены в рамках масштабной задачи по модернизации hot-billing'a.
Теперь передача информации по пакетам будет подтягиваться в течении 3х часов с момента расхода трафика.

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

134.17 Сервис переводов (Безлимит ЛК).

В рамках данной задачи произведено добавление сервиса переводов TranslationService, данный сервис подключен GetMaterialApp(translations: TranslationService())
В данный момент предусмотрена поддержка.
Произведена поддержка русского и английского языка.
Задача инициирована it отделом в рамках масштабного проекта нового приложения "Безлимит ЛК".

134.18 Реализация состояний GoldButton (Безлимит ЛК).

Для виджета кнопок - GoldButton реализованы следующая состояния:

• Active - состояние по умолчанию.
• Loading - используется для загрузки данных.
• Disabled - неактивная кнопка серого цвета.

Задача инициирована it отделом в рамках масштабного проекта нового приложения "Безлимит ЛК".

134.19 Подключение сервиса логирования sentry (Безлимит ЛК).

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

Задача инициирована it отделом в рамках масштабного проекта нового приложения "Безлимит ЛК".

134.20 Реализация стартового экрана (Безлимит ЛК).

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

Задача инициирована it отделом в рамках масштабного проекта нового приложения "Безлимит ЛК".

134.21 Проверка регистрации номера (Безлимит ЛК).

Выявлена ошибка в заголовке при использовании api запросов через postman.
Ошибка вызвана в некорректном получении информация о регистрации пользователя в новом Личном Кабинете Безлимит.
Для исправления данной ошибки произведена масштабная работа по корректировке получаемой информации.

Задача инициирована it отделом в рамках масштабного проекта нового приложения "Безлимит ЛК".

134.22 Подтягивать входы/выходы из Perco в Битрикс.

В рамках большой задачи по синхронизации системы учёта рабочего времени «Time-Keeper» с помощью считывателя отпечатка пальцев «Perco» и Битрикс, был реализован следующий функционал:

1. Осуществлена привязка сотрудников в Битрикс к системам Perco Ульяновска и Москвы. Для этого, в профиле каждого сотрудника добавлено два новых поля с ID Perco:
- «Аккаунт таймкипера Ульяновск»;
- «Аккаунт таймкипера Москва»;
Одновременно у одного сотрудника может быть два аккаунта (может работать на два офиса).

2. Настроена передача информации по API из Perco в Битрикс о входах и выходах сотрудников.

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

Битрикс отправляет запрос в Perco 1 раз в минуту, опрашиваем 2 аккаунта Perco (2 разных запроса). На основании этих данных, проверяем соответствие в своих полях (2 поля у пользователя, их ID), находим если соответствие проставляем время начала, все остальное описано ниже.

3. Настроена синхронизация времени у сотрудников в зависимости от принадлежности сотрудника к офису (Ульяновск/Москва). То есть, проведена настройка согласно часовым поясам.

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

Дополнительно. Для сотрудников с «Совмещенным графиком» реализован следующий функционал.

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

5. Сотрудник пришел на работу, программа автоматически начинает рабочий день.

Если сотрудник совершил выход из офиса в рамках своего рабочего графика проставляется «перерыв».

В случае если сотрудник вышел из офиса в рамках своего рабочего графика и не зашел в течении 1,5 часов, изменяется «перерыв» на «завершить рабочий день» и фиксируется время, когда сотрудник вышел из офиса как «окончание рабочего дня».

В случае если сотрудник вернулся через 1 час 30 мин 01 сек и более в рамках своего графика, то проставляется «продолжить рабочий день».

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

6. Осуществлена синхронизация данных входов и выходов из Perco к рабочему расписанию сотрудников.

7. Входы/выходы/перерывы фиксируются во вкладке «рабочее время» с возможностью отображения статистики и начала/завершения рабочего дня.

https://bbezlimit.ru/timeman/timeman.php

8. Дополнили список инфоблоков дополнительными событиями: «Опоздание», «Прогул», «Ранний уход», «Недоработка».

8.1  «Опоздание»

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

Пример. У сотрудника рабочее время в смене указано с 09:00-20:00. Сотрудник пришел в 09:17, зафиксировано опоздание.

8.2  «Прогул»

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

Пример. У сотрудника смена с 12:00, он пришел в 17:01.

8.3  «Ранний уход»

Если сотрудник ушел ранее положенного времени, указанного в графике, фиксируется данная информация в график отсутствия, как событие «Ранний уход».

Пример. У сотрудника стоит смена с 09:00-20:00, перерыв 60 мин. Сотрудник пришел в 08:55, вышел из офиса в 19:55, время перерыва 40 мин. Данное событие является «Ранним уходом», потому как время прихода и время перерыва не учитывается (не перекрывает время недоработки при уходе).

8.4  «Опоздание» и «Ранний уход»

Если сотрудник опоздал больше, чем на 15 мин (>15, то есть от 16) от времени, указанного у него в смене, и ушел раньше положенного времени, то фиксируются 2 события: «Опоздание» и «Ранний уход».

Пример. У сотрудника стоит смена с 09:00-20:00, перерыв 60 мин. Сотрудник пришел в 09:25, вышел из офиса в 19:55, время перерыва 40 мин.

8.5  «Недоработка»

Если сотрудник недоработал с учётом своего графика и положенного перерыва, то фиксируется событие «Недоработка».

Пример.Рабочий день сотрудника с 10:00 до 19:00, время перерыва 1 час. Сотрудник пришел в офис в 09:30 и ушел из офиса в 19:30, при этом общее время перерыва сотрудника в рамках его рабочего дня 2:30, т.е. по факту он не доработал 1 час.
Перерыв 2.3 - 1 час = 1.3.

8.6  «Опоздание» и «Недоработка»

Если сотрудник недоработал с учётом своего графика, положенного перерыва, а также опоздал, то фиксируется 2 события «Опоздание» и «Недоработка».

Пример. Рабочий день сотрудника с 10:00 до 19:00, время перерыва 1 час. Сотрудник пришел в офис в 10:16 и ушел из офиса в 19:30, при этом общее время перерыва сотрудника в рамках его рабочего дня 2:30, т.е. по факту он не доработал 1 час 16 мин.

По факту он не доработал 1 час 46 мин.

8.7  «Недоработка» и «Ранний уход»

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

Пример. Рабочий день сотрудника с 10:00 до 19:00, время перерыва 1 час. Сотрудник пришел в офис в 09:55 и ушел из офиса в 18:30, при этом общее время перерыва сотрудника в рамках его рабочего дня 40 мин, т.е. по факту он не доработал 10 мин.

8.8  «Опоздание», «Недоработка» и «Ранний уход»

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

Пример. Рабочая смена сотрудника с 09:00 до 21:00, сотрудник пришел в офис в 09:17, общее время перерыва было 38 мин, так же он завершил свой рабочий день в 20:45, таким образом получаем, что сотрудник не отработал достаточное количество часов (т.е. был вне офиса 70 мин, вместо положенных 60 мин).

8.9  Дополнительный функционал по событию «Недоработка»

Если сотрудник пришел в офис, но при уходе с работы не отметился, то в 23:55 фиксируется, что сотрудник закончил рабочий день раньше своего времени на 2 часа и проставляем событие «Недоработка».

Уточнения. Примеры, когда не фиксируются события:

Пример. График сотрудника с 10:00 до 19:00, перерыв 60мин. Сотрудник пришел в офис в 09:30, вышел из офиса в 19:00. Сделал перерыв с 09:40 до 09:55. Сделал перерыв с 13:00-14:00. Общее время отсутствия в офисе 75мин. Хотя в рамках рабочего графика отсутствовал 60 мин. Ни одно событие не фиксируется.

Пример. График сотрудника с 10:00 до 19:00, перерыв 60мин. Сотрудник пришел в офис в 10:00 вышел из офиса в 19:20. В рамках рабочего дня выходил 2 раза:

- 1-й первый перерыв 60 мин.

- 2-й перерыв 20 мин.

Общее время перерыва 80 мин. Но при этом сотрудник отработал лишние 20 мин после своего времени, указанного в графика. Ни одно событие не фиксируется.События, описанные в пункте 8 фиксируются в график отсутствия: https://bbezlimit.ru/timeman/?login=yes#AP:month|1622494800000|1625086800000

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

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

134.23 Обновить/поменять стадию на "падший" блокированных дилеров.

В связи с разблокировкой Чеченской Республики были восстановлены заблокированные дилеры в «Суперворонке».

У дилеров с признаком "Блокировка ЧР" обновлён статус в Битриксе в статусе "Падший"в воронке «Суперворонка» на "Падший" обновлено около 7000 сделок. Дилеры, попавшие в статус "под удаление" перенесены в статусы, в которых были ранее до того, как попали в статус "под удаление". Изменен статус на 3600 сделках.

134.24 Провести сверку дилеров со Store.

Проведена сверка дилеров в Битриксе с дилерами в Store на предмет отсутствия.

В Битриксе отсутствовало 162 кабинета дилеров. По этим кабинетам созданы сделки и контакты к ним, и добавлена между ними связь.

134.25 Возможность менять ссылки размещенных вакансий.

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

Периодически меняются ссылки на вакансии из-за новой публикации старой вакансии на hh.ru. Поэтому создан список вакансий со ссылками на вакансии в HH.ru для возможности редактирования отделом по работе с персоналом. Таким образом, SMS и письма кандидату будут отправляться с актуальной ссылкой.

Пример SMS:

134.26 Дубли URL Блога.

На официальном сайте «Безлимит» в разделе «Блог», страница https://bezlimit.ru/blog/ , были удалены дубли блогов.

А также, убрали в адресе категории: после blog убрали /selection/.

К примеру:
Было - https://bezlimit.ru/blog/selection/top-5-onlayn-perevodchikov-2021-goda/ Стало - https://bezlimit.ru/blog/top-5-onlayn-perevodchikov-2021-goda/

134.27 Добавить соглашение на страницу "верификации".

На официальном сайте «Безлимит» в разделе «Верификация», страница https://bezlimit.ru/verification/ , добавлена фраза "Для внесения персональных данных подтвердите, что Вам есть 18 лет".

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

134.28 Восстановления поступления заказов ЧР в логистику.

В рамках данной задачи было восстановлено поступление заказов с Чеченской Республики в воронку «Логистика», которые ранее попадали в «Отказ».

134.29 Выявление потенциальных киберугроз и проблем безопасности компании.

Произведено поверхностное тестирование на проникновение и анализ защищенности следующих ресурсов компании:

1. 82.142.134.126 cloud.bezlimit.ru
2. 5.53.123.51 bbezlimit.ru
3. 144.76.27.214 bill.bezlimit.ru
4. 188.40.129.213 bez.li
5. 148.251.21.51 hot.bezlimit.ru
6. 138.197.183.217
7. 176.9.82.209 static.
8. 209.82.9.176.clients.your-server.de
9. 157.90.67.102 cc.bezlimit.ru
10. 157.90.70.114 static.
11. 114.70.90.157.clients.your-server.de
12. 157.90.67.99 static.
13. 99.67.90.157.clients.your-server.de
14. 168.119.140.62 static.
15. 62.140.119.168.clients.your-server.de
16. 168.119.140.62 static.
17. 62.140.119.168.clients.your-server.de
18. 157.90.67.100 static.
19. 100.67.90.157.clients.your-server.de
20. 82.142.134.126 cloud.bezlimit.ru

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

Network Infrastructure Security Assessment (Оценка безопасности сетевой Инфраструктуры)
Many supported Services: Target most common TCP/UDP services (HTTP, FTP, SSH, SMB, Oracle, MS-SQL, MySQL, PostgreSQL, VNC, etc.).
Combine Power of Tools: Each security check is performed by a tool from the toolbox. Attacks are performed by chaining security checks.
Context Awareness: Security checks to run are selected and adapted according to the context of the target (i.e. detected technologies, credentials, vulnerabilities, etc.).
Reconnaissance: Automatic fingerprinting (product detection) of targeted services is performed.
CVE Lookup (поиск уязвимостей в онлайновых базах данных CVE): When product names and their versions are detected, a vulnerability lookup is performed on online CVE databases (using Vulners & CVE Details).
Vulnerability Scanning: Automatically check for common vulnerabilities and attempt to perform some exploitations (auto-pwn).
Brute-force Attack: Automatically check for default/common credentials on the service and perform dictionnary attack if necessary. Wordlists are optimized according to the targeted services.
Post-authentication Testing: Automatically perform some post-exploitation checks when valid credentials have been found.
Web Security Assessment
Large Focus on HTTP: More than 60 different security checks targeting HTTP supported for now.
Web Technologies Detection: Fingerprinting engine based on Wappalyzer is run prior to security checks, allowing to detect: Programming language, Framework, JS library, CMS, Web & Application Server.
Server Exploitation (Уязвимость серверов): Automatically scan and/or exploit most critical vulnerabilities (e.g. RCE) on web and application servers (e.g. JBoss, Tomcat, Weblogic, Websphere, Jenkins, etc.).
CMS Vulnerability Scanning: Automatically run vulnerability scanners on most common CMS (Wordpress, Drupal, Joomla, etc.).

В ходе тестирования критических уязвимостей не найдено.

134.30 Дорожная карта по информационной безопасности компании.

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

134.31 Система Мониторинга.

Произведена установка и настройка системы мониторинга Zabbix 5.4 (http://mon.bezlimit.lan) + Grafana (http://mon.bezlimit.lan:3000) система визуализации установлены и базово настроены.

134.32 Настройка резервного копирования на сервере Битрикс.

В настройках Администрирования Битрикс изменены планы резервного копирования,
Исключили директорию /upload/voximplant/ из резервного копирования, что позволило сократить размер резервных копий на 200 гб. Теперь каждая копия весит в среднем 65 Гб. Резервирование выполняются регулярно, через день.

134.33 Внешние хранилища для оптимизации Битрикса.

Перенесены записи звонков из битрикса на хранилище storageb.bezlimit.lan, что позволило разгрузить и оптимизировать файловую систему сервера Битрикс. Улучшена производительность сервера.

134.34 Метод аторизации.

В рамках перехода на новую техническую платформу ОСАГО получен токен авторизации для интеграции с платформой. Используя описанные в документации методы API по авторизации произведено подключение методов к нашему ресурсу на тестовой платформе.

134.35 Метод получения бренда авто.

Используя описанные в документации методы API по получению бренда (марки) автомобиля произведено подключение данных методов к нашему ресурсу используя внутренние параметры системы.

134.36 Метод получения модели автомобиля.

Используя описанные в документации методы API по получению модели ТС по признаку «BrandID” автомобиля произведено подключение методов к нашему ресурсу

134.37 Метод получения по гос.номеру.

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

134.38 Предварительный расчет полиса ОСАГО.

Произведено обновление метода «предварительного расчета ОСАГО под актуальные параметры используемых систем. Настроена интеграция с нашей системой.

134.39 Новое условие при внесении обещанного платежа.

Теперь, если у пользователя не внесены паспортные данные на номере, при запросе «обещанного платежа» USSD командой или в IVR меню, будет предоставляться уведомление следующего содержания – «Требуется предоставить паспортные данные!».
Если паспортные данные на номере внесены и подтверждены – «обещанный платёж» будет предоставлен.
Реализация данной задачи позволяет ускорить сбор паспортных данных.
Задача реализована по запросу отдела Сервиса.