Автор: Барт фон Вельден
Авторизация доступа к индивидуальным объектам данных на базе пространственных и временных привязок (spatial and temporal references ) представляет сложную задачу. Изучите этот пример, знакомящий читателей с одним возможным подходом.
Авторизация доступа к индивидуальным объектам данных в составе коллекции данных превращается в проблему, когда и коллекции данных, и группа пользователей становятся крупными и динамическими. Эта проблема становится еще более сложной, когда политики авторизации базируются на пространственных и временных привязках объектов данных. В этой статье предлагается решение указанной проблемы с использованием реального сценария моего работодателя, компании CycloMedia Technology, в сочетании с двумя компонентами Oracle Database Enterprise Edition: опциями Spatial и Virtual Private Database (виртуальная частная база данных).
Компания CycloMedia Technology
Компания CycloMedia специализируется на крупномасштабной и систематической визуализации сред, основанной на панорамных фотографиях с полным (360 градусов) обзором, или панорамах. Чтобы создать панораму, крупные области фотографируются и вводятся в онлайновую базу данных. Для каждой такой записи регистрируется местоположение, ориентация и время, что делает возможным использование универсальных приложений, например, приложений для трехмерных измерений и моделирования. (См. приведенный ниже пример.)
| ImageId | RecordingLocation | RecordingDateTime |
| 43c5klf8h0cg | 5.70698580234006,50.8474750817698 | 2005-03-12 15:22 |
| 6ju83ks7u6pg | 4.59019800392403,52.4622636292842 | 2004-08-02 08:51 |
| 85s8hi4nl7u2 | 6.9008111752263,52.4115443666161 | 2006-06-21 12:17 |
| .... | .... | .... |
Рисунок 1.Пример панорамы с картографическими данными
DCR7 - это последняя модель CycloMedia в цепочке систем записи, разработанных собственными силами компании. Она позволяет добиться качественного скачка визуального качества, метрической точности и высокоскоростной визуальной регистрации. С помощью DCR7, которая может производить панорамы с 5-метровым интервалом со скоростью 80 км/ч, CycloMedia намеревается визуализировать высокий процент открытых площадок для общественного пользования Европы. Как ожидается, благодаря этим разработкам коллекция панорам будет быстро расти.
Проблема авторизации
Предлагаемый пример компании CycloMedia представляет собой сценарий, в котором доступ к динамической коллекции объектов (как с пространственными, так и с временными привязками) должен быть разрешен (авторизован) для большой группы пользователей. Параметры авторизации базируются на пространственных и временных измерениях коллекции.
Традиционный подход к этой проблеме заключается в создании статических наборов данных или таблицы прав доступа для описания каждого отдельного отношения между субъектом (клиент или пользователь) и каждым объектом коллекции. Обычно построение этих наборов данных и таблиц базируется на использовании специализированных инструментов для оценки пространственных связей между объектами и разрешенными для использования (авторизованными) областями.
Построение и поддержание специальных (ad hoc) наборов данных или таблиц прав доступа для поддержания управления доступом становится неудобным, когда и коллектив пользователей, и коллекция данных становятся большими и динамическими. Более того, такие специальные данные не поддерживают гибкую степень детализации защиты и динамические изменения политики управления доступом.
В нескольких недавно предложенных решениях обнаружены различные недостатки. Основная причина этих недостатков связана с архитектурой предложенных решений: принудительное выполнение авторизации выполняется вне базы данных или после выполнения запроса, ограничивая тем самым использование данных. Специалисты находят, что даже архитектура GeoXACML, которая в настоящее время предлагается консорциумом Open Geospatial Consortium в качестве нового стандарта, является проблематичной. Она базируется на стандартах для пространственных данных (GML, WMS) и авторизации (XACML) и предлагает решение для управления доступом к незащищенным Web Map Services (web-сервисам для точечных карт), не изменяющее существующую инфраструктуру. Для этого она перехватывает сообщения для WMS, выполняет задачу поиска для целевой WMS, передает полученные результаты в точку принятия решения политики и создает результирующий набор, базирующийся на полученных решениях авторизации.
Эта архитектура прототипов, на которой в значительной степени базируется концепция, продемонстрировала свою неэффективность: все данные выбираются из первоначальной базы данных, затем преобразуются в GML и разбиваются и поэлементно (feature-by-feature) оцениваются внешним инструментом по отношению к политике авторизации. По этой причине не могут быть использованы имеющиеся в первоначальной базе данных пространственные индексы, и должны быть дополнительно реализованы пространственные функции сравнения в отдельном компоненте. Кроме того, эта архитектура неспособна к выполнению задач сложного анализа, потому что данные сначала выбираются, а позже фильтруются по отношению к политике авторизации. Проблематичен даже простой запрос о ближайшем соседе: самый близкий выбранный в первую очередь объект может впоследствии оказаться недоступным.
Оценка авторизации на уровне базы данных
Поскольку в наиболее широко распространенных сегодня базах данных реализованы пространственные типы данных и пространственные функции (обычно на базе стандарта консорциума Open Geospatial Consortium SFS [пространственные типы и функции]), кажется вполне возможным ввести принудительное исполнение политики авторизации на уровне базы данных. Используемый сегодня механизм авторизации SQL, однако, ограничен уровнем таблиц, представлений и столбцов. Можно было бы подумать о создании представлений для каждого отдельного пользователя, но выясняется, что этот подход не является масштабируемым при большом числе пользователей и при изменяющихся политиках.
Из-за вышеупомянутых проблем используемые сегодня информационные системы, как правило, блокируют возможности контроля доступа базы данных и внедряют управление доступом в прикладную программу, используемую для обращения к базе данных. Эта программа может быть приложением конечного пользователя или приложением, входящим в состав программного обеспечения среднего слоя. Включение управления доступом в приложение конечного пользователя представляется весьма проблематичным, если у вас не имеется никакого контроля над источником приложения, или если вы используете несколько приложений. Изменения в политике авторизации должны быть также применены к многочисленным механизмам контроля, но даже в этом случае все должно зависеть от политики обновления приложений, чтобы изменения вступили в силу. Кроме того, присутствует риск того, что пользователи или хакеры разместят какие-то произвольные запросы. Вторая опция должна создавать запрос в приложении среднего слоя. Это приложение затем должно редактировать запросы, выполняемые приложениями конечного пользователя, чтобы включить в них политику авторизации. Однако в случае сложных задач поиска и изменяющейся политики авторизации это может стать достаточно трудным делом. Еще один вариант заключается в том, чтобы предоставить приложению конечного пользователя несколько используемых по умолчанию задач поиска значения, как функций. И хотя это, вероятно, упростило бы процесс, это непосредственно ограничивает варианты для пользователей.
Принудительное применение авторизации на уровне базы данных
По упомянутым выше причинам детальное управление доступом должно в идеале быть и определено, и принудительно применено на уровне базы данных. Шарид Ризви (Shariq Rizvi) и другие из Калифорнийского университета в Беркли предложили для включения политики авторизации модель Трумэна, которая базируется на модификации запросов на уровне базы данных. Хотя другие авторы ранее уже обсуждали эту концепцию, модель Трумэна обобщает подход с модификацией запроса на уровне базы данных, используя инфраструктуру параметризованных представлений. Стоящая за моделью Трумэна идея заключается в том, что необходимо предоставить каждому пользователю личное и ограниченное представление полной базы данных. Для реализации этой идеи пользовательские запросы изменяются таким образом, чтобы можно было быть уверенным, что пользователь не сможет увидеть чего-то большего, чем ему разрешено. Политики авторизации, фактически являющиеся логическими выражениями, добавляются к сформулированным запросам как предикаты. Приводимый ниже рисунок визуализирует эту модель.
Рисунок 2. Модель Трумэна в действии: сформулированный пользователем запрос переписывается в новый запрос, который выполняется системой.
Поскольку модификация запроса производится прозрачно для пользователя, он может даже не обратить внимания на существование механизма управления доступом. Таким образом, архитектура воспринимается конечным пользователем, как будто к данным не применены никакие ограничения, и он имеет доступ ко всем объектам в таблице. Подобное представление модели Трумэна визуализируется ниже:
Рисунок 3. Модификация запроса в рамках модели Трумэна прозрачна для пользователя. Поэтому модель может быть также рассмотрена как модель, в которой каждое отношение в пользовательском запросе заменено представлением, которое разрешено видеть пользователю.
Модель Трумэна иногда называют детальным управлением доступом (fine-grained access control - FGAC) или организацией защиты на уровне строки (row-level security - RLS). (Название модели было вдохновлено искусственным миром, связанным с личностью Трумэна Бербанка - героя появившегося в 1998 году кинофильма "Шоу Трумэна".)
К преимуществам этой модели следует отнести единую точку принудительного проведения авторизации, вариант с наличием динамического сбора данных, возможности запросов конечного пользователя и эффективную обработку данных (которая является главным аспектом для пространственных данных).
Виртуальная частная база данных Oracle
В документации Oracle объект виртуальная частная база данных Oracle (Virtual Private Database Oracle - VPD) имеет еще несколько других названий, среди которых можно отметить FGAC и RLS. Независимо от названия, организация защиты VPD предлагает полностью новый способ управления доступом к данным. Он основан на идее - иметь определенную функцию правил разграничения доступа, прикрепленную к таблице или к представлению базы данных, которая будет выполняться каждый раз, когда делается запрос к данным в таблице или представлении, или эти данные изменяются. Прежде чем этот SQL будет использован, такая функция возвращает дополнительную часть оператора SQL - так называемый предикат, который присоединяется к фразе WHERE первоначального оператора SQL. Таким образом, получаемый оператор соответствует концепции модели Трумэна. Модификация запроса происходит в оптимизаторе запросов и фактически выполняется во время анализа и выполнения оператора SQL. Когда оператор SQL выполняется, он фактически является уже измененным оператором SQL, который выполняется от имени пользователя. Это означает, что тем, какие строки данных будут возвращены, управляет функция правил разграничения доступа. Процесс можно представить себе как системный триггер, выполняющийся при каждом обращении к таблице, для которой определена политика. Важной характерной особенностью VPD является ее динамическая природа.
Реализация
Для исследования пригодности модели Трумэна для спроектированного сценария мы создали в среде корпоративного выпуска Oracle Database 10g тестовую реализацию с активированной опцией Spatial. Для модификации запроса используется компонент VPD, который включается только в корпоративный выпуск Oracle Database. Коллекцию данных было относительно просто создать в базе данных; для этого достаточно создать отдельную таблицу со столбцами image_id, recording_location, и recording_datetime. Столбец image_id определяется как первичный ключ. Поскольку столбцы, определяющие местоположение и дату-время, используются в предикатах авторизации и в задачах поиска, для них обоих создаются индексы. Переменная recording_location имеет тип SDO_GEOMETRY. Это пространственный тип данных, в котором могут храниться различные виды пространственных конфигураций.
Затем необработанные данные были импортированы в базу данных. Поскольку первоначальные данные были в формате Dutch National Grid, было проведено преобразование к формату World Geodetic System (мировой геодезической системы - WGS84). Окончательная коллекция данных содержит почти 10 миллионов изображений, записанных в Нидерландах в течение приблизительно 10 лет.
Далее мы спроектировали модель данных, чтобы включить контракты, клиентов, пользователей и допустимые диапазоны каждого контракта, относящиеся к пространственному и временному типам. Было создано публичное представление, называющееся condition_sets, в котором объединились данные из этих таблиц, тем самым, обеспечивая все "доступные" комбинации пространственных и временных диапазонов. Наконец, были введены некоторые тестовые данные.
Чтобы ограничить пользователя только его собственными данными, для condition_sets мы определили следующий предикат:
(WHERE) client_id = SYS_CONTEXT ('THE_CTX', 'THE_CLIENT_ID')
Этот предикат делает для пользователя невозможным обращение к неавторизованным для него данным, удаляя из client_id все строки, кроме тех, которые были установлены для него в значении the_client_id в контексте сеанса (the_ctx). Такой контекст сеанса создается триггером входа в систему, который определяет, какому клиенту принадлежит этот пользователь. Поскольку VPD также предлагает функцию для установления контекста с использованием функции, сеанс между сервером приложений и базой данных может быть сделан постоянным (перманентным), а триггер входа в систему может быть удален.
Теперь этот предикат должен быть присоединен к таблице condition_sets. В Oracle для этого предоставляется функция dbms_rls.add_policy. Однако она не может непосредственно добавить предикат, а нуждается в еще одной функции, которая возвращает предикат. Такую функцию называют функцией правил разграничения доступа (policy function). Поэтому я создал функцию client_id_security в пакете, который я назвал exp_security:
CREATE OR REPLACE PACKAGE exp_security AS
FUNCTION client_id_security(owner VARCHAR2, objname VARCHAR2)
RETURN VARCHAR2;
END exp_security;
Тело пакета имеет следующий вид:
CREATE OR REPLACE PACKAGE BODY exp_security IS
FUNCTION client_id_security(owner VARCHAR2, objname VARCHAR2) RETURN VARCHAR2 IS predicate VARCHAR2(2000);
BEGIN
predicate := 'CLIENT_ID = sys_context(''THE_CTX'',''THE_CLIENT_ID'')';
RETURN predicate;
END client_id_security;
END;
Теперь, когда мы имеем функцию правил разграничения доступа, может быть выполнена специальная функция dbms_rls.add_policy. Эта функция прикрепляет функцию правил разграничения доступа к определенной таблице или представлению. Когда производится выборка данных из таблицы, выполняется функция правил разграничения доступа и возвращает предикат. Этот предикат используется для изменения запроса перед его выполнением. Первый параметр функции dbms_rls.add_policy определяет пользователя, владеющего таблицей (или представлением), имя которой определено в качестве второго параметра. Третий параметр дает этой новой политике имя, которое можно будет использовать позже для удаления или изменения политики. Четвертый и пятый параметры определяют, какая именно политика должна быть добавлена, и где ее можно найти. Заключительный параметр определяет, что политика должна использоваться только при выборке данных.
CALL dbms_rls.add_policy('BART', 'condition_sets', 'condition_sets_policy', 'BART', 'exp_security.client_id_security', 'SELECT');
Теперь всякий раз, когда делается запрос к представлению bart_condition_sets, из функции правил разграничения доступа bart.exp_security.client_id_security будет возвращен предикат, который ограничивает строки текущим пользователем. Этот предикат будет теперь использоваться для модификации запроса, как описано в модели Трумэна. В следующих параграфах это представление будет использоваться для авторизации фактических данных. В разделе, посвященном оценке, вы увидите результаты модификации запроса для пользователя, формулирующего запросы.
Таблицы images_authorized и images_unauthorized
Таблица изображений должна быть авторизована двумя способами, с использованием для авторизации двух различных политик. Первая политика должна исключить все строки, которые не могут быть квалифицированы как разрешенные диапазоны в condition_sets. Вторая политика должна исключить все разрешенные строки изображений, а также скрыть imageid всех остающихся строк. Таким образом, пользователь может увидеть, где и когда были сделаны изображения, которые он в настоящее время не может просмотреть. Позже мы увидим, что это может быть использовано как маркетинговый инструмент.
Для реализации этой возможности имеются два варианта: использование двух публичных синонимов и использование представлений. Но поскольку в документации Oracle утверждается, что политика уровня столбца, которая является необходимой для того, чтобы скрыть ImageId, не может быть применена к синониму, единственным доступным вариантом остается создание для таблицы изображений двух представлений. Поскольку удаление image_ids для не авторизованных изображений может также быть сделано в определении представления, в противоположность определенной политике уровня столбца, я выбрал этот вариант.
Пространственная оценка должна провести проверку того, что recording_location находится в указанной области (столбец geo). Опция Oracle Spatial предлагает для этого функцию SDO_INSIDE (geometry1, geometry2). Первый параметр определяет в таблице столбец geometry, а второй параметр определяет геометрию по таблице или динамическому экземпляру геометрии. Это означает, что подобная функция не может быть использована в запросе типа этого:
SELECT *
FROM images
WHERE sdo_inside(recording_location,
SELECT geo
FROM condition_sets) = 'TRUE';
Вместо этого запрос должен быть переписан следующим образом:
SELECT *
FROM images,
condition_sets
WHERE sdo_inside(recording_location,geo) = 'TRUE';
Это требование делает невозможным определение функции правил разграничения доступа, которая добавляет предикат авторизации к таблице пространственных данных с используемой по умолчанию пространственной функцией. Можно было бы создать альтернативную функцию, которая выполняет проверку для каждого изображения для всех пространственных областей, но это потребовало бы дополнительной работы и, вероятно, привело бы к снижению производительности. Поэтому выполнение сложных пространственных оценок в предикате, добавляемом моделью Трумэна, кажется проблематичным. Таким образом, я должен был выбрать другой вариант: вместо того чтобы определять представления images_authorized и images_unauthorized как копии первоначальной таблицы изображений, оба этих представления определяются как перекрестное соединение таблицы изображений и представления conditions_sets. Таким образом, может использоваться предикат на базе используемой по умолчанию пространственной функции. Оператор SQL для images_authorized должен иметь следующий вид:
CREATE VIEW images_authorized AS
SELECT *
FROM images,
condition_sets
После того как будут добавлены временные предикаты, полный предикат для представления images_authorized, который должен быть определен в функции правил разграничения доступа, примет вид:
(WHERE) recording_datetime >= start_date
AND recording_datetime?<= end_date
AND SDO_INSIDE(recording_location,geo) = 'TRUE'
Но в этом решении содержится некоторая нестыковка: в том случае, если объект из коллекции соответствует условиям для нескольких наборов условий, он, вопреки желанию пользователя, появится в представлении images_authorized несколько раз. Чтобы устранить эту проблему, пользователь должен в каждом запросе использовать различные "отборщики" (критерии отбора - прим. пер.), что является не очень подходящим выходом. Подобная проблема существует и для областей, встречающихся в представлении condition_sets, что также является нежелательным. Помочь решить эту проблему может еще одно доступное для пользователя новое представление:
CREATE VIEW images_authorized_fixed AS
SELECT DISTINCT imageid,
recording_datetime,
recording_location
FROM images_authorized;
Как можно видеть, в предикаты, добавленные к представлениям images_authorized и images_unauthorized, не включена привязка к контексту сеанса, потому что она уже присутствовала в предикате для представления condition_sets. Благодаря этому пространственные и временные предикаты могут быть также включены в фактическое определение представления. Области из представления condition_sets могут также быть исключены. Ниже приводится получающийся в итоге оператор SQL:
CREATE VIEW images_authorized AS
SELECT images.*
FROM images,
authorized_sets
WHERE recording_datetime >= start_date
AND recording_datetime <= end_date
AND SDO_INSIDE(recording_location,geo) = 'TRUE';
При подобном подходе в функциях правил разграничения доступа не должны быть определены никакие пространственные и временные предикаты. При анализе обоих дизайнов проекта не было обнаружено никакого различия в производительности. Это указывает, что обработка запросов не является тяжелой работой для оптимизатора запросов.
Вышеупомянутое решение соответствует поставленной цели: данные действительно являются авторизованными для пространственных и временных измерений. Модель Трумэна используется для того, чтобы включить в представление condition_sets только строки для текущего пользователя, и затем на базе этого персонифицированного набора условий производится авторизация фактических данные посредством соединения таблиц. Новые представления, созданные этим способом содержат только те данные, которые соответствуют персонифицированным условиям из condition_sets. Таким образом, единственная модификация запроса, выполняемая моделью Трумэна, становится базисом механизма полной авторизации. Заключительная архитектура предоставляет каждому пользователю три таблицы. В одной таблице содержатся авторизованные диапазоны, во второй - доступные данные, а в третьей показано, какие данные являются недоступными. В последней таблице, таким образом, содержатся все входящие в коллекцию данные за вычетом данных из второй таблицы. В последней таблице информационные объекты описываются только с помощью их пространственных и временных атрибутов (признаков).
Каждая из таблиц фактически является публичным представлением, базирующимся на ряде физических таблиц, принадлежащих одному администратору базы данных, к которым обычные пользователи не имеют прямого доступа. Хотя в базе данных каждое представление появляется только один раз, их контенты изменяются для каждого пользователя.
Оценка
Для использования предлагаемой архитектуры был разработан специальный программный компонент. При использовании выбранного инструмента результаты могут быть представлены понятным способом. Он базируется на использовании трехмерного приложения ГИС Google Earth, которое может динамически отыскивать данные с Web-сервера в формате KML (Keyhole Markup Language - гипертекстовый язык разметки, разработанный компанией Keyhole). Для аутентификации используется базовая аутентификация HTTP. Как и ожидалось, она показывается в Google Earth после активизации сетевого канала, нацеленного на Web-сервер:
Рисунок 4. Мандат пользователя, представленный на этом экране входа в систему Google Earth используется для соединения с базой данных.
Web-сервер использует предложенный мандат для соединения с базой данных. После того, как было установлено успешное соединение, могут выполняться запросы. Результаты преобразуются в формат KML и возвращаются в приложение ГИС. В запросы, формулируемые сервером, не включены никакие механизмы авторизации данных, потому что эта задача (включение механизмов авторизации - прим. пер.) полностью возлагается на механизм VPD в базе данных. Поэтому оператор SQL для выбора всех разрешенных изображений в текущей области просмотра (окно) выглядит следующим образом:
SELECT imageid, recordingdate, recordinglocation FROM bart.images_authorized WHERE SDO_FILTER(recordinglocation, ?window ) = 'TRUE'
Визуализация решений авторизации
На приведенном ниже рисунке 5 показано приложение ГИС для аутентифицированного пользователя. Этот пользователь авторизован для зеленой области слева, а также для широкого диапазона времени. Каждый зеленый маркер представляет авторизованный объект (панораму), являющийся результатом определенного выше запроса. Панорамы вне авторизованной области удалены из результирующего набора непосредственно самим механизмом базы данных. Как ожидается, все зеленые маркеры можно найти в многоугольниках авторизации (и между двумя уровнями, представляющими временной диапазон). Сюда же добавлены неавторизованные объекты, чтобы сделать наглядной эффективность механизма авторизации. Для отыскания этих неавторизованных объектов выполнялся запрос, подобный приведенному выше, в котором использовалось представление images_unauthorized.
Рисунок 5. Решение авторизации, принудительно введенное в исполнение базой данных, представляется в Google Earth цветом каждого маркера. Зеленые маркеры символизируют доступные панорамы, красные маркеры - недоступные.
После того, как пользователь кликнет по метке, принадлежащей авторизованной панораме, она будет представлена в окне приложения ГИС. Когда пользователь запрашивает неавторизованный объект, всплывающее окно сообщает ему, что он не может получить доступ к запрашиваемому ресурсу, и ему предлагается ссылка для контакта с коммерческим отделом.
Рисунок 6. Авторизованная панорама может быть рассмотрена в приложении ГИС; ее маркер окрашен в синий цвет. Маркер неавторизованной панорамы предлагает только некоторые метаданные и ссылку для того, чтобы войти в контакт с коммерческим отделом.
Запрос о ближайшем соседе: утечка информации
Помимо оконного запроса, в сценарии учебного примера CycloMedia важно и самое близкое к местоположению изображение. В Oracle Spatial предлагается функция sdo_nn:
SELECT/ imageid, recordingdate, recordinglocation /FROM/ bart.images_authorized /WHERE/ /SDO_NN/(recordinglocation, ?geometry, /'sdo_batch_size=10'/) = /'TRUE'/ and ROWNUM <2;/
После выполнения этого запроса, первые результаты выглядели вполне удовлетворительными. В большинстве случаев самое близкое изображение было найдено. Однако я столкнулся со следующим фактом: для некоторых местоположений не было найдено никакого результата. Поскольку не были определено никакие ограничения (типа максимального расстояния), это показалось мне неожиданным. Исследование с использованием некоторых тестовых данных показало, что запрос о ближайшем соседе может быть, как это описывается в руководствах, "оценен несколько раз, чтобы возвратить желаемое число результатов, которые также удовлетворяют другим условиям во фразе WHERE". Однако, фраза WHERE в вышеупомянутом операторе не содержит никаких других условий. После выполнения некоторого количества запросов для различных тестовых данных, я понял, что именно произошло: если ближе самого близкого авторизованного изображения будет найден неавторизованный объект, не будет возвращено никакого результата. Как следствие этого, возникает утечка информации о том, где расположены неавторизованные объекты. Чтобы исправить эту ситуацию, функцию sdo_nn также необходимо оценивать много раз в том случае, если ссылочная таблица создана с использованием соединения, которое фильтрует данные, как это имеет место в таблице image_authorized. Поскольку пользователь может и не осознавать этого факта, такое открытие удивительно и указывает на серьезную проблему, потому что утечка данных допущена механизмом базы данных.
Мне удалось создать искусственный приём для решения этой проблемы. Для этого я использовал функцию within_distance, которая создает авторизованное подмножество, упорядочивает результаты и возвращает первую строку. Но это не снимает проблему отсутствия нормальной функции для определения ближайшего соседа.
Рисунок 7. На этом изображении пользователь выбрал местоположение, которое он желает увидеть через инструмент "перекрестие" (визир). В базе данных проводится поиск самой близкой авторизованной панорамы в ограниченном диапазоне, найденное место отмечается на карте, а затем представляется в приложении ГИС. Кроме того, представление автоматически открывается в направлении первоначального местоположения.
Сложная пространственно-временная задача
В сценарии CycloMedia пользователей часто интересуют только самые новые панорамы. Применяемый сегодня подход для реализации этого интереса базируется на стратегии регистрации и использования наборов данных: области фотографируются полностью и помещаются в новый набор данных, который заменяет любой существующий набор данных. Оборотной стороной этого подхода является то, что когда новый набор данных неполон, образуются промежутки. Это, конечно, нежелательно для решения в ситуативном понимании. Помимо этого вопроса, для управления наборами данных требуется большой объем работы.
Для выполнения этой задачи в новой архитектуре необходимо сформулировать надлежащий запрос. Это довольно сложная задача, поскольку она вовлекает и пространственные, и временные отношения между объектами. Для каждого объекта должно быть проанализировано пространственное расстояние до других, более старых объектов, и когда такой объект найден, он должен быть исключен из результирующего набора. Однако когда временное расстояние до более старого объекта мало, он не должен быть исключен, потому что оба объекта релевантны. Чтобы понимать, о чем идет речь, нужно понять, что панорамы записываются в непрерывной последовательности. Из-за этого две панорамы с малым пространственным расстоянием, вероятно, будут иметь и малое временное расстояние. Таким образом, важен одинаковый временной порог. В SQL эту задачу было относительно просто определить, и были получены ожидаемые результаты.
Приведенный ниже рисунок иллюстрирует результаты этого запроса в Google Earth. Вертикальное измерение - обычно, высота - используется для визуализации временного измерения в коллекции. Самые высокие объекты являются и самыми новыми. Зеленый цилиндр вокруг каждого самого нового объекта представляет пространственно-временной диапазон, который охватывает объект. Объекты в таком цилиндре (отображаемые желтым маркером) могут быть удалены из результирующего набора, потому что они более не релевантны.
Рисунок 8. Механизм сложного пространственно-временного запроса может также быть визуализирован в приложении ГИС.
Производительность
Помимо правильных решений авторизации, важна и производительность архитектуры. Платформа тестирования, для которой была построена архитектура, не идеальна: система управления базой данных предприятия, программное обеспечение среднего слоя и приложение ГИС эксплуатируются на одной и той же машине. Однако, общая производительность была достаточной, потому что тестовая реализация была в состоянии удовлетворить требованиям использования прямого интерфейса обработки. Некоторые результаты тестирования масштабируемости также подтверждают это. Производительность не становится проблемой для модели Трумэна, даже в случае сложных условий пространственной и временной авторизации.
Заключение
В этой статье предполагается и подтверждается, что, используя две недавно введенные концепции для системы управления базой данных - а именно, модель Трумэна и SFS - можно динамически авторизовать динамические коллекции данных по пространственным и временным измерениям непосредственно системой управления базой данных, обеспечивая, в то же время, поддержку поиска.
Основное преимущество этой архитектуры состоит в том, что механизм авторизации, во всяком случае, не затрудняет использование данных. Другой важной выгодой архитектуры является то, что она в состоянии справиться с динамическим сбором данных. Третья ее выгода - диапазон общеупотребительных инструментальных средств, используемых для визуализации и управления пространственными данными, может все еще использоваться без модификации.
Визуализируя результаты нескольких задач поиска в приложении ГИС, мы могли контролировать корректность подвергаемого мониторингу механизма авторизации. При этом было показано, что, в общем и целом, корректно вводится принудительное исполнение и пространственной, и временной авторизации. Однако, при использовании применяемой по умолчанию функции для нахождения самого близкого соседа, мы обнаружили в механизме авторизации некоторую утечку информации. Это можно считать главной проблемой для некоторых приложений и затрагивает общую конфиденциальность архитектуры. Необходимо дополнительное исследование этой темы.
В недавно опубликованной в Microsoft Research статье обсуждается модель Трумэна (которая не реализована в Microsoft SQL Server). Она представляет новый подход к назначению предикатам полномочий путем проектирования строгого обобщения используемого сегодня механизма авторизации SQL. Ниже приводится пример запроса с предоставлением привилегий:
GRANT SELECT employees WHERE emp_id = user_id() TO PUBLIC
Таким образом, предикаты включаются в обычный оператор предоставления привилегий (grant). Это является противоположностью реализации Oracle VPD, которая отделяет спецификацию политики от модели предоставления привилегий SQL. По моему мнению, этот новый подход является именно таким, которым должно быть детальное управление доступом, и я хотел бы видеть, что это предложение стало базисом для полной эталонной реализации.