По вашему запросу ничего не найдено :(
Убедитесь, что запрос написан правильно, или посмотрите другие
наши статьи:
Вопросы безопасности преследовали Интернет вещей (Internet of Things) с самого момента изобретения. Все, от поставщиков до корпоративных пользователей и потребителей, обеспокоены тем, что их модные новые устройства и системы IoT могут быть скомпрометированы. Проблема на самом деле еще хуже, поскольку уязвимые устройства IoT могут быть взломаны и использованы в гигантских ботнетах, которые угрожают даже правильно защищенным сетям.
Но каких именно проблем и уязвимостей следует избегать при создании, развертывании или управлении системами IoT? И, что более важно, что мы можем сделать, чтобы смягчить эти проблемы?
Именно здесь вступает в действие OWASP (Open Web Application Security Project) - проект обеспечения безопасности открытых веб-приложений. По его собственным словам, «Проект Интернета вещей OWASP призван помочь производителям, разработчикам и потребителям лучше понять проблемы безопасности, связанные с Интернетом вещей, и позволяют пользователям в любом контексте принимать более обоснованные решения в области безопасности при создании, развертывании или оценке технологий IoT».
Давайте рассмотрим топ 10 уязвимостей интернета вещей.
1.Слабые, угадываемые или жестко заданные пароли
Использование легко взламываемых, общедоступных или неизменяемых учетных данных, включая бэкдоры во встроенном программном обеспечении или клиентском программном обеспечении, которое предоставляет несанкционированный доступ к развернутым системам.
Эта проблема настолько очевидна, что трудно поверить, что это все еще то, о чем мы должны думать.
2. Небезопасные сетевые сервисы
Ненужные или небезопасные сетевые службы, работающие на самом устройстве, особенно те, которые подключены к Интернету, которые ставят под угрозу конфиденциальность, целостность или подлинность или доступность информации или допускают несанкционированное удаленное управление.
3. Небезопасные экосистемные интерфейсы
Небезопасный веб-интерфейс, API бэкэнда, облачные или мобильные интерфейсы в экосистеме вне устройства, что позволяет компрометировать устройство или связанные с ним компоненты. Общие проблемы включают в себя отсутствие аутентификации или авторизации, отсутствие или слабое шифрование, а также отсутствие фильтрации ввода и вывода.
4. Отсутствие безопасных механизмов обновления
Отсутствие возможности безопасного обновления устройства. Это включает в себя отсутствие проверки прошивки на устройстве, отсутствие безопасной доставки (без шифрования при передаче), отсутствие механизмов предотвращения отката и отсутствие уведомлений об изменениях безопасности из-за обновлений.
Это постоянная проблема для приложений IoT, так как многие производители и предприятия не заботятся о будущем своих устройств и реализаций. Кроме того, это не всегда технологическая проблема. В некоторых случаях физическое расположение устройств IoT делает обновление - и ремонт или замену - серьезной проблемой.
5. Использование небезопасных или устаревших компонентов
Использование устаревших или небезопасных программных компонентов или библиотек, которые могут позволить скомпрометировать устройство. Это включает небезопасную настройку платформ операционной системы и использование сторонних программных или аппаратных компонентов из скомпрометированной цепочки поставок.
6. Недостаточная защита конфиденциальности
Личная информация пользователя, хранящаяся на устройстве или в экосистеме, которая используется небезопасно, ненадлежащим образом или без разрешения.
Очевидно, что с личной информацией нужно обращаться соответствующим образом. Но ключом здесь является «разрешение». Вы почти ничего не делаете с личной информацией, если у вас нет на это разрешения.
7. Небезопасная передача и хранение данных
Отсутствие шифрования или контроля доступа к конфиденциальным данным в любой точке экосистемы, в том числе в состоянии покоя, передачи или во время обработки.
В то время как многие поставщики IoT обращают внимание на безопасное хранение, обеспечение безопасности данных во время передачи слишком часто игнорируется.
8. Ограниченное управление устройством
Отсутствие поддержки безопасности на устройствах, развернутых в производстве, включая управление активами, управление обновлениями, безопасный вывод из эксплуатации, мониторинг систем и возможности реагирования.
Устройства IoT могут быть небольшими, недорогими и развернутыми в большом количестве, но это не означает, что вам не нужно ими управлять. Фактически, это делает управление ими более важным, чем когда-либо. Даже если это не всегда легко, дешево или удобно.
9. Небезопасные настройки по умолчанию
Устройства или системы поставляются с небезопасными настройками по умолчанию или не имеют возможности сделать систему более безопасной, ограничивая операторов от изменения конфигурации.
10. Отсутствие физического доступа
Отсутствие мер по физической защите, позволяющих потенциальным злоумышленникам получать конфиденциальную информацию, которая может помочь в будущей удаленной атаке или получить локальный контроль над устройством.
Что из этого следует?
Интернет вещей уже давно стал частью реальности, и с ним нельзя забывать о безопасности. И вопросы безопасности должны ложиться не только на плечи производителей, но и на плечи администраторов и обычных пользователей.
Такие большие, логически структурированные массивы, как базы данных, совершенно бессмысленны без систем управления реляционными данными (РСУБД). РСУБД – это программное решение, позволяющее взаимодействовать с базой данных (БД). Вы можете получать, добавлять или удалять данные, а также управлять доступом к хранимой информации.
На рынке существует множество программных вариантов, и большинство из них распространяется с открытым исходным кодом, то есть бесплатно. Самыми известными решениями для веб-серверов являются MySQL и PostgreSQL. Выбор одного из вариантов зависит от ваших требований к рабочей нагрузке и назначению БД.
В данной статье рассматриваются основные различия MySQL и PostgreSQL и приводится их подробное сравнение.
Краткий обзор MySQL и PostgreSQL
MySQL и PostgreSQL постоянно обновляются и улучшаются активным и изобретательным сообществом. Этот непрерывный процесс сокращает принципиальные отличия между двумя решениями.
Тем не менее, в них есть существенные различия, которые проявляются при развертывании с большой рабочей нагрузкой. Прежде, чем перейти к подробному анализу каждого решения, предлагаем ознакомиться с кратким сравнением систем.
MySQL
PostgreSQL
Предлагают как открытые, так и платные коммерческие версии.
Бесплатная, полностью с открытым кодом.
Очень быстрые и надежные.
Адаптивная и многофункциональная.
Делают акцент на скорости, а не следовании ключевым принципам SQL
Придерживается 160 из 179 обязательных пунктов ключевых принципов и стандартов SQL.
Идеальна для рабочих процессов в веб-решениях с интенсивным чтением данных.
Идеальна для сложных запросов и больших баз данных.
Темп разработки замедлился после того, как система стала частично проприетарным решением.
Активное и многочисленное сообщество постоянно разрабатывает новые функции.
MySQL возлагает функции безопасности на списки управления доступом (ACL).
В PostgreSQL есть встроенная поддержка SSL и возможность шифрования связи между клиентом и сервером.
Поддерживает управление параллельным доступом посредством многоверсионности (MVCC), но при условии, что оно поддерживается подсистемой хранения InnoDB
Встроенная реализация MVCC.
Стандартная репликация master-standby
Несколько вариантов репликации
Небольшая поддержка нереляционных функций
Поддержка нескольких нереляционных функций
Версия InnoDB совместима с ACID (атомарность, согласованность, изолированность, прочность)
Полная совместимость с ACID
Ограниченная поддержка расширяемости
Возможность добавления новых функций, типов, индексных типов и т.д.
По умолчанию добавлены геопространственные данные
Возможность реализации геопространственных данных через расширения
Ограниченная поддержка серверного программирования на нерасширяемом языке
PostgreSQL поддерживает самые популярные языки программирования
Поддерживает развертывание в контейнерах Docker
Поддерживает развертывание в контейнерах Docker
Сравнение производительности MySQL и PostgreSQL
Измерение производительности РСУБД во многом зависит от требований, предъявляемых к базе данных. В базовых примерах обе системы управления БД работают одинаково хорошо.
Производительность и скорость:
PostgreSQL создавался для выполнения сложных операций; он совместим с множеством платформ и языков
MQL не стремился следовать всем стандартам SQL, поэтому основной упор делается на скорость
Основной упор в PostgreSQL сделан на совместимости; система показала превосходные результаты при использовании в сложных запросах, анализе чтения/записи, а также управления большими базами данных. Важно помнить, что PostgreSQL может серьезно повлиять на производительность памяти, поскольку каждое новое клиентское подключение создает отдельные ветку процесса весом в 10 МБ.
MySQL ставил перед собой цель достичь максимальной скорости и простоты развертывания. Эта характеристика MySQL особенно полезна при простом обмене информации и рабочих процессах в веб-решениях с интенсивным чтением данных. Простота развертывания БД означает, что вы можете пользоваться MySQL для быстрого и горизонтального масштабирования данных.
Лицензия и поддержка сообщества
PostgreSQL – это бесплатное решение с полностью открытым исходным кодом. Лицензия Open Source означает, что исходный код находится в открытом доступе; кто угодно может его копировать, изменять и распространять.
Такая схема создала активное сообщество разработчиков, которое постоянно анализирует текущее состояние системы и разрабатывает новые, улучшенные решения.
MySQL доступна в бесплатном доступе с открытым кодом, а также в нескольких платных коммерческих версиях с проприетарной лицензией. Некоторые элементы и плагины доступны только в проприетарных версиях, что в итоге может приводить к дополнительным затратам.
Кроме того, люди жалуются, что процесс разработки слегка замедлился, поскольку после покупки компанией Oracle, MySQL перестал быть системой с полностью открытым кодом.
Соответствие SQL
Современные приложения и базы данных часто имеют распределенную архитектуру. Следование официальным стандартам и руководствам SQL упрощает обмен данными между различными БД и помогает им соответствовать строгим регуляторным требованиям (например, GDPR, PCI и ISO).
Соответствие SQL-стандартам:
MySQL сосредоточена на увеличении скорости и надежности. В итоге MySQL не до конца соответствует стандартам ISO
PostgreSQL придерживается большей части основных принципов и стандартов SQL; это портативная система, с которой легко интегрируются различные инструменты
PostgreSQL и MySQL: синтаксические отличия
MySQL и PostgreSQL основаны на одних и тех же стандартах SQL и активно пытаются следовать максимально возможному количеству требований. Так что синтаксис и команды в двух РСУБД практически одинаковы. Давайте рассмотрим несколько основных отличий, которые могут сказаться на управлении данными.
Синтаксис PostgreSQL
Синтаксис MySQL
Данные из таблицы чувствительны к регистру. WHERE Company = ‘Merion’ это не то же самое, что WHERE Company = ‘merion’
Данные не чувствительны к регистру. WHERE Company = ‘Merion’ – это то же самое, что и WHERE Company = ‘merion’
PostgreSQL допускает использование только одиночных кавычек: Company = ‘merion’
Поддерживает одиночные и двойные кавычки: Company = ‘merion’, равно как и Company = “merion”
Команды для даты и времени: CURDATE(), CURTIME(), EXTRACT()
Команды для даты и времени: CURRENT_DATE(), CURRENT_TIME(), EXTRACT()
Отличия в безопасности PostgreSQL и MySQL
Необходимость защиты баз данных в РСУБД от вредоносной активности привела к созданию множества инструментов, протоколов безопасности и процедур.
Главную функцию безопасности в MySQL выполняют списки управления доступом (ACL).
В PostgreSQL встроена поддержка SSL, а для настройки разрешений пользователей используется функция ROLE.
MySQL возлагает функцию безопасности на списки управления доступом (Access Control Lists - ACL), которые следят за всеми подключениями, запросами и другими операциями. Кроме того, предоставляется ограниченная поддержка подключений между MySQL-клиентами и серверами с SSL-шифрованием.
Например, в MySQL есть сценарий, который повышает безопасность вашей БД за счет настройки пароля для пользователя root. Этот же сценарий автоматически удаляет все стандартные тестовые базы данных из вашей системы. Кроме того, MySQL поддерживает управление пользователями и позволяет настраивать уровни доступа для каждого пользователя.
Для настройки разрешений пользователей PostgreSQL использует функцию ROLE. В ней есть встроенная поддержка SSL и шифрование обмена данными между клиентом и сервером. PostgreSQL также предлагает встроенное расширение под названием SE-PostgreSQL для настройки дополнительных элементов контроля доступа в соответствии с политикой безопасности SELinux.
Удобство для пользователей и универсальность интерфейса
Пользовательский интерфейс в PostgreSQL называется pgAdmin4. Он помогает начинающим пользователям выполнять сложные задачи и управлять базами данных. Основной акцент в PostgreSQL сделан на расширяемости, поэтому вы можете использовать pgAdmin4 для добавления новых типов данных, функций и типов индексов.
Графический пользовательский интерфейс в MySQL называется Workbench. Этот инструмент объединяет в себе разработку, управление, проектирование, создание и поддержание базы данных в единую интегрированную среду СУБД MySQL.
Языки программирования
Один из важнейших аспектов, которые необходимо учитывать при переходе на новую среду, заключается в том, как это повлияет на сотрудников из отдела разработки и эксплуатации. Чем больше языков программирования поддерживает сервер базы данных, тем легче разработчикам добавлять новые функции и улучшать уже существующие.
В этом плане PostgreSQL и MySQL поддерживает большое количество языков программирования.
PostgreSQL
MySQL
C++, .NET, Java, Delphi, Perl, Lua, Node.js, Python, PHP, R, D, Erlang, Go, Lisp
C, C++, Java, Perl, Delphi, Lua, Go, R, .NET, Node.js, Python, PHP, Erlang, Lisp, D
Параллельная обработка данных
Хорошо реализованный параллелизм позволяет многим людям из разных мест одновременно обращаться к БД и работать с ней без ограничений и угрозы противоречивости данных.
Когда базе данных с управлением параллельным доступом посредством многоверсионности (MVCC - multi-versioning concurrency control) необходимо обновить данные, она не перезаписывает оригинальную информацию. Вместо этого она создает более свежую версию файла и сохраняет ее предыдущую копию.
Это принципиально важный момент, если к вашим наборам данных одновременно должны обращаться многие подписчики. Если в системе отсутствует контроль параллельной обработки данных, то чтение из БД, пока другой процесс записывает в нее данные, приводит к несогласованности данных.
Встроенная реализация MVCC позволяет достичь высочайшего уровня параллелизма в PostgreSQ
MySQL тоже предлагает поддержку MVCC, но только если она поддерживается подсистемой хранилища InnoDB.
Репликация базы данных
Копирование данных из одного сервера БД в другую базу на другом сервере называется репликацией. При таком распределении информации группа пользователей сможет обращаться к новым данным, и это никак помешает работе других пользователей.
Одной из самых сложных задач в репликации БД является поддержание согласованности данных внутри распределенной системы. MySQL и PostgreSQL предлагают различные возможности для репликации БД.
PostgreSQL и MySQL поддерживают репликацию в виде master – standby (основной источник – резервная БД) и нескольких standby, а также предлагают ряд возможностей:
PostgreSQL:
логическая репликация;
потоковая репликация;
двунаправленная репликация.
MySQL:
репликация master – master;
master – standby, перенаправленная на один или несколько резервных серверов;
круговая репликация.
Заключение
PostgreSQL – это многофункциональная БД для обработки сложных запросов и больших баз данных. MySQL – это быстрое, надежное и популярное решение. MySQL относительно прост в установке и обслуживании. Функциональные возможности PostgreSQL и MySQL во многом схожи.
PostgreSQL отличается от MySQL по определенным рабочим нагрузкам. Данная статья поможет вам принять осмысленное решение с учетом всех достоинств той или иной РСУБД.
Система автоматического исходящего обзвона – это программное обеспечение, с помощью которого любой Call-центр может в разы сократить время и затраты на исходящий обзвон. Существует 4 основных способа организовать обзвон списка номеров:
ручной набор - оператор делает набор вручную. Это неэффективное расходование времени оператора (набор номер, писк контакта в базе и так далее);
preview – диалер загружает списки контактов, в которых оператор заранее видит информацию по каждому клиенту и принимает решение о звонке самостоятельно. При этом, он не набирает номер телефона и не снимает трубку до того момента, как абонент ответит на звонок;
progressive – так же, как и в preview загружаются списки контактов, но в этом варианте у оператора нет возможности отказаться от внешнего звонка. Диалер стремится занять звонками максимальное количество доступных каналов. Это подходит для автоматических извещений, IVR (когда вызываемого абонента нужно подключить на интерактивное меню) и прозвона номеров;
predictive dialer – самое интересное. При предиктивном дозвоне используются сложные сценарии и реальный математический расчет. Dialer предназначен для максимального сокращения времени ожидания оператором звонка при минимальных потерях успешных звонков. Для этого используются алгоритмы, «просчитывающие» необходимое количество звонков в следующий момент на основании данных о количестве операторов, которые будут доступны на момент соединения, о средней длительности разговора (ACD), о проценте успешных соединений (ASR) и прочих. У каждого продукта данные секретны и не публичны :).
Хочу презентацию продукта!
Программный продукт IqDialer
В качестве основной телекоммуникационной платформы для IqDialer был выбран Asterisk. Дайлер кроссфункционален и стабилен – он справляется с разными задачами, а его надежность протестирована в десятках инсталляций. Все функциональные возможности диалера (интеграция с внешними компонентами, CRM, например) управляются посредством RESTful API.
Работает это примерно так: устанавливается и настраивается оборудование, необходимое для начала работы Call-центра, затем загружается база контактов для обзвона, и операторы входят в систему, занимая свои виртуальные рабочие места и вставая в очередь на телефонии. IqDialer определяет доступные ресурсы для работы, и в этот момент программа начинает расчеты, запрашивает статистику звонков, рассчитывает, сколько нужно взять лидов (контактов для обзвона), занимает расчетное количество операторов, трансформирует лиды в звонки и отправляет все на телефонию. Первый этап закончен :)
В следующем этапе звонки, попавшие в телефонию, при дозвоне до клиента попадают в очередь и диалер собирает всю доступную ему информацию о звонке. На основании собранной информации программа отправляет карточки лидов операторам, и те видят на своих экранах всю информацию по контакту и обрабатывают звонок в соответствии с поставленной задачей. На последнем этапе по завершению звонка, оператор дополнительно обрабатывает карточку лида, сохраняя ее (срабатывает интеграция CRM и диалера) дает понять системе сколько длилась дообработка и что оператор готов принять новые вызовы (освобождается в очереди). Система обрабатывает завершенный звонок, производя манипуляции с лидом, меняет его статус и создает задачи для пропущенного звонка.
«Под капотом» это выглядит примерно так:
Время статистики. Для сравнения эффективности различных режимов набора, мы возьмем 3 (три) самых распространенных варианта обзвона (Preview, Progressive и Predictive), которые практикуют Call - центры, и для примера возьмем Call – центр, где один оператор работает 5 дней в неделю, по 8 часов в день:
Действие
Preview
Progressive
Predictive
Поиск карточки клиента (сек)
0
0
0
Ознакомление с карточкой клиента (сек)
10
0
0
Набор номера (сек)
0
0
0
Дозвон (сек)
20
20
0
Занятость оператора в разговоре (сек)
90
90
90
Всего времени на звонок (сек)
120
110
90
Звонков в день
240
262
320
Формула получения звонков в день и месяц
8*60*60/120240*22
8*60*60/110262*22
8*60*60/90320*22
Звонков в месяц
5280
5764
7040
Если привести здесь в качестве примера статистику, учитывающую еще и ручной набор, то результатом сравнения будет превосходство предиктивного набора над ручным почти в 2 раза. Даже при таком простом анализе, который не учитывает множество дополнительных факторов и полностью исключает сравнение с ручным набором оператором телефонных номеров, очевидна выгода :)
Таким образом, основываясь на вышесказанном, любой Call - центр просто обязан использовать только Predictive (предиктивный) Dialer. Однако не все так просто. Этот режим эффективен в том случае, если число работающих операторов не опускается ниже 20–30. В противном случае predictive dialing вместо пользы будет приносить только вред.
Смешанный режим работы оператора
В работе каждого Call - центра случаются временное затишье или резкий всплеск количества обращений, которые тяжело прогнозировать. В такой ситуации действенным инструментом поддержания необходимого и достаточного уровня сервиса могут стать работа в смешанном режиме – blended Agent. Смешанный режим позволяет оператору обрабатывать входящие и исходящие обращения по различным каналам коммуникаций в рамках единой очереди.
Чтобы проиллюстрировать выгоду, полученную при добавлении исходящих звонков в кейс (рабочие задачи) оператора, можно привести такой пример: допустим, операторы принимают только входящие звонки и при этом в течение одного рабочего дня простаивают 20% своего времени. Тогда в течение дня оператор не работает (8*60*0.2) = 96 минут. Пусть в Call - центре работает 10 операторов, тогда легко вычислить, что колл-центр уже простаивает (96*10/60) = 16 часов в день , а в месяц уже (16*22) = 352 человеко-часа.
При этом, у колл-центра могут быть заказы на проведение опросов (исходящая кампания на обзвон), и во время простоя оператору будут подмешиваться звонки с опросами. Производительность и качество обслуживание входящих звонков останутся на должном уровне, а Call - центр получит дополнительную прибыль.
Есть определенные тонкости, которые необходимо учитывать при планировании кампаний исходящего обзвона и входящих звонков, дело в том, что смешанный колл-центр будет эффективно работать только в режимах preview и progressive. Поскольку режим predictive подразумевает 100% занятость и любые отвлечения оператора приведут к потерям клиентов.
IqDialer: интерфейс и как он выглядит
Посмотрите, как выглядит дашборд супервизора, который следит за компаниями исходящего обзвона:
Двигаемся к отчетности – ниже отчет агентов по статусам (включает круговую диаграмму):
Заказать продукт
Отчеты реального времени – кто говорит, сколько времени:
Можно посмотреть самую важную информацию по каждой очереди:
Тайм – лайны! Смотрим, что делал наш агент на протяжении отрезка времени – звони, говорил, делал пост – ворк (работа после звонка) и так далее:
Интересен продукт? Напишите нам на dialer@merionet.ru