[1] Перекрестная ссылка на родственные заявки
[2] Данная заявка испрашивает приоритет по предварительной заявке на патент США № 61/902 786, озаглавленной «Cloud Service Security Broker and Proxy», поданной 11 ноября 2013 г., по предварительной заявке на патент США № 61/902 787, озаглавленной «Cloud Service Risk Analysis and Threat Detection», поданной 11 ноября 2013 г., по предварительной заявке на патент США № 61/902 789, озаглавленной «Cloud Service Discovery», поданной 11 ноября 2013 г., и по предварительной заявке на патент США № 62/049 473, озаглавленной «Cloud Service Suffix Proxy», поданной 12 сентября 2014 г., содержимое каждой из которых включено настоящим по ссылке во всей их полноте.
[3] Область техники, к которой относится изобретение
[4] Данная заявка относится, в основном, к обеспечению безопасности сетей и систем связи посредством мониторинга и обеспечения безопасности связи, в частности, посредством использования прокси суффикса.
[5] Уровень техники
[6] Предприятия все больше и больше принимают предложения программного обеспечения как услуги на основе облака. Эти услуги подвергаются разнообразным нарушениям сетевой безопасности. Известные системы для обеспечения безопасности этих сетей работают посредством инспектирования трафика между серверами, предоставляющими программное обеспечение как услугу, и конечной точкой, управляемой пользователем. Эти известные системы сетевой безопасности обычно требуют сложную конфигурацию конечной точки, что повышает сложность системы. Кроме того, во многих случаях конечная точка может не быть под полным управлением предприятия, может быть полностью неуправляемой или иным образом неконфигурируемой. В дополнение к трудностям, связанным с конфигурированием и администрированием конечной точки под управлением пользователя, трудно обеспечить захват трафика в течение всего сеанса, когда сетевые адреса генерируются динамически.
[7] Краткое описание чертежей
[8] Фиг.1 иллюстрирует примерный обзор примерной архитектуры и работы способа.
[9] Фиг.2 иллюстрирует примерную архитектуру с многочисленными прокси-узлами.
[10] Фиг.3 иллюстрирует примерный способ аутентификации с использованием языка разметки для системы обеспечения безопасности (SAML).
[11] Фиг.4 иллюстрирует пример многочисленных отдельных сетей, включающих в себя прокси-узлы, глобально распределенные для уменьшенного времени ожидания.
[12] Фиг.5 иллюстрирует примерную архитектуру сетевого прокси, изображающую маршрутизацию, при которой контролируемый трафик в аварийной ситуации пропускается в обход.
[13] Фиг.6 иллюстрирует примерный прокси-узел, состоящий из кластера балансировщиков нагрузки и многочисленных прокси-узлов.
[14] Фиг.7 иллюстрирует примерный пользовательский интерфейс.
[15] Фиг.8 иллюстрирует примерный пользовательский интерфейс.
[16] Фиг.9 иллюстрирует примерный пользовательский интерфейс.
[17] Фиг.10 иллюстрирует примерный пользовательский интерфейс.
[18] Фиг.11 иллюстрирует примерный способ для обнаружения угроз.
[19] Фиг.12 иллюстрирует примерный набор параметров.
[20] Фиг.13 иллюстрирует примерный способ отыскания среды программного обеспечения как услуга (SaaS).
[21] Фиг.14 иллюстрирует примерный способ работы прокси суффикса без кэширования.
[22] Фиг.15 иллюстрирует примерный способ работы прокси суффикса с кэшированием.
[23] Подробное описание
[24] В данном документе описывается архитектура для мониторинга и обеспечения безопасности связи. Системы и способы, описанные в данном документе, могут использоваться для того, чтобы прозрачно сделать возможным в любом месте обеспечение безопасности и управление облачным трафиком для пользователей. Система может быть выполнена с возможностью обеспечения безопасности любого или всего трафика и активности в учетных записях облачных услуг компании. В некоторых вариантах осуществления система может быть выполнена так, что ей не требуется никакая установка на стороне клиента или в сети. Система может включать в себя высоко отказоустойчивую виртуальную сеть, состоящую из независимых автономных сетевых прокси, распределенных по многочисленным местоположениям по всему миру.
[25] Услуга управляемого сетевого прокси связи может использоваться для перехвата, мониторинга, модифицирования и направления сетевого трафика связи между пользователем и провайдером услуг по предоставлению программного обеспечения на основе сети. Услуга управляемого сетевого прокси может быть выполнена с возможностью работы так, чтобы обнаруживать и уменьшать сетевые угрозы. В качестве неограничивающих примеров, услуга может быть выполнена с возможностью работы в различных режимах, включая режим брандмауэра приложения; режим пассивного обнаружения вторжений (IDS), для уведомления о подозрительном сетевом трафике и поведении; или режим системы предотвращения вторжений (IPS) для блокирования угроз. Система также может быть выполнена с возможностью выполнения управления приложением, фильтрации унифицированных указателей ресурса (URL) и защиты от вредоносного программного обеспечения в сетевом трафике.
[26] Архитектура
[27] Система, описанная в данном документе, может быть выполнена с возможностью работы на сетевом трафике между провайдером сетевого программного обеспечения как услуга (SaaS) и клиентом. В некоторых вариантах осуществления система способна конфигурироваться для работы на таком трафике между провайдером SaaS и клиентским вычислительным устройством, когда это вычислительное устройство подключено к провайдеру SaaS по сети общего пользования (такой как Интернет) без какого-либо контроля или ограничений, налагаемых на клиентское устройство или сеть. В некоторых вариантах осуществления не является необходимым конфигурирование клиентского устройства.
[28] Проекты архитектуры
[29] Компоненты системы могут быть воплощены в виде управляемого сетевого прокси связи. Хотя ссылка может делаться в данном документе на прокси, понятно, что прокси может быть воплощен в одном или нескольких сетевых устройствах. Кроме того, управляемый сетевой прокси может быть децентрализован, и функции управляемого сетевого прокси могут быть распределены по многочисленным машинам в различных географических регионах.
[30] В некоторых вариантах осуществления сетевой прокси может быть выполнен так, что трафик между клиентским устройством и провайдером SaaS проходит через сетевой прокси. Так как сетевой прокси является промежуточным элементом в связи, он может использоваться для мониторинга сетевого трафика между этими точками и может предпринимать действие на сетевом трафике, основываясь на заранее определенных политиках и правилах. Общий обзор примерной архитектуры и работы способа изображен на фиг.1. Сеть прокси может быть оптимизирована для устойчивости к ошибкам, и элементы управления пропускания в обход контролируемого трафика в аварийной ситуации могут использоваться для повторной маршрутизации трафика пользователя, если отказывает сеть прокси. Как более подробно описано ниже, при развертывании основным потоком трафика SaaS является следующий:
[31] Из любого местоположения, на любом устройстве, пользователи выполняют доступ к облачным услугам организации. Трафик маршрутизируется через ближайший управляемый сетевой прокси-узел. Узлы могут функционировать как узлы обеспечения выполнения политики и могут обеспечивать полный аудит облачной активности. В центре сбора данных сети прокси событиям назначаются токены, и они собираются в центральном центре сбора данных в отдельной базе данных для каждого участника. Происходит обработка событий, и передается отчет о происшествиях (например, «неизвестное устройство обращается к уязвимым данным»). Может обеспечиваться пользовательский интерфейс, посредством которого менеджеры могут получить доступ к консоли и могут получить видимость облачной активности. Кроме того, могут быть определены политики, и может обеспечиваться их выполнение прокси-узлами. Примерная архитектура с многочисленными прокси-узлами изображена на фиг.2.
[32] Прокси могут быть выполнены с возможностью автономной работы, обеспечивая устойчивость к ошибкам и высокую доступность для разных провайдеров услуг Интернета (ISP) и географических зон. В некоторых вариантах осуществления может применяться звездообразная архитектура, при которой все узлы посылают информацию (один путь) на центральный центр сбора данных.
[33] Система может быть выполнена или с обеспечением безопасности в аварийной ситуации или с пропусканием в обход контролируемого трафика в аварийной ситуации. Если используется решение с внешним хостингом, может быть выполнена маршрутизация пользователя на исходного провайдера SaaS в случае неудачи других средств. Это гарантирует прозрачное восприятие для пользователя.
[34] Общедоступное и частное облако
[35] Развертывание частного облака: Прокси-серверы могут развертываться в частном облаке компании для обеспечения дополнительной безопасности для данных компании. При таком устройстве журналы регистрации метаданных все еще могут посылаться вне периметра организации, когда сетевой трафик изолирован сетью организации.
[36] Развертывание общедоступного облака: Прокси-серверы развертываются вне частного облака компании. Само облако может быть общедоступным или частным облаком.
[37] Инфраструктура услуги управляемого сетевого прокси
[38] Управляемый сетевой прокси связи, описанный в данном документе, может быть выполнен в различных режимах прокси, включая, в качестве неограничивающих примеров, прямой прокси, прокси суффикса или обратный прокси.
[39] Если он выполнен в виде прямого прокси, сетевой прокси может использовать файл автоматической конфигурации прокси (PAC) и/или может подключаться к существующему сетевому прокси с построением цепочки прокси. Если он выполнен в виде обратного прокси, развертывание может выполняться посредством организационных серверов службы имен доменов (DNS).
[40] В предпочтительных вариантах осуществления управляемый сетевой прокси может быть выполнен в виде прокси суффикса. Например, в качестве прокси суффикса, к http://www.salesforce.com будут обращаться через http://www.salesforce.com.network-proxy-service.com, где network-proxy-service.com представляет собой имя домена, используемое для услуги управляемого сетевого прокси. В некоторых вариантах осуществления прокси суффикса может использовать двухфакторную аутентификацию, аутентификацию как для центра аутентификации на прокси суффикса, так и для провайдера SaaS.
[41] Поддержка протокола
[42] Управляемый сетевой прокси может быть выполнен с возможностью поддержки любого произвольного приложения или протокола. В качестве неограничивающих примеров, следующие протоколы могут поддерживаться: HTTP (протокол передачи гипертекста) и HTTPS (протокол защищенной передачи гипертекста), RPC (вызов удаленных процедур) по HTTP, Outlook anywhere, WebDAV, FTP (протокол передачи файлов) и проприетарные протоколы производителя.
[43] Безопасность: Захват трафика SaaS
[44] Управляемый сетевой прокси может быть выполнен с возможностью инспектирования трафика и обнаружения адресов Интернета SaaS. в некоторых вариантах осуществления управляемый сетевой прокси может быть выполнен с возможностью инспектирования сетевого трафика в отношении адресов Интернета (таких как унифицированные указатели ресурса, унифицированные идентификаторы ресурса и т.д.). В качестве неограничивающих примеров, сетевой прокси может декомпилировать, разбирать или дизассемблировать сетевой трафик для инспектирования. Управляемый сетевой прокси может быть выполнен с возможностью модифицирования сетевого трафика между клиентским устройством и провайдером SaaS так, что на пользовательское устройство не предоставляются сетевые адреса, которые непосредственно направляют клиентское устройство на доступ к ресурсу SaaS, обходя управляемый сетевой прокси. Если обнаруживается адрес Интернета SaaS, этот адрес может быть переписан в адрес на сетевом прокси посредством добавления имени домена для услуги сетевого прокси к исходному сетевому адресу.
[45] Прокси суффикса может быть выполнен для обработки персональной страницы посредством обработки ответов сервера SaaS, так что последующие запросы обрабатываются посредством прокси суффикса. Обработка может зависеть от типа файла и типа ответа. В качестве неограничивающих примеров, обрабатываемые типы файлов могут включать в себя HTML (язык разметки гипертекста) или JavaScript, и ответы могут включать в себя сжатые gzip-ом ответы или разбитые на фрагменты ответы. Прокси суффикса может быть выполнен с возможностью эмулирования любого контента, включая веб-страницы, посылаемые от провайдера SaaS. Прокси суффикса может быть выполнен с возможностью инспектирования и/или декомпилирования любого контента для идентификации любых ссылаемых страниц и/или URL, присутствующих в контенте, и перезаписи этих URL.
[46] В некоторых случаях инспектирование потребует код или сценарии исполнения, передаваемые между клиентом и провайдером SaaS. Например, JavaScript может эмулироваться на сетевом прокси для обнаружения генерирования сетевых адресов, которые непосредственно обращаются к провайдеру SaaS. Если адреса непосредственного доступа идентифицируются в контенте, контент может модифицироваться для перезаписи адресов для ссылки на сетевой прокси.
[47] Безопасность: Блокировка услуги SaaS
[48] Система может быть выполнена с возможностью ограничения доступа к услуге SaaS только через управляемый сетевой прокси. Система может включать в себя многочисленные методы для этой блокировки, и выбранный метод может зависеть от способа развертывания, описанного более подробно ниже. Сетевой трафик может блокироваться в момент создания сеанса, или в любой момент после него. Инициирование сеанса описывается более подробно ниже.
[49] Способ 1 блокировки: Замена мандата
[50] В некоторых средах провайдер SaaS может использовать язык разметки для систем обеспечения безопасности (SAML). В этих средах может использоваться замена токенов SAML для блокировки сетевого соединения. Например, токен SAML может быть действительным в течение 5 минут. Когда конфигурируется прокси SAML, пользователи могут обращаться к услуге только через управляемый сетевой прокси SAML.
[51] Может использоваться замена куки-файлов браузера для блокировки соединения. Когда пользователь выполняет аутентификацию у провайдера SaaS, провайдер SaaS посылает куки-файл пользователю. Посылаемый куки-файл может представлять собой куки-файл аутентификации, используемый провайдером SaaS для указания, зарегистрирован ли или нет пользователь, и с какой учетной записью зарегистрирован пользователь. Так как управляемый сетевой прокси находится между пользователем и провайдером SaaS, он может перехватывать и шифровать куки-файл браузера пользователя, посылаемый провайдером SaaS. Затем управляемый сетевой прокси может посылать зашифрованный куки-файл пользователю для хранения на устройстве пользователя. Таким образом, пользователь только хранит зашифрованную копию куки-файла, которая не может быть использована непосредственно клиентом на исходном сайте SaaS. При использовании посредством сети управляемого прокси, куки-файл посылается с клиентского устройства в сеть прокси, расшифровывается в сети прокси и посылается на инициирующий сайт. В некоторых случаях, куки-файл, сгенерированный провайдером SaaS, может шифроваться или может содержать зашифрованный контент. В этих случаях управляемый сетевой прокси может добавлять дополнительный уровень шифрования к куки-файлу перед посылкой его клиенту.
[52] Аналогично тому, как могут заменяться куки-файлы браузера, токены OAuth (или любой другой постоянный токен API (интерфейса прикладного программирования)) также могут заменяться оперативно. Управляемый сетевой прокси может отслеживать запросы токенов со стороны клиента (например, токенов OAuth, используемых мобильными приложениями) и может заменять их зашифрованной версией. Это дает возможность обеспечивать выполнение блокировки услуги по дополнительным сценариям аутентификации.
[53] Управляемый сетевой прокси также может проксировать пароль пользователя. Этот метод может применяться к любой услуге SaaS. В некоторых вариантах осуществления может использоваться прокси пароля, когда не поддерживается SAML. Для реализации этого пароль услуги SaaS может быть разделен на две или более частей. Пользователь знает меньше, чем все части пароля. Услуга управляемого сетевого прокси хранит остальную часть пароля. При таком устройстве полный пароль может быть составлен только тогда, когда пользователь обращается к услуге SaaS через услугу управляемого сетевого прокси. Методу не требуется, чтобы услуга управляемого сетевого прокси хранила пароли пользователя. Например, добавление хэш-суффикса ко всем паролям требует хранение только единственного хэш-ключа.
[54] Любые попытки пользователя изменить пароль в приложении SaaS могут контролироваться посредством услуги управляемого сетевого прокси, и пользователю может быть разрешено установить часть пароля. В некоторых вариантах осуществления пользователю предоставляет возможность только устанавливать половину пароля. Когда конфигурируется прокси пароля, любой запрос на изменение пароля (например, по ссылке «забыл мой пароль») может контролироваться сетевым прокси, и сетевой прокси может быть выполнен с возможностью хэширования нового пароля.
[55] Способ 2 блокировки: Ограничение доступа
[56] В некоторых случаях приложение SaaS может быть выполнено с возможностью предоставления функциональной возможности ограничения адреса протокола Интернета (IP) и, таким образом, ограничения доступа только по адресам протокола Интернета (IP), ассоциированным с услугой сетевого прокси.
[57] Дополнительные функции обеспечения безопасности
[58] Услуга управляемого сетевого прокси может быть выполнена с возможностью поддержки дополнительных функций обеспечения безопасности. В качестве неограничивающего примера, сетевой прокси может использоваться для выполнения аудита активности пользователя, посредством чего может быть выполнен синтаксический анализ и/или аудит из потока трафика любого действия пользователя. Сетевой прокси может использоваться при обеспечении выполнения политики. Например, услуга прокси может использоваться для управления доступом для запрещения конкретной операции; для предотвращения утечки данных (DLP) посредством реализации политик DLP, основанных на контексте пользователя, устройстве, местоположении, действии, контента и/или скорости; для динамического маскирования; и для защиты от копирования методом «водяных знаков». Сетевые угрозы также могут обнаруживаться и/или блокироваться с использованием логики характеризации угроз.
[59] Услуга управляемого сетевого прокси может быть выполнена с возможностью обеспечения улучшенных услуг защиты файлов. В некоторых вариантах осуществления услуга сетевого прокси может поддерживать интегрирование с сетевыми услугами хранения файлов. Неограничивающие примеры услуг этого типа включают в себя Google™ Drive, Dropbox™ и т.д. Сетевой прокси может быть выполнен с возможностью предотвращения осуществления поиска и выборки пользователем файлов у провайдера SaaS и сохранение их локально на устройстве пользователя. Это может упоминаться как политика «всегда в облаке». В некоторых вариантах осуществления это может быть выполнено с возможностью динамического изменения и перенаправления потоков информации во время сеанса пользователя, так что файлы не передаются между приложением SaaS и устройством пользователя или между приложениями SaaS. В некоторых случаях вместо загрузки файла пользователю может отображаться версия файла.
[60] VPN (виртуальная частная сеть) по «Всемирной паутине»
[61] Услуга прокси может быть выполнена с возможностью предоставления возможности безопасного доступа к корпоративным интрасетям. Если пользователь аутентифицирован на услугу сетевого прокси, пользователь может выполнить доступ к сайту интрасети по «Всемирной паутине» (используя, например, HTTP(S)). Этот способ не требует специального клиента VPN на устройстве. Если соединение инициировано, услуга сетевого прокси открывает соединение VPN и действует как обратный прокси для сайтов интрасети HTTP(S). На соединения VPN может обеспечиваться выполнение других функциональных возможностей, таких как аудит пользователя, предупреждение и защита файлов.
[62] Способы развертывания
[63] Система может развертываться любым из многочисленных средств, отдельно или в комбинации. В некоторых конфигурациях система может развертываться без какого-либо конфигурирования клиента. В других конфигурациях клиент может конфигурироваться вместо или в дополнение к конфигурированию на SaaS.
[64] Способы прозрачного развертывания
[65] Система может включать в себя методы для прозрачного направления трафика между пользователем и провайдером SaaS через управляемый сетевой прокси. В этих вариантах осуществления доступ к приложению SaaS может ограничиваться только пользователями прокси. Эти методы делают возможным работу управления по обеспечению безопасности без какой-либо установки на пользовательском устройстве или локальной сети пользователя. Этот метод может использоваться на глобальной основе для всех приложений, хостируемых провайдером SaaS.
[66] A. Прокси прозрачной аутентификации (уровень аутентификации)
[67] Применяя по-новому встроенную поддержку языка разметки для систем обеспечения безопасности (SAML) или подобных протоколов в облачных услугах, пользователь может автоматически перенаправляться на управляемые сетевые прокси-серверы без какого-либо конфигурирования на клиентской стороне. Например, SAML представляет собой стандарт расширяемого языка разметки (XML), который предоставляет возможность защищенным веб-доменам обмениваться данными аутентификации и авторизации пользователя. Используя SAML, провайдер онлайновых услуг может устанавливать связь с отдельным провайдером онлайновым идентификации для аутентификации пользователей, которые пытаются обратиться к защищенному контенту.
[68] В качестве неограничивающего примера, этот метод может использоваться с услугами SaaS, которые поддерживают SAML, и организациями, которые уже имеют внешнего провайдера SAML. В этих случаях управляемый сетевой прокси связи выполняется в виде провайдера SAML, и услуга прокси затем использует исходного провайдера SAML для выполнения аутентификации. При успешной аутентификации пользователь перенаправляется на провайдера SaaS через прокси суффикса, обеспечиваемый услугой сетевого прокси. (Услуга прокси суффикса описывается более подробно ниже).
[69] Функциональные возможности управления доступом приложений SaaS могут использоваться для ограничения доступа пользователей прокси суффикса. Прокси SAML также может использоваться для установки дополнения браузера вместо перенаправления на прокси суффикса. В этом случае, дополнение будет прозрачно направлять трафик услуге сетевого прокси, и обратный прокси будет использоваться вместо прокси суффикса. В дополнение к SAML, управляемый сетевой прокси связи может быть выполнен с возможностью взаимодействия с другими протоколами, которые имеют подобную функциональную возможность. Например, WS-Federation™ может использоваться в связи с услугами Office 365™.
[70] Примерный способ аутентификации, использующий SAML, изображен и описан на фиг.3.
[71] B. Прозрачная инициализация собственного IDP (провайдера идентификации) (уровень аутентификации)
[72] Инициализация собственного IDP может использоваться вместо решения с однократной регистрацией. Она является вариантом способа прокси SAML, где пользователь перенаправляется на услугу управляемого прокси SAML, но процесс аутентификации выполняется услугой управляемого сетевого прокси связи. Прокси логина может использоваться. При запросе логина пользователя управляемый сетевой прокси SAML запрашивает исходную услугу SaaS на верификацию мандата пользователя. Используя синхронизацию пароля услуга сетевого прокси может функционировать как эпизодический провайдер SAML посредством установки инструментального средства синхронизации пароля, которое синхронизирует пароли пользователя из Active Directory (или любого другого каталога LDAP (упрощенного протокола доступа к сетевым каталогам)) с управляемым сетевым прокси SAML.
[73] C. Прозрачный прокси шлюза (уровень трафика)
[74] Этот метод может применяться к любой услуге SaaS и может быть особенно применим в случаях, когда SAML не поддерживается услугой SaaS. Пользователь может инструктироваться на использование другого URL при доступе к услуге SaaS. URL перенаправляет пользователя через услугу управляемого сетевого прокси. Эта конфигурация может использовать функциональные возможности управления доступом приложений SaaS для ограничения доступа пользователям прокси суффикса. Может быть предоставлена возможность функциональной возможности ограничения IP для ограничения доступа только по адресам IP, расположенным в услуге управляемого сетевого прокси связи.
[75] Способы непрозрачного развертывания
[76] Приложения для мобильных и настольных систем могут конфигурироваться индивидуально посредством использования установки или изменений конфигурации на устройстве пользователя, чтобы перенаправлять трафик через услугу управляемого сетевого прокси связи.
[77] A. Прокси SAML: Используя прокси SAML, описанный выше, пользователь может перенаправляться на страницу, запрашивающую, чтобы пользователь установил и/или сконфигурировал устройство для связи с услугой управляемого сетевого прокси связи.
[78] B. Приложения для настольных систем (уровень трафика): Большинство приложений для настольных систем поддерживают конфигурацию системного прокси. Файл PAC может автоматически конфигурироваться для управляемых устройств и конфигурироваться пользователем для неуправляемых устройств. PAC поддерживается большинством операционных систем (OS), браузеров и приложений и может развертываться в доменной среде Windows, используя объект групповой политики (GPO). Файл PAC может конфигурироваться на пропускание только трафика SaaS через платформу сети управляемого прокси, и остальная часть трафика Интернета пользователя может маршрутизироваться напрямую без изменения.
[79] C. Приложения для мобильных систем (уровень трафика): Подобно способу PAC для управляемых устройств, мобильные устройства могут требовать установку VPN или APN (точки доступа к сети) на устройстве и сертификат сети управляемого прокси.
[80] Характерные для приложения решения: Некоторые приложения имеют возможные варианты конкретного конфигурирования, которые позволяют выполнять гладкое перенаправление. Например, используя функциональную возможность автоматического отыскания Outlook, клиенты Outlook автоматически перенаправляются на прокси Outlook сети управляемого прокси.
[81] Способы развертывания для управляемых сетей и устройств
[82] В некоторых вариантах осуществления управляемый сетевой прокси может быть встроен в прибор в помещении пользователя. В других вариантах осуществления функциональная возможность управляемого сетевого прокси может достигаться посредством дополнения веб-браузера. Дополнение браузера может быть выполнено с возможностью работы подобно файлу PAC, в том что, если приложение SaaS обнаруживается в браузере, трафик перенаправляется на сеть управляемого прокси.
[83] Некоторые варианты осуществления могут быть выполнены с возможностью использования построения цепочки прокси, посредством чего существующий прокси организации выполняется с возможностью направления связанных с SaaS запросов через инфраструктуру услуги управляемого сетевого прокси связи. Эти варианты осуществления необязательно могут включать идентификатор организации (имя пользователя и/или IP) с направляемым запросом.
[84] В некоторых вариантах осуществления может использоваться файл PAC. PAC может развертываться по организации. PAC может использоваться для перенаправления приложений SaaS на услугу управляемого сетевого прокси связи. Это может основываться на базе данных провайдеров SaaS. Может использоваться эффективный PAC с скомпилированным списком доменов в дерево, основываясь на именах доменов.
[85] В любой из этих конфигураций, описанных выше, платформа может динамически развертываться на конкретных пользователях или группах пользователей, таким образом делая возможным постепенное развертывание. Это может выполняться на основе прокси SAML, например, посредством перемаршрутизации только некоторых пользователей.
[86] Доступность системы
[87] Как показано на фиг.4, платформа может включать в себя многочисленные отдельные сети, включающие в себя прокси-узлы, глобально распределенные для уменьшенного времени ожидания (например, в пяти центрах, как показано). Пользователи могут маршрутизироваться на ближайший узел или другой оптимальный узел. Система может включать в себя автоматическую обработку отказа DNS между узлами. Любой из узлов может функционировать в качестве точки обеспечения выполнения политики и создавать журналы регистрации аудита. В качестве неограничивающего примера, сетью второго уровня может быть виртуальное частное облако (VPC) AWS (веб-услуги компании Amazon), содержащее центральную базу данных и серверы второго уровня.
[88] Высокая доступность DNS
[89] Примерная архитектура сетевого прокси, изображающая маршрутизации, при которой контролируемый трафик в аварийной ситуации пропускается в обход, изображена на фиг.5. Сеть прокси-узла может использовать сервер DNS для реализации высокой доступности. Записи DNS могут устанавливаться на очень короткое время существования (TTL) (например, 30 секунд), заставляя клиентов регулярно запрашивать сервер DNS в отношении обновлений (моменты времени запроса могут изменяться в зависимости от установок кэш-памяти браузера). Сервер направляет клиента на ближайший доступный узел (Geo-DNS) и, в случае неисправности узла, может обнаружить проблему и перенаправить клиентов гладким образом на другие доступные узлы.
[90] На доступность самой услуги DNS может оказывать влияние описанное поведение. Например, Route53 компании Amazon рассматривается продуманной и высокодоступной системой, гарантирующей высокую доступность. В случае неисправности самого сервера DNS система может конфигурироваться на пропускание в обход контролируемого трафика.
[91] Автономные режимы
[92] Прокси-узлы могут быть встроены в кластеры в различных глобальных регионах. Некоторые или все узлы могут быть одновременно в режиме онлайн и обслуживать заказчиков. В случае неисправности узлы не фиксируют текущее состояние, позволяя системе перемещать пользователей между узлами без какого-либо прерывания услуги.
[93] Узлы могут быть автономными и отказоустойчивыми. Как показано на фиг.6, прокси-узел может состоять из кластера балансировщиков нагрузки и многочисленных (например, 2 или 3) прокси-узлов. Некоторые из центральных узлов могут основываться на внешних балансировщиках нагрузки, обеспечиваемых самим облачным провайдером (например, ELB (эластичный балансировщик нагрузки) и RackSpace), учитывая даже еще большую отказоустойчивость. Каждый узел может функционировать автономно без какой-либо зависимости от других частей платформы. Связь с сетью второго уровня может выполняться с использованием сообщений брокера и может быть полностью асинхронной. В случае неисправности второго уровня сообщения сохраняются внутренне в очереди, размер которой ограничен верхним пределом, и не оказывают влияния на работу самого узла. В примерном варианте осуществления, показанном на фиг.6, каждый узел может быть составлен из кластера балансировщиков нагрузки и нескольких прокси-серверов. Может быть много центральных узлов (таких как запад США, восток США, Европа и Ближний Восток), которые используют внешние балансировщики нагрузки (такие как балансировщики нагрузки AWS и Rackspace) с встроенной в защиту от распределенного отказа в обслуживании (DDoS) (балансировщики нагрузки маршрутизируют трафик и могут не выполнять завершение протокола безопасных соединений (SSL)). В случае атаки DDoS трафик может автоматически маршрутизироваться на ближайший центральный узел.
[94] Сценарии обработки отказа
[95] Система может быть выполнена с возможностью обработки многочисленных разных сценариев обработки отказа. Некоторые возможные сценарии и решения описаны ниже.
[96] Обработка отказа единственной машины: В этом случае DNS маршрутизирует запрос на ближайший узел. Каждый узел работает независимо и выполняет обработку отказа внутренним образом.
[97] Отказ внутреннего процесса: Полное резервирование начинается с машинного уровня, где каждый критический процесс защищается схемой обеспечения безопасности и немедленно повторно запускается. Критические процессы имеют несколько экземпляров, постоянно выполняющихся. Все некритические операции выполняются асинхронно.
[98] Отказ прокси-сервера: Переводит трафик на другие прокси в узле.
[99] Отказ сервера балансировщика нагрузки: Вызывает прохождение всего трафика через второй балансировщик нагрузки в кластере.
[100] Обработка отказа единственного прокси-узла: Отказы единственного узла могут быть вызваны выходом из строя центра сбора данных или проблемами возможности соединения с ISP. Если узел не отвечает, обработка отказа DNS маршрутизирует трафик на следующий доступный узел без нарушения работы пользователя.
[101] Обработка регионального отказа: Даже в случае региональной проблемы, оказывающей влияние на многочисленные узлы, система будет продолжать нормальную работу. Обработка отказа DNS маршрутизирует трафик на оставшиеся функционирующие узлы в других регионах. Пользователи из перегруженного региона могут испытывать более высокое время ожидания чем обычно, но в меньшей степени.
[102] Обработка отказа центрального узла: Хотя сервер DNS выполняет балансировку нагрузки между доступными узлами, неожиданные резкие скачки могут вызвать цепную реакцию, оказывающую влияние на вспомогательные узлы. По этой причине, в случае многочисленных отказов, трафик маршрутизируется на центральные узлы, которые специально разрабатываются для обработки необычных резких скачков трафика.
[103] Дополнительные функциональные возможности
[104] Услуга управляемого сетевого прокси может быть выполнена с дополнительной возможностью предоставления показателей, относящихся к аналитике деловой активности, статистике принятий, интенсивности использование функциональной возможности, использованию лицензий, активности пользователя и мониторингу соглашения об уровне обслуживания (SLA), в качестве неограничивающих примеров.
[105] Услуга также может включать в себя центр команд и управления для услуги SaaS, центр предупреждений и центр статистики использования. Услуга может выполнять обеспечение выполнения роли, чтобы обеспечить выполнение доступности данных для каждого пользователя в соответствии с ролью и областью действия пользователя. Услуга может выполнять динамическое объединение ресурсов SSL для поддержания нескольких соединений второго уровня к провайдерам SaaS в соответствии с заданными шаблонами ежедневного использования.
[106] Примерные консоли управления для услуги управляемого сетевого прокси и другие функциональные возможности изображены на фиг.7-10.
[107] Логика обнаружения угроз
[108] Используя системы и способы, описанные выше, сетевой трафик между сетевым провайдером SaaS и клиентским устройством может перехватываться на прокси-узле. Прокси-узел может быть дополнительно выполнен с возможностью анализа трафика в отношении индикаторов различных угроз, используя логику обнаружения угроз.
[109] Обзор способа обнаружения угроз изображен на фиг.11. Шлюз (1011) безопасности может быть реализован как алгоритмическая подпрограмма в одном или нескольких прокси-узлах (1010), посредством которых переносится сетевой трафик пользователя. Альтернативно, шлюз безопасности может быть воплощен в отдельном устройстве, посредством которого переносится трафик. Пользовательский трафик может быть между любым источником и пунктом назначения, подключенным к прокси-узлу. Неограничивающими примерами пользователей могут быть локальный пользователь, пользователь Интернета, пользователь-соучастник или мобильный пользователь.
[110] Шлюз (1011) безопасности может быть выполнен с возможностью извлечения различных параметров из пользовательского трафика. Представлены следующие неограничивающие примеры. Шлюз безопасности может быть выполнен с возможностью извлечения информации, описывающей пользовательское устройство. В качестве неограничивающих примеров, параметры устройства могут включать в себя тип устройства, такой как iPad или планшет Surface, операционную систему устройства, такую как Windows RT или iOS, и/или используемый веб-браузер, такой как Chrome или Explorer. Шлюз безопасности может быть выполнен с возможностью извлечения информации, описывающей местоположение устройства пользователя. Информация о местоположении может описывать физическое/географическое местоположение и/или логическое местоположение в сети. Шлюз безопасности может быть выполнен с возможностью извлечения информации, касающейся действия, предпринимаемого пользователем (например, запрос данных), и/или ответа платформы SaaS (например, посылка запрошенных данных). Шлюз безопасности также может быть выполнен с возможностью извлечения информации, относящейся к идентификации устройства пользователя (в дополнение к его типу), времени активности пользователя и пропускной способности, потребляемой действиями пользователя.
[111] Шлюз безопасности также может быть выполнен с возможностью обнаружения и идентификации любого устройства связи, используемого пользователем для подключения к провайдеру SaaS. Идентификация устройства может регистрироваться в связи с предысторией обращений пользователя, так что индивидуальные сеансы SaaS могут ассоциироваться с конкретным устройством, использованным для этого сеанса. Хранимая идентифицирующая информация может включать в себя международный идентификатор мобильного оборудования (IMEI), телефонный номер, адрес управления доступом к среде передачи (MAC), адрес протокола Интернета (IP) или другую однозначно или, по существу, однозначно идентифицирующую информацию. Эта идентифицирующая устройство информация может отслеживаться по многочисленным сеансам пользователя и/или может сохраняться в связи с ассоциированным профилем пользователя. Последующие запросы тогда могут исполняться для определения, какое устройство использовалось данным пользователем для обращения к данной услуге SaaS в единственном сеансе или по многочисленным сеансам.
[112] Параметры трафика могут вводиться в модуль (1012) обнаружения. Модуль обнаружения также может принимать ввод, основываясь на информации о профиле пользователя из хранилища данных профиля пользователя. Информация о профиле пользователя может включать в себя информацию о пользователе, трафик которого анализируется. В качестве неограничивающего примера, информация о пользователе может получаться от модуля обнаружения. Модуль обнаружения также может принимать ввод от базы знаний, включая другую информацию, такую как информацию о конкретных угрозах безопасности. В предпочтительном варианте осуществления база знаний может включать в себя индекс (1015) облачной услуги в качестве компонента. В некоторых вариантах осуществления модуль (1012) обнаружения может быть включен как компонент шлюза (1011) безопасности. В альтернативных вариантах осуществления модуль (1012) обнаружения может представлять собой отдельный компонент при связи со шлюзом (1011) безопасности.
[113] Модуль (1012) обнаружения угроз может включать в себя механизм (средство) профилирования, механизм аномалий на основе расстояния и механизм аномалий на основе статистики. Механизм статистических аномалий может быть выполнен с возможностью выполнения оценки угрозы на основе комбинации краткосрочной и/или долгосрочной статистической информации. Каждый механизм может принимать любой или все параметры трафика, описанные выше. Каждый из механизмов также может принимать ввод, получаемый от других механизмов.
[114] Механизм аномалий
[115] Механизм аномалий может быть выполнен с возможностью обнаружения конкретной аномальной работы, последовательности аномальных операций и/или шаблона аномальных операций. Например, механизм может быть выполнен с возможностью определения, является ли конкретная операция, выполняемая пользователем или провайдером SaaS, подозрительной на основе того, что ее выполнение более частое, чем данные предыстории, полученные по предсказаниям времени обучения, когда она бы выполнялась (например, более высокая частота выполнения операций и т.д.), или соединение имеет новое местоположение источника или пункта назначения. Механизм аномалий также может быть выполнен с возможностью определения, является ли подозрительной последовательность операций пользователя. В некоторых случаях, индивидуальная операция может не быть подозрительной. Однако, когда эта операция выполняется в последовательности с другой операцией, набор операций может быть подозрительным. Например, пользователь аутентифицироваться у провайдера SaaS и затем начинает пересылку файлов из системы. В качестве примера, механизм аномалий может быть выполнен с возможностью идентификации этой последовательности в качестве подозрительной. Таким образом, обнаружение аномалий подозрительного трафика может основываться на последовательности активности, которая может состоять из некоторого количества операций. Механизм аномалий также может быть выполнен с возможностью определения, является ли подозрительным шаблон непоследовательных операций. При обнаружении подозрительного шаблона механизм аномалий может быть выполнен с возможностью исследования действий, взятых из последовательности и в течении произвольных периодов времени. Подозрительность индивидуальных операций, последовательностей операций и шаблонов операций может определяться на основе любого из параметров, описанных в данном документе.
[116] Аномалии могут обнаруживаться на основе сравнения одного или нескольких параметров с ранее сохраненной информацией о профиле. В качестве неограничивающих примеров, информация о профиле может включать в себя: местоположение, время активности (час дня, день недели и т.д.), интенсивность использования устройства, пользователя-агента (тип и версия), частоту действий/запросов, тип выполняемых действий, порядок выполняемых действий, тип информации, к которой производится обращение, пропускная способность трафика, характеристики сеанса (длительность, время простоя и т.д.) и/или характеристики запросов HTTP (к каким ресурса производится обращение, способы, заголовки, выделение заглавными буквами и т.д.).
[117] Индекс облачной услуги
[118] Логика обнаружения угроз может включать в себя индекс (1015) облачной услуги, содержащий набор параметров, которые объединяют факторы риска приложения SaaS для любого данного провайдера SaaS. Примерный набор параметров изображен на фиг.12. Оценка уровня риска может основываться на информации от некоторых или всех источников, включая, но не ограничиваясь ими:
[119] 1. Информацию, предоставляемую провайдером SaaS, касающуюся его политики безопасности, получаемой от него, в качестве неограничивающих примеров, технические описания, сертификаты и т.д.;
[120] 2. Независимое исследование, касающееся провайдера SaaS, клиента и других факторов окружающей среды; и/или
[121] 3. Предысторию уязвимостей и/или атак на приложения SaaS клиента, идентифицированных модулем обнаружения, на основе анализа трафика, перехваченного шлюзом безопасности.
[122] Риск может измеряться относительно одной или нескольких осей, включая, но не ограничиваясь ими:
[123] 1. Риск данных: Риски, налагаемые на данные, которые хранит SaaS, такие как многоарендная архитектура и использование нешифрованных данных;
[124] 2. Риск пользователя/устройства: Риски, налагаемые подключенными пользователями и устройствами, включая, например, качество аутентификации, возможность анонимного использования и т.д.;
[125] 3. Риск услуги: Риски, налагаемые на сеть провайдера услуги, такие как качество практик безопасности, на выполнение которых претендует провайдер, уровень безопасности веб-приложения, управление уязвимостями и т.д.; и
[126] 4. Деловой риск: Управление, которое провайдер предоставляет своим клиентам и возможность этих мер управления для защиты использования услуги, включая, например, возможности аудита, административное управление предприятием и эксплуатационные практики.
[127] На фиг.12 представлен список примерных факторов риска. Как указано в таблице, любой риск может идентифицироваться на основе его оси, категории, атрибута, описания, значения атрибута и/или значения индекса (такого как оценка или взвешивание).
[128] Механизм идентификации и профилирования
[129] Логика обнаружения угроз может включать в себя модуль для идентификации пользователя и устройства и профилирования (1013). Модуль профилирования может использовать перехваченный мандат для идентификации текущего пользователя. Модуль может выполнять профилирование организации и пользователя на основе пассивных записей трафика для идентификации некоторых или всех из следующих характеристик:
[130] Иерархия и поведение организации, включая шаблоны использования единственного пользователя;
[131] Роли компании, обнаруживающие администраторов, менеджеров и/или разные отделы;
[132] Местоположения компании, обнаруживающие разные местоположения подразделений и/или офиса и/или местоположения дома служащих;
[133] Распределение активности пользователя по часам дня, дням недели, месяцам года и специальным случаям, для уровня компании и/или уровня единственного пользователя; и
[134] Ежедневный режим пользователя, включая ежедневные местоположения, времена активности, приложения и шаблоны использования.
[135] Модуль идентификации и профилирования устройства также может быть выполнен с возможностью различения и идентификации устройств пользователя по сеансам и браузерам на основе информации, полученной из:
[136] Сеансов отслеживания со специальным куки-файлом сеанса, который хранят идентификацию устройства, идентификацию пользователя и информацию о сеансе для любого приложения SaaS, в котором пользователь зарегистрирован;
[137] Внесение JavaScript в страницы, чтобы идентифицировать устройства, выполняющие доступ через прокси;
[138] Межбраузерное хранение для связи сеансов, управляемых с разных браузеров на одном и том же устройстве; и
[139] База данных унифицированных идентификаторов для отслеживания сеансов, устройств и связей между ними.
[140] Обратная связь
[141] Логика характеризации угроз может включать в себя способы построения модели контролируемого обучения для предупреждений безопасности. Система может собирать обратную связь по предупреждениям, привлекать как информационные технологии (IT), так и служащих и динамически строить профиль пользователя посредством запроса пользователя в отношении подозрительных шаблонов и/или привлекать супервизора, если пользователь кажется подозрительным (например, ненадежный пользователь).
[142] Виртуальная сеть
[143] В предпочтительном варианте осуществления система, описанная выше, может быть на связи с отдельной виртуальной сетью (1020), в которой фиктивная организация выполняет активность по различным приложениям SaaS и контролируется шлюзом безопасности. В этом варианте осуществления виртуальная сеть может представлять собой изолированную сеть, поддерживаемую для целей исследования и тестирования. В других вариантах осуществления виртуальная сеть может быть встроена в действующую систему мониторинга сети и обнаружения угроз. Характеристики фиктивной организации и шаблоны использования могут проверяться по информации от реальных организаций, которые затем записываются шлюзом безопасности. Аномалии могут случайно вставляться в фиктивный трафик для тестирования модуля обнаружения. Аномалии могут представлять или шаблоны подозрительного поведения или атаки. Аномалии могут собираться от различных источников, включая фактические аномалии, записанные шлюзом безопасности, и аномалии, которые существуют на практике, и обнаруживаются независимым исследованием.
[144] Виртуальная сеть может использоваться для выполнения исследования по будущим функциональным возможностям обеспечения безопасности, а также для тестирования разных компонентов системы в тяжелом режиме и измерения процентов ложноположительных и ложноотрицательных обнаружений.
[145] Виртуальная сеть может включать в себя виртуального клиента (1021), а также отдельные реализации шлюза (1022) безопасности, модуля (1023) обнаружения и механизма (1024) предупреждений. Изменения, которые должны быть сделаны в механизме (1014) предупреждений, могут тестироваться сначала на механизме (1024) виртуальных предупреждений.
[146] Взвешивание рисков/угроз
[147] Как указано в примере, представленном на фиг.12, идентифицированные риски могут ассоциироваться со значением индекса в индексе (1015) облачной услуги. Это значение индекса может использоваться для взвешивания факторов риска относительно друг друга. В некоторых вариантах осуществления многочисленные факторы риска могут оцениваться вместе. В качестве неограничивающего примера, значения индекса для угроз, идентифицированных в течение периода времени в сетевом трафике, могут суммироваться вместе для получения индикатора угрозы с числовым значением.
[148] Ответное действие
[149] Взвешивание риска может подаваться на модуль (1012) обнаружения и/или на механизм (1014) предупреждений. Модуль обнаружения затем может предпринимать действие над сетевым трафиком на основе, в целом или частично, информации о взвешенной угрозе, и механизм предупреждений затем может предоставить предупреждение клиенту (1001) или провайдеру (1030) SaaS. В некоторых вариантах осуществления модуль обнаружения может предоставлять инструкцию шлюзу (1011) безопасности на отбрасывание пакетов, посылаемых клиенту (1001) от провайдера (1030) SaaS, основываясь на выходном сигнале модуля (1012) обнаружения.
[150] Архитектура модуля отыскания
[151] В некоторых вариантах осуществления модуль отыскания может быть выполнен с возможностью инспектирования сетевого трафика между провайдером сетевого программного обеспечения как услуга (SaaS) и клиентом. В этих вариантах осуществления система может быть выполнена с возможностью работы с таким трафиком между провайдером SaaS и клиентским вычислительным устройством, когда это вычислительное устройство подключено к провайдеру SaaS по общедоступной сети (такой как Интернет) без каких-либо элементов управления или ограничений, накладываемых на клиентское устройство или сеть. В некоторых из этих вариантов осуществления, не является необходимым конфигурирование клиентского устройства. Модуль отыскания может включать в себя базу данных приложений SaaS, содержимое которой описывается более подробно ниже.
[152] В некоторых из этих вариантов осуществления модуль отыскания может быть встроен в управляемый сетевой прокси связи. Хотя ссылка может быть сделана в данном документе на прокси, понятно, что прокси может быть встроен в одно или несколько сетевых устройств. Кроме того, управляемый сетевой прокси может быть децентрализован, и функции управляемого сетевого прокси могут быть распределены по многочисленным машинам в разных географических регионах.
[153] В других вариантах осуществления модуль отыскания не выполнен с возможностью непосредственного инспектирования сетевого трафика, проходящего между провайдером сетевого программного обеспечения как услуга (SaaS) и клиентом. В этих вариантах осуществления модуль отыскания может инициировать активность отыскания SaaS с любого устройства в сети. Модуль отыскания может включать в себя сервер апплетов и базу данных приложений SaaS, содержимое которой описывается более подробно ниже.
[154] Отыскание среды SaaS
[155] Модуль отыскания, находящийся или на независимом устройстве, или в сетевом прокси, может быть выполнен с возможностью идентифицирования шаблонов доступа и использования для любой среды SaaS. Как используется в данном документе, среда SaaS может включать в себя платформу SaaS, любое приложение, исполняющееся или установленное на платформе, данные, хранимое на платформе, и/или конфигурационные параметры отдельно или в комбинации с другими факторами.
[156] Примерная система и способ отыскания среды SaaS изображены на фиг.13. Как показано, клиентский компьютер может представлять собой администратора или пользователя подобного типа с достаточными привилегиями для выполнения функций отыскания. Модуль отыскания может быть воплощен в виде исполняемых инструкций на клиентском устройстве, таких как приложение, апплет, дополнительный подключаемый модуль или другой вид кода. В некоторых вариантах осуществления клиент может загружать и исполнять приложение (такое как Java-апплет), выполненное с возможностью исполнения на любом компьютере организации и создания моментального отчета. Дополнительно, система может быть выполнена для непрерывного отыскания, используя услугу, которая выполняется в фоновом режиме компьютера организации или клиента и позволяет выполнять непрерывный мониторинг SaaS.
[157] Система может включать в себя базу данных приложений SaaS для хранения данных, представляющих широкий диапазон и произвольное количество приложений SaaS и их характеристики. В качестве неограничивающих примеров, база данных приложений может включать в себя, среди других записей, записи для любого приложения SaaS, известного, что оно используется на любой платформе. Записи могут обновляться на регулярной основе (например, ежедневно) от многочисленных источников данных.
[158] Записи приложения SaaS могут включать в себя различные метрики, определяющие уровень безопасности конкретного SaaS и/или приложения SaaS. В качестве неограничивающих примеров, записанные метрики могут включать в себя: зашифрованы ли данные при хранении, уровень шифрования SSL, присутствие или отсутствие встроенных функциональных возможностей обеспечения безопасности, местоположения базы данных и центра сбора данных и т.д.
[159] Система может быть выполнена с возможностью автоматического выполнения отыскания оценки риска для данной платформы или приложения SaaS, основываясь на любой из метрик, описанных выше. Процесс отыскания риска облачной услуги может исполнять процедуры для выполнения пассивного отыскания и/или активного отыскания среды SaaS.
[160] Пассивное отыскание
[161] В некоторых вариантах осуществления процессы пассивного отыскания могут использоваться для определения, к каким приложениям SaaS и/или хранилищам данных был выполнен доступ пользователем или был вызван доступ пользователем.
[162] Система может быть выполнена с возможностью определения, является ли локально сконфигурированный сервер службы имен доменов (DNS) общедоступным или организационным (на основе открытого списка общедоступных серверов DNS). Если он организационный, система может запросить сервер DNS предприятия (не многократно) в отношении конкретных доменов SaaS. Основываясь на ответе, система может определить, было ли недавно обращение к конкретному приложению, файлу или набору данных из этой сети предприятия. Если запрос является успешным, система может определить, что недавний доступ был выполнен с предприятия. В противном случае, если запрос не является успешным, система может определить, что недавний запрос не был выполнен с предприятия.
[163] Активное отыскание
[164] Система может быть выполнена с возможностью использования целевых запросов для тестирования, является некоторое SaaS доступным в некоторой организационной сети, и, таким образом, определения, блокируется ли конкретное SaaS в организационной сети. Например, модуль отыскания может предпринять попытку выборки заданного URL на SaaS. Если попытка выборки является успешной, тогда SaaS может быть отмечено как незаблокированное. Если попытка выборки не является успешной, тогда SaaS может быть отмечено как заблокированное.
[165] В некоторых вариантах осуществления активное отыскание может использоваться для контроля проблем конфигурирования. Например, администратор, возможно, не сконфигурировал запоминающее устройство SaaS, но запоминающее устройство все же расходуется.
[166] Предупреждения
[167] Результаты процесса пассивного и/или активного отыскания могут посылаться на сервер отыскания или другое местоположение для электронного хранения. Результаты могут подвергаться автоматизированному и/или ручному анализу.
[168] Основываясь на результатах процесса отыскания, могут генерироваться автоматизированные предупреждения и отчеты использования облака. Например, еженедельно и/или ежемесячно отчеты использования облака могут автоматически генерироваться на основе данных использования, хранимых в базе данных. Использованные новые и обладающие определенной тенденцией облачные услуги могут быть показаны отдельно или вместе с подробными анализами риска. В некоторых вариантах осуществления использование приложения SaaS с высоким риском может запускать автоматические предупреждения по электронной почте или другими средствами.
[169] Захват трафика SaaS
[170] Реализации прокси суффикса сталкиваются с проблемой динамически сгенерированного контента на клиентской стороне. Современные веб-приложения, такие как платформа Google Apps, используют большое количество кода на клиентской стороне (JavaScript). Это может сделать реализацию прокси суффикса значительно более трудной, так как основные функции прокси являются недостаточными, и требуется дополнительное вмешательство в код на клиентской стороны.
[171] Как описано в данном документе, прокси суффикса может использоваться для поддержания URL и веб-доступов проксированной веб-страницы в пределах удержания прокси. Это выполняется добавлением суффикса к URL на странице. В контексте статических страниц (например, тех, которые не содержат исполняемый клиентом код JavaScript), это может выполняться на стороне сервера посредством прокси. Способ включает в себя синтаксический анализ HTML и использование регулярных выражений для замены URL на странице.
[172] Управляемый сетевой прокси может быть выполнен с возможностью инспектирования трафика и обнаружения адресов Интернета SaaS. В некоторых вариантах осуществления управляемый сетевой прокси может быть выполнен с возможностью инспектирования сетевого трафика в отношении адресов Интернета (таких как унифицированные указатели ресурса, унифицированные идентификаторы ресурса и т.д.). В качестве неограничивающих примеров, сетевой прокси может декомпилировать, разбирать или дизассемблировать сетевой трафик для инспектирования. Управляемый сетевой прокси может быть выполнен с возможностью модифицирования сетевого трафика между клиентским устройством и провайдером SaaS, так что сетевые адреса не предоставляются пользовательскому устройству, которые бы направляли клиентское устройство на непосредственный доступ к ресурсу SaaS, обходя управляемый сетевой прокси. Если обнаруживается адрес Интернета SaaS, этот адрес может перезаписываться в адрес на сетевом прокси прибавлением имени домена для услуги сетевого прокси к исходному сетевому адресу.
[173] Прокси суффикса может быть выполнен для обработки персональной страницы посредством обработки ответов сервера SaaS, так что последующие запросы обрабатываются посредством прокси суффикса. Обработка может зависеть от типа файла и типа ответа. В качестве неограничивающих примеров, обрабатываемые типы файлов могут включать в себя HTML или JavaScript, и ответы могут включать в себя сжатые gzip-ом ответы или разбитые на фрагменты ответы. Прокси суффикса может быть выполнен с возможностью эмулирования любого контента, включая веб-страницы, посылаемые от провайдера SaaS. Прокси суффикса может быть выполнен с возможностью инспектирования и/или декомпилирования любого контента для идентификации любых ссылаемых страниц и/или URL, присутствующих в контенте, и перезаписи этих URL.
[174] В некоторых случаях инспектирование потребует исполняющийся код или сценарии, передаваемые между клиентом и провайдером SaaS. Например, JavaScript может эмулироваться на сетевом прокси для обнаружения генерирования сетевых адресов, которые непосредственно обращаются к провайдеру SaaS. Если адреса непосредственного доступа идентифицируются в контенте, контент может модифицироваться, чтобы переписывать адреса для ссылки на сетевой прокси.
[175] Прокси, использующий трансляцию JavaScript на лету
[176] С JavaScript на клиентской стороне возможны изменения в процессе выполнения объектной модели документов (DOM) страницы, и, как результат, возможно клиентскому браузеру создавать или модифицировать элементы DOM с URL без суффикса (так как прокси на стороне сервера не имеет возможности их замены). Ниже описаны системы и способы для ограничения доступа кода JavaScript веб-приложения к DOM.
[177] Сущность ограничения может быть такой, что изменения веб-URL в DOM из исходного кода JavaScript будут контролироваться компонентом времени выполнения прокси. С кэшированием может быть уменьшено любое влияние на рабочие характеристики времени выполнения кода JavaScript.
[178] Код мониторинга может вызываться для доступов для чтения и записи в элементы DOM, так что к записям URL в DOM добавляется суффикс, и суффикс удаляется при считывании URL из DOM. В результате, может быть разделение между URL, видимыми кодом JavaScript «пользователя» (например, кодом веб-приложений) и самим браузером (DOM и его представление JavaScript). В результате, исходный код JavaScript может эффективно сохраняться внутри среды прокси, так что предотвращается связь с исходным сервером (около прокси).
[179] Реализация прокси на стороне сервера
[180] Код JavaScript, который загружается как часть веб-приложения, может получаться с исходного сервера в любом из нескольких видов, включая встроенные сценарии внутри HTML-страниц и файлы JavaScript (обычно с типом контента «text/javascript»). Системы, описанные в данном документе, также могут быть выполнены для работы с кодом, сценарием или контентом других типов, таким как CSS.
[181] Обычно, браузер сначала загружает главную HTML-страницу и затем, впоследствии, загружает все ссылаемые и встроенные сценарии. Дополнительный JavaScript (или содержащие HTML сценарии) также может загружаться динамически посредством веб-приложения, используя, например, оператор «eval».
[182] Так как динамическая загрузка кода первоначально выполняется статически загруженным кодом (или, если загружен, другим динамическим кодом), система может взять управление исполнением посредством модифицирования статического кода JavaScript во время этапа загрузки страницы на прокси-сервер. Модифицирования кода могут выполняться, так что будущий динамически загружаемый код будет модифицироваться во время выполнения, и конкретные изменения DOM могут перехватываться, чтобы обеспечить выполнение вышеупомянутых правил, которые позволят странице оставаться под управлением прокси.
[183] Модификация динамически загружаемого кода может достигаться посылкой динамически оцененного кода на прокси или приемом динамически оцененного кода на прокси для обработки, и затем предоставлением возможности загрузки нового кода на клиентский браузер. Примерный способ операции без кэширования изображен на фиг.14. В некоторых вариантах осуществления кэширование может применяться для улучшения рабочих характеристик, как описано более подробно ниже и изображено на фиг.15.
[184] В качестве неограничивающих примеров, по меньшей мере для следующих элементов DOM и свойств может создаваться оболочка:
[185] 1. Свойства элементов HTML, которые содержат URL:
a. Элементы: «IFRAME», «STYLE», «LINK», «IMG», «AUDIO», «A», «FORM», «BASE» и «SCRIPT».
b. Для каждого одного, где они применяется, свойства: «src», «href» и «action».
c. Методы getAttribute и setAttribute этих элементов также могут использоваться для установки вышеупомянутых свойств.
[186] 2. Свойства элементов HTML, которые могут содержать поддерево DOM (т.е. больше HTML):
a. Метод «appendChild» может использоваться для добавления элементов (и кода) динамически.
b. Свойство «innerHTML» может использоваться для добавления дополнительного кода.
[187] 3. Свойства объекта «document», который может содержать URL или Hostname (имя хоста):
a. «cookie», «domain» - оба могут содержать исходный домен окна.
b. Метод «write» может использоваться для добавления элементов и кода на страницу.
[188] 4. Метод «open» объектов XMLHttpRequest содержит запрос URL.
[189] 5. Свойство «origin» объектов «MessageEvent» содержит исходное имя хоста.
[190] 6. Методы и свойства объекта «Window»:
a. «location» - может перенаправлять кадр на другой URL или определять текущее местоположение кадра.
b. Метод «postMessage» - имеет исходный аргумент.
c. «eval» и «execScript» - используются для динамической загрузки кода.
[191] Существуют другие такие элементы и свойства, и может быть создана оболочка для любого или для всех из них.
[192] Статический перехват кода JavaScript
[193] Статический перехват может использоваться для контента многочисленных типов, включая встроенные сценарии и файлы. На прокси-сервере проксированный код JavaScript может обрабатываться следующим образом:
[194] 1. Встроенные сценарии в HTML извлекаются и обрабатываются.
[195] 2. Код преобразуется в абстрактное синтаксическое дерево (AST) в соответствии со спецификацией API синтаксического анализатора Mozilla, используя библиотеки синтаксического анализа открытых исходных текстов.
[196] 3. AST проходится рекурсивно, и вызовы оболочек вставляются вокруг некоторых узлов AST, чтобы предоставить возможность перехвата.
[197] 4. Код может быть перестроен из AST с исправлениями и послан на клиентский браузер.
[198] 5. Может выполняться кэширование результирующего обработанного кода.
[199] Вставленные оболочки могут предоставлять возможность захвата изменений DOM на этапе выполнения. Оболочки могут применяться для охватывания любых или всех потенциальных доступов DOM.
[200] В качестве неограничивающих примеров, оболочки могут применяться к некоторым или всем следующим узлам AST:
[201] 1. MemberExpression:
a. Создаются оболочки для потенциальных доступов к свойствам объекта объектов DOM.
b. Создаются оболочки для операций снабжения нижними индексами с нелитеральными ключами.
c. Создается оболочка для доступа к конкретным свойствам (например, obj.src), если имя свойства совпадает с белым списком «интересных» свойств.
d. В конечном счете, оболочка времени выполнения принимает решение, являются ли необходимыми какие-либо изменения. В большинстве случаев - например, «ложноположительное обнаружение» - оболочка принимает решение не выполнять ничего.
[202] 2. Identifier:
a. Создаются оболочки для потенциальных доступов к белому списку глобальных Identifier (идентификаторов) (которые являются свойствами объекта DOM window, например «местоположение»).
b. Узлы AST Identifier могут появляться во многих несвязанных логических позициях в дереве. Создаются оболочки для экземпляров, где Identifier представляет доступ к глобальной переменной. Это определяется во время этапа обхода посредством проверки родительских узлов и устранения всех других случаев.
[203] 3. AssignmentExpression:
a. Присваивания ранее «отмеченным» MemberExpressions и Identifiers обрабатываются другой оболочкой, которая конкретно обрабатывает доступ «set».
b. Создаются оболочки для операторов присваивания «=» и «+=», так как относящиеся свойства DOM могут представлять собой строки (URL).
[204] 4. CallExpression:
a. CallExpressions, где ранее «отмеченные» MemberExpression или Identifier представляют собой вызываемую функцию, обрабатываются другой оболочкой, которая конкретно обрабатывает вызовы функции.
b. Существует специальный случай с вызовом «eval», который ведет себя подобно оператору, но представляется как вызов функции в AST.
[205] Примерный код перед и после создания оболочки:
[206] Поведение оболочек во время выполнения
[207] Может быть определено несколько разных функций оболочек (в соответствии с разными случаями создания оболочки во время фазы обхода AST):
[208] 1. wrapped_get, wrapped_set, wrapped_call - создание оболочки для доступа к MemberExpressions в соответствии с разными случаями использования.
[209] 2. wrapped_name_get, wrapped_name_set, wrapped_name_call - создание оболочки для доступа к глобальным Identifiers в соответствии с разными случаями использования.
[210] 3. wrapped_eval_param - специально обрабатывает код, пропущенный как параметр вызова «eval» (который может оказывать влияние на локальный контекст).
[211] В некоторых вариантах осуществления система может сначала обнаруживать, была ли вызвана оболочка на относящиеся объекты или свойства:
[212] 1. В оболочках «MemberExpression» имя свойства проверяется в отношении белого списка, а также индексированного объекта.
[213] 2. С оболочками «Identifier» также выполняется обращение за справкой к белому списку.
[214] 3. Определяется, что объекты являются некоторого типа (элементы «Document», «Window», HTML и т.п.) и также сравниваются с глобальными экземплярами, когда это применимо.
[215] Эта сравнения и поиски могут выполняться эффективно без существенного влияния на рабочие характеристики во многих случаях.
[216] Вызов оболочки может обрабатываться с использованием любой одной из различных процедур, включая, в качестве неограничивающих примеров:
[217] 1. Динамически загружаемый код процесса:
a. Новый код JavaScript посылается на специальную конечную точку REST API прокси для трансляции и кэширования, как описано ниже.
b. Это может происходить в оболочках «appendChild», «innerHTML», «eval», «execScript» и «write».
[218] 2. Добавление суффикса или удаление суффикса из URL или имени хоста.
[219] 3. Обнаружение вызова оболочки ложноположительного обнаружения и возобновление нормального исполнения.
[220] Обработчики оболочки, которые являются ответственными за обработку доступа DOM к связанным с URL свойствам или методам, могут быть разделены на логические группы, например:
[221] 1. getters - обрабатывают оболочки «get». Они удаляют суффикс у обрабатываемых URL.
a. Если выполняется обращение к методу («функции» типа JavaScript), возвращается «декоратор» (см. ниже).
[222] 2. setters - они обрабатывают оболочки «set». Они добавляют суффикс назначенным URL.
[223] 3. decorators - они обрабатывают оболочки «call». Они возвращают совпадающие с декоратором функции для методов с созданной оболочкой, которые добавляют суффикс или удаляют суффикс URL в соответствии тем, что представляет собой декодированный метод.
a. Этот декоратор может быть связан с корректным объектом, используя метод «bind» JavaScript. В случае оболочек «Identifier», корректным объектом является глобальный объект (в некоторых случаях окно). В случае оболочек «MemberExpression» им является индексируемый объект.
[224] Влияние на рабочие характеристики и оптимизации
[225] В некоторых случаях может быть влияние на рабочие характеристики от выполнения процессов, описанных в данном документе, некоторые из которых может испытывать пользователь проксированного веб-приложения из-за трансляции JavaScript и обхода AST по большим сценариям и оболочкам времени выполнения, предотвращающих оптимизирование оперативными компиляторами JavaScript кода в браузерах.
[226] Чтобы уменьшить издержки фазы трансляции, кэш может быть реализован:
[227] 1. На стороне сервера, элементы транслируемого кода JavaScript (например, встроенный сценарий, файл или запрос динамической трансляции) кэшируются локально на каждом сервере.
[228] 2. Вводы снабжаются ключом посредством криптографической хеш-функции исходного кода.
[229] 3. Кэш, таким образом, совместно используется пользователями прокси. Таким образом, только первый пользователь на каждом сервере испытывает влияние фазы трансляции для сценариев с общей загрузкой.
[230] 4. Конечная точка REST динамической трансляции сценариев также может быть выполнена с возможностью принятия вычисленной на стороне клиента хэш-функции и выполнения поиска в кэше с ее использованием. Это может уменьшить использование полосы пропускания загрузки в восходящем направлении для пользователей прокси. В данной конфигурации динамически сгенерированные сценарии почти никогда могут фактически не посылаться на прокси (за исключением первого раза).
[231] 5. Кроме того, ответы на запросы динамической трансляции (на хэш-функцию) возвращаются с заголовками HTTP «Управление кэш-памятью» или «Истекает», так что результат будет кэшироваться браузером клиента. Таким образом, маловероятно, что клиенту потребуется запрашивать прокси-сервер более одного раза на эти же динамически сгенерированные сценарии.
[232] При заданной вышеупомянутой оптимизации влияние фазы трансляции может быть существенно уменьшено по сравнению со случаями нормального использования.
[233] Влияние на рабочие характеристики времени исполнения оболочек может быть уменьшено некоторыми или всеми из:
[234] 1. Создания оптимизированного быстрого пути для несоответствующих/ложноположительных вызовов оболочки (на уровне кода). Это достигается написанием основных функций оболочки при помощи ограниченного поднабора JavaScript, который легко оптимизируется оперативным компилятором браузера.
[235] 2. Ручной интерфейс обслуживания, который позволяет выполнять профилирование и обнаружение ветвей кода, имеющих наибольшее количество удачных обращений к кэш-памяти, и делает возможным (вручную) удаления некоторых оболочек из транслируемого кода во внутренней кэш-памяти прокси.
[236] Реализация системы
[237] Системы и способы, описанные в данном документе, могут быть реализованы программными средствами, аппаратными средствами или любой их комбинацией. Системы и способы, описанные в данном документе. могут быть реализованы с использованием одного или нескольких вычислительных устройств, которые могут быть или могут не быть физически или логически изолированными друг от друга. Кроме того, различные аспекты способов, описанных в данном документе, могут объединяться или сливаться в другие функции.
[238] В некоторых вариантах осуществления системные элементы могут объединяться в единственное аппаратное устройство или разделяться на многочисленные аппаратные устройства. Если используются многочисленные аппаратные устройства, аппаратные устройства могут физически располагаться вблизи или удаленно друг от друга.
[239] Способы могут быть реализованы в продукте компьютерной программы, к которому может выполняться обращение с используемого компьютером или считываемого компьютером носителя данных, который обеспечивает программный код для использования компьютером или в связи с компьютером или любой системой исполнения инструкций. Используемым компьютером или считываемым компьютером носителем данных может быть любой аппарат, который может содержать или хранить программу для использования или в связи с компьютером или системой, аппаратом или устройством исполнения инструкций.
[240] Система обработки данных, пригодная для хранения и/или исполнения соответствующего программного кода, может включать в себя по меньшей мере один процессор, подсоединенный непосредственно или косвенно к компьютеризованным устройствам хранения данных, таким как элементы памяти. Устройства ввода/вывода (I/O) (включая, но не ограничиваясь клавиатурами, дисплеями, указательными устройствами и т.д.) могут быть подсоединены к системе. Сетевые адаптеры также могут подсоединяться к системе, делая возможным то, что система обработки данных становится подключенной к другим системам обработки данных или удаленным принтерам или устройствам хранения посредством промежуточных частых или общедоступных сетей. Чтобы обеспечить взаимодействие с пользователем, функциональные возможности могут быть реализованы на компьютере с устройством отображения, таким как электронно-лучевая трубка (CRT), жидкокристаллический дисплей (LCD) или монитор другого типа для отображения информации пользователю, клавиатурой и устройством ввода, таким как мышь или трекбол, посредством которого пользователь выполнять ввод в компьютер.
[241] Компьютерная программа может представлять собой набор инструкций, которые могут использоваться, непосредственно или косвенно, в компьютере. Системы и способы, описанные в данном документе, могут быть реализованы с использованием языков программирования и/или разметки, таких как Perl, Python, JAVA™, C++, C, C#, Visual Basic™, JavaScript™, PHP (гипертекстовый предпроцессор), Flash™, XML, HTML и др. или в комбинации языков программирования и/или разметки, включая компилируемые или интерпретируемые языки, и могут быть развернуты в любом виде, включая как автономную программу или как модуль, компонент, подпрограмму или другую единицу, пригодную для использования в вычислительной среде. Программное обеспечение может включать в себя, но не ограничиваться ими, аппаратно-программное обеспечение, резидентное программное обеспечение, микрокод и т.д. Протоколы и стандарты, такие как SOAP (простой протокол доступа к объектам)/HTTP, JSON (объектная нотация JavaScript), SQL (язык структурированных запросов) и т.д., могут использоваться при реализации интерфейсов между модулями программирования. Компоненты и функциональные возможности, описанные в данном документе, могут быть реализованы на любой настольной или серверной операционной системе, исполняющейся в виртуализированной или невиртуализированной среде, используя любой язык программирования, пригодный для разработки программного обеспечения, включая, но не ограничиваясь ими, разные версии Microsoft™ Windows™, Apple™ Mac™, iOS™, Unix™/X-Windows™, Linux™ и т.д.
[242] В некоторых вариантах осуществления один или несколько серверов могут функционировать в качестве файлового сервера и/или могут включать в себя один или несколько файлов, используемых для реализации способов изобретения, объединяемых приложением, выполняющимся на пользовательском компьютере и/или на другом сервере. Альтернативно, файловый сервер может включать в себя некоторые или все необходимые файлы, позволяющие выполнять вызов такого приложения удаленно пользовательским компьютером и/или сервером. Функции, описанные в соотношении различных серверов в данном документе (например, сервер приложений, сервер базы данных, веб-сервер, файловый сервер и т.д.), могут выполняться единственным сервером и/или множеством специализированных серверов в зависимости от характерных для реализации потребностей или параметров
[243] В некоторых вариантах осуществления система может включать в себя одну или несколько баз данных. Местоположение базы (баз) данных является дискреционным. В качестве неограничивающих примеров, база данных может находиться на носителе данных, который является локальным (и/или резидентным) для сервера (и/или пользовательского компьютера). Альтернативно, база данных может быть удаленной от любого или всех вычислительных устройств до тех пор, пока она может находится на связи (например, по сети) с одним или несколькими из них. В некоторых вариантах осуществления база данных может находиться в сети хранения данных (SAN). SAN может быть реализована в виде группы компьютеризованных устройств хранения данных. Некоторые или все необходимые файлы для выполнения функций, приписываемых компьютерам, могут сохраняться локально на соответствующем компьютере и/или удаленно, по необходимости. В некоторых вариантах осуществления база данных может быть реляционной базой данных, такой как база данных Oracle, которая предназначена для хранения, обновления и извлечения данных в ответ на форматированные SQL команды. База данных может управляться и/или поддерживаться сервером базы данных.
[244] Подходящие процессоры для исполнения программы инструкций включают в себя, но не ограничиваются ими, микропроцессоры общего или специального назначения, и единственный процессор или один из многочисленных процессоров или ядер, компьютера любого вида. Процессор может принимать и сохранять инструкции и данные от компьютеризованного устройства хранения данных, такого как постоянное запоминающее устройство, оперативное запоминающее устройство, оба или любая комбинация устройств хранения данных, описанных в данном документе. Процессор может включать в себя любую схему обработки или схему управления, действующую для управления операциями и рабочими характеристиками электронного устройства.
[245] Процессор также может включать в себя одно или несколько устройств хранения данных, или функционально соединен для выполнения связи с ними, для хранения данных. Такие устройства хранения данных могут включать в себя, в качестве неограничивающих примеров, магнитные диски (включая внутренние жесткие диски и съемные диски), магнитооптические диски, оптические диски, постоянное запоминающее устройство, оперативное запоминающее устройство и/или флэш-память. Устройства хранения, подходящие для материального воплощения инструкций компьютерной программы и данных, также могут включать в себя все виды энергонезависимой памяти, включая, например: устройства полупроводниковой памяти, такие как стираемое программируемое постоянное запоминающее устройство (EPROM), электрически стираемое программируемое постоянное запоминающее устройство (EEPROM) и устройства флэш-памяти; магнитные диски, такие как внутренние жесткие диски и съемные диски; магнитооптические диски; и/или диски CD-ROM (компакт-диски без возможности перезаписи) и DVD-ROM (цифровой многофункциональный диск без возможности перезаписи). Процессор и память могут быть дополнены специализированными интегральными схемами (ASIC), или встроены в них.
[246] Системы, модули и способы, описанные в данном документе, могут быть реализованы с использованием любой комбинации программных или аппаратных элементов. Системы, модули и способы, описанные в данном документе, могут быть реализованы с использованием одной или нескольких виртуальных машин, работающих отдельно или в комбинации друг с другом. Любое применимое решение виртуализации может использоваться для инкапсуляции платформы физической вычислительной машины в виртуальную машину, которая исполняется под управлением программного обеспечения виртуализации, выполняющегося на аппаратной вычислительной платформе или хосте. Виртуальная машина может иметь как аппаратные средства виртуальной системы, так и программное обеспечение гостевой операционной системы.
[247] Системы и способы, описанные в данном документе, могут быть реализованы в компьютерной системе, которая включает в себя компонент второго уровня, такой как сервер данных, или которая включает в себя компонент промежуточного программного обеспечения, такой как сервер приложений или Интернет-сервер, или которая включает в себя компонент первого уровня, такой как клиентский компьютер, имеющий графический пользовательский интерфейс или Интернет-браузер, или любую их комбинацию. Компоненты системы могут соединяться любым видом или средой передачи цифровых данных, такой как сеть передачи данных. Примеры сетей передачи данных, включают в себя, но не ограничиваются ими, локальную сеть (LAN), глобальную сеть (WAN) или любую из сетей, которая образует Интернет.
[248] Один или несколько вариантов осуществления изобретения может быть осуществлен на практике с другими конфигурациями компьютерной системы, включая карманные устройства, микропроцессорные системы, микропроцессорную или программируемую бытовую электронику, миникомпьютеры, универсальные вычислительные машины и т.д. Изобретение также может быть осуществлено на практике в распределенных вычислительных средах, где задачи выполняются устройствами удаленной обработки, которые связаны по сети.
[249] Хотя был описан один или несколько вариантов осуществления изобретения, различные изменения, дополнения, перестановки и эквиваленты его включены в объем изобретения.
| название | год | авторы | номер документа |
|---|---|---|---|
| СИСТЕМА И СПОСОБ ДЛЯ ОБРАБОТКИ ИНФОРМАЦИИ WEB-ОБЗОРА | 2014 |
|
RU2676880C2 |
| СПОСОБЫ И СИСТЕМЫ ОБРАБОТКИ ОБЪЕКТНЫХ МОДЕЛЕЙ ДОКУМЕНТОВ (DOM) ДЛЯ ОБРАБОТКИ ВИДЕОКОНТЕНТА | 2010 |
|
RU2475832C1 |
| Способ и система для динамической глобальной идентификации окружения пользователя | 2020 |
|
RU2751436C1 |
| СИСТЕМА И СПОСОБ ОБНАРУЖЕНИЯ ИНТЕЛЛЕКТУАЛЬНЫХ БОТОВ И ЗАЩИТЫ ОТ НИХ | 2020 |
|
RU2738337C1 |
| СИСТЕМЫ И СПОСОБЫ ДЛЯ ЗАЩИТЫ СЕТЕВЫХ УСТРОЙСТВ | 2015 |
|
RU2675055C2 |
| СПОСОБ ПРОВЕДЕНИЯ ТРАНСАКЦИЙ, КОМПЬЮТЕРИЗОВАННЫЙ СПОСОБ ЗАЩИТЫ СЕТЕВОГО СЕРВЕРА, ТРАНСАКЦИОННАЯ СИСТЕМА, СЕРВЕР ЭЛЕКТРОННОГО БУМАЖНИКА, КОМПЬЮТЕРИЗОВАННЫЙ СПОСОБ ВЫПОЛНЕНИЯ ОНЛАЙНОВЫХ ПОКУПОК (ВАРИАНТЫ) И КОМПЬЮТЕРИЗОВАННЫЙ СПОСОБ КОНТРОЛЯ ДОСТУПА | 2000 |
|
RU2252451C2 |
| УПРАВЛЕНИЕ СЕАНСОМ УДАЛЕННОГО ПРОСМОТРА | 2012 |
|
RU2589306C2 |
| УСТРОЙСТВО И СПОСОБ ДЛЯ ОБРАБОТКИ ИНТЕРАКТИВНОЙ УСЛУГИ | 2013 |
|
RU2594295C1 |
| ОРГАНИЗАЦИЯ ИСТОРИЧЕСКОЙ СЕССИИ ПРОСМОТРА | 2012 |
|
RU2595509C2 |
| УСТРОЙСТВО И СПОСОБ ДЛЯ СОЗДАНИЯ УЧЕТНЫХ ЗАПИСЕЙ СЛУЖБ И КОНФИГУРИРОВАНИЯ УСТРОЙСТВ | 2007 |
|
RU2426252C2 |
Способ содержащий этапы, на которых: принимают на прокси-сервере запрос контента, извлекают запрошенный контент с сервера, анализируют запрошенный контент, чтобы идентифицировать по меньшей мере одну исполняемую инструкцию из упомянутых исполняемых инструкций, модифицируют запрошенный контент, сохраняют на прокси-сервере модифицированный контент, передают модифицированный контент и отслеживают на прокси-сервере изменения во время выполнения в отношении объектной модели документов (DOM), осуществляемые клиентским устройством, чтобы контролировать любой осуществляемый во время выполнения доступ к DOM на считывание и запись при, по меньшей мере, считывании и записи по упомянутому URL с суффиксом. 2 н. и 4 з.п. ф-лы, 15 ил.
1. Способ обработки инструкций для модифицирования будущего запроса контента, содержащий этапы, на которых:
принимают на прокси-сервере, сконфигурированном как прокси суффикса, запрос контента, включающего в себя исполняемые инструкции, причем запрошенный контент включает в себя сценарий;
извлекают запрошенный контент с сервера, на котором размещено облачное приложение, и сохраняют запрошенный контент на прокси-сервере;
анализируют запрошенный контент, чтобы идентифицировать по меньшей мере одну исполняемую инструкцию из упомянутых исполняемых инструкций, сконфигурированную для генерирования URL-адреса облачного приложения;
модифицируют запрошенный контент посредством создания оболочки идентифицированной по меньшей мере одной инструкции для вызова альтернативной инструкции, при этом альтернативная инструкция выполнена с возможностью присоединения, в виде суффикса, идентификации прокси суффикса к упомянутому URL для создания URL с суффиксом;
сохраняют на прокси-сервере модифицированный контент, включающий в себя упомянутую по меньшей мере одну инструкцию с оболочкой;
передают модифицированный контент, включающий в себя упомянутую по меньшей мере одну инструкцию с оболочкой, на клиентское устройство; и
отслеживают на прокси-сервере изменения во время выполнения в отношении объектной модели документов (DOM), осуществляемые клиентским устройством, чтобы контролировать любой осуществляемый во время выполнения доступ к DOM на считывание и запись при, по меньшей мере, считывании и записи по упомянутому URL с суффиксом.
2. Способ по п.1, в котором сценарий представляет собой любой один из JavaScript и файла каскадной таблицы стилей (CSS).
3. Способ по п.1, дополнительно содержащий этапы, на которых:
определяют, сохраняется ли запрошенный контент в виде модифицированного, включающего в себя инструкцию с оболочкой, на прокси-сервере;
если запрошенный контент в виде модифицированного, включающего в себя инструкцию с оболочкой, сохраняется на прокси-сервере, посылают модифицированный контент на клиентское устройство без извлечения запрошенного контента с сервера.
4. Система связи, функционирующая как прокси суффикса для обработки инструкций для модифицирования будущего запроса контента, содержащая:
процессор и
память, причем в памяти содержатся упомянутые инструкции, которые при их исполнении процессором конфигурируют систему:
принимать запрос контента, включающего в себя исполняемые инструкции, причем запрошенный контент включает в себя сценарий;
извлекать запрошенный контент с сервера, на котором размещено облачное приложение;
сохранять запрошенный контент;
анализировать запрошенный контент, чтобы идентифицировать по меньшей мере одну исполняемую инструкцию из упомянутых исполняемых инструкций, сконфигурированную для генерирования URL-адреса облачного приложения;
модифицировать запрошенный контент посредством создания оболочки идентифицированной по меньшей мере одной инструкции для вызова альтернативной инструкции, при этом альтернативная инструкция выполнена с возможностью присоединения, в виде суффикса, идентификации прокси суффикса к упомянутому URL для создания URL с суффиксом;
сохранять модифицированный контент, включающий в себя упомянутую по меньшей мере одну инструкцию с оболочкой;
передавать модифицированный контент, включающий в себя упомянутую по меньшей мере одну инструкцию с оболочкой, на клиентское устройство; и
отслеживать изменения во время выполнения в отношении объектной модели документов (DOM), осуществляемые клиентским устройством, чтобы контролировать любой осуществляемый во время выполнения доступ к DOM на считывание и запись при, по меньшей мере, считывании и записи по упомянутому URL с суффиксом.
5. Система по п.4, в которой сценарий представляет собой любой один из JavaScript и файла каскадной таблицы стилей (CSS).
6. Система по п.4, при этом система дополнительно конфигурируется:
определять, сохраняется ли запрошенный контент в виде модифицированного, включающего в себя инструкцию с оболочкой, на прокси-сервере; и
если запрошенный контент в виде модифицированного, включающего в себя инструкцию с оболочкой, сохраняется на прокси-сервере, посылать модифицированный контент на клиентское устройство без извлечения запрошенного контента с сервера.
| Изложница с суживающимся книзу сечением и с вертикально перемещающимся днищем | 1924 |
|
SU2012A1 |
| Способ приготовления лака | 1924 |
|
SU2011A1 |
| US 6397246 B1, 28.05.2002 | |||
| Способ приготовления лака | 1924 |
|
SU2011A1 |
