Предшествующий уровень техники
1. Перекрестная ссылка на родственную заявку
По настоящей заявке на патент испрашивается приоритет по дате подачи предварительной заявки США № 60/862930, поданной 25 октября 2006 г., и заявки США № 11/923513 на полезную модель, поданной 24 октября 2007 г., которые полностью включены в этот документ по ссылке.
2. Область техники, к которой относится изобретение
Это изобретение, в общем, относится к управлению событием/информацией, относящимся к безопасности, (SIM или SIEM) и, в частности, к осуществлению доступа к модели узла сети (например, узла, на который нацелено событие) так, чтобы данные модели могли быть использованы вместе с событиями/информацией, относящимися к безопасности.
3. Описание предшествующего уровня техники
Область управления событием/информацией, относящимися к безопасности, (SIM или SIEM), в общем, имеет отношение к 1) сбору данных из сетей и сетевых устройств, которые отражают сетевую активность и/или работу устройств, и к 2) анализу упомянутых данных для увеличения безопасности. Например, данные могут анализироваться для идентификации атаки на сеть или сетевое устройство и определения, какой пользователь или машина являются ответственными. Если атака продолжается, то может быть принята ответная мера, чтобы помешать атаке или уменьшить вызываемый ею ущерб. Данные, которые собираются, обычно исходят от сообщения (например, события, предупреждения или сигнала тревоги) или записи в журнале регистрации, которые формируются сетевым устройством.
В сообщении или записи обычно указывается одно или более устройств компьютерной сети ("узлов сети"), которые вовлечены в сетевую активность. Например, в сообщении или записи может указываться узел, на который была направлена активность, ("целевой узел") и/или узел, из которого исходила активность, ("узел источника"). Хотя идентифицировать и исследовать атаку можно с использованием только собранных данных, часто полезно иметь дополнительную информацию, например, информацию об указанных узлах сети.
Информация об узле сети, называемая "моделью ресурса", может включать в себя, например, адрес Интернет-протокола (IP) узла, имя хоста узла, сеть, к которой принадлежит узел, роль узла в пределах предприятия, открытый порт в узле, программные средства, установленные в узле (например, операционную систему и приложения) и известные уязвимости или слабые стороны узла (называемые "незащищенными уязвимостями").
Доступ к моделям ресурса получают во время анализа безопасности. Анализ безопасности может быть выполнен или в пакетном режиме или в реальном времени. В пакетном режиме, когда принимаются события/информация, относящиеся к безопасности, они сохраняются. Позже, сохраненные события/информация, относящиеся к безопасности, анализируются. В режиме реального времени, когда принимаются события/информация, относящиеся к безопасности, они анализируются в реальном времени или почти в реальном времени.
Для того чтобы анализ безопасности осуществлялся в реальном времени (или почти в реальном времени), доступ к модели ресурса должен осуществляться в реальном времени (или почти в реальном времени). Это очень трудно осуществить, так как в минуту формируются тысячи событий, и в каждом событии указывается один или более узлов. Например, скорость события 5 000 событий/секунда и 4 узла/событие в результате приводят к 20 000 узлов/секунда. Для каждого узла идентифицируется его модель ресурса и к ней осуществляется доступ.
Требуется эффективный способ осуществления доступа к модели ресурса, чтобы модель ресурса могла использоваться в реальном времени вместе с событиями/информацией, относящимися к безопасности.
Сущность изобретения
Менеджер принимает одно или более событий и анализирует их для обнаружения атак. Событие описывает действие, затрагивающее устройство компьютерной сети, называемое "узлом сети". Событие включает в себя ссылку, называемую "ссылкой на узел", на один или более узлов (например, на узел, на который было направлено действие ("целевой узел") и/или узел, из которого исходило действие ("узел-источник")). Ссылка на узел включает в себя множество полей, например, адрес Интернет-протокола (IP), зону сети, имя хоста, адрес протокола управления доступом к среде (MAC) и идентификатор ресурса (assetID).
Поле assetID предназначено для сохранения уникального идентификатора (ID), который назначен узлу сети. Когда менеджер впервые принимает событие, поле assetID ссылки на узел является пустым. Позже, идентификатор, соответствующий "модели ресурса" узла, сохраняется в поле assetID. ID используется для получения модели ресурса, соответствующей узлу сети, связанному с ID, и определения, является ли узел сети членом конкретной категории. Менеджер осуществляет доступ к модели ресурса узла сети для выполнения анализа безопасности.
Модель ресурса является набором информации об узле сети. Эта информация может включать в себя, например, IP-адрес узла, имя хоста узла, сеть, к которой принадлежит узел, роль узла в пределах предприятия, открытый порт в узле, программные средства, установленные в узле (например, операционную систему и приложения) и список известных уязвимостей или слабых сторон узла (называемых "незащищенными уязвимостями").
Менеджер включает в себя модуль идентификатора и модуль категории. Модуль идентификатора обеспечивает выполняемые функции, относящиеся к уникальному ID, который назначен узлу сети, и включает в себя модуль поиска и модуль управления. Модуль поиска определяет ID узла сети на основе различных характеристик узла сети, например, IP-адреса, имени хоста, зоны сети и/или адреса протокола управления доступом к среде (MAC). Эти порции информации используются как ключи в одной или нескольких поисковых структурах данных (например, поисковых таблицах). Если поиск является успешным (например, найдено значение, которое связано с ключом), то это значение (которое является ID модели ресурса узла) возвращается. Модуль управления отслеживает, какие ID были назначены узлам сети, и какие ID нет.
Модуль категории обеспечивает выполняемые функции, относящиеся к категориям, и включают в себя модуль поиска и модуль управления. Модуль поиска определяет, является ли конкретный узел сети (ресурс) членом (то есть, находится в пределах) конкретной категории. Для того, чтобы определить это, модуль категории использует данные категории. Данные категории используют транзитивное замыкание (TC) для моделирования иерархического и динамического пространства категоризации (свойств), которые могут быть присоединены к модели ресурса. TC хранится в памяти как набор битовых карт, где битовая карта соответствует конкретной группе или категории ресурса. Бит 0/1 в битовой карте представляет, существует ли связь между конкретной категорией/группой ресурса и ресурсом. Уникальный ID ресурса служит индексом в битовой карте транзитивного замыкания. Модуль управления по мере необходимости обновляет данные категории.
Краткое описание чертежей
Фиг.1 - схема высокого уровня, иллюстрирующая среду, содержащую систему управления событием/информацией, относящимся к безопасности, согласно одному варианту осуществления.
Фиг.2 - блок-схема высокого уровня компьютера, действующего как менеджер системы управления событием/информацией, относящимся к безопасности, согласно одному варианту осуществления.
Фиг.3 - блок-схема высокого уровня, иллюстрирующая модули, находящиеся в менеджере системы управления событием/информацией, относящимся к безопасности, согласно одному варианту осуществления.
Фиг.4 - блок-схема, представляющая способ определения идентификатора, связанного с узлом сети, согласно одному варианту осуществления.
На фиг.5 представлены иллюстративные структуры данных для поисковой таблицы с IP-адресами.
На фиг.6 представлены две поисковые таблицы, которые используются для выполнения поиска по имени хоста.
На фиг.7 представлена иллюстративная структура данных для поисковой таблицы с MAC-адресами.
На упомянутых чертежах вариант осуществления изображен только с целью иллюстрации. Из следующего описания специалисту в данной области техники будет очевидно, что могут быть использованы альтернативные варианты осуществления структур и способов, представленных в этом документе, не отступая от принципов, описанных в этом документе.
Подробное описание вариантов осуществления
В этом документе описана компьютерная система для перехватывания событий безопасности из гетерогенных источников, стандартизации таких событий в общепринятую схему и осуществления взаимной корреляции таких стандартизированных событий с правилами создания метасобытий. Система (один вариант осуществления которой явно является программным обеспечением) обеспечивает возможность агрегирования, корреляции, обнаружения и исследовательского отслеживания подозрительной сетевой активности из множества устройств безопасности. Настоящая система также поддерживает управление ответом, анализ запроса для данного случая, представление отчета и повторное использование для криминалистического анализа и графическую визуализацию сетевых угроз и активности.
Хотя настоящая система будет обсуждаться со ссылкой на различные иллюстрированные примеры, не следует интерпретировать эти примеры как ограничение более широкого существа и объема настоящего изобретения. Например, примеры, представленные в этом документе, описывают распределенных агентов, менеджеров и системы управления, которые являются всего лишь одним вариантом осуществления настоящего изобретения. Общие концепции и охват настоящего изобретения намного шире и могут распространяться на любую компьютерную или сетевую систему безопасности. Кроме того, примеры сообщений, которые можно передавать в компоненты системы и из них, и схемы данных, которые могут использоваться компонентами системы, даны в попытке дополнительного описания настоящего изобретения, но не подразумевается, что они являются всеобъемлющими примерами, и их не следует считать таковыми.
Некоторые последующие части подробного описания представлены в терминах алгоритмов и символических представлений операций над данными в машинной памяти. Эти алгоритмические описания и представления являются средствами, используемыми специалистами в области вычислительной техники для наиболее эффективной передачи сущности их работы другим специалистам в данной области техники. В данной работе, и, как правило, алгоритм представляют согласующейся последовательностью этапов, приводящих к требуемому результату. Упомянутые этапы являются этапами, требующими физических манипуляций физическими величинами. Обычно, хотя не обязательно, эти величины принимают форму электрических или магнитных сигналов, которые можно сохранять, передавать, объединять, сравнивать и которыми можно манипулировать каким-либо иным образом. Иногда оказывалось удобным, преимущественно по причине общепринятого использования, называть эти сигналы битами, значениями, элементами, символами, знаками, термами, числами и т.п. Однако следует принять во внимание, что все эти и подобные термины должны быть связаны с соответствующими физическими величинами и являются просто удобными обозначениями, относящимися к этим величинам. Если специально не обусловлено иное, будет понято, что на протяжении всего описания настоящего изобретения использование таких терминов, как "обработка", "вычисление", "расчет", "определение", "вывод на экран" и т.п., относится к действию и процессам компьютерной системы или аналогичного электронного вычислительного устройства, которое манипулирует данными, представленными как физические (электронные) величины в блоках памяти и регистрах компьютерной системы, и преобразует их в другие данные, также представленные как физические величины в регистрах или блоках памяти компьютерной системы или других таких устройствах отображения, передачи или хранения информации.
Как указано выше, один вариант осуществления настоящего изобретения реализован в программном обеспечении, то есть в компьютерно-читаемых командах, которые при исполнении одним или несколькими компьютерными процессорами/системами, дают указания процессорам/системам выполнить указанные действия. Такое программное обеспечение может находиться на одном или нескольких компьютерно-читаемых носителях информации, например, жестких дисках, дисках CD-ROM, дисках DVD-ROM, постоянном запоминающем устройстве, стираемом запоминающем устройстве и так далее. Такое программное обеспечение может быть распределено в одном или нескольких этих носителях информации или может быть сделано доступным для загрузки в одной или нескольких компьютерных сетях (например, Интернет). Независимо от формата, способы компьютерного программирования, визуализации и обработки, обсуждаемые в этом документе, являются просто примерами типов программирования, визуализации и обработки, которые могут использоваться для реализации аспектов настоящего изобретения. Эти примеры никоим образом не ограничивают настоящее изобретение, которое лучше всего можно понять из формулы изобретения, которая следует за этим описанием.
Архитектура системы
Фиг.1 является схемой высокого уровня, иллюстрирующей среду, содержащую систему 10 управления событием/информацией, относящимися к безопасности, согласно одному варианту осуществления. Система 10 включает в себя агентов 12, один или более менеджеров 14 и одну или более систем управления 16 (которые могут включать в себя их версии на основе браузера). В некоторых вариантах осуществления, агенты, менеджеры и/или системы управления могут быть объединены на одной платформе или распределены на двух, трех или большем количестве платформ (таких, как в иллюстрированном примере). Использование этой многоуровневой архитектуры поддерживает масштабируемость по мере роста компьютерной сети или системы.
Агенты 12 являются программами, которые обеспечивают эффективный перехват и фильтрацию локальных данных о событиях в реальном времени (или почти в реальном времени) из множества приложений и/или устройств защиты сети. Первичными источниками событий безопасности являются общепринятые сетевые элементы, включающие в себя брандмауэры, системы обнаружения несанкционированного вторжения и регистрационные журналы операционной системы. Агенты 12 могут собирать события из любого источника, который формирует журналы регистрации событий или сообщения, и могут работать в «родном» устройстве, в точках объединения в пределах сети и/или посредством ловушек простого протокола сетевого управления (SNMP).
Агенты 12 конфигурируются посредством и автоматизированных и не автоматизированных процессов и через связанные файлы конфигурации. Каждый агент 12 может включать в себя один или более программных модулей, в том числе компонент стандартизации, компонент поправки времени, компонент агрегирования, компонент группирования, компонент преобразователя адресов, транспортный компонент и/или дополнительные компоненты. Эти компоненты могут быть активизированы и/или отключены посредством соответствующих команд в файле конфигурации.
Менеджеры 14 являются серверными компонентами, которые дополнительно объединяют, фильтруют и осуществляют взаимную корреляцию событий, принятых из агентов, с использованием механизма 18 правил и централизованной базы 20 данных событий. Одной ролью менеджера 14 является перехват и хранение всех данных о прошлых событиях и в реальном времени для создания (посредством менеджера 22 базы данных) полной картины на уровне предприятия активности средств безопасности. Менеджер 14 также обеспечивает централизованное администрирование, оповещение (посредством одного или нескольких устройств 24 оповещения) и представление отчета, а также базу 28 знаний и последовательность выполняемых действий по управлению случаем. Менеджер 14 может быть развернут на любой компьютерной аппаратной платформе, и один вариант осуществления использует систему управления реляционными базами данных, например, базу данных OracleTM для реализации компонента хранилища данных событий. Связь между менеджером 14 и агентами 12 может быть двунаправленной (например, обеспечивать возможность менеджеру 14 передавать команды в платформы, размещающие агентов 12) и зашифрованной. В некоторых инсталляциях менеджеры 14 могут действовать как концентраторы для множества агентов 12 и могут пересылать информацию другим менеджерам (например, развернутым в штаб-квартире корпорации).
Менеджер 14 включает в себя одного или более менеджеров 26 агентов, которые ответственны за прием сообщений данных события, передаваемых агентами 12. Там, где реализована двусторонняя связь с агентами 12, эти менеджеры 26 агентов могут быть использованы для передачи сообщений агентам 12. Если используется шифрование для связи агент-менеджер (которое является необязательным), менеджер 26 агентов отвечает за расшифровку сообщений, принимаемых от агентов 12, и шифровку любых сообщений, передаваемых агентам 12.
Системы управления 16 являются приложениями на основе компьютера (например, рабочей станции), которые обеспечивают возможность специалистам в области безопасности выполнять повседневные задачи административного управления и эксплуатации, например, текущий мониторинг событий, авторскую разработку правил, исследование инцидентов и представление отчетов. Списки контроля доступа обеспечивают возможность множеству специалистов в области безопасности использовать идентичные систему и базу данных событий, причем каждый имеет свои собственные вид, правила корреляции, предупреждения, отчеты и базу знаний, соответствующие их ответственности. Один менеджер 14 может поддерживать множество систем управления 16.
В некоторых вариантах осуществления основанная на браузере версия системы управления 16 может использоваться для обеспечения доступа к событиям безопасности, статьям базы знаний, отчетам, оповещениям и случаям. Соответственно, менеджер 14 может включать в себя компонент web-сервера, доступный через web-браузер, который размещен на личном или малогабаритном компьютере (который заменяет систему управления 16), для обеспечения некоторых или всех функций, выполняемых системой управления 16. Доступ через браузер, в частности, полезен для специалистов в области безопасности, которые находятся вдали от систем управления 16, и для пользователей, работающих по совместительству. Связь между системами управления 16 и менеджером 14 двунаправленная и может быть зашифрована.
Посредством вышеописанной архитектуры система может поддерживать централизованную или децентрализованную среду. Это полезно, потому что организации может потребоваться реализация одного экземпляра системы 10 и использование списка контроля доступа для разделения пользователей. В качестве альтернативы, организация может выбрать развертывание отдельных систем 10 для каждой из нескольких групп и объединение результатов на "ведущем" уровне. Подобным развертыванием можно также осуществить размещение "вслед за солнцем", где географически рассредоточенные равноправные группы сотрудничают друг с другом посредством передачи основной ответственности за контроль группе, работающей в настоящее время в обычные часы работы. Системы 10 могут также быть развернуты в корпоративной иерархии, где отделы компании работают отдельно и поддерживают накопление в централизованной функции управления.
Система 10 управления событием/информацией, относящимся к безопасности, также описана в заявке США № 10/308415, поданной 2 декабря 2002 г., которая полностью включена в этот документ по ссылке.
Введение в модели ресурса
Менеджер 14 принимает одно или более событий и анализирует их для обнаружения атак. Событие описывает действие, затрагивающее устройство компьютерной сети, называемое "узлом сети". Иллюстративные узлы сети включают в себя портативные или настольные компьютеры, серверы (например, серверы электронной почты, серверы управления доступом и серверы доменной системы имен (DNS)), брандмауэры, маршрутизаторы, системы обнаружения несанкционированного вторжения, системы виртуальной частной сети (VPN) и принтеры.
В одном варианте осуществления, событие указывает один или более узлов (например, узел, на который было направлено действие ("целевой узел") и/или узел, из которого исходило действие ("узел источника")). В этом варианте осуществления событие включает в себя ссылку на каждый узел (называемую "ссылкой на узел"). Ссылка на узел включает в себя множество полей, например, адрес Интернет-протокола (IP), зону сети, имя хоста, адрес протокола управления доступом к среде (MAC) и идентификатор ресурса (assetID). (Зона сети является сегментом сети. Метка идентифицирует зону сети и используется, чтобы отличать частные адресные пространства друг от друга). К узлу сети обращаются с использованием IP-адреса. К некоторым устройствам, например, серверам, подключенным к множеству физических линий данных, можно обращаться посредством любого из множества IP-адресов. В этой ситуации каждый IP-адрес обрабатывается как отдельный узел сети. Соответственно, одно устройство может "содержать" множество узлов сети.
Поле assetID предназначено для сохранения уникального идентификатора (ID), который назначен узлу сети. Когда менеджер впервые принимает событие, поле assetID ссылки на узел является пустым. Позже, идентификатор, соответствующий "модели ресурса" узла, сохраняется в поле assetID. В одном варианте осуществления, ID используется для получения модели ресурса, соответствующей узлу сети, связанному с ID. В другом варианте осуществления, ID используется для определения, является ли узел сети членом конкретной категории (описано ниже). Модель ресурса является набором информации об узле сети. Эта информация может включать в себя, например, IP-адрес узла, имя хоста узла, сеть, к которой принадлежит узел, роль узла в пределах предприятия, открытый порт в узле и программные средства, установленные в узле (например, операционную систему и приложения). В одном варианте осуществления, модель ресурса включает в себя список известных уязвимостей или слабых сторон узла, называемых "незащищенными уязвимостями". Уязвимость в общем определяется как конфигурация или состояние узла, которые могут быть использованы для оказания воздействия, отличного от того, которое подразумевалось изготовителем узла.
Менеджер 14 осуществляет доступ к модели ресурса узла сети для выполнения анализа безопасности. Например, событие может описывать попытку использования одной или нескольких известных уязвимостей, называемых "используемыми уязвимостями". Менеджер 14 может определять незащищенные уязвимости целевого узла (посредством осуществления доступа к модели ресурса узла) и затем сравнивать их с используемыми уязвимостями. Угроза обнаруживается, если уязвимость появляется и как незащищенная уязвимость и как используемая уязвимость. Обнаружение угрозы также описано в патенте США № 7260844, выданном 21 августа 2007 г., который полностью включен в этот документ по ссылке.
В качестве другого примера, рассмотрим стандарт в рамках федеральных стандартов обработки информации (FIPS), который требует категоризации узла согласно его допуску для конфиденциальности. Событие может описывать действие, которое может аннулировать конфиденциальность на конкретном узле. Менеджер 14 может заметить это событие и определить, насколько важна конфиденциальность для этого узла (посредством осуществления доступа к модели ресурса узла). Если конфиденциальность важна, то может быть создан аварийный мандат для отслеживания нарушения.
Может быть определена категория узла сети (ресурса) для описания его свойств. Категория реализуется как "группа". Например, для спецификации того, что конкретный узел работает под управлением операционной системы Windows 2003 Server, ресурс узла помещается в группу "/AllCategories/OperatingSystems/Microsoft/Windows/2003Server". Категории могут быть иерархическими. Например, "2003Server" является дочерним элементом категории "Windows", которая является дочерним элементом категории "Microsoft" и т.д. Другим примером иерархических категорий являются географические классификации (например, континент/страна/штат/округ/...).
С учетом ссылки на узел и категорию, менеджер 14 может определять, является ли узел членом (то есть, находится в пределах) этой категории. Может также быть определена категория группы ресурса, как и зоны сети и группы зоны сети.
Анализ безопасности, соответственно, включает в себя идентификацию модели ресурса и осуществление к ней доступа и проверку членства в категории. Для того чтобы анализ безопасности выполнялся в реальном времени (или почти в реальном времени), идентификация модели ресурса и доступ к ней и проверки категории должны также выполняться в реальном времени (или почти в реальном времени). Это очень трудно осуществить, так как в минуту формируются тысячи событий, и в каждом событии указывается одна или более ссылок на узлы. Например, скорость события 5 000 событий/секунда и 4 ссылки на узлы/событие в результате приводят к 20 000 ссылок на узлы/секунда. Для каждой ссылки на узел, идентифицируется ее модель ресурса и осуществляется к ней доступ, и выполняется несколько проверок членства в категории.
Архитектура Менеджера
Фиг.2 является блок-схемой высокого уровня компьютера 200, действующего как менеджер 14 системы 10 управления событием/информацией, относящимся к безопасности, согласно одному варианту осуществления. Изображен, по меньшей мере, один процессор 202, подключенный к шине 204. Также к шине 204 подключены память 206, устройство 208 хранения, клавиатура 210, графический адаптер 212, указательное устройство 214 и сетевой адаптер 216. В одном варианте осуществления выполняемые функции шины 204 обеспечены соединительным набором микросхем. Дисплей 218 соединен с графическим адаптером 212.
Устройство 208 хранения является любым устройством, которое может хранить данные, например, жестким диском, постоянным запоминающим устройством на компакт-диске (CD-ROM), DVD или твердотельным запоминающим устройством. Память 206 содержит команды и данные, используемые процессором 202. Указательное устройство 214 может быть мышью, трекболом или другим типом указательного устройства и используется в комбинации с клавиатурой 210 для ввода данных в компьютер 200. Графический адаптер 212 выводит на экран дисплея 218 изображения и другую информацию. Сетевой адаптер 216 подключает компьютер 200 к локальной или глобальной сети.
Как известно в данной области техники, компьютер 200 может иметь отличные и/или другие компоненты, чем те, которые изображены на фиг.2. Кроме того, в компьютере 200 могут отсутствовать некоторые изображенные компоненты. Например, в компьютере 200, действующем как менеджер 14, могут отсутствовать клавиатура 210, указательное устройство 214, графический адаптер 212 и/или дисплей 218. Кроме того, устройство 208 хранения может быть локальным и/или удаленным от компьютера 200 (таким как реализованное в сети хранения данных (SAN)).
Программный агент 12 (например, SmartConnector от ArcSight, Inc., Cupertino, CA (Калифорния)) принимает, от датчика, сообщение относительно узла сети. После этого агент 12 обрабатывает сообщение для создания события. В одном варианте осуществления, событие представляет структуру данных, которая включает в себя одно или более полей, где каждое поле может содержать значение. Значение поля определяется на основе сообщения, принятого от датчика. Агент отправляет событие в менеджер 14 (например, Enterprise Security Manager от ArcSight, Inc.) для хранения и анализа.
Менеджер 14 включает в себя модуль, называемый распознавателем ресурса события (EAR) (не изображен). Напомним, что событие может включать в себя ссылку на узел. Модуль EAR связывает эту ссылку на узел с ее соответствующей моделью ресурса и помечает ссылку на узел уникальным идентификатором (ID). Например, модуль EAR модифицирует событие посредством сохранения ID в поле assetID ссылки на узел, которое ранее было пустым. В одном варианте осуществления, событие включает в себя ссылки на четыре узла: источник сетевого трафика, адрес назначения сетевого трафика, хост агента и хост датчика, который сообщил о событии. Для каждой ссылки на узел, модуль EAR связывает ссылку на узел с ее соответствующей моделью ресурса и помечает ссылку на узел уникальным ID.
Фиг.3 является блок-схемой высокого уровня, иллюстрирующей модули, находящиеся в менеджере 14 системы 10 управления событием/информацией, относящимся к безопасности, согласно одному варианту осуществления. Как изображено на фиг.3, вариант осуществления менеджера 14 включает в себя модуль 300 идентификатора и модуль 310 категории. В других вариантах осуществления могут быть другие и/или дополнительные модули, по сравнению с теми, которые изображены на чертеже. Например, менеджер 14 может содержать модули, изображенные на фиг.1, хотя для ясности эти модули не включены в фиг.3. Кроме того, функции могут быть распределены среди модулей способом, отличным от способа, описанного в данной работе.
Модуль 300 идентификатора обеспечивает выполняемые функции, относящиеся к уникальному идентификатору (ID), который назначен узлу сети. В одном варианте осуществления, ID является целым числом (например, значением, выраженным в простом типе данных "int"). В одном варианте осуществления, ID является "локально" уникальным. Например, он уникален в пределах конкретного менеджера 14, но не обязательно уникален во всем множестве менеджеров. В другом варианте осуществления, ID является универсальным уникальным идентификатором (UUID) или глобально уникальным идентификатором (GUID). В этом варианте осуществления, ID является "глобально" уникальным. Например, он уникален во всем множестве менеджеров. Объем памяти, требуемый для хранения UUID или GUID, составляет, по меньшей мере, 16 байтов. Для хранения целочисленного значения требуется меньше памяти. Так как может потребоваться хранить в памяти более одного миллиона ID одновременно, то это различие в памяти является существенным.
В одном варианте осуществления, ID используется для получения модели ресурса, соответствующей узлу сети, связанному с ID. Например, модуль управления ресурсом (не изображен) поддерживает информацию модели ресурса и при запросе возвращает модель ресурса с использованием ID. Модель ресурса представляется, например, структурой данных объекта (например, в языке объектно-ориентированного программирования, таком как Java). В другом варианте осуществления, ID используется для определения, является ли узел сети членом конкретной категории.
В иллюстративном варианте осуществления, модуль 300 идентификатора включает в себя модуль 320 поиска, модуль 330 управления, таблицу 340 интервала и одну или более поисковых таблиц 350. Модуль 320 поиска определяет ID узла сети на основе различных характеристик узла сети. Эти характеристики присутствуют в ссылке на узел в событии, как описано выше. ID конкретного узла сети определяется на основе IP-адреса узла, имени хоста, зоны сети и/или адреса протокола управления доступом к среде (MAC). В одном варианте осуществления, эти порции информации используются как ключи в одной или нескольких структурах данных поиска (поисковых таблицах 350, описанных ниже). Если поиск является успешным (например, найдено значение, которое связано с ключом), то это значение (которое является ID модели ресурса узла) возвращается.
Фиг.4 является блок-схемой, представляющей способ определения идентификатора, связанного с узлом сети, согласно одному варианту осуществления. До начала способа 400 принимается информация об узле сети. Эта информация включает в себя одно или большее количество из следующего: IP-адреса узла, зоны сети, имени хоста и MAC-адреса.
Предпринимается 410 поиск с использованием MAC-адреса узла. Если в результате этого успешно найдено соответствие, то возвращается 420 ID. Если в результате MAC-поиска соответствие успешно не найдено, то предпринимается 430 поиск с использованием зоны сети и IP-адреса узла. Если в результате этого успешно найдено соответствие, то возвращается 420 ID. Если в результате IP-поиска соответствие успешно не найдено, то предпринимается 440 поиск с использованием зоны сети и имени хоста узла. Если в результате этого успешно найдено соответствие, то возвращается 420 ID. Если в результате поиска по имени хоста соответствие успешно не найдено, то предпринимается 450 поиск с использованием диапазона для ресурса, который охватывает IP-адрес узла в пределах зоны сети узла. Если в результате этого успешно найдено соответствие, то возвращается 420 ID. В одном варианте осуществления, порядок, в котором предпринимается каждый поиск (MAC-поиск, IP-поиск, поиск по имени хоста и поиск по диапазону для ресурса), является конфигурируемым.
Поисковые таблицы 350 используются модулем 320 поиска для определения ID узла сети на основе различных характеристик узла сети. В одном варианте осуществления существует четыре типа поисковых таблиц 350: поисковые таблицы IP-адрес/зона сети, поисковые таблицы имя хоста/зона сети, поисковые таблицы с MAC-адресами и поисковые таблицы с диапазонами для ресурсов. Каждая из этих поисковых таблиц заполняется модулем управления ресурсом (описанным выше).
Поиск по IP-адресу/зоне сети
В одном варианте осуществления, поисковая таблица с IP-адресами использует ключи и значения простого типа данных "int" (integer (целое число)). Ключ, который используется для выполнения поиска, является 32-разрядным целым числом, которое представляет IP-адрес. Значение, которое возвращается поиском, является целочисленным ID соответствующей модели ресурса. Так как IP-адреса уникальны только в пределах зоны сети, то в каждой зоне сети существует своя собственная поисковая IP-таблица.
В одном варианте осуществления, поисковая таблица настраивается и оптимизируется для демонстрации использования памяти небольшой емкости и/или высокой скорости. Настраиваемая таблица может быть или хэш-картой или массивом.
На фиг.5 представлены иллюстративные структуры данных для поисковой таблицы с IP-адресами. Иллюстративные структуры данных включают в себя хэш-карту 500 с открытой адресацией и массив 510 с прямым доступом. В общепринятых реализациях хэш-карт с открытой адресацией используются три массива: один для хранения ключей, один для хранения значений и один для указания, допустимы ли пары ключ-значение. Здесь ключи (IP-адреса) и значения (ID) хранятся вместе в одном целочисленном массиве 500. В иллюстративном варианте осуществления, ключ и связанное с ним значение размещены вблизи друг от друга (например, рядом друг с другом) в массиве для лучшей локализации кэша. Другими словами, хэш-карта с открытой адресацией реализована с использованием одного массива посредством чередования значений массива ключей и массива значений. Реализация хэш-карты с открытой адресацией с использованием одного массива известна специалистам в данной области техники и описана в Data Structures/Hash Tables (Структуры данных/хеш-таблицы) Wikibook (Викикнига) по адресу http://en.wikibooks.org/wiki/Data_Structures/Hash_Tables.
Некоторые IP-адреса могут быть недопустимыми в пределах зоны сети. В одном варианте осуществления, в структуре данных поиска недействительный адрес используется для указания того, что соответствующее значение (здесь ID) пусто.
В качестве альтернативы, может использоваться массив 510 с прямым доступом, где каждое значение (здесь ID) сохраняется как один элемент массива. Индекс этого элемента в массиве определяется на основе ключа (здесь IP-адреса). В одном варианте осуществления, индекс равен смещению IP-адреса в пределах конкретного диапазона адресов. Например, рассмотрим зону сети, которая включает в себя IP-адреса, которые изменяются в пределах от 192.168.0.100 до 192.168.0.200. У IP-адреса 192.168.0.150 индекс был бы равным 50, так как его смещение от нижней границы диапазона равно 50. Соответственно, его ID был бы сохранен в array[50], где array является именем массива, и 50 является индексом в массиве. Следовательно, нет необходимости сохранять ключ. Вместо этого он преобразован в индекс, который далее используется для доступа к конкретному элементу массива.
Рассмотрим другую зону сети и диапазон ее IP-адресов (например, 192.168.0.0 по 192.168.0.255). Если IP-адреса в пределах упомянутого диапазона заполнены плотно (как должно быть), то используется прямой массив. При этом осуществляется более быстрый поиск с экономией памяти, потому что IP-адреса не должны явно храниться в поисковой таблице.
Если IP-адреса заполнены исключительно редко в пределах зоны сети, то при использовании поиска с прямым массивом будут существенные непроизводительные затраты памяти, и вместо него используется хэш-карта. В одном варианте осуществления, тип внутренней структуры данных, используемой для поисковой таблицы с IP-адресами, основан на коэффициенте загрузки IP-адресов (например, плотности заполнения) в пределах IP-адресов, связанных с зоной сети. Структура данных может переключаться между поиском 510 в массиве и хэш-поиском 500 по мере необходимости (например, если плотность заполнения IP-адресов изменяется).
Поиск по имени хоста/зоне сети
Так как имена хостов уникальны только в пределах зоны сети, то в каждой зоне сети существует своя собственная поисковая таблица с именами хостов. В одном варианте осуществления, поисковая таблица настраивается и оптимизируется для демонстрации использования памяти небольшой емкости и/или высокой скорости.
В одном варианте осуществления, поиск по имени хоста выполняется с использованием двух поисковых таблиц. Каждая поисковая таблица может быть реализована или как хэш-карта или как массив. На фиг.6 изображены две поисковые таблицы, которые используются для выполнения поиска по имени хоста. Для простоты поисковые таблицы изображены в формате строка/столбец, где каждая строка представляет пару ключ/значение.
Имя хоста разделяется на две части: имя машины и имя домена. Например, имя хоста 'test.arcsight.com" разделяется на "test" (имя машины) и "arcsight.com" (имя домена). Первая поисковая таблица 600 использует ключи простого типа данных "string" (строка) и значения простого типа данных "int" (integer (целое число)). Ключ, который используется для выполнения поиска, является строкой (изображенной как "DN1"), которая представляет имя домена. Значение, которое возвращается поиском, является целочисленной ссылкой (изображенной как "Ref1") на вторую таблицу 610, которая связана с этим именем домена. Посредством этого избегают непроизводительного расходования пространства памяти при сохранении множества копий одного имени домена.
Вторая поисковая таблица 610 использует ключи и значения простого типа данных "int" (integer (целое число)). Ключ, который используется для выполнения поиска, является целым числом (изображен как "MN1/DN1"), который представляет имя машины и имя домена (см. ниже иллюстративную реализацию). Значение, которое возвращается поиском, является целочисленным ID (изображен как "ID1") соответствующей модели ресурса.
В одном варианте осуществления, ключ для второй поисковой таблицы 610 основан на целочисленном хэше имени машины и целочисленной ссылке имени домена (например, сохраненной в таблице с именами доменов). В одном варианте осуществления имя машины хранится как байтовый массив UTF-8 (8-битовый формат преобразования UCS/Unicode) для компактного хранения. В Java символ кодируется как UTF-16, который требует 2 байтов памяти для каждого символа. Кодирование UTF-8 требует только 1 байта для каждого символа, если имя машины содержит только символы ASCII, что должно иметь место в большинстве случаев. (Интернет-спецификация таблицы хостов министерства обороны США (DoD Internet Host Table Specification) (RFC 952) определяет, что имя хоста должно содержать только символы ASCII).
В общепринятых реализациях хэш-карт с открытой адресацией используются три массива: один для хранения ключей, один для хранения значений и один для указания, допустимы ли пары ключ-значение. Здесь, для второй поисковой таблицы 610, ключи (целые числа, которые представляют имя машины и имя домена) и значения (ID) хранятся вместе в одном целочисленном массиве. Ключ и связанное с ним значение размещены вблизи друг от друга (например, рядом друг с другом) в массиве для лучшей локализации кэша. Другими словами, хэш-карта с открытой адресацией реализована с использованием одного массива посредством чередования значений массива ключей и массива значений.
В одном варианте осуществления, вторая поисковая таблица 610 реализована с использованием одного целочисленного массива для каждой записи таблицы (например, одного массива для каждого имени хоста). Этот массив включает в себя байтовый массив UTF-8 имен машин, хэш-код имени машины, ссылку на имя домена и связанный ID. Так как объекты не используются, то избегают связанных с ними непроизводительных издержек, что также уменьшает использование памяти. Кроме того, улучшается локализация кэша, что увеличивает производительность.
В хэш-картах с открытой адресацией, вычисляется хэш, выбирается запись в этой точке и проверяется ключ для определения, существует ли ответная справка. Здесь, имя домена используется с первой таблицей 600 для получения ссылки на имя домена. В одном варианте осуществления, для оптимизации проверки ключа, полученная ссылка (целое число) сравнивается со ссылкой, хранящейся в записи (также целое число). Далее, хэш имени машины (целое число, которое было вычислено как часть вычисления хэша для этого поиска) сравнивается с хэшем, хранящимся в записи (также целое число). Наконец, строка с именем машины сравнивается со строкой, хранящейся в записи. Возвращаемое значение является целочисленным ID модели ресурса, связанным с данным именем хоста.
Поиск по MAC-адресу
Поисковая таблица с MAC-адресами использует ключи простого типа данных "long" (long integer (длинное целое)) и значения простого типа данных "int" (integer (целое число)). Ключ, который используется для выполнения поиска, является 64-разрядным целым числом, которое представляет MAC-адрес. Значение, которое возвращается поиском, является целочисленным ID соответствующей модели ресурса. Так как MAC-адреса глобально уникальны, то используется только одна поисковая MAC-таблица.
В одном варианте осуществления, поисковая таблица настраивается и оптимизируется для демонстрации использования памяти небольшой емкости и/или высокой скорости. Настраиваемая таблица может быть или хэш-картой или массивом.
На фиг.7 представлена иллюстративная структура данных для поисковой таблицы с MAC-адресами. Иллюстративная структура данных является хэш-картой 700 с открытой адресацией. В общепринятых реализациях хэш-карт с открытой адресацией используются три массива: один для хранения ключей, один для хранения значений и один для указания, допустимы ли пары ключ-значение. Здесь ключи (MAC-адреса) и значения (ID) хранятся вместе в одном целочисленном массиве. Ключ и связанное с ним значение размещены вблизи друг от друга (например, рядом друг с другом) в массиве для лучшей локализации кэша. Другими словами, хэш-карта с открытой адресацией реализована с использованием одного массива посредством чередования значений массива ключей и массива значений.
Некоторые MAC-адреса могут быть недопустимыми. В одном варианте осуществления, в структуре данных поиска недействительный адрес используется для указания того, что соответствующее значение (здесь ID) пусто.
Поиск по диапазону ресурсов
Ключ, который используется для выполнения поиска, является парой IP-адресов, которые вместе представляют диапазон IP-адресов. Значение, которое возвращается поиском, является целочисленным ID соответствующей модели ресурса. Так как IP-адреса уникальны только в пределах зоны сети, то в каждой зоне сети существует своя собственная поисковая таблица с диапазонами для ресурсов. До выполнения поиска, проверяется рассматриваемый IP-адрес для определения диапазона IP-адресов, который включал бы в себя этот IP-адрес.
Модуль 330 управления отслеживает, какие ID были назначены узлам сети, и какие ID нет. Модуль 330 управления также обеспечивает ID, когда требуется (например, для связи с новым узлом сети). ID создаются близко друг к другу для минимизации интервалов между ними. Когда узлы сети (и связанные с ними модели ресурса) удаляются из системы, между ID, которые используются, могут начать появляться интервалы. В одном варианте осуществления, модуль 330 управления управляет интервалами между ID следующим образом: Во время начальной загрузки составляется таблица интервалов (таблица 340 интервалов). Когда добавляется новый узел сети (и соответственно создается новая модель ресурса), назначается ID. Если существует интервал, то используется существующий ID в пределах интервала. Если интервала не существует, то создается и используется новый ID.
Таблица 340 интервалов используется модулем 330 управления для управления интервалами между ID, как описано выше.
Модуль 310 категории обеспечивает выполняемые функции, относящиеся к категориям. Напомним, что может быть определена категория ресурса для описания его свойств. Категория реализуется как "группа". Например, для спецификации того, что конкретный узел работает под управлением операционной системы Windows 2003 Server, ресурс узла помещается в группу "/AllCategories/OperatingSystems/Microsoft/Windows/2003Server". Категории могут быть иерархическими. Например, "2003Server" является дочерним элементом категории "Windows", которая является дочерним элементом категории "Microsoft" и т.д. Другим примером иерархических категорий являются географические классификации (например, континент/страна/штат/округ/...). Может также быть определена категория группы ресурса, как и зоны сети и группы зоны сети.
В иллюстративном варианте осуществления, модуль 310 категории включает в себя модуль 360 поиска, модуль 370 управления, данные 380 категории и данные 390 обновления. Модуль 360 поиска определяет, является ли конкретный узел сети (ресурс) членом (то есть, находится в пределах) конкретной категории. Например, может возникнуть вопрос "является ли этот Ресурс членом этой Категории или какой-либо категории-потомка?" Для того, чтобы определить это, модуль 310 категории использует данные 380 категории.
Данные 380 категории используют транзитивное замыкание (TC) для моделирования иерархического и динамического пространства категоризации (свойств), которые могут быть присоединены к модели ресурса. TC в основном является ориентированным ациклическим графом (DAG), где между каждым предком (категорией или группой) и каждым потомком (ресурсом) может существовать ребро. Существование ребра указывает, что ресурс-потомок является членом категории- или группы-предка или членом любой из категорий- или групп-потомков предка. Ребро строится в дополнение к ребрам родитель-дочерний элемент, которые уже существуют в DAG. Наличие ребер TC обеспечивает возможность О(1) эффективности времени проверки того, является ли данный дочерний элемент (ресурс) потомком данного родителя (категории или группы).
Рассмотрим иерархию категории, описанную выше:
A1lCategories/OperatingSystems/Microsoft/Windows/2003Server. Часто, знание, работает ли узел сети под управлением операционной системы 2003Server, является менее интересным, чем знание, работает ли этот узел под управлением операционной системы Microsoft вообще (например, любого вида). Если между категорией "Microsoft" и узлом не существует никакого ребра, то должен быть выполнен обход дерева. Например, обход может начинаться в категории Microsoft, и поиск на соответствие ведется вниз среди потомков. В качестве альтернативы, обход может начинаться в узле сети и поиск ведется вверх. Обход дерева занимает непредсказуемое количество времени и теоретически всегда требует больших затрат, чем поиск O(1) по полному списку ребер между всеми предками и всеми потомками (то есть, транзитивное замыкание). Недостатком использования TC является то, что оно требует хранения большого количества информации. Например, количество ребер предок-потомок экспоненциально больше, чем количество ребер родитель-дочерний элемент.
Структура данных, которая представляет транзитивное замыкание, будет использоваться для поиска в реальном времени со скоростями 5 000 событий в секунду и 4 ссылки на узел для каждого события и 100 проверок членства в категории для каждой ссылки на узел (для в общей сложности 2 000 000 проверок в секунду). Если структура данных сохраняется во вспомогательном хранилище или кэшируется общепринятым способом (например, с наиболее длительным отсутствием обращений - LRU), то производительность проверок категории не будет ни быстрой, ни предсказуемой. В одном варианте осуществления структура данных TC сохраняется в памяти индексированным способом так, чтобы проверки членства в категории могли быть выполнены быстро.
В одном варианте осуществления транзитивное замыкание сохраняется в памяти как набор битовых карт, где битовая карта является массивом битов, и в каждом бите хранится булево (Boolean) значение. Это аналогично индексации битовых карт. Здесь, битовая карта соответствует конкретной группе или категории ресурса. Бит 0/1 в битовой карте представляет, существует ли связь между конкретной категорией/группой ресурса и ресурсом. Если существует 1 миллион ресурсов и 1000 категорий/групп ресурса, то потенциально требуется 1 миллион* 1000=1 миллиард битов памяти. Напомним, что модель ресурса идентифицируется посредством ID, который является целочисленным значением. В одном варианте осуществления, этот ID служит индексом в битовой карте транзитивного замыкания.
Ресурс обычно относится к приблизительно тридцати категориям из общего количества 1000 категорий. Соответственно, вероятность, что конкретный ресурс относится к конкретной категории, равна 30/1000=3%. Это означает, что в битовой карте установлено приблизительно 3% битов (то есть, имеют значения, которые отличаются от других). Соответственно, битовая карта будет очень разреженной. В одном варианте осуществления битовую карту сжимают с использованием такого способа, как Word-Aligned Hybrid (гибридная схема пословного выравнивания) для уменьшения требуемого объема и конфигурации памяти.
При выполнении проверки категории, быстрее использовать несжатую битовую карту, чем сжатую битовую карту. В одном варианте осуществления, битовые карты для категорий, которые проверяются чаще, хранятся в несжатом виде, в то время как битовые карты для категорий, которые проверяются реже, хранятся в сжатом виде. Это обеспечивает возможность очень быстрых проверок категории для большинства проверок при минимальных затратах на дополнительные требуемые объемы и конфигурации памяти, тем самым увеличивая среднюю производительность проверки категории.
Модуль 370 управления по мере необходимости обновляет данные 380 категории. Со временем, модели ресурса могут изменяться, и структура данных транзитивного замыкания должна обновляться. Если битовая карта сжата, то ее обновление включает в себя ее распаковку, применение обновления и повторное ее сжатие. В одном варианте осуществления, обновления к соответствующим битовым картам применяются немедленно, сжаты они или нет.
В другом варианте осуществления, если битовая карта сжата, то ее не обновляют немедленно. Вместо этого обновление временно сохраняют (в данных 390 обновления) и применяют позже вместе с другими обновлениями к идентичной битовой карте (например, посредством задачи, которая периодически выполняется, например, раз в минуту). Так как распаковка и сжатие битовой карты занимает время, то быстрее распаковать битовую карту один раз, выполнить множество обновлений, и затем сжать битовую карту. В этом варианте осуществления, когда требуется проверка категории, которая включает в себя сжатую битовую карту, осуществляют доступ к временной памяти с обновлением (данным 390 обновления) для определения, существуют ли какие-нибудь обновления. Если поиск во временной памяти (которая является маленькой и, следовательно, поддерживает быстрый поиск) с обновлением оказался неудачным, то поиск выполняется в сжатой битовой карте. Если битовая карта является несжатой, то ее обновляют немедленно.
Данные 390 обновления используются модулем 370 управления для задержки обновления данных 380 категории, как описано выше.
Вышеупомянутое описание включено (в этот документ) для иллюстрации функционирования предпочтительных вариантов осуществления, и нет намерения ограничивать объем изобретения. Объем изобретения должен ограничиваться только в соответствии со следующей формулой изобретения. Из вышеуказанного обсуждения специалистам в соответствующей области техники будут очевидны многие изменения, которые, тем не менее, охватываются существом и объемом изобретения.
Изобретение относится к методам осуществления доступа к узлам сети. Технический результат заключается в обеспечении осуществления доступа к модели ресурса, чтобы модель использовалась в реальном времени вместе с событиями/информацией, относящимися к безопасности. Узлу сети назначается уникальный идентификатор, который используется для получения модели ресурса, соответствующей этому узлу, и для определения, является ли этот узел членом конкретной категории. Модель ресурса является набором информации об узле. Модуль поиска идентификатора определяет идентификатор узла на основе характеристик узла, которые используются как ключи в поисковых структурах данных. Модуль поиска категории определяет, является ли конкретный узел членом конкретной категории, с использованием транзитивного замыкания для моделирования категорий, которые могут быть присоединены к модели ресурса. Транзитивное замыкание для конкретной категории ресурса хранится как битовая карта, аналогично индексации битовых карт. 5 н. и 11 з.п. ф-лы, 7 ил.
1. Способ определения уникального идентификатора, связанного с узлом сети, содержащий:
осуществление запроса поисковой структуры данных с адресами Интернет-протокола (IP) с использованием IP-адреса, связанного с узлом сети, причем поисковая структура данных с IP-адресами содержит массив, содержащий один или более элементов, причем элемент хранится в индексе, при этом элемент содержит уникальный идентификатор, связанный с конкретным узлом сети, а индекс определяется на основании IP-адреса, связанного с конкретным узлом сети;
возвращение уникального идентификатора, связанного с узлом сети, и выполнение одного из:
использования возвращенного уникального идентификатора для получения модели ресурса, связанного с узлом сети, и использования возвращенного уникального идентификатора для определения, является ли узел сети членом категории.
2. Способ по п.1, в котором осуществление запроса поисковой структуры данных с IP-адресами с использованием IP-адреса, связанного с узлом сети, содержит определение индекса на основании IP-адреса, связанного с конкретным узлом сети.
3. Способ по п.1, в котором структура данных поиска с IP-адресами сконфигурирована с возможностью автоматического изменения с реализации на основе массива на реализацию на основе таблицы.
4. Способ определения уникального идентификатора, связанного с узлом сети, содержащий:
запрос первой поисковой таблицы с использованием имени домена, связанного с узлом сети, причем эта первая поисковая таблица содержит одну или более пар, пара содержит имя домена, связанное с конкретным узлом сети, и ссылку на одну вторую поисковую таблицу из множества вторых поисковых таблиц, причем каждая из вторых поисковых таблиц содержит одну или более пар, пара содержит имя хоста, связанное с конкретным узлом сети, и уникальный идентификатор, связанный с конкретным узлом сети,
запрос второй поисковой таблицы, на которую указывает ссылка, с использованием имени хоста, связанного с узлом сети, возвращение уникального идентификатора, связанного с узлом сети, и выполнение одного из:
использования возвращенного уникального идентификатора для получения модели ресурса, связанного с узлом сети, и использования возвращенного уникального идентификатора для определения, является ли узел сети членом категории.
5. Способ по п.4, в котором уникальный идентификатор, связанный с узлом сети, является значением простого типа данных "int" (integer - (целое число)).
6. Способ по п.4, в котором использование возвращенного уникального идентификатора для определения, является ли узел сети членом категории, содержит:
идентификацию транзитивного замыкания, причем это транзитивное замыкание включает в себя одно или более ребер между узлами-предками и узлами-потомками, причем узел-предок представляет категорию, узел-потомок представляет узел сети, ребро указывает, что узел-потомок является членом узла-предка, осуществление запроса транзитивного замыкания с использованием возвращенного уникального идентификатора и категории, и
возвращение булевого значения, которое указывает, является ли узел сети членом категории.
7. Способ по п.6, в котором запрос транзитивного замыкания с использованием возвращенного уникального идентификатора и категории содержит определение, существует ли ребро между узлом-потомком, связанным с возвращенным уникальным идентификатором, и узлом-предком, связанным с категорией.
8. Способ по п.4, в котором использование возвращенного уникального идентификатора для определения, является ли узел сети членом категории, содержит:
идентификацию битовой карты, связанной с категорией, причем эта битовая карта содержит множество битов, значение бита указывает, является ли узел сети членом категории,
запрос битовой карты с использованием возвращенного уникального идентификатора, и
возвращение булевого значения, которое указывает, является ли узел сети членом категории.
9. Способ по п.4, в котором запрос битовой карты с использованием возвращенного уникального идентификатора содержит:
идентификацию бита в пределах битовой карты при использовании возвращенного уникального идентификатора как индекса в битовой карте, и
возвращение значения идентифицированного бита.
10. Компьютерно-читаемый носитель, содержащий код компьютерной программы для выполнения способа определения уникального идентификатора, связанного с узлом сети, причем этот способ содержит:
запрос поисковой таблицы с адресами Интернет-протокола (IP) с использованием IP-адреса, связанного с узлом сети, причем эта поисковая таблица с IP-адресами содержит одну или более пар, пара содержит IP-адрес, связанный с конкретным узлом сети, и уникальный идентификатор, связанный с конкретным узлом сети,
возвращение уникального идентификатора, связанного с узлом сети, и выполнение одного из:
использования возвращенного уникального идентификатора для получения модели ресурса, связанного с узлом сети, и
использования возвращенного уникального идентификатора для определения, является ли узел сети членом категории;
причем поисковая структура данных с IP-адресами автоматически преобразуется в массив, содержащий один или более элементов, причем элемент хранится в индексе, при этом элемент содержит уникальный идентификатор, связанный с конкретным узлом сети, а индекс определяется на основании IP-адреса, связанного с конкретным узлом сети.
11. Компьютерно-читаемый носитель по п.10, в котором IP-адрес, связанный с конкретным узлом сети, является значением простого типа данных "int" (integer - (целое число)).
12. Компьютерно-читаемый носитель по п.10, в котором запрос поисковой структуры данных с IP-адресами с использованием IP-адреса, связанного с узлом сети, содержит определение пары, которая содержит IP-адрес, связанный с узлом сети.
13. Компьютерно-читаемый носитель по п.10, в котором таблица является хэш-картой с открытой адресацией.
14. Компьютерно-читаемый носитель по п.10, в котором таблица является хэш-картой с открытой адресацией, реализованной с использованием только одного массива.
15. Компьютерно-читаемый носитель, содержащий код компьютерной программы для выполнения способа определения уникального идентификатора, связанного с узлом сети, причем этот способ содержит:
запрос первой поисковой таблицы с использованием имени домена, связанного с узлом сети, причем эта первая поисковая таблица содержит одну или более пар, пара содержит имя домена, связанное с конкретным узлом сети, и ссылку на одну вторую поисковую таблицу из множества вторых поисковых таблиц, причем каждая из вторых поисковых таблиц содержит одну или более пар, пара содержит имя хоста, связанное с конкретным узлом сети, и уникальный идентификатор, связанный с конкретным узлом сети,
запрос второй поисковой таблицы, на которую указывает ссылка, с использованием имени хоста, связанного с узлом сети, возвращение уникального идентификатора, связанного с узлом сети, и выполнение одного из:
использования возвращенного уникального идентификатора для получения модели ресурса, связанного с узлом сети, и
использования возвращенного уникального идентификатора для определения, является ли узел сети членом категории.
16. Устройство для определения уникального идентификатора, связанного с узлом сети, содержащее:
модуль запроса, сконфигурированный для запроса поисковой таблицы с адресами Интернет-протокола (IP) с использованием IP-адреса, связанного с узлом сети, причем эта поисковая таблица с IP-адресами содержит одну или более пар, пара содержит IP-адрес, связанный с конкретным узлом сети, и уникальный идентификатор, связанный с конкретным узлом сети, модуль возврата, сконфигурированный для возврата уникального идентификатора, связанного с узлом сети, и
одно из:
модуля модели ресурса, сконфигурированного для использования возвращенного уникального идентификатора для получения модели ресурса, связанной с узлом сети, и
модуля категории, сконфигурированного для использования возвращенного уникального идентификатора для определения, является ли узел сети членом категории,
причем поисковая структура данных с IP-адресами автоматически преобразуется в массив, содержащий один или более элементов, причем элемент хранится в индексе, при этом элемент содержит уникальный идентификатор, связанный с конкретным узлом сети, а индекс определяется на основании IP-адреса, связанного с конкретным узлом сети.
| Способ приготовления мыла | 1923 |
|
SU2004A1 |
| US 6108699, 22.08.2000 | |||
| Способ приготовления мыла | 1923 |
|
SU2004A1 |
| RU 97118465 A1, 20.11.1999. | |||
