3) при первоначальном вводе массивов слов в отдельные устройства В этом случае ввод информации производится дважды, каждый раз с контрольным суммированием. Если обе контрольные суммы совпали, то считают, что ввод произведен верно, а контрольная сумма принимается за эталонную.
Суммирование может производиться либо по программе, либо при помощи специального сумматора. Наиболее распространенными способами контрольного суммирования являются следующие:
* поразрядное суммирование слов по модулю 2;
* арифметическое суммирование слов без кольцевого переноса в младший разряд;
* арифметическое суммирование с кольцевым переносом из стар-шего в младший разряд (суммирование по модулю 2"', где т - длина слов).
Первый способ имеет наименьшую эффективность, последний -наибольшую. Второй способ занимает промежуточное положение.
При очень малых вероятностях искажений значений разрядов эффективность контроля при различных методах суммирования будет почти одинакова. В случае относительно больших значений вероятности q суммирование по модулю обеспечивает большую вероятность обнаружения ошибок.
Проверка переменной на появление запрещенных комбинаций. Суть проверки состоит в сравнении какой-либо переменной x с заранее известными разрешенными или запрещенными значениями переменных, причем X .
При нормальной работе x X, а при наличии ошибок x X У.
Контроль может проводиться следующими двумя способами.
Первый способ состоит в проверке попадания переменной x в множество X разрешенных значений. При этом проверяются условия x = . Если для одного из г равенство соблюдается, то считают, что ошибка отсутствует.
3. Предоставление доступа к хранилищам данных
Семантическая БД может быть представлена в виде RDF-графов, таких, как онтологический, видимый, невидимый, логический и несанкционированный RDF-графы.
Определение 1. Семантическая БД может быть представлена в виде RDF-графа Q, состоящего из множества вершин V (множество субъектов и объектов) и множества рёбер G (множество предикатов), который обозначается как Q = {V, G}, где V--· C I, G ? P. Каждая вершина графа Q соответствует субъекту или объекту некоторого триплета СБД, а каждое ребро соответствует предикату данного триплета.
Определение 2. Онтологическим графом Q l является результат применения множества онтологических логических правил R1 к графу Q, Q ? Q l .
Определение 3. Видимым графом Qs для пользователя U является часть графа Q l, содержащая все триплеты, у которых уровни безопасности меньше или равны уровню доступа пользователя slU (т.е. пользователь имеет к ним доступ).
Определение 4. Невидимым графом Qh для пользователя U является часть графа Q l, содержащая все триплеты, у которых уровни безопасности больше, чем уровень доступа пользователя slU (т.е. к ним пользователь не имеет права доступа).
Из определений 1 - 4 может быть получено отношение между графами Q l, Qs и Qh, которое определяется по формуле
Qh ? Qs = ?, Qh = Q l \ Qs или Q l = Qs ? Qh.
Определение 5. Логическим графом Q l s для пользователя U является результат применения множества пользовательских логических правил R2 к видимому графу Qs, и получено отношение Q l ? Qs l .
Определение 6. Несанкционированным графом Qt является множество не санкционированных результатов логических выводов, элементами которых являются триплеты, которые находятся одновременно в двух графах Qs l и Qh.
Qt определяется по формуле Qt = Qs l ? Qh
На основе определений 5 - 6 для пользователя U могут быть определены следующие области RDF-графов в семантических БД (рисунок 1)
Рисунок 1. Области RDF-графов для пользователей в БД
1. область начального графа Q (выделена границей);
2. область видимого графа Qs (выделена границей);
3. область онтологического графа Q l (выделена границей);
4. область логического графа Q l s (выделена границей);
5. область несанкционированного графа Qt (показана, как).
Для каждого пользователя в системе поддержки безопасности базы данных создаётся учётная запись, содержащая сведения, которые пользователь идентифицирует себя в системе обеспечения безопасности.
Основными элементами учётной записи пользователя являются его имя usersl и некий параметр slu, значение которого определяет уровень доступа пользователя к данным хранилища. В данном случае значение параметра безопасности следует рассматривать как значение свойства субъекта "пользователь".
Если с каждым субъектом в RDF-хранилище связать новое свойство sld, значение которого характеризует степень доступности свойств, связанных с данным субъектом, то проверка прав доступа к этим сведениям сводится к анализу значений slu и sld. Например, если slu ? sld, то данные пользователю доступны. В противном случае пользователю в доступе данных будет отказано.
Для интеграции нового свойства sld в состав хранилища данных необходимо определить пространство имен, которое обеспечит возможность подключения нового свойства к субъектам хранилища.
Для решения этой задачи используется средство XML Schema [2], которое является современным форматом для описания структуры XML документов. Структура документов хранится в файлах с расширением xsd (XML Schema definition).
Пример файла XML schema для нашего случая приведен на рис.2, файл определяет три простых элемента (имя элемента и его тип).
#flsd.xsd
<?xml version="1.0"?>
<xs:schema xmlns:xs="http://www.w3.org/2001/XMLSchema">
<xs:element name="lsd" type="xs: integer">
<xs:element name="usersl" type="xs: string ">
<xs:element name="lsd" type="xs: integer">
</xs:element>
</xs:schema>
Рисунок 2. Содержание файла XML schema.
Права доступа к данным определяются владельцем RDF-хранилища данных. Для интеграции в хранилище информации об уровне доступа к данным необходимо добавить к свойствам каждого субъекта дополнительный граф, отражающий значение уровня доступа (sld) к остальным свойствам субъекта (рис.3.)
Диапазон значений sld определяется политикой безопасности владельца RDF-хранилища. Например, 0 - доступ безограничений, 1 - для служебного использования и так далее.
Ввод дополнительной информации в RDF-хранилище осуществляется с помощью операторов INSERT.
Пример запроса на обновление данных, который присоединяет к субъекту:book1 свойство lsd=0 представлен на рис.4.
PREFIX dc: <http://purl.org/dc/elements/1.1/>
PREFIX xsd: <http://www.w3.org/2001/XMLSchema#>
PREFIX : <http://www.libRegistry.org/ns/lib#>
PREFIX flsd: <http://localhost:3030/rdf/flsd.xsd>.
INSERT
{ :book1 flsd:lsd 0.}
WHERE {}
Рисунок 4. Запрос SPARQL определяющий новое свойство субъект:book1
В результате применения указанного запроса и аналогичного запроса с определением lsd=1 для субекта book2 к исходному документу (рис. 5) получим документ с добавленными свойствами lsd для каждого субъекта (рис.6).
@prefix rdf: <http://www.w3.org/1999/02/22-rdf-syntax-ns#> .
@prefix dc: <http://purl.org/dc/elements/1.1/> .
@prefix xsd: <http://www.w3.org/2001/XMLSchema#> .
@prefix : <http://www.libRegistry.org/ns/lib#> .
@prefix flsd: <http://localhost:3030/rdf/flsd.xsd>.
# Экземпляр book1 класса Book
:book1 a <http://www.libRegistry.org/ns/lib#Book>;
dc:identifier "02419-0";
dc:title "Десять негритят"@ru;
dc:creator "Кристи Агата"@ru;
dc:date "2003-03-09"^^xsd:date .
# Экземпляр book2 класса Book
:book2 a <http://www.libRegistry.org/ns/lib#Book>;
dc:identifier "966-00-0785-5";
dc:title "Кобзар"@uk;
dc:creator "Шевченко Тарас"@uk;
dc:date "2002-10-16"^^xsd:date .
Рисунок 5. Исходный документ (фрагмент RDF-хранилища)
@prefix rdf: <http://www.w3.org/1999/02/22-rdf-syntax-ns#> .
@prefix dc: <http://purl.org/dc/elements/1.1/> .
@prefix xsd: <http://www.w3.org/2001/XMLSchema#> .
@prefix : <http://www.libRegistry.org/ns/lib#> .
@prefix flsd: <http://localhost:3030/rdf/flsd.xsd>.
# Экземпляр book1 класса Book
:book1 a <http://www.libRegistry.org/ns/lib#Book>;
# Значение уровня доступа для данного экземпляра книги
flsd:lsd 0^^xsd:integer;
dc:identifier "02419-0";
dc:title "Десять негритят"@ru;
dc:creator "Кристи Агата"@ru;
dc:date "2003-03-09"^^xsd:date .
# Экземпляр book2 класса Book
:book2 a <http://www.libRegistry.org/ns/lib#Book>;
flsd:lsd 1^^xsd:integer;
dc:identifier "966-00-0785-5";
dc:title "Кобзар"@uk;
dc:creator "Шевченко Тарас"@uk;
dc:date "2002-10-16"^^xsd:date .
Рисунок 6. Исходный документ с добавленными свойствами lsd.
В дальнейшем, при обработке запросов пользователей к RDF-хранилищу, предусматривается модификация этих запросов с целью определения условий фильтрации в соответствии с правами доступа пользователя.
Так запрос, который должен вывести в таблицу ответов все экземпляры книг модифицируется следующим образом. В шаблон WHERE добавляется часть считывающая значение свойства flsd:lsd в переменную ?plsd и оператор фильтрации данных по условию slu??pld (рис.7).
PREFIX dc: <http://purl.org/dc/elements/1.1/>
PREFIX xsd: <http://www.w3.org/2001/XMLSchema#>
PREFIX : <http://www.libRegistry.org/ns/lib#>
PREFIX flsd: <http://localhost:3030/rdf/flsd.xsd>.
SELECT ?book ?bookTitle
WHERE {?book dc:title ?bookTitle.
?book flsd:lsd ?plsd.
FILTER(slu??pld }
Рисунок 7. Запрос на все экземпляры книг в хранилище
Результат выполнения этого запроса по отношению к документу, содержание которого приведено на рис. 6, при значении slu=0 показан на рис.8.
|
?book |
?bookTitle |
|
|
book1 |
"Десять негритят" |
Рисунок 8. Результат выполнения запроса при slu=0
Таким образом, предложен достаточно простой подход к реализации подсистемы обеспечения информационной безопасности в RDF-хранилищах данных. Современные корпорации накапливают терабайты данных и для их хранения используют системы NAS и SAN. Однако в силу своей конструкции данное оборудование не предусматривает встроенных средств разграничения доступа к данным между отдельными пользователями или их группами. Информация при этом сконцентрирована в одном месте, и потенциальная степень ее уязвимости весьма высока.
Высокая степень консолидации оборачивается опасностью несанкционированного доступа по открытым каналам, так как все узлы находятся в единой сети. Взлом одного или нескольких узлов в корпоративной сети хранения данных может привести к катастрофическим последствиям для бизнеса.
В связи с тем, что 50-80% атак начинаются внутри сети, большинство организаций признают, что их наиболее критичная информация "по умолчанию" находится под угрозой. Такие решения, как межсетевые экраны или виртуальные частные сети обеспечивают общую защиту периметра корпоративной сети, а центральные хранилища данных остаются уязвимыми для внутренних и внешних атак.
Как уже отмечалось, низкая степень защищенности NAS и SAN заложена в самой их природе, поэтому стоит сказать несколько слов об их архитектуре. NAS-решения представляют собой выделенный файл-сервер. Подключаются к локальным сетям и осуществляют доступ независимо от операционной системы и платформы. Их достаточно легко администрировать, однако они не решают проблему транзита данных до сервера приложений. Проблема загрузки локальной сети решается с помощью NAS-решений частично. Доступ к данным осуществляется только через выделенный NAS. Если другим узлам необходимо обратиться к серверу, данные должны передаваться по локальной сети, что существенно нагружает трафик. Системы NAS позволяют разбивать хранилище данных на сегменты. Клиенты сети, также разделенные по группам, получают доступ только к определенному сегменту хранилища, доступ к другим им запрещен.
Другой серьезный недостаток NAS в том, что они не могут совместно использовать жесткие диски разных устройств, подключенных к локальной сети. Иногда недостатком считается и доступ к данным на уровне целых файлов, а не блоков (например при обработке структурированных и ресурсоемких приложений СУБД). Помимо этого, средой передачи для NAS-серверов являются сети Ethernet, в результате общая производительность работы системы не очень высокая. К тому же NAS, как правило, не допускают наращивания, в отличие от SAN.
С учетом низкой масштабируемости хранилища, ограничений пропускной способности локальной сети и протокола передачи данных, NAS обычно используются в малобюджетных решениях.
Вплоть до недавнего времени шли дискуссии, чему отдать предпочтение: SAN или NAS? Сегодня же специалисты все чаще приходят к мнению, что оба подхода должны сосуществовать.
Теперь о SAN. Она представляет собой обособленную сеть, отделенную от локальной, с возможностью хранения огромных объемов информации, которые можно наращивать практически бесконечно. Типичная SAN включает ряд дисковых массивов, подключенных к коммутатору, который, в свою очередь, соединен с серверами, служащими для организации доступа к хранимым данным. Техническую основу сети хранения данных составляют волоконно-оптические соединения, адаптеры шины узла FC HBA и FC-коммутаторы, в настоящее время обеспечивающие скорость передачи 200 Мбайт/с и удаленность между соединяемыми объектами до 10 км (до 120 км с помощью специальных решений). SAN позволяет любому серверу получить доступ к любому накопителю, не загружая при этом ни другие серверы, ни локальную сеть компании. Кроме того, возможен обмен данными между системами хранения без участия серверов.