пїЅпїЅпїЅпїЅпїЅпїЅпїЅпїЅпїЅпїЅпїЅпїЅпїЅпїЅ пїЅпїЅпїЅпїЅпїЅпїЅпїЅпїЅпїЅпїЅпїЅпїЅ
Слишком длинный поисковый запрос.
По вашему запросу ничего не найдено :(
Убедитесь, что запрос написан правильно, или посмотрите другие
наши статьи:
Мы продолжаем изучать один из важнейших протоколов IP телефонии H.323 и в сегодняшней статье рассмотрим возможные сценарии установления соединения, а также углубимся в суть сигнальных сообщений, использующихся в данном протоколе.
Итак, что же происходит прежде чем Вы слышите в трубке голос собеседника, когда соединяетесь по H.323?
Давайте рассмотрим временную диаграмму установления и разъединения связи между парой терминалов под управлением привратника. Для простоты восприятия, сигнальные сообщения протоколов выделены разными цветами.
Как видно из диаграммы на первом этапе установления соединения (SETUP) работают протоколы RAS (Registration, Admission, Status) и H.225.0 .
Терминал 1 по протоколу RAS посылает Привратнику сообщение ARQ (Admission Request), которое содержит информацию о вызываемом абоненте и требования к пропускной способности будущей сессии. Привратник отвечает сообщением ACF (Admission Confirmation), содержащее номер порта TCP для будущего сигнального канала.
Получив номер порта, Терминал 1 инициирует установление TCP-сессии, и, по протоколу H.225.0, посылает сообщение SETUP Терминалу 2. Стоит напомнить, что SETUP, как и все остальные сообщения протокола H.225.0, является разрешенным для использования в VoIP сообщением протокола Q.931, использующегося в ISDN.
SETUP содержит такую информацию как IP адрес, порт и alias, вызываемого абонента. Alias – это адрес по формату напоминающий e-mail адрес, в первой части которого находится уникальный идентификатор терминала, а во второй имя домена, которому он принадлежит, например: alex@merionet.ru или 192.168.1.32@merionet.ru .
Терминал 2 отвечает сообщением CALL PROCEEDING, означающее, что все данные получены. Для того, что бы взаимодействовать с Привратником Терминал 2 также проходит процедуру регистрации, обмениваясь сообщениями ARQ и ACF. Наконец, по протоколу H.225 (Q.931 ) Терминал 2 посылает вызывающей стороне сообщение ALERTING. В этот момент вызывающий абонент слышит контроль посылки вызова.
Согласование
Далее начинается фаза согласования дополнительных параметров с использованием протокола H.245, информация которого передаются внутри сообщений FACILITY протокола H.225.0.
Протокол H.245 осуществляет следующие процедуры:
Определение ведущего и ведомого сессии (Master/Slave Determination).
Данное определение выявляет какой из терминалов будет решать потенциальные разногласия. Например в случае несогласования какого-либо параметра ведущий (Master) может этот параметр отклонить.
Согласование функциональных возможностей терминалов (Terminal Capability Set)
Терминалы обмениваются списком поддерживаемых аудио и видео кодеков. Ведущий выбирает по какому кодеку будет проходить вызов.
Открытие логических каналов (Open Logical Channel)
Окончательное согласование всех необходимых параметров будущей RTP – сессии перед ее непосредственным открытием.
После того как все параметры согласованы и абонент Терминала 2 принимает вызов, в сторону вызывающего терминала отсылается сообщение CONNECT. На этом фаза установления соединения заканчивается и начинается фаза разговора.
Между терминалами устанавливается RTP/RTCP – сессия и начинается обмен речевой информацией.
Далее абонент Терминала 2 инициирует завершение соединения, посылкой сообщений CloseLogicalChannel и EndSessionCommand, на что получает соответствующие CLC ACK и ESC ACK от Терминала 1. Далее по протоколу H.225.0 соединение закрывается окончательно сообщением RELEASE COMPLETE. Терминалы, по протоколу RAS, извещают Привратник об освобождении ресурсов сообщениями DRQ Disenagae Request. Привратник подтверждает освобождение полосы пропускания сообщением Disengage Confirmation.
H.323 был одним из первых протоколов IP – телефонии, поэтому понимание принципов его работы является крайне важным фактором при изучении более новых и современных протоколов VoIP.
Что такое SSO?
С помощью системы единого входа (SSO - single sign-on) клиенты могут получать доступ к различным сайтам и приложениям, используя всего один набор входных данных. SSO работает со стратегией подтверждения личности клиента. Это происходит, когда клиент входит в одну программу и сразу же получает доступ в других связанных приложениях. Различные имена пользователей и пароли теперь можно более эффективно отслеживать в различных учетных записях и ресурсах.
Удобно ведь, когда человек входит в Google, и его сертификаты за доли секунды подтверждаются в связанных ресурсах, включая Gmail и YouTube, без необходимости регистрации в каждой из них.
Токен SSO
Токеном системы единого входа (SSO Token) называется сбор информации или данных, которые отправляются с одной платформы на другую в процессе использования SSO. Это основополагающие данные такие, как адрес электронной почты клиента и сведения о системе, которая отправляет токен. Чтобы условный сборщик имел возможность подтвердить, что токен поступает из надежного источника, они должны быть строго промаркированы. В процессе настройки пересылается подтверждение надежности токена, используемого для этой маркировки.
Важность системы единого входа
SSO имеет важное значение в свете того факта, что постоянно растет количество ресурсов и учетных записей, доступ к которым клиентам необходимо контролировать, и каждый из этих ресурсов требует определенной степени безопасности, которая обычно обеспечивается с помощью комбинации имени пользователя и пароля. Тем не менее, руководителям и клиентам, которые стараются подобрать надежные пароли для нескольких учетных записей, может быть трудно упорядочить и работать с таким количеством учетных записей. Система единого входа поддерживает безопасный доступ к приложениям, унифицируя технику для руководителей и клиентов.
Процедура единого входа может выполняться с использованием различных методических инструкций, но все они соответствуют одной и то же базовой структуре. Важным аспектом является то, что они позволяют приложениям отдавать право подтверждения клиента другому приложению или администратору.
Этап SSO рассматривается как отдельное пространство, где можно работать лишь с идентификаторами клиентов.
Как работает SSO?
В основе лежат доверительные отношения между поставщиком услуг (Service Provider) – программой, и поставщиком удостоверений (Identity Provider) – например такой компанией, как OneLogin. Сертификат, которым обмениваются поставщик услуг и поставщик удостоверений, как правило, служит основой для этих самых доверительных отношений. Чтобы поставщик услуг знал, что идентификационная информация поступает из надежного источника, этот сертификат можно использовать для подписи этой идентификационной информации, которая передается от поставщика идентификационной информации поставщику услуг. В SSO эти идентификационные данные представляют собой токены, которые включают в себя идентифицирующие данные о человеке, такие как его адрес электронной почты или имя пользователя.
SSO работает на основе доверительных отношений, установленных между приложением, называемым поставщиком услуг, и поставщиком персональных данных, таким как OneLogin. Эти доверительные отношения часто основаны на положительном заключении, одобрении, которым обмениваются поставщик персональных данных и специализированная организация. Это одобрение можно использовать для подписи данных о пользователе, которые отправляются от поставщика персональных данных в специализированную организацию, чтобы поставщик услуг убедился в надежности источника данных. В SSO эта персональная информация отображается в виде токенов, которые содержат различимые фрагменты данных о клиенте, такие как адрес электронной почты клиента или имя пользователя.
Далее показано, как обычно происходит взаимодействие при входе в систему:
Клиент изучает программу или сайт – «поставщика услуг», к которому он хочет получить доступ.
Чтобы запросить проверку личности клиента у SSO, иначе называемой поставщиком удостоверений, поставщик услуг передает токен, который содержит некоторую информацию о клиенте, например, его адрес электронной почты.
Чтобы разрешить доступ к приложению поставщика услуг и сразу перейти к пункту 5, поставщик удостоверений должен для начала определить, проходил ли недавно клиент аналогичную проверку.
Если клиент этого еще не делал, ему будет предложено войти в систему, предоставив требуемые условия допуска поставщика удостоверений. Это может быть просто имя пользователя и пароль, или это может быть даже совсем другая стратегия подтверждения, например, одноразовый пароль.
Поставщик удостоверений отправляет обратно поставщику услуг символьные данные подтверждения фактической проверки каждый раз, когда он подтверждает отправленные сертификаты.
Программа клиента передает этот токен поставщику услуг.
Доверительные отношения, который были установлены между поставщиком услуг и поставщиком удостоверений во время основного соглашения, используются для утверждения пути проверки через символьные данные, полученные поставщиком услуг.
Специализированная организация (поставщик услуг) разрешает доступ клиента.
Новый сайт также должен иметь группу доверия, настроенную с механизмом SSO, и процесс проверки будет аналогичным, когда клиент попытается получить доступ к альтернативному сайту.
Типы конфигураций SSO
SAML - Открытый стандарт SAML (Security Access Markup Language) рассматривает обмен символьной информацией путем кодирования текста в машинный язык. На сегодняшний день SAML – один из основных принципов SSO, он помогает поставщикам приложений гарантировать правильность выполнения их требований проверки. Данные могут передаваться через интернет-браузер благодаря SAML 2.0, который был создан специально для использования в веб-приложениях.
OAuth - Компонент авторизации открытого стандарта, известный под названием oAuth, отправляет идентификационные данные между приложениями, используя шифрование машинного кода. Это особенно удобно для использования в локальных приложениях, поскольку позволяет клиентам разрешать доступ к своей информации, начиная с первого приложения, и далее в следующих приложениях, без необходимости подтверждать свою личность физически.
Kerberos - При неопределенной организации защиты клиент и сервер могут проверять личность друг друга, используя соглашение Kerberos. Клиенты и программирующие программы, такие как клиенты электронной почты или вики-серверы, проверяются с помощью пропускающего ресурса, который распространяет токены.
OIDC - OIDC расширяет OAuth 2.0 путем расширения возможности SSO и поддерживая явную информацию о клиенте. Это позволяет произвести однократную авторизацию для входа в систему для нескольких уникальных приложений. Например, позволяет клиентам входить в справочную систему, используя свою учетную запись Facebook или Google, а не вносить новую информацию в сертификат клиента.
Проверка подлинности смарт-карты - Помимо обычного SSO, существует также средства, поддерживающие подобный механизм. Модели устройств содержат устройства чтения карт, которые клиенты могут подключать к своим компьютерам. Для проверки личности клиента программа использует криптографические ключи, хранящиеся на карте. Карты должны находиться только у клиента во избежание утери. Их использование является дорогостоящим, независимо от того, являются ли они просто сами по себе безопасными или требуют PIN-код для работы.
Использование SAML и OAuth в SSO
Для проверки своей легитимности токены подтверждения используют рекомендации по обмену данными (переписке). SAML, который является языком для создания токенов подтверждения, является основной рекомендацией. XML используется в стандарте SAML для разрешения проверки личности клиента и передачи ему доступа, чтобы можно было связываться через зоны действия системы безопасности. SAML работает с перепиской между клиентом, SP и IdP при использовании его в SSO.
Данные клиентов должны безопасно предоставляться различным ресурсам с единственным входом в систему. Это становится возможным с OAuth, который позволяет различным внешним ресурсам использовать данные записи клиента. SP сообщает IdP о запросе клиента на доступ, который IdP затем проверяет и подтверждает, прежде чем предоставлять доступ клиенту. Решение зарегистрироваться на сайте, используя учебную запись Facebook, а не имя пользователя и пароль, является одним из примеров.
SSO может использоваться как для автономных соглашений OAuth, так и для SAML. В то время как SAML проверяет клиентов, OAuth используется для подтверждения доступа клиентов.
Преимущества и недостатки SSO
Преимущества:
Сокращение количества атак: SSO исключает возможность того, что закончатся пароли, а также правила подбора паролей, что делает организацию более защищенной от фишинга. Это исключает сбросы паролей, что является утомительным и дорогостоящим, и позволяет клиентам запоминать лишь один пароль.
Простой и безопасный клиентский доступ: SSO предоставляет организациям возможность оперативно получить информацию о том, какие клиенты, когда и откуда получили доступ к тем или иным приложениям, позволяя им тем самым защитить целостность своих инфраструктур. Механизмы SSO также могут справить с такими угрозами безопасности, как сбой рабочего устройства, позволяя IT-службам быстро блокировать доступ к учетным записям и важной информации на устройстве.
Улучшена оценка клиентского доступа. В постоянно меняющейся обстановке в организации, как правило, стараются обеспечить доступ законных сотрудников к базовым данным и активам на соответствующем уровне. В зависимости от работы, подразделения и статуса клиента права доступа могут быть реализованы с использованием механизмов SSO. Это обеспечивает различимость входных уровней.
Конкурентоспособность: пользователи отмечают более быстрый и удобный доступ к проектам, которые им необходимо завершить. Физическая обработка запросов – это задача, которая в основном раздражает клиентов. Проверка SSO избавляет от этой необходимости, предоставляя мгновенный доступ к огромному количеству приложений всего за одну галочку.
SSO – это наиболее важный этап защиты вашего бизнеса и его клиентов. Вы можете использовать SSO в качестве основы для других средств защиты, включая многофакторную проверку подлинности и сочетание проверки личности, оценки рисков и согласования советов директоров для выполнения предварительных требований и сокращения предоставления неверных данных. SSO делает вашу организацию легитимной и обеспечивает ее безопасность.
Недостатки:
SSO проста и практична в использовании, но если она не контролируется должным образом, то это может быть проблемой для безопасности. К проблемам SSO относятся:
Если злоумышленник получает права доступа SSO клиента, он также получает и доступ ко всем его приложениям. Соответственно, использование стратегий проверки, отличных от паролей, является основополагающим принципом.
Возможные недостатки: недавно злоумышленники получили несанкционированный доступ к веб-сайтам и различным записям из-за недостатков, обнаруженных к SAML и OAuth. Работа с поставщиком, который объединяет SSO с другими этапами проверки и управление личностями в своем продукте, является крайне необходимой в этом отношении.
Сходство приложений: иногда приложение может быть спроектировано так, что оно не очень подходит для работы с SSO. Будь то через SAML, Kerberos или OAuth, поставщики приложений должны обеспечить полноценную функциональность SSO. В любом другом случае, ваша система SSO не будет полностью вовлечена, а просто добавит еще один пароль, чтобы клиенты могли его восстановить.
Безопасна ли система SSO?
Однако неверно было бы утверждать, что SSO – это волшебное решение проблемы. Стоимость, контроль, нормализация (SAML против OAuth) и безопасность, безусловно, являются трудными задачами для организации системы единого входа. Сайт или ресурс могут быть подвержены атаке злоумышленника из-за проблем с проверкой, таких как уязвимость функции «Войти через Apple» или дефект Microsoft OAuth.
Кроме того, стоит понимать, что SSO-этап должен быть включен в более крупную корпоративную IT-структуру, поэтому следует тщательно продумать, как это сделать, сохраняя при этом общую безопасность. SSO, например, может помешать устройствам безопасности распознать начальный IP-адрес клиента при попытке пойти в вашу систему.
Несмотря на все это, использование SSO в большинстве случаев обеспечивает более высокий уровень безопасности, чем ожидание того, что клиенты будут контролировать все входы в систему для крупных бизнес-приложений. SSO явно сокращает количество моментов для атак, поскольку клиентам нужно реже регистрироваться и вспоминать меньше паролей. Директора могут более эффективно поддерживать меры предосторожности, такие как 2FA и надежные пароли, когда организация представляет собой единую структуру. Самое главное, что использование SSO, как правило, в любом случае безопаснее, чем его неиспользование.
Друг, начнем с цитаты:
Redis – это высокопроизводительная БД с открытым исходным кодом (лицензия BSD), которая хранит данные в памяти, доступ к которым осуществляется по ключу доступа. Так же Редис это кэш и брокер сообщений.
Надо признаться, определение не дает точного понимания, что же такое Redis. Если это так круто, то зачем вообще нужны другие БД? На самом деле, Redis правильнее всего использовать в определенных кейсах, само собой, зная про подводные камни – именно об этом и поговорим.
Про установку Redis в CentOS 8 мы рассказываем в этой статье.
Redis как база данных
Говорим про случай, когда Redis выступает в роли базы данных:
Пару слов про ограничения такой модели:
Размер БД ограничен доступной памятью
Шардинг (техника масштабирования) ведет к увеличению задержки
Это NoSQL - никакого языка SQL
LUA скриптинг в качестве альтернативы
Это нереляционная СУБД!
Нет сегментации на пользователей или группы пользователей. Отсутствует контроль доступа
Доступ по общему паролю. Что скажут ваши безопасники?
Теперь про преимущества модели:
Скорость
Хранение данных в памяти делает быстрее работу с ними
Скрипты на LUA
Выполнение прямо в памяти, опять же, ускоряет работу
Удобные форматы запросов/данных
Geospatial – геоданные (высота, ширина, долгота и так далее)
Hyperloglog – статистическе алгоритмы
Hash – если коротко, то хэш в Redis делают между строковыми полями и их значениями
Алгоритмы устаревания данных
Примеры использования
Представь, у нас есть приложение, где пользователям необходимо авторизоваться, чтобы выполнять какие – либо действия внутри приложения. Каждый раз, когда мы обновляем авторизационные данные клиента, мы хотим их получать для последующего контроля.
Мы могли бы отправлять лист авторизационных параметров (с некими номерами авторизаций, сроком действия с соответствующими подписями), чтобы каждое действие внутри приложения, сопровождалось авторизацонной транзакцией из листа, который мы прислали клиенту. С точки зрения безопасности, в этом подходе нет ничего плохого, если мы храним на своей стороне данные в безопасности и используем Javascript Object Signing and Encryption (JOSE), например. Но проблема появится в том случае, когда наш пользователь имеет более одной авторизации внутри приложения – такие схемы плохо поддаются масштабированию.
А что если вместо отправки листа авторизационных параметров, мы сохраним его у себя, а пользователю отправим некий токен, который они должны отправлять для авторизации? Далее, по этому токену, мы легко сможем найти авторизации юзера. Это делает систему гораздо масштабируемой. Redis, такой Redis.
Итого, для указанной выше схемы, мы хотим:
Скорость
Мы не хотим, чтобы пользователь долго ожидал авторизации
Масштабирумость системы
Сопоставление ключа (токена) с авторизациями юзера
А вот, что на эти вызовы может ответить Redis:
Redis хранит данные в памяти – он быстрый.
Redis можно кластеризовать через компонент Sentinel. Масштабируемость? Пожалуйста.
В Redis куча вариантов хранения списков. Самый простой будет являться набором данных.
В качестве бонуса от Redis, вы получите механизм экспайринга токенов (устаревания). Все будет работать.
Redis как кэш!
Redis почти заменил memcached в современных приложениях. Его фичи делают супер – удобным кэширование данных.
Ограничения:
Значения не могут превышать 512 МБ
Отсутствует искусственный интеллект, который будет очищать ваше хранилище данных
Профит:
Совместное использование кэша разными сервисами по сети
Удобные фичи, такие как LUA скриптинг, который упрощает работы с кэшом
Временные ограничения для данных
Еще один кейс
Предположим, перед нами такая задача: приложение, отображает пользователям данные с определенными значениями, которые можно сортировать по множеству признаков. Все наши данные хранятся в БД (например, MySQL) и показывать отсортированные данные нужно часто. Дергать БД каждый раз весьма тяжело и ресурсозатратно, а значит, нам нужно кэшировать данные в отсортированном порядке.
Окей, кейс понятен. Рэдис, что скажешь на такие требования?
Кэш должен хранить сортированные наборы данных
Нам нужно вытаскивать наборы данных внутри наборов данных (для пагинации, например, то есть для переключения между страницами)
Это должно быть быстрее, чем пересчет данных с нуля
Что скажет Redis:
Хранить наборы данных - легко
Может вытаскивать сабсеты из наборов - легко
Конечно быстрее. Ведь данные хранятся в памяти
Redis как брокер сообщений
Редис может выступать в качестве брокера сообщений. Схема обычная и весьма базовая - publish–subscribe (pub/sub), или как можно перевести на русский язык «Издатель - подписчик».
Как и раньше, давайте обсудим плюсы и минусы, хотя их тут и не так много. Минусы:
Только тривиальная модель pub/sub
Отсутствие очередей сообщений
Ну а плюсы, как обычно для Редиса – скорость и стабильность.
Кейс напоследок
Простой пример – коллаборация сотрудников одной компании. Предположим, у них есть приложение, где они работают над общими задачами. Каждый пользователь делает свой набор действий, о котором другие пользователи должны знать. А так же, юзеры могут иметь разные экземпляры приложений – десктоп, мобильный или что то еще.
Требования по этой задаче:
Низкая задержка
Мы не хотим иметь трудности в процессе совместной работы сотрудников
Стабильная работа и непрерывность
Масштабирование
Кампания растет и развивается
Редис, твой выход!
Низкая задержка – да, говорили об этом ранее
Стабильность – минимальное количество точек отказа в Redis
Стабильная работа и непрерывность
Масштабирование – сделаем кластер, нет проблем.
Выводы
Redis - крутая штука, которая позволяет объединять сервисы и следовать 12 принципам приложений. Для приложений, в которых нагрузка ориентирована на быстрое изменение наборов данных и высокая безопасность данных не имеет завышенных требований – Redis прекрасный выбор.
Если данные нуждаются в усиленной защите, Редис подойдет в меньшей степени, лучше посмотрите в сторону MongoDB или Elasticsearch.