Доказательность (non-repudiation)
Интерфейсы, связанные с поддержкой доказательности, относятся к Уровню 2, т.е. отслеживание происходящих в системе событий происходит не автоматически, а под управлением приложения. Спецификация оговаривает типы событий, политики и интерфейсы, которые должен использовать разработчик, чтобы создавать и сохранять информацию о происходящем.
По сути, поддержка доказательности сводится к ведению защищенной базы данных, в которую заносятся записи, связанные с фиксацией создания, отправки, получения и использования удаленных сообщений. Спецификация Сервиса Безопасности определяет следующие виды деятельности, информация о выполнении которых сохраняется в БД:
| enum EvidenceType { SecProofofCreation, SecProofofReceipt, SecProofofApproval, SecProofofRetrieval, SecProofofOrigin, SecProofofDelivery, SecNoEvidence }; |
Важнейшими типами событий являются Creation (создание сообщения) и Receipt (его получение адресатом).
Заносимая в БД информация о событии обычно содержит тип события и сопоставленное с ним описание. Описание включает множество параметров, в том числе информацию о принципале, о дате и времени работы с событием и т.д. Интерфейсы обеспечения доказательности содержат методы, которые позволяют создать описание на основе его параметров.
Несколько слов о соотношении средств обеспечения доказательности в CORBA Security Service и более общих моделях обеспечения доказательности.
Существуют стандарты таких моделей. Графическое представление модели ISO-стандарта приведено на рисунке ниже:
Рисунок 11.13
Серым цветом выделен компонент, включенный в систему обеспечения доказательности CORBA в данной версии спецификации. Основная функциональность, обеспечиваемая этим компонентом:
- Генерация информации о происходящих событиях.
- Контроль (verification) этой информации.
- Генерация запроса для информации, связанной с отправленным событием.
- Получение запроса для информации, связанной с полученным событием.
- Анализа информации о событии.
Другие аспекты обеспечения доказательности – собственно обеспечение хранения информации в БД и извлечение ее оттуда, обеспечение доставки этой информации компонентам или пользователем, непосредственно принимающим решения в случае конфликтов, само разрешение конфликтов на основе полученной информации – в спецификации CORBA Security Service не рассматриваются.
Интерфейс Current
Обычно разработчики прибегают к использованию API Security Service в тех случаях, когда нужно отслеживать действия в системе и сохранять информацию об этом, предоставлять права доступа с учетом большого количества информации (в том числе той, которая известна только на момент выполнения вызова) или при организации взаимодействия с унаследованными системами.
Одним из наиболее важных интерфейсов Сервиса Безопасности является интерфейс Current - точнее, таких интерфейсов даже два – они определены в разных модулях. Это интерфейсы SecurityLevel1::Current и SecurityLevel2::Current. Получение доступа к интерфейсу Current выполняется стандартным образом, с помощью вызова для ORB метода resolve_initial_references() с аргументом «SecurityCurrent».Как обычно, после вызова метода resolve_initial_references() нужно выполнить преобразование типа результата к нужному интерфейсу Current. При преобразовании к SecurityLevel2::Current необходимо предварительно убедиться, что реализация поддерживает этот уровень. Получить информацию о реализации можно с помощью вызова метода CORBA::ORB::get_service_information(), задав в качестве параметра типа CORBA::ServiceType значение константы CORBA::Security. Метод возвращает одно из следующих значений:
| module Security { const CORBA::ServiceOption CommonInteroperabilityLevel0 = 10; const CORBA::ServiceOption CommonInteroperabilityLevel1 = 11; const CORBA::ServiceOption CommonInteroperabilityLevel2 = 12;}; |
На уровне Security Level 1 интерфейс Current содержит единственный метод, который позволяет получить список атрибутов безопасности в контексте выполняемого защищенного вызова:
| module SecurityLevel1 { local interface Current : CORBA::Current { Security::AttributeList get_attributes (in Security::AttributeTypeList attributes); };}; |
Единственный метод возвращает связанный с контекстом вызова список атрибутов безопасности указанных типов.
IDL-объявления основных типов выглядят так:
| module Security { typedef string SecurityName; typedef sequence <octet> Opaque; // Объявления констант для Security Service Options const CORBA::ServiceOption SecurityLevel1 = 1; const CORBA::ServiceOption SecurityLevel2 = 2; const CORBA::ServiceOption NonRepudiation = 3; const CORBA::ServiceOption SecurityORBServiceReady = 4; const CORBA::ServiceOption SecurityServiceReady = 5; const CORBA::ServiceOption ReplaceORBServices = 6; const CORBA::ServiceOption ReplaceSecurityServices = 7; const CORBA::ServiceOption StandardSecureInteroperability = 8; const CORBA::ServiceOption DCESecureInteroperability = 9; // Service options for Common Secure Interoperability const CORBA::ServiceOption CommonInteroperabilityLevel0 = 10; const CORBA::ServiceOption CommonInteroperabilityLevel1 = 11; const CORBA::ServiceOption CommonInteroperabilityLevel2 = 12; ... // Расширяемые семейства (families) для стандартных типов данных struct ExtensibleFamily { unsigned short family_definer; unsigned short family; }; |
| typedef sequence<octet> OID; typedef sequence<OID> OIDList; typedef unsigned long SecurityAttributeType; |
| // Общие атрибуты (family = 0) const SecurityAttributeType AuditId = 1; const SecurityAttributeType AccountingId = 2; const SecurityAttributeType NonRepudiationId = 3; // Атрибуты привилегий (family = 0) const SecurityAttributeType _Public = 1; const SecurityAttributeType AccessId = 2; const SecurityAttributeType PrimaryGroupId = 3; const SecurityAttributeType GroupId = 4; const SecurityAttributeType Role = 5; const SecurityAttributeType AttributeSet = 6; const SecurityAttributeType Clearance = 7; const SecurityAttributeType Capability = 8; struct AttributeType { ExtensibleFamily attribute_family; SecurityAttributeType attribute_type; }; typedef sequence<AttributeType> AttributeTypeList; struct SecAttribute { AttributeType attribute_type; OID defining_authority; Opaque value; // значение зависит от defining_authority }; typedef sequence <SecAttribute> AttributeList;} |
Таким образом, метод SecurityLevel1::Current::get_attributes() возвращает, по сути, состояние объекта Credentials, сопоставленного с выполняемым вызовом. На уровне Level1 вызов этого метода обычно выполняется самим ORB’ом.
На уровне Level 2 появляется дополнительная функциональность, связанная с явным управлением процессом обеспечения безопасности:
| module SecurityLevel2 { ... local interface Credentials { Credentials copy (); void destroy(); readonly attribute Security::InvocationCredentialsType credentials_type; readonly attribute Security::AuthenticationStatus authentication_state; readonly attribute Security::MechanismType mechanism; attribute Security::AssociationOptions accepting_options_supported; attribute Security::AssociationOptions accepting_options_required; attribute Security::AssociationOptions invocation_options_supported; attribute Security::AssociationOptions invocation_options_required; ... boolean set_attributes ( in Security::AttributeList requested_attributes, out Security::AttributeList actual_attributes ); Security::AttributeList get_attributes ( in Security::AttributeTypeList attributes ); ... }; typedef sequence <Credentials> CredentialsList; local interface ReceivedCredentials : Credentials { ... };... local interface Current : SecurityLevel1::Current { readonly attribute ReceivedCredentials received_credentials; };}; |
Заключение
Совместное использование возможностей ORB, стандартных компонентов Сервиса Безопасности CORBA и его API позволяет создавать распределенные системы с требуемым уровнем защиты. При этом разработчик можно легко задействовать стандартные решения в области обеспечения безопасности, которые уже широко используются в компьютерной индустрии.
Стандарт ODBC
ODBC предназначен для предоставления прикладным разработчикам функциональных возможностей по обработке баз данных независимо от типа данных, к которым выполняется доступ, - базам данных ISAM, текстовым данным (Excel) или базам данных SQL. Эта цель достигается путем закрепления каждого драйвера ODBC за одним из предопределенных уровней соответствия. Чтобы считаться драйвером ODBC, драйвер должен соответствовать спецификациям ядра ODBC. Эти требования гарантируют, что разработчик приложения всегда может рассчитывать на одни и те же функциональные возможности независимо от того, к каким данным происходит обращение. Если формат используемых данных непосредственно не поддерживает основные функциональные возможности, драйвер ODBC должен эмулировать эти функции. С помощью ODBC можно манипулировать данными любой СУБД (и даже данными, не имеющими прямого отношения к базам данных, например данными в файлах электронных таблиц или в текстовых файлах), если для них имеется ODBC-драйвер. Для каждой используемой СУБД нужен собственный ODBC-драйвер. Говоря об ODBC, нельзя не отметить, что спецификация ODBC подразумевает несколько стандартов на ODBC-драйверы. Эти стандарты отличаются различной функциональностью, которая должна быть реализована в таком драйвере. Метод соединения с источником данных, получения сообщений об ошибках, а также стандартные интерфейсы регистрации являются общими для всех драйверов. Для обеспечения унифицированности драйверы придерживаются основных требований. Открытый интерфейс доступа к базам данных представляет собой библиотеку функций, которая позволяет прикладной программе обращаться к различным СУБД. Используя структурированный язык запросов SQL. Таким образом, разработчик прикладной программы может создавать программу для виртуальной базы данных и позволить загружаемому драйверу преобразовать логические данные в данные конкретной СУБД или систем, используемых данной прикладной программой.
Привлекательность ODBC обусловлена ее портативностью и взаимодействием с кодом прикладной программы. ODBC функционирует как стандартный интерфейс для разработчиков прикладных программ, а также для разработчиков библиотек драйверов.
Архитектура ODBC имеет четыре основных компонента: - прикладная программа, - диспетчер драйверов, - драйвер, - источник или источники данных.
Приложение, использующее интерфейс ODBC, выполняет следующие задачи: Запрашивает соединение с источником данных. Посылает SQL- запросы к источнику данных. Описывает область хранения и формат для результатов SQL- запросов. Запрашивает данные. Обрабатывает ошибки. Оповещает об ошибках. Осуществляет фиксацию или откат действий в режиме транзакций. Закрывает соединение с источником данных.
Диспетчер драйверов, совместно с набором средств ODBC, является динамически связанной библиотекой (DLL), которая загружает драйверы, обеспечивая единственную точку входа в функции ODBC для различных драйверов.
Функции интерфейса ODBC подразделяются на семь групп.
1. назначение и отмена назначения: идентификатор окружения, идентификатор соединения, идентификатор оператора
2. соединение
3. выполнение SQL-операторов
4. получение результатов
5. управление транзакциями
6. идентификация ошибок
7. смешанные функции
Теперь подробнее: